DDoS

[smurf]

@TQM:
Z doświadczenia wiem , że GET / POST nie są najlepszymi atakami DDoS, szczególnie w kontekście tego co napisał lame .
Rozumiem, że większość starszych administratorów mierzyła się z takimi atakami , ale są 'z dolnej półki' chyba, że mamy do
czynienia z atakami masowego downloadu - tutaj sprawa się odwraca, zmasowany atak przyniesie szybsze efekty od zwykłych
requestów GET / POST.

[TQM]

Sorry, ale widac ze nie rozumiesz o czym mowa... DDoS GET/POST vs. DDoS SYN-flood.

Uwierz mi, ze glupie zapytania GET/POST sa w stanie sprowadzic system do parteru znacznie szybciej niz SYN-Flood... co prawda jak dobijasz do paruset mbit/sek na samych pakietach SYN to i tak to juz nie robi zadnej roznicy.

Teraz badz tak laskaw i podaj konkretne argumenty dlaczego taki atak jak podajesz (generalnie prosty flood) jest lepszy odDDoS uzywajacego GET/POST. Jestem bardzo ciekaw jakie argumenty przedstawisz

[smurf]

Okej, więc nacieramy dalej
Po pierwsze. Atak bardzo latwy do wykrycia, wystarczy ciagly prosty TCP(RST) do adresu agresora i bedzie po sprawie, a zeby wyslac pakiet GET / POST musi byc polaczony chyba ze robi atak Blind. Roznica pomiedzy atakiem SYN jest taka ze mozna go robic z roznych adresow dzieki czemu ciezko stworzyc dla niego filtry, a ofiara zawsze musi odpowiedziec ACK lub RST. Dodam tutaj, ze co innego jesli atakujemy odpowiednio spreperowanym atakiem GET / POST DDoS typu masowy download duzych plikow z serwera ofiary.

[TQM]

Ok... to tlumaczymy co i jak dziala w rzeczywistosci

Nieco kontekstu jesli idzie o obrone powiedzmy stron WWW (bo to jest glowny cel atakow DDoS) - zniwelowac atak w taki sposob aby prawdziwy klient nadal mogl sie podlaczyc do serwera i uzyskac odpowiedz w rozsadnym czasie. Zakladamy ze nie doszlismy jeszcze do sytuacji gdzie DDoS samymi pakietami SYN zapycha calutkie lacze firmy, bo wtedy juz nic nie ma znaczenia...

1) Flood pakietow SYN, SYN+URG i innych kombinacji
- Nie ma sensu z tego powodu ze banalny do wykrycia jesli robisz proste profilowanie ruchu, poza tym pakiety SYN mozna spoofowac i czekac by serwer odeslal SYN+ACK do adresu ktory nie odpowie, wtedy zajmujesz zasoby bo serwer czeka na odpowiedz ktora nigdy nie wroci... ale uzywa sie SYN-Cookies i problem uwiazania zasobow rozwiazany czesciowo.
- Profilowanie ruchu to podstawa - jesli widze jakiekolwiek cechy charakterystyczne w ruchu DDoS to moge to odfiltrowac na krancowym firewallu i po sprawie - atak wyciety, jedyne co to to ze zatyka nieco lacza.
- Serwer odpowiada pakietem RST - mit, nie ma takiej potrzeby... wrecz jest to niewskazane z co najmniej paru powodow...
- W zaleznosci od ustawien serwera i jego stosu TCP/IP kazde nawiazane polaczenie TCP zajmuje iles pamieci RAM - wyczerpanie RAM oznacza koniec pracy serwera ale tym mozna ladnie manipulowac po stronie serwera i co inteligentniejsze firewalle potrafia regulowac ruch sieciowy bawiac sie opcjami TCP
- ilosc nowych polaczen w jednostce czasu pozwala okreslic profil danego adresu IP - dalej prosta obserwacja wynikow i w locie generujesz blocklist'e
- pozwalasz nawiazac polaczenie TCP i patrzysz co dalej... w ciagu minut masz profil co wycinac :P

2) Atak L7 na HTTP - pelen GET/POST, chocby zaladowanie strony glownej
- atak robi wszystko to co SYN-Flood (i jeszcze wiecej)
- generuje znacznie wiecej ruchu niz SYN flood
- dodatkowo obciaza serwery bo te musza zrobic I/O dyskowe, byc moze uruchomic aplikacje (CPU i RAM leci od razu), komunikacja trwa dluzej niz SYN, SYN+ACK, ACK...
- musisz jakos okreslic, czy polaczenie to prawdziwy klient czy bot (a to juz nie jest tak proste bo np AOL przekazuje caly ruch z USA, Niemiec, Anglii i paru innych krajow przez raptem kilka duzych proxy i masz tysiace userow ukrytych za jednym adresem IP)
- itp... nie m sensu juz dalej pisac

Wnioski
Jesli wiec zablokujesz nie tego co trzeba to jako organizacja tracisz klienta (pieniadze, reputacje, cokolwiek).
DDoS bardzo latwo przeprowadzic ale sa sposoby blokowania roznych smieci. Jedyna skuteczna obrona to duza rura na swiat aby nie braklo lacza, urzadzenia ktore pozwalaja w czasie rzeczywistym analizowac ruch do poziomu analizy protokolu HTTP i na bazie analizy TCP i HTTP jednoczesnie podejmuja decyzje. Mozna zawsze ograniczyc ilosc nowych polaczen w jednostce czasu i dac limit na calkowita ilosc polaczen z jednego IP - jak przegladarka ktora normalnie otwiera 8 polaczen do serwera (bo tak wiekszosc robi - srednio 4 polaczenia na serwer) da rade otworzyc jedno to strona sie zaladuje... ale nieco wolniej - w pelni akceptowalne.

I jak, udowodnilem ze atak L7 jest o wiele skuteczniejszy niz zwykly flood?

[lame]

Chciałbym zauważyć, że przy mojej technice, przeciętnie każdy użytkownik zaatakuje raz, może ze dwa razy, nie wiem zatem co chcesz i gdzie wysyłać, jakie RST.. Zresztą za NATem to ma jakiś sens? Nie wiem.
Poza tym nie rozmawiamy o atakowaniu jednego serwera.
Round Robin, Load Balancer.. Cholera wie co jeszcze.
Infrastruktura celu może być tak złożona i rozbudowana, że czacha pęka.
Chce Ci się to rozpracowywać inaczej niż zapychając łącze masą GETów i POSTów względem strony głównej? Ambitne..

[TQM]

NAT zupelnie nic nie zmienia w przypadku odsylania RST. Robiac atak taki ze klient (w sensie IP) trafia serwer 2-3 razy to sorry, nawet tego nie zauwaze a nie dasz raczej rady wygenerowac masy krytycznej aby zakwalifikowac to jako DDoS.

Pare przykladow (i lekcji) z mojego podworka...
- DDoS L7 na jedna z domen wygenerowal raptem 50mbit ruchu na wejsciu, sami zrobilismy DoS kanalu wyjsciowego wysylajac odpowiedzi na te requesty, pozostale strony przestaly odpowiadac (nauczka: wprowadzic egress traffic shaping)
- mierzyc sily na zamiary... doslownie kilka serwerow w clustrze (malenki cluster), strona praktycznie statyczna, load-balancery spinaja calosc - przychodzi DDoS, serwery zuzycie CPU w gore o 22-25% jedynie, pada glowny load-balancer - jestem off-line (wniosek: im bardziej skomplikowana struktura tym bardziej skomplikowana obrona bo trzeba wiecej systemow pilnowac i powstaja bardzo ciekawe zaleznosci)
- rekonfiguracja frontowego firewalla przed load-balancerem - zdejmuje obciazenie z LB ale podnosi na FW... jak padnie FW to LB zanudzi sie na smierc (wniosek: konieczny ciagly monitoring przez caly czas jak trwa atak, 24/7/365 jesi trzeba)
- gdy znajdziesz slodki punkt i wszystko ladnie dziala nagle atak wzrasta i zatyka ci lacze glupimi pakietami SYN, dzwonisz do uplink'ow aby zareagowali ale moj ruch jest u nich na poziomie szumu (kolesie klada po kilkadziesiat gbit/sek przez ich szkielet wiec moje pakiety sa niewidoczne)
- jak w 2006 przyszedl DDoS na poziomie >40gbit/sek to polozyl cala serwerownie (a to nie ja bylem celem tak w ogole) - pareset firm off-line... cale szczescie bylem na wakacjach

[smurf]

Chciałbym zauważyć, że przy mojej technice, przeciętnie każdy użytkownik zaatakuje raz, może ze dwa razy, nie wiem zatem co chcesz i gdzie wysyłać, jakie RST.. Zresztą za NATem to ma jakiś sens? Nie wiem.
Poza tym nie rozmawiamy o atakowaniu jednego serwera.
Round Robin, Load Balancer.. Cholera wie co jeszcze.
Infrastruktura celu może być tak złożona i rozbudowana, że czacha pęka.
Chce Ci się to rozpracowywać inaczej niż zapychając łącze masą GETów i POSTów względem strony głównej? Ambitne..

Mądrze powiedziane lame
Co prawda TQM patrzy pod kątem wykrywalności po stronie serwera, ja patrzę na całokształt, czyli strona klienta i strona serwera.
Przypuśćmy zainfekowanie komputera złośliwym oprogramowaniem. Flood paczkami GET / POST duzo bardziej
obciąża łącze niż SYN, przez co potrzeba większej ilości zombie i bardzo dobrego ukrycia malware w OS.

Inny przykład to infekcja całej sieci lokalnej ofiary i rozpoczęcie ataku choćby protokołem ICMP robiąc pętelkę
pomiędzy serwerem a komputerami LAN.

GET / POST prowadzi do zapchania całego łącza przy czym SYN może nawalać dalej, jeśli mamy mówić o tym który atak jest efektywniejszy określmy najpierw jak wykonać to z innych komputerów / serwerów

[TQM]

Przypuśćmy zainfekowanie komputera złośliwym oprogramowaniem. Flood paczkami GET / POST duzo bardziej
obciąża łącze niż SYN, przez co potrzeba większej ilości zombie i bardzo dobrego ukrycia malware w OS.

I o to wlasnie chodzi... dobrze napisany kod nie obciazy klienta az tak bardzo a po stronie serwer dowali ze glowa mala i wcale nie trzeba tak wielu zombie!

Dalej jednak moim zdaniem sie mylisz nieco bo ruch HTTP jest najpopularniejszym jaki teraz obserwujemy, wiec ciezko jest okreslic czy cos laczace sie jest zlosliwe czy nie. Poza tym mozna zainfekowac przegladarke (drive-by) i kawalkiem JS generowac zapytania z przegladarki. To ze zapchasz lacze klienta to nie problem - robisz zaptania pojedynczo ale przez dlugi okres czasu i masz super efekt. Klient nie wie co sie dzieje bo nie zauwazy, w koncu otwiera wiele stron... Jesli program jakis monitoruje co biega na kliencie, zobaczy przegladarke robiaca zapytanie i tyle - czy przegladarka powinna robic zapytania do serwerow WWW, czy to jest normalne zachowanie tego programu? Jak najbardziej!

Jesli robisz syn-flood albo ICMP flood... na poziomie sieci klienta kazdy system wykrywania anomalii (nawet tak prosty jak liczniki ruchu) wykaze nagly wzrost liczby pakietow w danym protokole. Takie cos od razu krzyczy ze cos jest nie tak.

Przyklad z jednego z moich DDoS'ow - oto dlaczego powazny admin powinien znac profil swojego ruchu sieciowego...
Mam domenke ktora odwiedza spooooro ludzi wiec moge zrobic profil... analizujac logi widze jakie sa przegladarki (user-agent string) i jaki udzial w ruchu maja. To samo moge zrobic dla pakietow TCP, zobaczyc jakie maja wlasciwosci itd. Tworze w ten sposob wykres albo tabelke i porownujac kolejne dni wyznaczam udzial procentowy. Teraz po miesiacu robie wykres - mediana i wariancje w gore i w dol. Teraz jesli przyjdzie DDoS to na pewno gdzies cos sie zmieni i ten dzien/godzina/cokolwiek nie bedzie pasowal do ogolnego profilu. Oczywiscie nie powiem Wam co monitoruje dokladnie ale lista parametrow jest dosc ciekawa - nie sa to jakies wielkie rzeczy bo jestem w stanie robic to niskim kosztem i w czasie rzeczywistym ale...

Przykladowe wartosci wziete z kapelusza ale tak to mniej wiecej dziala:
- normalny ruch: IE 60%, FF, 25%, Chrome 15%, inne 10%
- DDoS: IE 99,4%, inne 0.6%
Co z tego wiem? Tyle ze atak przeprowadzany jest za pomoca przegladarki IE (rozne werjse), dalsza analiza naglowkow klienta (na bazie logow) pozwala okreslic jakie jezyki sa uzywane przez przegladarke a wiec zawezic kraje atakujace (zrodlo infekcji) do malej grupy - jesli 90% mam Finalndii i Ukrainy to wiem ze to jakis atak ktory trafil te dwa kraje, zaczynam limitowac ruch dla nich, pozostali sa ok, lacze to z GeoIP i mam miejsce gdzie moge potwierdzic ze to nie spoof naglowka. To samo dotyczy wersji pluginow itp - mozna statystycznie wskazac skad pochodzi problem (np klienci ze starsza wersja .Net ktora zostala zalatana tydzien temu). W ten sposob moge kopac dosc gleboko i jesli moje urzadzenia (load-balancery albo nawet zwykle proxy) potrafia te pola zobaczyc, to moge ten ruch odfiltrowac.

... a klient - dalej pobiera dokladnie ten sam dokument przez kolejne godziny lub dni, raz po raz nigdzie sie nie spieszac i nie generujac alertow u ISP ani samego usera.

[Piter2704]

Jeśli już uśmiercać maszynę to tylko Ddos botnet i serwer spada jak bomba
atomowa na Hiroszimę ; )) . Jeśli ktoś zainteresowany jak to działa PW
udziele odpowiedzi w celach edukacyjnych