Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Ataki Slow HTTP DoS (cz. 1.) – Slowloris
Wstęp
Ataki odmowy dostępu do usługi są niezwykle uciążliwym zagrożeniem – przy odpowiedniej liczbie zasobów agresorzy są w stanie zablokować działanie serwerów obsługujących nawet największe strony na świecie. Mimo że ataki DDoS ewoluują, ciągle zwiększając wolumen danych, to nie można zapomnieć o atakach subtelniejszych, czyli o DoSie warstwy siódmej. To zagrożenie wymaga dużo mniejszych zasobów po stronie agresora, jednak efekty ataku mogą okazać się równie groźne, jak w wariancie ogromnych ataków rozproszonych. Najlepszym tego przykładem są ataki Slow HTTP DoS, na które potencjalnie narażona jest nawet co druga strona na świecie.
Pierwsza wzmianka o tego typu zagrożeniu pojawiła się już w 2007 r. (w czym udział miał nasz rodak, Michał Zalewski), więc Slow HTTP DoS nie jest niczym szczególnie nowym. Charakter tych ataków jest jednak na tyle specyficzny, że jeszcze przez dobre kilka lat zagrożenie to będzie aktualne. Warto się więc przyjrzeć wariantom tego ataku, tym bardziej że może on być z sukcesem przeprowadzony z pojedynczego węzła w bardzo prosty sposób.
W tym cyklu dowiesz się:
- czym są ataki Slow HTTP DoS i czym różnią się od innych ataków odmowy dostępu do usługi,
- czym jest atak Slowloris i jaka jest jego zasada działania,
- jakie są podstawowe koncepcje procesu obsługi żądań wybranych serwerów WWW,
- jakie są inne warianty ataków Slow HTTP DoS (oprócz ataku Slowloris),
- w jaki sposób testować podatność Slow HTTP DoS i jakich narzędzi używać,
- jaka jest specyfika ochrony przed tego typu zagrożeniem.
Przed lekturą zalecamy przeczytanie serii artykułów dotyczących DDoS, która opisuje rodzaje ataków odmowy dostępu oraz nakreśla problematykę ochrony przed tego rodzaju zagrożeniami:
Przypominamy, że publikowane tutaj informacje służą tylko celom edukacyjnym i wszystkie ćwiczenia powinny być wykonywane w ściśle kontrolowanym środowisku testowym.
Przed testami penetracyjnymi na realnych systemach należy zawsze uzyskać zgodę właściciela!
Początki ataków Slow HTTP DoS
Problem ataku na warstwę aplikacji nie jest niczym nowym – jedną ze standardowych procedur zapewniania bezpieczeństwa web aplikacji jest wykrywanie wąskich gardeł i zapobieganie częstemu wykonywaniu kosztownych akcji. Dlatego właśnie w aplikacjach internetowych ogranicza się częsty dostęp np. do funkcji wyszukiwania (duża ilość informacji wymienianych z bazą danych) czy bezpiecznego logowania (duża ilość mocy potrzebna do obliczenia skrótu metodą key stretching).
Problem ataków na logikę aplikacji jakby powoli odchodzi w zapomnienie, chociażby przez ciągłe zwiększanie mocy serwerów oraz dzięki przechodzeniu w nierelacyjne bazy danych. Całkowicie nowe spojrzenie na ataki DoS warstwy aplikacji rzucił w 2009 r. znany badacz bezpieczeństwa, RSnake, publikując skrypt Slowloris.
Slowloris – the low bandwidth, yet greedy and poisonous HTTP client, nie jest flooderem TCP czy HTTP – w przeciętnym ataku wysyłane jest wyłącznie kilka tysięcy żądań HTTP GET, które w praktyce nie obciążają mocno łącza między atakującym i celem. Slowloris, dzięki wykorzystaniu pewnych koncepcji protokołu HTTP oraz sposobu obsługi żądań serwerów WWW, potrafi całkowicie je sparaliżować w przeciągu kilku sekund.
Skrypt przedstawiony przez Roberta „RSnake” Hansena tworzy dużą liczbę gniazd, a następnie w specyficzny, powolny sposób dosyła dane częściowych żądań HTTP, co w końcu skutkuje wyczerpaniem puli wolnych wątków obsługujących żądania HTTP. Sztuczne utrzymywanie kilkuset równoczesnych połączeń z atakowanym serwerem powoduje, że po krótkim czasie cała „uwaga” serwerów WWW skierowana jest na atakującego, przez co zwiększa nie tylko obciążenie systemu, ale przede wszystkim uniemożliwia innym klientom podłączenie do serwera. Co ciekawe atak w sprzyjających okolicznościach może nie zostawić po sobie żadnych śladów w logach. Dużą jego zaletą jest również to, że kilka chwil po zakończeniu ataku docelowy system od razu zaczyna wracać do normy, co nie raz było wykorzystywane do „spektakularnych” szantaży.
Na atak Slowloris podatne są przede wszystkim serwery Apache, zarówno w wersji 1.x, jak i 2.x (w tym zarówno gałąź 2.2, jak i 2.4). Serwery usług Microsoft IIS oraz popularny serwer nginx są przykładem oprogramowania, które zdecydowanie lepiej radzi sobie przeciwko skryptowi Slowloris.
Slowloris w praktyce jest tylko jednym z wariantów ataku Slow HTTP DoS. Odmowa dostępu w pierwowzorze tej rodziny ataków jest realizowana przez nietypowe wysyłanie nagłówków HTTP, dlatego zanim przejdziemy do szczegółów przypomnijmy, jak wygląda struktura żądania HTTP.
Struktura żądań HTTP
Żądanie HTTP, opierając się na dokumencie RFC 2616, wygląda następująco:
request = Request-Line *(( message-header ) CRLF) CRLF [ message-body ]
Request-Line = Method SP Request-URI SP HTTP-Version CRLF message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string>
token = 1*<any CHAR except CTLs or separators>
CHAR = <any US-ASCII character (octets 0 - 127)>
CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
TEXT = <any OCTET except CTLs, but including LWS>
LWS = [CRLF] 1*( SP | HT )
W najprostszym wypadku składowymi żądania są więc:
- linia żądania zakończona znakiem nowej linii (metoda, spacja, URI, spacja, protokół, nowa linia):
GET /?s=vizzdoom HTTP/1.1 <CRLF>
- dowolna liczba (*) nagłówków żądań (general, request, entity… header), zawierających nazwę nagłówka i jego wartość, rozdzielone dwukropkiem oraz każdorazowo zakończone znakiem nowej linii:
Host: sekurak.pl<CRLF> Connection:keep-alive<CRLF> Cache-Control: max-age=0 <TAB><TAB><CRLF> X-Custom-Header: wartosc naglowka ktora moze byc<CRLF> <SP>zapisana w dwoch<CRLF> <SP><TAB>a nawet trzech liniach<CRLF> <CRLF> Koniec naglowkow, poczatek ciala.
- Sekcja nagłówków od ciała (content-body) oddzielona jest pojedynczą linią CRLF. W praktyce więc dwa wystąpienia CRLF CRLF powodują, że następne bajty żądania będą interpretowane jako element ciała.
Przyjęło się, że nagłówek posiada strukturę: <nazwa><dwukropek><spacja><wartość>. Po dwukropku jednak wcale nie musi występować znak pojedynczej spacji – może go tam nie być, spacji może być więcej lub mogą zastąpić ją znaki tabulacji (horizontal tab, HT). Zarówno programiści, jak i testerzy często zapominają również, że nagłówek można przenosić do następnej linii, używając sekwencji Linear Whitespace (LWS) – czyli znaku nowej linii, po której występują białe znaki. Informacje te nie są może ważne w kontekście Slow HTTP Attacks, jednak warto o tym pamiętać, chociażby w kontekście fuzzingu protokołu HTTP czy wciąż „żywych” ataków HTTP Response Splitting.
Jak widać, struktura żądania HTTP jest wbrew pozorom dość skomplikowana i łatwo się w niej pogubić. Najważniejsze jest, aby zapamiętać trzy elementy:
- linię żądania,
- opcjonalne nagłówki oraz
- ciało, które oddzielone jest od nagłówków znakiem nowej linii.
Dodatkowo warto wspomnieć o tym, że w przypadku protokołu HTTP/1.1 nagłówek Host jest obligatoryjny.
Po krótkiej powtórce struktury żądania HTTP możemy przejść do analizy ataku zaimplementowanego w skrypcie Slowloris.
Slowloris, czyli Slow HTTP Headers DoS
Metoda działania skryptu została zobrazowana na rysunku 1.:
Rys.1. Nagłówki HTTP podczas zwykłego żądania HTTP GET oraz nagłówki wysyłane podczas ataku Slowloris.
W klasycznym żądaniu, np. wykorzystującym metodę HTTP GET, do serwera wysyłana jest linia żądania, nagłówki oraz pusta linia CRLF oznaczająca koniec nagłówków.
Atak Slowloris polega na wysyłaniu dużej liczby dodatkowych nagłówków, przykładowo X-a: b, które będą sukcesywnie dochodzić do atakowanego serwera dopiero po pewnym czasie. Okazuje się, że natura protokołu TCP, w którym enkapsulowany jest HTTP oraz koncepcje obsługi żądań przez niektóre serwery WWW powodują, że utrzymywanie wielu takich „powolnych” połączeń spowoduje brak możliwości obsługi innych żądań.
Atak działa więc następująco:
- Budowane są gniazda (domyślnie: 1000).
- Następuje podłączenie do serwera i wysyłanie podstawowych nagłówków.
- Wysyłany jest nagłówek X-a: b.
- Odczekujemy pewien czas (domyślnie: 100 sekund).
- Wysyłamy ponownie nagłówek X-a: b.
- Powtarzaj do skutku kroki 4. i 5. dla każdego połączenia, ewentualnie dobuduj gniazda do zamkniętych połączeń.
1. Oprogramowanie podatne na atak Slowloris
Zgodnie z pierwotną listą autora skryptu, serwerami podatnymi na atak Slowloris są:
- Apache 1.x,
- Apache 2.x,
- dhttpd,
- GoAhead WebServer,
- inne mniej znane.
Inne koncepcje obsługi żądań w niektórych serwerach powodują, że nie są one podatne na ten rodzaj ataku. Metoda przedstawiona przez RSnake’a nie działa między innymi przeciwko (dane Ha.ckers.org):
- IIS6.0,
- IIS7.0,
- lighttpd,
- Squid,
- nginx,
- Cherokee,
- Netscaler,
- Cisco CSS.
W praktyce można więc powiedzieć, że na atak Slowloris podatny jest „wyłącznie” serwer Apache (niezależnie od gałęzi: 1.x, 2.2.x, 2.4.x), ponieważ inne serwery wymienione przez Roberta Hansena są mało popularne. Niestety statystycznie rzecz biorąc, Apache napędza co drugą stronę w Internecie (dane Netstat; kwiecień 2014r.), więc zasięg ataku jest spory.
Inne popularne serwery, takie jak Microsoft IIS (również w najnowszych wersjach; 8 oraz 8.5) czy nginx opierają się działaniom skryptu Slowloris.
Jak się okaże w kolejnych częściach tego cyklu, odporność na klasyczny atak Slowloris niektórych serwerów wcale nie oznacza, że są one odporne na inne odmiany ataków Slow HTTP.
2. Testowanie podatności Slow HTTP Headers
Skrypt Slowloris implementujący atak Slow HTTP Headers można pobrać ze strony ha.ckers.org w wersji IPv4 oraz IPv6. Do ich działania wymagane jest posiadanie interpretera języka Perl. Zaleca się, aby Slowloris był uruchamiany w środowiskach *NIXowych, ponieważ w systemach z rodziny Windows (przez co też w Cygwinie) odczuwalne są ograniczenia dotyczące równoczesnych połączeń TCP (oczywiście można próbować to zmienić).
Wywołanie skryptu jest bajecznie proste – jedynym obligatoryjnym parametrem jest -dns, gdzie definiujemy adres celu (po domenie lub adresie IP):
./slowloris.pl -dns pentesting-site-with-perm.com
Wykonanie skryptu pokazano na rysunku 2. Efekt powinien być zauważalny po dosłownie paru sekundach – zbudowane gniazda będą utrzymywać połączenia i blokować dostęp do strony innym klientom.
Rysunek 2. Slowloris podczas ataku.
Slowloris realizujący atak powolnych nagłówków HTTP posiada szereg przydatnych przełączników, które pozwalają w bardziej kontrolowany sposób przeprowadzać testy tej podatności.
Najbardziej przydatnymi przełącznikami są -port oraz -https, dzięki którym dostajemy możliwość testowania stron udostępnionych na nietypowych portach i/lub korzystających z bezpiecznego kanału wymiany danych. Natomiast parametry -num oraz -timeout pozwalają sterować liczbą jednocześnie otwartych połączeń oraz czasem dosyłania kolejnych nagłówków.
Część ataków Slowloris nie dojdzie do skutku ze względu na cachowanie żądań HTTP przez niektóre urządzenia pośredniczące lub nawet sam serwer WWW. Sytuacji takiej można zaradzić, posiłkując się przełącznikiem -cache, dzięki któremu nagłówki będą dosyłane z pewnymi losowymi wartościami.
Mimo, że atak Slowloris nie powinien spowodować niestabilności docelowego serwera, to jednak często przy testach penetracyjnych jesteśmy ograniczani do wykonywania akcji zmieniających stan (dostępność) systemu. Przydatnym w takim wypadku okazuje się parametr -test, który w mało inwazyjny sposób przy wykorzystaniu tylko jednego połączenia pomaga ustalić wartość parametru timeout do dalszego ataku. Czasem sama wartości utrzymywanego połączenia oraz wiedza odnośnie sposobu przetwarzania żądania w testowanym środowisku wystarcza do wskazania podatności.
Jak widać przeprowadzenie ataku Slow HTTP Headers DoS z wykorzystaniem Slowloris.pl nie jest niczym trudnym. Czas na strojenie skryptu do określonych środowisk i strategie testowania zostaną opisane w kolejnych częściach cyklu, tymczasem aby szerzej zrozumieć problematykę zagrożenia, dowiedzmy się w praktyce, jakiego rodzaju atak został przedstawiony w skrypcie RSnake’a oraz dlaczego serwery są na niego podatne.
3. Charakter ataku
Ataki Slow HTTP, których szczególnym przypadkiem jest Slowloris.pl, należą do kategorii ataków odmowy dostępu przez wykorzystanie (słabości) logiki aplikacji. Ataki L7 (warstwy siódmej) kojarzone są z częstym wykonywaniem akcji kosztownych (obliczeniowo, pamięciowo…) po stronie web aplikacji. Slowloris jednak nie atakuje logiki aplikacji internetowej, a logikę samego serwera WWW jako aplikacji w systemie, która udostępnia usługę HTTP.
Slow HTTP z pewnością nie jest atakiem DoS typu sieciowego/wolumetrycznego. Chociaż utrzymywanie częściowego połączenia HTTP można skojarzyć z atakiem SYN Flood, to trzeba pamiętać, że w kontekście warstw niższych trudno dopatrzyć się tutaj jakichkolwiek anomalii – mamy tu pełne połączenie TCP bez żadnych manipulacji. Ataki Slow HTTP nie są też flooderami – do sukcesu potrzebują wysłać kilka tysięcy żądań HTTP, jednak jest to bardzo niski wolumen ataku, który nie jest w stanie wysycić łącza ofiary.
Ataki tego rodzaju oczywiście mogą mieć charakter rozproszony (DDoS), jednak skrypt można z sukcesem wykonać z jednej maszyny (lub co najwyżej z kilku), co zazwyczaj ma miejsce.
Dlaczego Ja?
Wiemy, w jaki sposób działa skrypt Slowloris oraz jak wykonać z jego pomocą atak Slow HTTP Headers na wybrany serwer WWW. Zastanówmy się, na wysokim poziomie abstrakcji, co powoduje, że Slowloris w tak efektywny (i efektowny) sposób pozwala przeprowadzać atak DoS i dlaczego niektóre serwery są na niego podatne, a niektóre nie.
1. Apache – MPM Prefork
Strategia obsługi żądania w serwerze Apache kontrolowana jest przez tzw. moduły MPM – Multi Processing Module. Moduły te muszą zostać wkompilowane w serwer (statycznie lub dynamicznie), a następnie odpowiednio skonfigurowane. MPM Prefork jest domyślnym modułem serwera Apache i jest wybierany, gdy żaden z innych MPM-ów nie zostanie jawnie podany.
Apache działający wraz z MPM Prefork charakteryzuje się stabilną, jednowątkową obsługą żądań, co okupione jest niestety dużym apetytem na pamięć RAM. Działanie MPM Prefork przedstawiono na rysunku 3.:
Rys.3. Apache MPM Prefork – ogólna zasada działania (po kliknięciu uruchomi się animacja).
Proces rodzica tworzy pewną (konfigurowalną) liczbę procesów potomnych, które działają w trybie Idle i oczekują na klientów. Gdy klient wysyła żądanie do serwera Apache moduł MPM ,Prefork przekazuje zadanie obsługi do procesu potomnego (oraz oczywiście, jeśli jest to możliwe, tworzy kolejny proces w stanie „Idle” do ewentualnej obsługi kolejnego klienta).
W uproszczeniu proces potomny działa do momentu, aż nie odbierze wszystkich danych od klienta, po czym wykonuje zaprogramowane operacje i odsyła odpowiedź. Jest to bardzo stabilne podejście, niezwykle pasujące do bezstanowego protokołu HTTP. Gdy proces załamie się, nie wpływa to w żaden sposób na inne procesy. Niestety wyżej opisane podejście okupione jest kilkoma problemami.
Największym z nich jest apetyt na pamięć. Każdy proces Apache zajmuje dużo pamięci, chociażby przez fakt redundancji niektórych bibliotek i niewspółdzielonego kodu. Powoduje to, że serwery, do których podłącza się wielu klientów, zaczynają mieć problemy z wolną pamięcią RAM, a sam procesor traci dużo czasu na ciągłe tworzenie i usuwanie procesów.
2. Apache – MPM Worker
MPM Worker jest drugim najbardziej znanym modułem Apache. Do niedawna cechował się mniejszą stabilnością, ale przez kilka lat stał się podstawowym zarządcą żądań konfigurowanym przez bardziej doświadczonych administratorów Apache.
W odróżnieniu od domyślnego Preforka, MPM Worker jest modułem obsługującym wielowątkowo dużo większą liczbę klientów przy mniejszym zużyciu pamięci. Jego działanie ilustruje rysunek 4.:
Rys.4. Apache MPM Worker – ogólna zasada działania (po kliknięciu uruchomi się animacja).
Podobnie jak w poprzednim przypadku, również przy MPM Worker istnieje jeden proces rodzica, który tworzy kilka procesów potomnych. W każdym z tych procesów tworzone są wątki „idle”, które czekają na klientów. Wątek, czyli swoisty „proces w procesie” ma za zadanie obsłużyć żądanie, po czym zakończyć swoje życie. Tworzenie wątków jest szybsze niż tworzenie procesów i zajmuje mniej pamięci. Powoduje to, że Apache w trybie MPM Worker potrafi obsłużyć nawet kilkakrotnie więcej klientów na tej samej konfiguracji sprzętowej niż MPM Prefork.
Oczywiście MPM Worker spisuje się dobrze na maszynach wyposażonych w kilka procesorów i tylko, gdy jest odpowiednio skonfigurowany – brak rozsądku w liczbie procesów potomnych oraz wątków w stosunku do liczby procesorów wpłynie negatywnie na czas obsługi żądań, gdy dużo czasu pochłonie sama zmiana kontekstu czasu pracy procesora między wątkami. Trzeba też pamiętać o tym, że w domyślnych konfiguracjach popularne PHP nie jest wielowątkowe i należy troszkę się napracować, aby zmusić je do pracy z Workerem (chociażby delegując obsługę PHP przez wątki CGI).
3. Apache – „wolne” połączenie, „duży” problem
Podsumowując, zdecydowana większość serwerów Apache pracuje w jednym z dwóch trybów:
- MPM Prefork – czyli „proces na żądanie” oraz
- MPM Worker – czyli „wątek na żądanie”.
Niestety w obu powyższych przypadkach proces obsługi żądania (proces/wątek) pracuje tak długo, na jak długo ustanowione jest połączenie. Gdy sztucznie będziemy wydłużać czas połączenia przez powolne dosyłanie nagłówków w częściowych zapytaniach HTTP, tym dłużej będziemy utrzymywać proces lub wątek serwera. W wersji MPM Worker będziemy musieli wykonać więcej przeciągających się połączeń (w praktyce zazwyczaj wystarczy uruchomić dodatkową instancję Slowlorisa na osobnej maszynie).
W domyślnej konfiguracji serwer Apache zrywa połączenie, gdy przez 300 sekund nie otrzyma żadnych danych od klienta. Gdy jednak od klienta otrzyma przynajmniej jeden bajt, zeruje ten licznik i czeka przez kolejne 300 sekund na dane.
Prześledźmy jeszcze raz działanie Slowlorisa. Po stworzeniu kilkuset połączeń i wysłaniu częściowych zapytań HTTP jesteśmy w stanie utrzymać proces/wątek serwera. Wątki te przez (domyślnie) 300 sekund nie będą robić nic innego, niż oczekiwać na nasze dane, czyli nagłówek X-a: b, który w końcu zostanie wysłany. Jednak nie zakończymy wysyłania nagłówków przez wysłanie pustej linii CRLF, zamiast tego poczekamy, aby dalej utrzymywać częściowe żądanie i tak w kółko. Oczywiście liczba procesów/wątków serwera obsługujących żądanie jest ograniczona (chociażby z powodów braku pamięci RAM), co powoduje, że po krótkim czasie zaczniemy przetrzymywać wszystkie procesy/wątki obsługi żądania i uniemożliwimy podłączenie się innym klientom. W praktyce całkowicie paraliżuje to działanie serwera.
W domyślnych konfiguracjach do udanego ataku Slow HTTP Headers na serwer Apache wystarczy jedna maszyna, która utrzyma około 300–600 połączeń (w niektórych konfiguracjach wystarczy nawet 150). Liczby te wynikają nie tyle z konfiguracji sprzętowej, a z konfiguracji samego Apache oraz systemu operacyjnego (zazwyczaj Linuksa).
Chwilę po zakończeniu ataku (Ctrl+C lub po przekroczeniu czasu połączenia przy zbyt odważnych wartościach parametrów Slowloris) następuje rozłączenie gniazd Slowlorisa, przez co serwer niemal momentalnie zaczyna obsługiwać innych klientów.
Co ciekawe, Apache tworzy logi z połączeń dopiero po ich obsłudze, co oznacza, że zazwyczaj na podstawie samego dziennika Apache nie można zlokalizować trwającego ataku.
4. IIS oraz nginx – czy jestem bezpieczny?
Serwer IIS oraz nginx są podawane jako przykład oprogramowania odpierającego atak Slowloris. W kontekście nginx jest w tym dużo prawdy, jednak w IIS jest to w zasadzie tylko „przypadek”.
Proces IIS, przyjmując żądania HTTP, używa pewnego rodzaju „buforu”, w którym przechowywane są nadchodzące żądania. IIS nie przetwarza takich żądań do momentu, aż nie zostaną wysłane wszystkie nagłówki, co odróżnia go od Apache (bez filtru HTTPReady, który aktywuje takie zachowanie w Apache). Dopiero po dosłaniu wszystkich wysłanych nagłówków IIS decyduje, który handler ma dalej obsługiwać żądanie, np. zwracając statyczną zawartość czy przetwarzając stronę ASP. W związku z tym, że zasoby IIS są w praktyce przydzielane dopiero po wysłaniu wszystkich nagłówków, atak Slow HTTP Headers nie ma tutaj żadnego zastosowania.
Nie oznacza to, że administratorzy IIS mogą czuć się bezpiecznie – przy odpowiednim sterowaniu parametrami skryptu Slowloris, a tak naprawdę wykonując inną odmianę atak Slow HTTP, można wykonać udany atak DoS na IIS równie prosto, jak w wypadku serwera Apache. Taki scenariusz zostanie opisany w następnej części cyklu.
Serwer nginx stosuje całkowicie inną strategię obsługi żądań niż poprzednicy. Przede wszystkim nginx posiada tylko jeden proces, który przyjmuje i obsługuje żądania (w dużym uproszczeniu, ponieważ istnieją również Workery). Sam proces obsługi żądania jest realizowany w tzw. pętli zdarzeń (ang. Event Loop), która w praktyce jest implementacją wzorca Reactor będącego sercem takich technologii jak chociażby Node.js. W tym podejściu każda akcja jest zdarzeniem, które trafia do pętli zdarzeń. Zdarzeniem jest np. odebranie żądania, odebranie kolejnego bajtu powolnego żądania, odczytywanie danych z dysku czy nawet zwrócenie odpowiedzi do klienta. Mimo że wszystkie żądania odbierane są przez jeden wątek, to wykonywane są w modelu nieblokującym, asynchronicznie. Przez to że oczekiwanie na dalsze dane nie blokuje wykonywania innych zdarzeń, atak Slowloris staje się mało efektywny.
Czy koncepcja serwerów „zdarzeniowych”, w tym lubianego przez wielu nginxa jest remedium na zagrożenia Slow HTTP? O tym dowiemy się w kolejnych częściach cyklu.
Podsumowanie
Skrypt Slowloris zapoczątkował erę ataków Slow HTTP DoS, które przy bardzo małym nakładzie pracy i zasobów potrafią efektywnie blokować działanie nawet bardzo dużych serwisów.
Poznaliśmy zasadę działania skryptu Slowloris, który uwydatnił wady serwerów WWW. W następnej części poznamy inne warianty ataków Slow HTTP – ich metodę działania oraz kolejne sposoby testowania. W dalszych częściach przybliżymy również problem ochrony przed tym niezwykle uciążliwym zagrożeniem.
Maskotka ataku Slow HTTP Headers DoS – małpka z rodziny lorisowatych (źródło).
Bibliografia
- RFC2616 Hypertext Transfer Protocol – HTTP/1.1
- http://stackoverflow.com/questions/21072713/what-exactly-is-the-linear-whitespace-lws-lwsp
- http://www.rfc-editor.org/std/std68.txt
- http://tools.ietf.org/html/rfc4229
- http://ha.ckers.org/slowloris/
- http://en.wikipedia.org/wiki/Reactor_pattern
- http://www.slashroot.in/how-is-nginx-different-from-apache
- http://www.thegeekstuff.com/2013/11/nginx-vs-apache/
Adrian “Vizzdoom” Michalczyk
Apropo 'Testowania podatności’, nmap posiada wbudowany skrypt który weryfikuje czy dany host jest podatny.
nmap –script http-slowloris-check
Yup, dokładnie. Ale jakby co, w następnej części poznamy jeszcze fajniejszą metodę weryfikowania takich podatności :)
Super artykuł!
Mam nadzieję, że w następnej części gdzie będzie o obronie przed tego rodzaju atakami przedstawione zostaną rozwiązania również oparte na np. iptables, a nie tylko modułach do serwera www. Niektóre, inne aplikacje (zupełnie nie związane z serwerem www) też są podatne na tego rodzaj ataku, a np. nie oferują możliwości instalacji modułów i istnieje rozwiązanie tylko na filtracji za pomocą np. iptables.
Będą przedstawione głównie metody oparte o obronę w warstwach niższych, a nie tylko serwerze WWW. Ogółem problem obrony jest tutaj ciekawy (jeszcze go opracowuję) i obecnie planuję go poruszyć szeroko w części trzeciej. Na razie skupimy się na samych atakach.
I tak przy okazji – witam czytelników po mojej przerwie od pisania :)
Zaczynam od rana czytać sekuraka zamiast posty na FB to znaczy że jest tu co czytać a ten artykuł jest tego dowodem.
No to zachęcamy do promocji vortalu wśród znajomych. Czym więcej publiki, tym większa motywacja wśród autorów i lepsza dyskusja w komentarzach :D
Ciekawe jest to że taki atak można 'ubić’ na poprawnej konfiguracji np:
http://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html
Oczywiście świadomość czy taki atak powstanie czy nie, jest już inną sprawą ;)
Sam atak, jest dość ciekawy bo z założenia, można wyczerpać każde zasoby, 'każdego serwera’ który pozwala na potrzymanie połączenia, np serwer FTP posiada PWD, NOOP, czy inne podobne.
W każdym przypadku, ilość połączeń jest ograniczona, i kilka maszyn vs jeden serwer nie ma szans na przeżycie.
W sumie na każdy s serwerów można (wypadało by), nałożyć kolejne warstwy przeciw DDoS, lub używać 'balancera’ (Network Load Balancing), w przypadku 'anomali’ typu: 200 połaczeń z 1 IP, wywalic na tablesie.
http://www.cyberciti.biz/faq/iptables-connection-limits-howto/
Tak jest się z czym bawić ;)
PS: Jak to w życiu bywa na każdego znajdzie się metoda … kwestia czasu, i fantazji ;)
Z modem reqtimeout i innymi tego typu zabawami (łącznie z iptables) jeszcze się pobawimy w tym cyklu. Ale ładnie nakreśliłeś już problematykę.
No cóż – ochrona przeciwko DoS to zawsze zabawa w kotka i myszkę. Tutaj jest to szczególnie widoczne.
Innym ciekawym przypadkiem może być tego typu atak na WebSockety, które wchodzą pomału do „mainstreamu”
Websockety, albo tak jak ktoś już w komentarzach wspomniał, stary dobry FTP i wiele innych ;-)
Ogromne dzięki za artykuł i zapoznanie z narzędziem! Dzisiaj pierwszy test i od razu zadowalające rezultaty – tool działa bez zarzutów ;)
No to pięknie, mam nadzieję, że klient/członkowie projektu zadowoleni z PoC. Teraz pewnie przyjdzie czas z zabezpieczeniem i tu się zaczyna dopiero ciekawie.
Do publikacji części związanej z ochroną minie troszkę czasu (po drodze inny cykl, urlopy itp.), więc jak wymyślisz coś ciekawego, to daj znać mailem ;-)
Na Seconference 2014 była ciekawa prelekcja o tym ataku razem z pokazem na żywo. Były też omawiane inne (wg. autora jeszcze groźniejsze) ataki na HTTP. Czy będą one omówione w kolejnych artykułach?
Nie kojarzyłem wcześniej tej prezentacji, ale faktycznie, jest tam kilka przypadków, które zostaną opisane w kolejnych częściach.
Trochę wazeliny. Artykuł rozwalił mnie na łopatki. Jestem laikiem w tych tematach ale czytało się bardzo dobrze. Podeślę to teraz swoim programistom:-)
Miałem takie ataki już i musze powiedzieć że w sumie odpowiednio dobrane timeouty + jednocześnie odpowiednio duże limity apache i małe iptables skutecznie pomagają na proste slowloris. Niestety gdy atakujący ma do dyspozycji dużo maszyn i/lub wątków no to niestety już nic nie pomoże. Zawsze to będzie siłowanie się. Jak nie na gbps, to na ilośc ;/
http://www.autosectools.com/Page/HTTP-Denial-Of-Service
No to czekamy nadal :)
Bardzo fajny artykuł! Podoba mi się bardzo.
Mam drobne pytania. Padło tutaj, że mamy do czynienia ze slow http headers. A czy można opóźniać również przesyłanie treści (ciała) żądania, nie tylko nagłówków? Jak długo (w standardowej konfiguracji apache) można opóźniać wysyłanie kolejnych części żądania http?
[…] SMBloris została wymyślona w odniesieniu do ataku Slowloris autorstwa Roberta Hansena. Obywa ataki są w stanie za pomocą jednej maszyny zawiesić znacznie […]