Jak rozpoznać atak DDoS: diagnoza bez wątpliwości

Usługa przestała odpowiadać, wskaźnik obciążenia stoi na maksimum, a na czacie pada pytanie: czy ktoś nas atakuje? Na to pytanie da się odpowiedzieć pomiarem. Da się nawet odpowiedzieć dość szybko, jeśli wiesz, na które cztery liczby patrzeć i w jakiej kolejności oraz która próba kontrolna zamienia podejrzenie w pewne rozpoznanie.

Ten artykuł dotyczy wyłącznie diagnozy. Nie chodzi o odparcie ataku, tylko o to, żeby bez cienia wątpliwości odróżnić go od problemu z obciążeniem, od błędu w oprogramowaniu albo po prostu od sukcesu. Jeśli chcesz wiedzieć, czym atak DDoS jest technicznie, zajrzyj do wpisu Czym jest atak DDoS. Jeśli po rozpoznaniu chcesz działać, czytaj dalej w Jak chronić serwer przed atakami DDoS.

Czterech podejrzanych, jeden objaw

„Serwer jest wolny” to nie rozpoznanie, tylko objaw z co najmniej czterema wiarygodnymi przyczynami. Zanim wpiszesz choćby jedno polecenie, warto wiedzieć, jakie wzorce właściwie chcesz od siebie odróżnić.

Czwartego podejrzanego w tej tabeli nie ma, bo nie potrzebuje własnej kolumny: to zaplanowane prace. Kopie zapasowe, przebudowa indeksów, rotacja logów i aktualizacje pakietów działają o przewidywalnych porach. Rzut oka na systemctl list-timers i na crontaby kosztuje dziesięć sekund, a zamyka zaskakująco wiele podejrzeń o atak.

Pierwsze 60 sekund: cztery liczby

Zbierz cztery wartości w tej kolejności. Wymowna jest ich kombinacja, żadna z nich osobno nie jest.

cat /proc/loadavg
ss -s
cat /proc/net/dev
curl -o /dev/null -s -w '%{time_total}\n' http://127.0.0.1/

Jak to czytać:

• Wysokie obciążenie, wysoki ruch sieciowy, dużo półotwartych połączeń, ale 127.0.0.1 odpowiada w milisekundach: problem siedzi przed aplikacją, czyli na warstwie sieciowej. To klasyczny obraz ataku.
• Wysokie obciążenie, normalny ruch sieciowy, 127.0.0.1 odpowiada wolno: aplikacja albo baza danych. To nie atak, tylko robota dla programisty.
• Niskie obciążenie, wysoki ruch sieciowy: mocno podejrzane. Burza pakietów, która w ogóle nie przebija się do aplikacji, zużywa mało CPU i dużo łącza.
• Wszystko niskie, a usługa i tak nieosiągalna z zewnątrz: patrz niżej, rozdział o przypadkach bez mierzalnego śladu.

O samej wartości obciążenia trzeba wiedzieć jedno: /proc/loadavg liczy także procesy czekające na operacje wejścia i wyjścia. Wartość 40 przy czterech rdzeniach może oznaczać zarówno atak, jak i przeciążony dysk. vmstat 1 5 rozdziela to czysto: kolumna r pokazuje procesy gotowe do liczenia, b zablokowane, a wa udział czasu oczekiwania.

Liczenie połączeń: ss zamiast netstat

Prawie każdy poradnik w sieci zaczyna się od netstat. Na aktualnym systemie kończy się to tak:

Command 'netstat' not found, but can be installed with:
apt install net-tools

netstat należy do pakietu net-tools, którego w standardowych instalacjach Debiana 12, Debiana 13, Ubuntu 22.04 i Ubuntu 24.04 już nie ma. W rodzinie Red Hata (AlmaLinux, Rocky, RHEL, Oracle Linux) również nie. Doinstalować go oczywiście możesz, ale sensowniejsze jest ss z pakietu iproute2: znajdziesz je praktycznie na każdym serwerze, przy dużej liczbie połączeń działa znacznie szybciej i daje dokładnie te same informacje.

ss -s

Żeby wszystkie poniższe polecenia w ogóle ruszyły, potrzebujesz garstki pakietów, a te nazywają się różnie w zależności od rodziny dystrybucji. To najczęstsze miejsce, w którym skopiowany poradnik zacina się na systemie AlmaLinux już w pierwszej linii:

Na Debianie i Ubuntu będzie to więc apt-get install -y iproute2 net-tools procps sysstat dnsutils tcpdump, a w rodzinie Red Hata dnf -y install iproute net-tools procps-ng sysstat bind-utils tcpdump. curl lepiej tam na tę listę nie dopisywać: jest już zainstalowany jako curl-minimal, a pełny pakiet z nim koliduje (curl-minimal ... conflicts with curl). Jeśli mimo wszystko go potrzebujesz, pomoże dnf -y --allowerasing install curl.

Pierwsza linia podaje łączną liczbę socketów, linia TCP rozbija to na części: estab, closed, orphaned, timewait. Sama wysoka wartość timewait nie jest jeszcze poszlaką ataku, tylko normalnym następstwem wielu krótkich połączeń HTTP.

Ciekawszy jest rozkład na stany:

ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn

W oczy rzuca się duży blok w stanie SYN-RECV. Te połączenia zostały rozpoczęte, ale nigdy nie potwierdzone, a to dokładnie wzorzec SYN flooda. Policzyć da się to wprost:

ss -Htn state syn-recv | wc -l

Pułapka z kolumnami, na której wykłada się większość jednolinijkowców

Gdy tylko podasz ss filtr stanu, kolumna ze stanem znika z wyniku. Druga strona połączenia trafia wtedy do kolumny 4 zamiast do kolumny 5. Właśnie dlatego skopiowane z forów jednolinijkowce regularnie zwracają bzdury: liczą porty zamiast adresów IP albo wypisują puste linie. Zapamiętaj: bez filtra druga strona to $5, z filtrem $4. Przełącznik -H dodatkowo usuwa nagłówek, dzięki czemu wc -l zgadza się bez poprawek.

Połączenia w rozbiciu na adres źródłowy, odporne na IPv6:

ss -Htn state established | awk '{print $4}' | sed 's/:[^:]*$//' | sort | uniq -c | sort -rn | head -20

sed obcina tylko ostatni dwukropek razem z portem. Popularne podejście z cut -d: -f1 działa przy IPv4, ale adresy IPv6 rozcina po pierwszym bloku i czyni całą analizę bezwartościową. Przy IPv6 zostają nawiasy kwadratowe, w liczeniu to nie przeszkadza.

Interpretacja wymaga wyczucia. Sto połączeń z jednego adresu IP może być atakiem, ale równie dobrze firmowym NAT-em, carrier NAT-em operatora komórkowego albo reverse proxy stojącym przed twoim serwerem. Jeśli z przodu pracuje sieć CDN albo load balancer, i tak widzisz wyłącznie jego adresy i musisz przenieść analizę do logu serwera WWW, do nagłówka X-Forwarded-For.

Dla UDP obowiązuje ten sam schemat z -u. A żeby w ogóle wiedzieć, która usługa nasłuchuje na którym porcie:

ss -tulnp

Jak poprawnie mierzyć ruch sieciowy i liczbę pakietów

Przepustowość w megabitach to liczba, którą podaje każdy. Bardziej wymowna jest liczba pakietów na sekundę. Atak złożony z 200 000 malutkich pakietów na sekundę kładzie serwer, choć przepustowość wygląda całkiem niegroźnie.

Najpierw nazwa interfejsu, bo eth0 dawno nie jest wszędzie prawidłową odpowiedzią. Typowe nazwy to ens3, enp1s0 albo eth0:

ip -br link

Potem dwa pomiary w odstępie jednej sekundy, całkiem bez dodatkowych pakietów. Nazwa interfejsu jest przy tym pobierana z trasy domyślnej, zamiast wpisywać ją na sztywno:

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) pakietów/s przychodzących na $IF"

Ta zawiłość ma solidny powód. Wpisz tu na sztywno eth0, a interfejs w rzeczywistości nazywa się ens3 albo enp1s0, jak to bywa na większości serwerów KVM, a polecenie wprawdzie dwa razy wypisze cat: /sys/class/net/eth0/statistics/rx_packets: No such file or directory, ale potem najspokojniej w świecie zamelduje 0 pakietów/s przychodzących i zakończy się kodem powrotu 0. W artykule o wykrywaniu ataków to najgroźniejszy z możliwych wariantów: czytasz zero pakietów, ogłaszasz spokój, a atak leci dalej. || exit 1 dokładnie temu zapobiega.

To samo z rx_bytes daje bajty na sekundę. Z obu wartości obliczysz średni rozmiar pakietu, a ten zdradza rodzaj ataku:

• średnio poniżej 100 bajtów przy bardzo dużej liczbie pakietów: SYN flood, ACK flood albo UDP flood. Celem jest przetwarzanie pakietów, a nie łącze.
• 1200 do 1500 bajtów przy dużej przepustowości, porty źródłowe 53, 123, 389 albo 11211: atak z odbiciem i wzmocnieniem. Adresy źródłowe należą do obcych serwerów, a nie do atakujących.
• normalny rozkład rozmiarów, poprawne zapytania HTTP: warstwa aplikacji. Wtedy rozstrzyga log serwera WWW, a nie licznik pakietów.

Wygodniej jest z sar z pakietu sysstat:

sar -n DEV 1 3

Miejsce, na którym łatwo się potknąć: pomiar na żywo działa od razu po instalacji, natomiast analiza historyczna przez sar -f już nie. Na Debianie i Ubuntu zbieranie danych jest fabrycznie wyłączone, w /etc/default/sysstat stoi ENABLED="false". Kto zauważy to dopiero w trakcie ataku, nie ma wartości porównawczych sprzed dwóch dni. To właśnie powód, żeby włączyć ten pakiet zawczasu, a nie dopiero, kiedy się pali.

I najważniejsze ograniczenie ze wszystkich: na serwerze mierzysz tylko to, co przez niego przeszło. Jeśli przed nim stoi filtrowanie, widzisz ułamek rzeczywistego wolumenu albo zupełnie nic. Wiarygodna liczba jest na wykresie ruchu w panelu klienta, a nie w /proc/net/dev.

Czytanie komunikatów jądra

Jądro zapisuje sytuacje przeciążeniowe, które na warstwie aplikacji pozostają niewidoczne. Na Ubuntu i aktualnych wersjach Debiana bufor pierścieniowy jest zablokowany dla zwykłych użytkowników, bez sudo pojawia się:

dmesg: read kernel buffer failed: Operation not permitted

To nie usterka, tylko kernel.dmesg_restrict=1. Z uprawnieniami roota i ze znacznikami czasu:

dmesg -T | grep -Ei 'syn flood|conntrack|neighbour|drop'

Komunikat, którego szuka większość, brzmi dosłownie tak:

TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.

Są dwa warianty i jedna różnica w formacie, którą warto znać:

• Sending cookies oznacza, że SYN cookies są aktywne i połączenia nadal są obsługiwane. Dropping request pojawia się zamiast tego wtedy, gdy net.ipv4.tcp_syncookies stoi na 0. Wtedy zapytania są odrzucane, razem z prawdziwymi odwiedzającymi.
• Starsze jądra podają tylko numer portu, nowsze dodatkowo adres nasłuchu w postaci 0.0.0.0:443. Na Debianie 12 zobaczysz więc formę krótką, na Debianie 13 i Ubuntu 24.04 długą. Kto grepuje po dokładnym starym brzmieniu, na nowych systemach nie znajdzie nic.

Ważne dla uczciwości diagnozy: ten komunikat nie dowodzi ataku. Pojawia się także wtedy, gdy aplikacja pracuje ze zbyt małym listen backlogiem i przewraca ją legalny skok obciążenia. To poszlaka, którą muszą podeprzeć inne pomiary.

Odpowiednie liczniki dostarcza nstat:

nstat -az TcpExtSyncookiesSent
nstat -az TcpExtListenDrops
nstat -az TcpExtListenOverflows

Tu również czyha potknięcie: nstat przy wywołaniu zapamiętuje stan pośredni i następnym razem pokazuje już tylko różnicę. Tak ma być i do pomiaru jest to nawet praktyczne, ale zaskakuje każdego, kto przy drugim wywołaniu widzi nagle same zera. Przełącznikiem -a wymuszasz wartości bezwzględne, a -s wyłączasz zapisywanie stanu.

Dwa kolejne komunikaty, które regularnie pojawiają się podczas ataku i oba prowadzą do gubienia pakietów prawdziwych odwiedzających:

nf_conntrack: table full, dropping packet
neighbour: arp_cache: neighbor table overflow!

Stopień zapełnienia śledzenia połączeń sprawdzisz przez cat /proc/sys/net/netfilter/nf_conntrack_count w zestawieniu z nf_conntrack_max. Oba pliki istnieją tylko wtedy, gdy moduł jest załadowany, czyli gdy działa firewall. Na systemie bez reguł ich nie ma i to jest normalne.

Logi serwera WWW: wzorce zamiast przeczucia

Na Debianie i Ubuntu logi leżą w /var/log/nginx/access.log względnie /var/log/apache2/access.log. W rodzinie Red Hata ścieżka Apache'a to /var/log/httpd/access_log, bez kropki przed końcówką. Na początek wystarczą trzy zestawienia:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

Rozróżnienie między atakiem a prawdziwym napływem wynika ze stosunku tych trzech list:

• Stosunek zapytań do unikalnych adresów IP. Dziesięć tysięcy zapytań z 6000 adresów to publiczność. Dziesięć tysięcy zapytań z 30 adresów już nie.
• Zapytania następcze. Prawdziwy odwiedzający po stronie HTML dociąga arkusze stylów, skrypty i obrazki. Jeśli na liście ścieżek stoi wyłącznie jeden adres URL i ani jeden plik statyczny, to nie pracowała tam żadna przeglądarka.
• Pochodzenie. Przy sukcesie reklamowym w polu referrera stoi źródło: serwis informacyjny, medium społecznościowe, wyszukiwarka. Przy ataku pole jest zwykle puste albo wypełnione zmyślonym adresem.
• Identyfikator programu. Jeden jedyny, dokładnie identyczny User-Agent w dziesiątkach tysięcy zapytań to narzędzie. Podejrzane są też identyfikatory bardzo starych wersji przeglądarek.
• Kody statusu. Przewaga 200 przemawia za publicznością, a mur z 404 albo 499 za automatycznym obmacywaniem względnie za klientami, którzy zrywają połączenie przed odpowiedzią.

Ostrożnie z wyszukiwarkami: adres IP chętnie twierdzi w polu User-Agent, że jest Googlebotem. Sprawdzić da się to tylko testem odwrotnego, a następnie zwykłego rozwiązywania nazw. Dopiero gdy nazwa odwrotna wskazuje na domenę dostawcy i ta nazwa rozwiązuje się z powrotem na ten sam adres IP, twierdzenie się zgadza.

dig -x 66.249.66.1 +short

Dla prawdziwego adresu Googlebota wraca wtedy nazwa w rodzaju crawl-66-249-66-1.googlebot.com., którą następnie przez dig +short crawl-66-249-66-1.googlebot.com każesz rozwiązać z powrotem na ten sam adres IP. Jeśli nie wraca zupełnie nic, może to wynikać także z serwera bez wychodzącego rozwiązywania DNS i wtedy nie jest żadnym dowodem.

I najważniejsze zdanie o logach w ogóle: ataku na warstwie sieciowej nie ma w logu serwera WWW. SYN flood nigdy nie dociera do aplikacji i nie zostawia tam ani jednej linii. Pusty log niczego więc nie obala, zawęża tylko warstwę.

Próba kontrolna: tak z podejrzenia robi się rozpoznanie

Do tego miejsca masz poszlaki. Nośne stają się dopiero dzięki próbom kontrolnym, z których każda potrafi obalić dokładnie jedną hipotezę.

1. Zatrzymaj usługę. Zatrzymaj serwer WWW na 30 sekund. Jeśli przychodząca liczba pakietów pozostaje niezmiennie wysoka, atak leży poniżej aplikacji. Jeśli się załamie, były to zapytania do twojej aplikacji, złośliwe albo nie.
2. Wewnątrz kontra na zewnątrz. Jeśli curl przez 127.0.0.1 odpowiada w milisekundach, podczas gdy pobranie z zewnątrz kończy się przekroczeniem czasu, aplikacja jest zdrowa, a problemem jest łącze.
3. Drugi pomiar. Powtórz pomiar pakietów dwie minuty później. Ataki trwają albo wracają falami. Jednorazowy szczyt był po prostu szczytem.
4. Spojrzenie z zewnątrz. Zewnętrzny test dostępności z kilku lokalizacji oddziela „nieosiągalny dla wszystkich” od „nieosiągalny tylko dla ciebie”. Ten drugi przypadek to zwykle problem z routingiem albo z operatorem po stronie obserwatora, a nie atak.
5. Sprawdź kierunek. Porównaj rx_packets z tx_packets. Jeśli podejrzana jest liczba wychodząca, to nie ciebie ktoś atakuje, tylko twój serwer atakuje sam. Jest wtedy przejęty albo nadużywany jako reflektor, a sprawa natychmiast zmienia stopień pilności.

Po czym poznasz, że diagnoza jest nośna: potrafisz w jednym zdaniu powiedzieć, jaki protokół trafia na jaki port i z jaką intensywnością, przychodząco czy wychodząco, i masz dwa niezależne pomiary, które pokazują to samo. Wszystko poniżej tego to domysł.

Kiedy nie ma mierzalnego śladu

Cztery sytuacje, które regularnie wywołują zamieszanie:

• W ogóle nie dostajesz się już na serwer. Przy zapchanym łączu nie przebija się nawet SSH. Dostęp idzie wtedy przez konsolę w panelu klienta, która działa niezależnie od podłączenia systemu do sieci. Dokładnie po to jest.
• Usługa zniknęła, a na serwerze nic nie widać. Przy filtrowaniu po stronie sieci to reguła, a nie wyjątek. Jeśli atak zostanie przechwycony w sieci, system widzi tylko krótkie wgniecenie. Dowód stoi wtedy na wykresie ruchu w panelu klienta.
• Log urywa się w środku zdarzenia. Sprawdź, czy w międzyczasie nie zadziałała rotacja logów, starszy materiał leży obok jako access.log.1 albo access.log.2.gz. Jeśli access_log jest w konfiguracji wyłączony albo buforowany, ostatnich linii po prostu brakuje.
• Jądro milczy. W systemach opartych na kontenerach bufor pierścieniowy należy do systemu gospodarza, dmesg nie pokazuje tam nic własnego. Na serwerze root KVM z własnym jądrem to nie jest temat.

Co udokumentować, zanim skontaktujesz się z dostawcą

Zgłoszenie w stylu „serwer był dziś po południu wolny” wydłuża obsługę o kilka rund. Zgłoszenie z wynikami pomiarów trafia do obsługi od razu. Zbieraj dane, dopóki zdarzenie trwa, bo liczniki w /proc zerują się przy restarcie.

mkdir -p /root/incydent && cd /root/incydent
date -u > 01-czas.txt
ss -s > 02-sockets.txt
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn > 03-stany.txt
ss -Htn state established | awk '{print $4}' | sed 's/:[^:]*$//' | sort | uniq -c | sort -rn | head -50 > 04-top-ips.txt
ip -s link > 05-interfaces.txt
sar -n DEV 1 10 > 06-pakiety.txt
dmesg -T | tail -100 > 07-kernel.txt
nstat -az > 08-liczniki.txt

Jeśli łącze na to pozwala, do kompletu należy krótki zrzut pakietów. Ogranicz go, bo nieograniczony zrzut na zapchanym łączu zapełnia dysk w kilka minut i zaostrza problem:

tcpdump -D
tcpdump -ni "$IF" -s 96 -c 2000 -w /root/incydent/zrzut.pcap

tcpdump -D wypisuje dostępne interfejsy, gdyby zmienna $IF z rozdziału o pomiarach wyżej nie była już ustawiona. Oba wywołania wymagają uprawnień roota.

Do zgłoszenia trafiają następnie:

1. Moment rozpoczęcia i zakończenia, ze strefą czasową. date -u ucina każdą dyskusję na ten temat.
2. Adres IP, którego sprawa dotyczy, oraz port.
3. Zmierzona liczba pakietów i przepustowość, wyraźnie z podaniem kierunku.
4. Rozkład protokołów oraz, jeśli da się rozpoznać, porty źródłowe drugiej strony.
5. Garść przykładowych adresów źródłowych, z zastrzeżeniem, że nadawcy mogą być podrobieni.
6. Fragment logu serwera WWW z powtarzającym się wzorcem zapytań, wystarczą trzy do pięciu linii.
7. Co zmieniło się krótko wcześniej: deploy, przełączenie DNS, kampania reklamowa, nowo otwarty port.
8. Wynik próby kontrolnej: czy usługa była osiągalna przez 127.0.0.1, kiedy z zewnątrz przestała działać?

Częste błędne wnioski

• Dużo połączeń TIME-WAIT jako dowód ataku. To normalne następstwo krótkich połączeń HTTP i znika samo.
• Komunikat o SYN floodingu jako dowód. Zbyt mały listen backlog wywołuje go także przy legalnym skoku obciążenia.
• Blokowanie adresu IP z dużą liczbą połączeń bez sprawdzenia. Za firmowym NAT-em, za NAT-em operatora komórkowego albo za proxy stojącym z przodu wykluczasz w ten sposób całe grupy klientów.
• Wnioskowanie o ataku z wysokiej przepustowości. Najpierw sprawdź kierunek. Szczyty wychodzące to najczęściej kopia zapasowa albo popularny plik do pobrania.
• Wnioskowanie z pustych logów, że „ataku nie było”. Ataki na warstwie sieciowej nigdy nie docierają do aplikacji.
• Restart w trakcie trwającego zdarzenia. Restart kasuje wszystkie liczniki, których potrzebowałbyś do zgłoszenia, a atak leci potem dalej bez zmian.

Kto raz przećwiczy tę kolejność, dojdzie do nośnego rozpoznania w niecałe pięć minut. A kto dołączy wyniki pomiarów do zgłoszenia, pominie rundę pytań i przejdzie od razu do rozwiązania. W temacie: lista kontrolna dla nowych serwerów root oraz konfiguracja Fail2ban do obróbki po zdarzeniu na warstwie aplikacji.