Co je UDP flood?

UDP se nikoho neptá

TCP otevírá spojení dohodou. Vymění se tři pakety a server, který nechce nebo nemůže mluvit, může odmítnout dřív, než se cokoli alokuje. Handshake je pro útočníka náklad a pro vás rozhodovací bod.

UDP nemá ani jedno. RFC 768 má tři stránky a popisuje osmibajtovou hlavičku přišitou k datům: zdrojový port, cílový port, délka, kontrolní součet. Žádný handshake, žádná sekvenční čísla, žádná potvrzení, žádný stav na ani jedné straně. Odesílatel vysílá; jestli někdo naslouchá, není jeho problém.

A to je celý útok. UDP flood je prostě velmi velké množství UDP paketů poslaných na vaši adresu. Není tu žádný krok protokolu, který by mohl selhat, žádná fronta, která se plní rozdělanou prací, žádné rafinované zneužití specifikace. První věc, kterou s UDP paketem váš server může udělat, je přijmout ho — a přijetí už je ta škoda.

Právě proto jsou UDP floody po desítkách let jedním z nejčastějších tvarů útoku: nepotřebují zranitelnost, průzkum ani nic sofistikovanějšího než linku.

Selžou dva zdroje a navzájem se skrývají

„UDP flood" popisuje metodu, nikoli velikost, a tatáž metoda láme tři různé věci podle toho, jak jsou pakety tvarované.

Aritmetiku se vyplatí mít v hlavě, protože záplava optimalizovaná na jednu z těchto věcí je skoro neviditelná v grafu, kterým byste hledali druhou. Rámec o 64 bajtech zabere na drátě 84 bajtů, když připočteme preambuli a mezirámcovou mezeru, takže:

Přečtěte si druhý sloupec znovu. Paketová rychlost, která zničí většinu originů, je bitová rychlost, které si vaše linka ani nevšimne. Pokud váš monitoring kreslí megabity a ne pakety za sekundu — což je skoro všude výchozí stav — vypadá paketová záplava tak, že server záhadně přestane být dostupný, zatímco graf provozu zůstává v klidu. Tahle chybná diagnóza posílá lidi na hodinu restartovat služby.

Obrácený případ lidé čekají: 1 500bajtové pakety při stejných 10 Gb/s jsou jen asi 820 000 paketů za sekundu, triviální na zpracování a naprosto fatální, protože linka je plná dřív, než se kterýkoli z nich dostane k softwaru.

Přímé záplavy, reflexe a amplifikace

Pakety musí odněkud přicházet a tři způsoby, jak to zařídit, se liší v tom, co s nimi můžete dělat.

Podvrhávání je vůbec možné proto, že UDP nikdy neověřuje zpáteční adresu, a protože vstupní filtrace (BCP 38) — praxe, kdy sítě odmítají přeposílat pakety se zdrojovými adresami, které jejich zákazníkům nemohou patřit — bylo poprvé doporučeno v roce 1998, v roce 2000 znovu vydáno jako best current practice a po čtvrtstoletí je stále nasazené nerovnoměrně.

Amplifikace je průmyslová verze téhož principu a má vlastní stránku: DNS amplifikační útoky rozebírají ekosystém reflektorů, amplifikační faktory podle protokolu a proč záplava přichází od tisíců nevinných serverů. Rozdíl, na kterém tady záleží, je ten, že přímá UDP záplava žádné reflektory nepotřebuje, takže neexistuje čistá signatura „nevyžádaná odpověď ze zdrojového portu 53", podle které by se dalo filtrovat. Pakety vypadají jako to, co jsou: provoz na port, odněkud.

Mezi nimi, a čím dál častěji, stojí záplava rozprostřená po podsíti: stejný celkový objem rozdělený na všechny adresy ve vaší /24 místo soustředěný na jednoho hosta. Detekční limity na jednotlivé IP se nikdy nespustí, zatímco součet stále ucpe linku výš, kterou celý rozsah sdílí.

ICMP odpověď je součástí útoku

Tady je detail, který dělá UDP floody svébytně sebeposilující, a ten, který většina návodů pro servery vynechává.

Když UDP paket dorazí na port, kde nic nenaslouchá, správně se chovající stroj nemlčí — odpoví ICMP typ 3, kód 3: cíl nedostupný, port nedostupný. Záplava tedy není jen ignorovaná. Každý paket vás stojí odpověď: sestavení nového paketu, vyhledání cesty, spotřebovanou odchozí linku.

A pokud byly zdrojové adresy podvržené, letí ty odpovědi na cizí lidi. Váš server se stane reflektorem v cizím směru — jev známý jako backscatter — a právě tak oběť končí s abuse stížnostmi během útoku, který míří na ni.

Linux tyhle odpovědi omezuje (net.ipv4.icmp_ratelimit a icmp_ratemask, který vybírá, kterých typů se limit týká), což škodu ohraničí, ale neodstraní cenu rozhodnutí o potlačení u každého paketu. Praktický důsledek je pravidlo, které se vyplatí si zapsat: nežádoucí UDP filtrujte pomocí drop, nikdy ne reject. Reject je ICMP odpověď s pár kroky navíc.

Druhý tichý multiplikátor je connection tracking. Stavové firewally sledují UDP „flows" podle čtveřice, i když UDP žádná spojení nemá, a výchozí nf_conntrack_udp_timeout je 30 sekund. Podvržená záplava s náhodnou zdrojovou adresou a portem u každého paketu tedy vytváří nový záznam na každý paket a každý se drží půl minuty. Proti výchozímu nf_conntrack_max 262 144 zaplní záplava o milionu paketů za sekundu tabulku asi za čtvrt sekundy — a od té chvíle jádro zahazuje provoz bez rozdílu, včetně spojení vašich skutečných návštěvníků. Řádek v logu je nf_conntrack: table full, dropping packet a běžně se čte jako chyba serveru.

Jak potvrdit, že jde o UDP flood

Dvě minuty důkazů, než cokoli změníte:

• Spočítejte pakety na zavřené porty. nstat -az | grep -i udp nebo netstat -su. Rostoucí UdpNoPorts znamená, že přicházejí pakety na porty, které neobsluhujete — samo o sobě téměř diagnostické. Rostoucí RcvbufErrors a InErrors naopak znamenají, že záplava míří na port, který obsluhujete, a aplikace nestíhá vyprazdňovat socket.
• Vězte, na čem skutečně nasloucháte. ss -lun vypíše vaše reálné UDP listenery. Většinu správců ten výpis překvapí.
• Srovnejte paketovou a bitovou rychlost. sar -n DEV 1 nebo ip -s link. Hodně paketů s plochým grafem přenosu znamená paketovou záplavu; vytočená linka při běžné paketové rychlosti znamená velké pakety nebo amplifikaci.
• Kontrolujte kartu, ne jen jádro. ethtool -S eth0 | grep -iE 'drop|miss|fifo'. Rostoucí rx_dropped nebo rx_missed_errors znamená, že pakety zhynuly v ring bufferu dřív, než je jádro vůbec vidělo, a to žádné pravidlo firewallu neovlivní.
• Podívejte se na sto paketů. tcpdump -ni eth0 udp -c 100 -nn. Shodné délky dat a fixní cílový port říkají „generátor". Zdrojové porty 53, 123, 389, 1900 nebo 11211 říkají „reflexe" a posílají vás na průvodce amplifikací.
• Přečtěte si log aplikace — bude prázdný. Pokud provozujete web nebo API, váš provoz je TCP. UDP flood nevytvoří žádný záznam: žádné pomalé požadavky, žádné chyby, nic. Access log plný věrohodných požadavků během výpadku znamená, že se díváte na útok na vrstvě 7, což je jiný problém s jinou odpovědí.

Tahle poslední kontrola je nejrychlejší rozcestí a když ji spletete, lidé píší WAF pravidla, zatímco paketová záplava drží stroj mimo síť.

Co se dá udělat na serveru a na jaký strop to narazí

Všechno následující se vyplatí udělat na každém stroji otočeném do internetu. Nic z toho nerozhoduje o výsledku, což je pointa další sekce.

Zakažte UDP ve výchozím stavu, a to přes drop. Povolte tu hrstku portů, které skutečně obsluhujete, a zbytek tiše zahoďte. Tím zmizí cena ICMP odpovědí i backscatter.

Držte UDP mimo connection tracking. Pravidlo notrack pro veřejné UDP porty — nebo žádné stavové sledování na tom rozhraní — vyřadí tabulku ze seznamu věcí, které mohou selhat první. Zvýšení nf_conntrack_max pomůže proporčně; vyjmutí provozu pomůže kategoricky.

Dejte kartě prostor a víc než jedno jádro. ethtool -G zvedne přijímací ring a RSS/RPS rozprostře přerušení na víc jader, takže záplava nevytočí jádro 0, zatímco patnáct dalších zahálí. Jednofrontová virtuální karta je tvrdý strop, kterým žádný sysctl nepohne.

Nastavte přijímací buffer služby, kterou skutečně provozujete. net.core.rmem_max a explicitní SO_RCVBUF koupí hlubší frontu pro špičky. Pro trvalou záplavu nekoupí nic; jen přesunou místo, kde se zahazuje.

Zahazujte v ovladači, ne ve stacku. eBPF program na XDP hooku zahodí paket dřív, než se vůbec alokuje skb, což je přibližně o řád levnější než pravidlo v iptables. Jestli chcete filtrovat lokálně, filtrujte tady.

Rate limity na zdroj fungují proti přímé záplavě ze skutečných adres a proti podvržené prakticky vůbec, protože každý paket se představí jinak.

Dohromady to možná zvedne paketovou rychlost, kterou přežijete, desetinásobně až dvacetinásobně. Co z toho nezmění nic, je věta, která vládne každému objemovému útoku: jakmile je paket na vaší lince, linka je už spotřebovaná. Každé pravidlo, které přidáte, je práce, kterou odvedete na každý útočný paket, na železe, které útočník za pár eur na hodinu přeroste. Je to tentýž strop, který popisuje co je DDoS mitigace, a UDP je místo, kde se na něj naráží nejtvrději.

Ještě s jedním důsledkem je lepší počítat předem. Většina hostingů chrání svou síť dřív než vás: když útok na vaši adresu ohrozí sdílenou kapacitu, standardní reakce je null-route té IP — zahodit veškerý provoz na ni, výš v síti, na hodinu nebo několik. Váš server je pak zdravý, nevytížený a nedostupný. To není selhání poskytovatele; je to dokumentovaná politika téměř každého levného hostingu a přesně proto není „můj origin má firewall" plán.

Kde se UDP flood skutečně zastaví

Výš v síti, 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.

1. Absorpční kapacita v síti operátora. Záplava musí dopadnout někam, kde je pro ni místo, ještě před poslední mílí, která vede k vám. Pro objemové UDP za to neexistuje náhrada a žádná vychytralost to nenahradí.
2. Bezstavová filtrace na plné rychlosti linky. UDP na port, který nikdo neobsluhuje, odpověď z portu reflektoru, na který se nikdo neptal, poškozené pole délky, fragment, který nelze složit: všechno zahoditelné na první pohled, v ovladači, bez držení stavu a bez alokace paměti. Tady se řeší desítky milionů paketů za sekundu.
3. Identita protokolu na každém flow. Filtr, který ví, jaký protokol na daný port legitimně patří, zahodí cokoli jiného už v prvním paketu, místo aby omezoval rychlost portu, kterému nerozumí.
4. Žádná vystavená UDP služba. Nejsilnější obrana je strukturální, ne vychytralá. Pokud věc, kterou chráníte, mluví HTTP, není důvod, aby byl jakýkoli UDP port vašeho originu dosažitelný z internetu — a službu, kterou nelze adresovat, nelze zaplavit.
5. Stropy na zdroj a zahození v jádře pro prokázané zdroje, které mají smysl u nepodvržených záplav a jsou plýtváním tabulkou proti podvrženým.

A jeden předpoklad, který stojí mimo seznam, protože vše výše tiše ruší: váš origin musí být nedostupný jinak než přes ochrannou síť. Pokud útočník může stále adresovat pakety na reálnou IP vašeho serveru, žádná z vrstev výše není v cestě — záplava je obejde. Je to nejčastější důvod, proč ochrana „nefungovala", a celý checklist je v jak skrýt IP adresu originu.

Výjimka jménem QUIC

„Blokujte všechno příchozí UDP" byla pro většinu webových serverů třicet let bezpečná rada. HTTP/3 to ukončuje: QUIC běží nad UDP, běžně na portu 443, takže moderní webový stack může UDP listener skutečně potřebovat.

QUIC byl navržen s tímhle na mysli — koncový bod musí ověřit adresu klienta přes Retry paket, než pošle víc dat, a RFC 9000 omezuje, co smí server poslat na neověřenou adresu, na trojnásobek toho, co přijal, čímž ohraničuje reflexi už specifikací. Co neohraničuje, je cena na paket na vaší straně: QUIC endpoint provádí skutečnou kryptografickou práci hned v úvodu spojení, takže záplava věrohodných úvodních paketů je útokem na CPU stejně jako na linku. Pokud servírujete HTTP/3 z vlastního železa, zaslouží si ten UDP port stejné zacházení výš v síti jako všechno ostatní na téhle stránce.

Jak UDP floody řeší Itnetic

Tady je lepší být přesný, protože UDP je oblast, kde se dodavateli nejsnáz naznačí víc, než dělá.

Dva komerční detaily váží stejně jako cesta paketu. Odfiltrovaný útočný provoz se nikdy neúčtuje proti vaší kvótě přenosu, v žádném plánu včetně bezplatného, takže týden trvající záplava nepřijde jako faktura. A každá funkce je v každém plánu — WAF, vlastní pravidla, rate limity, čekárna, logy na úrovni požadavku — takže se z incidentu nikdy nestane rozhodování o upgradu. Nasazení jsou dva DNS záznamy u vašeho stávajícího poskytovatele: bez přesunu nameserverů, asi pět minut, klidně po jednom hostname, chcete-li si to nejdřív pohlídat. Zbytek mechaniky má DDoS ochrana Itnetic a hranice tarifů, nakolik existují, ceník.

A teď to omezení, bez obalu. Pokud věc, kterou potřebujete mít online, mluví UDP přímo do internetu — Minecraft Bedrock server na RakNetu, herní server na Source engine, voice server, QUIC endpoint na vlastním železe — pak je HTTP reverzní proxy špatný tvar produktu, ten náš včetně. Herní ochrana Itnetic je filtrační proxy pro Minecraft Java Edition, což je TCP; Bedrock dnes nepodporujeme. Pro libovolné UDP služby chcete poskytovatele, který vám ohlásí prefix přes BGP nebo dá UDP forwarding, a kdokoli tvrdí něco jiného, si zaslouží slevu na důvěře. Pokud chráníte Minecraft Java server, začněte spíš u DDoS ochrany Minecraft serveru a ping floodů a front.

Checklist o sedmi bodech

1. Spusťte ss -lun a zapište si každý UDP port, který skutečně obsluhujete. Zbytek zakažte přes drop, nikdy reject.
2. Dejte na dashboard pakety za sekundu hned vedle přenosu a alertujte na obojí. Na metriku, kterou nekreslíte, nelze reagovat.
3. Přidejte tam UdpNoPorts a RcvbufErrors z nstat — řeknou vám, ve které z obou záplav jste.
4. Vyjměte veřejné UDP porty z connection trackingu, nebo si ověřte nf_conntrack_max proti rychlosti záplavy, ne proti rychlosti provozu.
5. Zkontrolujte ethtool -S na zahození v ring bufferu, zvedněte přijímací ring a ověřte, že jsou přerušení rozprostřená na víc jader.
6. Nastavte firewall originu tak, aby přijímal provoz jen z ochranné sítě — jinak je každá vrstva výš z pohledu útočníka volitelná.
7. Přečtěte si dnes DDoS politiku svého hostingu a zjistěte, jak dlouho drží null-route na napadené adrese. Znát to číslo před incidentem mění, co postavíte.

Pokud jste právě uprostřed útoku, přestaňte číst a projděte jak zastavit DDoS útok; je napsaný pro incident, ne do seznamu na čtení. Až vlna přejde, jak otestovat DDoS ochranu popisuje, jak si bezpečně a legálně potvrdit, že ta příští dopadne někde jinde než na vaši linku.