Útok Slowloris aneb plíživé nebezpečí pro web servery

Petr Krčmář 17. 5. 2011

DoS a DDoS útoky jsou staré jako internetové lidstvo samo. Jsou k nim potřeba rozumné počítače připojené k velmi rychlé lince. Skrze ni pak útočník zasype server takovým množstvím požadavků, že způsobí nedostupnost služby. Technicky zajímavou a zákeřnou modifikací je útok Slowloris. Je nenápadný a smrtící.

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ý.

Našli jste v článku chybu?
120na80.cz: SOS aneb spálená pokožka

SOS aneb spálená pokožka

Měšec.cz: Banky umí platby na kartu, jen to neříkají

Banky umí platby na kartu, jen to neříkají

Měšec.cz: Test: Výběry z bankomatů v cizině a kurzy

Test: Výběry z bankomatů v cizině a kurzy

120na80.cz: Jaké plavecké pomůcky vaše dítě ochrání?

Jaké plavecké pomůcky vaše dítě ochrání?

Root.cz: Bitcoin začal vyplácet jen půlku odměn

Bitcoin začal vyplácet jen půlku odměn

Měšec.cz: Kurzy platebních karet: vyplatí se platit? (TEST)

Kurzy platebních karet: vyplatí se platit? (TEST)

120na80.cz: Tipy pro odvodnění organismu

Tipy pro odvodnění organismu

DigiZone.cz: Skylink o půlnoci vypnul 12 525

Skylink o půlnoci vypnul 12 525

DigiZone.cz: Sázka na e-sporty stanici Prima vychází

Sázka na e-sporty stanici Prima vychází

Lupa.cz: eIDAS: Nepřehnali jsme to s výjimkami?

eIDAS: Nepřehnali jsme to s výjimkami?

DigiZone.cz: Nestihli jste Bonda na ČT2? Zkuste RTVS

Nestihli jste Bonda na ČT2? Zkuste RTVS

Podnikatel.cz: Tahle praktika stála šmejdy přes milion

Tahle praktika stála šmejdy přes milion

Vitalia.cz: Klíšťata letos řádí, skvrna se udělá jen někomu

Klíšťata letos řádí, skvrna se udělá jen někomu

Vitalia.cz: Jak může být v uzenině 150 % masa?

Jak může být v uzenině 150 % masa?

120na80.cz: I tuto vodu můžete pít

I tuto vodu můžete pít

Podnikatel.cz: Profese budoucnosti? Úředník nepřežije

Profese budoucnosti? Úředník nepřežije

Vitalia.cz: Paní výčepní: Holka, co mluví chlapům do piva

Paní výčepní: Holka, co mluví chlapům do piva

DigiZone.cz: Žhavé novinky u IPTV operátorů

Žhavé novinky u IPTV operátorů

DigiZone.cz: Sat novinky: Skylink skončil s kanály ČT

Sat novinky: Skylink skončil s kanály ČT

Měšec.cz: Dodavatele energií porovnáte snáz

Dodavatele energií porovnáte snáz