> Software-ul a fost scris, si ramane scris... pana acum nu am auzit sa > se rescrie stack-ul IP din kernel-ul linux iar eventualele modificari > nu ai introdus bug-uri vechi, ci le-au reparat. Sau au introdus bug-uri noi, vezi Ubuntu :) http://www.securityfocus.com/news/11409
> Daca ai acces la calculatorul real, de ce il mai spoofezi ? Pai nu am. > Cu ce te ajuta DROP [..] Sa nu se intample ce ai zis tu mai jos ?! > Te referi la SNAT, toate bune si frumoase pana aici. Acel > thread/daemon/program nu va primi nici un pachet, si nici nu are cum, > intrucat "serverul" trimite pachetele catre A, pachetele vor fi routate > catre A, iar A va raspunde frumos cu un RST. In caz ca mai ajunge ceva la el ;-) > Daca citeai documentul din `96 observai ca: > - A era dus, distrus de un Denial of Service asa numit si 'slice', > 'sl2', 'sl3' ... unelte disponibile online. Nu conteaza cum era A dus! (puteai sa-l scoti si din priza, etc...) >Ai auzit de TCP SYN COOKIES Da. > patch pentru linux ? A fost introdus in kernel prin `97-`98. Acest patch > impiedica astfel de atacuri. Corect, se trimite un pachet spre sistemul real. Cand acesta primeste pachetul si vede flag-ul ACK setat va verifica valoarea cookie-ului. Daca este corecta, atunci se ca creea conexiunea, desi nu s-a trimis nici un SYN. And your point is ? (ce te faci daca nu ajunge un astfel de pachet la masina reala, iar o copie a lui ajunge la masina B ?) > - B nu primea nici un pachet, doar ESTIMA numarul secventei TCP, > ESTIMA timpul dupa care ar trebui sa raspunda, si raspundea in numele > calculatorului A, care nu putea trimite RST, intrucat era terminat de un > atac SYN. Pentru linux, in kenel 2.2.13 s-a reparat aceasta problema. De > retinut ca au fost afectate aproape toate sistemele de operare. Nu ai fost atent, nu este vorba de un BLIND spoofing (asta era ipoteza). > Cele 2 metode de atac descrise in doc din `96 nu mai sunt posibile in > software-ul din ziua de azi... sau cine stie... poate Windows Vista va > introduce aceste 'functionalitati' in kernelul lor, intrucat se pare ca > au rescris stack-ul IP. In parte ai dreptate, nici nu am negat acest lucru. Se vede ca ai rasfoit documentul, pacat ca nu ai citit mai atent si mailul la care ai raspuns. > Ceea ce zici tu aici, nu poti reproduce nici in laborator. Citeste > RFC-urile, si vei observa ca protocul TCP nu permite spoofare astfel > incat sa se poata face schimb de date Excelent, putem rasufla usurati :) Avand in vedere ca s-a lungit destul de mult thread-ul asta pe o chestie teoretica, propun ca doritorii de polemica si de alte discutii fructuoase pe tema asta sa-mi scrie pe adresa personala (poate sunt unii pe care nu-i intereseaza subiectul acesta). -- Andrei Saygo _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
