Čím více se šíří povědomí o WEDOS Global a přichází k nám stále více a více nových zákazníků, kteří mají s DDoS útoky problém, tím frustrovanější jsou i útočníci. To vede k intenzivnějším útokům na náš web a infrastrukturu. Někdy se opravdu snaží, a my tak získáváme cenná data a zkušenosti 🙂 .
Na našem webu tak můžeme testovat nové metody ochrany před DDoS útoky, zkoumat jejich efektivitu a zátěž na cílový server. 20. 11. 2023 jsme otestovali novou formu ochrany, která skvěle funguje proti „hloupým“ L7 DDoS Flood útokům.
Co je L7 DDoS útok?
HTTP L7 Flood útok je forma DDoS, která cílí na 7. vrstvu modelu OSI (Open Systems Interconnection), tedy na aplikační vrstvu. Tento typ útoku je zvláště zákeřný, protože využívá legitimně vypadající HTTP požadavky k přetížení cílového webového serveru nebo aplikace. Útočníci generují obrovské množství HTTP požadavků GET nebo POST, které mohou být maskovány tak, aby vypadaly jako běžný uživatelský provoz, což komplikuje jejich detekci a blokování.
Projevy HTTP L7 Flood útoku zahrnují významné zpomalení nebo úplný výpadek webové služby, abnormálně vysoké využití serverových zdrojů (CPU, paměť) a nárůst počtu HTTP požadavků zaznamenaných v log souborech, často z několika tisíc IP adres a stovek sítí. Tyto útoky mohou vést k částečnému nebo úplnému výpadku poskytovaných služeb.
Blokování HTTP L7 Flood útoků je výzvou z několika důvodů:
- Maskování jako legitimní provoz: Útoky na aplikační vrstvu často vypadají jako běžný uživatelský provoz, což komplikuje jejich odlišení od legitimních požadavků.
- Rozmanitost a složitost aplikací: Aplikace na vrstvě 7 mají různé funkce a charakteristiky, což ztěžuje vytvoření jednotné obranné strategie.
- Nízká předvídatelnost útoku: Útoky mohou být vysoce proměnlivé co do objemu, trvání a použitých technik, což vyžaduje adaptabilní obranné mechanismy.
Pro nás je detekce L7 DDoS Flood útoků technicky jednodušší, protože reverzní proxy mezi uživatelem a cílovým serverem vidí do provozu. Mohou jej tak detailně analyzovat, což je základ pro některé pokročilejší formy L7 útoků, a dokonce do něj vstoupit.
Toho využíváme například u nových zranitelností WordPress, kde útok zneužívá nějaký neošetřený vstup. Naposledy jsme takto manuálně přidali pravidlo, které eliminovalo riziko nové zranitelnosti v pluginu WP Fastest Cache pro WordPress (CVE-2023-6063). Útočník pomocí upravené cookie mohl provést SQLi útok na libovolnou instalaci. Požadavek s cookie obsahující SQLi jsme eliminovali.
Máme tedy velmi detailní přehled o každém požadavku směřujícím na chráněný web zákazníka, který daleko překračuje běžné logování (access log, error log), a také máme opravdu širokou škálu možností, jak zareagovat. Když si to spojíte s agregací dat ze všech webhostingů a chráněných webů, tak násobně rostou naše možnosti detekce úplně nových hrozeb, zranitelností, botnetů a tak dále.
Jak (ne)zablokovat útok
V říjnu jsme začali intenzivně pracovat na cachování obsahu chráněných webů. V listopadu jsme pak hromadně nasadili cachování pro všechny, což vedlo k razantnímu zrychlení. Je obrovský rozdíl, když cachujete obsah přímo na hostingu, nebo na našich reverzních proxy, které jsou k tomu určené.
Reverzní proxy jsou vždy blíže k návštěvníkům – máme servery v desítkách lokací po celém světě a postupně je propojujeme do lokálních a národních internetových uzlů (IXP). Takže náš reverzní server je přímo propojen k poskytovateli internetového připojení vašich zákazníků. Dále v lokalitách máme specializované servery na cachování, které využívají jen k tomu určený software. Je velký rozdíl, když cachovaný obsah vrací váš webserver, nebo náš specializovaný reverzní proxy server.
Vyjádřeno v číslech jsou to desítky až nižší stovky ms vs 1–2 ms. Navíc i cachovaný obsah na vašem webserveru stojí výpočetní výkon a konektivitu, což u nás neřešíte. Nám je jedno, jestli vrátíme deset nebo milion cachovaných stránek.
Ale zpět k tématu. Po odladění cache jsme si všimli, že vrátit cachovaný obsah je, co se týká serverových zdrojů, daleko levnější než třeba captcha, která se musí generovat. Stejně tak to je s dalšími druhy ochran, které pracují například s přesměrováním. Takže co vracet útočníkům prostě cache a vůbec je neblokovat?
Tento experiment jsme provedli v pondělí 20. 11. 2023, kdy šel útok na náš web a jednu podstránku. Vzorec útoku „hloupých“ L7 DDoS útoků je v posledních dnech stejný. Hlavní stránka našeho webu a nějaká podstránka, občas okořeněno parametrickými útoky. Pokud používáte WordPress, je snadné se tomu bránit.
Útok trval zhruba pět a půl minuty. Celkem přišlo 8,8 milionů požadavků ze zhruba 2 tisíc unikátních IP adres. Špička 2,4 milionu za minutu. Tohle jsou jen požadavky, které prošly přes blacklisty, různé limitery a filtry. Většinou je to jen zlomek z původního útoku, zpravidla 1/3 až 1/10. Záleží na druhu botnetu. Jinak se chováme k sítím mobilních operátorů a jinak k sítím poskytovatelů serverů.
To, co vidíte na grafu, dorazilo na WAF. Tam se s tím poprala řada filtrů a pravidel. Pojďme se podívat, co se dělo na koncovém serveru. Tedy to, co prošlo až na webhosting – ano náš hlavní web jede na našem webhostingu NoLimit :).
Na horním grafu vidíte počet odbavených requestů. Zeleně jsou 200 (vrácení stránky) a modře 3XX (301 přesměrování a 304 …). Jak vidíte, na našem webu se prohání vesele naši zákazníci. Z útoku prošlo pár requestů, které nestojí ani za řeč.
Na spodním grafu je délka odpovědi serveru v ms.
Od cca 21:43:40 probíhal útok na hlavní stránku. Tam se aplikují běžná pravidla. Filtrujeme útok a co projde většinou nestojí za řeč, protože to web zvládne ustát (pár desítek požadavků za minutu). Navíc pravidla se s každým opakovaným požadavkem zpřísňují pro jednotlivé podezřelé IP adresy. Většina požadavků je zablokována na filtrech s limity. Z důvodu testování je vypnutá captcha ve všech lokalitách.
Od cca 21:47:15 útočník mění strategii a útočí na podstránku našeho webu. Tam už mu do cesty nedáváme nic, jen cachovanou verzi webu.
V tento okamžik si každá lokalita, která obdrží požadavek o podstránku, uloží její statický otisk do své cache a vrací ji za 0,001 až 0,002 vteřiny. Pokud ji drží déle jak 3 vteřiny a obdrží požadavek znovu, tak se zeptá serveru, jestli cachovaná verze platí (požadavek se stavovým kódem 304). Proto tam vidíte nárůst těch požadavků 3XX. Pokud bychom mezitím upravili stránku, tak si stáhne novou verzi. Jinak pokračuje dál s tím, co má.
Požadavky 304 spotřebují zanedbatelné množství výpočetního výkonu v porovnání s vrácením běžné stránky (stavový kód 200). Je to vidět na grafu rychlosti odpovědi serveru. V porovnání s odpověďmi 200, které trvají 50–70ms, tak 304 vrátí za 3–5 ms.
Samozřejmě parametry můžeme měnit. Nemusíme kontrolovat, zdali máte novou verzi stránek každé 3 vteřiny z každé lokality. To v případě útoku přes všechny lokality u slabších hostingů může narážet na limity požadavků za minutu. Není problém nastavit 60 vteřin nebo více. V administraci WEDOS Global je vždy možnost vyčistit cache ručně, pokud byste potřebovali aktuální obsah ihned.
Za dvě minuty to útočník vzdává a ukončí útok. Proč také plýtvat drahými zdroji jeho botnetu na cíl, který na útok nereaguje žádnou ochranou, a navíc se ani nezpomalí. Cílů, které může touto silou sestřelit jinde a držet off-line celé hodiny, je jinde požehnaně.
Závěr
Nová forma ochrany si odbyla premiéru a můžeme ji dále testovat a vylepšovat. Nasazena ale bude brzy. Všem se to vyplatí. Nejsnáze to půjde pro weby na WordPress a pak samozřejmě zákazníky se statickými stránkami.