Vektor je technika, ne číslo
Většina zpráv o DDoS útocích uvádí jedno číslo: špičkovou propustnost nebo špičkový počet požadavků. To číslo vám ale o obtížnosti obrany neřekne téměř nic. Rozhoduje, kolik různých technik útok používá, protože každou techniku musí zastavit jiný mechanismus na jiném místě.
Jednovektorový útok je jedna technika: SYN flood, DNS amplifikace, nebo záplava HTTP požadavků. Multivektorový útok jich proti stejnému cíli vede několik současně nebo za sebou.
| Vrstva | Vektor v mixu | Co se snaží vyčerpat |
|---|---|---|
| 3 — síťová | UDP amplifikace, reflektované záplavy, ICMP floody | Kapacitu vaší linky a kapacitu výš v síti |
| 4 — transportní | SYN, ACK a RST floody, vyčerpání TCP stavů | Tabulky spojení a rozpočet na zpracování paketů |
| 6 — TLS | Záplavy handshaků a renegociací | Cykly CPU spálené na asymetrické kryptografii |
| 7 — aplikační | Záplavy HTTP požadavků, query stringy obcházející cache, low and slow | Workery, spojení do databáze, CPU originu |
Proč to má praktický dopad: objemová záplava 300 Gbps na jednom vektoru je problém kapacity a kapacitu lze koupit. Útok o 2 Gbps, který rotuje mezi čtyřmi řádky výše, je problém architektury — a ten žádné množství pásma nevyřeší.
Proč útočníci vektory rotují
Útočná kapacita se pronajímá na hodiny a provozovatel chce váš výpadek za nejnižší náklad. Rotace je způsob, jak najít levnou cestu dovnitř. Postup je téměř vždy stejný:
- Ozkoušet. Pošle krátkou vlnu na jednom vektoru a sleduje, co se stane — zpomalí web, vyprší časový limit, vrátí se výzva, vrátí se chybová stránka od jiného serveru než předtím?
- Přečíst odpověď. 503 z vašeho originu znamená, že k němu záplava dorazila. Čistá blokační stránka znamená, že nedorazila. Zpomalený, ale živý web znamená, že jste blízko limitu.
- Soustředit se. Tlačit ten vektor, který na jednotku pronajaté kapacity způsobil největší degradaci.
- Přepnout, až to přestane fungovat. Jakmile se mitigace přizpůsobí, přejít na jinou vrstvu a zopakovat.
Proto je „první vlnu jsme přežili" tak slabý signál. První vlna byl průzkum. Veřejné doporučení CISA říká totéž o tom, že krátký výpadek je třeba brát jako varování, ne jako závěr.
Je tu ještě druhý motiv, o kterém je dobré vědět: odvedení pozornosti. Hlučná objemová záplava zaměstná všechny a zaplní každý graf, zatímco pod ní běží tichý aplikační útok s nízkou intenzitou — credential stuffing na přihlašovacím endpointu, stahování sortimentu, testování karet v košíku. Záplava není útok. Je to krytí.
Modelový incident minutu po minutě
Časová osa níže je složenina toho, jak tyto incidenty skutečně probíhají, ne log jednoho zákazníka. Důležitý je tvar, který se máte naučit poznávat.
| Čas | Co dělá útočník | Jak to vidíte vy |
|---|---|---|
| T+0 | 40 Gbps UDP amplifikace na IP adresu | Linka je ucpaná, nic není dostupné, monitoring budí všechny |
| T+8 | Objemová část končí; začíná SYN flood o několika stech tisíc paketů za sekundu | Graf propustnosti padá na normál — vypadá to, že útok skončil. Neskončil |
| T+20 | SYN flood končí; 80 tisíc požadavků za sekundu obyčejných HTTP GETů s náhodnými query stringy | Propustnost stále normální, CPU na 100 %, cache hit rate se hroutí, origin vrací 502 |
| T+35 | Počet požadavků padá na 900 za sekundu rozprostřených mezi 40 tisíc rezidenčních adres, míří jen na vyhledávání a přihlášení | Vypadá to jako organický provoz. Vyčerpá se pool databázových spojení. Žádná jednotlivá IP nepřekročí váš limit |
| T+60 | Otevřená a držená spojení se pomalým čtením napříč všemi workery | Vyčerpaná konkurence při téměř nulové propustnosti. Nic v alertech na pásmo ani na počet požadavků se neozve |
| T+90 | Vrací se objemová část, teď míří na hostname místo na IP | Druhý incident ohlašuje tým, který je vzhůru už hodinu a půl |
O výsledku rozhodují tři věci z té tabulky a žádná z nich není kapacita. Graf propustnosti, který v T+8 utichne, je past — je to moment, kdy týmy incident uzavřou. Přepnutí v T+35 je to, co porazí většinu rate limitů, protože limit je navázaný na IP a žádná jednotlivá adresa ho nepřekročí. A fáze v T+60 je neviditelná pro jakýkoli alerting postavený na objemu, což je většina alertingu.
Proč tady selže právě jednovrstvá obrana
Každá z těchto obran má svůj smysl. Každá pokrývá některé řádky tabulky výše a žádný z ostatních.
| Obrana | Pokrývá | Nevidí |
|---|---|---|
| Hardware u vás v racku | L4 a část L7, do detailu | Cokoli, co ucpe linku před ním — pakety se k němu nedostanou |
| Scrubbing u ISP nebo hostingu | Objemové L3/L4 výš v síti, se skutečnou kapacitou | Celou Layer 7: správně tvarovaný HTTP GET je podle všech jeho metrik platný provoz |
| Samostatný WAF | Škodlivé jednotlivé požadavky | Záplavy jednotlivě platných požadavků a každý paketový vektor |
| Samostatná CDN | Cachovatelnou zátěž, což je většina provozu | Query stringy obcházející cache, necachovatelné cesty, přihlášení a košík, POST těla |
| Autoscaling | Provoz, který chcete obsloužit | Provoz, který nechcete — platíte za obsluhu útoku a útočník škáluje levněji než vy |
Problém není, že by některá z nich byla špatná. Problém jsou švy mezi nimi. Když se vektor změní v T+20, otázka je, jestli to, co zvládlo T+0, a to, co má zvládnout T+20, leží na jedné cestě, sdílí stav a přizpůsobuje se spolu — nebo jestli si musí předání všimnout člověk a jít něco nastavit.
Tři selhání detekce, která incident prodraží
Alerty jen na objem. Propustnost a celkový počet požadavků jsou dvě metriky, na které alertuje téměř každý, a fáze T+35 a T+60 výše nepřekročí ani jednu. Alertujte i na chybovost, latenci originu, cache hit ratio, konkurenci a vytížení poolu databázových spojení. I když je abnormální jen jedna z nich, incident máte.
Odvolání poplachu po utišení jednoho vektoru. Konec jednoho vektoru není konec útoku. Nechte incident — a mitigaci — zapnuté po předem definovanou dobu klidu, ne do prvního čistého grafu. Délku té doby si určete před útokem, jako součást svého plánu reakce na DDoS.
Rate limity navázané jen na IP. Proti 40 tisícům rezidenčních adres, z nichž každá posílá 0,02 požadavku za sekundu, je limit na IP aritmeticky zbytečný — to je hlavní argument článku co je rate limiting. Drahé endpointy navažte na účet, session, API klíč nebo fingerprint klienta, aby limit přežil rozprostření.
Jak se multivektorový útok skutečně mitiguje
Mitigace musí být vrstvená stejně jako útok a musí už běžet. Minuty, které strávíte zapínáním ochrany, jsou minuty výpadku — a to je celý argument pro always-on místo on-demand v článku co je DDoS mitigace.
| Vektor v mixu | Co ho zastaví | Kde to musí proběhnout |
|---|---|---|
| Objemové L3 záplavy | Kapacita k pohlcení a bezstavové zahazování paketů | Výš v síti nad vaším serverem, kde kapacita je |
| SYN a vyčerpání stavů | Validace handshaku, SYN cookies, zahození v kernelu | Na edge, dřív než se spojení začne sledovat |
| Záplavy TLS handshaků | Ukončení spojení na edge, rozpočet handshaků na zdroj | Na edge PoPu, ne na vašem originu |
| Záplavy HTTP požadavků | Cache na edge, modely běžného chování, neviditelný proof-of-work | Na edge, pro každý host a endpoint zvlášť |
| Rozprostřená L7 s nízkou intenzitou | Rate limity navázané na identitu, JA4 a behaviorální fingerprinting | Na edge, navázané na něco jiného než IP |
| Low and slow | Agresivní timeouty, bufferování požadavků, ukončení spojení na edge | Na edge, měřeno konkurencí, ne objemem |
| Query stringy obcházející cache | Normalizace query stringu a WAF pravidla na daný vzorec | Na edge cache |
Obranou místo seznamu to dělají dvě vlastnosti:
Jedna cesta, společný stav. Když všechny vrstvy leží na jedné trvale zapnuté cestě, verdikt o klientovi z T+20 platí i v T+35, i když se vektor změnil a fingerprint se přesunul na jiné endpointy. Slepenec samostatných produktů přesně tuhle návaznost na švech ztrácí.
Přepočet modelu pro každý vektor uvnitř incidentu. Přizpůsobení je čtvrtá fáze mitigace a u multivektorového útoku ta rozhodující. Model běžného provozu pro daný host a endpoint, který se přehodnocuje v sekundách, označí přepnutí v T+35 za anomálii, i když jeho absolutní objem je nezajímavý. Statický práh nastavený před incidentem ne.
A nic z toho nedrží, pokud je váš origin dostupný přímo. Útočník rotující vektory zkusí IP stejně ochotně jako hostname — viz T+90 v tabulce — takže nastavte firewall tak, aby origin přijímal provoz jen z vaší mitigační sítě. Postup je v článku jak skrýt IP adresu originu.
Na co se ptát poskytovatele
- Je mitigace na Layer 3/4 i na Layer 7 trvale zapnutá, a na jedné cestě? Pokud se jedna z nich zapíná na vyžádání, útočník se usadí přesně na ní.
- Jak rychle detekce přepočítá model, když se vektor změní? Užitečná odpověď je v sekundách, rozhodnuto na edge, bez cesty do control plane a zpět.
- Můžu rate limit navázat na něco jiného než na IP? Na účet, session, API klíč nebo fingerprint klienta. Pokud je odpověď „jen IP", rozprostřená Layer 7 jím projde.
- Mám všechny mitigační funkce dostupné na svém současném tarifu? Během rotujícího útoku budete chtít WAF pravidlo, rate limit, čekárnu a syrové logy v jedné hodině. Jakmile kterákoli z nich leží o tarif výš, z reakce na incident se stává jednání o objednávce.
- Objeví se útočný provoz na mé faktuře? Objemové vektory přenesou hodně bajtů. Za to, že vás někdo napadl, nemá přijít účet — viz kolik stojí DDoS útok.
- Uvidím důkazy na úrovni požadavku během incidentu, ne až po něm? Rotaci vektoru, kterou nevidíte, nemůžete rozpoznat. Na to jsou logy a analytika.
Zatímco to běží
Reakci držte krátkou a v pořadí. Plná verze je jak zastavit DDoS útok; multivektorově specifické jsou tyto body:
- Neodvolávejte poplach kvůli utišenému grafu. Nechte mitigaci zapnutou po celou předem určenou dobu klidu.
- Sledujte tvar, ne velikost. Které endpointy, které fingerprinty, které stavové kódy — velikost vám o dalším kroku neřekne nic.
- Chraňte nejdřív drahé cesty. Přihlášení, vyhledávání, košík a vše, co zapisuje do databáze. Tyhle padají při objemech, které by se jako útok vůbec neprojevily.
- Předpokládejte krytí. Zatímco běží záplava, zkontrolujte chybovost přihlášení a chybovost v košíku. Tichý útok pod ní je ten, který stojí peníze.
- Zapisujte rotaci. Každou změnu vektoru a její čas si poznamenejte, jak se děje. Je to jediný záznam, který budete mít, a je to on, co příští incident zkrátí.
Kde do toho zapadá Itnetic
Itnetic je postavený přesně na dělení, které tento článek popisuje. Objemové záplavy na Layer 3/4 se pohlcují výš v síti nad naším edge, dřív než dorazí na aplikační vrstvu — a na stránce sítě zveřejňujeme, které sítě to dělají a jakou mají kapacitu, místo abychom číslo jen naznačovali. Všechno od TCP handshaku nahoru je naše: validace handshaku, ukončení TLS, cache na edge, behaviorální a JA4 fingerprinting, neviditelný proof-of-work místo CAPTCHA, rate limity navázané na identitu a adaptivní detekce po hostech, která přepne do režimu výzev přibližně do sekundy od špičky a tenhle verdikt rozešle na všechny ostatní uzly.
Všechno běží na jedné trvale zapnuté cestě, v každém tarifu včetně toho zdarma. Naše plány se liší počtem domén a doručeným pásmem a ničím jiným, takže vektor, který přijde v T+35, se nikdy nezmění v rozhodování o upgradu — a útočný provoz vám nikdy nepočítáme do limitu přenosu.
Chcete to mít nasazené dřív, než přijde další rotace? DDoS ochrana od Itnetic jsou dva DNS záznamy a asi pět minut, s bezplatným plánem Starter a ceníkem od 5 € měsíčně. Pokud útok běží právě teď, nečtěte dál a začněte nouzovým postupem.