Silny atak DDoS: co robić teraz

Atak, który kończy się po dziesięciu minutach, jest irytujący. Atak, który od kilku dni wraca każdego wieczoru o tej samej porze, to zupełnie inna sprawa: twój serwer nie jest już przypadkowym celem. Ten wpis pokazuje, co robić teraz, co możesz zabezpieczyć samodzielnie i bez dodatkowych kosztów oraz gdzie te działania się kończą.

Wszystkie polecenia dotyczą Debiana 12, Debiana 13, Ubuntu 22.04 LTS oraz Ubuntu 24.04 LTS i są napisane dla użytkownika root; jako zwykły użytkownik poprzedź je poleceniem sudo. Czym atak DDoS jest technicznie, wyjaśnia wpis Czym jest atak DDoS?.

Dopóki atak trwa: żadnego restartu i żadnej przebudowy połowy konfiguracji. Restart kasuje dokładnie te liczniki, które są potrzebne do zgłoszenia u dostawcy, a atak i tak wraca potem w niezmienionej postaci.

Dlaczego akurat twój serwer jest atakowany tak uporczywie

Serwery ostrzeliwane przez całe tygodnie mają prawie zawsze te same trzy cechy. Po pierwsze same publikują swój adres: na liście serwerów, na Discordzie, przez wpis DNS. Po drugie korzysta się z nich w stałych godzinach, więc awaria o 20:00 jest widoczna maksymalnie. Po trzecie jest ktoś, dla kogo taka awaria coś znaczy: konkurencyjny projekt, zbanowany gracz, rozgoryczony klient.

Dochodzi do tego sprawa techniczna: wiele dotkniętych usług działa po UDP. UDP nie zna nawiązywania połączenia, którego można by wymagać, a adresy nadawcy da się podrobić. Atakujący nie musi więc ani wejść do twojej usługi, ani poprawnie się do niej odezwać, żeby wygenerować obciążenie. W usługach TCP zasoby zajmują z kolei połączenia otwarte do połowy, które nigdy nie zostają domknięte.

Porty, o które naprawdę chodzi

Atak nie trafia w „serwer”, tylko w port. Poniższe zestawienie wymienia domyślne porty najczęściej ostrzeliwanych usług i jest zarazem twoją listą kontrolną: wszystko, czego tu nie ma, a mimo to stoi otworem, należy zamknąć.

Druga grupa pojawia się nie jako cel, tylko jako źródło: 53 (DNS), 123 (NTP), 389 (CLDAP), 1900 (SSDP), 11211 (memcached) oraz również 27015. Jeśli przeważają takie porty źródłowe, mamy do czynienia z atakiem typu reflection i amplification. Nadawcami są wtedy postronne, źle skonfigurowane serwery, dlatego blokowanie pojedynczych adresów trafia w próżnię.

Co możesz zrobić sam, zanim wydasz pieniądze

Ten rozdział jest najdłuższy i to celowo: porządnie skonfigurowany serwer wytrzyma małe i średnie ataki o własnych siłach, a w razie potrzeby dostarczy wyniki pomiarów dla kolejnego szczebla.

1. Pierwsze minuty: mierz, zamiast kręcić przy ustawieniach

Zanim cokolwiek zmienisz, zapisz, co się właśnie dzieje. Wystarczą cztery wartości: przychodząca liczba pakietów, rozkład stanów połączeń, komunikaty kernela oraz odpowiedź na pytanie, czy usługa odpowiada jeszcze lokalnie.

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"
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn
dmesg -T | tail -50
curl -o /dev/null -s -w '%{time_total}\n' http://127.0.0.1/

Nazwa interfejsu pochodzi z trasy domyślnej, bo eth0 na wielu serwerach KVM w ogóle nie istnieje (nazywa się tam ens3 albo enp1s0), a błędnie wpisana nazwa najspokojniej w świecie zgłosi zero pakietów. Duży blok w stanie SYN-RECV to wzorzec SYN flooda. Jeśli usługa odpowiada szybko przez 127.0.0.1, a z zewnątrz jest nieosiągalna, problem siedzi w sieci. I jeszcze jedno: na serwerze mierzysz tylko to, co przeszło, bo za filtrowaniem widać już wyłącznie ułamek wolumenu. Metodykę opisuje wpis Jak rozpoznać atak DDoS.

Jeśli nie przebijasz się już przez SSH, to nie powód do restartu, tylko skutek zapchanego łącza. Dostęp prowadzi wtedy przez konsolę VNC w panelu klienta, która działa niezależnie od łącza sieciowego.

2. Inwentaryzacja: co nasłuchuje na zewnątrz?

ss -lntup
nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

Pierwsze polecenie pokazuje widok własny, drugie, wywołane z innej maszyny, widok atakującego. Decyduje adres lokalny: 0.0.0.0:3306 znaczy „osiągalne z całego internetu”, a 127.0.0.1:3306 znaczy „tylko lokalnie” i nie potrzebuje reguły firewalla. Regularnie wychodzą przy tym na jaw zapomniane usługi: instancja testowa, panel zarządzania, baza danych bez lokalnego bindowania.

3. Zostaw otwarte tylko to, czego usługa naprawdę potrzebuje

Kolejność jest ważna, inaczej zamkniesz dostęp sam sobie: najpierw reguły zezwalające, potem polityka domyślna, na końcu włączenie.

ufw allow 22/tcp comment 'SSH'
ufw allow 80,443/tcp comment 'Web'
ufw allow 25565/tcp comment 'Port gry'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sprawdź potem drugą, świeżo nawiązaną sesją, czy nadal się dostaniesz: istniejące połączenia przeżyją włączenie firewalla nawet wtedy, gdy pasującej reguły brakuje. Instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

Baza danych nie ma czego szukać w otwartej sieci; w pliku /etc/mysql/mariadb.conf.d/50-server.cnf musi stać bind-address = 127.0.0.1. Interfejsy zarządzania tak samo: jeśli nie masz stałego adresu IP do celowego przepuszczenia, zostaw port zamknięty i dostawaj się do niego przez tunel SSH.

ssh -N -L 8443:127.0.0.1:8443 root@TWOJ.ADRES.IP.SERWERA

Opublikowane porty kontenerów omijają łańcuchy UFW. Binduj je lokalnie, czyli -p 127.0.0.1:8080:80 zamiast -p 8080:80, a dostęp poprowadź przez reverse proxy.

4. Zabezpiecz port zapytań, nie zamykając go

Wiele usług ma obok właściwego portu drugi, który wydaje informacje o statusie: w grach opartych na Steamie jest to 27015 UDP, w Minecrafcie port query, w TeamSpeaku interfejs ServerQuery na 10011 TCP. Odpowiadają bez logowania, a odpowiedź jest większa od zapytania, więc nadaje się do wzmocnienia ataku na osoby trzecie. Zamknięcie zwykle nie wchodzi w grę, bo twój serwer zniknie wtedy z listy serwerów. Zamiast tego ogranicz ruch osobno dla każdego adresu źródłowego:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Dziesięć zapytań na sekundę na jeden adres wystarczy prawdziwym graczom i twojemu monitoringowi, a odrzuci źródło wysyłające tysiące zapytań na sekundę. W Minecrafcie enable-query=false w pliku server.properties wyłącza port query całkowicie i serwer nie znika przy tym z listy. enable-status=false tłumi dodatkowo odpowiedź na ping z listy serwerów, ale wtedy twój serwer pokazuje się jako offline. Interfejs ServerQuery w TeamSpeaku zbinduj na 127.0.0.1.

5. Ogranicz liczbę połączeń i pakietów

iptables -I INPUT -p tcp --dport 443 --syn -m connlimit --connlimit-above 40 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name game_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

Pierwsza reguła odrzuca nowe połączenia TCP, gdy tylko jeden adres ma otwartych więcej niż czterdzieści równocześnie, druga odrzuca pakiety UDP, gdy z tego samego źródła trwale przychodzi ich więcej niż 600 na sekundę. Obie wartości to punkt wyjścia, a nie prawda objawiona: kto ustawi je za ciasno, wyrzuci własnych użytkowników. Sprawdź przez iptables -L INPUT -n -v, czy liczniki trafień rosną. Jeśli stoją na zerze, reguła w ogóle nie jest osiągana.

Same reguły iptables znikają po restarcie; utrwalisz je przez apt-get install -y iptables-persistent oraz netfilter-persistent save. Przy UFW należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload. I granica zasadnicza: limity na adres źródłowy działają tylko dopóty, dopóki w ogóle istnieją rzucające się w oczy źródła. Jeśli każdy z 200 000 zaangażowanych adresów wyśle dokładnie jeden pakiet, żaden z nich nie zwróci uwagi.

6. Przygotuj kernel na wiele małych pakietów

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

SYN cookies odpowiadają na próbę nawiązania połączenia bez zajmowania pamięci i są aktywne fabrycznie. Obie kolejki przepełniają się jako pierwsze przy dużej liczbie równoczesnych prób połączenia. Na stałe takie wartości należą do pliku w katalogu /etc/sysctl.d/ i wczytuje je sysctl --system. Ostatni wiersz pokazuje śledzenie połączeń, które istnieje tylko przy aktywnym firewallu: gdy jego tablica się zapełni, serwer odrzuca także pakiety legalne i melduje nf_conntrack: table full, dropping packet.

7. Warstwa aplikacji: rate limity, whitelista, pluginy i anti-cheat

Ataki, które przeciążają nie łącze, tylko aplikację, wyglądają inaczej: mało pakietów, ale kosztownych. Flood HTTP na wyszukiwarkę w sklepie nie potrzebuje gigabita. Przy serwerze WWW najskuteczniejszym środkiem jest dlatego ograniczenie na jeden adres, w nginx w bloku http, a potem w bloku server albo location:

limit_req_zone $binary_remote_addr zone=web:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=webconn:10m;

limit_req zone=web burst=20 nodelay;
limit_conn webconn 20;

Przeciw powtarzającym się próbom logowania sensownie uzupełnia to Fail2ban; konfigurację opisuje wpis Konfiguracja Fail2ban. Na serwerach gier przeciw wszystkiemu, co korzysta ze zwykłej drogi dołączenia, działają trzy rzeczy: whitelista (w Minecrafcie whitelist=true razem z enforce-whitelist=true), realistyczny górny limit równoczesnych graczy oraz zdarzenia sieciowe sprawdzane po stronie serwera.

Trzeba równie jasno powiedzieć, czego pluginy i systemy anti-cheat nie potrafią: oba działają w tym samym procesie co gra i sprawdzają dopiero wtedy, gdy pakiet jest już przetwarzany. Gdy proces stanie, razem z nim stanie logika ochronna. Dla whitelisty obowiązuje to samo, bo kto zalewa twój serwer, wcale nie chce do niego dołączyć.

8. Lista serwerów, DNS i własny adres IP

Tu opłaca się szczerość zamiast pobożnych życzeń: twojego adresu IP nie da się utrzymać w tajemnicy. Zna go każdy, kto choć raz się połączył, a wpis na liście publikuje go i tak. Dwa nawyki mimo wszystko pomagają: nigdzie nie publikuj surowego adresu samodzielnie, także nie na kanale Discord ani przez bota statusowego, oraz podłączaj użytkowników przez nazwę hosta, żeby zmiana adresu nie połamała wszystkich odwołań.

Przy samej zmianie klasykiem są stare wpisy DNS: zapomniany wpis A, subdomena ze strony statusu, wpis MX wskazujący na ten sam serwer. A i tak zmiana adresu pozostaje zyskiem na czasie, a nie rozwiązaniem.

9. Zbieraj dokumentację, dopóki incydent trwa

Bez wartości odniesienia nie powiesz potem, czy 40 000 pakietów na sekundę to dużo, czy po prostu wtorkowy wieczór. Po apt-get install -y vnstat sysstat pomiar leci nieprzerwanie w tle. W trakcie incydentu zbierz:

mkdir -p /root/incydent && cd /root/incydent
date -u > 01-czas.txt
ss -s > 02-sockets.txt
ip -s link > 03-interfaces.txt
sar -n DEV 1 10 > 04-pakiety.txt
dmesg -T | tail -100 > 05-kernel.txt
tcpdump -ni "$IF" -s 96 -c 500 -q > 06-probka.txt

tcpdump zawsze ograniczaj przez -c, bo nieograniczony zrzut na pełnym łączu dodatkowo obciąża serwer. Do zgłoszenia trafiają potem: moment zdarzenia razem ze strefą czasową, dotknięty adres IP wraz z portem, zmierzona liczba pakietów z podaniem kierunku, rozkład protokołów oraz rzucające się w oczy porty źródłowe. Z takimi danymi zgłoszenie trafia do obsługi od razu, a po „serwer był wolny” następuje runda pytań.

Gdzie te działania się kończą

Teraz część, której nie rozwiąże żaden plik konfiguracyjny. Wszystkie dotychczasowe działania pracują na końcu łącza. Reguła firewalla rozstrzyga o pakiecie, który przeszedł już przez kabel: możesz go odrzucić, ale nie możesz sprawić, żeby nie został wysłany.

Policz to razem ze mną. Łącze 1 Gbit/s przenosi 125 megabajtów na sekundę i jest pełne, gdy tylko ktoś wyśle więcej. Przy najmniejszych możliwych pakietach odpowiada to około 1,49 miliona pakietów na sekundę, a przy 10 Gbit/s około 14,9 miliona. Kernel serwera przetworzy z tego, zależnie od CPU i karty sieciowej, kilkaset tysięcy, zanim zacznie odrzucać. Atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, i tak cię więc położy, bo cały czas procesora idzie na odrzucanie.

Dla porządku wielkości, które zdarzają się naprawdę: na serwerach KernelHost odfiltrowano w czasie rzeczywistym między innymi atak o wolumenie ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę wymierzony w serwer głosowy (9987 UDP) oraz flood UDP o wolumenie ponad 112,2 Gbit/s w serwer gier (7777 UDP). Pierwszy przypadek to około 473 razy więcej, niż łącze 1 Gbit/s jest w stanie w ogóle przenieść. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem, bo inaczej kończą się w twoim łączu.

Co przeciwstawia temu KernelHost

Stała ochrona wliczona w każdy serwer

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i stale aktywna, bez konieczności zamawiania, włączania czy konfigurowania czegokolwiek:

• Warstwa 1: 17 Tbps pojemności mitygacji w globalnej sieci scrubbing. Ataki wolumetryczne są oczyszczane blisko źródła, zanim dotrą do centrum danych.
• Warstwa 2: filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps na miejscu we Frankfurcie nad Menem. Bezpośrednio przed serwerem rozpoznawane i odrzucane są wzorce specyficzne dla protokołów, pakiet po pakiecie.

W sytuacji krytycznej decydujące są dwie cechy. Ochrona działa nieprzerwanie i nie musi dopiero reagować na atak, nie ma więc kilku minut na starcie, w których serwer znika. Nie stosuje się też null-routingu: twój adres IP zostaje w sieci, a odrzucane są wyłącznie szkodliwe pakiety. Jeśli natomiast dostawca zdejmuje atakowany adres z sieci, wynik jest dla ciebie identyczny z udanym atakiem. Centrum danych to maincubes we Frankfurcie nad Menem w Niemczech, a operatorem jest KernelHost GmbH z siedzibą w Wiedniu w Austrii. Ochrona jest zawarta w każdym pakiecie serwerowym bez dopłaty, od serwera root KVM po serwer dedykowany.

Advanced DDoS Protection dla projektów pod stałym ostrzałem

Niektóre projekty obrywają nie okazjonalnie, tylko celowo i przez wiele tygodni. Dla nich jest Advanced DDoS Protection od 50,00 EUR miesięcznie, w modelu PrePaid i bez minimalnego okresu umowy. Różnica nie polega na większej pojemności, tylko na kontroli:

• Dedykowany chroniony adres IP z rdzenia sieci we Frankfurcie, na który twój serwer zostaje przełączony w naszej sieci. Po twojej stronie nie trzeba niczego przebudowywać.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta, bez zgłoszenia: port gry dostaje inne reguły niż port zapytań.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w środku trwającego ataku.
• Profil ochrony dopasowany do konkretnej gry, a do tego profile dla własnych i zmodyfikowanych aplikacji na dowolnych portach TCP albo UDP.

Porównanie obu poziomów

Dla większości projektów wystarczy wliczona stała ochrona razem z czystą konfiguracją serwera. Advanced DDoS Protection jest odpowiedzią na sytuację, w której ktoś bierze to do siebie osobiście.

Typowe błędy i ich rozwiązania

„Zrestartowałem serwer i potem przez chwilę znowu działało”: to atak szedł falami, a nie restart pomógł. Restarty kasują liczniki, które przydałyby się do zgłoszenia.

„Zmieniłem adres IP i dwie godziny później znowu byłem offline”: nowy adres trafił do atakującego z tego samego źródła co stary, zwykle z wpisu na liście serwerów, z bota statusowego albo ze starego wpisu DNS.

„Blokuję podejrzane adresy, a ciągle przychodzą nowe”: przy ataku rozproszonym są ich dziesiątki tysięcy, a przy atakach typu reflection i tak blokujesz wyłącznie postronne osoby trzecie.

„Moje reguły firewalla nie działają”: częste są trzy przyczyny. Reguły stoją za łańcuchami UFW, zniknęły po ostatnim restarcie albo atak jest wolumetryczny, a reguła pracuje poprawnie na łączu, które jest już pełne.

„Obciążenie było niskie, a usługa i tak padła”: typowy atak liczbą pakietów. Przepustowość wygląda niewinnie, liczba pakietów już nie. Mierz pakiety na sekundę, a nie megabity.

„W tcpdumpie nie widzę niczego podejrzanego”: jeśli ruch jest filtrowany w sieci przed serwerem, to zgodnie z oczekiwaniem nic do serwera nie dociera. Jeśli natomiast łącze jest zapchane, może do ciebie nie dojść nawet sesja SSH. Skorzystaj wtedy z konsoli VNC w panelu klienta.

W skrócie

Najpierw mierz, dopiero potem przebudowuj. Zamknij wszystko, czego usługa nie potrzebuje, ogranicz port zapytań, połączenia i liczbę pakietów osobno dla każdego adresu źródłowego oraz zbieraj wyniki pomiarów, dopóki incydent trwa. Jesteś wtedy przygotowany na wszystko, co obchodzi się bez znaczącej przepustowości. Powyżej tego progu rozstrzyga wyłącznie sieć stojąca przed serwerem.

Jeśli twój projekt działa już w KernelHoście, filtrowanie jest aktywne i nie musisz nic robić. Gdybyś mimo to zauważył coś nietypowego, załóż zgłoszenie wsparcia, żeby reguły filtrowania dla twojego adresu IP zostały skorygowane. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883.