Uživatel vidí pomalý web nebo chybovou stránku. Administrátor vidí warning v monitoringu. Správce serveru vidí úplně jiný příběh — detailní, vrstvený a mnohdy alarmující.
Fáze 1 – Klid před bouří
Server běží normálně. Zátěž se pohybuje v rozmezí hodnot 0.3–0.8, procesy jsou v pořádku, logy rostou pomalu a pravidelně. Nic nenasvědčuje problému.
Fáze 2 – Začátek útoku
Správce si nejdříve všimne, že zátěž serveru začíná pomalu stoupat – z 0.8 na 1.5, pak na 3. Není to dramatické, ale trend je zřejmý. Souběžně se dějí věci, které admin ve webovém panelu neuvidí.
Logy přístupů rostou alarmující rychlostí. Každý požadavek znamená řádek v logu – při tisících požadavků za sekundu naroste log o stovky MB za hodinu. Co ráno zabíralo 50 MB, odpoledne může mít 8 GB.
Počet otevřených spojení stoupá. Server musí udržovat v paměti záznamy o všech příchozích připojeních, která se hromadí rychleji, než je možné jejich zpracování.
Worker procesy webserveru jsou plně obsazené. Každý příchozí požadavek si „zabere“ jedno místo ve frontě zpracování – typicky je jich k dispozici 100 až 200. Při útoku jsou všechna obsazená a nové požadavky čekají nebo jsou odmítnuty.
Fáze 3 – Eskalace
Situace se začíná vymykat. Zátěž přesahuje hodnotu 16 na serveru se 4 jádry – to znamená, že procesy čekají na přidělení výkonu čtyřnásobně déle, než by měly. Vše se zpomaluje kaskádovitě.
Fyzická RAM je plná. Systém začne odkládat část paměti na disk – takzvaný swap – což celou situaci výrazně zhoršuje, protože disk je řádově pomalejší než RAM.
Disk je vytížený na 90–100 % – ale ne kvůli databázi nebo aplikaci. Záznamy o útoku se zapisují tak rychle, že kapacita disku je vyčerpána samotným logováním.
Místo na disku dochází. Logy mohou zaplnit celý diskový oddíl během hodin. Pokud se tak stane, server přestane být schopen zapisovat cokoli – včetně databáze nebo dočasných souborů aplikace.
Zajímavý efekt: přenosová rychlost na síťovém rozhraní může být paradoxně nízká. Útočník neposílá velká data – posílá jen hlavičky HTTP požadavků, ale klidně 10 000 za sekundu. Server na každý reaguje, generuje záznamy a alokuje paměť.
Fáze 4 – Přetížení a výpadek
Systém se blíží kolapsu. Správce vidí jevy, které uživatel ani admin nikdy nezaznamenají.
Operační systém začne sám násilně ukončovat procesy, aby uvolnil paměť. V systémových záznamech se objeví hlášení, že byl bez varování zastaven třeba databázový server nebo aplikační vrstva. Žádné upozornění pro uživatele – věci prostě přestanou fungovat.
Může dojít k vyčerpání maximálního počtu procesů. Každý operační systém má nastavený strop – typicky tisíce až desítky tisíc současně běžících procesů. Jakmile je dosažen, nelze spustit žádný nový proces – ani vzdálené přihlášení správce není možné.
Pokud je disk zcela zaplněn, systém automaticky přepne do režimu jen pro čtení, aby předešel poškození dat. Server formálně „běží“, ale nic nezapisuje – databáze selhávají, aplikace hází chyby, nová připojení nejsou možná.
Při extrémním zatížení přestane operační systém stíhat ani zaznamenávat události – může přeskočit tisíce záznamů, protože je nestíhá zpracovat. Správce tak ztrácí přehled o tom, co přesně se děje.
Co útočník vidí vs. co vidí správce
| Co vidí útočník | Co vidí správce |
|---|---|
| Timeout nebo chyba 503 | Záznamy o násilném ukončení procesů |
| Pomalé odpovědi | Zátěž 16+ na 4jádrovém serveru |
| Nic – útok „funguje“ | Disk 100% zaplněný logy, swap vyčerpaný |
| Server stále odpovídá | Tisíce polootevřených spojení čekajících na vyřízení |
Poznámka k brute-force útokům
U brute-force útoků – opakovaných pokusů o přihlášení – je průběh mírnější, ale specifický. Správce vidí v bezpečnostních záznamech tisíce řádků o neúspěšných pokusech z jedné nebo více IP adres. Ochranné nástroje tyto adresy postupně blokují, ale záznamy mezitím narůstají. Efekt je stejný – logy rostou, disk se plní, a pokud není rotace logů správně nakonfigurovaná, může i tento zdánlivě „mírný“ útok server položit.
Jak tomu předejít? Nasadit ochranu předtím, než útok dorazí na server!
Všechny výše popsané situace mají jedno společné: odehrávají se přímo na koncovém serveru. Ten je na konci řetězce a dostává útok v plné síle – zpracovává každý požadavek, zapisuje každý log, alokuje paměť pro každé spojení.
Řešením není silnější server. Řešením je to, aby útok na koncový server vůbec nedorazil.
Přesně na tomto principu funguje WEDOS.Protection. Provoz zákazníka je přesměrován přes síť scrubbing center – specializovaných uzlů rozmístěných po světě – které škodlivý provoz zachytí, filtrují a odstraní dříve, než se vůbec dostane k samotnému serveru. Legitimní návštěvníci projdou, útok nikoliv.
Klíčovou technologií, která toto umožňuje, je BGP Anycast. Jde o způsob směrování provozu v internetu, kdy stejná IP adresa existuje na více místech světa současně. Pokud útočník pošle obrovský objem dat, internet jej automaticky nasměruje na nejbližší scrubbing centrum – a ne na server zákazníka. Scrubbing centrum má kapacitu a výkon na to, aby takový nápor vstřebalo. Koncový server mezitím ani netuší, že se něco děje.
V praxi to znamená, že správce serveru místo výše popsaného scénáře – rostoucí zátěže, plnícího se disku a násilně ukončovaných procesů – neuvidí nic. Zátěž zůstane na hodnotách 0.3–0.8. Logy porostou normálně. Server funguje, web je dostupný, zákazníci nakupují.
Útok pohltí naše síť. Ne váš server.