Daniele Angellotti ha scritto:1 A quanto ho capito se l'host che si è spostato non manda nessun pacchetto, e l'ageing time non è scaduto, i pacchetti del ping continueranno ad essere inviati sul dominio di collisione sbagliato e quindi continueranno ad essere persi, fino a che non si verifica una delle due situazioni (pacchetto da parte dell'host che si è spostato o scadenza dell'ageing time).
In riferimento alla esercitazione di stamattina, avrei qualche domanda.Relativamente alla prima domanda penso che il ping se ne accorgerebbe; se l'host si è spostato, lo switch inoltra il ping, non riceve risposta (l'host si è spostato), allora parte una arp request (dallo switch?) e l'host che si è spostato risponde: a quel punto lo switch aggiorna la tabella e comincia a instradare correttamente i pacchetti ICMP (e conseguentemente tutto il resto).
1. Relativamente al terzo caso presentato sulle slide relative agli
spostamenti di host in vari domini di collisione, si è detto (se
non erro) che se un host si sposta in un altro dominio di
collisione e l'ageing time non è scaduto, il bridge erroneamente
continua a inoltrare i pacchetti sul link sbagliato perchè è
ancora convinto che l'host si trovi in quel dominio di
collisione. Supponiamo che l'host che si è spostato non emetta
inizialmente alcun pacchetto (e quindi non aggiorni la tabella
dello switch) e supponiamo che l'ageing time sia impostato ad un
valore alto, diciamo 100 secondi. Possibile che il bridge
continui per molti secondi a inoltrare pacchetti altrove (perdendoli tra la'ltro perchè nessun host vedrebbe il proprio
indirizzo)? Possibile che nè il bridge nè l'host si accorgano
che, ad esempio un comando di ping, non restituirebbe messaggi
ICMP di risposta?
2. In riferimento alla tecnica ARP poisoning si è detto (se non
erro) che si interviene inviando una ARP reply contraffatta. Ma
anche l'utente reale manderà una ARP reply visto che la ARP
request è broadcast. Si è detto che la prima risposta che arriva
viene memorizzata nella tabella dello switch. Innanzitutto, non
dovrebbe essere il contrario? Ovvero l'ultima che arriva
aggiorna definitvamente la tabella dello switch e quindi essa
stessa risulta memorizzata? Inoltre, non è possibile
implementare un algoritmo per cui se un bridge riceve
istantaneamente più di un ARP reply con lo stessa coppia IP/MAC
capisca che possa esserci un intruso e scarti le ARP reply non
potendo sapere con certezza quale sia quella corretta?
3. Se uno switch utilizza completamente entry statiche, è possibile
forzarlo per applicare comunque l'ARP poisoning?
Grazie
D.A.
Per la seconda domanda, se l'utente vero manda una reply (che viaggia unicast) si aggiorna solo la tabella del richiedente (chi ha fatto partire la ARP request corrispondente) e il richiedente non sarà mai la vittima (dato che la sua tabella ha già una entry per l'"utente reale", cioè la entry con cui l'attaccante ha avvelenato la tabella della vittima).
Cmq vediamo che dicono gli esercitatori!
fabrizio
Archivio con motore MhonArc 2.6.16.