On Fri, 2006-09-01 at 21:47 +0300, Andrei Saygo wrote:
> > Da, in 1996-1999 - pe vremea cand era kernel 2.0 si 2.2 -
> > Vulnerabilitatea s-a reparat in kernel 2.2.14 (Redhat 6.2).
>
> Lol adica de atunci nu se mai face IP-spoofing ? :))
De atunci pe TCP se face spoofing SYN, ceea ce nu este de ajuns pentru
a face si schimb de date.
>
> > Intrebarea 2 este - Cat de "posibil" este ca cineva sa foloseasca
> > aceasta vector de atac, foarte greu de exploatat,atata timp cat
> > exista metode mult mai simple disponibile ?
> Asadar se poate ? ( vezi ca te contrazici ;-) )
>
> > "A FOST" posibil, "ODATA". "Teoretic" n-ar trebui sa traiesti in
> > trecut.
> Vezi ca e bine sa te uiti putin si in trecut ca teoretic sa nu repeti
> greselile pe care le-ai facut.
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.
>
> Ok, acum hai sa-ti explic mai pe indelete.
>
> Ipoteza:
> - posibilitatea ca eu sa pot vedea pachetele care merg spre calculatorul
> real de la server
Dupa cum am zis, nu se poate, si vei vedea de ce...
> - o regula in fw de pe calc real care sa faca DROP la toate conexiunile
> care nu sunt initiate de pe calc respectiv (mai putin catre serv web,
> ftp, alte servicii publice, etc...) (aici merge si ceva similar precum
> scoaterea cablului de retea ;-), ma rog nu e chiar un efort foarte mare
> de gandire pentru a gasi si alte posibilitati )
Daca ai acces la calculatorul real, de ce il mai spoofezi ?
Cu ce te ajuta DROP pe forward in cazul de fata ?
>
> Rezolvare:
> - pe calc care spoofeaza (sa-i spune B) exista un program care modifica
> la toate pachetele OUTGOING care ne intereseaza, adresa IP cu adresa
> calculatorului A (cel real). ; un alt thread/daemon/program care sa
> monitorizeze traficul si sa intercepteze pachetele care vin de la
> server la calc A.
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.
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. Ai auzit de TCP SYN COOKIES
patch pentru linux ? A fost introdus in kernel prin `97-`98. Acest patch
impiedica astfel de atacuri.
- 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.
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.
> -acum avand in vedere ca eu trimit pachetele cum vreau, vad raspunsul de
> la server rezultand faptul ca pot raspunde si eu la randul meu in
> concordanta cu datele primite, esti sigur ca "TEORETIC" NU SE
> POATE ? :D
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, din nici un sens, spre diferenta
de UDP care permite spoofarea datelor trimise cu usurinta.
>
>
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
