Ono je to všechno pěkné, ale vždyť přesně proti SYN floodu by měl být imuní systém SYN cookies. Neví někdo erudovaný, proč tak zastaralý útok udělal takové problémy?
Kedze podhadzovali IP adresy nic ine sa robit neda. Cele nadviazanie s podhodenou IP urobit nevies. Problem nespociva v SYN floode attack, ten je uz obvykle vyrieseny na strane servra ale v mohutnosti toho utoku.
Ty podvržené IP nehrají v tomhle případě žádnou roli, jen blokují pokusy o filtrování útočníků. Co se objemu týče, tak jestli jsou ta data z NIXu relevantní, tak objem dat nebyl nijak závratný, aby zahltil linku.
To mi taky není příliš jasné - a napadá mě, jestli to není tím, že všichni používají nějaký "předsunutý firewall" - který SYN cookies neumí. Všichni si totiž stěžovali, že se jim přetěžuje firewall.
Tak tieto firmy obvykle pouzivaju HW zariadenia na to urcene. Tie tipujem maju jednak detekciu takehoto utoku a naslednu opravu. Ono ale aj tak dochadza k zahlteniu pretoze je nutne alokovat polozky v tabulkach a nejaku dobu ju tam drzat (sekundy) pokial nepride potvrdenie (keby vedeli urobit kompletne uvodne spojenie tak to moze byt az 100 sekund). Ta doba sa da skratit ale potom zacnu vypadavat aj regulerne pomale spojenia. Potom treba tu tabulku prechadzat a taketo spojenia vyhadzovat. No a proste pri tom pocte je to OVER.
Reseni pomoci SYN cookies spociva prave v eliminaci tabulky prichozich spojeni.
I me by zajimalo, zda takove reseni neni dostatecne nebo se nepouziva a proc.
Praveze SYN cookies ma tu vyhodu, ze po prijati uvodneho SYN paketu nemusis nic ukladat do ziadnej tabulky ani do queue. Do SYN-ACK paketu zakodujes svoje info ktore potrebujes a viac sa nestaras. Pokial ti pripade finalny ACK, tak z neho vies vsetko vycitat a do tabulky connection zapises az teraz. Pokial ziadna odpoved nepride, tak ta to nezaujima lebo si o tej connection nic nepamatas. Akurat ta to stalo par instrukcii na odoslanie SYN-ACK.
Akurat ze vacsina linuxovych distribucii ma SYN cookies default vypnute, zapnut sa daju cez /etc/sysctl.conf. A aj ked su zapnute tak linux ich zacne pouzivat az ked je pod utorom (asi ked sa zaplni backlog queue), kedze nie vsetky info vies do toho SYN-ACK zakodovat, takze v pripade utoku stracas podporu zopar TCP vlastnosti.
Tiez neviem preco to v tomto pripade nepomohlo. Naozaj to moze byt tym, ze FW nestihal, ale ved prave pri SYN floode nejde o velke pocty paketov... Alebo mozno uz az takom velkom rozsahu uz SYN cookies na to nestacia...
Mozna by to chtelo podrobneji rozvest:
a) bezny provoz - TCP se chova normalne; trifazovy handshaking, server skladuje pozadavky na navazani spojeni ve fronte, funguji timeouty atd.,
b) jsme pod utokem - fronta pozadavku se zaplni a aktivuje se mechanismus SYN cookies; server i nadale odpovida na vsechny pozadavky na navazani spojeni, tj. porad realizuje druhou fazi handshakingu (=> zahlceni se nekona), ale uz si je neuklada. Predpoklada se totiz, ze vetsina pozadavku byla falesnych a tudiz ze na odpoved serveru neprijde zadne potvrzeni klienta (ona treti faze handshakingu). Pokud by ale prislo (=> klient je realny) pozna se z ni vse potrebne pro navazani spojeni. Jak je to mozne? Server pri sve odpovedi nezvolil udaj do pole SYN nahodne, coz bezne dela, ale zakomponoval do nej cas a hlavne komunikujici IP adresy a porty (prohnano pres hashovani). Detaily u autora, TCP cookies: http://cr.yp.to/syncookies.html .
Vzhledem k tomu, jak to vypadalo, tak na to asi HW nemaj. Nic méně HW, který se sám zahltí útokem, proti kterému má chránit a ještě dřív než servery za ním, by byl opravdu výhodná investice.
