Rozproszony atak słownikowy na SSH

Przedmiotowy system jest klastrem obliczeniowym. Prowadzone obliczenia produkują duże ilości danych, które trzeba później przenosić między różnymi zewnętrznymi systemami. Odbywa się to przez sftp (scp), które musi być wystawione do internetu. Użytkownikcy również logują się przez ssh.

Przeważnie zdarzają się trwające kilka godzin słownikowe ataki na konto roota, na które nie zwracam uwagi. Tym razem trafił sie ktoś bardziej zdeterminowany, kto przypuścił rozproszony atak na ten system.

Przebieg ataku

Obserwowałem przez kilka dni, co się działo.

1. Równocześnie próby logowania podejmuje około 10-20 różnych hostów. Atak jest leniwy i cierpliwy, przez co nie widać go na wykresach obciążenia sieci (bps, pps), ani tym bardziej na wykresach obciążenia samego systemu. Ilości gniazd w stanie ESTABLISHED i TIME_WAIT też nie zwiększa się w wyraźny sposób.

2. Nie sądzę, aby atakujący robił wcześniej jakikolwiek rekonesans w sieci, którą zamierzał atakować. Mógłby bez trudu znaleźć charakterystyczne loginy występujące w naszej domenie i próbować atakować te konta. Tymczasem wszystkie loginy pochodziły z jakiegoś chińskiego słownika, przez co cały atak był marnowaniem prądu.

3. Komputery biorące udział w ataku są częścią dużego botnetu. Przypuszczam, że w tym jednym botnecie były ich tysiące. Ja cierpliwe doczekałem do ujawnienia ponad pięciuset.

4. Zablokowanie jednego z atakujących hostów powoduje automatyczne wysłanie kolejnego komputera z botnetu. Kontroler stara się tak dysponować zasobami, aby liczba aktywnych atakujących hostów wynosiła około 10.

5. Przy takim tempie ataku botnet dokonuje około 7000 prób logowania na dobę.

Logi

Mar 15 03:12:09 server sshd[3261]: Failed password for root from 201.149.20.162 port 18848 ssh2
Mar 15 03:12:53 server sshd[3274]: Failed password for invalid user ofisher from 111.231.137.158 port 58650 ssh2
Mar 15 03:13:03 server sshd[3285]: Failed password for root from 51.38.232.93 port 36012 ssh2
Mar 15 03:13:04 server sshd[3282]: Failed password for invalid user rustserver from 111.229.53.186 port 52124 ssh2
Mar 15 03:13:28 server sshd[3303]: Failed password for root from 114.67.99.229 port 49343 ssh2
Mar 15 03:13:52 server sshd[3315]: Failed password for root from 46.98.251.57 port 47538 ssh2
Mar 15 03:14:12 server sshd[3337]: Failed password for root from 212.129.249.202 port 48016 ssh2
Mar 15 03:14:13 server sshd[3339]: Failed password for invalid user sdtdserver from 94.180.58.238 port 46752 ssh2
Mar 15 03:14:18 server sshd[3342]: Failed password for invalid user weizeding from 113.141.70.199 port 57434 ssh2
Mar 15 03:14:35 server sshd[3347]: Failed password for root from 123.207.7.130 port 60144 ssh2
Mar 15 03:15:04 server sshd[3360]: Failed password for root from 43.251.214.54 port 38994 ssh2
Mar 15 03:15:34 server sshd[3376]: Failed password for root from 202.62.224.61 port 52112 ssh2
Mar 15 03:16:15 server sshd[3411]: Failed password for root from 193.70.38.187 port 33888 ssh2
Mar 15 03:16:27 server sshd[3413]: Failed password for invalid user tony from 123.207.7.130 port 53628 ssh2

Prób logowania jest około 5/min. Niektóre na roota, niektóre na nieistniejące konta ze słownika. W danym oknie czasowym jeden host pojawia się jeden lub najwyżej dwa razy. To może trochę utrudniać automatyczne wykrywanie i blokowanie botnetu w sytuacji, gdy normalny (legalny) ruch na serwerze jest duży.

Blokowanie

Precyzyjne blokowanie takich ataków, przy jednoczesnym utrzymaniu pełnej dostępności usług dla legalnych użytkowników, jest w zasadzie niemożliwe.

Uruchomiłem automat, który blokował na poziomie filtra pakietów ruch z hostów, z których pochodziły te próby logowania. Informacje o ilości zablokowanych hostów wyciągnąłem z iptables do zabbixa.

Warstwa czerwona to blokady nałożone na 15 minut. Są to hosty, które przed chwilą atakowały, mają 15 minut przerwy i za chwilę znowu zaczną atak. Jeśli w ciągu godziny jeden host trafił do tej grupy trzykrotnie, dostawał od razu blokadę na tydzień. Tę drugą grupę recydywstów reprezentuje warstwa żółta.

Stan po 14 godzinach:

Widać, że pomimo tego, iż przybywa hostów zablokowanych na siediem dni (w tempie około 14/h), to grupa aktywna nie zmienia liczebności. Botnet stara się utrzymać stałą prędkość ataku.

Stan po 3 dniach:

Liczba zablokowanych adresów IP w ciągu 2 dni wzrosła z 200 do prawie 600, prędkość ataku (mierzona w ilości prób logowania na dobę) udało się zmniejszyć zaledwie o 50%. Liczba hostów aktywnych wynosiła przez prawie cały czas około 10.

Uzyskane spowolnienie ataku miało związek z czasem, który potrzebny był kontrolerowi botnetu na podjęcie decyzji o wysłaniu nowego hosta na miejsce jego zablokowanego poprzednika.

Podsumowanie

Właściwie jedyny sposob, aby całkowicie zablokować taki atak "u celu", to wyczerpanie całego botnetu na filtrach. W przypadku małych botnetów to możliwe, jednak w tym przypadku raczej nie.

Ostatecznie problem rozwiązała white lista. Tutaj można było ją wprowadzić na jakiś czas. Częściej jednak nie da się tego zrobić.