Přizpůsobená ochrana proti DDoS útokům s programovatelnou ochranou toku dat

Informatec Digital » Zdroje » Přizpůsobená ochrana proti DDoS útokům s programovatelnou ochranou toku dat

Žijeme v době, kdy síť tvoří pojivovou tkáň téměř všeho, co děláme. Když společnost ztratí službu kvůli útoku typu „denial-of-service“, nepadá jen webová stránka: paralyzuje se prodej, interní procesy, zákaznický servis a v nejzávažnějších případech i základní služby. Proto se strategickou součástí každé moderní architektury stala přizpůsobená mitigace DDoS útoků s programovatelnou ochranou toku dat .

Vznik technologií, jako je Programmable Flow Protection pro Magic Transit od Cloudflare , použití vlastní logiky v jazyce C nasazené jako eBPF, integrace s cloudy, jako jsou AWS a Azure, a podpora specializovaných obranných služeb radikálně změnily situaci. Nyní je možné modelovat, co představuje „dobrý“ nebo „škodlivý“ provoz na úrovni paketů, přizpůsobit mitigaci velmi specifickým protokolům UDP (například těm, které se používají v online hrách nebo VoIP) a kombinovat to s řešeními business intelligence a umělé inteligence, která se učí z každého útoku.

Co je to DDoS útok a proč se stal tak vážným problémem?

Distribuovaný útok typu denial-of-service (DDoS) si klade za cíl zahltit systémové zdroje (servery, linky, aplikace nebo mezilehlou infrastrukturu) spuštěním záplavy provozu z více simultánních zdrojů. Na rozdíl od klasického útoku DoS, kde útok spouští jeden zdroj, útok DDoS zahrnuje tisíce nebo dokonce miliony napadených zařízení organizovaných do botnetu.

Motivace DDoS útoků jsou různé: ekonomické vydírání, sabotáž mezi konkurencí, aktivismus, odvety proti novinářům či médiím, nebo jednoduše testy síly nových botnetů v režimu „demonstrace schopností“. Výsledek je však vždy stejný: nedostupnost služeb , vážné snížení výkonu a ekonomické a reputační škody.

V posledních letech dochází k neustálému nárůstu frekvence a intenzity těchto útoků. Zprávy od hlavních dodavatelů bezpečnostních řešení naznačují trvalý nárůst hypervolumetrických útoků (nad 1 Tbps neboli miliardu paketů za sekundu), které často cílí na kritickou infrastrukturu, jako jsou finanční služby, veřejné služby a telekomunikace.

Typy DDoS útoků: ze sítě do aplikace

Abychom pochopili, jak funguje zmírňování DDoS útoků na míru, je užitečné si projít hlavní kategorie útoků. Obecně řečeno, můžeme je rozdělit do čtyř hlavních skupin, které jsou propojeny s různými vrstvami modelu OSI a různými zdroji, které se snaží vyčerpat.

Útoky na síťové vrstvě (L3/L4) se zaměřují na zneužívání síťových a transportních protokolů (IP, TCP, UDP, ICMP) k odčerpávání omezených zdrojů ze serveru nebo mezilehlé infrastruktury: CPU, paměti, tabulek firewallu, čekajících připojení nebo síťových vyrovnávacích pamětí. Mezi klasické příklady patří SYN floods (zahlcení serveru požadavky na TCP připojení, které nikdy nedokončí handshake), UDP floods na náhodné porty a ICMP útoky.

Útoky na aplikační vrstvě (L7) cílí na menší šířku pásma než na zdroje samotné webové aplikace nebo API. Generují obrovské množství HTTP požadavků (GET/POST), komplexních dotazů do interních vyhledávačů, volání náročných API nebo interakcí, které se sice zdají být legitimní, ale nutí backend, databázové nebo systémy generující obsah pracovat na hranici svých možností.

Volumetrické útoky: Cílem je zahltit linku, dokud se nestane nepoužitelnou. Odesílá se obrovské množství provozu, často s využitím technik zesílení a reflexe na nesprávně nakonfigurovaných UDP službách, jako jsou veřejné DNS servery (DNS, NTP, Memcached, CLDAP, SNMP, SSDP, Chargen, SLP atd.), takže malý paket požadavku generuje mnohem větší odpověď namířenou na zosobněnou oběť.

Multivektorové útoky jsou v současnosti nejsložitější. Kombinují několik metod (volumetrické, protokolové a aplikační) a mění strategii v reálném čase, jakmile zjistí, že obrana je úspěšná. Jeden útok může začít jako UDP flood, poté přejít do SYN flood a následně se zvrhnout v HTTP útok na 7. vrstvě, což oběť donutí nasadit komplexní a koordinovanou obranu.

Skutečný vývoj DDoS útoků: od Mirai k hyperútokům s Tbps

Teorie je sice v pořádku, ale skutečný rozsah problému se projeví v reálných případech. V posledním desetiletí jsme se od útoků o rychlosti stovek Gb/s dostali k událostem, které snadno překračují několik terabitů za sekundu (Tb/s) , s rychlostí paketů dosahující miliard za sekundu.

V roce 2016 dosáhl útok na Dyn – významného poskytovatele DNS – rychlosti přibližně 1,2 Tb/s a dočasně vyřadil z provozu weby jako Twitter, GitHub, PayPal a Netflix. Botnet Mirai, který oslovil přes 600 000 zařízení IoT (routery, kamery a DVR s výchozími přihlašovacími údaji), byl použit ke generování masivního provozu na DNS servery Dyn, pravděpodobně za použití kombinace technik UDP flooding a amplifikace.

Ve stejném roce utrpěl bezpečnostní blog KrebsOnSecurity útok o síle přibližně 623 Gb/s , rovněž založený na technologii Mirai. Po téměř čtyři dny byly velké UDP pakety odesílány primárně na náhodné porty, čímž saturovaly linky a nutily provoz přesměrovat na specializované služby pro zmírnění útoků, jako je Akamai Prolexic, které používaly filtrování signatur a chování.

V roce 2018 se GitHub stal terčem útoku s rychlostí 1,35 Tb/s založeného na amplifikaci Memcached. Útočníci odesílali malé UDP požadavky na servery Memcached vystavené na portu 11211 s použitím falešné IP adresy GitHubu. Každý malý požadavek spouštěl 50–100krát větší odpovědi směřující do systémů GitHubu, které byly nuceny přesměrovat provoz do čisticích center, kde byly odpovědi Memcached filtrovány podle jejich specifických vzorců.

V roce 2020 společnost Amazon oznámila, že AWS Shield zmírnil útok s rychlostí 2,3 Tb/s, který se spoléhal na reflexi CLDAP (UDP 389). Vektor útoku zahrnoval bombardování bezstavových LDAP serverů dotazy, které generovaly oběti velké množství odpovědí. AWS distribuovala provoz po celé své globální síti a aplikovala pravidla filtrování pro daný specifický vzorec CLDAP.

V poslední době se objevily botnety jako Mēris , které zneužívají zranitelnosti v routerech MikroTik. V roce 2021 byly zaznamenány vrcholy 21,8 milionu požadavků za sekundu (RPS) a v roce 2022 dosáhly 46 milionů RPS proti infrastruktuře Googlu s přibližným objemem 1,3 Tbps. Úsilí o zmírnění dopadů zahrnovalo hromadné opravování zařízení, uzavírání portů, jako je 5678 , a aplikaci specifických pravidel filtrování pro signaturu Mēris v sítích, jako jsou Cloudflare a Akamai.

V dubnu 2025 společnost Cloudflare ohlásila hyperútok s rychlostí přibližně 6,5 Tb/s a několika miliardami paketů za sekundu. Podle jejich analýzy se jednalo o neidentifikovaný botnet s charakteristikami podobnými Mēris a Aisuru, který primárně využíval přímé UDP záplavy ze zařízení IoT a špatně nakonfigurovaných serverů, aniž by vyžadoval tradiční zesílení. Obrana se spoléhala na globální síť Anycast od Cloudflare, zmírňování XDP/eBPF na okraji sítě, dynamické čištění a omezení rychlosti na IP adresu a na region.

A v květnu 2025 se KrebsOnSecurity opět dostala na titulní stránky novin, když odolala útoku o rychlosti přibližně 6,3 Tb/s, který spustil botnet Aisuru. V tomto případě bylo po dobu přibližně 40–45 sekund generováno přibližně 585 milionů UDP paketů za sekundu. Google Project Shield, který web chránil, okamžitě aktivoval agresivní filtrovací zásady pro nevyžádané UDP a přesměroval provoz do čisticích center rozmístěných po celé globální síti, takže dopad na službu byl prakticky nepostřehnutelný.

Zdroje a techniky útočníků: botnety, zesilování a úniky

Aby útočníci dosáhli těchto ohromujících čísel, využívají řadu zdrojů, které kombinují podle svého cíle. Základem jsou masivní botnety : sítě napadených zařízení po celém světě, které jsou rekrutovány zneužíváním známých zranitelností, výchozích hesel nebo odhalených administrativních služeb. Mirai, Mēris a Aisuru jsou rodinná jména, ale existuje nespočet variant zaměřených na různé výrobce nebo služby.

Druhou hlavní zranitelností jsou nesprávně nakonfigurované servery fungující jako reflektory. Kandidátem je jakákoli neověřená služba UDP, která odesílá více dat, než kolik přijímá: DNS (port 53), NTP (123), Memcached (11211), CLDAP (389), SNMP (161), SSDP, Chargen, SLP, TFTP, Portmap, služby P2P nebo dokonce protokoly videoher. Útočník odesílá malé požadavky, které falšují IP adresu oběti, a servery je zesilují a vracejí odpověď skutečnému cíli.

Například v DNS může dotaz ANY na otevřený resolver znásobit velikost požadavku přibližně 28krát. V NTP dosahoval starý příkaz MONLIST poměrů zesílení 50–500x. Memcached je extrémní případ: malý požadavek může vrátit stovky kilobajtů a dosáhnout poměrů zesílení desítek tisíc. CLDAP pracuje s faktory 56–70x, zatímco SLP se používá s hodnotami přesahujícími 2000x.

Útočníci navíc zdokonalují své techniky obcházení. IP spoofing zůstává klasickou metodou pro zatajení skutečného původu a zneužití odrazu. Mezi další metody patří neustálé střídání vektorů útoku, míchání šifrovaného provozu s cílem vynutit vyšší zátěž obránce, používání technik „nízkého a pomalého“ (postupná spotřeba zdrojů bez zjevných nárůstů) nebo přiblížení provozu k aplikační vrstvě, kde se mnohem více podobá legitimnímu provozu.

V předútokové fázi se k lokalizaci zranitelných služeb používají nástroje pro hromadné skenování, jako je masscan nebo zmap, spolu s exploit kity speciálně navrženými pro IoT nebo servery. Během útoku se používají generátory provozu, jako je hping3, LOIC/HOIC nebo optimalizované skripty C/Python, zatímco pro analýzu po útoku mohou útočníci sami použít Wireshark, tcpdump a monitorovací platformy.

Fáze DDoS útoku a potřeba adaptivní obrany

Ačkoli jsou sofistikované DDoS útoky často vnímány jako chaotické výbuchy provozu, procházejí několika odlišnými fázemi . Zaprvé, fází průzkumu, ve které útočník zkoumá exponovaný povrch, identifikuje domény, IP adresy, otevřené služby, CDN nebo přítomné poskytovatele mitigačních opatření a hledá zranitelnosti.

Dalším krokem je kompromitace zařízení, která zahrnuje infikování počítačů, jež budou zásobovat botnet. To může znamenat zneužití zranitelností v routerech, kamerách, systémech vzdálené správy nebo serverech, často s využitím zastaralého softwaru nebo výchozích přihlašovacích údajů. Po načtení se zařízení připojí k infrastruktuře C2, která centralizuje příkazy a aktualizace.

Fáze provedení útoku je obvykle načasována tak, aby se shodovala s kritickými okamžiky pro oběť: marketingové kampaně, uvedení produktů na trh, víkendy s menším počtem zaměstnanců ve službě nebo politicky či mediálně citlivá data. Cílem je maximalizovat dopad a tlak . U útoků nové generace existuje také složka dynamické adaptace: botnet monitoruje reakci oběti a mění svůj vektor útoku, pokud detekuje účinné zmírnění dopadu.

Na straně obrany to vyžaduje návrh stejně adaptivních strategií. Statický firewall nebo prahová hodnota šířky pásma již nestačí: jsou zapotřebí systémy schopné detekovat anomálie v provozu v reálném čase , korelovat události, nasazovat nová pravidla za chodu a škálovat zdroje (výpočetní, úložné a síťové kapacity) na vyžádání.

Nedávná studie ukázala, že DDoS útoky proti kritické infrastruktuře vzrostly za čtyři roky o více než 50 % a že se často používají jako zástěrka pro jiné útoky, jako je nasazení ransomwaru, zatímco bezpečnostní tým se soustředí na „hašení“ odmítnutí služby.

Tradiční mitigace: centra pro čištění dat, CDN, firewally a WAF

Profesionální obrana proti DDoS útokům se spoléhá na kombinaci technologií a poskytovatelů. Nejcharakterističtější složkou jsou centra pro čištění provozu , rozsáhlé distribuované infrastruktury, které dokáží absorbovat desítky Tbps a filtrovat škodlivý provoz, než klientovi vrátí pouze platná připojení.

Společnosti jako Netscout/Arbor, Akamai/Prolexic, Cloudflare, Radware, Imperva a AWS Shield spravují globální sítě s více body přítomnosti. Když je detekován útok, provoz směřující do oběti je přesměrován (prostřednictvím změn BGP nebo aktualizací DNS) do těchto center, kde jsou aplikovány filtry na základě signatur, chování, blacklistů, statistické analýzy a vlastních pravidel.

Souběžně mnoho organizací nasazuje lokální zařízení proti DDoS útokům ve vlastních datových centrech nebo v datových centrech svých poskytovatelů internetových služeb. Zařízení jako Arbor TMS, Radware DefensePro, FortiDDoS nebo některá řešení F5 jsou zodpovědná za detekci a zmírňování útoků až do určitého limitu kapacity. Běžnou praxí je kombinovat tato lokální zařízení s cloudovým řešením pro odstraňování útoků, které překračují jejich kapacitu.

Architektury CDN a Anycast – například od společností Cloudflare, Akamai, Fastly nebo Google Cloud CDN – přidávají další vrstvu obrany geografickým rozložením zátěže. Publikováním služby za CDN je provoz distribuován mezi více uzlů a volumetrické útoky jsou zředěny tím, že nejsou soustředěny do jednoho bodu. Dále obvykle integrují firewally webových aplikací (WAF) a zásady omezující rychlost na úrovni HTTP.

A konečně, síťové firewally (Cisco, Palo Alto, iptables v Linuxu atd.) a specializované WAFy (ModSecurity, Cloudflare WAF, AWS WAF) umožňují filtrovat provoz podle IP adresy, portu, příznaků a vzorců aplikací . I když samy o sobě nezastaví útok Tbps na úrovni páteřní sítě, jsou nezbytné pro blokování známých útočných vektorů, omezení podezřelých připojení a ochranu vrstev 6 a 7 sítě.

Programovatelná ochrana průtoku a přizpůsobené zmírňování hluku s Magic Transit

V tomto kontextu stále složitějších útoků a stále specifičtějších protokolů se objevují řešení, jako je Programmable Flow Protection for Magic Transit od společnosti Cloudflare , která představují kvalitativní skok: umožňují společnostem napsat si vlastní logiku pro zmírňování rizik a nasadit ji přímo v síti globálního poskytovatele.

Myšlenka je jednoduchá, ale účinná: zákazníci Magic Transit si mohou načíst stavové programy pro zpracování paketů napsané v jazyce C. Cloudflare tyto programy ověřuje, kompiluje a transformuje do eBPF a spouští je v uživatelském prostoru v rámci své globální infrastruktury. To jim umožňuje kontrolovat UDP provoz aplikací s ohledem na protokol: porozumět záhlavím specifickým pro online hru, vysokofrekvenční obchodní systém, VoIP služby nebo streamovací platformy a paket po paketu rozhodovat, co povolit a co blokovat.

Tato vlastní logika se integruje s Flowtrackd, platformou Cloudflare pro stavové zmírňování rizik. Funkce podporuje symetrické i asymetrické topologie, ačkoli v této uzavřené beta fázi se zaměřuje na analýzu příchozího provozu. Veškerá správa je řešena prostřednictvím Cloudflare API s koncovými body pro nahrávání programů, vytváření souvisejících pravidel, výpis konfigurací nebo jejich mazání podle potřeby.

Klíčovým poznatkem je, že se již nespoléháme pouze na generické podpisy a heuristiky dodavatelů. Například herní společnost může jasně definovat legitimní tok svého proprietárního UDP protokolu (handshake, zprávy o poloze, keep-alive atd.) a které vzorce jsou charakteristické pro útok. Tato logika je kompilována a nasazena napříč všemi body přítomnosti Cloudflare, čímž se rozhodování přibližuje k okraji sítě.

Pro prostředí s vlastními protokoly nebo aplikacemi s velmi vysokými nároky na latenci je toto zmírňování útoků DDoS s programovatelnou ochranou toku zásadní: přidává vrstvu podnikově specifické inteligence nad rámec standardních obranných opatření. A v kombinaci s cloudovými službami, jako jsou AWS nebo Azure, a s vlastními softwarovými řešeními (jako jsou ta vyvinutá společnostmi specializujícími se na umělou inteligenci a analytiku, jako je Q2BSTUDIO), umožňuje ještě větší automatizaci detekce pravidel a aktualizací na základě nově vznikajících hrozeb.

Proč poskytovatelé internetových služeb a organizace potřebují pokročilé zmírňování DDoS útoků

Poskytovatelé internetových služeb (ISP) a velké organizace jsou v první linii. Dostatečně velký útok může zahltit nejen jednoho zákazníka, ale celou část sítě operátora a způsobit kaskádové výpadky , které postihnou tisíce uživatelů. Zmírňování DDoS útoků se proto stalo nezbytným požadavkem, nikoli volitelným doplňkem.

Z obchodního hlediska jsou důsledky neschopnosti se bránit jasné: přerušení služby, porušení dohod o úrovni služeb (SLA), smluvní pokuty, přímá ztráta příjmů a odliv zákazníků ke konkurenci vnímané jako spolehlivější. Pokud je kritická aplikace nedostupná, když ji uživatel potřebuje, bude přirozeně hledat alternativy.

V odvětvích, jako je bankovnictví, pojišťovnictví, veřejné služby a zdravotnictví, může dopad přesahovat rámec ekonomické oblasti: narušení fyzických procesů , provozní rizika a narušení základních služeb. Kromě toho existují náklady na reputaci, které je obtížné získat zpět, když je značka na sociálních sítích a v tisku spojována s „výpadkem systému“ po celé hodiny.

Aby toho nebylo málo, DDoS útoky se často používají jako krytí pro ničivější útoky. Zatímco se bezpečnostní tým zaměřuje na zvládání nárůstu provozu, útočníci se mohou pokusit o laterální pohyb v síti, nasazení ransomwaru nebo odcizení dat. Jinými slovy, DDoS útoky fungují jako návnady a rozptýlení pozornosti při vícestupňových útocích.

Moderní řešení pro zmírňování rizik, ať už lokální nebo cloudová, výrazně snižují prostoje, udržují kontinuitu provozu a chrání jak lokální aktiva, tak i veřejné cloudové zdroje. Klíčem je jejich schopnost automaticky se škálovat, aby zvládala masivní nárůsty provozu, a nabízet jasné záruky kapacity a doby odezvy.

Specifické techniky zmírňování: od omezení rychlosti po blackholing

Kromě hlavních technologických bloků existuje řada specifických technik, které se denně používají k boji proti různým typům útoků. Jednou z nejzákladnějších je filtrování perimetru pomocí firewallů a seznamů řízení přístupu (ACL) na routerech a přepínačích, které blokují pakety na základě zdrojové IP adresy, cílové IP adresy, portů, TCP příznaků nebo velikosti.

Další klasickou součástí je omezení rychlosti , a to jak na vrstvách 3/4, tak v HTTP. V systémech Linux nabízí iptables moduly jako hashlimit nebo SYNPROXY pro řízení počtu připojení nebo paketů za sekundu, které jsou z jedné IP adresy akceptovány. Na úrovni aplikace mohou proxy servery jako Nginx nebo HAProxy nastavit limity pro požadavky na klienta nebo na trasu.

Pro útoky na 7. vrstvě je velmi užitečné implementovat výzvy nebo dodatečné ověřování . CAPTCHA, výzvy JavaScriptu a podobné mechanismy umožňují lepší rozlišení mezi skutečnými prohlížeči a automatizovanými boty, čímž se snižuje zátěž skutečné aplikace. V TCP techniky jako SYN cookies pomáhají serveru vyhnout se nutnosti ukládat stav pro každý pokus o připojení, dokud není handshake dokončen.

Pokud je objem útoku nezvládnutelný i pro mitigační infrastrukturu, lze použít BGP blackholing : poskytovatel internetových služeb inzeruje trasu do napadené sítě jako „černou díru“ a zahazuje veškerý provoz směřující k danému prefixu před vstupem do páteřní sítě. Jedná se o poslední možnost, protože znemožňuje dostupnost služby, ale brání útoku v ovlivnění dalších částí sítě.

Služby cloudového čištění – jako jsou ty, které nabízí Cloudflare, Akamai, AWS Shield, Google Project Shield, Radware a další – vám umožňují směrovat veškerý provoz do jejich datových center a čistit ho tam s použitím specifických pravidel pro vektory, jako je amplifikace Memcached, CLDAP, DNS, NTP, neamplifikované UDP záplavy atd. Každý zablokovaný útok zásobuje modely strojového učení a databáze podpisů, které se používají v budoucích snahách o zmírnění dopadů.

Osvědčené postupy a poučení z aktuálních DDoS útoků

Z velkých incidentů posledních let lze vyvodit několik jasných ponaučení. Prvním je, že zabezpečení zařízení internetu věcí je klíčové: velká část síly botnetů, jako jsou Mirai, Mēris nebo Aisuru, pochází z domácích routerů, kamer a dalších zařízení se zastaralým firmwarem a továrními hesly.

Druhým je, že musíme eliminovat vektory zesilování v našich vlastních sítích: zakázat nepotřebné služby UDP, filtrovat odchozí provoz NTP, DNS nebo Memcached, aplikovat pravidla firewallu, která povolují pouze dotazy z autorizovaných rozsahů, a pravidelně kontrolovat odhalené porty. Jakýkoli nesprávně nakonfigurovaný server se může stát zesilovačem pro útočníka.

Včasná detekce anomálií je také nezbytná . Nástroje jako NetFlow, sFlow, IDS/IPS (Snort, Suricata), platformy pro analýzu protokolů nebo SIEM by měly být nakonfigurovány tak, aby upozornily, jakmile se objeví neobvyklé špičky v provozu, náhlé změny ve vzorcích připojení nebo známé signatury útoků. Čím dříve je reakce aktivována, tím méně času zbývá na eskalaci útoku.

Ve webových prostředích je téměř povinné používat aktualizované WAFy, CAPTCHA, pokud odpovídají uživatelskému prostředí, a mezipaměti nebo CDN, aby se absorbovala část zátěže. Na systémové úrovni povolování SYN cookies, úprava prahových hodnot pro simultánní připojení a uzavření všech nepodstatných služeb snižuje plochu pro útok.

A konečně, každá organizace by měla mít zdokumentovaný pohotovostní plán pro DDoS útoky : runbook s jasnými kroky, určenými odpovědnými stranami, technickými kontakty na poskytovatele mitigace a poskytovatele internetových služeb a předdefinovanými kritérii pro aktivaci scrubbingu, kdy požádat o blackholing nebo kdy degradovat nepodstatné funkce k ochraně klíčových obchodních aktivit.

Tento trend poukazuje na stále rychlejší, intenzivnější a adaptivnější útoky, ale také na chytřejší a přizpůsobitelnější obranu. Využití možností řešení, jako je Programmable Flow Protection, v kombinaci s neustálým monitorováním provozu, osvědčenými konfiguračními postupy a redundantními cloudovými architekturami umožňuje společnostem pokračovat v normálním provozu i uprostřed paketové bouře a chránit tak nejen svá data, ale také svou reputaci a důvěru zákazníků.