> Fino a qui diciamo la stessa cosa. > > Ora supponiamo che l'impiegato (a) del tuo esempio è malato e non si presenta > in ufficio --> ciò implica che la porta dello switch ha rimosso per timeout > il MAC di (a), perchè il PC è spento. Supponiamo anche che in questa azienda > arrivi un consulente "vispo", vede che (a) non è presente, e pensa bene di > attaccare il suo portatile al posto del PC di (a). > Lo switch gli permette l'accesso essendo il suo il primo MAC che si presenta > su quella porta. Se consulente inizia a fare un arp poisoning, lo switch > glielo permette. > Ora supponiamo che l'amministratore dello switch abbia configurato > staticamente il MAC del PC di (a) sulla porta di competenza. Cosa succede se > il consulente cerca di connettersi al posto di (a)?. Lo switch non abilita la > porta. Ecco abbiamo prevenuto l'arp poisoning. > > Alfredo
Ma lo riesci a prevenire solo in questo strettissimo caso,ma solitamente i "disgruntled user" sono proprio gli impiegati interni...si nel caso del consulente esterno con suo pc + mac address sticky siamo d'accordo...anche se comunque il consulente "vispo" potrebbe un attimo accendere il pc di (a) e beccare il mac adddr e poi settarlo sul suo portatile.. :D ma dicevo..apparte questo stretto esempio il portsecurity da solo non ce la fa a prevenire l'arp poisoning...
_______________________________________________ http://cug.areanetworking.it [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
