Co je DDoS útok? Technika, úrovně a obrana

DDoS útok je pokus znepřístupnit službu uměle vyvolaným přetížením, prováděný současně z velmi mnoha různých odesílatelů. Zkratka znamená Distributed Denial of Service, tedy distribuovaně vyvolané odepření služby. Neútočí se přitom ani na obsah serveru, ani na bezpečnostní chybu v jeho softwaru, nýbrž na prostředek, který je konečný: na šířku pásma linky, na paketovou rychlost síťové karty, na místo ve stavové tabulce jádra nebo na výpočetní čas, který aplikace vynaloží na jediný dotaz. Jakmile je jeden z těchto čtyř prostředků obsazený, skuteční uživatelé se už nedostanou skrz, a to aniž by někdo do systému pronikl.

Tento článek je vstupem do tématu. Vysvětluje tři úrovně, na kterých útoky probíhají, s jakými faktory zesílení se z jednoho bajtu dotazu stane 51 000 bajtů odpovědi, odkud se útočná kapacita bere a kolik stojí na trhu, podle čeho útok poznáte na vlastních naměřených hodnotách, co ještě pomůže na serveru samotném a kde přesně tato hranice vede. Všechna čísla jsou uvedena se zdrojem, abyste si je mohli ověřit. Pokud vaše služba právě stojí, přečtěte si nejdřív oddíl „Co dělat při útoku“ a měřte, místo abyste šroubovali.

Co je DDoS útok technicky

Každý DDoS útok žije z asymetrie: odeslat paket musí útočníka stát méně, než stojí cíl tento paket zpracovat. Všechno ostatní je jen otázka toho, na kterém místě je tato asymetrie největší. Taková místa jsou přesně čtyři a každé má tvrdou horní mez, kterou lze spočítat.

Šířka pásma linky. Přípojka s 1 Gbit/s přenese 125 megabajtů za sekundu, víc ne. Kdo pošle více, vyvolá ztráty, a ty zasáhnou pakety vašich uživatelů stejně jako pakety útočníka, protože plná přípojka nevybírá.

Paketová rychlost. Nejmenší přípustný ethernetový paket má 64 bajtů a s preambulí a mezerou mezi pakety zabírá na lince 84 bajtů. Do 1 Gbit/s se jich vejde zhruba 1,49 milionu za sekundu. Běžné serverové jádro jich podle CPU a síťové karty zpracuje několik set tisíc, než začne zahazovat. Paketová rychlost je proto téměř vždy tou hranicí, které se dosáhne dřív než šířky pásma.

Stavové tabulky. Jádro si pamatuje polootevřená spojení TCP a toky paketů. Tyto tabulky jsou omezené počtem, ne v bitech za sekundu. Naplnit je lze s velmi malou šířkou pásma, pokud každý paket nese novou adresu odesílatele.

Výpočetní čas aplikace. Vyhledávací dotaz, pokus o přihlášení s ověřením hesla nebo serverový dotaz, který vrací celý seznam modů, stojí cíl tisíckrát víc než odesílatele. Zde účinný útok často nepotřebuje ani 10 Mbit/s.

DoS a DDoS: rozdíl, který se dá změřit

Pojmový základ dodává RFC 4732, „Internet Denial-of-Service Considerations“, informační publikace IETF z listopadu 2006. Doslova se tam píše: „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.“ DoS útok je tedy definován přes účinek, ne přes počet zdrojů. Distribuovaný, tedy DDoS, je tehdy, když jsou tyto zdroje početné a vzájemně nezávislé.

Prakticky se rozdíl počítá na jediném místě: na délce vašeho seznamu blokovaných adres. DoS útok z jednoho zdroje ukončíte jedním pravidlem. Cloudflare v květnu 2025 zdokumentoval útok, který přišel ze 122 145 různých zdrojových adres ze 161 zemí a 5 433 autonomních systémů, průměrně 26 855 nových adres za sekundu, ve špičce 45 097. Proti něčemu takovému neexistuje seznam blokovaných adres, který by rostl dost rychle, a každý záznam v něm navíc stojí paměť a čas vyhledávání na zařízení, které je už tak přetížené.

Společný návod „Understanding and Responding to Distributed Denial-of-Service Attacks“ od CISA, FBI a MS-ISAC dělí útoky přesně na tři techniky: volumetrické, protokolové a aplikační. Toto rozdělení je nejužitečnější, jaké existuje, protože zároveň popisuje, který z vašich čtyř prostředků je napadán a kde musí sedět obrana.

Tři úrovně DDoS útoku

Volumetrické útoky na Layer 3 a 4

Volumetrický útok nechce nic jiného než zaplnit linku před cílem. Měří se v bitech za sekundu. Prostředkem bývá zpravidla UDP flood, protože UDP nezná navázání spojení, které by se dalo vyžadovat, a protože adresy odesílatele lze podvrhnout.

Aktuálně největší veřejně zdokumentovaný příklad: Cloudflare hlásí za období do konce roku 2025 automaticky odražený útok s 31,4 Tbit/s, který trval 35 sekund. To je kapacita zhruba 31 400 serverových přípojek s 1 Gbit/s, současně, po dobu dobré půlminuty. Ve stejné zprávě stojí druhá hodnota, která řádovou velikost činí uchopitelnější než špičková čísla: v roce 2025 odrazil tentýž provozovatel 47,1 milionu DDoS útoků, o 121 procent více než v předchozím roce, průměrně 5 376 útoků za hodinu.

Lépe zdokumentovaný případ z května 2025 ukazuje, jak takový útok vypadá, když se rozebere: 7,3 Tbit/s ve špičce, 37,4 terabajtu dat za 45 sekund, to je průměrně zhruba 830 gigabajtů za sekundu. Linka s 1 Gbit/s by na stejný objem dat potřebovala dobré tři dny. 99,996 procenta provozu byly čisté UDP floody, rozdělené průměrně přes 21 925 cílových portů současně, ve špičce 34 517. Toto rozprostření přes všechny porty je typické: útočník neví, který port je důležitý, a tak si vezme všechny.

Protokolové útoky: tabulky, ne linka

Protokolový útok využívá toho, že si jádro musí pamatovat stavy. Standardním příkladem je záplava SYN: útočník posílá TCP pakety s nastaveným bitem SYN a podvrženou adresou odesílatele, server pro každý z nich založí záznam ve své frontě polootevřených spojení, odpoví paketem SYN-ACK na adresu, která se nikdy neozvala, a čeká. Měří se zde v paketech za sekundu, ne v gigabitech.

Délka této fronty stojí v net.ipv4.tcp_max_syn_backlog a na běžném serveru se pohybuje ve čtyřmístném rozsahu. Fronta s 1 024 místy je při 1,49 milionu paketů SYN za sekundu plná za méně než milisekundu. Čistě početně na to stačí 1 Gbit/s, a je-li cílem jen tabulka, stačí zlomek.

Do stejné rodiny patří postup, který byl popsán teprve v roce 2021: TCP reflexe přes stavová zprostředkující zařízení. Práce „Weaponizing Middleboxes for TCP Reflected Amplification“ ukazuje, že firewally a cenzurní infrastruktura, které sledují stav TCP jen zpola, reagují na jediný podvržený paket celými stránkami odpovědi. Tím lze poprvé zneužít k zesílení i TCP, což do té doby platilo za prakticky nemožné.

Aplikační útoky na Layer 7

Aplikační útok vypadá jako běžný provoz, protože běžným provozem je, jen v nesprávném množství. Měří se v požadavcích za sekundu. Přichází přes plně navázané spojení, přežije tedy každou kontrolu, která hodnotí jen navázání spojení, a potřebuje málo šířky pásma: 10 000 HTTP požadavků za sekundu je podle velikosti požadavku méně než 50 Mbit/s, a přesto to stačí, aby to srazilo databázi na kolena.

Měřítkem je HTTP/2 Rapid Reset, zveřejněný 10. října 2023 jako CVE-2023-44487. Slabina leží ve schopnosti multiplexu u HTTP/2: útočník otevře datový proud, pošle požadavek a proud okamžitě zase zruší. Server už práci začal, útočník má ale hned zase volné místo v okně. Dosažené hodnoty ležely na 201 milionech požadavků za sekundu (Cloudflare), 398 milionech (Google) a 155 milionech (Amazon). Pro srovnání: dosud nejvyšší útok na Layer 7 naměřený Cloudflarem ležel na 71 milionech požadavků za sekundu.

U herních serverů je úrovní Layer 7 samo navázání spojení. Nullping, QuietException a záplavy falešných handshaků proti sítím Minecraftu nepotřebují téměř žádnou šířku pásma a položí celé svazky proxy serverů, protože každý paket nutí proxy k nákladnému rozhodnutí o stavu. Jak tyto vzory přesně vypadají, stojí v článku Ochrana Minecraftu proti DDoS a ochrana Nullping.

Srovnání tří úrovní

Skutečné útoky se tohoto rozdělení nedrží. V praxi nejnepříjemnějším případem je vícevrstvý útok: volumetrická část, která zaměstná linku, a k tomu část na Layer 7, která projde právě ve chvíli, kdy pozornost leží na šířce pásma. Jeden z útoků odfiltrovaných u KernelHost, ukázaných níže, se skládal z více než dvanácti různých hlavních vzorů současně.

Zesilovací útoky: jak se z jednoho bajtu stane 51 000

Zesilovací útok je útok, při kterém útočník nestřílí na cíl sám, ale přiměje cizí, veřejně dostupné služby, aby to udělaly za něj. Pošle malý dotaz na otevřenou službu a jako odesílatele uvede IP adresu oběti. Služba povinně odpoví, jenže oběti, a odpověď je násobkem dotazu.

Poměr mezi velikostí odpovědi a velikostí dotazu se jmenuje Bandwidth Amplification Factor, zkráceně BAF. Faktor BAF ve výši 50 znamená, že útočník s vlastní přípojkou 1 Gbit/s namíří na cíl 50 Gbit/s. Aby to fungovalo, musí se sejít dvě věci: protokol přes UDP, který odpovídá více, než kolik je dotázán, a možnost podvrhnout adresu odesílatele. Proto je podvrhování IP adres předpokladem každého zesilovacího útoku, a ne jen taktikou zakrytí stop.

Pro obránce z toho plyne nepříjemná vlastnost: provoz přichází ze skutečných, legitimních serverů. Jsou to reálné DNS resolvery, reálné časové servery, reálné herní servery. Seznam blokovaných adres podle zdrojové adresy tedy buď vyřadí půlku zemí, nebo nezabere.

Faktory zesílení zneužívaných protokolů

Následující faktory pocházejí z výstrahy TA14-017A od US-CERT, respektive CISA, „UDP-Based Amplification Attacks“, která se od roku 2014 průběžně rozšiřuje. Je referencí, na kterou se odvolává celý obor.

Tabulka vysvětluje, proč seznam blokovaných portů v každém dobře udržovaném firewallu vypadá podobně. To, co můžete udělat sami, je přehledné, ale důležité: zkontrolujte pomocí ss -lnup, zda na vašem serveru nestojí otevřeně v síti některá služba z této tabulky. Instance memcached, která není navázaná na 127.0.0.1, dělá z vašeho serveru zbraň proti třetím stranám, stojí vás vlastní odchozí šířku pásma a dostane vaši IP adresu na seznamy blokovaných adres, ze kterých se jen těžko dostává ven.

Proč sem patří i herní dotazovací protokoly

Herní servery stojí v této tabulce ve dvou rolích. Jsou zesilovači, protože jejich dotazovací port odpovídá na malý paket jménem, mapou, počtem hráčů a kompletním seznamem modů. A jsou obětí, protože tentýž dotaz stojí výpočetní čas, často přesně na tom jádru, které nese herní simulaci.

Faktor zesílení protokolu Steamu leží s hodnotou 5,5 nízko, u staršího protokolu Quake s hodnotou 63,9 vysoko. Účinek ale nezávisí jen na faktoru, nýbrž na velikosti odpovědi v jednotlivém případě: server s 200 mody dodá výrazně větší odpověď než server bez nich. Bohemia Interactive u Army 3 pod ticketem T83469 od roku 2015 dokumentuje, že ke zmrazení serveru stačily už 4 Mbit/s podvržených dotazů na Steam Query port. Čtyři megabity za sekundu jsou méně, než zvládne jediná domácí přípojka.

Z toho plyne pravidlo, které platí pro každou hru: dotazovací port omezovat, ne blokovat. Kdo ho zablokuje, zmizí ze seznamu serverů a noví hráči ho už nenajdou. Který port to u které hry je a jak těsně se smí vést, stojí v článcích k jednotlivým hrám níže, například pro Armu 3, CS2 a tituly na Source nebo Rust.

Případ memcached: 1,35 Tbit/s proti GitHubu

Dne 28. února 2018 byl GitHub od 17:21 do 17:26 UTC nedostupný a do 17:30 UTC jen občas dosažitelný. Útok dosáhl 1,35 Tbit/s při 126,9 milionu paketů za sekundu a přišel z více než 1 000 různých autonomních systémů a z desetitisíců jednotlivých koncových bodů. Zesílen byl přes memcached, s faktorem až 51 000: jeden bajt útočníka vytvořil až 51 kilobajtů směrem k cíli.

Tento případ je dodnes nejlepší školou, protože ukazuje tři věci najednou. Zaprvé: zesílení poráží velikost botnetu. Útočník nepotřeboval sto tisíc zařízení, potřeboval otevřené instance memcached, kterých tehdy stálo v síti po celém světě více než 90 000. Zadruhé: 126,9 milionu paketů za sekundu je zhruba 85krát víc, než kolik vůbec zvládne přenést linka s 1 Gbit/s. Žádné nastavení na serveru s tím nic neudělá. Zatřetí: obrana fungovala, protože byl provoz odkloněn do filtrační sítě a doba výpadku tak skončila na devíti minutách místo na devíti hodinách.

Odkud se bere kapacita pro DDoS útok

Botnety z převzatých zařízení

Botnet je svazek cizích zařízení převzatých škodlivým softwarem, která útočník centrálně ovládá na dálku. Majitelé o tom zpravidla nic nevědí, protože zařízení dál dělá to, kvůli čemu bylo koupeno. Napadána jsou hlavně zařízení, která visí trvale v síti, jen zřídka se aktualizují a nesou výchozí hesla: routery, kamery, síťové rekordéry, televizní boxy.

Měřítkem je Mirai, jehož zdrojový kód byl zveřejněn koncem září 2016. Práce „Understanding the Mirai Botnet“ (USENIX Security 2017) sleduje síť po sedm měsíců a vyčísluje maximum na více než 600 000 nakažených zařízení. Útok na stránku Briana Krebse v září 2016 dosáhl 620 Gbit/s a přišel z více než 175 000 zařízení. Při útoku na provozovatele DNS Dyn 21. října 2016, který současně znepřístupnil Twitter, Spotify a Reddit, bylo napočítáno zhruba 107 000 útočících IP adres.

O devět let později je řádová velikost jiná. Cloudflare rekordní útok s 31,4 Tbit/s připisuje botnetu s odhadovanou velikostí jednoho až čtyř milionů nakažených zařízení, převážně televizních boxů s Androidem. V útočné vlně z prosince 2025 bylo napočítáno 902 hypervolumetrických útoků, průměrně 53 denně, se špičkami 9 miliard paketů za sekundu, 24 Tbit/s a 205 milionů požadavků za sekundu. Velikost botnetu tak během jednoho desetiletí vzrostla o faktor 5, dosažená šířka pásma o faktor 50.

Služby booter a stresser a kolik útok stojí

Mezi botnetem a zadavatelem sedí služba, která útočnou kapacitu prodává v předplatném. Tyto služby vystupují jako „booter“, „stresser“ nebo „IP stresser“ a ve svých obchodních podmínkách tvrdí, že slouží k zátěžovým testům vlastních systémů. Nikdy přitom nekontrolují, zda zadaný cíl uživateli patří, a přesně v tom je rozdíl mezi nástrojem a nabídkou.

Ovládání je webové rozhraní se třemi poli: cíl, port, doba. Existují platební procesy, zákaznická podpora a programy pro další prodejce. Vstupní balíčky leží zhruba na 10 až 20 eurech měsíčně, větší balíčky s vyšší šířkou pásma a delší dobou útoku na několika stech eurech měsíčně. Tím je zodpovězena otázka, proč to potkává i malé projekty: útok, který herní server stojí sobotní večer, stojí toho, kdo ho spustí, méně než dvě vstupenky do kina a žádné technické znalosti.

Na druhé straně stojí trvalý tlak stíhání. V akčním týdnu mezinárodní operace PowerOFF v dubnu 2026 převzaly úřady z 21 zemí 53 domén takových služeb, zatkly čtyři osoby a provedly 25 domovních prohlídek. Vyšetřovatelé přitom získali přístup k datům více než tří milionů uživatelských účtů a více než 75 000 identifikovaných uživatelů bylo osloveno dopisem. V prosinci 2024 bylo v téže operaci odstaveno 27 platforem. Kdo takovou službu zaplatí, zanechává tedy platební stopu v databázi, která bude dřív nebo později zabavena.

Podle čeho DDoS útok poznáte

Co hlásí uživatelé a co to už vypovídá

První informace přichází téměř vždy od uživatelů a je použitelnější, než zní. Čtyři hlášení mají jasný význam:

• „Všichni vypadli naráz.“ Současné přerušení u všech uživatelů svědčí pro linku nebo pro proces služby, ne pro jednotlivá spojení. Problém se zátěží zasahuje uživatele postupně.
• „Ping skáče z 20 na 400 a zpátky.“ Kolísající doba průchodu při dál trvajícím spojení je vzorem přeplněné fronty před cílem, ne přetíženého procesu.
• „Seznam serverů nás ukazuje jako offline, ale já se připojit dokážu.“ To je ukazatel na záplavu dotazů: dotazovací port už neodpovídá, herní port ještě ano.
• „Přes mobilní data se dostanu dovnitř, přes svou přípojku ne.“ Odlišné chování podle přístupové sítě naznačuje, že není nasycený váš server, ale jedna z cest k němu.

Čtyři naměřené hodnoty na serveru

Potom se měří, a to v tomto pořadí: paketová rychlost, šířka pásma, stavy spojení, čítače zahozených paketů. Ukazatel vytížení CPU přijde na řadu jako poslední, protože při síťovém útoku zůstává často nenápadný.

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 dodá pakety a bajty za sekundu na jednotlivá rozhraní za deset sekund. Rozhodující je poměr: mnoho paketů při málo bajtech znamená malé pakety, tedy protokolový útok. Málo paketů při velmi mnoha bajtech znamená velké pakety, tedy zesilovací útok. ip -s link show ukazuje ve sloupcích dropped a overrun, zda už jádro zahazuje. ss -tn state syn-recv počítá polootevřená spojení: trojmístná hodnota je normální, pětimístná je záplava SYN. A nstat dodá čítače, které zůstanou, i když je útok pryč.

Nejdůležitější krok je ten, který skoro nikdo předem neudělá: založit si srovnávací základnu, dokud všechno běží normálně. Bez normální hodnoty nedokážete říct, jestli je 40 000 paketů za sekundu hodně, nebo jestli je prostě sobotní večer. S apt-get install -y vnstat sysstat běží měření trvale. Podrobný návod k vyhodnocení stojí v článku Jak poznat DDoS útok.

Řádky logu, které jsou jednoznačné

Čtyři hlášení v logu jádra a v logu webového serveru jsou prakticky průkazná. dmesg -T | tail -50 ukáže první tři:

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

První řádek znamená, že fronta polootevřených spojení přetekla a jádro přepnulo na SYN cookies. Stojí-li tam místo toho Dropping request, je net.ipv4.tcp_syncookies nastaveno na 0 a server zahazuje dotazy včetně těch skutečných. Druhý řádek znamená, že je sledování spojení plné, a od této chvíle server zahazuje i legitimní provoz. Třetí řádek je vedlejším efektem: jádro potlačuje hlášení, protože by se jinak zabývalo logováním. Čtvrtý řádek přesouvá problém do aplikace.

V přístupovém logu webového serveru jsou vypovídající dvě věci. Náhlý podíl stavového kódu 499 znamená, že klient spojení zavírá dřív, než je odpověď hotová, a přesně to dělá útok na Layer 7, který chce jen vyvolat práci a ne ji číst. A prázdné pole referrer u téměř všech požadavků odlišuje útok od skutečného náporu návštěvníků, který referrer z vyhledávačů a sociálních sítí přináší s sebou.

Zkouška naopak: útok, nápor, nebo vlastní chyba

Co pomáhá na serveru samotném

Na serveru se dá dosáhnout víc, než se často tvrdí, a to proti všemu, co zůstává malé: nečistým botům, jednotlivým zdrojům, záplavám dotazů a aplikačním útokům. Nástroji k tomu jsou nftables, sledování spojení, SYN cookies a omezení rychlosti podle zdrojové adresy. Všechny následující údaje platí pro Debian 12, Debian 13, Ubuntu 22.04 LTS a Ubuntu 24.04 LTS a jsou psané pro uživatele root.

nftables: zahazovat brzy, počítat málo

Zásada zní: paket, který má být zahozen, má být zahozen co nejdřív a co nejlevněji. Každé pravidlo, které běží před ním, stojí výpočetní čas krát paketová rychlost. Následující sada pravidel pro /etc/nftables.conf propustí webový server a jednu herní službu a zbytek zahodí, s omezením rychlosti pro nová TCP spojení podle zdrojové adresy:

#!/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; }
}

Do adminips zapište svou vlastní pevnou adresu, než sadu načtete, jinak se sami vyzamknete z SSH. Zkontroluje a aktivuje se takto:

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

O účinku rozhodují tři body. ct state established,related accept stojí záměrně jako druhé pravidlo, aby stávající spojení neprobíhala celou sadou pravidel. ct state invalid counter drop odstraní chybné kombinace příznaků a opožděné fragmenty, aniž byste je museli popisovat jednotlivě. A counter před každým drop je důvod, proč pak víte, které pravidlo zabralo: zůstanou-li čítače na nule, pravidlo se nedostane ke slovu, a to je úplně jiná diagnóza než neúčinná sada pravidel.

SYN cookies a hranice fronty backlog

SYN cookies jsou postup, při kterém si server polootevřené spojení nepamatuje, ale potřebné údaje zašifrovaně zapíše do vlastního čísla odpovědi. Přijde-li třetí paket navázání spojení zpět, vypočítá z něj stav znovu. Tím fronta už nepřetéká, protože pro tato spojení žádná fronta neexistuje.

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

Tyto hodnoty patří do souboru pod /etc/sysctl.d/ a přebírají se příkazem sysctl --system, jinak jsou po příštím restartu pryč. Na Debianu a Ubuntu stojí tcp_syncookies od výroby na 1, což je správně. Hodnota 1 neznamená „vždy cookies“, nýbrž „cookies, jakmile fronta přeteče“.

Cena za to je reálná a málokdy se zmiňuje. V cookie není místo pro TCP volby protistrany. Linux zachrání zvětšení okna a selektivní potvrzování jen tehdy, když net.ipv4.tcp_timestamps stojí na 1, protože tyto údaje pak cestují v časovém razítku. Bez časového razítka odpadnou a spojení běží po zbytek své životnosti pomaleji. Kromě toho jsou pro maximální velikost paketu k dispozici jen tři bity, tedy osm hrubých stupňů místo přesné hodnoty. SYN cookies jsou nouzový provoz, který zachraňuje spojení, ne nastavení pro běžný případ.

conntrack: tabulka, která se naplní jako první

Sledování spojení v jádře zakládá záznam pro každý tok paketů, i pro UDP, ačkoli UDP spojení nezná. Právě tato tabulka je při distribuovaném útoku prvním prostředkem, který dojde, a dochází velmi rychle: při 1,49 milionu paketů za sekundu s pokaždé novou adresou odesílatele je tabulka s 262 144 místy naplněná za méně než pětinu 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 záznam zabírá zhruba 300 bajtů, 524 288 záznamů tedy asi 150 megabajtů paměti jádra. Velikost hashovací tabulky se nenastavuje přes sysctl, nýbrž jako parametr modulu, obvykle na čtvrtinu horní meze, v souboru /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

U čistě herního nebo hlasového serveru je elegantnějším řešením nenechat herní provoz vůbec sledovat. To ušetří tabulku úplně:

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

Pozor: notrack a stavová pravidla se vzájemně vylučují. Kdo některý port ze sledování vyjme, nesmí pro tento port už použít žádné pravidlo s ct state, jinak povolení přestane platit a služba je zavřená.

Omezení rychlosti podle zdrojové adresy

Omezení rychlosti podle zdrojové adresy je nejúčinnějším jednotlivým opatřením na serveru, protože trefí přesně to, co dělá útočník, a propustí přesně to, co dělá uživatel. Rozdíl je velký: skutečný prohlížeč serverů se ptá několikrát za minutu, útočník stokrát za sekundu. S nftables se k tomu pracuje s dynamickými množinami jako v sadě pravidel výše, s klasickým iptables s 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

Všechna čísla v takových pravidlech jsou výchozí hodnoty, ne pravdy. Měřte nejdřív týden v normálním provozu, jinak vyhodíte vlastní uživatele, a to v nejhorší možné chvíli. Počítejte kromě toho s tím, že samotná pravidla iptables jsou po restartu pryč (apt-get install -y iptables-persistent, pak netfilter-persistent save) a že pod UFW patří do /etc/ufw/before.rules, protože jinak při příštím ufw reload zmizí. Úplná sada pravidel pro běžný provoz stojí v článku Jak ochránit server před DDoS útoky.

Kde každá filtrace na serveru končí

Teď část, kterou nevyřeší žádný konfigurační soubor. Všechna dosavadní opatření běží na vašem serveru, tedy na konci linky. Pravidlo firewallu rozhoduje o paketu, který už po kabelu proběhl. Můžete ho zahodit, ale nemůžete ho udělat neodeslaným. Je-li linka před ním plná, pakety vašich uživatelů se nedostanou skrz už dřív, a to nezávisle na tom, jak dobrá je vaše sada pravidel.

Tato tabulka zodpovídá otázku, zda vlastní ochrana stačí, pro každý jednotlivý případ. Útok na GitHub se 126,9 milionu paketů za sekundu se v paketové rychlosti těsně vejde na přípojku se 100 Gbit/s, při objemu 1,35 Tbit/s by jich ale bylo potřeba čtrnáct současně. Rekordní útok s 31,4 Tbit/s odpovídá 314 zcela nasyceným přípojkám se 100 Gbit/s. Herní server visí typicky na 1 Gbit/s nebo na dvakrát 1 Gbit/s: hranice vlastní ochrany tak leží zhruba na 1,5 až 3 milionech paketů za sekundu, a prakticky výrazně níž, protože jádro to vzdá dřív.

Existuje ještě druhá, nepříjemnější hranice. Jakmile je linka nasycená, nemusí se k vám za určitých okolností dostat ani relace SSH, kterou jste chtěli měřit. Kdo pak nemá přístup nezávislý na síti, například konzoli VNC v zákaznické sekci, se už ani nemůže podívat, co se děje.

Co pomáhá jen před serverem: filtrace v síti a scrubbing

Účinně filtrovat může jen ten, kdo má větší kapacitu než útok. To předpokládá místo, kde se sbíhá mnoho linek, tedy síť, ne jeden stroj. Tam existují dva postupy, které se doplňují.

Filtrace v síti v reálném čase. Veškerý provoz běží trvale přes filtrační stupeň, který každý paket vyhodnotí, než ho pustí dál k serveru. Výhodou je, že neexistuje žádné přepnutí: ochrana nemusí útok nejdřív rozpoznat, aby zabrala. Přesně to rozhoduje u her, protože doba přepnutí dvou minut je ztracené kolo, a doba přepnutí dvou minut u útoku, který trvá 35 sekund, není obranou vůbec.

Scrubbing. Rozpozná-li síť velký volumetrický útok, je dotčený provoz odkloněn do filtračních center, tam zbaven škodlivých podílů a následně doručen směrem k cíli. Smyslem tohoto odklonu je blízkost: útočný provoz končí tam, kde vstupuje, místo až u datacentra. Filtrační pravidla se k tomu rozesílají v síti, technicky popsáno v RFC 8955 jako Flow Specification.

Strukturálním protiopatřením proti podvrženým adresám odesílatele je mimochodem postup známý už od roku 2000, uvedený v RFC 2827, tedy v BCP 38: kdo připojuje zákazníka, zahazuje na této hranici všechny pakety, jejichž adresa odesílatele tomuto zákazníkovi nepatří. RFC 3704 to rozšiřuje na vícenásobně připojené sítě. Kdyby to zavedli všichni provozovatelé sítí, byla by celá třída zesilovacích útoků vyřízená. Není, protože stačí, že to někteří nedělají.

A existuje třetí metoda, kterou je nutné znát, protože se často prodává jako ochrana: nullrouting, technicky Remote Triggered Black Hole Filtering podle RFC 5635. Napadená IP adresa se přitom v síti ohlásí jako nedosažitelná a veškerý provoz k ní se zahazuje, útočný stejně jako provoz vašich uživatelů. To chrání síť poskytovatele, pro vás je výsledek totožný s úspěšným útokem, a většinou ještě hodiny poté. V případě pochybností se ptejte, zda se filtruje, nebo nulluje. Odpověď rozhoduje o vaší dostupnosti víc než jakýkoli údaj o hardwaru.

Co proti tomu staví KernelHost

Trvalá ochrana, která je v ceně každého serveru

Ochrana proti DDoS od KernelHost je postavená dvoustupňově a je trvale aktivní, aniž byste museli cokoli zapínat, objednávat nebo konfigurovat:

• Stupeň 1: 17 Tbps mitigační kapacity v globální scrubbingové síti. Volumetrické útoky se čistí blízko svého zdroje, ještě než dorazí do datacentra.
• Stupeň 2: filtrace Arbor v reálném čase s 3,2 Tbps ve Frankfurtu nad Mohanem. Přímo před serverem se rozpoznávají a zahazují vzory specifické pro jednotlivé protokoly, paket po paketu.

Rozhodující jsou dvě vlastnosti. Ochrana běží trvale a je aktivní od zřízení serveru, nejsou tedy žádné minuty na začátku útoku, kdy je služba pryč. A nepoužívá se nullrouting: vaše IP adresa zůstává v síti, zahazují se jen škodlivé pakety. Které hry a protokoly mají vlastní filtrační profily, vypisuje článek Ochrana herních serverů proti DDoS v reálném čase.

Advanced DDoS Protection pro trvale ostřelované projekty

Některé projekty nejsou napadány příležitostně, ale cíleně a celé týdny, každý večer ve stejnou dobu a se střídajícími se vzory. Pro takové případy existuje Advanced DDoS Protection od 50,00 € měsíčně, PrePaid, bez minimální doby trvání a bez zřizovacího poplatku. Rozdíl neleží ve větší kapacitě, ale v kontrole:

• Dedikovaná chráněná IP z frankfurtského jádra, na kterou se váš server ve vlastní síti přepne. Na vaší straně není žádná přestavba nutná.
• Vlastnoručně spravovatelná ochranná pravidla podle portu a protokolu v zákaznické sekci: nastavíte odděleně, co je povolené na herním portu a co na dotazovacím portu, a můžete tak využít přesně tu asymetrii z oddílu o dotazovacích protokolech.
• Změny se projeví v reálném čase, můžete tedy doladit nastavení i během probíhajícího útoku, místo abyste čekali na servisní okno.
• Ochranný profil odpovídající dané službě, stejně tak pro upravené a vlastní aplikace na libovolných TCP nebo UDP portech.

Advanced DDoS Protection je určena zákazníkům KernelHost a předpokládá server u KernelHost. Pokud váš projekt momentálně běží jinde a je tam pravidelně pod útokem, je cestou přesun sem, ne vzdálená správa vaší dosavadní adresy.

Srovnání obou stupňů

Čtyři skutečně odfiltrované útoky z provozu

Následující čtyři útoky zasáhly servery zákazníků KernelHost a byly zcela odfiltrovány v reálném čase, pokaždé bez výpadku. Obrázky pocházejí z živého monitoringu obrany.

Hlasový server TeamSpeak 3, port 9987 UDP. Komplexní útok s několika současnými vzory, přes 473,4 Gbit/s a přes 41,5 milionu paketů za sekundu. To je zhruba 28násobek paketové rychlosti přípojky s 1 Gbit/s.

Herní server ARK, port 7777 UDP. Jednoduchý UDP flood bez složité struktury, zato přes 112,2 Gbit/s a přes 8,7 milionu paketů za sekundu. Jak se vedle toho zabezpečuje samotný cluster ARK, stojí v článku Ochrana serveru ARK před DDoS útoky.

Útok na všechny porty, porty 0-65535 TCP a UDP. Přes dvanáct různých hlavních útočných vzorů proti všem portům současně, celkem přes 21,3 Gbit/s a přes 3,9 milionu paketů za sekundu. Tento případ ukazuje rozprostření přes všechny porty, které vykazuje i případ Cloudflare z května 2025 s průměrně 21 925 cílovými porty.

Minecraft a OpenVPN, porty 25565 TCP a 1194 UDP. Kombinovaný útok s více než šestnácti různými hlavními útočnými vzory, přes 4 miliony paketů za sekundu a přes 8,6 Gbit/s. Obě služby zůstaly trvale dosažitelné, ačkoli mluví různými protokoly.

Co dělat při útoku, a to v tomto pořadí

Pořadí je důležitější než jednotlivé kroky, protože nejčastější chyby se dějí v prvních pěti minutách.

1. Měřit, ne šroubovat. Zajistěte si nejdřív hodnoty z sar -n DEV 1 10, ip -s link show, ss -s a dmesg -T do souboru. Po útoku budou pryč a bez nich vám nikdo nepomůže.
2. Nerestartovat. Restart smaže všechny čítače, všechny stavy spojení a každý důkaz, a zátěž je po pár sekundách zase zpátky.
3. Zjistit, o kterou úroveň jde. Bajty děleno pakety dají průměrnou velikost paketu. Pod 100 bajtů ukazuje na protokolový útok, nad 1 000 bajtů na zesilovací útok, normální velikosti při vysokém vytížení CPU na Layer 7.
4. Zavřít správní porty. Panel, databáze, RCon a všechno, co nemusí být veřejné, patří omezit na vaši vlastní adresu. To okamžitě zmenší útočnou plochu a bez rizika pro uživatele.
5. Nastavit omezení rychlosti, těsně na dotazovací port, volně na užitný port. Neblokujte dotazovací port, jinak zmizíte z každého seznamu serverů.
6. Neměnit unáhleně vlastní adresu. Změna adresy zabere jen do chvíle, než nová adresa zase veřejně stojí, a zapomenutý starý záznam DNS udělá změnu bezúčinnou.
7. Zapojit poskytovatele s čísly. Otevřete ticket s časem, cílovým portem, paketovou rychlostí, šířkou pásma a průměrnou velikostí paketu. Těchto pět údajů rozhoduje o tom, jak rychle se filtrační pravidla pro vaši adresu doladí.
8. Potom dokumentovat. Zapište si, kdy to začalo, jak dlouho to trvalo a o jaký vzor šlo. Opakující se útoky ve stejnou hodinu jsou kritériem toho, zda projekt potřebuje dedikovanou chráněnou IP.

Podrobný postup pro těžký, déle běžící útok stojí v článku Vážný DDoS útok: co dělat?.

Právní stav: DDoS útok je trestný čin

V Rakousku spadá DDoS útok pod § 126b rakouského trestního zákoníku (StGB), „Störung der Funktionsfähigkeit eines Computersystems“, tedy narušení funkčnosti počítačového systému. Základní skutková podstata počítá s trestem odnětí svobody až do šesti měsíců nebo s peněžitým trestem až do 360 denních sazeb. Trvá-li narušení delší dobu, jsou to až dva roky. Je-li napadeno mnoho systémů programem, který byl zjevně k tomu účelu vytvořen, jsou to až tři roky. A při škodě nad 300 000 eur, při útoku na kritickou infrastrukturu nebo jako člen zločinného spolčení leží sazba mezi šesti měsíci a pěti lety. Doplňkově staví § 126c rakouského StGB pod trest už samotné vytváření, šíření a zpřístupňování programů k tomu určených.

V Německu se uplatní § 303b německého trestního zákoníku (StGB), „Computersabotage“, tedy počítačová sabotáž: až tři roky odnětí svobody nebo peněžitý trest, až pět let, slouží-li zpracování dat provozovně, podniku nebo úřadu, a ve zvlášť závažných případech šest měsíců až deset let, například při jednání za účelem zisku nebo při narušení kritické infrastruktury. Pokus je trestný a u přípravných jednání odkazuje § 303b odst. 5 německého StGB na § 202c StGB.

Služby booter a stresser proto nejsou šedou zónou, ale placenou částí trestného činu. Tři body bývají přitom pravidelně nepochopeny. Zaprvé, poznámka „jen pro zátěžové testy vlastních systémů“ nic nelegalizuje, protože služby nekontrolují, komu zadaný cíl patří. Zadruhé, trestně odpovědný je i zadavatel, ne jen provozovatel: Europol po akčním týdnu v dubnu 2026 výslovně oslovil dopisem více než 75 000 identifikovaných uživatelů, aby to objasnil. Zatřetí, ani zátěžový test na vlastní server přes takovou službu není řešením, protože útočný provoz jde sítí poskytovatele a tím po linkách ostatních zákazníků, což každá hostingová smlouva zakazuje. Kdo chce odolnost své služby skutečně změřit, dělá to ohlášeně a po dohodě s poskytovatelem. Tento oddíl podává stav zákonů a není právním poradenstvím.

Vhodný návod pro vaši službu

Tento článek vysvětluje princip. Který port patří otevřít, která konfigurační direktiva omezuje který dotaz a kde leží hranice u konkrétní hry: to stojí v článcích k jednotlivým službám, pokaždé s faktografickou tabulkou portů.

• Základy a postup: Jak poznat DDoS útok, Jak ochránit server před DDoS útoky, Vážný DDoS útok: co dělat?, Ochrana her proti DDoS s filtrací v reálném čase
• Minecraft a hlas: Minecraft a Nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Hraní rolí na základech GTA: FiveM, RedM, RAGE MP a alt:V, SA-MP a open.mp, MTA:SA
• Přežití a budování: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Taktika a střelba: CS2 a Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Stručné shrnutí

• DDoS útok obsadí jeden ze čtyř konečných prostředků: šířku pásma, paketovou rychlost, stavovou tabulku jádra nebo výpočetní čas aplikace. Nevyužívá bezpečnostní chybu, proto samotné aktualizování nechrání.
• RFC 4732 definuje DoS útok přes účinek, ne přes počet zdrojů. Distribuovaný se jmenuje tehdy, jsou-li zdroje početné: v případu Cloudflare z května 2025 to bylo 122 145 adres ze 161 zemí.
• CISA, FBI a MS-ISAC rozlišují tři techniky: volumetrickou v Gbit/s, protokolovou v paketech za sekundu, aplikační v požadavcích za sekundu. Každá potřebuje jinou obranu.
• Zesilovací útoky zneužívají otevřené UDP služby. Faktory sahají od 5,5 u protokolu Steamu přes 30,8 u SSDP a 556,9 u NTP až po 51 000 u memcached, k dohledání ve výstraze US-CERT TA14-017A.
• Kapacita přichází z botnetů převzatých zařízení, od 600 000 u Mirai v roce 2016 až po odhadovaný jeden až čtyři miliony za rekordním útokem s 31,4 Tbit/s, a prodává se dál od zhruba 10 eur měsíčně.
• Na serveru zabírají nftables, SYN cookies, upravené meze conntracku a omezení rychlosti podle zdrojové adresy. Končí zhruba na 1,5 milionu paketů za sekundu, protože přípojka s 1 Gbit/s víc nepřenese.
• Nad touto hranicí rozhoduje výhradně filtrace v síti před serverem. Nullrouting není obranou, ale výsledkem, který útočník chtěl.
• U KernelHost je dvoustupňová trvalá ochrana obsažena v každém serverovém balíčku bez příplatku a je aktivní od zřízení serveru, bez nullroutingu: 17 Tbps mitigační kapacity v globální scrubbingové síti plus filtrace Arbor v reálném čase s 3,2 Tbps ve Frankfurtu nad Mohanem. Advanced DDoS Protection ji od 50,00 € měsíčně doplňuje o dedikovanou chráněnou IP a vlastnoručně spravovatelná pravidla podle portu.
• DDoS útok je v Rakousku trestný podle § 126b StGB a v Německu podle § 303b StGB, pro zadavatele stejně jako pro provozovatele těchto služeb.

Běží-li váš projekt už u KernelHost, je filtrace aktivní, aniž byste museli cokoli dělat. Pokud přesto zaznamenáte nesrovnalosti, otevřete ticket na podporu s pěti údaji z kroku 7, aby se filtrační pravidla pro vaši IP adresu doladila. Během probíhajícího útoku nás navíc zastihnete přes nouzový chat na WhatsAppu na čísle +43 650 8209883.