Application level flood (Application Level DoS Attacks) česky zaplavení na úrovní aplikace (DoS útok na úrovni aplikace) je druh DoS anebo DDoS útoku, který většinou směřuje na slabá místa aplikace. Zjednodušeně řečeno na tu část aplikace, která serveru zabere nejdelší čas na zpracování, je vedeno velké množství požadavků až do té míry, že server nebude stačit požadavky odbavovat. Tento druh útoku mají v oblibě zvláště script kiddie, protože není náročný na provedení a stačí k němu dostatečný počet útočících strojů.

Jak Application level flood probíhá prakticky

Nejdříve je nutné najít slabinu webu. Stránku, která trvá nejdelší dobu na vygenerování a zároveň se neukládá do cache. Nejčastěji jsou slabinou skripty, které stahují anebo zpracovávají externí data a provádí náročné databázové dotazy. Například většina webů dnes má nějakou funkci na vyhledávání. Stránka s hledáním je tedy dobrým cílem.

Pro otestování rychlosti odbavování požadavků použijeme službu tools.pingdom.com. Jako příklad si zvolíme třeba tento blog – timehosting.cz. Zajímá nás hodnota TTFB (time to first byte). Pokud se na stránce nenachází přesměrování, tak se jedná o první řádek. Konkrétně žlutá část z grafu.

Jak vidíte, díky cachovacímu pluginu se jedná o 25 ms. Na shození by bylo potřeba příliš mnoho dotazů. Zkusíme slabinu – výsledky vyhledávání.

http://timehosting.cz/?s=test

Tady už je vidět, že celková doba na zpracování požadavku se protáhla z 25 ms na 542 ms (přesnou hodnotu jsem si zjistil ze zdrojového kódu). Vzhledem k tomu, že se stránka nachází na hostingu Wedos, který má pět PHP vláken, musíme jej zahltit nejméně 1000/542*5 požadavky za vteřinu (1000 ms / 542 ms doba na vyřízení požadavku * 5 PHP vláken). Takže potřebujeme 9,22 požadavků za vteřinu (nepočítáme li další skripty na které odkazuje externě v rámci hostingu). Vzhledem k tomu, že se server negeneruje stránku vždy stejně rychle, bylo by potřeba větší číslo.

K testu byl použitý program SIEGE a proběhl v pozdních hodinách. Nastavil jsem jej na 20 prohlížečů po dobu 60 vteřin. Dokončilo se celkem 340 HTTP transakcí. Výsledkem bylo jen zpomalení. Nejdelší spojení trvalo 22,31 vteřiny. Pro přesnější výsledky by bylo potřeba nechat test delší dobu, ale přeci jen timehosting jede na sdíleném webhostingu.

Zároveň jsem si ale párkrát refreshnul stránku jestli nevyskočí chyba 503 a probíhaly i testy načtení stránky.

Docílili jsme tedy zpomalení a při větším množství požadavků by se možná objevila i chyba 503. Museli bychom docílit, aby server začal spojení zahazovat.

Obrana proti Application level flood

Základem je odstranit z webu slabá místa. Tedy stránky, které jsou pro server náročné na zpracování. Možností je optimalizace skriptů a dotazů na databázi anebo ukládat obsah do cache. Například v předchozím případě, by mě zachránilo ukládání výsledků hledání do cache. Načtení části stránky uložené jako soubor v cache je otázkou maximálně desítek milisekund.

Pokud dokážeme identifikovat útočníka, například má bezdůvodně příliš velké množství dotazů na jednu a tu samou stránku, můžeme mu dát dočasný ban na IP adresu. Samozřejmě v případě koordinovaného DDoS stovek strojů s tím moc nenaděláme 🙂

Je třeba brát ohledy i na roboty vyhledávačů, kteří mohou při procházení webu stahovat velké množství dat celkem intenzivně, aby si je tedy vaše ochrana nespletla s útočníky 🙂

Tento článek byl byl přečten 2526 krát