moin,
es gibt aber durchaus auch sehr sinnige anwendungen für das angesprochene thema. ich zB habe in mehreren server geteamte 1000er-nic-verbünde laufen. diese bekommen vom dhcp (weil eben server) ihre feste ipaddr via macaddr-reservierung verpasst (und natürlich nochmal fest, wenn der dhcp mal nicht online ist). fällt nun eine der nic's aus, dann sorgt der entsprechende treiber dafür, dass sich die anderen nic's im team unter exakt dieser macaddr weiterhin nach aussen hin zur verfügung stellen, und somit -für den benutzer vollkommen transparent- fällt der server nicht einen ping lang aus.
also kann man, wenn man zB nur zwei karten im team hat, diese (load-balancing) unter einer macaddr erscheinen lassen, oder aber (fail-over) die karten 'teilen' sich eine macaddr, indem die co-standby-karte die macaddr in dem falle übernimmt, in welchem die masterkarte ausfällt.
ansonsten würde ich aus erfahrung heraus sagen, dass ein macaddr-spoofing eigentlich nur dann möglich ist, wenn man sein netzwerk nicht wirklich überwacht. interessant wird das ja eigentlich 'fast' nur bei servern, deren macaddr man an den ports der switch festverdrahten kann, fertig. nix iss mit pakete empfangen. des weiteren kann man die arp-mechanismen einschränken/deaktivieren, intervalle konfigurieren, subnetten, und dafür sorgen, dass mit zB noch zusätzlich sehr kurzen dhcp-intervallen dem potentiellen angreifer die sache sehr schwer gemacht wird. vernünftig konfigurierte firewalls setzen wir hier einmal voraus, und auch ein min. akzeptables router-/switch-monitoring/logging und ein funktionierendes sicherheitskonzept, welches auch umgesetzt wurde (und welches permanent kontrolliert wird).
totz alledem ist macaddr- und auch ip-spoofing eine nicht zu unterschätzende gefahr, wobei der/die provider in der tat wenig bis überhaupt gar nicht davon betroffen sind, da deren routing-/switching-technik auf anderen protokollen basiert, welche auf diese art und weise nicht angreifbar sind (dafür auf andere).
aber zB in einer dmz (weiß der geier, wie der typ dann da reingekommen ist, wir nehmen es einfach einmal an) kann so etwas in der tat katastrophale folgen haben. obwohl auch hier bei einem latent auftretenden ipaddr-konflikt normalerweise die entsprechend miteinenader kommunizierenden server sofort die schotten dicht machen sollten (beide!). man-in-the-middle-attacks sind aber auch zB durch extrem kurze ttl's und verschlüsselung zwischen zwei servern (vlan's, vpn, tunnel allg.) zu ver-/behindern.
naja, usw.usf.
man kann sich zu dem thema zu tode schreiben, und hat doch nur den bodensatz aufgeschüttelt.
mfG olly
