Łatwy sposób na ochronę Mikrotika przed atakami

Chcę podzielić się ze społecznością prostym i działającym sposobem wykorzystania Mikrotika do ochrony sieci i usług „wyglądających” zza niej przed atakami z zewnątrz. Mianowicie tylko trzy zasady zorganizowania Honeypota na Mikrotiku.

Wyobraźmy sobie więc, że mamy małe biuro, z zewnętrznym adresem IP, za którym znajduje się serwer RDP, dzięki któremu pracownicy mogą pracować zdalnie. Pierwsza zasada to oczywiście zmiana portu 3389 na interfejsie zewnętrznym na inny. Ale to nie potrwa długo; po kilku dniach dziennik audytu serwera terminali zacznie pokazywać kilka nieudanych autoryzacji na sekundę od nieznanych klientów.

Inna sytuacja, gwiazdkę masz ukrytą za Mikrotikiem, oczywiście nie na porcie udp 5060, a po kilku dniach zaczyna się też wyszukiwanie hasła... tak, tak, wiem, Fail2ban to dla nas wszystko, ale jeszcze musimy popracuj nad tym... na przykład niedawno zainstalowałem to na Ubuntu 18.04 i ze zdziwieniem odkryłem, że Fail2ban nie zawiera bieżących ustawień gwiazdki z tego samego pudełka tej samej dystrybucji Ubuntu... i szybkich ustawień Google na gotowe „przepisy” już nie działają, liczba wydań z biegiem lat rośnie, a artykuły z „przepisami” na stare wersje już nie działają, a nowe prawie nigdy się nie pojawiają…

Czyli w skrócie czym jest Honeypot - jest to Honeypot, w naszym przypadku dowolny popularny port na zewnętrznym IP, każde żądanie do tego portu od zewnętrznego klienta wysyła adres src na czarną listę. Wszystko.

/ip firewall filter
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment="block honeypot ssh rdp winbox" 
    connection-state=new dst-port=22,3389,8291 in-interface=
    ether4-wan protocol=tcp
add action=add-src-to-address-list address-list="Honeypot Hacker" 
    address-list-timeout=30d0h0m chain=input comment=
    "block honeypot asterisk" connection-state=new dst-port=5060 
    in-interface=ether4-wan protocol=udp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
    "Honeypot Hacker"

Pierwsza reguła na popularnych portach TCP 22, 3389, 8291 zewnętrznego interfejsu ether4-wan wysyła adres IP „gościa” na listę „Honeypot Hacker” (porty dla ssh, rdp i winbox są wcześniej wyłączane lub zmieniane na inne). Drugi robi to samo na popularnym UDP 5060.

Trzecia reguła na etapie przed trasowaniem odrzuca pakiety od „gości”, których adres srs jest zawarty w „Honeypot Hacker”.

Po dwóch tygodniach pracy z moim domowym Mikrotikiem na liście „Honeypot Hacker” znalazło się około półtora tysiąca adresów IP tych, którzy lubią „trzymać za wymię” moich zasobów sieciowych (w domu mam własną telefonię, pocztę, nextcloud, rdp). Ataki brutalnej siły ustały, nadeszła błogość.

W pracy nie wszystko okazało się takie proste, tam nadal łamią serwer RDP poprzez brutalne wymuszanie haseł.

Podobno numer portu skaner ustalał na długo przed włączeniem Honeypota, a w czasie kwarantanny nie jest już tak łatwo rekonfigurować ponad 100 użytkowników, z czego 20% ma ponad 65 lat. W przypadku, gdy nie można zmienić portu, istnieje mały działający przepis. Widziałem coś podobnego w Internecie, ale wiąże się to z dodatkowymi dodatkami i dostrojeniami:

Zasady konfiguracji blokowania portów

 /ip firewall filter
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=15m chain=forward comment=rdp_to_blacklist 
    connection-state=new dst-port=3389 protocol=tcp src-address-list=
    rdp_stage12
add action=add-src-to-address-list address-list=rdp_stage12 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage11
add action=add-src-to-address-list address-list=rdp_stage11 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage10
add action=add-src-to-address-list address-list=rdp_stage10 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage9
add action=add-src-to-address-list address-list=rdp_stage9 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage8
add action=add-src-to-address-list address-list=rdp_stage8 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage7 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage6
add action=add-src-to-address-list address-list=rdp_stage6 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage5
add action=add-src-to-address-list address-list=rdp_stage5 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage4
add action=add-src-to-address-list address-list=rdp_stage4 
    address-list-timeout=4m chain=forward connection-state=new dst-port=
    3389 protocol=tcp src-address-list=rdp_stage3
add action=add-src-to-address-list address-list=rdp_stage3 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage2
add action=add-src-to-address-list address-list=rdp_stage2 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp src-address-list=rdp_stage1
add action=add-src-to-address-list address-list=rdp_stage1 
    address-list-timeout=4m chain=forward connection-state=new dst-port=3389 
    protocol=tcp 
/ip firewall raw
add action=drop chain=prerouting in-interface=ether4-wan src-address-list=
rdp_blacklist

W ciągu 4 minut zdalny klient może wysłać tylko 12 nowych „żądań” do serwera RDP. Jedna próba logowania to od 1 do 4 „żądań”. Na 12. „prośbę” - blokowanie na 15 minut. W moim przypadku napastnicy nie przestali hackować serwera, dostosowali się do timerów i teraz robią to bardzo powoli, taka prędkość selekcji zmniejsza skuteczność ataku do zera. Pracownicy firmy nie odczuwają praktycznie żadnych niedogodności w pracy z powodu podjętych działań.

Kolejna mała sztuczka
Ta reguła włącza się zgodnie z harmonogramem o 5:XNUMX w nocy i wyłącza o XNUMX:XNUMX, kiedy prawdziwi ludzie zdecydowanie śpią, a zautomatyzowani zbieracze nadal nie śpią.

/ip firewall filter 
add action=add-src-to-address-list address-list=rdp_blacklist 
    address-list-timeout=1w0d0h0m chain=forward comment=
    "night_rdp_blacklist" connection-state=new disabled=
    yes dst-port=3389 protocol=tcp src-address-list=rdp_stage8

Już przy 8. połączeniu adres IP atakującego znajduje się na czarnej liście przez tydzień. Uroda!

Cóż, oprócz powyższego dodam link do artykułu na Wiki z działającą konfiguracją ochrony Mikrotika przed skanerami sieciowymi. wiki.mikrotik.com/wiki/Drop_port_scanners

Na moich urządzeniach to ustawienie współpracuje z opisanymi powyżej regułami Honeypot, dobrze je uzupełniając.

UPD: Zgodnie z sugestiami w komentarzach reguła odrzucania pakietów została przeniesiona do formatu RAW, aby zmniejszyć obciążenie routera.

Źródło: www.habr.com