пропозиції роботи
Wypowiedzi
-
Jak dawno sie tu nie logowalem... ;p- 28.01.2012, 23:58
Pokaż wszystkie 1 komentarz -
Witam Panow dyskutujacych :) - czesc rezos, czesc ouna :)
Pozwole wtracic sie w owa dyskusje - mam nadzieje, ze wolno i nie bedzie nikt na mnie zly za to.
Osobiscie uwazam ze obaj macie racje tylko omawiacie zupelne inne idee atakowania DDoS. Najpierw kwestia rezos'a - owszem przemek ma racje. Dodatkowo dorzucilbym do mod_security i mod_rewrite wysmienity modol mod_evarista. DDoS nie zawsze jest wykorzystaniem botnetu z 2348579324658342756893425 iloscia komputerow i prowadzenie SYN Flood'a czy GET Flood'a korzystajac z owego botnetu. Trzeba pamietac ze lacze dziala w 2 strony i jezeli mamy jakis atak DDoS w stylu zapytania do servera po jakis duzy plik, wowczas serwer nie dosc ze traci lacze na obsluzenie samego zapytania ale + na przeslanie pliku wiec jedno zapytanie moze generowac ogromny ruch z serwera. Wykorzystujac owe moduly (dalej polecam mod_evarista) mozna latwo wykryc IP+ilosc_zapytan i zamiast przeslac odpowiednia strone/plik ktora zezre nam przykaldowo 2mb lacza to zwrocic kod 5xx albo 4xx co tylko zezre nam parenascie bajtow. wiec zamiast wysylac do kazdego zapytania zalozmy 2mb kodu czegos to wyslemy naglowek jezlei porownamy teraz X*2mb a X*<30> to roznica jest znaczna. Dodatkowo jezeli jezeli wykryjemy ze nadal nasycenie lacza wzrasta mzoemy poprosty zerwac polaczenie (firewall / ids). DDoS ograniczony? ograniczony...
No ale zarazem ouna- ma racje :) Jezeli ktos jednak ma duzy botnet to mozemy tylko sie modlic... do ISP :)
Obaj macie racje! Tylko mowicie o calkiem roznych atakach DDoS. Podpisuje sie tez rekoma i nogami ze przy odpowiednim botnecie mod_* moze conajwyzej byc :) -
;]
-
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 -
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 ;] -
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. -
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
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
