Jak zdiagnozować atak DDoS?

Jak zdiagnozować atak DDoS?

Wstęp

W regulaminie VPS znajduje się następujący zapis:

6. OBOWIĄZKI UŻYTKOWNIKA 6.1. Użytkownik jest zobowiązany: 6.1.5. do zapewnienia bezpieczeństwa systemu;

Zwykle sami sobie ataków na serwer nie sprowadzamy. Jednak dalej ponosimy odpowiedzialność jeśli to przez atak na nasz serwer padnie infrastruktura usługodawcy. Często nie zdajemy sobie sprawy z tego, że nasz serwer właśnie przeżywa atak DDoS. Dobrą praktyką jest codzienne kontrolowanie serwera, czy nic mu się nie dzieje. Jak zatem zdiagnozować atak?

Poradnik zakłada, że przeczytałeś i rozumiesz teorię wyjaśnioną w wątku SystemZ: https://lvlup.rok.ovh/t/rodzaje-atakow-i-sposoby-ochrony/131

Od czego zacząć? Jeśli zauważasz, że serwer odpowiada wolno odpowiada, laguje ZAWSZE na początku upewniaj się, czy to przypadkiem nie Twoje łącze internetowe nie powoduje problemów. Często okazuje się, że lagi są psikusem operatora, niekoniecznie niewydalającym serwerem. Gdy się już upewnisz, że to serwer działa powoli przechodzimy do diagnozy.

Przed przystąpieniem do dalszych czynności upewnij się, że masz następujące programy:

• htop
• iftop

1. Poprawne działanie serwera

Na początku należy sprawdzić, czy problemy nie są wynikiem błędu w zainstalowanym oprogramowaniu lub/i sprytnym jego wykorzystaniu przez "Użyszkodnika". Sprawdźmy, co mówi htop:

Na co zwracać uwagę?

• Patrzymy na Wykorzystanie RAM przez system. Jeśli jest zbyt wysokie zwróćmy uwagę na to, jakie procesy ją zużywają. (Kolumna MEM%) Skąd mamy wiedzieć, kiedy użycie RAMu jest zbyt wysokie? Tutaj musimy już polegać na własnych obserwacjach. Zasada jest taka, że pojedynczy proces nie powinien zużywać więcej niż 75%, a cały system nie więcej niż 90%. Jak już wcześniej wspomniałem, dobrą praktyką jest codzienna obserwacja serwera, abyśmy mieli punkt odniesienia.
• Load average. Jest to średnia wykorzystania CPU przez odpowiednio: 1, 5 i 15 minut. 0.00 odpowiada 0% wykorzystania CPU, a 1.00 to 100%. Wartość ta odnosi się do jednego rdzenia procesora, tak więc 1.00 na jednordzeniowym procesorze to 100%, ale na dwurdzeniowym to już 50% (2.00 to 100% wykorzystania 2 rdzeni). Wartośc ta może być większa niż ilość rdzeni, jeśli serwer jest zbyt wolny i nie nadąża (np. 250% wykorzystania procesora to 2.50). Na poprawnie działającym systemie w warunkach maksymalnego obciążenia (czyli na przykład, gdy jest dużo graczy na serwerze) wykorzystanie procesora nie powinno przekraczać 80%. Zawsze powinno być trochę zapasu. Warto zauważyć, że przy ataku na nasz serwer często wykorzystanie procesora jest wyższe niż zwykle, często procesor nie nadąża z zapytaniami, co skutkuje tym, że Load Average jest wyższy niż liczba rdzeni serwera.
• Sprawdzamy, jakie procesy wykorzystują CPU. (Kolumna CPU%) Jeśli jest to głównie nasz serwer gry lub cokolwiek innego po czym moglibyśmy się spodziewać dużego wykorzystania CPU, nie ma problemu. Jeśli jest to któreś z pobocznych "zajęć" (np. SSH lub serwer WWW), warto się temu przyjrzeć. Można też sprawdzić, czy któryś z naszych graczy celowo nie robi czegoś, co ma obciążyć nasz serwer.

Przykładowa maszyna do generowania lagów w Minecraft. (Źródło)

Jeśli zauważymy któryś z powyższych objawów dobrze jest zrestartować serwer, aby sprawdzić, czy problem nadal występuje.

2. Atak wolumetryczny -- Ataki wolumetryczne typu DoS i DDoS są stosunkowo łatwe do zdiagnozowania. Ich objawem jest zwiększony ruch sieciowy. Spowolnienie pracy serwera wynika z przeciążenia sieci (Gdy atakujący próbuje "przepchać" więcej pakietów niż pozwala łącze), lub jest spowodowane przeciążeniem samego serwera (Gdy serwer nie nadąża z odpowiadaniem).

Aby zrozumieć ruch, który zaraz będziemy obserwować musimy wiedzieć coś na temat portów, których używamy.

Sprawdźmy najpierw na jakich portach nasłuchuje nasz serwer oraz które programy je obsługują. Wpiszmy polecenie sudo ss -tunlp .

Program wydrukuje nam jakie porty są otwarte, na jakich użytkownicy mogą się łączyć z naszym serwerem.

Porada Jeśli chcesz się dowiedzieć coś więcej na temat omawianego programu, zaglądnij do manuala, wpisz man , np. man ss

Przykładowy wynik:

Netid State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port
udp   UNCONN  0       0              0.0.0.0:9987         0.0.0.0:*     users:(("ts3server",pid=331,fd=51))
tcp   LISTEN  0       128               [::]:22              [::]:*     users:(("sshd",pid=290,fd=4))

Interesujące nas kolumny:

• Netid - Protokół TCP lub UDP
• State - Status połączenia. Przełącznikiem -l wybraliśmy, aby wyświetlać tylko porty nasłuchujące. Zauważ, że status dla portów UDP różni się od statusu dla portów TCP. Wynika to z różnic pomiędzy tymi protokołami, które wykraczają poza zakres tego poradnika. Nie będziemy się tym zajmować.
• Local Address:Port - Adres i port na którym serwer nasłuchuje połączeń. 0.0.0.0 oznacza wszystkie interfejsy ipv4, a [::] oznacza wszystkie interfejsy ipv6.
• users - Dane procesu(ów) obsługujących port: Nazwa, PID i File Descriptor

Informacje na temat najczęściej spotykanych numerów portów można znaleźć pod adresem: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Do rzeczy Jeśli już wiemy co mamy uruchomione na serwerze, co może być potencjalnym celem ataków możemy zająć się właściwym obserwowaniem serwera. Zobaczmy, co na temat ruchu mówi iftop. Uruchommy iftop -PNn

Na początek może krótkie wyjaśnienie użytych przełączników:

• -n - Wyłącza rozwiązywanie nazw - Zapobiega sytuacjom, gdy zamiast IP klienta widzimy user-xxxxxx.play-internet.pl
• -P - Włącza wyświetlanie numerów portów
• -N - Wyłącza rozwiązywanie portów - Zawsze pokazuje numer portu, nie nazwę (22 zamiast SSH)

To narazie tyle tej teorii, przejdźmy do analizy.

Najpierw przeanalizujmy sobie widok, tak abyśmy mogli wyciągnąć z niego jakiekolwiek dane.

Poniżej skali widzimy poszczególne połączenia. Każde połączenie w tym widoku ma 2 linie wysokości. Górna dotyczy wysyłania, a dolna pobierania. (Strzałki są podpowiedzią) Pierwsze dwie kolumny od lewej reprezentują kolejno nasz serwer oraz hosta po drugiej stronie (nie musi być to podłączony klient, nasz serwer może być też klientem dla innego serwera) wraz z ich portami. Po prawej stronie znajdują się prędkości. Są to uśrednione prędkości przesyłu z ostatnich 2, 10 i 40 sekund. Dolny pasek reprezentuje statystyki całości. Górna linia to wysyłanie (TX), środkowa odbieranie (RX), a dolna to suma (TOTAL). Po prawej widzimy sumę wszystkich połączeń

Dobrze, więc co widzimy na powyższym screenie? Widzimy 5 połączeń przychodzących do serwera TeamSpeak3 (Port serwera 9987) oraz 1 połączenie SSH (port 22). Połączenia przychodzące możemy rozpoznać po tym, że port po lewej stronie to jest port usługi, którą mamy uruchomioną na serwerze. Przy określaniu usługi sugerujemy się portem serwera, nie patrzymy na port klienta, ponieważ on jest ustalany losowo przy każdym połączeniu. Ruch jak widać jest nieduży (Jest to łącznie ok. 30Kb/s), i jest to normalne, ponieważ te usługi nie przesyłają dużo danych.

Skąd mamy wiedzieć, że nasz serwer jest pod atakiem DDoS? Tutaj wracamy do profilaktyki. Warto obserować swój serwer. Musimy mieć punkt odniesienia, jak działa w normalnych warunkach. Administracja serwerem to nie tyko "Odpal i zapomnij", a ciągły proces. Wykonajmy sobie parę symulacji.

Do symulacji została użyta maszyna wirtualna z Ubuntu Server 16.04, uruchomionymi serwerami Minecraft (25565/TCP), TeamSpeak3 (9987/UDP) oraz SSH (22/TCP)

Nasz serwer ma IP 192.168.0.14, a klient 192.168.0.47. Jak widzimy do serwera są 3 połączenia: 1 Minecraft, 1 Teamspeak3 oraz 1 SSH. Widzimy również "połączenie" na adresie rozgłoszeniowym (192.168.0.255), możemy je zignorować.

Tutaj mamy przykład ataku DoS UDP Flood z IP 192.168.0.30 na port 9987. Jeśli widzimy dużo połączeń z jednego hosta możemy sobie pomóc, wyłączając widok portów klawiszem p na klawiaturze, lub usuwając przełącznik -P. Wtedy wszystkie połączenia z jednego hosta będą zgrupowane do jednego wpisu. Jeśli widzimy, że jeden adres IP zużywa za dużo transferu (więcej niż to możliwe normalnymi sposobami) sprawa jest oczywista. Tego typu atak jest bardzo skuteczny jeśli o zablokowanie sieci. Jednak jest łatwy zarówno do wykrycia jak i zablokowania. UDP Flood rzadko dzisiaj jest problemem, ponieważ filtry AntyDDoS dosyć skutecznie przed nim chronią.

Skąd mamy wiedzieć ile to za dużo? Z obserwacji! Jako administrator musimy wiedzieć co mamy na serwerze, co ile łącza potrzebuje. Mając serwer CSa musimy wiedzieć, że pobieranie mapki może zająć nawet 50 Mb/s i nie krzyczeć od razu że DDoS. To my musimy wiedzieć, że już trzeba kupić lepszy serwer, a nie zwalać na DDoSy konkurencji każdego wieczora. Trzeba umieć nałożyć limity jeśli głupie ściąganie może zająć cały transfer. Ten poradnik nie pomoże Ci jeśli przyszedłeś uruchamiać publiczny serwer Minecrafta na Raspberry Pi!

Atak DDoS to jest nic innego jak DoS z wielu (czyli z minimum dwóch) hostów. Może być (i najczęściej jest) ich o wiele więcej niż 2.

Jest wiele różnych rodzajów ataków DoS/DDoS, UDP Flood jest tylko jednym z nich. Jeśli na przykład na serwerze Minecraft widzimy, że wbija nagle 50 botów to również się to zalicza jako atak DoS. Atakiem DoS możemy nazwać każdy atak, który ma na celu zablokowanie dostępu do serwera. Prawie zawsze objawem jest zwiększone użycie sieci. Są też wyjątki, czyli ataki, które nie wymagają wiele od atakującego, ale zmuszają serwer do wytężonej pracy. Są to ataki aplikacyjne, o których mowa w następnym punkcie.

Boty na serwerze Minecraft. Źródło NIE ODPOWIADAM ZA WSZELKIE SZKODY

3. Ataki aplikacyjne

"Pracuj mądrze, nie ciężko" powiedział haker uziemiając serwer 1 pakietem. Podczas gdy przy ataku wolumetrycznym używana była siła, to do ataku aplikacyjnego bardziej potrzeba sprytu. Atak aplikacyjny jest dosyć ciężko zlokalizować, głównie dlatego, że wszystko zależy zarówno od konkretnej aplikacji (serwera) jak i przypadku. Nie ma jednej, uniwersalnej metody na diagnozę, jednak postaram się opisać podstawowe kroki, które powinny pomóc w dalszym szukaniu informacji na ten temat.

Po pierwsze musimy wiedzieć, co się dzieje z serwerem. Działa? Crashuje go po dołączeniu pewnego gracza? Od tego zależy jakie kroki będziemy podejmować.

Pierwsza i podstawowa rzecz to zawsze miej najnowsze wersje wszystkich programów, których używasz na serwerze. Stare wersje często mają znane błędy, które wprawny haker może łatwo wykorzystać. Czasami zdarza się, że błędy, które nowa wersja naprawia są publikowane przez twórców aplikacji. A te błędy mogą być przeróżne, niektóre nawet mogą z łatwością położyć większy serwer. Dotyczy się to również serwerów gier dla starszych wersji klientów. Po raz kolejny posłużę się przykładem Minecrafta: Jeśli zakładasz serwer dla wersji 1.8 - sam się prosisz o kłopoty. Spigot 1.8 posiada wiele błędów, ale nikt przecież nie będzie łatał wersji z 2014 roku. Obalenie serwera nie jest jednak najgorszą rzeczą, która może się przytrafić: Znacznie więcej szkód może się pojawić, gdy atakujący przejmie kontrolę nad serwerem. Może na przykład dołączyć Twój serwer do botnetu, aby bez Twojej świadomości serwer DDoSował inne serwery. A wtedy już można mówić o niedopełnieniu obowiązku administratora za co hosting ma prawo odebrać Ci serwer, (i pewnie to zrobi) niezależnie od tego ile za niego zapłaciłeś.

Druga rzecz to sprawdzaj logi. Sprawdzaj co tam pisze i nie ignoruj błędów. Jeśli serwer wyłącza się bez zapowiedzi prawie zawsze tam pisze dlaczego tak zrobił. Nic się nie dzieje bez przyczyny. Jeśli nie rozumiesz tego co tam pisze (np. gdy widzisz nullPointerException), wklej treść błędu w Google. Jeśli nigdzie nie możesz znaleźć nikogo, kto by miał podobny problem, możesz spróbować zgłosić błąd autorowi aplikacji. Kto wie, może odkryłeś coś nowego? Osoby o złych intencjach często wybierają jako cel do testowania nowoodkrytych luk mniejsze serwery, ponieważ są one zwyczajnie najłatwiejszymi celami i mają nadzieję, że nikt nie będzie wiedział co zrobić z luką, której nikt nie widział wcześniej.

Jednak mimo wszystko przejęcie serwera wymaga najczęściej znacznych umiejętności, a większość "hakerów" ich nie posiada, więc jest zainteresowana zwyczajnie pozbyciem się go. Jeśli zauważamy, że nasz serwer nagle zaczyna zużywać 100% CPU, długo odpowiadać lub użycie RAMu zaczyna gwałtownie rosnąć warto też sprawdzić co się dzieje. Niestety przyczyna tego może leżeć naprawdę wszędzie. Praktycznie zawsze jest to błąd aplikacji, jednak trzeba zlokalizować co go powoduje. Najpierw spróbuj zrestartować serwer. Jeśli problem się powtarza spróbuj go zamknąć (tak, żeby był włączony, ale nikt nie miał do niego dostępu). To, jak to zrobisz to zależy od samej aplikacji. Jeśli w logach nie ma żadnej wzmianki o błędach spróbuj zresetować serwer (usunąć wszystkie dane). Jeżeli problem nadal występuje zbierz wszystkie dane, które wydają Ci się, że mogą być przydatne (głównie logi) i zapytaj na forum. Wszystko tutaj zależy od konkretnego przypadku.

4. Boty

Mając wystawiony na świat adres IP na pewno chociaż raz jakiś bot próbował się dobić do naszych bram. Żaden szanujący się cracker sam nie skanuje serwerów, używają oni do tego zautomatyzowanych botów, które robią to za nich na kilkuset serwerach na raz. Boty, które grasują w internecie mają przygotowane zestawy procedur i słowniki haseł (z wycieków), które testują na każdym napotkanym serwerze. Zauważyć je jest stosunkowo łatwo jeśli tylko interesuje nas co się z serwerem dzieje. Zauważyć je można chociażby w logach usług jako powtarzające się nieudane próby logowania z nieznanego adresu IP.

Więc jak to przełożyć na praktykę? Dla przykładu sprawdźmy sobie logi SSH. Jeśli nie robiłeś tego wcześniej, informacje, które możesz tam znaleźć mogą Cię zaskoczyć.

Wpisz w terminalu sudo journalctl -b -u sshd

Jak widzimy ktoś tutaj nazywa się Chris oraz bardzo chce skorzystać z Teamspeak2 :D (Dzień dobry) [details="Oczywiście zrobiłem z nim co trzeba"] Jeśli ktoś podobnie próbuje się dobić do SSH lub czegokolwiek co masz uruchomione na serwerze, możesz (a nawet powinieneś) go zgłosić w odpowiednim miejscu. W tym krótkim offtopie zaprezentuję jak mozna to zrobić.

1. Zlokalizuj, gdzie hostowany jest bot. To nie powinno być trudne zadanie. Wpisz na stronie http://whois.domaintools.com/ te IP. Jak pojawi się pole z Captchą zaznacz je i wciśnij Go. W tym momencie pojawią się informacje na temat zadanego adresu IP. Szukamy tutaj informacji o abuse. 2. Zgłaszamy Jako że serwer jest w OVH mamy w zasadzie 2 opcje:

• e-mail na podany adres
• ovh.pl/abuse

Ja wybrałem 2 opcję. Wchodzimy na podaną wyżej stronę i wypełniamy formularzyk.

Gotowe ;)

[/details] Więc na co zwracać uwagę w przypadku SSH? W szczególności patrz, komu się udaje zalogować na serwer. Możesz na przykład wspomóc się skryptem poniżej. Jeśli zauważysz, że to nie byłeś Ty, przegrałeś. To znaczy, że ktoś dorwał się do serwera.

[details="O skryptach do filtrowania logów"]

 /Accepted/ { printf("Logowanie od %s na %s dnia %s %s o godzinie %s\n", $11, $9, $2, $1, $3);}

Wrzuć to do pliku ssh.awk Skrypt ten wyświetla udane połączenia do serwera SSH z logów. Aby skorzystać z niego wpisz sudo journalctl -u sshd | awk -f ssh.awk. Jeśli chcesz sprawdzić logi z ostatnich 24 godzin użyj sudo journalctl -u sshd --since "24 hours ago" | awk -f ssh.awk

Awk jest bardzo przydatnym i prostym językiem skryptowania jeśli chodzi o filtrowanie logów. Polecam się go nauczyć. Poniżej daję linki do tutoriala:

• Część pierwsza
• Część druga
• Część trzecia [/details]

Oczywiście powyższe zasady nie dotyczą tylko serwera SSH. Zadaniem administratora jest pilnowanie, żeby całość była bezpieczna. Jeśli masz serwer Minecrafta, a ktoś się dostał na RCONa, to jest dokładnie ten sam problem.