> > > --- Gio 10/9/09, Gianremo Smisek <[email protected]> ha scritto: >> Lo switch vede un indirizzo L2 aggiuntivo provenire da >> quella porta >> per cui entra in violation. > > Prima di analizzare se l'arp poisoning è bloccato dal portsecurity > analizziamo il seguente scenario (tratto da wikipedia): > > > * Attacker: IP = 192.168.1.2, MAC = 00:00:00:ZZ:ZZ:ZZ > * John: IP = 192.168.1.13, MAC = 00:00:00:JJ:JJ:JJ > * Linus: IP = 192.168.1.88, MAC = 00:00:00:LL:LL:LL > > Le ARP cache di ciascun host prima dell'attacco saranno: > > * Per l'attacker: > o 192.168.1.2, MAC = 00:00:00:ZZ:ZZ:ZZ > o 192.168.1.13, MAC = 00:00:00:JJ:JJ:JJ > o 192.168.1.88, MAC = 00:00:00:LL:LL:LL > * Per John: > o 192.168.1.2, MAC = 00:00:00:ZZ:ZZ:ZZ > o 192.168.1.13, MAC = 00:00:00:JJ:JJ:JJ > o 192.168.1.88, MAC = 00:00:00:LL:LL:LL > * Per Linus: > o 192.168.1.2, MAC = 00:00:00:ZZ:ZZ:ZZ > o 192.168.1.13, MAC = 00:00:00:JJ:JJ:JJ > o 192.168.1.88, MAC = 00:00:00:LL:LL:LL > > Per realizzare l'ARP poisoning l'attacker invierà delle ARP reply > appositamente fatte: a John invierà una reply che ha come IP quello di Linus > (192.168.1.88) ma come MAC il proprio (00:00:00:ZZ:ZZ:ZZ), a Linus invierà > una reply con IP quello di John (192.168.1.13) e con MAC, anche questa volta, > il proprio (00:00:00:ZZ:ZZ:ZZ). Per protrarre l'attacco è necessario inviare > delle ARP reply ogni 10 secondi poiché spesso i sistemi operativi cancellano > sistematicamente le voci dell'ARP cache. > > Quindi dopo l'attacco le ARP cache di ciascun host saranno: > > * Per l'attacker: > o 192.168.1.2, MAC = 00:00:00:ZZ:ZZ:ZZ > o 192.168.1.13, MAC = 00:00:00:JJ:JJ:JJ > o 192.168.1.88, MAC = 00:00:00:LL:LL:LL > * Per John: > o 192.168.1.2, MAC = 00:00:00:ZZ:ZZ:ZZ > o 192.168.1.13, MAC = 00:00:00:JJ:JJ:JJ > o 192.168.1.88, MAC = 00:00:00:ZZ:ZZ:ZZ > * Per Linus: > o 192.168.1.2, MAC = 00:00:00:ZZ:ZZ:ZZ > o 192.168.1.13, MAC = 00:00:00:ZZ:ZZ:ZZ > o 192.168.1.88, MAC = 00:00:00:LL:LL:LL > > Le due vittime John e Linus crederanno di comunicare tra di loro, ma in > realtà comunicheranno con l'attacker il quale inoltrerà il traffico > proveniente da John verso Linus e viceversa il traffico proveniente da Linus > verso John, realizzando così un MITM. > > Come si può notare l'attacker invia solo frame contenenti il come MAC > sorgente il suo MAC reale. Lo switch, anche con portsecurity attivo a max 1, > se l'attacante è il primo a presentarsi su quella porta ed è abilitato a > trasmettere(*), permette l'attacco. > > Per tornare in IT (in topic), domandiamoci perchè è corretto dire che > portsecurity aiuta a prevenire l'arp poisoning, così come era stato domandato > all'inizio? > Perchè port security può essere configurato con il parametro "sticky", ciò > significa che non è lo switch che impara il MAC da accettare (solitamente il > primo che si presenta), ma è l'amministratore che indica il MAC che può > accedere alla porta. Ed ecco che l'attacco arp poisoning è impedito. > > Spero di essere stato abbastanza chiaro. Ma se non lo fossi sono a > disposizione per ulteriori chiarimenti. > Alfredo
Secondo me non ci siamo capiti. Diciamo che nella compagnia XY ci siano degli impiegati a,b,c un giorno,l'impiegato c si sveglia troppo allegro e decide di fare qualche scherzetto ai suoi colleghi,avvia ettercap e comincia a poisonare a & b conducendo un MITM. Essendoci dunque l'amministratore che "incolla" i mac address di a,b e c sullo switch che cosa cambia? un bel nulla. prima dell'attacco sullo switch il mac address di c stickato sullo switch era cc dopo l'attacco rimane sempre quello. e dunque ? Il PortSecurity non aiuta in alcun modo a prevenire l'arp poisoning.
_______________________________________________ http://cug.areanetworking.it [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
