On Sep 02, 2006 12:23 PM, Andrei Saygo <[EMAIL PROTECTED]> wrote: >>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 > Si Microsoft introduce noi buguri, si le reia pe cele vechi periodic .. si ?! discutia era depre kernel-ul linux, si mai precis depsre stack-ul IP.
> >>Daca ai acces la calculatorul real, de ce il mai spoofezi ? >Pai nu am. Ai din moment ce-i pui reguli de DROP sau il scoti din priza. > >>Cu ce te ajuta DROP [..] >Sa nu se intample ce ai zis tu mai jos ?! LoL, parca ti-am zis, sau am vrut sa-ti spun. DACA PUI DROP PE FORWARD PACHETELE GENERATE LOCAL NU SUNT BLOCATE (si mai citeste putin documentatie despre iptables si netfilter poate iti revi) > > >>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 ;-) In caz ca este scos din priza cum zici tu, atunci nu se intampla nimic. > >>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 ?) Bati campii, citeste http://www.cert.org/advisories/CA-1996-21.html, daca intelegi limba engleza. > > >>- 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). Auzi domnu, iti sugerezi sa scrii un document, sa-ti faci bagajele si ne vedem la HackInTheBox sa-ti prezinti ipoteza, fac eu cinste cu drumul daca e nevoie. Asta e ultmul meu post pe acest thread intrucat ori esti prea "shmeker" pentru noi, si nu stii cum sa te faci inteles, ori esti varza si faci pe desteptul. > > >>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). Iar pe tine te depaseste se pare. > >-- >Andrei Saygo > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
