Jak wiadomo, nie jestem fanem malware i raczej staram się uprzykrzać życie botom i spamerom. Nic wielkiego: a to zrobię miejsce, gdzie boty mogą znaleźć wiele adresów email, a to zwykły spam do SpamCopa wyślę, a to boty próbujące zgadnąć hasła SSH metodą bruteforce zgłoszę do blocklist.de. No i właśnie o botach atakujących SSH tym razem będzie.
Poprzedni wpis był o dziwnych wpisach w auth.log i choć już prawdopodobnie sama konfiguracja serwera powodowała zaangażowanie botów, z którego nie miały pożytku, to, jak zapowiedziałem w komentarzach, postanowiłem pójść o krok dalej.
Otóż iptables pozwala nie tylko na odrzucenie połączenia (DROP, REJECT), ale – co prawda nie w podstawowej wersji – także na udawanie nawiązania połączenia przy pomocy TARPIT. Jeśli chodzi o szczegóły, to odsyłam do tego artykułu, a w skrócie: połączenie przychodzące do serwera jest nawiązane, dane nie są przesyłane, nie jest honorowane zakończenie połączenia, musi dojść do timeoutu po stronie klienta (bota). Czyli bot traci zasoby na komunikację, która się nie odbywa. Zużywa ich więcej, niż gdyby po stronie serwera był w iptables REJECT czy DROP.
Aby zainstalować TARPIT w Debianie, potrzebujemy źródeł kernela oraz pakietu xtables-addons-dkms. Pierwsze możemy zainstalować przez:
apt-get install linux-headers-`uname -r`
Przy okazji powinny doinstalować gadżety typu GCC, które za moment będą potrzebne. Natomiast właściwy pakiet instalujemy oczywiście przez:
apt-get install xtables-addons-dkms
Jeśli wszystko poszło OK, to zostaną zbudowane stosowne moduły dla aktualnie uruchomionego kernela i można korzystać w iptables z -j TARPIT.
Oczywiście to nie wszystko, co można zrobić z TARPIT. Inne, związane z utrudnieniem skanowania itp. można znaleźć na stronie projektu LaBrea. Polecam lekturę.
Proste rozwiązanie dla tych, którzy przenieśli SSH na inny port, niż standardowy, to utworzenie reguły:
iptables -A INPUT -p tcp -m tcp --dport 22 -j TARPIT
Wszystkie boty próbujące bruteforce na standardowym porcie 22 ugrzęzną tu na chwilkę. 😉
Linki:
Wybacz pytanie laika, ale co będzie gdy to udawanie nawiązania połączenia wystąpi na masową skalę (z moich amatorskich obserwacji wynika, że boty rzadko analizują odpowiedź na bieżąco), Ty ich „zawiesisz” w powietrzu, ale maszyna jaką dysponujesz jest słaba, a atakujący ma o wiele grubszą rurkę? Poważnie pytam. Mam wrażenie, że można też „załatwić” w ten sposób samego siebie. Czy się mylę?
1. Dany bot nie ma powodu, by nawiązywać kolejne połączenia. Przecież właśnie się połączył z ofiarą i „działa”. 😉
2. Te boty nie mają na celu (D)DoSa, tylko przejęcie kontroli nad systemami. Więc nawiązuje minimalny ruch.
3. Maszyna nie jest tak słaba (nawet jak na to co miałaby zrobić przy nawiązaniu połączenia SSH), rurka jest przyzwoita. Boty pewnie siedzą na zainfekowanych maszynach na łączach klienckich.
4. Myślę (nie sprawdzałem, jeszcze, pewnie weekend), że TARPIT jest na tyle sprytnym rozwiązaniem, że od strony systemu na którym jest uruchomiony obciążenie jest praktycznie żadne, a na pewno mniejsze, niż przy aktywnej usłudze (choć większe, niż przy DROP). Ot, jak przyjdzie SYN, to odsyła SYN, ACK. Przy REJECT na iptables też odsyła odpowiedź – myślę, że podobny narzut.
Ad.3. Pytałem pod kątem wypróbowania tego np. u siebie. Słaba maszyna, rurka jeszcze słabsza.
@Monter Śmiało. Szansa, że w ogóle zauważysz różnicę jest przyzerowa, o problemach nie wspominam nawet.
Nie slyszalem o TARPIT, dzieki rozie. Teraz mozna do firewall’a dodac TARPIT zamiast drop 😉
iptables -A INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –update –seconds 120 –hitcount 5 -j TARPIT