Itnetic TechnologiesCo plán reakce na DDoS je — a co není
Plán reakce na DDoS je jednostránkový provozní dokument, který předem říká, co váš tým dělá ve chvíli, kdy provoz přestane být provozem. Není to strategie mitigace ani její náhrada. Filtrovat útočný provoz je práce edge vrstvy; plán pokrývá všechno, co za vás edge rozhodnout nemůže: kdo incident vlastní, kdy eskalujete, co řeknete zákazníkům, jaké důkazy uchováte a kdy incident prohlásíte za ukončený.
Ten rozdíl je důležitý, protože se obojí plete dohromady. Pokud jste dole právě teď, potřebujete seřazený checklist v článku jak zastavit DDoS útok. Pokud vás zajímá mechanika samotné filtrace, přečtěte si co je DDoS mitigace. Tento průvodce je pro klidné odpoledne předtím, než bude potřeba jedno nebo druhé — hodina přípravy, která učiní hodinu incidentu zvládnutelnou.
Pět věcí, které rozhodněte před útokem
Každou z nich jinak někdo rozhodne pod tlakem, špatně a ve chvíli, kdy je web dole.
| Rozhodnutí | Vyřešte teď | Co stojí rozhodovat za běhu |
|---|---|---|
| Kdo je vedoucí incidentu | Jmenovitě osoba a záskok, s kontakty, které fungují ve 3:00 | Deset minut „řekl to někdo Petrovi?", během nichž nikdo nejedná |
| Co se počítá jako incident | Práh: chybovost, saturace originu, nebo spuštěný alert z mitigace | Dohadování, jestli tohle „fakt" je útok |
| Kdo smí zasahovat do produkce | Předem zmocněte vedoucího zpřísnit ochranu, zapnout challenge režim, víc cachovat | Čekání na schvalovací řetězec, který spí |
| Co se řekne zákazníkům | Připravené a schválené prohlášení včetně kanálu, kterým vyjde | Improvizovaná formulace, kterou pak musíte opravovat |
| Jaké důkazy se uchovají | Export logů, časové značky, cílené endpointy, vzorky ID požadavků | Rekonstrukce incidentu po paměti o týden později |
Role: kdo co dělá
Malé týmy nepotřebují organizační schéma, ale dvě jmenované role a oprávnění jednat.
- Vedoucí incidentu — vlastní časovou osu, rozhoduje a vede průběžný záznam kroků a časů. V jednočlenném týmu jste to vy a hodnota plánu spočívá v tom, že vám říká pořadí práce.
- Odpovědný za komunikaci — aktualizuje status page a odpovídá zákazníkům, aby vedoucí nepsal příspěvky během ladění. Ve dvoučlenném týmu je to ten druhý.
- Eskalační kontakty — cesta na podporu hostingu, cesta na podporu poskytovatele ochrany a u vydírání kontakt na policii, který byste skutečně použili. Do plánu patří i čísla účtů a adresy přihlášení; uprostřed incidentu nechcete hledat zákaznické ID.
Piště jména, ne funkce. „Pohotovostní inženýr" ve tři ráno není člověk.
První hodina, minutu po minutě
Plán by měl obsahovat takhle konkrétní časovou osu. Časy si upravte podle své sestavy, ale tvar zachovejte.
| Čas | Krok | Kdo |
|---|---|---|
| T+0 | Spustí se alert nebo přijde hlášení výpadku. Vedoucí incidentu potvrdí převzetí a zakládá záznam kroků | Vedoucí |
| T+5 | Potvrďte, že jde o útok, ne o nasazení nebo výpadek: objem požadavků proti normálu, koncentrace na endpointy, CPU originu versus přenos | Vedoucí |
| T+10 | Zpřísněte ochranu — nejpřísnější challenge režim, rate limity na cílené endpointy, cachování stránek pod palbou | Vedoucí |
| T+15 | Odchází první informace pro zákazníky, i kdyby říkala jen to, že situaci řešíte | Komunikace |
| T+30 | Ověřte, že origin není dosažitelný přímo a že ho neprozrazuje žádný neproxovaný DNS záznam | Vedoucí |
| T+45 | Sesbírejte důkazy: export logů za dané okno, poznamenané cílené cesty, zdroje a vzorky ID požadavků | Vedoucí |
| T+60 | Druhá aktualizace: stav a čas další zprávy. Rozhodnutí, zda eskalovat k poskytovatelům | Komunikace |
Nejčastější selhání téhle hodiny není technické. Je jím to, že krok přesměrování — vůbec dostat provoz přes filtr — se dělá poprvé uprostřed incidentu, zatímco se propaguje DNS. To je argument pro trvale zapnutou ochranu převedený do praxe: s DDoS ochranou Itnetic už před webem je T+10 změna nastavení, ne projekt nasazení, a prvních deset minut útoku se pohltí místo protrpí.
Ať se plán spustí sám
Plán, který začíná slovy „někdo si všimne, že je web pomalý", začíná pozdě. Zapojte tři nezávislé spouštěče:
- Externí monitoring dostupnosti mimo vaši vlastní síť, který kontroluje skutečnou stránku, ne health endpoint, jenž zůstává levný i pod zátěží.
- Alerty z mitigace na edge, které útok vidí dřív, než ho pocítí origin. Itnetic posílá alerty o útoku v reálném čase na Discord ve chvíli, kdy doména přejde do režimu útoku — upozornění tak dorazí do kanálu, který tým už čte.
- Zdravotní signály originu — CPU, počet spojení a chybovost na vlastním serveru, které odliší Layer 7 flood od objemové události.
Určete práh, který ze signálu udělá incident, a zapište ho jako číslo. „Chybovost nad 5 % po dvě minuty" je plán; „když to bude vypadat zle" je skupinový chat.
Co říct zákazníkům
Řekněte něco do patnácti minut a řekněte to srozumitelně. Před problémy vás uchrání dvě pravidla: nikdy neslibujte čas obnovení, který nemáte pod kontrolou, a nikdy neprozrazujte detaily obrany, které by útočníkovi pomohly doladit další vlnu.
Prohlášení, které stojí za to mít předschválené, zní zhruba takto:
Víme, že [služba] je pro část uživatelů pomalá nebo nedostupná, od [čas včetně časové zóny]. Příčinou je nápor škodlivého provozu a ochrana proti němu právě probíhá. Zákaznická data zasažena nejsou. Další informace zveřejníme do [čas].
Poslední věta je ta, která zastaví růst fronty na podpoře: publikum, které ví, kdy přijde další zpráva, se na ni přestane ptát. Pokud útok dorazil s požadavkem na platbu, o výkupném veřejně nemluvte a neplaťte — zdůvodnění i postup najdete v článku vyděračské DDoS útoky.
Sbírejte důkazy, dokud se to děje
Zpětný rozbor, pojistné události, dotazy vedení i hlášení policii potřebují tentýž materiál — a všechen se sbírá snáz během útoku než po něm:
- Časové značky začátku a konce v UTC a okamžik, kdy se každá změna ochrany projevila.
- Které endpointy byly cílem a jaké tempo požadavků snesly.
- Charakteristiky zdrojů: sítě, země, user agenty a otisky klientů.
- Vzorky ID požadavků pro blokovaný i propuštěný provoz, abyste později doložili, co prošlo.
- Kolik vás útok stál — výpočet najdete v článku kolik stojí DDoS útok.
Přesně k tomu slouží evidence na úrovni jednotlivých požadavků. Logy a analytika Itnetic zaznamenávají u každého požadavku stav, latenci, otisk klienta i verdikt WAF, takže rozbor je export, ne rekonstrukce. Ověřte si dobu uchování u svého poskytovatele dřív, než ji budete potřebovat — důkaz, který vyprší před vaším post-mortemem, není důkaz.
Šablona runbooku
Dokument udržte na jedné stránce. Delší se ve tři ráno nečte. Nadpisy, které si své místo zaslouží:
- Spouštěč — číselné prahy, které vyhlašují incident, a koho upozorní.
- Role — vedoucí incidentu, záskok, komunikace. Jména a telefonní čísla.
- První hodina — výše uvedená časová osa upravená na váš stack.
- Přístupy — kde je dashboard ochrany, registrátor DNS, hostingový panel a status page a kdo k nim drží přihlašovací údaje.
- Eskalace — cesty na podporu poskytovatelů včetně identifikátorů účtu a práh, od kterého je použijete.
- Komunikace — předschválené prohlášení, kanál a frekvence aktualizací.
- Důkazy — výše uvedený seznam a místo, kam se export ukládá.
- Ukončení — co znamená „konec" (provoz a chybovost zpět na normálu po stanovenou dobu), kdo ho vyhlásí a kdo vrátí nouzová nastavení.
Uložte ho tam, kam se dostanete, i když je váš web dole — do sdíleného dokumentu, ne na wiki za originem, který se právě snažíte ubránit. Pokud je váš tým dost malý na to, aby to znělo rozumně a ne staromódně, vytiskněte si kopii.
Nacvičte ho, jinak je to fikce
Dvakrát ročně projděte plán od začátku do konce: zavolejte vedoucímu, otevřete dashboardy, ověřte, že přihlašovací údaje fungují, a publikujte zkušební zprávu na testovací status page. Cílem není simulovat záplavu — cílem je zjistit, že alert chodí na adresu bývalého kolegy nebo že DNS umí měnit jediný člověk. Bezpečné a legální způsoby, jak procvičit technickou polovinu, popisuje jak otestovat DDoS ochranu.
Pak uzavřete kruh u té části plánu, kterou lze úplně odstranit: u kroků, které existují jen proto, že ochrana ještě není zapnutá. S trvale zapnutou edge filtrací, originem uzamčeným na síť poskytovatele ochrany a útočným provozem, který se vám nikdy neúčtuje, se plán smrskne na pozorování, komunikaci a záznam — a to je plán, který malý tým skutečně zvládne provést.