Temat: HTTP DoS

http://isc.sans.org/diary.html?storyid=6613 - Macie jakieś inne, praktyczne pomysły jak zminimalizować szanse skutecznego ataku?

Temat: HTTP DoS

http://mod-qos.sourceforge.net/

Temat: HTTP DoS

Albo mieć porządny firewall, na stronie firmy w której pracuje nie chce działać, chyba że z sieci wewnętrznej.

iptables też powinno pomóc np.

 connlimit

       Allows  you  to restrict the number of parallel connections to a server

       per client IP address (or client address block).



       [!] --connlimit-above n

              Match if the number of existing connections is (not) above n.



       --connlimit-mask prefix_length

              Group hosts using the prefix length. For IPv4, this  must  be  a

              number  between  (including)  0  and 32. For IPv6, between 0 and

              128.

Można też tymczasowo postawić reverse proxy na lighttpd (który podobno nie buguje się na tym) i skrócić timeout w apache2.conf, drugiej metody nie sprawdzałem ale pierwsza pomaga, chociaż nie w 100%

Temat: HTTP DoS

Mariusz Gronczewski:
Albo mieć porządny firewall, na stronie firmy w której pracuje nie chce działać, chyba że z sieci wewnętrznej.

iptables też powinno pomóc np.

 connlimit

       Allows  you  to restrict the number of parallel connections to a server

       per client IP address (or client address block).



       [!] --connlimit-above n

              Match if the number of existing connections is (not) above n.



       --connlimit-mask prefix_length

              Group hosts using the prefix length. For IPv4, this  must  be  a

              number  between  (including)  0  and 32. For IPv6, between 0 and

              128.

Można też tymczasowo postawić reverse proxy na lighttpd (który podobno nie buguje się na tym) i skrócić timeout w apache2.conf, drugiej metody nie sprawdzałem ale pierwsza pomaga, chociaż nie w 100%

Rozwiązanie z FW wydaje się mieć największy potencjał. Problem z TimeOutem w Apache 2.x jest taki, że trzeba uruchomić więcej wątków w slowlorisie i Apache nadal pada - jest o tym pod linkiem, który podałem w pierwszej wiadomości.

Temat: HTTP DoS

Firewall to chyba podstawa. Ale zapewne jakiś IPS też by mógł sporo pomóc...

Temat: HTTP DoS

Ciekawe co chcecie w firewall'u porobic by ograniczyc ten atak ? :) IPS'y tez nie pomoga. Tak naprawde poki nie zalataja tego w kodzie to nie mozna sie przed tym calkowicie obronic. Mozna ograniczej limit per IP - ale wtedy ludzie zza NAT'u beda mieli problem, a ten kto chce atakowac skorzysta z paru maszyn.

Proponuje zaglebic sie w idee bug'u a potem sugerowac FW :)

Tak jak Pan Mariusz proponuje z reverse proxy, to jest to obecnie chyba jedyne skuteczne rozwiazanie (oczywiscie jest to latanie skutkow nie przyczyny), zanim nie zmodyfikuja kodu.Adam Zabrocki edytował(a) ten post dnia 28.06.09 o godzinie 18:23

Temat: HTTP DoS

Adam Zabrocki:
Ciekawe co chcecie w firewall'u porobic by ograniczyc ten atak ? :) IPS'y tez nie pomoga. Tak naprawde poki nie zalataja tego w kodzie to nie mozna sie przed tym calkowicie obronic. Mozna ograniczej limit per IP - ale wtedy ludzie zza NAT'u beda mieli problem, a ten kto chce atakowac skorzysta z paru maszyn.

Nie byłbym taki pewien, że FW nie pomoże. Wbrew pozorom NAT'ów, które ukrywają duuuża ilość klientów nie jest tak bardzo dużo jak się wydaje. Trzeba wziąć pod uwagę, że największy problem dotyczy tych ludzi, korzystających z Apache, którzy mają 1-2 serwery. Tam liczba pracujących httpd jest prawdopodobnie najmniejsza, ale też i ilość odwołań do nich przy 'normalnej' pracy nie jest bardzo duża. Tym samym limit per IP nie powinien skutkować częstym wyzwalaniem reguł blokujących normalnych użytkowników.

BTW: Przy tak prostej architekturze łatwo będzie uruchomić wspomniane reverse-proxy.

Przy dużo większych instalacjach jest inna sytuacja:
- N serwerów przy M procesach httpd
- przed httpd Apache jest jakiś load-balancer, który może pracować na kilku różnych warstwach
- jeżeli jest tam load-balancer pracujący na warstwach wyższych niż 3 to prawdopodobnie nie jest to Apache i poradzi sobie z tym rodzajem ataku, jeśli nie to liczba httpd, które trzeba wysycić jest duża (NxM)

Przed rozproszonym DoS'em nie ma uniwersalnych metod obrony[1] - bez względu czy jest to DoS w 3 czy 7 warstwie.

Proponuje zaglebic sie w idee bug'u a potem sugerowac FW :)

Adam, masz na myśli fakt, że jest to HTTP DoS, a nie TCP DoS?
Firewall to nie panaceum, a jedynie rozwiązanie pozwalające zminimalizować ryzko. Do jakiego poziomu? Wszystko zależy od implementacji, zdrowego rozsądku i potrzeb.

Tak jak Pan Mariusz proponuje z reverse proxy, to jest to obecnie chyba jedyne skuteczne rozwiazanie (oczywiscie jest to latanie skutkow nie przyczyny), zanim nie zmodyfikuja kodu.

Przy lawinowo rosnącej liczbie połączeń I(D|P)S też pomoże. Nawet taki w postaci skryptu shellowego.

Zgadzam się, że nie jest to rozwiązanie idealne i właściwe, ale o takie muszą postarać się już panowie od Apache. Z drugiej strony my nie możemy stać i patrzeć jak kolejny dzieciak odpala Slowlorisa czyniąc nasz site niedostępnym.

PS
IMHO FW to podstawa i to nie tylko taki, który pozwala na dostęp do danych portów czy połączeń w danym stanie. Jest wiele innych aplikacji podatnych na podobne ataki, ale póki nie ma publicznie dostępnego narzędzia, które obnaża ich słabości to mało kto się tym przejmuje. Przypomnijmy sobie, że słabość Apache, którą wykorzystuje Slowloris nie jest nowa, jest znana przynajmniej od 2 lat.

[1] - przy założeniu, że przed Apache nie ma nic poza prostym (stanowym) FW

Temat: HTTP DoS

Przemysław S.:

Adam Zabrocki:
Ciekawe co chcecie w firewall'u porobic by ograniczyc ten atak ? :) IPS'y tez nie pomoga. Tak naprawde poki nie zalataja tego w kodzie to nie mozna sie przed tym calkowicie obronic. Mozna ograniczej limit per IP - ale wtedy ludzie zza NAT'u beda mieli problem, a ten kto chce atakowac skorzysta z paru maszyn.

Nie byłbym taki pewien, że FW nie pomoże. Wbrew pozorom NAT'ów, które ukrywają duuuża ilość klientów nie jest tak bardzo dużo jak się wydaje. Trzeba wziąć pod uwagę, że największy problem dotyczy tych ludzi, korzystających z Apache, którzy mają 1-2 serwery. Tam liczba pracujących httpd jest prawdopodobnie najmniejsza, ale też i ilość odwołań do nich przy 'normalnej' pracy nie jest bardzo duża. Tym samym limit per IP nie powinien skutkować częstym wyzwalaniem reguł blokujących normalnych użytkowników.

Biorac pod uwage ze limit per IP jest dopuszczalny to i tak to uchroni TYLKO przed script kiddie, poniewaz atak mozna powielic z wielu adresow (wystarczy bodjarze 256/<ilosc dopuszczalnych polaczen per IP>)

BTW: Przy tak prostej architekturze łatwo będzie uruchomić wspomniane reverse-proxy.

Przy dużo większych instalacjach jest inna sytuacja:
- N serwerów przy M procesach httpd
- przed httpd Apache jest jakiś load-balancer, który może pracować na kilku różnych warstwach
- jeżeli jest tam load-balancer pracujący na warstwach wyższych niż 3 to prawdopodobnie nie jest to Apache i poradzi sobie z tym rodzajem ataku, jeśli nie to liczba httpd, które trzeba wysycić jest duża (NxM)

Przed rozproszonym DoS'em nie ma uniwersalnych metod obrony[1] - bez względu czy jest to DoS w 3 czy 7 warstwie.

To nie jest DoS jako szeroko rozumiany DoS. Pod DoS jest wiele ukrytych atakow, tu akurat DoS jest tylko objawem skonczonej liczby deskryptorow.

Proponuje zaglebic sie w idee bug'u a potem sugerowac FW :)

Adam, masz na myśli fakt, że jest to HTTP DoS, a nie TCP DoS?
Firewall to nie panaceum, a jedynie rozwiązanie pozwalające zminimalizować ryzko. Do jakiego poziomu? Wszystko zależy od implementacji, zdrowego rozsądku i potrzeb.

Tu wg mnie nie pomoze - tak jak opisywalem wyzej.

Tak jak Pan Mariusz proponuje z reverse proxy, to jest to obecnie chyba jedyne skuteczne rozwiazanie (oczywiscie jest to latanie skutkow nie przyczyny), zanim nie zmodyfikuja kodu.

Przy lawinowo rosnącej liczbie połączeń I(D|P)S też pomoże. Nawet taki w postaci skryptu shellowego.

Zgadzam się, że nie jest to rozwiązanie idealne i właściwe, ale o takie muszą postarać się już panowie od Apache. Z drugiej strony my nie możemy stać i patrzeć jak kolejny dzieciak odpala Slowlorisa czyniąc nasz site niedostępnym.

Owszem FW moze ochronic przed ./slowloris -dns nasa.gov ale tak naprawde ilosc polaczen nie musi rosnac lawinowo. wazne by przez jak najdluzszy czas utrzymywac polaczenia (default 5 minut) wiec wystarczy co 10 sekund sie laczyc i wiekszosc IDS/IPS nas pusci :)

PS
IMHO FW to podstawa i to nie tylko taki, który pozwala na dostęp do danych portów czy połączeń w danym stanie. Jest wiele innych aplikacji podatnych na podobne ataki, ale póki nie ma publicznie dostępnego narzędzia, które obnaża ich słabości to mało kto się tym przejmuje. Przypomnijmy sobie, że słabość Apache, którą wykorzystuje Slowloris nie jest nowa, jest znana przynajmniej od 2 lat.

[1] - przy założeniu, że przed Apache nie ma nic poza prostym (stanowym) FW

Zgadzam sie :) Nie mniej jednak jak pisalem wyzej problem lezy troszke gdzie indziej niz sie go opisuje.

Ps. nie odbierajcie moich postow jako atak :) Jezeli chodzi o ochrone przed tym atakiem to jak zaznaczylem wczesniej FW nie da tego czego oczekujecie. Obecnie daje rade tylko reverse-proxy.

Ps2. Siema rezos :)

Pozdr.

Temat: HTTP DoS

Z moich doświadczeń (niestety serwery pojechały do kolokacji i nie mogę już się pobawić ;] ) reverse proxy (lighttpd + haproxy) pomagało, ale nie było 100% lekarstwem.

Jeżeli masz dostęp do wielu adresów, to równie dobrze możesz przeprowadzić normalnego DDoSa ;]

Temat: HTTP DoS

Mariusz Gronczewski:
Z moich doświadczeń (niestety serwery pojechały do kolokacji i nie mogę już się pobawić ;] ) reverse proxy (lighttpd + haproxy) pomagało, ale nie było 100% lekarstwem.

Jeżeli masz dostęp do wielu adresów, to równie dobrze możesz przeprowadzić normalnego DDoSa ;]

Owszem :) Z tym, ze ten atak minimalizuje drastycznie ilosc potrzebnych maszyn do ataku. No i w tym tkwi kruczek - zamiast posiadac ~250 maszyn wystarczy ~20. Roznica jest ;]

Temat: HTTP DoS

Niby tak ale przy obecnych cenach botnetów nie taka wielka ;]. Ale każda metoda zmniejszająca skutki chociaż trochę jest dobra. Chociaż bez naprawy tego bezpośrednio w serwerze się nie obejdzieMariusz Gronczewski edytował(a) ten post dnia 29.06.09 o godzinie 16:19

Temat: HTTP DoS

Adam Zabrocki:

Przemysław S.:

Adam Zabrocki:
Ciekawe co chcecie w firewall'u porobic by ograniczyc ten atak ? :) IPS'y tez nie pomoga. Tak naprawde poki nie zalataja tego w kodzie to nie mozna sie przed tym calkowicie obronic. Mozna ograniczej limit per IP - ale wtedy ludzie zza NAT'u beda mieli problem, a ten kto chce atakowac skorzysta z paru maszyn.

Nie byłbym taki pewien, że FW nie pomoże. Wbrew pozorom NAT'ów, które ukrywają duuuża ilość klientów nie jest tak bardzo dużo jak się wydaje. Trzeba wziąć pod uwagę, że największy problem dotyczy tych ludzi, korzystających z Apache, którzy mają 1-2 serwery. Tam liczba pracujących httpd jest prawdopodobnie najmniejsza, ale też i ilość odwołań do nich przy 'normalnej' pracy nie jest bardzo duża. Tym samym limit per IP nie powinien skutkować częstym wyzwalaniem reguł blokujących normalnych użytkowników.

Biorac pod uwage ze limit per IP jest dopuszczalny to i tak to uchroni TYLKO przed script kiddie, poniewaz atak mozna powielic z wielu adresow (wystarczy bodjarze 256/<ilosc dopuszczalnych

> polaczen per IP>)

Pisałem, że ochrona przed DDoS'em to trochę inny temat. FW minimalizuje ryzyko i utrudnia skuteczny atak z jednego źródła. Zgodzisz się ze mną? :)

BTW: Przy tak prostej architekturze łatwo będzie uruchomić wspomniane reverse-proxy.

Przy dużo większych instalacjach jest inna sytuacja:
- N serwerów przy M procesach httpd
- przed httpd Apache jest jakiś load-balancer, który może pracować na kilku różnych warstwach
- jeżeli jest tam load-balancer pracujący na warstwach wyższych niż 3 to prawdopodobnie nie jest to Apache i poradzi sobie z tym rodzajem ataku, jeśli nie to liczba httpd, które trzeba wysycić jest duża (NxM)

Przed rozproszonym DoS'em nie ma uniwersalnych metod obrony[1] - bez względu czy jest to DoS w 3 czy 7 warstwie.

To nie jest DoS jako szeroko rozumiany DoS. Pod DoS jest wiele ukrytych atakow, tu akurat DoS jest tylko objawem skonczonej liczby deskryptorow.

Khm. A czy DoS to z definicji nie jest zajęcie wszystkich wolnych zasobów? Np. deskryptorów? http://pl.wikipedia.org/wiki/DoS

Proponuje zaglebic sie w idee bug'u a potem sugerowac FW :)

Adam, masz na myśli fakt, że jest to HTTP DoS, a nie TCP DoS?
Firewall to nie panaceum, a jedynie rozwiązanie pozwalające zminimalizować ryzko. Do jakiego poziomu? Wszystko zależy od implementacji, zdrowego rozsądku i potrzeb.

Tu wg mnie nie pomoze - tak jak opisywalem wyzej.

Wg. mnie pomoże, ale nie rozwiąże problemu. Pisałem o tym.

Tak jak Pan Mariusz proponuje z reverse proxy, to jest to obecnie chyba jedyne skuteczne rozwiazanie (oczywiscie jest to latanie skutkow nie przyczyny), zanim nie zmodyfikuja kodu.

Przy lawinowo rosnącej liczbie połączeń I(D|P)S też pomoże. Nawet taki w postaci skryptu shellowego.

Zgadzam się, że nie jest to rozwiązanie idealne i właściwe, ale o takie muszą postarać się już panowie od Apache. Z drugiej strony my nie możemy stać i patrzeć jak kolejny dzieciak odpala Slowlorisa czyniąc nasz site niedostępnym.

Owszem FW moze ochronic przed ./slowloris -dns nasa.gov ale tak naprawde ilosc polaczen nie musi rosnac lawinowo. wazne by przez jak najdluzszy czas utrzymywac polaczenia (default 5 minut) wiec wystarczy co 10 sekund sie laczyc i wiekszosc IDS/IPS nas pusci :)

Adam, jesteś świadomy pewnych rzeczy, ja też. Rozmawiamy o ataku, który został zaimplementowany w slowloris.pl. Doskonale wiesz, że przy innych atakach można mutować shellcode i w ten sposób omijać sygnatury I(D|P)S. Rozmawiajmy o innych, lepszych rozwiązaniach.

BTW: Prosty skrypt w shellu może monitorować sesje, ich ilość, stan, tempo pojawiania się nowych i reagować na taki atak. Po FIŚ'ie możemy zrobić taki eksperyment.

PS
IMHO FW to podstawa i to nie tylko taki, który pozwala na dostęp do danych portów czy połączeń w danym stanie. Jest wiele innych aplikacji podatnych na podobne ataki, ale póki nie ma publicznie dostępnego narzędzia, które obnaża ich słabości to mało kto się tym przejmuje. Przypomnijmy sobie, że słabość Apache, którą wykorzystuje Slowloris nie jest nowa, jest znana przynajmniej od 2 lat.

[1] - przy założeniu, że przed Apache nie ma nic poza prostym (stanowym) FW

Zgadzam sie :) Nie mniej jednak jak pisalem wyzej problem lezy troszke gdzie indziej niz sie go opisuje.

Gdzie się go tak opisuje? :>

Ps2. Siema rezos :)

Siema pi3 :>

Pozdrawiam,
--
Przemek

Temat: HTTP DoS

BTW: Prosty skrypt w shellu może monitorować sesje, ich ilość, stan, tempo pojawiania się nowych i reagować na taki atak. Po FIŚ'ie możemy zrobić taki eksperyment.

Bardzo chetnie poexperymenruje ;p

Temat: HTTP DoS

Daniel Fukuda:
http://mod-qos.sourceforge.net/

czy zastosowanie tego modułu pomogło Ci jesli chodzi o Apache i atak DOS (powolny) ??

Temat: HTTP DoS

Wspominałem już wcześniej o haproxy:
http://haproxy.1wt.eu/
opis walki z tym przy użyciu haproxy

i tu config "anty-slowloris"
http://haproxy.1wt.eu/download/1.3/examples/antidos.cfg