SYN-flood obrona, zasady dzialania

[Whizz_BANG]

Witam,

mam problemy ze zrozumieniem do konca pewnych wlasnosci; jezeli mozecie rozjasnijcie

jak wiadomo: Sesja TCP powstaje w wyniku procesu three-way handshake czyli nadawca SYN, odbiorca SYN+ACK, nadawca ACK
atak SYN-flood: wykorzystanie slabosci w momencie przesyłania strumieni pakietów synchronizacyjnych

przeciwdzialanie:
1)SYN-cookies: zrozumiale dla mnie (w iptables to mozna napisac)
2)SYN-defender: jezeli dobrze rozumie, przejmuje wszystkie segmenty SYN przesylane do ochranianego systemu. Polaczenie nawiazane dopiero gdy odebrane jest ACK

on to sobie jakos w buforze przechowuje?
Tzn tego bufora juz nie mozna przeciazyc?

3)SYN-proxy: jezeli dobrze rozumie, wspolpracuje z firewallem, ktory podobnie jak w technice obrony SYN-defender, buforuje caly proces nawiazywania polaczenia; gdy odebrane zostanie ACK, powtarzana jest cala sekwencja nawiazania polaczenia z chronionym hostem

tego za bardzo nie rozumiem... jak on powtarza cala sekwencje nawiazania polaczenia to:

gdzie tu jest sesja TCP?
Czy to jest zasada tego typu: ten host jest zaufany - to sie z nim teraz polaczymy?

4)Ochrona z wykorzystaniem odpowiednich skladni napisanych w firewall'u:
zastosowanie firewall'a, ktory rozpoznaje wiele identycznych strumieni pakietow z bitem SYN, wysylane z tego samego adresu IP,ale:

chyba mozna stworzyc pakiety SYN z losowo generowanym zrodlowym IP?
czy takie rozwiazanie mialoby sens tylko w sieci wewnetrznej?

to chyba tyle pytan

[TQM]

Dobre pytania ale przyznam ze nie do konca rozumiem kwestie defender i proxy z Twojego opisu.

SYN Cookies to jasne - zamiast zajmowac zasoby RAM'u itd tworzone jest cookie i do tego numery ISN o ile pamietam tez sa inaczej generowne. Niestety jest to cos za cos - zasoby obslugujace polaczenie w sensie handshake itd i tak gdzies trzeba skladowac, wiec cookies tylko przenosza z RAM/stosu w inne miejsce. Daje to niezly efekt "pojemnosciowy" kosztem minimalnej utraty predkosci (osobiscie jeszcze nie zauwazylem tego na wlasne oczy).

SYN Defender - nie mam pojecia o co chodzi Tak czy inaczej cos musi obsluzyc te pakiety SYN, zrobic handshake... wiec gdzies te zasoby tak czy inaczej zostana zwiazane. Jak to zostanie nazwane to IMHO nie ma zadnego znaczenia. Podaj prosze jakis url albo cos... gdzie to znalazles, bo ja pierwszy raz slysze takie pojecie.

SYN Proxy - jak wyzej, cos musi udostepnic zasoby w celu nawiazania polaczenia. Sens jest taki jak z kazdym serwerem proxy - on lapie wszystkie smieci i nie odtwarza polaczenie pozniej, ale ustanawia wlasne polaczenie do chronionego serwera i jak jest ruch to po prostu czyta z jednego socketu i pisze do drugiego - zwykly przekaznik. Zaleta taka, ze docelowa, "chroniona" maszyna dostaje tylko autentyczne polaczenia a cale g*** idace z sieci (syn flood) powinno utknac na proxy. Problem zaczyna sie jak polaczenia sa prawdziwe, tzn nie syn-flood ale pelen handshake, wtedy mamy DDoS na proxy i w efekcie tak czy inaczej nasza usluga znika z sieci.

Ostatnia metoda - firewall - nie bardzo rozumiem o co chodzi...
Mozna zastosowac limitowanie ilosci polaczen na konkretne IP ale to nadal nie rozwiazuje atakow typu "distributed" bo mozna miec 2mln atakujacych kompow ktore wysylaja po 1 polaczenia kazdy a Twoj system i tak padnie, poza tym dodatkowa logika limitowania spowolni go dalej. Mozna tak samo nalozyc limit na ilosc pakietow, wielkosc pakietow... ustawaic QoS jakis dynamiczny pewnie tez sie da - zezwolic na burst a pozniej limitowac... ale to przywali w niektore aplikacje - np VoIP, streaming obrazu itd... mozliwosci jest duuuzo wiecej w kazdym razie i kazda pokrywa tylko czesc problemu.

chyba mozna stworzyc pakiety SYN z losowo generowanym zrodlowym IP?

Mozna wygenerowac dowolny pakiet - to najmniejszy problem.

czy takie rozwiazanie mialoby sens tylko w sieci wewnetrznej?

Takie tzn generowanie pakietu z losowym zrodlowym IP czy stosowanie zabezpieczen j.w.?

[Whizz_BANG]

Jezeli chodzi o SYN defender.
Ciezko mi podac żródło, bo tu cos przeczytam, tam przeczytam cos innego i tak sie krece w kolko
np takie cos: http://www.mail-archive.com/fw-1-mai.../msg01473.html

Działanie:
Kiedy serwer wysle pakiet do klienta, chroniacy go firewall sam wygeneruje odpowiedz
W prosty sposob to przedstawie:

siec: host--(Internet)--firewall----serwer

host wysyla ACK, firewall odsyla SYN/ACK, host wysyla ACK
teraz firewall wysyla SYN do serwera, serwer wysyla SYN/ACK, firewall wysyla ACK
dopiero w tym momencie host moze przeslac segment do serwera
Firewall ma czasowe ograniczenie w ktorym musi przyjsc potwierdzenie ACK.
W sumie sam sobie moge odpowiedziec, ze bufora wielkiego nie potrzeba

czy takie rozwiazanie mialoby sens tylko w sieci wewnetrznej?

Takie tzn generowanie pakietu z losowym zrodlowym IP czy stosowanie zabezpieczen j.w.?

glupio zadalem pytanie...ale juz mowie co i jak;
jak juz wspomniales: mozna losowo generowac pakiety z jakims IP zrodlowym;

mamy siec: hosty====firewall+router----Internet

firewall skonfigurowany tak, ze pakiety opuszczajace siec wewnetrzna musza zawierac adresy zrodlowe IP pochadzace z tej sieci (czyli ograniczona jest ilosc, losowo tworzonych, zrodlowych IP).
I chyba tym samym ataki wewnatrz tej sieci tez sa w miare ograniczone.


Dodatkowo:
jeszcze doczytalem cos o algorytmie SYNkill, ktory ma na celu monitorowanie sieci w poszukiwaniu pakietow SYN, ktore nie otworzyly polaczenia po okreslonym czasie. Jezeli je znajdzie wysyla pakiet TCP RST i zwalnia zasoby.


----TQM pytales o zrodla; dołącze pare, ktore mi sie przewinely:
- http://ftp.cerias.purdue.edu/pub/pap...ni-synkill.pdf
- http://cr.yp.to/syncookies.html
- http://www.securityfocus.com/infocus/1729

[TQM]

Nie jestem specem od Checkpoint'a ale wyglada mi na to ze ewidentnie ten caly "defender" to funkcjonalnie jest proxy lub cos podobnego, jak omowilismy wczesniej. Po prostu Checkpoint nazywa to defenderem, ja bym powiedzial ze to zwyczajne proxy (choc moze miec dodatkowe funkcje jakies o ktorych nie wiem).

Filtrowanie o ktorym mowisz to egress filtering - powinien to robic kazdy ISP moim zdaniem, choc to spowoduje zablokowanie pewnych uzytecznych funkcji, jednak wiekszosc osob uzywa tej mozliwosci (nawet nieswiadomie) do atakowania innych (tak robia niekore botnety na przyklad). Brak filtracji przydaje sie jesli masz 2 lacza i jednym chcesz odbierac dane :-)

Co do SYNkill to musze doczytac ale tak jeszcze przed czytaniem mam dziwne wrazenie ze za wiele innowacji w tym nie ma. Jesli nie ma 3-way w okreslonym czasie to takie pol-otwarte polaczenie jest zamykane i zasoby zwalniane. Skrocenie czasu oczekiwania na handshake to parametr jadra najczesciej wiec zmiana czegokolwiek to zmiana wlasnie tego parametru. Jesli nie chcemy grzebac w jadrze i jego rzeczach to mozna to zaimplementowac w user space jako osobna aplikacje - w sumie potrzebne bylyby 2-3 rzeczy... tcpdump, perl, moze hping - na tym mozna zbudowac taki prosty SYNkill

Dobra ide spac bo przechodze powoli na standby... a to dobre nie jest, pozniej sa problemy z obudzeniem i stabilnym podniesieniem (z lozka hihi)