![[HaBo]](/styles/default/logoklein.png){kind=small}
ARP poisoning
- Themenstarter lightf
- Beginndatum
GrafZahl
0
ARP dient dazu adressen der schicht 3 auf die schicht 2 abzubilden.
wenn du nun einen L3-Switch, a.k.a. Router, hast der als koppelelement deine netzsegmente untereinander und mit dem rest der welt verbindet, kommt es im fall von ARP poisoning darauf an wie diese kiste mit frames umgeht:
wenn beispielsweise dein L3 switch strikt nach dem schichtenmodell arbeitet, ist es mittels ARP poisoning immernoch möglich den treffic umzuleiten:
ein host ein deinem internen netz möchte daten an einen anderen host (z.B. zum Gateway) in deinem internen netz versenden. da die IP bekannt ist, aber der link nicht IP basiert ist, sondern beispielsweise Ethernet spricht, muss nun die zieladresse auf der link schicht in erfahrung gebracht werden ... steht die nicht als gültiger eintrag im lokalen ARP cache oder ist statisch konfiguriert, wird ARP durchgeführt... mittels ARP poisoning wird eine falsche adresse geliefert... die nun auf der link schicht versendeten daten haben als ziel nicht die MAC des ziel hosts, sondern die MAC die der angreifer eingebracht hat.
der L3 switch sieht das eingehende frame, und betrachtet die zieladresse. da es nicht seine eigene ist, leitet er das frame weiter zum switching des betreffenden vlans.
das ziel wird entweder im MAC cache gefunden, und das frame an den gelisteten port gegeben, oder per broadcast an alle dem vlan zugehörigen ports gesendet und erreicht wenig später den host des angreifers ...
ein nicht strikt das schichtenmodell befolgender L3 switch wird vermutlich entdecken, dass das beinhaltete protokoll IP ist, und dass die ziel adresse ausserhalb des LANs liegt ... jedoch könnte solches verhalten zu anderen problemen führen. die trennung der schichten ist wichtig um kompatiblität und interoperabilität zu gewährleisten, daher ist derartiges verhalten eines L3 Switches vermutlich auf explizite konfiguration zurück zu führen...
wenn du nun einen L3-Switch, a.k.a. Router, hast der als koppelelement deine netzsegmente untereinander und mit dem rest der welt verbindet, kommt es im fall von ARP poisoning darauf an wie diese kiste mit frames umgeht:
wenn beispielsweise dein L3 switch strikt nach dem schichtenmodell arbeitet, ist es mittels ARP poisoning immernoch möglich den treffic umzuleiten:
ein host ein deinem internen netz möchte daten an einen anderen host (z.B. zum Gateway) in deinem internen netz versenden. da die IP bekannt ist, aber der link nicht IP basiert ist, sondern beispielsweise Ethernet spricht, muss nun die zieladresse auf der link schicht in erfahrung gebracht werden ... steht die nicht als gültiger eintrag im lokalen ARP cache oder ist statisch konfiguriert, wird ARP durchgeführt... mittels ARP poisoning wird eine falsche adresse geliefert... die nun auf der link schicht versendeten daten haben als ziel nicht die MAC des ziel hosts, sondern die MAC die der angreifer eingebracht hat.
der L3 switch sieht das eingehende frame, und betrachtet die zieladresse. da es nicht seine eigene ist, leitet er das frame weiter zum switching des betreffenden vlans.
das ziel wird entweder im MAC cache gefunden, und das frame an den gelisteten port gegeben, oder per broadcast an alle dem vlan zugehörigen ports gesendet und erreicht wenig später den host des angreifers ...
ein nicht strikt das schichtenmodell befolgender L3 switch wird vermutlich entdecken, dass das beinhaltete protokoll IP ist, und dass die ziel adresse ausserhalb des LANs liegt ... jedoch könnte solches verhalten zu anderen problemen führen. die trennung der schichten ist wichtig um kompatiblität und interoperabilität zu gewährleisten, daher ist derartiges verhalten eines L3 Switches vermutlich auf explizite konfiguration zurück zu führen...
GrafZahl
0
du könntest selbst mithören was denn so an ARP paketen durch gie gegend geht, und die IP zu MAC zuordnung überwachen ... wenn sich da etwas verändert, kann es dafür verschiedene gründe geben ... einer wäre ARP spoofing ...
ein beispiel für ein programm das sowas überwacht wäre "arpwatch"
ein beispiel für ein programm das sowas überwacht wäre "arpwatch"
GrafZahl
0
die idee ist die, das netz abzuhören, was für ARP anfragen/antworten durch die gegend fliegen ... dabei lässt sich aus dem inhalt der ARP pakete ablesen welche IP zu welcher MAC gehört ... wenn du nun ein netzwerk auf diese art und weise abhörst, und es ändert sich die MAC zu einer IP, kann das mehrere gründe haben ... wenn du der admin bist, solltest du wissen ob dieser wechsel von dir beabsichtigt war, oder ob da jemand am rumpfuschen ist ...
welcher host die quelle ist, sagt dir das noch nicht ... auch die MAC dieses hosts kann gefälscht sein ... aber in der regel haben modernere managed switches die möglichkeit dir zu zeigen welche MAC sie auf welchen ports kennen...
wenn der angreifer nun einen rechner mit arpwatch oder ähnlich gestalteter ARP überwachung zu manipulieren versucht, wird auch das im log landen. es ist allerdings sinvoll für sowas rechner an monitor ports zu hängen, falls die ARP cache manipulation nicht via broadcast erfolgt. bei größeren datenmengen im netzwerk kann das aber zum problem werden
man kann daher auch einfach ein kleines programm/script schreiben was in regelmäßigen abständen auf den rechnern ausgeführt wird, nen dump der arp tabelle zieht, und irgendwo hochläd ... vorzugsweise sollte das ziel, wohin die dumps geladen werden, mittels statischem ARP eintrag aufgelößt werden ...
wenn man dann die dumps vergleicht, fällt genauso wie bei arpwatch auf, wenn sich eine zuordnung ändert ...
aber abgesehen davon ist arp spoofing nicht die einzige möglichkeit datenpakete umzuleiten ... somit auch nicht das einzige wogegen man sich schützen will ...
welcher host die quelle ist, sagt dir das noch nicht ... auch die MAC dieses hosts kann gefälscht sein ... aber in der regel haben modernere managed switches die möglichkeit dir zu zeigen welche MAC sie auf welchen ports kennen...
wenn der angreifer nun einen rechner mit arpwatch oder ähnlich gestalteter ARP überwachung zu manipulieren versucht, wird auch das im log landen. es ist allerdings sinvoll für sowas rechner an monitor ports zu hängen, falls die ARP cache manipulation nicht via broadcast erfolgt. bei größeren datenmengen im netzwerk kann das aber zum problem werden
man kann daher auch einfach ein kleines programm/script schreiben was in regelmäßigen abständen auf den rechnern ausgeführt wird, nen dump der arp tabelle zieht, und irgendwo hochläd ... vorzugsweise sollte das ziel, wohin die dumps geladen werden, mittels statischem ARP eintrag aufgelößt werden ...
wenn man dann die dumps vergleicht, fällt genauso wie bei arpwatch auf, wenn sich eine zuordnung ändert ...
aber abgesehen davon ist arp spoofing nicht die einzige möglichkeit datenpakete umzuleiten ... somit auch nicht das einzige wogegen man sich schützen will ...