Krátká odpověď
Webový aplikační firewall (WAF) kontroluje jednotlivé požadavky a blokuje ty, které nesou útočnou zátěž. DDoS mitigace čte provoz v souhrnu a zahazuje záplavu. Jedna se ptá: snaží se tento požadavek zneužít mou aplikaci? Druhá: je tento klient jedním z deseti tisíc, které předstírají návštěvníka?
| Webový aplikační firewall | DDoS mitigace | |
|---|---|---|
| Na co se ptá | Je tento požadavek škodlivý? | Je tento provoz útok? |
| Jednotka rozhodování | Jeden požadavek, samostatně | Mnoho požadavků v čase |
| Co zachytí | SQL injection, XSS, průchod adresáři, vkládání souborů — OWASP Top 10 | HTTP floody, credential stuffing, scraping, objemové a protokolové záplavy |
| Kolik stačí k újmě | Jeden požadavek | Tisíce až miliony |
| Jak rozhoduje | Signatury, spravované sady pravidel, vlastní pravidla | Základní linie provozu, fingerprint klienta, ověření prohlížeče, rate limity |
| Co přehlédne | Útoky složené z jednotlivě korektních požadavků | Jeden korektní požadavek se škodlivou zátěží |
| Podle čeho ho hodnotíte | Zablokované exploity, míra falešných poplachů | Doba do mitigace, dostupnost pod útokem |
Ta záměna je pochopitelná. Obojí je reverzní proxy, obojí ukončuje spojení dřív než váš server a většina mitigačních produktů má uvnitř i engine pro WAF pravidla. Jenže obrana vyladěná na jeden špatný požadavek neuvidí vzor rozprostřený přes botnet — a obrana vyladěná na takový vzor nemá názor na to, co je uvnitř jednotlivého požadavku.
Co WAF skutečně dělá
WAF rozebere HTTP a porovná obsah každého požadavku s pravidly: URL, query string, hlavičky, cookies a tělo. Kus SQL v parametru vyhledávání, script tag v poli komentáře, ../.. v cestě k souboru, známá signatura exploitu pro váš redakční systém — to jsou útoky, které fungují v objemu jedna, z jediného klienta, v naprosto lidském tempu.
Pravidla mají dvě podoby. Spravované sady pokrývají zveřejněné třídy zranitelností a udržuje je dodavatel. Vlastní pravidla kódují to, co víte o své vlastní aplikaci: na /wp-admin se dostane jen vaše firemní síť, na obsluhu formuláře je povolená jen metoda POST, požadavky ze zemí, které neobsluhujete, dostanou výzvu.
Co WAF neumí, je počítat. Když deset tisíc klientů žádá vaši stránku vyhledávání a každý požadavek je korektní a bez škodlivé zátěže, signaturový engine nemá co spárovat — protože tam nic není. Útok existuje jen v souhrnu a na souhrn se WAF nedívá.
Co skutečně dělá DDoS mitigace
DDoS mitigace začíná z opačného konce. Modeluje, jak u vás vypadá normál — frekvence požadavků na klienta, na endpoint, na region, spolu se skladbou prohlížečů, TLS fingerprintů a pořadí hlaviček, kterou produkuje skutečné publikum — a hledá klienty, jejichž chování do toho nezapadá. Objemové a protokolové záplavy pohltí síťová kapacita výše po proudu; útoky na aplikační vrstvě se od skutečných uživatelů oddělí ověřením prohlížeče, behaviorálními signaturami a rate limity.
Nic z toho ale nečte těla vašich požadavků a nehledá v nich exploity. Jediný pokus o SQL injection ze skutečného prohlížeče, v tempu, jakým člověk brouzdá, se neodchýlí od žádné základní linie. Pro DDoS mitigaci je to jeden návštěvník, který dělá návštěvnické věci.
Kde každá obrana sama o sobě selže
Samotný WAF proti L7 záplavě. Tady je selhání horší než „nepomůže". WAF odvádí za každý požadavek skutečnou práci — parsování, vyhodnocení regulárních výrazů proti stovkám pravidel — takže záplava mířená na váš web teď stojí CPU i na vrstvě kontroly. Úzké hrdlo jste přesunuli, ne odstranili, a pokud platforma zjevný útočný provoz nezahodí před kontrolou, položí se WAF jako první.
Samotná DDoS mitigace proti exploitu. Behaviorální filtrace ochotně předá dál požadavek, který vysype vaši tabulku uživatelů — protože chováním je ten klient k nerozeznání od zákazníka. Dostupnost a integrita jsou dvě různé vlastnosti: web může být dokonale dostupný ve chvíli, kdy ho někdo vybírá.
Síťový firewall na cokoli z toho. Stojí za zmínku, protože slovo „firewall" v branži slouží dvěma věcem naráz. Síťový firewall filtruje podle adres, portů a protokolů — vrstvy 3 a 4. HTTP číst neumí, takže nevidí ani škodlivou zátěž, ani rozdíl mezi zákazníkem a botem na portu 443. Nechte si ho na zavření originu jen pro vaši mitigační síť; to je jediná úloha, kde je opravdu dobrý.
Potřebujete obojí? Ano — a v jednom průchodu
Správná otázka nezní které z toho, ale kde běží a v jakém pořadí. Na dobře postavené edge projde požadavek těmito fázemi dřív, než se o něm váš origin vůbec dozví:
- IP reputace a síťová filtrace — známé škodlivé zdroje a podvržené pakety padnou v nejlevnějším možném bodě.
- Výzva a ověření prohlížeče — neviditelná kontrola oddělí skutečné prohlížeče od automatizace dřív, než se spustí cokoli drahého.
- Rate limity — stropy na klienta a endpoint ohraničí cesty, které musí zůstat dynamické: přihlášení, vyhledávání, objednávka, obnova hesla.
- Kontrola WAF — provozu, který přežije, je málo, takže je vyhodnocení pravidel za požadavek únosné, a je natolik smysluplný, že se vyhodnocovat vyplatí.
- Cache — každý zásah je požadavek, který váš origin nikdy neobslouží; proto je CDN zároveň pancíř proti útokům.
Pořadí není detail. Dejte kontrolu WAF na první místo a platíte její cenu za každý útočný požadavek; dejte ji na konec a uvidí jen provoz, který už vypadá lidsky. Stejná úvaha mluví proti tomu koupit obojí od různých dodavatelů a zřetězit to: dvě proxy znamenají dva síťové skoky latence, dvě sady logů, které během incidentu musíte ručně spárovat, dva dashboardy, nad kterými máte přemýšlet ve tři ráno, a mnohem větší prostor pro chybu v konfiguraci, která útočníkům otevře cestu přímo na origin.
Co si ověřit, než koupíte jedno nebo druhé
- Běží obojí v jednom průchodu? Jedna proxy, jedna rozhodovací linka, jedny logy. Zřetězení dodavatelé přidávají latenci a párování dat přesně ve chvíli, kdy na to nemáte čas.
- Funguje WAF i pod útokem? Ptejte se, co se stane s vyhodnocováním pravidel při desetinásobku vašeho špičkového provozu. „Během mitigace se WAF vypíná" je odpověď, kterou některé produkty dávají.
- Poznáte, která vrstva co zablokovala? Rozbor po incidentu potřebuje důkaz na úrovni požadavku — verdikt, pravidlo, fingerprint klienta. Přesně na to jsou logy a analytika.
- Co zažijí skuteční uživatelé? Filtr, který hodí CAPTCHA všem, mění konverzi za dostupnost. Legitimní návštěvník má projít bez tření.
- Účtuje se vám útočný provoz? Být pod útokem by nemělo generovat fakturu. Ověřte si to před podpisem, ne při prvním incidentu.
- Jsou vlastní pravidla v ceně, nebo příplatek? WAF, do kterého si nemůžete napsat vlastní pravidla, je spravovaná sada pravidel s hezčím názvem.
Jak to řeší Itnetic
Itnetic staví celou linku na jednu edge síť před váš web a zapíná se změnou dvou DNS záznamů. Filtrace podle IP reputace zahodí známé škodlivé sítě, zatímco ověření dobří boti zůstávají povolení; neviditelná výzva oddělí skutečné prohlížeče od skriptovaných klientů, aniž by kdokoli viděl CAPTCHA; behaviorální signatury odhalí automatizaci, která předstírá prohlížeč; rate limity ohraničí vaše drahé endpointy; a WAF pravidla umožní povolit, blokovat nebo vyzvat podle cesty, hlavičky, metody, země či fingerprintu klienta. Cesty API lze označit tak, aby strojoví klienti dostali korektní stavové kódy místo výzvy, kterou nemají jak vyřešit — proč, to rozebírá jak chránit API před DDoS útoky.
Protože jde o jeden průchod, nese každý požadavek jediný verdikt, který si přečtete v logu požadavků: co bylo zablokováno, kterou vrstvou a proč. DDoS ochrana i WAF jsou součástí každého tarifu včetně bezplatného a útočný provoz se nikdy nepočítá do limitu přenosu.
Pokud se právě teď mezi obojím rozhodujete, poctivá odpověď zní, že je ta volba falešná — ale když musíte někde začít, začněte tím, co vás dokáže shodit. Podrobnosti o filtrační straně pak najdete v článku co je DDoS mitigace.