Chcę podzielić się z społecznością prostym i działającym sposobem, jak za pomocą Mikrotika ochronić swoją sieć oraz usługi, które się przez niego "wyglądają", przed zewnętrznymi atakami. A mianowicie, jak za pomocą trzech zasad zorganizować na Mikrotiku honeypot.
Wyobraźmy sobie, że mamy małe biuro, a zewnętrzny IP chroni serwer RDP dla pracy pracowników zdalnych. Pierwszą zasadą jest oczywiście zmiana portu 3389 na zewnętrznym interfejsie na inny. Jednak to nie wystarczy, po kilku dniach dziennik audytu serwera terminalowego zacznie pokazywać kilka nieudanych prób autoryzacji na sekundę od nieznanych klientów.
Inna sytuacja, gdy za Mikrotikiem ukryty jest asterisk, oczywiście nie na porcie udp 5060, i po kilku dniach również zaczyna się atak siłowy na hasła... tak, tak, wiem, że fail2ban to nasze wszystko, ale będziemy musieli jeszcze trochę nad nim popracować... niedawno na przykład zainstalowałem go na ubuntu 18.04 i z zaskoczeniem odkryłem, że w standardowej konfiguracji fail2ban nie zawiera aktualnych ustawień dla asteriska w tej samej wersji dystrybucji ubuntu... a szybkie wyszukiwanie gotowych „przepisów” już nie działa, liczby wersji z latami rosną, a artykuły z „przepisami” dla starych wersji już nie działają, a nowych pojawia się prawie wcale... Ale wracając do sedna...
Co to jest honeypot w dwóch słowach — to pułapka, w naszym przypadku jakiś popularny port na zewnętrznym IP, każdy żądanie do tego portu od zewnętrznego klienta wysyła adres źródłowy do czarnej listy. I to 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 zasada dla popularnych portów TCP 22, 3389, 8291 na zewnętrznym interfejsie ether4-wan wysyła IP „gościa” do listy „Honeypot Hacker” (porty dla ssh, rdp i winbox zostały wcześniej wyłączone lub zmienione na inne). Druga zasada działa tak samo na popularnym UDP 5060.
Trzecia zasada na etapie przetwarzania przed routowaniem blokuje pakiety „gości”, których adres źródłowy znalazł się na liście „Honeypot Hacker”.
Po dwóch tygodniach pracy mojego domowego Mikrotika lista „Honeypot Hacker” obejmowała około półtora tysiąca adresów IP miłośników „trzymania za udko” moich zasobów sieciowych (w domu mam własną telefonie, e-mail, nextcloud, rdp). Ataki typu brute-force ustały, nastał błogostan.
W pracy nie jest tak łatwo, tam serwer rdp nadal jest łamany metodą ataku siłowego.
Wygląda na to, że numer portu został określony przez skaner długo przed włączeniem honeypota, a w czasie kwarantanny nie jest łatwo przestawić ponad 100 użytkowników, z których 20% ma ponad 65 lat. W przypadku, gdy port nie może być zmieniony, istnieje mały sprawdzony przepis. Spotkałem coś podobnego w Internecie, ale tutaj pojawia się dodatkowe poprawki i drobne dostrojenia:
Zasady konfiguracji Port Knocking
/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
Zdalny klient ma tylko 4 minuty na złożenie 12 nowych 'żądań' do RDP serwera. Jedna próba logowania to od 1 do 4 'żądań'. Po 12-tym 'żądaniu' - blokada na 15 minut. W moim przypadku napastnicy nie przestali atakować serwera, dostosowali się do timerów i teraz robią to bardzo powoli, taka prędkość próbki obniża skuteczność ataku do zera. Pracownicy firmy nie odczuwają praktycznie żadnych niedogodności związanych z podjętymi działaniami.
Jeszcze jedna mała sztuczka
Ta zasada jest włączana zgodnie z harmonogramem o godzinie 1 w nocy i wyłączana o 5, kiedy żywi ludzie z pewnością śpią, a zautomatyzowane próbki wciąż są aktywne.
/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_stage8Już przy 8-ym połączeniu IP napastnika jest dodawane do czarnej listy na tydzień. Piękne!
No i dla uzupełnienia dodam link do artykułu Wiki, z działającą konfiguracją ochrony Mikrotika przed skanowaniami sieciowymi.
Na moich urządzeniach ta konfiguracja działa razem z powyżej opisanymi zasadami honeypot, dobrze je uzupełniając.
UPD: Jak zasugerowano w komentarzach, zasada dropowania pakietów została przeniesiona do RAW, aby zmniejszyć obciążenie routera.
Źródło: habr.com
