Je tomu asi týždeň čo Robert ‘RSnake’ Hansen publikoval na svojom blogu nástroj, ktorý zneužíva nie najlepšie navrhnutú vlastnosť niektorých HTTP serverov, vrátane veľmi populárneho Apachu. Bohužiaľ, lokálne (cz/sk) IT weby tomu nevenujú pozornosť.
Pred dvoma rokmi opísal bezpečnostný analytik Adrian Ilarion Ciobanu zraniteľnosť, ktorá vychádza z nie práve šťastného návrhu autorov niektorých HTTP serverov (myslený softvér, ktorý vytvára HTTP server). Výsledkom tejto zraniteľnosti je veľmi úspešný a zákerný DOS (Denial-of-service) útok, ktorý umožňuje jedinej osobe na bežnej domácej linke položiť veľký webový server.
Popis
Podstata útoku spočíva v tom, že útočník odosiela nekompletné požiadavky na server, presnejšie nekompletné hlavičky požiadaviek. Apache a niektoré ďalšie HTTP servery (zoznam neskôr) na to reagujú tak, že čakajú na dokončenie celej požiadavky (hlavičky) a nechávajú pripojenie medzi útočníkom a serverom otvorené až do prijatia všetkých potrebných údajov, resp. do vypršania času. A to práve umožňuje útočníkovi zasielať väčšie množstvo požiadaviek, ktoré však nikdy nebudú kompletné. Výsledkom je preťaženie webového servera (procesu) a jeho následný pád. Podľa testov rôznych bezpečnostných analytikov je takto možné zhodiť približne 98% všetkých funkčných serverov, ktoré používajú niektorý zo zraniteľných HTTP serverov.
Robert týmto krokom vyvolal veľmi vášnivú diskusiu, pretože dal bežným užívateľom (script kiddies) do rúk nástroj, ktorý veľmi efektívne môžu používať na poškodzovanie veľkého množstva webov. Ochrana je pritom relatívne zložitá, občas veľmi neefektívna. Nástroj nazval Slowloris, je naprogramovaný v jazyku Perl. Jeho najefektívnejšie využitie je na systémoch Unix-like, ktoré nemajú obmedzenia na množstvo otvorených socketov. Windows toto obmedzenie má, umožňuje len 140 aktívnych socketov, čo znemožňuje útok v prípade, že nastavenie časového limitu pre prijatie zbytku hlavičky webovým serverom je nižší, než 60 sekúnd.
Postihnuté sú tieto aplikácie:
- Apache 1.x
- Apache 2.x
- dhttpd
- GoAhead WebServer
- Squid (nepotvrdené)
- WebSense “block pages” (nepotvrdené)
- Trapeze Wireless Web Portal (nepotvrdené)
- Verizon’s MI424-WR FIOS Cable modem (nepotvrdené)
- Verizon’s Motorola Set-Top Box (port 8082 and requires auth – nepotvrdené)
- BeeWare WAF (nepotvrdené)
Zaručene v poriadku sú tieto aplikácie:
- IIS6.0
- IIS7.0
- lighttpd
- nginx
- Cherokee (potvrdené komunitou)
- Netscaler
- Cisco CSS (potvrdené komunitou)
Ochrana
Majitelia webových serverov majú niekoľko možností, ako zmierniť, či úplne zabrániť tomuto druhu útoku, ak teda používajú niektorý z náchylných aplikácií.
Výmena
Samozrejme, že je možné vymeniť zraniteľnú aplikáciu za takú, ktorá zraniteľná nie je. Problémom však býva, že často je webový server uspôsobený na fungovanie konkrétnej aplikácie a prehodiť tieto nastavenia nebýva jednoduchá záležitosť. Týka sa to napríklad zmeny pravidiel pre mod_rewrite, ktoré nie sú rovnaké v ostatných serverových aplikáciach.
Load ballancer a proxy
Ak vaša aplikácia vyžaduje viac ako jediný webový server, je možnosť sa vyhnúť celému problému za pomoci load ballanceru, alebo proxy umiestneného pred vašimi webovými servermi. Samozrejme, toto proxy nesmie byť náchylné na tento typ útoku, potom stráca táto ochrana zmysel.
Nastavenia
Ak však máte len jediný server, na ktorom beží Apache, jednoduchšou možnosťou je zmeniť nastavenia. Najdôležitejším nastavením je zmena TimeOut Directive, ktorá je štandardne nastavená na 300. Toto nastavenie určuje, ako dlho má Apache čakať na dokončenie požiadavky pri POST, PUT aj GET požiadavkách, pokým uzavrie spojenie. V tomto časovom limite musí útočník poslať 256 požiadaviek, ktoré sú štandardne povolené. Vhodné je zvoliť veľmi nízky čas, i keď je potrebné si dávať pozor, aby ste nezvolili prinízky čas a neobmedzili tak svojich bežných užívateľov. Dobré je zvoliť čas okolo 15 sekúnd, možno až 30.
Bohužiaľ, Slowloris sa vie tejto situácii ľahko prispôsobiť. V nastaveniach útoku je možné zmeniť čas vypršania požiadaviek na ľubovoľnú hodnotu, podľa ktorej sa útok graduje. Ak teda nastavíte čas do vypršania požiadavky na 4 sekundy, nástroj odošle 256 požiadaviek v tomto časovom limite, čo predstavuje podľa meraní približne len 45 kb/s. To znamená, že užívateľ s bežným domácim pripojením dokáže poľahky zložiť takmer akýkoľvek veľký web, ktorý je náchylný na tento typ útoku.
Ďalšou možnosťou je obmedzenie množstva požiadaviek pre jednú IP adresu. K tomuto je možné využiť napríklad modul pre Apache mod_limitipconn, alebo na UNIX-like systémoch je možné využiť ipt_recent/ipt_limit modul, ktorý robí tú istú vec ale na úrovni systému. So striktným nastavením však veľmi opatrne, pretože môžete veľmi ľahko odstaviť bežných užívateľov, ktorí sú nútení svojím ISP surfovať cez proxy servery. Príkladom je zahraničné AOL, ktoré je týmto povestné.
Bohužiaľ, v dnešnej dobe nie je najmenší problém zakúpiť niekoľko tisíc proxy za pár korún. Sú špecializované, hlavne ruské weby, ktoré ponúkajú za niekoľko dolárov prístup k veľkému množstvu proxy serverov, ktoré túto ochranu absolútne obchádzajú a pri neustálej obmene identifikátorov prehliadačov, zmeny veľkosti požiadavky, atď. je útočník prakticky nezastaviteľný.
Viac možností mi v tejto chvíli nenapadá. Je potrebné si podrobne naštudovať nastavenia vášho webového servera a aplikovať vybrané obmedzenia, resp. si nájsť inú formu ochrany. Akútnosť tejto zraniteľnosti je veľmi vysoká, preto je dosť možné, že sa čoskoro objavia nové verzie aplikácií, ktoré túto zraniteľnosť odstránia.
Záver
Robert nenechal nikoho ani vydýchnuť a už vo svojom ďalšom článku oznámil, že našiel ďalší spôsob, ako za pomoci DOS útoku spomaliť, resp. zhodiť akýkoľvek webový server. Viac si môžete prečítať v článku “HTTP Longevity During DoS“.
Ak teda prevádzkujete webový server, snažte sa ponoriť sa do tajov možných nastavení a nespoliehajte sa na aktuálnu funkčnosť dodávanú štandardne s aplikáciou.
MaxClients a ListenBackLog neriesi prave toto?
#1 ja: este ze si napisal, zabudol som tam dat cast o proxy serveroch. uz je to doplnene
#1 ja::
Praveze neriesi… MaxClients je akurat limit kolko sucasnych poziadaviek budes spracovavat. Tento utok vytvori vela sucasnych poziadaviek cakajucich len na timeout. Mozes sice MaxClients zvysit, ale pri beznej prevazke to moze spomalit – ak kazda poziadavka bude legitimna, pre kazdu potrebujes dost RAM a dost CPU.
ListenBackLog je parameter kolko TCP spojeni Ti bude cakat v systeme v stave SYN_RECV kym si ich apache prevezme cez accept(). Ked ma apache vyuzite vsetkych MaxClients procesov, tak dalsie poziadavky ostavaju v tejto systemovej queue v SYN_RECV TCP stave a postupne ako tie predchadzajuce apache spracoval, dostava tieto.
Avsak problem to neriesi, kedze aj keby si nastavit tuto queue na 4096 napriklad, tak poziadavky v nej budu tak dlho (minuty/desiatky minut) ze browser pripadne navstevnik to vzda.
Lighttpd zrejme nie je (az tak) nachylny, kedze je to 1procesovy server, ktory obhospodaruje vsetky poziadavky v cykle cez select(), takze v zasade kym dany socket iba caka na dalsie data tak lighttpd vobec nezatazuje. Problemom su potom systemove limity (ci uz globalne alebo per proces) na pocet otvorenych socketov/file handlov.
Ochrana proti DOS utoku moze byt cez tie moduly apache prip. iptables ako limit na IP. Pokial nejde o download webserver, tak sucasnych poziadaviek by nemalo byt z browsra viac ako 5-20, takze dat limit na nejakych 50-100 a vyskusat co to spravi. Jeden priklad kedy treba dat pozor je hostovanie wap portalov, kedze tam idu vsetky poziadavky cez web proxy daneho mobilneho operatora.
Ochrana proti akemukolvek DDoS utoku (teda nielen konkretne tomuto) je velmi narocna a pri velkej intenzite skoro nerealna a urcite nerealizovatelna na urovni jedneho servera ci priamo apache procesu.
Mně jako první napadlo zahazování právě těch nekompletních hlaviček na základně příznaku.. Nevím teď, které všechny firewally by to umožnily a které ne…
#3 Marki: No s obmedzenim MaxClients zrejme nevyriesim dostupnost, ale nie je mi jasne preco by mal server padnut.
#4 Accuphose: No problem je prave v tych timeoutoch… Kedy urcis ze hlavicka je nekompletna? Ako rychlo musi prist cela hlavicka, aby si ju nezahodil? Za sekundu? za 10? Musis dat pozor, aby si tym neblokoval klientov s pomalsou linkou – ako napr. GPRS.
#5 ja: Server padne len ak to prezenies. Predpokladam ze mas nejako urceny sucasnu hodnotu MaxClients, tak aby vykon servera bol optimalny. Kazdy apache/php berie RAM, takze ak ich budes mat 500 naraz a kazdy bude robit s databazami, tak sa moze ze server zacne swapovat a tym sa vyrazne spomali. To iste aj s CPU. Ked jeden skript trva 100 ms a bude sa ti ich vykonavat 10 naraz, tak vsetky naraz zacnu a kazdy z nich bude trvat sekundu (a skoncia naraz). Ak ich budes mat 100, tak kazdy bude trvat 10 sekund a to uz je pre web nepouzitelne. (Samozrejme nie kazdy http request potrebuje tolko RAM a CPU, ale ber to ako zjednoduseny priklad.)
#6: Marki: Nemyslim, ze dojde na vykonavanie nejakeho php skor ako pridu vsetky hlavicky.
#7 ja: Jasne, to mas pravdu. Ja som skor hovoril o tom, ze ked si das prilis velky MaxClients tak sa ti to vypomsti v pripade vyssej legitimnej navstevnosti, lebo vtedy dovolis serveru vykonavat viac poziadaviek naraz. V pripade tohto DoS utoku, by velky problem nemal nastat, velka vacsina pamate apache+php by mala byt shared.
Niečo takéto som riešil asi pred rokom, keď jeden nahnevaný script kiddie spustil distribuovaný TCP syn flood na našu servrovú aplikáciu a webstránku. Aplikácia, ako lighthttpd, používa 1 select, takže cieľom útoku bolo vyčerpať FD_SETSIZE, aby nešlo pripojiť normálnych klientov. To sa riešilo ad-hoc googlením, kldload ipfw (mašina nemala), tcp cookies a agresívnymi timeoutami.
Nanešťastie, na položenie apacha stačilo blbých 20 polootvorených tcp spojení, čo ma dosť zaskočilo. Tu sme to poriešili cez mod_dosevasive, zvýšením počtu forkov/threadov a timeoutami. Síce to pomohlo, ale od bežného času odozvy to malo ďaleko. Našťastie ten DDoS po čase skonči.
Apache má zúfalo málo nastavení proti takémuto primitívnemu typu útoku ~.~
co takto ponuknut riesenie ?
alebo teraz mame vsetci zacat kodit v .nete a preist na IIS ?
Pre tych ktory nechcu cakat na napravu existuju este urcite (aspon relativne sluzne) riesenie:
prve: modul na apache server: ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/
druhe ale nie celkom korektne riesenie (ale zarucene ucinne voci slowloris utoku) :) :
V podstate ide o ochranu na urovni kernelu.
:)
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/tcp_keepalive_time
#9 ultramage: no ja som tam ponukol riesenia, je to v casti nastavenia. ako spomenul #10 on:, momentalne je mozne pouzit modul pre apache, ktory by mal zastavit tento utok
Když už není možno pořádně vytisknout stránku přes to tlačítko do PDF, tak by nebylo od věci trochu upravit stily CSS pro tisk, aby se dala stránka vytisknout. Ani mě tak moc neirituje to, že je v ní tisknou nepodstatné věci, jako mě irituje to, že se nevytiskne celá. Dík za případnou a brzkou úpravu stylu pro tisk…
#13 Já: hm to je velmi zvlastne, lebo mne to ide celkom v pohode. skusal som to vo ff3 a ie8. CSS tejto sablony je katastrofalne, rovnako cela sablona je dost zle urobena, preto cakam na redesign.