Iptables TARPIT, czyli spowolnij boty

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:

  1. Slow Down Internet Worms With Tarpits
  2. LaBrea: „Sticky” Honeypot and IDS
  3. Debian TARPIT iptables How To

Dziwne wpisy w auth.log, czyli coś nowego na SSH

Jedną z maszynek mam wystawioną do netu z SSH na standardowym, 22 porcie[1]. Głównie w celu zbierania śmieci (i zgłaszania ich do blocklist.de). Zerknąłem na /var/log/auth.log i zobaczyłem masę nietypowych wpisów typu:

Jan  8 19:41:28 xxx sshd[32002]: Connection closed by 195.130.253.159 [preauth]Jan  8 19:46:52 xxx sshd[32298]: Connection closed by 195.130.253.159 [preauth]Jan  8 19:52:16 xxx sshd[32645]: Connection closed by 195.130.253.159 [preauth]

Są to jedyne wpisy w logach dotyczące tych IP. IP jest stosunkowo niewiele, połączenia zwykle co kilka minut. Brak śladów po próbie logowania. Wydaje mi się, że wcześniej tego nie było, przynajmniej nie aż tyle. Logi mam od 7 grudnia, wygląda, że zjawisko zaczęło się w okolicy 11 grudnia, a apogeum miało miejsce na przełomie roku:

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $1" "$2}' | sort | uniq -c | sort -n      1 Dec 11      1 Dec 12      1 Dec 21      1 Dec 8      2 Dec 18      4 Dec 17     10 Dec 26     19 Dec 16     43 Dec 14     75 Dec 22    150 Jan 4    155 Jan 8    159 Dec 24    209 Dec 15    214 Dec 27    267 Jan 5    303 Jan 7    360 Dec 28    381 Jan 3    445 Dec 29    446 Jan 6    717 Dec 30    905 Jan 2   1041 Jan 1   1132 Dec 31

Jeśli chodzi o rozkład IP, to na moim serwerze wygląda to następująco (tylko ponad 100 wystąpień prezentuję):

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $9}' | sort | uniq -c | sort -n | egrep "[0-9][0-9][0-9]    113 128.199.252.25    147 121.78.147.217    159 195.154.226.100    358 195.130.253.159    416 118.98.43.33    684 37.187.119.89   1378 76.74.157.51   1416 112.216.92.44   1883 112.107.2.154

Kolejnych 13 IP ma powyżej 10 wystąpień.

Jeśli chodzi o kraje, to raczej malware’owy standard (dla >10 wystąpień):

zegrep -h "Connection closed by .*preauth" /var/log/auth.log* | awk '{print $9}' | sort | uniq -c | sort -n | egrep "[0-9][0-9] " | awk '{print $2}' | xargs -L1 geoiplookup | sort | uniq -c | sort -n      1 GeoIP Country Edition: AR, Argentina      1 GeoIP Country Edition: AT, Austria      1 GeoIP Country Edition: GB, United Kingdom      1 GeoIP Country Edition: ID, Indonesia      1 GeoIP Country Edition: IT, Italy      1 GeoIP Country Edition: NL, Netherlands      1 GeoIP Country Edition: RU, Russian Federation      2 GeoIP Country Edition: FR, France      2 GeoIP Country Edition: IP Address not found      3 GeoIP Country Edition: CN, China      3 GeoIP Country Edition: KR, Korea, Republic of      5 GeoIP Country Edition: US, United States

Ktoś się orientuje o co chodzi? Jakiś nowy atak? Błąd w skryptach od bruteforce w którymś botnecie?

UPDATE Dzięki pomocy ludzi z #z3s udało się ustalić, że tego typu wpisy w logach pojawią się, jeśli nawiąże się połączenie tylko w celu pobrania obsługiwanych sposobów szyfrowania (i rozłączy się po ich otrzymaniu). Nie tłumaczy to oczywiście, czemu połączenia się powtarzają. Padła sugestia, że może jakiś głupi bot wykłada się na nietypowej konfiguracji – host nie ma domyślnego konfiga SSH, tylko wdrożone zalecenia z bettercrypto.org (polecam, swoją drogą).

[1] Ponieważ było to pierwsze pytanie, jakie dostałem, to dopiszę: tak, celowo, tak nie mam tu innego portu/fail2ban/knockd, choć każda z tych metod pewnie eliminuje 99% skanów. Jestem świadomy możliwości nie oglądania tego typu rzeczy, ale tu chcę je widzieć.

Shutter, czyli Linux i screenshoty

Przyznaję, że jeśli chodzi o zrzuty ekranu pod Linuksem, to nie znałem do tej pory dobrego narzędzia. Znaczy jest scrot[1], który jest prosty, bardzo mały, lekki i wywoływany z CLI, i którego użycie w wersji podstawowej, czyli cd /tmp && scrot -d 8 było proste do zapamiętania, ale… jak lubię CLI, tak w przypadku grafiki to zdecydowanie nie jest to, co tygrysy lubią najbardziej. Tym bardziej, że zwykle robię zrzuty przeglądarki, więc trzeba było dodatkowo przyciąć, wymazać, wykadrować… Czyli w ruch szedł GIMP.

Zrzuty ekranu robię na tyle rzadko, że nigdy nie szukałem dokładniej programu do screenshotów i przypuszczałem, że po prostu takiego nie ma. Okazuje się, że się myliłem. Kumpel z pracy pokazał mi genialny program o nazwie shutter[2]. Nie jest lekki (łącznie z zależnościami pobrał kilkadziesiąt MB danych), ale za to jest w pełni graficzny, minimalizuje się do traya, pozwala na robienie screenshotów zarówno całego pulpitu, tylko wybranego okna programu jak i wcześniej zaznaczonego obszaru (odpada konieczność kadrowania).

Po wykonaniu zrzutu ekranu, można go zapisać na dysku (wspierane wszystkie popularne formaty grafiki), wysłać na jeden z wielu dostępnych serwisów do publikowania obrazków, zapisać na zdalnym hoście przy pomocy FTP lub wysłać do innego programu do dalszej obróbki. Jeśli zajdzie potrzeba, bo sporo funkcji jest wbudowanych np. w postaci pluginów. Jest też wsparcie dla sesji screenshotów podobno z automatycznym numerowaniem, ale nie używam, więc nie testowałem.

W zasadzie, gdyby działało wszystko, co jest opisane na stronie, to nie potrzebowałbym nie potrzebuję niczego innego do robienia i obróbki screenshotów. 🙂 , niestety, w mojej wersji (0.88.3, Debian Wheezy) nie widzę narzędzia do cenzurowania/ukrywania danych, a czasami z tego korzystam. Możliwe, że pojawiło się dopiero w nowszej wersji Tak czy inaczej Polecam zapoznanie się z programem shutter każdemu, kto potrzebuje robić screenshoty pod Linuksem – zdecydowanie interesujący i dopracowany kawałek softu.

UPDATE: Aby działała edycja screenshotów (w tym cenzurowanie), konieczne jest jeszcze doinstalowanie biblioteki Perla: apt-get install libgoo-canvas-perl.

[1] Instalacja przez apt-get install scrot.

[2] Instalacja (Debian) to oczywiście apt-get install shutter.