Czym jest atak DDoS? Technika, warstwy i obrona

Atak DDoS to próba uczynienia usługi nieosiągalną przez sztucznie wytworzone przeciążenie, prowadzona jednocześnie z bardzo wielu różnych adresów nadawcy. Skrót pochodzi od Distributed Denial of Service, czyli od rozproszonej odmowy usługi. Atakowana nie jest ani treść serwera, ani luka bezpieczeństwa w jego oprogramowaniu, tylko zasób, który jest skończony: przepustowość łącza, liczba pakietów, jaką obsłuży karta sieciowa, miejsce w tablicy stanów kernela albo czas procesora, jaki aplikacja poświęca na jedno jedyne zapytanie. Gdy jeden z tych czterech zasobów jest zajęty, prawdziwi użytkownicy już nie przechodzą, i to bez tego, żeby ktokolwiek włamał się do systemu.

Ten wpis jest wprowadzeniem do tematu. Wyjaśnia trzy warstwy, na których odbywają się ataki, z jakimi współczynnikami amplifikacji z jednego bajtu zapytania robi się 51 000 bajtów odpowiedzi, skąd pochodzi pojemność do ataku i ile kosztuje ona na rynku, po czym rozpoznasz atak na swoich własnych pomiarach, co jeszcze pomaga na samym serwerze oraz gdzie dokładnie przebiega ta granica. Wszystkie liczby są podane wraz ze źródłem, żebyś mógł je sprawdzić. Jeśli twoja usługa właśnie stoi, przeczytaj najpierw rozdział „Co robić w razie ataku” i mierz, zamiast kręcić śrubami.

Czym jest atak DDoS z technicznego punktu widzenia

Każdy atak DDoS żyje z asymetrii: wysłanie pakietu musi kosztować atakującego mniej, niż przetworzenie tego pakietu kosztuje cel. Cała reszta to już tylko pytanie, w którym miejscu ta asymetria jest największa. Takich miejsc jest dokładnie cztery i każde ma twardy górny limit, który da się wyliczyć.

Przepustowość łącza. Łącze o przepustowości 1 Gbit/s przenosi 125 megabajtów na sekundę i nic więcej. Kto wyśle więcej, wytwarza straty, a straty dotykają pakietów twoich użytkowników dokładnie tak samo jak pakietów atakującego, bo pełne łącze nie wybiera.

Liczba pakietów na sekundę. Najmniejszy dopuszczalny pakiet ethernetowy ma 64 bajty i razem z preambułą oraz przerwą międzypakietową zajmuje na łączu 84 bajty. W 1 Gbit/s mieści się ich około 1,49 miliona na sekundę. Zwykły kernel serwera przetworzy, zależnie od procesora i karty sieciowej, kilkaset tysięcy, zanim zacznie odrzucać. Właśnie dlatego liczba pakietów jest prawie zawsze tą granicą, którą osiąga się przed przepustowością.

Tablice stanów. Kernel zapamiętuje połowicznie otwarte połączenia TCP oraz przepływy pakietów. Te tablice są ograniczone liczbowo, a nie w bitach na sekundę. Da się je zapełnić bardzo małą przepustowością, jeśli każdy pakiet niesie nowy adres nadawcy.

Czas procesora aplikacji. Zapytanie wyszukiwania, próba logowania ze sprawdzeniem hasła albo zapytanie o serwer, które zwraca całą listę modów, kosztuje cel tysiąc razy więcej niż nadawcę. Tutaj skuteczny atak nie potrzebuje często nawet 10 Mbit/s.

DoS i DDoS: różnica, którą da się zmierzyć

Podstawę pojęciową daje RFC 4732 „Internet Denial-of-Service Considerations”, informacyjna publikacja IETF z listopada 2006 roku. Stoi tam dosłownie: „A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work.” Atak DoS jest więc zdefiniowany przez skutek, a nie przez liczbę źródeł. Rozproszony, czyli DDoS, jest wtedy, gdy tych źródeł jest wiele i są one od siebie niezależne.

Praktycznie różnica liczy się w dokładnie jednym miejscu: w długości twojej listy blokad. Atak DoS z jednego źródła kończysz jedną regułą. Cloudflare udokumentował w maju 2025 roku atak, który przyszedł ze 122 145 różnych adresów źródłowych ze 161 krajów i 5433 systemów autonomicznych, średnio 26 855 nowych adresów na sekundę, w szczycie 45 097. Przeciwko czemuś takiemu nie ma listy blokad, która rosłaby dość szybko, a każdy wpis na niej kosztuje dodatkowo pamięć i czas wyszukiwania na urządzeniu, które i tak jest już przeciążone.

Wspólny przewodnik „Understanding and Responding to Distributed Denial-of-Service Attacks” autorstwa CISA, FBI i MS-ISAC dzieli ataki na dokładnie trzy techniki: wolumetryczne, protokołowe i aplikacyjne. Ten podział na trzy jest najużyteczniejszy, jaki istnieje, bo opisuje jednocześnie, który z twoich czterech zasobów jest atakowany i gdzie musi siedzieć obrona.

Trzy warstwy ataku DDoS

Ataki wolumetryczne na warstwie 3 i 4

Atak wolumetryczny nie chce niczego innego, jak zapełnić łącze przed celem. Mierzy się go w bitach na sekundę. Środkiem jest z reguły flood UDP, bo UDP nie zna nawiązywania połączenia, którego można by wymagać, i bo adresy nadawcy da się podrobić.

Obecnie największy publicznie udokumentowany przykład: Cloudflare podaje za okres do końca 2025 roku automatycznie odparty atak o wolumenie 31,4 Tbit/s, który trwał 35 sekund. To pojemność około 31 400 łączy serwerowych po 1 Gbit/s, jednocześnie, przez dobre pół minuty. W tym samym raporcie stoi druga wartość, która lepiej oddaje skalę niż wynik szczytowy: w 2025 roku ten sam operator odparł 47,1 miliona ataków DDoS, czyli o 121 procent więcej niż rok wcześniej, średnio 5376 ataków na godzinę.

Lepiej udokumentowany przypadek z maja 2025 roku pokazuje, jak taki atak wygląda, gdy rozłożyć go na części: 7,3 Tbit/s w szczycie, 37,4 terabajta danych w 45 sekundach, czyli średnio około 830 gigabajtów na sekundę. Łącze o przepustowości 1 Gbit/s potrzebowałoby na tę samą ilość danych dobrych trzech dni. 99,996 procent ruchu stanowiły czyste floody UDP, rozłożone średnio na 21 925 portów docelowych jednocześnie, w szczycie na 34 517. Takie rozłożenie na wszystkie porty jest typowe: atakujący nie wie, który port jest ważny, więc bierze wszystkie.

Ataki protokołowe: tablice, a nie łącze

Atak protokołowy wykorzystuje to, że kernel musi zapamiętywać stany. Standardowym przykładem jest flood SYN: atakujący wysyła pakiety TCP z ustawionym bitem SYN i podrobionym adresem nadawcy, serwer zakłada dla każdego z nich wpis w swojej kolejce połowicznie otwartych połączeń, odpowiada pakietem SYN-ACK na adres, który nigdy nie odpowiedział, i czeka. Mierzy się tutaj w pakietach na sekundę, a nie w gigabitach.

Długość tej kolejki stoi w net.ipv4.tcp_max_syn_backlog i na zwykłym serwerze leży w zakresie czterocyfrowym. Kolejka z 1024 miejscami zapełnia się przy 1,49 miliona pakietów SYN na sekundę w mniej niż milisekundę. Rachunkowo wystarczy do tego 1 Gbit/s, a jeśli celem jest wyłącznie tablica, wystarczy jego drobna część.

Do tej samej rodziny należy metoda opisana dopiero w 2021 roku: refleksja TCP przez urządzenia pośrednie z pamięcią stanu. Praca „Weaponizing Middleboxes for TCP Reflected Amplification” pokazuje, że firewalle i infrastruktura cenzury, które śledzą stan TCP tylko połowicznie, reagują na jeden podrobiony pakiet całymi stronami odpowiedzi. Tym samym po raz pierwszy także TCP daje się nadużyć do amplifikacji, co do tej pory uchodziło za praktycznie niemożliwe.

Ataki na aplikację na warstwie 7

Atak na aplikację wygląda jak zwykły ruch, bo jest zwykłym ruchem, tylko w niewłaściwej ilości. Mierzy się go w zapytaniach na sekundę. Przychodzi przez w pełni nawiązane połączenie, przeżywa więc każde sprawdzenie, które ocenia wyłącznie nawiązanie połączenia, i potrzebuje niewiele przepustowości: 10 000 zapytań HTTP na sekundę to, zależnie od rozmiaru zapytania, mniej niż 50 Mbit/s, a i tak dość, żeby położyć bazę danych.

Miarą tego jest HTTP/2 Rapid Reset, ujawniony 10 października 2023 roku jako CVE-2023-44487. Słabość leży w zdolności HTTP/2 do multipleksowania: atakujący otwiera strumień danych, wysyła zapytanie i natychmiast strumień przerywa. Serwer już zaczął pracę, a atakujący ma od razu znowu wolne miejsce w oknie. Osiągnięte tą drogą wartości wyniosły 201 milionów zapytań na sekundę (Cloudflare), 398 milionów (Google) oraz 155 milionów (Amazon). Dla porównania: najwyższy zmierzony do tego czasu atak na warstwę 7 u Cloudflare wynosił 71 milionów zapytań na sekundę.

Przy serwerach gier warstwą 7 jest samo nawiązywanie połączenia. Nullping, QuietException i floody fałszywych handshake'ów przeciwko sieciom Minecraft nie potrzebują prawie żadnej przepustowości, a kładą całe grupy proxy, bo każdy pakiet zmusza proxy do kosztownej decyzji o stanie. Jak dokładnie wyglądają te wzorce, opisuje wpis Ochrona DDoS Minecraft i ochrona przed Nullpingiem.

Trzy warstwy w porównaniu

Prawdziwe ataki nie trzymają się tego podziału. W praktyce najbardziej nieprzyjemny jest atak wielowarstwowy: część wolumetryczna, która zajmuje łącze, do tego część na warstwie 7, która przechodzi właśnie w chwili, gdy uwaga leży na przepustowości. Jeden z pokazanych niżej ataków odfiltrowanych w KernelHoście składał się z ponad dwunastu różnych wzorców głównych jednocześnie.

Ataki amplifikacyjne: jak z jednego bajtu robi się 51 000

Atak amplifikacyjny to atak, w którym atakujący nie strzela w cel sam, tylko nakłania cudze, publicznie osiągalne usługi, żeby zrobiły to za niego. Wysyła małe zapytanie do otwartej usługi i wpisuje jako nadawcę adres IP ofiary. Usługa odpowiada zgodnie z obowiązkiem, tylko że do ofiary, a odpowiedź jest wielokrotnie większa od zapytania.

Stosunek rozmiaru odpowiedzi do rozmiaru zapytania nazywa się Bandwidth Amplification Factor, w skrócie BAF, czyli współczynnik amplifikacji pasma. BAF równy 50 oznacza, że atakujący z własnym łączem 1 Gbit/s kieruje na cel 50 Gbit/s. Do tego, żeby to działało, muszą wystąpić razem dwie rzeczy: protokół nad UDP, który odpowiada więcej, niż jest pytany, oraz możliwość podrobienia adresu nadawcy. Dlatego IP spoofing jest warunkiem koniecznym każdego ataku amplifikacyjnego, a nie tylko taktyką maskowania.

Dla obrońcy wynika z tego nieprzyjemna cecha: ruch przychodzi od prawdziwych, legalnych serwerów. To realne resolwery DNS, realne serwery czasu, realne serwery gier. Lista blokad po adresie źródłowym albo wyklucza więc całe kraje, albo nie działa.

Współczynniki amplifikacji nadużywanych protokołów

Poniższe współczynniki pochodzą z alertu TA14-017A wydanego przez US-CERT, dziś CISA, „UDP-Based Amplification Attacks”, uzupełnianego na bieżąco od 2014 roku. To referencja, do której odnosi się cała branża.

Ta tabela wyjaśnia, dlaczego lista zablokowanych portów w każdym dobrze utrzymanym firewallu wygląda podobnie. To, co możesz zrobić sam, jest niewielkie, ale ważne: sprawdź przez ss -lnup, czy na twoim serwerze stoi otwarta w sieci usługa z tej tabeli. Memcached, który nie jest związany z 127.0.0.1, czyni z twojego serwera broń przeciwko osobom trzecim, kosztuje cię własną przepustowość wychodzącą i wprowadza twój adres IP na listy blokad, z których trudno wyjść.

Dlaczego protokoły zapytań o serwery gier też się tu liczą

Serwery gier stoją w tej tabeli w dwóch rolach. Są wzmacniaczem, bo ich port zapytań odpowiada na mały pakiet nazwą, mapą, liczbą graczy i całą listą modów. I są ofiarą, bo to samo zapytanie kosztuje czas procesora, często dokładnie na tym rdzeniu, który niesie symulację gry.

Współczynnik amplifikacji protokołu Steam leży nisko, na 5,5, a starszego protokołu Quake wysoko, na 63,9. Skutek nie zależy jednak od samego współczynnika, tylko od rozmiaru odpowiedzi w konkretnym przypadku: serwer z 200 modami zwraca wyraźnie większą odpowiedź niż serwer bez modów. Bohemia Interactive dokumentuje dla Arma 3 pod zgłoszeniem T83469 od 2015 roku, że do zamrożenia serwera wystarczyły już 4 Mbit/s podrobionych zapytań na port Steam Query. Cztery megabity na sekundę to mniej, niż wystawi jedno domowe łącze.

Wynika z tego reguła obowiązująca dla każdej gry: port zapytań ograniczać, a nie blokować. Kto go zablokuje, znika z listy serwerów i nowi gracze już go nie znajdą. Który port to jest w danej grze i jak ciasno wolno go prowadzić, stoi we wpisach dla poszczególnych gier niżej, na przykład dla Arma 3, CS2 i tytułów na silniku Source albo Rust.

Przypadek memcached: 1,35 Tbit/s przeciwko GitHubowi

28 lutego 2018 roku GitHub był nieosiągalny od 17:21 do 17:26 UTC, a do 17:30 UTC osiągalny tylko okresowo. Atak sięgnął 1,35 Tbit/s przy 126,9 miliona pakietów na sekundę i przyszedł z ponad 1000 różnych systemów autonomicznych oraz dziesiątek tysięcy pojedynczych punktów końcowych. Wzmocniony został przez memcached, ze współczynnikiem do 51 000: jeden bajt atakującego wytwarzał do 51 kilobajtów w kierunku celu.

Ten przypadek jest do dziś najlepszą lekcją, bo pokazuje trzy rzeczy naraz. Po pierwsze: amplifikacja bije rozmiar botnetu. Atakujący nie potrzebował stu tysięcy urządzeń, potrzebował otwartych instancji memcached, a tych stało wtedy w sieci na świecie ponad 90 000. Po drugie: 126,9 miliona pakietów na sekundę to około 85 razy więcej, niż łącze 1 Gbit/s jest w ogóle w stanie przenieść. Żadne ustawienie na serwerze tego nie zmieni. Po trzecie: obrona zadziałała, bo ruch został przekierowany do sieci filtrującej, a czas awarii skończył się przez to na dziewięciu minutach, a nie na dziewięciu godzinach.

Skąd pochodzi pojemność do ataku DDoS

Botnety z przejętych urządzeń

Botnet to zbiór cudzych urządzeń przejętych złośliwym oprogramowaniem, którymi atakujący steruje centralnie i zdalnie. Właściciele z reguły nic nie zauważają, bo urządzenie dalej robi to, do czego zostało kupione. Atakowane są przede wszystkim urządzenia, które wiszą w sieci na stałe, rzadko są aktualizowane i noszą domyślne hasła: routery, kamery monitoringu, rejestratory sieciowe, przystawki telewizyjne.

Miarą jest Mirai, którego kod źródłowy opublikowano na koniec września 2016 roku. Praca „Understanding the Mirai Botnet” (USENIX Security 2017) śledzi tę sieć przez siedem miesięcy i określa jej stan szczytowy na ponad 600 000 zainfekowanych urządzeń. Atak na stronę Briana Krebsa z września 2016 roku sięgnął 620 Gbit/s i przyszedł z ponad 175 000 urządzeń. Przy ataku na operatora DNS Dyn z 21 października 2016 roku, który jednocześnie uczynił nieosiągalnymi Twittera, Spotify i Reddita, policzono około 107 000 atakujących adresów IP.

Dziewięć lat później skala jest inna. Cloudflare wiąże rekordowy atak o wolumenie 31,4 Tbit/s z botnetem o szacowanej wielkości od jednego do czterech milionów zainfekowanych urządzeń, w przewadze przystawek telewizyjnych z Androidem. W fali ataków z grudnia 2025 roku policzono 902 ataki hiperwolumetryczne, średnio 53 na dobę, z wartościami szczytowymi 9 miliardów pakietów na sekundę, 24 Tbit/s oraz 205 milionów zapytań na sekundę. Wielkość botnetów wzrosła tym samym w ciągu dekady pięciokrotnie, a osiągana przepustowość pięćdziesięciokrotnie.

Usługi booter i stresser oraz ile kosztuje atak

Między botnetem a zlecającym siedzi usługa, która sprzedaje pojemność ataku w abonamencie. Usługi te występują jako „booter”, „stresser” albo „IP stresser” i twierdzą w swoich warunkach korzystania, że służą do testowania obciążeniowego własnych systemów. Nigdy przy tym nie sprawdzają, czy wpisany cel należy do użytkownika, i dokładnie w tym leży różnica między narzędziem a ofertą.

Obsługa to interfejs webowy z trzema polami: cel, port, czas trwania. Są procesy płatnicze, obsługa klienta i programy partnerskie dla odsprzedawców. Pakiety wejściowe leżą przy około 10 do 20 euro miesięcznie, większe pakiety z większą przepustowością i dłuższym czasem ataku przy kilkuset euro miesięcznie. Tym samym mamy odpowiedź na pytanie, dlaczego dostaje się też małym projektom: atak, który pozbawia serwer gier sobotniego wieczoru, kosztuje zlecającego mniej niż dwa bilety do kina i żadnej wiedzy technicznej.

Po drugiej stronie stoi stała presja ścigania. W tygodniu akcji międzynarodowej operacji PowerOFF w kwietniu 2026 roku organy z 21 krajów przejęły 53 domeny takich usług, aresztowały cztery osoby i przeprowadziły 25 przeszukań. Śledczy uzyskali przy tym dostęp do danych ponad trzech milionów kont użytkowników, a do ponad 75 000 zidentyfikowanych użytkowników wysłano pisma. W grudniu 2024 roku w tej samej operacji wyłączono 27 platform. Kto płaci za taką usługę, zostawia więc ślad płatniczy w bazie danych, która wcześniej czy później zostanie zabezpieczona.

Po czym poznasz atak DDoS

Co zgłaszają użytkownicy i co to już mówi

Pierwsza informacja przychodzi prawie zawsze od użytkowników i jest bardziej użyteczna, niż brzmi. Cztery zgłoszenia mają jasne znaczenie:

• „Wszystkich wyrzuciło jednocześnie.” Jednoczesne zerwanie u wszystkich użytkowników mówi o łączu albo o procesie usługi, a nie o pojedynczych połączeniach. Problem z obciążeniem dotyka użytkowników jeden po drugim.
• „Ping skacze z 20 na 400 i z powrotem.” Wahające się opóźnienie przy dalej istniejącym połączeniu to wzorzec przepełnionej kolejki przed celem, a nie przeciążonego procesu.
• „Lista serwerów pokazuje nas jako offline, ale ja mogę się połączyć.” To wskazanie na flood zapytań: port zapytań już nie odpowiada, port gry jeszcze tak.
• „Przez komórkę wchodzę, przez swoje łącze nie.” Różne zachowanie zależnie od sieci dostępowej wskazuje, że nasycony jest nie twój serwer, tylko jedna z dróg do niego.

Cztery pomiary na serwerze

Potem się mierzy, i to w tej kolejności: liczba pakietów, przepustowość, stany połączeń, liczniki odrzuconych pakietów. Wskaźnik obciążenia procesora przychodzi na końcu, bo przy ataku sieciowym często pozostaje niepozorny.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 podaje pakiety i bajty na sekundę dla każdego interfejsu przez dziesięć sekund. Decydujący jest stosunek: dużo pakietów przy małej liczbie bajtów oznacza małe pakiety, czyli atak protokołowy. Mało pakietów przy bardzo dużej liczbie bajtów oznacza duże pakiety, czyli atak amplifikacyjny. ip -s link show pokazuje w kolumnach dropped i overrun, czy kernel już odrzuca. ss -tn state syn-recv liczy połowicznie otwarte połączenia: wartość trzycyfrowa jest normalna, pięciocyfrowa to flood SYN. A nstat podaje liczniki, które zostają także po zakończeniu ataku.

Najważniejszy krok to ten, którego prawie nikt nie robi wcześniej: przygotuj bazę porównawczą, dopóki wszystko działa normalnie. Bez wartości normalnej nie powiesz, czy 40 000 pakietów na sekundę to dużo, czy po prostu sobotni wieczór. Po apt-get install -y vnstat sysstat pomiar chodzi na stałe w tle. Szczegółową instrukcję odczytu znajdziesz we wpisie Jak rozpoznać atak DDoS.

Wpisy w logach, które są jednoznaczne

Cztery komunikaty w logu kernela i w logu serwera WWW są praktycznie dowodem. dmesg -T | tail -50 pokazuje pierwsze trzy:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

Pierwszy wiersz oznacza, że kolejka połowicznie otwartych połączeń się przelała i kernel przeszedł na SYN-cookies. Jeśli stoi tam zamiast tego Dropping request, to net.ipv4.tcp_syncookies jest ustawione na 0, a serwer odrzuca zapytania, w tym prawdziwe. Drugi wiersz oznacza, że śledzenie połączeń jest pełne, a od tej chwili serwer odrzuca także legalny ruch. Trzeci wiersz to skutek uboczny: kernel tłumi komunikaty, bo inaczej byłby zajęty logowaniem. Czwarty wiersz przenosi problem do aplikacji.

W logu dostępu serwera WWW wymowne są dwie rzeczy. Nagły udział kodu statusu 499 oznacza, że klient zamyka połączenie przed ukończeniem odpowiedzi, a dokładnie tak robi atak na warstwę 7, który chce tylko wywołać pracę, a nie czytać. Puste pole referrera przy niemal wszystkich zapytaniach odróżnia zaś atak od prawdziwego napływu odwiedzających, który przynosi referrery z wyszukiwarek i sieci społecznościowych.

Kontrpróba: atak, napływ czy własny błąd

Co pomaga na samym serwerze

Na serwerze da się osiągnąć więcej, niż często się twierdzi, i to przeciwko wszystkiemu, co pozostaje małe: niechlujnym botom, pojedynczym źródłom, floodom zapytań i atakom na aplikację. Narzędziami są nftables, śledzenie połączeń, SYN-cookies oraz ograniczenie liczby na adres źródłowy. Wszystkie poniższe informacje dotyczą Debiana 12, Debiana 13, Ubuntu 22.04 LTS oraz Ubuntu 24.04 LTS i są napisane dla użytkownika root.

nftables: odrzucać wcześnie, liczyć mało

Zasada brzmi: pakiet, który ma zostać odrzucony, powinien zostać odrzucony tak wcześnie i tak tanio, jak to możliwe. Każda reguła, która działa przed tym, kosztuje czas procesora razy liczba pakietów. Poniższy zestaw reguł dla /etc/nftables.conf przepuszcza serwer WWW oraz usługę gry, a resztę odrzuca, z ograniczeniem liczby nowych połączeń TCP na adres źródłowy:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Wpisz pod adminips swój własny stały adres, zanim wczytasz reguły, bo inaczej zamkniesz sobie dostęp przez SSH. Sprawdza się je i aktywuje tak:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

O skutku decydują trzy punkty. ct state established,related accept stoi świadomie jako druga reguła, żeby istniejące połączenia nie przechodziły przez cały zestaw reguł. ct state invalid counter drop usuwa błędne kombinacje flag i spóźnione fragmenty bez tego, żebyś musiał opisywać je pojedynczo. A counter przed każdym drop jest powodem, dla którego potem wiesz, która reguła zadziałała: jeśli liczniki zostają na zerze, reguła nie jest osiągana, a to całkiem inna diagnoza niż bezskuteczny zestaw reguł.

SYN-cookies i granica kolejki backlog

SYN-cookies to metoda, w której serwer nie zapamiętuje połowicznie otwartego połączenia, tylko zapisuje potrzebne informacje zaszyfrowane we własnym numerze odpowiedzi. Gdy wraca trzeci pakiet nawiązania połączenia, wylicza z niego stan z powrotem. Kolejka nie przelewa się już wtedy, bo dla tych połączeń żadnej kolejki nie ma.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Te wartości należą do pliku pod /etc/sysctl.d/ i przejmuje się je przez sysctl --system, bo inaczej znikną po następnym restarcie. Na Debianie i Ubuntu tcp_syncookies stoi fabrycznie na 1, i tak jest poprawnie. Wartość 1 nie oznacza „zawsze cookies”, tylko „cookies, gdy tylko kolejka się przelewa”.

Cena za to jest realna i rzadko się o niej mówi. W cookie nie ma miejsca na opcje TCP drugiej strony. Linux ratuje skalowanie okna i selektywne potwierdzanie tylko wtedy, gdy net.ipv4.tcp_timestamps stoi na 1, bo wtedy te informacje podróżują w znaczniku czasu. Bez znaczników czasu wypadają, a połączenie działa wolniej przez resztę swojego życia. Poza tym na maksymalny rozmiar pakietu są dostępne tylko trzy bity, czyli osiem zgrubnych stopni zamiast dokładnej wartości. SYN-cookies to tryb awaryjny, który ratuje połączenia, a nie ustawienie na normalną pracę.

conntrack: tablica, która zapełnia się pierwsza

Śledzenie połączeń w kernelu zakłada wpis dla każdego przepływu pakietów, także dla UDP, choć UDP nie zna połączeń. Dokładnie ta tablica jest przy rozproszonym ataku pierwszym zasobem, który się kończy, i kończy się bardzo szybko: przy 1,49 miliona pakietów na sekundę z coraz to nowym adresem nadawcy tablica z 262 144 miejscami jest zapełniona w mniej niż jedną piątą sekundy.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Jeden wpis zajmuje około 300 bajtów, 524 288 wpisów to więc około 150 megabajtów pamięci kernela. Rozmiar tablicy haszującej ustawia się nie przez sysctl, tylko jako parametr modułu, zwyczajowo na jedną czwartą górnego limitu, w /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Dla czystego serwera gry albo serwera głosowego elegantszym rozwiązaniem jest całkowite wyłączenie śledzenia ruchu gry. To oszczędza tablicę w całości:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Uwaga: notrack i reguły oparte na stanie wykluczają się wzajemnie. Kto wyjmuje port ze śledzenia, nie może już używać dla tego portu reguły z ct state, bo inaczej przepustka przestaje działać, a usługa jest zamknięta.

Ograniczenie liczby na adres źródłowy

Ograniczenie liczby na adres źródłowy to najskuteczniejsze pojedyncze działanie na serwerze, bo trafia dokładnie w to, co robi atakujący, i przepuszcza dokładnie to, co robi użytkownik. Różnica jest duża: prawdziwa przeglądarka serwerów odpytuje kilka razy na minutę, a atakujący setki razy na sekundę. Przy nftables pracuje się do tego ze zbiorami dynamicznymi, jak w zestawie reguł powyżej, a przy klasycznym iptables z hashlimit:

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

Wszystkie liczby w takich regułach to wartości startowe, a nie prawdy objawione. Mierz najpierw tydzień w normalnej pracy, bo inaczej wyrzucisz własnych użytkowników, i to w najgorszym momencie. Pamiętaj poza tym, że same reguły iptables znikają po restarcie (apt-get install -y iptables-persistent, potem netfilter-persistent save) i że przy UFW należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload. Pełny zestaw reguł na bieżącą pracę znajdziesz we wpisie Jak chronić serwer przed atakami DDoS.

Gdzie kończy się każde filtrowanie na serwerze

Teraz część, której nie rozwiąże żaden plik konfiguracyjny. Wszystkie dotychczasowe działania dzieją się na twoim serwerze, czyli na końcu łącza. Reguła firewalla decyduje o pakiecie, który już przeszedł przez kabel. Możesz go odrzucić, ale nie możesz sprawić, żeby nie został wysłany. Gdy łącze przed nim jest pełne, pakiety twoich użytkowników nie docierają już wcześniej, i to niezależnie od tego, jak dobry jest twój zestaw reguł.

Ta tabela odpowiada na pytanie, czy ochrona własna wystarczy, dla każdego pojedynczego przypadku. Atak na GitHuba z 126,9 miliona pakietów na sekundę mieści się co do liczby pakietów z trudem na łączu 100 Gbit/s, ale przy wolumenie 1,35 Tbit/s potrzeba by czternastu takich łączy jednocześnie. Rekordowy atak o wolumenie 31,4 Tbit/s odpowiada 314 całkowicie wysyconym łączom po 100 Gbit/s. Serwer gier wisi typowo na 1 Gbit/s albo na dwa razy 1 Gbit/s: granica ochrony własnej leży tym samym przy około 1,5 do 3 milionów pakietów na sekundę, a praktycznie wyraźnie niżej, bo kernel poddaje się wcześniej.

Jest jeszcze druga, nieprzyjemniejsza granica. Gdy tylko łącze jest wysycone, może cię w pewnych okolicznościach nie dosięgnąć nawet sesja SSH, której chciałeś użyć do pomiaru. Kto nie ma wtedy dostępu niezależnego od sieci, na przykład konsoli VNC w panelu klienta, nie może nawet sprawdzić, co się dzieje.

Co pomaga tylko przed serwerem: filtrowanie w sieci i scrubbing

Skutecznie filtrować może tylko ten, kto ma większą pojemność niż atak. To wymaga miejsca, w którym zbiega się wiele łączy, czyli sieci, a nie maszyny. Są tam dwie metody, które się dopełniają.

Filtrowanie w sieci w czasie rzeczywistym. Cały ruch przechodzi trwale przez stopień filtrujący, który ocenia każdy pakiet, zanim przekaże go do serwera. Zaletą jest brak przełączania: ochrona nie musi najpierw rozpoznać ataku, żeby zadziałać. Dokładnie to decyduje przy grach, bo czas przełączenia wynoszący dwie minuty to przegrana runda, a czas przełączenia wynoszący dwie minuty przy ataku, który trwa 35 sekund, to w ogóle nie obrona.

Scrubbing. Gdy sieć rozpozna duży atak wolumetryczny, dotknięty ruch jest przekierowywany do centrów filtrujących, tam oczyszczany ze szkodliwych części, a następnie doprowadzany w kierunku celu. Sensem tego przekierowania jest bliskość: ruch atakujący kończy się w miejscu, w którym wchodzi, a nie dopiero w centrum danych. Reguły filtrowania są do tego rozprowadzane w sieci, co technicznie opisuje RFC 8955 jako Flow Specification.

Strukturalne przeciwdziałanie podrobionym adresom nadawcy jest zresztą znane od 2000 roku i stoi w RFC 2827, czyli w BCP 38: kto przyłącza klienta, odrzuca na tej granicy wszystkie pakiety, których adres nadawcy nie należy do tego klienta. RFC 3704 rozszerza to na sieci przyłączone wielokrotnie. Gdyby wszyscy operatorzy sieci to wdrożyli, cała klasa ataków amplifikacyjnych byłaby skończona. Nie jest, bo wystarczy, że niektórzy tego nie robią.

Jest jeszcze trzecia metoda, którą trzeba znać, bo bywa sprzedawana jako ochrona: null-routing, technicznie Remote Triggered Black Hole Filtering według RFC 5635. Atakowany adres IP zostaje przy tym ogłoszony w sieci jako nieosiągalny, a cały ruch do niego jest odrzucany, ruch atakujący tak samo jak ruch twoich użytkowników. To chroni sieć dostawcy, a dla ciebie wynik jest identyczny z udanym atakiem, zwykle jeszcze przez wiele godzin po nim. W razie wątpliwości zapytaj, czy ruch jest filtrowany, czy null-routowany. Ta odpowiedź decyduje o twojej dostępności bardziej niż jakakolwiek specyfikacja sprzętu.

Co przeciwstawia temu KernelHost

Stała ochrona zawarta w każdym pakiecie serwerowym

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i stale aktywna, bez konieczności włączania, zamawiania 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 we Frankfurcie nad Menem. Bezpośrednio przed serwerem rozpoznawane i odrzucane są wzorce specyficzne dla protokołów, pakiet po pakiecie.

Decydujące są dwie cechy. Ochrona działa nieprzerwanie i jest aktywna od momentu udostępnienia serwera, nie ma więc kilku minut na starcie ataku, w których usługa znika. I nie stosuje się null-routingu: twój adres IP zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety. Które gry i protokoły mają własne profile filtrowania, wylicza wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

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

Niektóre projekty są atakowane nie okazjonalnie, tylko celowo i przez wiele tygodni, każdego wieczoru o tej samej porze i ze zmiennymi wzorcami. Dla nich jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid, bez minimalnego okresu umowy i bez opłaty aktywacyjnej. 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: osobno ustawiasz, co jest dozwolone na porcie gry, a co na porcie zapytań, i możesz tym samym wykorzystać dokładnie tę asymetrię z rozdziału o protokołach zapytań.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, zamiast czekać na okno serwisowe.
• Profil ochrony dopasowany do konkretnej usługi, tak samo dla zmodyfikowanych i własnych aplikacji na dowolnych portach TCP albo UDP.

Advanced DDoS Protection jest skierowana do klientów KernelHost i wymaga serwera w KernelHoście. Jeśli twój projekt działa obecnie gdzie indziej i jest tam regularnie atakowany, drogą jest przeniesienie go tutaj, a nie zdalna opieka nad twoim dotychczasowym adresem.

Porównanie obu warstw

Sześć realnie odfiltrowanych ataków z praktyki

Poniższych sześć ataków uderzyło w serwery klientów KernelHost i zostało w całości odfiltrowanych w czasie rzeczywistym, za każdym razem bez awarii. Zrzuty ekranu pochodzą z monitoringu mitygacji na żywo.

Serwer głosowy TeamSpeak 3, port 9987 UDP. Złożony atak z kilkoma równoczesnymi wzorcami, ponad 473,4 Gbit/s i ponad 41,5 miliona pakietów na sekundę. To około 28-krotności liczby pakietów łącza 1 Gbit/s.

Serwer gry ARK, port 7777 UDP. Prosty flood UDP bez złożonej struktury, za to ponad 112,2 Gbit/s i ponad 8,7 miliona pakietów na sekundę. Jak obok tego zabezpiecza się sam klaster ARK, opisuje wpis Ochrona serwera ARK przed atakami DDoS.

Atak na wszystkie porty, porty 0-65535 TCP i UDP. Ponad dwanaście różnych głównych wzorców ataku wymierzonych jednocześnie we wszystkie porty, łącznie ponad 21,3 Gbit/s i ponad 3,9 miliona pakietów na sekundę. Ten przypadek pokazuje rozłożenie na wszystkie porty, jakie wykazuje też przypadek Cloudflare z maja 2025 roku ze średnio 21 925 portami docelowymi.

Minecraft i OpenVPN, porty 25565 TCP oraz 1194 UDP. Połączony atak z ponad szesnastoma różnymi głównymi wzorcami, ponad 4 milionami pakietów na sekundę i ponad 8,6 Gbit/s. Obie usługi pozostały osiągalne przez cały czas, choć mówią różnymi protokołami.

Flood UDP na pojedynczy port usługi, osiem minut. Najcięższy z tych sześciu przypadków: 745,5 Gbit/s i 73,1 miliona pakietów na sekundę, czyli około 49-krotności liczby pakietów łącza 1 Gbit/s. 99,93 procent ruchu przypadało na jeden jedyny port docelowy, źródła były całkowicie rozproszone. Po ośmiu minutach atak się skończył, usługa pozostała osiągalna przez cały czas.

Atak ciągły przez trzy godziny i 31 minut. 501,2 Gbit/s i 43,9 miliona pakietów na sekundę, nie jako pojedynczy szczyt, lecz jako ciąg fal bez przerwy. Siedem wzorców ataku jednocześnie, wśród nich amplifikacja przez SSDP, MS SQL RS, L2TP i RIPv1. Porty docelowe rozłożyły się na cały zakres od 1024 do 65535, zmiana portu nie dałaby więc nic. Więcej o obu przypadkach we wpisie Jak długo trwa atak DDoS.

Co robić w razie ataku, w tej kolejności

Kolejność jest ważniejsza niż poszczególne kroki, bo najczęstsze błędy dzieją się w pierwszych pięciu minutach.

1. Mierz, nie kręć śrubami. Zabezpiecz najpierw do pliku wartości z sar -n DEV 1 10, ip -s link show, ss -s oraz dmesg -T. Po ataku już ich nie będzie, a bez nich nikt ci nie pomoże.
2. Nie restartuj. Restart usuwa wszystkie liczniki, wszystkie stany połączeń i każdy dowód, a obciążenie wraca po kilku sekundach.
3. Ustal, o którą warstwę chodzi. Bajty podzielone przez pakiety dają średni rozmiar pakietu. Poniżej 100 bajtów wskazuje na atak protokołowy, powyżej 1000 bajtów na atak amplifikacyjny, normalne rozmiary przy wysokim obciążeniu CPU na warstwę 7.
4. Zamknij porty administracyjne. Panel, baza danych, RCon i wszystko, co nie musi być publiczne, należy ograniczyć do twojego własnego adresu. To zmniejsza powierzchnię ataku natychmiast i bez ryzyka dla użytkowników.
5. Ustaw ograniczenie liczby, ciasno na porcie zapytań, szeroko na porcie użytkowym. Nie blokuj portu zapytań, bo inaczej znikniesz z każdej listy serwerów.
6. Nie zmieniaj pospiesznie własnego adresu. Zmiana adresu działa tylko tak długo, jak nowy adres nie stoi znowu publicznie, a zapomniany stary wpis DNS unieważnia całą zmianę.
7. Włącz dostawcę, podając liczby. Załóż zgłoszenie z momentem, portem docelowym, liczbą pakietów, przepustowością i średnim rozmiarem pakietu. Te pięć informacji decyduje o tym, jak szybko reguły filtrowania dla twojego adresu zostaną skorygowane.
8. Potem dokumentuj. Zanotuj, kiedy się zaczęło, jak długo trwało i jaki to był wzorzec. Powtarzające się ataki o tej samej godzinie to kryterium tego, czy projekt potrzebuje dedykowanego chronionego adresu IP.

Szczegółowy przebieg dla ciężkiego, dłużej trwającego ataku opisuje wpis Ciężki atak DDoS: co robić.

Stan prawny: atak DDoS to przestępstwo

W Austrii atak DDoS podpada pod § 126b austriackiego kodeksu karnego (StGB), „Zakłócenie funkcjonowania systemu komputerowego”. Podstawowy typ czynu przewiduje karę pozbawienia wolności do sześciu miesięcy albo karę grzywny do 360 stawek dziennych. Jeśli zakłócenie trwa dłuższy czas, jest to do dwóch lat. Jeśli wiele systemów zostaje zaatakowanych programem widocznie do tego stworzonym, są to do trzech lat. A przy szkodzie ponad 300 000 euro, przy ataku na infrastrukturę krytyczną albo jako członek organizacji przestępczej wymiar leży między sześcioma miesiącami a pięcioma latami. Uzupełniająco § 126c austriackiego StGB penalizuje już samo wytwarzanie, rozpowszechnianie i udostępnianie programów do tego przeznaczonych.

W Niemczech stosuje się § 303b niemieckiego kodeksu karnego (StGB), „Sabotaż komputerowy”: do trzech lat pozbawienia wolności albo kara grzywny, do pięciu lat, gdy przetwarzanie danych służy zakładowi, przedsiębiorstwu albo organowi władzy, a w przypadkach szczególnie ciężkich od sześciu miesięcy do dziesięciu lat, na przykład przy działaniu zawodowym albo przy naruszeniu infrastruktury krytycznej. Usiłowanie jest karalne, a dla czynności przygotowawczych § 303b ust. 5 niemieckiego StGB odsyła do § 202c niemieckiego StGB.

Usługi booter i stresser nie są więc szarą strefą, tylko płatną częścią przestępstwa. Trzy punkty są przy tym regularnie źle rozumiane. Po pierwsze wzmianka „tylko do testów obciążeniowych własnych systemów” nie czyni niczego legalnym, bo usługi nie sprawdzają, do kogo należy wpisany cel. Po drugie karalny jest także zlecający, a nie tylko operator: Europol po tygodniu akcji w kwietniu 2026 roku wyraźnie wysłał pisma do ponad 75 000 zidentyfikowanych użytkowników, żeby to właśnie wyjaśnić. Po trzecie test obciążeniowy na własnym serwerze przez taką usługę też nie jest rozwiązaniem, bo ruch atakujący idzie przez sieć dostawcy, a tym samym przez łącza innych klientów, czego zakazuje każda umowa hostingowa. Kto naprawdę chce zmierzyć odporność swojej usługi, robi to zgłoszone i w porozumieniu z dostawcą. Ten rozdział oddaje stan prawny i nie stanowi porady prawnej.

Właściwy poradnik dla twojej usługi

Ten wpis wyjaśnia zasadę. Który port ma być otwarty, która dyrektywa konfiguracyjna ogranicza które zapytanie i gdzie leży granica w danej grze: to stoi we wpisach o poszczególnych usługach, za każdym razem z tabelą faktów o portach.

• Podstawy i przebieg: Jak rozpoznać atak DDoS, Jak chronić serwer przed atakami DDoS, Ciężki atak DDoS: co robić, Ochrona DDoS gier z filtrowaniem w czasie rzeczywistym
• Minecraft i głos: Minecraft i Nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Role-play na bazie GTA: FiveM, RedM, RAGE MP i alt:V, SA-MP i open.mp, MTA:SA
• Przetrwanie i budowanie: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Taktyka i strzelanie: CS2 i Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Krótkie podsumowanie

• Atak DDoS zajmuje jeden z czterech skończonych zasobów: przepustowość, liczbę pakietów, tablicę stanów kernela albo czas procesora aplikacji. Nie wykorzystuje luki bezpieczeństwa, dlatego samo aktualizowanie nie chroni.
• RFC 4732 definiuje atak DoS przez skutek, a nie przez liczbę źródeł. Rozproszony nazywa się wtedy, gdy źródeł jest wiele: w przypadku Cloudflare z maja 2025 roku było to 122 145 adresów ze 161 krajów.
• CISA, FBI i MS-ISAC rozróżniają trzy techniki: wolumetryczną w Gbit/s, protokołową w pakietach na sekundę, aplikacyjną w zapytaniach na sekundę. Każda potrzebuje innej obrony.
• Ataki amplifikacyjne nadużywają otwartych usług UDP. Współczynniki sięgają od 5,5 przy protokole Steam przez 30,8 przy SSDP i 556,9 przy NTP aż do 51 000 przy memcached, co da się sprawdzić w alercie US-CERT TA14-017A.
• Pojemność pochodzi z botnetów przejętych urządzeń, od 600 000 przy Mirai w 2016 roku do szacowanych od jednego do czterech milionów za rekordowym atakiem o wolumenie 31,4 Tbit/s, i jest odsprzedawana od około 10 euro miesięcznie.
• Na serwerze działają nftables, SYN-cookies, dopasowane limity conntrack oraz ograniczenie liczby na adres źródłowy. Kończą się przy około 1,5 miliona pakietów na sekundę, bo łącze 1 Gbit/s nie przeniesie więcej.
• Powyżej tej granicy decyduje wyłącznie filtrowanie w sieci przed serwerem. Null-routing nie jest obroną, tylko wynikiem, którego chciał atakujący.
• W KernelHoście dwuwarstwowa stała ochrona jest zawarta w każdym pakiecie serwerowym bez dopłat i działa od momentu udostępnienia, bez null-routingu: 17 Tbps pojemności mitygacji w globalnej sieci scrubbing plus filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps we Frankfurcie nad Menem. Advanced DDoS Protection uzupełnia ją od 50,00 € miesięcznie o dedykowany chroniony adres IP i samodzielnie zarządzane reguły na port.
• Atak DDoS jest karalny w Austrii według § 126b austriackiego StGB, a w Niemczech według § 303b niemieckiego StGB, dla zlecających tak samo jak dla operatorów tych usług.

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 z pięcioma informacjami z kroku 7, ż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.