Ugrzęźnij w płynnym asfalcie

https://xpil.eu/ln9

Ale nie Ty, Czytelniku. Nie. Ty sobie czytaj. Tytułowy apel kieruję do hakerów i hack-botów zaglądających mi regularnie na port 22 i próbujących z uporem godnym lepszej sprawy wbić mi się na serwer z blogiem.

Hak wam, gnojki, w smak.

"Tarpit" to popularne w świecie komputerowym określenie na wciągnięcie atakującego w pułapkę, która konsumuje względnie niedużo zasobów ofiary, a potencjalnie całkiem sporo - napastnika.

Słowo jest połączeniem angielskich słów "tar" - "asfalt" oraz "pit" czyli "dziura" albo "jama". Tak naprawdę "tar pit" tłumaczy się dosłownie jako "jezioro asfaltowe" i jest to na ogół efekt jakiegoś błędu lub zaniedbania budowlanego. Można w nim ugrzęznąć na dobre, bo asfalt - nawet płynny - jest cholernie gęsty. "Ruszać się jak mucha w smole" i tak dalej. Wiadomo.

Przykładem komputerowego tarpitu może być na przykład lista losowo wygenerowanych adresów email, rozbita na strony, które się nigdy nie kończą. Jeżeli bot zbierający adresy natrafi na taką stronę (i jest odpowiednio głupi), sczeźnie tam, próbując bez końca zapamiętywać bzdurne adresy, pod którymi nic nie ma.

Od niedawna uruchomiłem taki tarpit na moim blogu, na porcie 22 (czyli domyślnym porcie SSH).

Idea jest bardzo prosta i bazuje na pewnej właściwości protokołu SSH: otóż na samym początku, zanim jeszcze nastąpi połączenie do serwera i próba jakiejkolwiek autentykacji, klient wysyła tekst SSH - wersja1 - wersja2 komentarze, po czym to samo robi serwer czyli my.

Ma to na celu ustalenie, czy klient i serwer "rozmawiają" w tej samej wersji protokołu SSH; wersja1 dotyczy protokołu, wersja2 - oprogramowania.

Jednak zgodnie z oficjalną specyfikacją serwer ma prawo wysłać najpierw dowolny inny tekst - jedyne ograniczenie jest takie, że żadna linia tego tekstu nie może być dłuższa niż 255 znaków. A klient ma w tym czasie grzecznie czekać na linię zaczynającą się od "SSH-..."

To w zupełności wystarczy!

Prawdziwy serwer SSH ustawiamy na innym porcie (najlepiej jakimś wysokim, pięciocyfrowym), a na porcie 22 uruchamiamy program endlessh, który każdemu próbującemu się podłączyć klientowi wysyła - zamiast numeru wersji klienta i protokołu - nieskończony ciąg losowych linii tekstu, nie dłuższych niż 255 znaków. Po wysłaniu każdej linii czeka 10 sekund, co jest wystarczająco krótko, żeby nie było time-out-u, ale wystarczająco długo, żeby serwer nie miał za dużo roboty. A atakujący grzecznie czeka na wersję, która nigdy nie nadejdzie.

Jeżeli atakujący robi to za pomocą bota/automatu (a większość script kiddies tak właśnie robi), to jego program zawiesi się bezproduktywnie. Jedyne co można zrobić, to "nauczyć" bota, żeby się rozłączał po upływie zadanego czasu, ale na to script kiddies są często niewystarczająco wyszkoleni.

Póki co endlessh nie jest częścią żadnej oficjalnej dystrybucji linuksowej, trzeba go więc ściągnąć i zainstalować ręcznie:

  1. Logujemy się na nasz serwer
  2. Ściągamy endlessh: git clone https://github.com/skeeto/endlessh
  3. Czekamy chwilę.
  4. Wchodzimy do folderu aplikacji: cd endlessh
  5. Instalujemy aplikację, czyli najpierw: make a zaraz potem: make install.
  6. Instalacja trwa niecałą sekundę.
  7. Voila!

Teraz możemy uruchomić tarpita poleceniem: nohup endlessh -p 22 & po czym wylogowujemy się z konsoli serwera i gra gitara.

Pamiętajmy tylko, żeby najpierw ustawić sobie nasz prawdziwy serwer ssh na jakimś innym porcie. Na przykład 39563 albo 17320 albo nawet 62137. Obojętnie, byle nie 22, nie 80 i nie 443.

Smacznego!

No chyba, że jesteś chakierę, wtedy udław się.

😉

P.S. Dopisane kilka dni później: niektóre linuksowe klienty SSH akceptują "tylko" 1024 linie tekstu od serwera i jeżeli wśród nich nie natrafią na SSH-..., rozłączają się z komunikatem:

kex_exchange_identification: No SSH version received in first 1024 lines from server

1024 linie to 10230 sekund czekania. Prawie trzy godziny zamiast kilku milisekund. Tak właśnie działa tarpit.

https://xpil.eu/ln9

3 komentarze

  1. Czy jest generowana jakaś statystyka? Np. ile było prób, po jakim czasie klienci się rozłączają, czy klienci z tego samego IP próbują ponownie się podłączyć (a jeśli tak, to ile czekali).

    1. Z tego co kojarzę, można przekierować wyjście aplikacji do logu, i potem próbować to poanalizować we własnym zakresie. Na GH jest więcej informacji, zajrzyj sobie.

  2. Jeśli już zmieniasz port serwera SSH, to możesz użyć po prostu tarpit w iptables: https://zakr.es/blog/2015/01/iptables-tarpit-czyli-spowolnij-boty/ Oczywiście działa to w innej warstwie. No i da się wykorzystać także na porcie 22, jeśli jesteś w stanie dać regułę na “swoje” adresy IP z których się łączysz lub wykorzystasz port knocking.

    Przy okazji: przenoszenie SSH na wysokie, nieuprzywilejowane porty to niekoniecznie dobry pomysł https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

    Aby pozbyć się najbardziej uporczywych można też skorzystać z fail2ban, a dodatkowo, wysyłając skanujące IP do serwisów w stylu blocklist.de abuseipdb.com zmienić nasz serwer w sondę wykrywającą złe IP. Ostatnio coraz bardziej się skłaniam do takiego rozwiązania: okresowe pobieranie listy IP do zablokowania (iptables) z ww. serwisów, do tego fail2ban raportujący to, co się prześliźnie. Póki co tylko blokuję i mam raptem 20 IP zablokowanych przez fail2ban

Leave a Comment

Komentarze mile widziane.

Jeżeli chcesz do komentarza wstawić kod, użyj składni:
[code]
tutaj wstaw swój kod
[/code]

Jeżeli zrobisz literówkę lub zmienisz zdanie, możesz edytować komentarz po jego zatwierdzeniu.