Pomalu je lepší než rychle
Klasické DoS útoky jsou velmi dobře známé, zdokumentované a existují proti nim obranné postupy. Taktikou takových útoků je zahltit systém velkým množstvím nesmyslných požadavků. K tomu budeme potřebovat solidní datový tok, kterým zahltíme vstupy cílového serveru. Takový útok je ovšem poměrně nápadný, protože generuje nestandardně velký datový tok a operační systém začne obvykle upozorňovat hlasitě na různé problémy s tím spojené.
Představte si takový útok v reálném světě: Do obchodního domu vtrhne ohromná skupina lidí, kteří začnou vykřikovat své požadavky: Jednu bublinku do vodováhy!
nebo Metr mlíka!
Takový dav samozřejmě ochromí provoz obchodu, ale ochranka si s ním velmi rychle poradí. Prostě všechny křiklouny vyvede ven.
Útok Slowloris, o kterém se mluví asi dva roky, je ale jiný. Nepotřebujete pro něj silné linky ani velké množství útočících počítačů. Stačit vám bude jen jeden skript, který útok provede. Princip Slowloris útoku spočívá v otevření spojení a jeho udržování po dlouhou dobu – klidně několika hodin. Toho dosáhneme tak, že budeme požadavky posílat velmi pomalu, po částech a těsně před vypršením timeoutu.
V naší analogii z obchodního domu zajistíme tento útok tak, že si vezmeme hodně drobných. Zatímco běžný zákazník zaplatí jednou bankovkou, vezme si peníze zpět a odejde, náš Slowloris bude stát u pokladny tři hodiny a lovit v peněžence jednotlivé mince. Jelikož „prodavačka“ v počítači nemá příliš dobrou paměť, pamatuje si jen dobu, která uběhla od podání poslední mince. Pokud tedy nepřekročíme mez a každou minutu jí něco přidáme, můžeme u ní stát celé hodiny. A fronta za námi roste a roste.
A přesně takhle funguje Slowloris. Webový server totiž obvykle otevře spojení a čeká na doručení celého HTTP požadavku, na který bude odpovídat. Útočník ale velmi pomalu posílá jednotlivé řádky nekonečné hlavičky. A server trpělivě čeká a čeká a nikdy se nedočká. Místo toho je server obtěžován „zákazníkem“, který si vlastně nikdy nic nekoupí.
Mimochodem útok Slowloris je pojmenován podle zvířete slow loris, které česky nazýváme outloň váhavý. Patří mezi primáty a žije v jižní a jihovýchodní Asii. Outloň se pohybuje velmi váhavě a pomalu, proto bylo jeho jméno použito i pro pojmenování útoku. Na rozdíl od ostatních poloopic není tak obratný, svými pomalými, téměř rozvážnými pohyby, kdy pozvolna posunuje jednu končetinu za druhou, by zdálky mohl připomínat spíš koalu,
píše Wikipedie.
Jen pro zajímavost – Apache má standardně timeout nastavený na 300 sekund (ano, pět minut!). Pokud mu v tomto intervalu útočný software pošle alespoň jeden další řádek hlavičky, počítadlo se vynuluje a server čeká dál. S naprosto minimální námahou tak dokážete spojení udržovat neomezenou dobu.
Jak to konkrétně vypadá?
Podobné typy útoků jsou samozřejmě známé už mnoho let, ale začalo se o nich hovořit až v roce 2009, kdy Robert „RSnake“ Hansen vytvořil implementaci nazvanou právě Slowloris. Ta ukázala zranitelnost řady velkých serverů proti takovému útoku. Do té doby se mělo obecně za to, že problémy mohou způsobit velké datové toky. Čím víc dat, tím větší zahlcení. Ukázalo se ale, že menší tok může být paradoxně ničivější.
Komunikace se serverem vypadá následovně. Nejprve je mu odeslána naprosto legitimní část hlavičky:
GET / HTTP/1.1\r\n Host: host\r\n User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n Content-Length: 42\r\n
Vidíte, že vše je v pořádku, ale chybí poslední prázdný řádek, který by serveru oznámil, že je hlavička kompletní a teď je čas na jeho odpověď. Teď už stačí počkat rozumnou dobu a pak hlavičku doplnit o další řádek:
X-a: b\r\n
Tento řádek není chybný, ale nesděluje serveru žádnou informaci. Jen ho donutí vynulovat počítadlo a zahájit další fázi čekání. Ta se pak opakuje do nekonečna. Pochopitelně je možné konkrétní řetězce jednoduše změnit, takže jejich detekce v rámci IDS může být neúčinná.
Proč je to problém?
Kromě toho, že server zůstane zahlcen čekajícími spojeními a přestane odpovídat na ta regulérní, má Slowloris ještě několik významných vedlejších efektů. Především je velmi těžké ho vůbec odhalit. Logy web serveru mlčí, protože k žádnému problému vlastně nedošlo.
Stejně tak operační systém nemá nejmenší problém, v logu není nic o zahazovaných spojeních, zatížení systému je téměř nulové, disky jsou v klidu a nic zvláštního se neděje. Ani síťový provoz není nijak vysoký, vlastně je naopak extrémně nízký. Jediné, co by vás mohlo upozornit, je velké množství otevřených spojení na server. Jinak je ale na serveru vše v pořádku až na to, že neobsluhuje požadavky.
Potíž totiž je, že Slowloris postihuje přímo aplikační vrstvu serveru. Neútočí na síťová rozhraní ani na TCP stack zajišťovaný jádrem. Operační systém tedy o útoku nic neví. Všechny ostatní služby mohou naprosto bez problémů běžet a útok vyřadí jen web server.
Kdo je postižen?
Slowloris není efektivní na všech web serverech. Postižen je ale nejrozšířenější Apache (první i druhá řada), dhttpd a několik dalších méně známých serverů. Naopak v klidu mohou být provozovatelé lighttpd, nginx, proxy serveru Squid a také microsoftího IIS 6 a 7.
Důvodem je, že IIS nakládá se spojeními jinak než Apache. Zatímco u Apache je ke každému novému TCP spojení staticky navázán konkrétní proces (thread), v případě IIS spuštěné procesy čekají na kompletní požadavek, který následně vyřídí. Nekompletní požadavky je nezajímají a zatímco systém čeká na jejich dokončení, servery vyřizují ostatní žádosti, které mezitím dorazí. Zablokované spojení tak sice drží socket, ale nemá vliv na reálné thready v systému.
Vyzkoušel jsem prakticky Slowloris na Apache 2.2.17 ve standardním nastavení a skutečně byl server během několika sekund naprosto nedostupný. Počítač se přitom naprosto nudil, jediným příznakem bylo 530 otevřených spojení z útočící IP adresy. Slowloris spojení občerstvoval jednou za sto sekund, čili aktivita byla velmi malá. Po zastavení Slowloris se spojení zavřela a server byl opět okamžitě k dispozici.
Jak se tomu bránit?
Neexistuje jednoduchá volba v konfiguraci, která by zajistila univerzální ochranu. Přesto je možné zavést některá opatření, která minimalizují dopad útoku na váš server. V první řadě je možné změnit standardní nastavení Apache tak, aby byla zkrácena jeho standardní doba čekání na hlavičku. I v dobách opravdu pomalých připojení bylo pět minut až až a dnes je to o to přehnanější hodnota.
Úprava konfigurace Apache
Můžete tedy v konfiguračním souboru (například /etc/apache2/apache2.conf, ale podle distribuce se hodně liší) nastavit volbu
Timeout 10
Samozřejmě záleží na tom, jak rychle váš server obvykle podává soubory a zda na něm nemáte nějaké skripty, které běží delší dobu. Odladění je na vás. Výsledek je samozřejmě pozitivní, po uplynutí času už Apache nečeká a dokáže obsluhovat další uživatele. Potíž tohoto řešení ovšem je, že stačí ve skriptu Slowloris nastavení změnit a intervaly se také zkrátí (parametry -timeout a -num. V tu chvíli je opatření neúčinné.
IPtables
Velmi jednoduše je možné omezit počet spojení z jedné IP adresy pomocí IPtables.
# iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 20 -j REJECT
Nevýhodou je, že taková konfigurace může být pro některé weby příliš hrubá, protože nerozlišuje, jaký obsah se snaží uživatel získat. K tomu naopak pomáhá následující postup.
Omezení počtu spojení v Apache
Další možností je nasadit modul mod_limitipconn, který omezí počet spojení otevřených z jedné IP adresy. Pozor ovšem na to, že tím můžete omezit i regulérní uživatele, především ty, kteří jsou za NATem. Klasická verze modulu byla k dispozici jen pro Apache 1.X, ale existuje verze pro řadu 2. Připraveny jsou předkompilované balíčky RPM a DEB.
Po instalaci vytvořte soubor /etc/apache2/conf.d/limitipconn.conf a do něj zapište následující konfiguraci:
ExtendedStatus On
<IfModule mod_limitipconn.c>
<Location />
MaxConnPerIP 10
NoIPLimit images/*
</Location>
</IfModule>
Vidíte, že je možné nastavit počet spojení a zároveň z tohoto počtu vyjmout konkrétní soubory, v tomto případě obrázky. Pokud máte na webu hodně obrázků, většina prohlížečů si na jejich stahování otevře další spojení. Stejně tak je možné omezení na IP adresy konfigurovat pro různé adresáře nebo virtuální hosty.
Specializované moduly
Nakonec zmíním dva specializované moduly, zaměřené přímo na potírání útoků Slowloris. První z nich se jmenuje mod_antiloris a stáhnete jej přímo z domovského webu projektu. Má jen několik kilobajtů a budete si ho muset přeložit. Druhým podobným projektem je mod_noloris, který si můžete stáhnout ze SVN Apache.
Oba moduly dělají totéž: počítají, kolik spojení z jedné IP adresy je ve stavu SERVER_BUSY_READ. Tedy v tom stavu, kdy server čte data od klientů. Pokud je toto číslo příliš veliké, další spojení z adresy už nejsou přijímána. Tohle řešení má zásadní výhodu v tom, že pokud existuje větší množství spojení zaneprázdněných stahováním dat ze serveru, není kvůli nim blokována další komunikace.
Po překladu a instalaci stačí v konfiguraci Apache nastavit zavedení modulu mod_antiloris.so a poté Apache restartovat. Modul se zavede a bude automaticky vykonávat svou práci.
Závěrem
Slowloris samozřejmě není jediný možný útok proti web serveru. Stejně tak nebyly v článku popsány všechny metody, kterými je možné se proti němu bránit. Můžete například použít modul mod_qos nebo před ohrožený Apache postavit SQUID či lighthttpd, které jsou vůči problémům tohoto typu odolnější.
Cílem článku bylo spíše upozornit na existující útok, který je velmi snadné zahájit (tak snadné, jako spustit jeden skript) a naopak může být poměrně těžko odhalitelný.
