Jak otestovat DDoS ochranu.

Neotestovaná obrana je jen hypotéza

DDoS ochrana se kupuje jako hlásič kouře: nainstalujete ji, blikne kontrolka a zbytek předpokládáte. Rozdíl je v tom, že hlásič kouře má testovací tlačítko. Většina nasazených mitigací dostane první poctivý test až od samotného útoku, v hodinu, kterou vybral útočník.

A když ochrana v praxi selže, skoro nikdy to není proto, že by síť neustála objem. Selže na konfiguraci, která vypadala naprosto správně v den, kdy vznikla:

• IP originu pořád odpovídá napřímo, takže záplava edge úplně obejde.
• Jeden hostname — staging, mail, api-v1 — se nikdy nepřesunul a míří rovnou na tentýž server.
• Rate limit stojí na čísle, které nikdo nikdy neporovnal se skutečným provozem, a jako první přiškrtí vaši vlastní mobilní aplikaci.
• Filtrace je on-demand a člověk, který ji smí zapnout, spí.
• Útok se odfiltruje správně a potom není co ukázat zákazníkovi, pojišťovně ani vlastnímu vedení.

Ani jedno z toho není problém kapacity a všechno se to dá najít v klidné úterní odpoledne.

Pravidlo jedna: nikdy si nekupujte útok na test obrany

Zkuste hledat způsob, jak otestovat DDoS ochranu, a první výsledky budou služby prodávající útočný provoz po minutách, prodávané jako „IP stresser" nebo „zátěžový test vlastního serveru". Nepoužívejte je, a to ze tří důvodů, seřazených podle toho, jak moc by vám na nich mělo záležet.

1. Je to trestné a obhajoba „je to můj server" neobstojí. Neoprávněný zásah do počítačového systému je trestný čin podle českého trestního zákoníku i podle obdobné úpravy napříč EU, Spojeným královstvím a USA. I když je cíl váš, provoz jde přes sítě, které vaše nejsou, generují ho stroje, jejichž majitelé k tomu nedali souhlas, a končí na infrastruktuře, na kterou podle vaší hostingové smlouvy útočit nesmíte. Při zásazích policie proti těmto službám se pravidelně zveřejňují jejich zákaznické databáze; být v jedné z nich je nepovedené odpoledne.
2. Platíte lidem, kteří útočí na všechny ostatní. Tyto služby běží na kompromitovaných routerech, kamerách a serverech. Váš poplatek za test financuje botnet, který se objeví v cizím incidentu — a případně později i ve vašem.
3. Odpovídá na otázku, kterou jste nepoložili. Kupujete si čistý objem, a objem je právě ta část, kterou váš poskytovatel zvládá nejlépe a vy ji ovlivníte nejméně. Neřekne vám nic o tom, jestli máte limity klíčované správně, jestli vaši API klienti přežijí zavřenou bránu, ani jestli je origin pořád odhalený. Weby shazují útoky na aplikační vrstvě a ty vám žádný booter neprodá.

Všechno, co stojí za zjištění, se dá zjistit cílenými funkčními kontrolami vlastní infrastruktury a autorizovaným zátěžovým testem, který si spustíte sami. O tom je zbytek této stránky.

Co vlastně testujete

Vaše ochrana dává šest slibů. Testujte je odděleně, protože selhávají odděleně.

Test 1 — Je origin pořád dosažitelný mimo edge?

Tohle je ten test, který něco najde. Odhalený origin dělá ze všech ostatních obran volitelnou položku: útočník míří na IP adresu a vaše filtrace ty pakety nikdy neuvidí.

Ze sítě, která není vaše kancelář ani váš CI runner, se serveru zeptejte napřímo — curl -sI --resolve vasedomena.cz:443:IP_ORIGINU https://vasedomena.cz — a podívejte se, co přijde zpátky. Stránka znamená, že jsou dveře otevřené. Zopakujte to na portu 80 a na všech administračních nebo aplikačních portech, které váš stack vystavuje.

Pak je zavřete: omezte firewall na originu jen na rozsahy edge svého poskytovatele, aby se cokoli jiného zahodilo místo odpovědi. A všimněte si, jak vypadá správný výsledek při opakovaném testu — timeout, ne 403. Odmítnutí dokazuje, že paket dorazil, což znamená, že útočník pořád dokáže váš server přimět utrácet zdroje za rozhodnutí říct ne.

Druhá polovina cvičení je najít samotnou adresu a útočníci k ní mají víc cest než jen přímé DNS: historické DNS záznamy, logy certificate transparency, hlavičky e-mailů a chybové stránky, které prozradí interní hostname. Kompletní přehled je v jak skrýt IP adresu originu — projděte ho jako součást tohoto testu, ne místo něj.

Test 2 — Je opravdu každý hostname za edge?

Ochrana platí pro jména, která jste na ni nasměrovali, a pro žádná jiná. Udělejte si inventuru všech A, AAAA a CNAME záznamů ve všech zónách, které vlastníte — včetně těch zděděných po předchozím týmu — a každý zařaďte do jednoho ze dvou sloupců: za edge, nebo mimo.

Ve špatném sloupci obvykle končí: staging, dev, old, legacy, vpn, direct, origin, cpanel, regionální varianty a marketingový mikroweb, který někdo postavil ke kampani v roce 2023. Cokoli, co míří na adresu originu, je zveřejněné obejití ochrany a útočník procházející vaše DNS to najde během pár sekund.

Když už u toho jste, ověřte, že edge dělá víc než jen přeposílá. Vyžádejte statický asset dvakrát a zkontrolujte cache hlavičku v druhé odpovědi: samý MISS znamená, že origin pořád obsluhuje každý bajt, a pod zátěží padne přesně tak rychle, jako by padl bez CDN. Cachovatelný provoz obsloužený z edge není kosmetika výkonu — je to kapacita, která vám během útoku zůstane.

Test 3 — Spustí se vaše limity a odpoví jazykem, kterému klienti rozumí?

Rate limity jsou nejčastěji špatně nastavený prvek v celém stacku a jejich selhání míří na obě strany: příliš vysoký limit se nikdy nespustí a limit klíčovaný na sdílenou IP přiškrtí celou kancelář, mobilního operátora nebo univerzitu za jedním NATem.

Spusťte umírněný, řízený burst — pár stovek požadavků za minutu z jednoho zdroje, což je hluboko pod tím, co váš origin obslouží v běžný den — proti testovací cestě, kterou jste k tomu účelu vytvořili. Ne na přihlašovací endpoint a ne z kancelářské IP, kterou potřebujete mít funkční. Pak zkontrolujte čtyři věci:

• Spustí se tam, kde myslíte. Pokud je dokumentovaný limit 100 požadavků za minutu a při 400 se nic neděje, pravidlo nedělá to, co tvrdí dashboard.
• Odpovědí je 429 s hlavičkou Retry-After. Ne HTML stránka s výzvou, ne 302, ne 200 s chybou v těle. Strojový klient, který odmítnutí nedokáže přečíst, zkouší tvrději a přidá se k záplavě — celý argument najdete v jak chránit API před DDoS útoky.
• Klíč je ten, který jste zamýšleli. Podle přihlašovacího údaje u autentizovaných cest, podle IP jen tam, kde nic lepšího není. Ověřte to tak, že na stejný limit narazíte ze dvou různých účtů na jednom spojení a z jednoho účtu na dvou spojeních.
• Limit se uvolní. Má vypršet podle plánu, ne držet klienta venku hodinu, protože se čítač nikdy nesnížil.

Test 4 — Co zažije skutečný klient, když se brána zavře?

Každý přísnější režim ochrany utahuje šrouby nejen útočníkům, ale i někomu legitimnímu. Chcete vědět komu — dřív, než to za vás rozhodne útok.

Vyberte si okno se slabým provozem, vědomě přepněte ochranu na pár minut do nejpřísnějšího režimu a projděte si vlastní funnel: domovská stránka, vyhledávání, přihlášení, objednávka — na desktopu, v mobilním prohlížeči a ve vaší vlastní mobilní aplikaci. Pak klienti, kteří žádný prohlížeč nemají: API integrace, platební callbacky, odesílatelé webhooků, monitoring dostupnosti, kontrola status page a vyhledávací roboti, na jejichž výsledcích vám záleží.

Co tenhle test spolehlivě odhalí: smyčky výzev u klientů bez cookies, tiše selhávající webhooky od platební brány a monitoring, který začne budit lidi, protože ho obrana zařadila mezi boty. Sepište všechno, co se rozbije, opravte to teď explicitním povolením nebo výjimkou pro API cesty a seznam si nechte — během skutečného útoku nikdo dokumentaci číst nebude.

Test 5 — Dokážete potom doložit, co se stalo?

Mitigace, která funguje a nenechá po sobě záznam, vás stejně něco stojí. Účet za incident dorazí o pár dní později v dotazech zákazníků, v žádosti pojišťovny o podklady a v poincidentním rozboru — a všichni tři chtějí konkrétní čísla. Zbytek té faktury je v kolik stojí DDoS útok.

Otestujte to tedy: vezměte okno, které jste způsobili v testu 3, a zrekonstruujte ho jen ze svého dashboardu. Kolik požadavků, z jakých sítí, na jaké cesty, které pravidlo se spustilo a jaký stav klient dostal? Pokud odpověď trvá víc než pár minut nebo vyžaduje SSH na server, nemáte záznam, ale archeologický projekt — a archeologický projekt zákazníkovi tentýž den nepředáte.

Ve stejném průchodu stojí za ověření dvě věci. Uchovává váš poskytovatel detail na úrovni požadavku, nebo jen souhrnné grafy, které ukážou špičku, ale nikdy ne, kdo v ní byl? A počítá se blokovaný provoz do vaší kvóty — protože obrana, která z útoku udělá fakturu, náklad jen tiše přesunula, místo aby ho odstranila.

Test 6 — Runbook a lidé v něm

Doba do nasazení mitigace je přinejmenším stejně často lidské číslo jako technické a žádný nástroj ji nezměří. Vyhraďte si dvacet minut, odložte klávesnice a odpovězte nahlas:

• Kdo si toho všimne? Které upozornění, do jakého kanálu a kdo drží telefon v neděli ve dvě ráno.
• Kdo smí měnit režim ochrany? Má funkční přihlašovací údaje na zařízení, které nosí u sebe, nebo je heslo ve správci, který běží za webem, jenž je zrovna dole?
• Co se dozvědí zákazníci a kde? Někdo to musí napsat a musí to jít zveřejnit někde, co nesdílí origin s tím, co je právě mimo provoz.
• Co výslovně neuděláme? Vyplatí se dohodnout předem: neplatíme výkupné a neblokujeme celou zemi, které prodáváme, jen proto, že ve tři ráno vypadal graf hrozivě.
• Kdo incident prohlásí za ukončený a na základě čeho? Útoky chodí ve vlnách a druhá vlna obvykle dopadne na tým, který už si oddechl.

Napište odpovědi na jednu stránku a uložte je tam, kam se dostanete z telefonu. Pokud je vaše ochrana on-demand místo always-on, tohle cvičení je vaše obrana — každá minuta mezi „útok začal" a „někdo se přihlásil" se účtuje plnou hodinovou cenou výpadku. Argument pro always-on filtraci najdete v co je DDoS mitigace a je to hlavně tohle.

Zátěžový test je užitečný — jen to není test obrany

Autorizovaný zátěžový test vlastního stacku má smysl. Buďte si jen jasní v tom, co měří: kapacitu vašeho originu, kde začíná saturace, jestli autoscaling zareaguje včas a který endpoint povolí první. Co změřit nedokáže, je jestli váš edge pozná útočníka od zákazníka — protože váš generátor zátěže je slušně vychovaný klient, který posílá poctivé požadavky z jednoho místa.

Základní pravidla, pokud test spustíte:

• Testujte proti stagingu postavenému jako kopie produkce, nebo v produkčním okně, které jste interně ohlásili.
• Řekněte to předem hostingu i poskytovateli mitigace — oba mají v podmínkách ustanovení o generované zátěži a jeden z nich by vás jinak mohl odfiltrovat.
• Zvyšujte zátěž postupně, sledujte metriky originu místo počtu úspěchů na straně klienta a mějte dokumentovaný způsob, jak test okamžitě zastavit.
• Nikdy nemiřte generátorem na infrastrukturu, kterou nevlastníte, včetně edge poskytovatele. Měřit kapacitu CDN z jednoho stroje znamená měřit jen to, jak rychle vám přiškrtí vlastní účet.

Dejte to do kalendáře

Selhání, kterému má tenhle plán předejít, není nedbalost. Je to migrace: přestavěný server, nová subdoména, pravidlo firewallu povolené kvůli nasazení a nikdy nevrácené zpátky. Konfigurace se tiše vrací k odhalenému stavu a obrana ověřená jednou je obrana ověřená pro infrastrukturu, kterou už neprovozujete.

Jak Itnetic testování usnadňuje

Několik z těchto testů je těžších, než by muselo být, protože platforma pod nimi nikdy nebyla stavěná na to, aby do ní šlo vidět. Ta naše ano.

Není co selhat na lidském kroku. Filtrace u Itneticu je always-on, ne něco, co zapínáte uprostřed incidentu, takže test 6 se smrskne na komunikaci a přístupy — není žádný přepínač, který by šlo zapomenout přepnout, ani fronta ticketů mezi začátkem útoku a začátkem filtrace.

Test 5 je export, ne vykopávka. Logy na úrovni požadavku nesou metodu, cestu, stav, latenci, TLS detaily, otisk klienta i přesné WAF pravidlo a verdikt za každým rozhodnutím, včetně kopírovatelného ID požadavku. Časová osa útoku dělí provoz na povolený, vyzvaný a blokovaný sekundu po sekundě a označí okamžik, kdy se automaticky spustil režim útoku — přesně ten důkaz „naskočila mitigace, a kdy", který poincidentní rozbor chce.

Test 3 na strojových cestách projde už z principu. Označte prefix jako /api/ jako API zónu a odpovídající požadavky nikdy nedostanou výzvu ani přesměrování: omezený klient dostane 429 s Retry-After, klíčované podle přihlašovacího údaje místo sdílené IP.

Pravidla si otestujete dřív, než začnou kousat. Vlastní WAF pravidla umí běžet v režimu pouhého logování nad živým provozem, takže přesně uvidíte, které skutečné požadavky by pravidlo zachytilo, ještě než mu dovolíte cokoli blokovat.

Testování negeneruje fakturu. Útočný provoz se odfiltruje a nikdy se nepočítá do vaší kvóty přenosu — viz ceník — takže ani test, ani skutečný útok se nepromění v účet za data. Upozornění do Discordu v reálném čase odpovídají na otázku „kdo si toho všimne" z testu 6 a tarif Starter je zdarma, takže všechny kontroly z této stránky můžete projet na skutečné doméně bez nákladů. Spuštění jsou dva DNS záznamy a asi pět minut.

Projděte šest testů a stane se jedna ze dvou věcí. Buď nenajdou nic a vy jste strávili odpoledne tím, že jste z domněnky udělali fakt. Nebo něco najdou — a při prvním průchodu obvykle najdou origin, který pořád odpovídá — a našli jste to v hodinu, kterou jste si vybrali vy, ne v té, kterou vybere útočník.

Jste pod útokem právě teď? Přestaňte testovat a začněte filtrovat: jak zastavit DDoS útok.