Co je SYN flood útok jednoduše řečeno?

Je to záplava požadavků na spojení, které se schválně nikdy nedokončí. TCP navazuje spojení ve třech krocích a útočník posílá jen ten první, takže server rezervuje prostředky pro tisíce spojení, která nikdy nevzniknou. Když je fronta s nedokončenými handshaky plná, noví návštěvníci se nepřipojí vůbec — ne proto, že by server spadl, ale protože mu nezbylo místo, kam je přijmout.

Jak se SYN flood liší od amplifikačního DDoS útoku?

Lámou různé věci. Amplifikační záplava zahltí velkými odraženými odpověďmi vaše pásmo, takže obětí je linka. SYN flood spotřebovává stav spojení drobnými pakety a dokáže položit server při bitovém toku, kterého si uplink ani nevšimne. Poznávacím znamením je poměr: hodně paketů za sekundu při plochém přenosu ukazuje na SYN flood, vytížené pásmo při běžné paketové rychlosti na amplifikaci.

Zastaví SYN cookies SYN flood?

Zařídí, aby selhávajícím místem přestal být backlog, což je skutečné a užitečné zlepšení. Záplavu nezastaví. Pakety pořád dorazí na linku a jádro pro každý z nich počítá a ověřuje kryptografickou hodnotu, takže při vysokých paketových rychlostech se úzké hrdlo přesune z paměti na procesor a síťovou kapacitu. Zapněte je — a počítejte s tím, že dost velká záplava bude stejně potřebovat filtraci před vaším serverem.

Proč při SYN floodu vypadá přenos normálně?

Protože SYN pakety mají kolem 60 bajtů. Milion za sekundu — dost na položení většiny originů a stavových firewallů — je zhruba půl gigabitu, což se na moderním uplinku sotva projeví. Právě tenhle nesoulad je důvod, proč se SYN floody tak často diagnostikují jako chyba serveru: graf, do kterého se všichni podívají první, je ten, se kterým útok nehne.

Dokáže SYN flood zastavit firewall?

Firewall před serverem obvykle padne dřív než samotný server. Každý příchozí SYN zakládá záznam ve sledování spojení, takže stavový firewall brání tabulku, kterou je záplava přesně navržená vyčerpat — a pakety už spotřebovaly linku ve chvíli, kdy jakékoli pravidlo vyhodnocuje. Pravidla na firewallu mají smysl proti menším záplavám a přímým útokům ze skutečných adres; obranou proti distribuovanému útoku nejsou.

Co je SYN-ACK reflexní útok?

Útočník pošle SYN pakety na tisíce běžných veřejných serverů a jako zdroj do nich podvrhne vaši IP adresu. Ty servery odpovědí SYN-ACK pakety mířenými na vás a protože se nedočkají odpovědi, několikrát je zopakují. Výsledkem je záplava, v níž každá zdrojová adresa patří nevinné třetí straně, takže blocklisty jsou k ničemu — jedinou reálnou obranou je filtrace upstream, která nevyžádaný SYN-ACK provoz zahodí dřív, než dorazí na vaši linku.

Chrání CDN nebo reverzní proxy proti SYN floodům?

Chrání, pokud platí dvě podmínky. Proxy musí sama ukončovat TCP handshake, aby podvržený SYN nešlo dokončit a nikdy se z něj nestalo spojení k vašemu originu. A váš origin musí být zafirewallovaný tak, aby přijímal provoz jen ze sítě té proxy — útočník, který se pořád dostane přímo na IP vašeho serveru, tam záplavu prostě namíří a ochranu úplně obejde.

Jak zjistím, jestli jsem právě pod SYN floodem?

Spusťte „ss -n state syn-recv | wc -l" a sledujte to číslo. Tisíce polootevřených spojení, řádek v dmesg o možném SYN floodu na vašem portu, vysoká paketová rychlost při běžném přenosu a nezvykle tichý log aplikace dohromady případ uzavírají. Nejsilnější signál je to ticho v logu: při SYN floodu požadavky nikdy nedorazí, protože se vůbec nenaváže spojení.

Co je SYN flood útok? Záplavy TCP handshaků vysvětlené

V handshaku je mezera

Každé TCP spojení začíná třemi pakety. Klient pošle SYN. Server odpoví SYN-ACK a rezervuje stav pro spojení, které ještě neexistuje. Klient potvrdí ACK a teprve pak je spojení navázané a předané vaší aplikaci.

Mezera je v prostředním kroku. Mezi odesláním SYN-ACK a přijetím ACK drží server polootevřené spojení: strukturu v jádře ve frontě pevné velikosti — SYN backlogu — a čeká na třetí paket, který nemusí přijít nikdy. SYN flood není nic jiného než rozhodnutí ho neposlat.

Útočník posílá SYN za SYN a všechny odpovědi ignoruje. Každý zabere jedno místo. Linux ve výchozím nastavení opakuje SYN-ACK pětkrát s odstupem 1, 2, 4, 8, 16 a 32 sekund, takže jediný zapomenutý paket drží místo zhruba minutu. Jakmile se backlog naplní, jádru nezbývá než příchozí SYN pakety zahazovat — včetně těch od skutečných návštěvníků. Ti přitom nevidí chybovou stránku. Neozve se vůbec nic a prohlížeč se točí, dokud to nevzdá. Proto se SYN flood nejčastěji hlásí jako „web je dole", ne jako útok.

Celý útok je o ekonomice

	Útočník platí	Vy platíte
Za jeden handshake	Jeden paket o ~60 bajtech	Strukturu v jádře drženou až ~63 sekund
Držený stav	Žádný — paket odejde a je zapomenutý	Jedno místo v backlogu a záznam v conntracku na každém stavovém firewallu v cestě
Vykonaná práce	Vystřelit a zapomenout	Až pět opakování `SYN-ACK` odeslaných do prázdna
Identita	Zdrojová adresa, kterou lze rovnou podvrhnout	Místo, které teď nedostane skutečný návštěvník

Každý řádek běží proti obránci a backlog je z podstaty malý: pár tisíc míst na vyladěném serveru, pár set na výchozí instalaci nebo malém VPS. Proto SYN floody přežily třicet let záplatování — není tu žádná chyba k opravě. Útočník používá TCP přesně podle specifikace a jen ho odmítá dokončit.

Graf přenosu vám neřekne nic

Tohle uprostřed incidentu mate nejvíc. SYN paket má na drátě kolem 60 bajtů, takže se záplava měří v paketech za sekundu, ne v gigabitech — a graf provozu, do kterého se všichni podívají první, zůstává uklidňujícím způsobem plochý, zatímco server odmítá spojení.

SYN paketů/s	Zhruba	Co obvykle padne první
10 000	~5 Mbps	Nevyladěný backlog na výchozím serveru nebo malém VPS
100 000	~50 Mbps	Tabulky sledování spojení na stavovém firewallu; většina originů
1 000 000	~0,5 Gbps	Firewally a load balancery střední třídy; cokoli se stavem na paket
10 000 000	~5 Gbps	Všechno kromě filtrace na plné rychlosti linky upstream

Půl gigabitu je na moderním uplinku zaokrouhlovací chyba a pro tabulku spojení konec světa. Pokud si z téhle stránky máte odnést jednu věc, tak tuhle: při SYN floodu rozhoduje počet paketů za sekundu — a většina dashboardů ho nezobrazuje.

Čtyři podoby téhož útoku

Varianta	Co k vám dorazí	Proč ji útočníci používají
Přímý SYN flood	`SYN` pakety ze skutečných adres botnetu	Nejjednodušší na spuštění — a jediná varianta, kde má blokování zdrojů smysl
Podvržený SYN flood	`SYN` pakety s falešnou zdrojovou adresou	Není co blokovat a vaše `SYN-ACK` odpovědi navíc letí na nezúčastněné cizí adresy
SYN-ACK reflexe	`SYN-ACK` pakety z tisíců legitimních serverů	Útočník podvrhne vaši adresu vůči veřejným TCP službám; záplavou se stanou jejich odpovědi a opakování a každý zdroj je nevinný
ACK, RST nebo FIN flood	Pakety, které neodpovídají žádnému vašemu spojení	Každý vynutí vyhledání ve stavové tabulce a bezstavový filtr je nerozezná od provozu uprostřed spojení

Poslední řádek stojí za pozornost, protože je zrcadlem toho prvního. SYN flood útočí na cenu navázání spojení, ACK flood na cenu jeho vyhledání. Obrana nastavená jen na první z nich pustí druhý rovnou na zařízení, které jste chránili.

Hraniční případ jsou vycpané SYN pakety: totéž zneužití handshaku, ale s paketem nafouknutým k MTU, takže vyčerpává stav i pásmo zároveň. Tím se z toho stává i objemový útok a každou z těch dvou věcí je potřeba pohltit jinde.

Jak SYN flood potvrdit

Než cokoli změníte, věnujte dvě minuty tomu, abyste věděli, na co se díváte:

Spočítejte polootevřená spojení. ss -n state syn-recv | wc -l na Linuxu. Tisíce rostoucích záznamů jsou charakteristický podpis. Na starších systémech totéž udělá netstat -ant | grep SYN_RECV.
Přečtěte si log jádra. dmesg hlásící „Possible SYN flooding on port 443. Sending cookies." vám to říká rovnou — a zároveň říká, že backlog už přetekl.
Podívejte se i do tabulky firewallu. nf_conntrack: table full, dropping packet znamená, že padl stroj před aplikací. Je to běžné a snadno se to zamění za chybu serveru.
Porovnejte paketovou rychlost s přenosem. Velký nárůst paketů za sekundu při plochém bitovém toku je téměř diagnostický. Opak — vytížené pásmo při běžné paketové rychlosti — ukazuje spíš na amplifikaci.
Zkontrolujte log aplikace. Při SYN floodu je ticho, protože požadavky nikdy nedorazí: spojení se nenaváže. Pokud je naopak přístupový log plný věrohodně vypadajících požadavků, jde o útok na Layer 7 — jiný problém s jinou odpovědí.

Právě poslední kontrola odliší obě rodiny rychleji než cokoli jiného. Když se splete, lidé ladí pravidla WAF, zatímco paketová záplava drží origin nedostupný dál.

Co zvládnete na vlastním serveru

Tohle stojí za nastavení na každém stroji v internetu, hned teď, ještě než se něco stane. A zároveň to samo o sobě nestačí — což je smyslem následující kapitoly.

Zapněte SYN cookies. net.ipv4.tcp_syncookies = 1 je nejúčinnější lokální obrana. Jádro místo ukládání stavu polootevřeného spojení zakóduje stav do sekvenčního čísla, které posílá zpět: hash čtveřice adres a portů, tajného klíče a hrubého času, plus index do malé tabulky hodnot MSS. Nealokuje se žádná paměť. Když závěrečný ACK dorazí, číslo, které potvrzuje, spojení zrekonstruuje; když nedorazí, nic se neutratilo. Cena je reálná, ale mírná — tabulka MSS je hrubá a TCP volby jako window scaling a SACK přežijí jen se zapnutými časovými značkami — proto se cookies zapínají až při přetečení backlogu, ne pro každé spojení.

Nastavte fronty vědomě. net.ipv4.tcp_max_syn_backlog řídí polootevřená spojení, net.core.somaxconn a parametr, který vaše aplikace předá do listen(), řídí navázaná spojení čekající na převzetí. Velkorysý SYN backlog před aplikací, která přijímá pomalu, jen přesune frontu, jež přeteče.

Uvolňujte místa rychleji. Snížení net.ipv4.tcp_synack_retries z 5 na 2 zkrátí dobu, po kterou mrtvý handshake drží místo, z asi 63 sekund na zhruba 7. Ztratíte kus tolerance k opravdu ztrátovým klientům a získáte zhruba devětkrát rychlejší obrátku míst.

Nesledujte, co sledovat nemusíte. Každý SYN zakládá na stavovém firewallu záznam a nf_conntrack_max bývá první strop, na který narazíte. Zvyšte ho a snižte timeout syn_recv, nebo veřejný naslouchající port ze sledování úplně vyjměte pravidlem notrack a nechte validaci handshaku na samotném TCP stacku jádra.

Omezte rychlost nových spojení na zdroj v nftables nebo iptables. Proti přímé záplavě ze skutečných adres to pomůže, proti podvržené skoro vůbec — není tu stabilní zdroj, který by šlo omezovat.

Dohromady tím zvednete paketovou rychlost, kterou přežijete, možná o řád. Nic z toho ale nemění to podstatné: pakety pořád dorazí na váš uplink a pořád je vyhodnocuje váš procesor. Každé přidané pravidlo je práce odvedená na každý útočný paket, na hardwaru, který útočník přeplatí za pár eur na hodinu. Jakmile provoz dorazí na vaši linku, pásmo je utracené — podrobněji v článku co je DDoS mitigace.

Kde se SYN flood skutečně zastaví

Upstream a v konkrétním pořadí — nejlevnější rozhodnutí první, protože obrana, která stojí na paket víc než útok, je jen pomalejší způsob, jak prohrát:

Kapacita k pohlcení v páteřní síti. Záplava musí dopadnout někam, kde je pro ni místo, ještě před poslední mílí, která vede k vám.
Bezstavová filtrace na plné rychlosti linky. Podvržený, poškozený nebo protokol porušující paket lze zahodit na první pohled, přímo v ovladači síťové karty, dřív než se pro něj alokuje paměť. Tady se řeší desítky milionů paketů za sekundu a běžný server to sám za sebe neumí.
Validace handshaku na edge. Ochranný edge dokončí TCP handshake sám za sebe. K vašemu originu se dostane jen klient, který odpoví správně — tedy skutečný TCP stack na skutečné adrese. Podvržený SYN nemůže handshake dokončit s nikým, takže záplava končí na edge z principu.
Stropy na rychlost nových spojení ze zdroje, aby jedna adresa nespotřebovala rozpočet handshaků, i když jsou její pakety jinak validní.
Zahazování prokázaných útočníků v jádře, takže už jednou odsouzený zdroj nestojí za paket nic.

A jeden předpoklad mimo tento seznam, protože potichu ruší všechno ostatní: váš origin musí být nedostupný jinudy než přes ochrannou síť. Pokud útočník pořád může posílat pakety na skutečnou IP vašeho serveru, žádná z výše uvedených vrstev není v cestě. Je to nejčastější důvod, proč ochrana „nefunguje" — kompletní postup je v článku jak skrýt IP adresu originu.

Jak SYN floody zastavuje Itnetic

Každá vrstva z toho seznamu je v cestě v každém tarifu Itnetic včetně bezplatného — neexistuje úroveň, kde by ochrana handshaku byla příplatek.

Vrstva	Co dělá
Pohlcení upstream	Frankfurt stojí za sítí X4B s 500 Gbps mitigační kapacity, Toronto a Singapur běží na Linode (Akamai) s vlastní síťovou ochranou. Objemové a vycpané záplavy se vsáknou před naším edge, natož před vaším — aktuální seznam je na stránce sítě
Filtrace paketů v ovladači	eBPF filtr na XDP hooku vynucuje identitu protokolu na každém flow, uplatňuje stropy SYN a zahazuje záplavy `ACK`, `RST` a `FIN`, které bezstavový filtr nerozezná — všechno dřív, než se alokuje socket
Ukončení handshaku na edge	TCP i TLS končí v bodě přítomnosti. Váš origin uvidí jen spojení, která dokončila handshake a prošla filtrací, takže jeho backlog nikdy není zdrojem pod útokem
Řízení příjmu podle rychlosti spojení	Stropy na zdroj přímo pro handshake, přičemž prokázaní návštěvníci se pouštějí přednostně, aby je záplava nevytlačila
Zahození prokázaných útočníků v jádře	Recidivisté skončí v nftables setu a od té chvíle nestojí za paket nic
Důkazy	Logy na úrovni požadavku se stavem, latencí, otiskem klienta a uplatněným verdiktem, takže rozbor je export, ne rekonstrukce

Stejně jako cesta paketu ale záleží na dvou obchodních detailech. Odfiltrovaný útočný provoz se nikdy neměří proti vaší kvótě přenosu, takže z týden trvajícího SYN floodu nevznikne faktura. A nasazení jsou dva DNS záznamy u vašeho stávajícího poskytovatele — žádná změna nameserverů, zhruba pět minut a klidně po jednom hostname, pokud si to chcete nejdřív osahat. Zbytek mechaniky popisuje DDoS ochrana Itnetic.

Pokud chráníte herní server a ne web, má problém s handshakem jinou podobu — join floody, ping floody a záplavy spojení proti protokolu, který není HTTP. To řeší ochrana herních serverů a průvodce ping floody v Minecraftu.

Šestibodový checklist na zpevnění

Zapněte tcp_syncookies a ověřte to příkazem sysctl net.ipv4.tcp_syncookies místo spoléhání, že to distribuce udělala za vás.
Nastavte tcp_max_syn_backlog, somaxconn a backlog ve listen() vaší aplikace na konzistentní hodnoty, od největší dolů.
Snižte tcp_synack_retries na 2, aby mrtvé handshaky uvolňovaly místa v sekundách, ne za minutu.
Porovnejte nf_conntrack_max se svou skutečnou rychlostí spojení, nebo veřejný naslouchající port přestaňte sledovat.
Dejte si na dashboard paketovou rychlost hned vedle přenosu a alertujte na ni. Na metriku, kterou nekreslíte, nelze reagovat.
Zafirewallujte origin tak, aby přijímal provoz jen z vaší ochranné sítě — jinak je z pohledu útočníka všechno upstream nepovinné.

Pokud jste právě uprostřed útoku, přestaňte číst a projděte jak zastavit DDoS útok; je psaný na incident, ne na čtení. Až vlna opadne, jak otestovat DDoS ochranu popisuje, jak si bezpečně a legálně ověřit, že ta příští dopadne někam jinam než do vaší tabulky spojení.

Co je SYN flood útok?