von Redaktion IT-A…
Lesezeit
1 Minute
ARP-Angriffe
Im Intranet basiert die Adressierung, anders als im Internet, nicht auf Layer 3 (IP), sondern auf Layer 2 (Ethernet). Ein Paket findet sein Ziel über die MAC-Adresse. Damit die Auflösung zwischen IPv4- und MAC-Adressen reibungslos funktioniert, kommt ARP (Address Resolution Protocol) beziehungsweise sein Pendant RARP (Reverse ARP) zum Einsatz. Darauf baut eine der häufigsten Angriffe aus dem Internet auf: ARP-Spoofing.
Der einfachste Angriff auf ARP-Ebene basiert darauf, dass der Angreifer kontinuierlich ARP-Reply-Pakete an Computer A schickt und so seine eigene MAC-Adresse für die IP-Adresse von Computer B setzt. Sendet er nun noch ein ARP-Reply an Computer B, in dem seine MAC-Adresse für die von Computer A eingetragen ist, verfügt er über eine bidirektionale Man-in-the-Middle- Verbindung. Dieser Angriff wird auch Network Hijacking genannt. Nun ist der Angreifer in der Lage, sämtlichen Traffic zwischen den beiden Computern zu lesen und zu manipulieren.
Man-in-the-Middle-Angriffe über ARP sind am einfachsten auf dem Client zu erkennen, aber auch Netzwerkgeräte wie Switche können dies, wenn der Traffic des Angriffs über sie läuft. Wie wir schon gesehen haben, wird innerhalb eines internen Netzes ein ARP-Request verschickt, um die zu einer IPv4-Adresse zugehörige MAC-Adresse zu finden. Der Angriff beruht darauf, den Reply auf einen ARP-Request zu fälschen, sodass der Client anstatt der richtigen IP-Adresse die des Angreifers in seinen ARP-Cache einträgt. Die einfachste Art, diesen Angriff zu verhindern, ist es, überhaupt kein ARP-Protokoll zu nutzen, um MAC-Adressen zu verbreiten. Stattdessen werden die MAC-Adressen in allen Geräten des Netzwerks statisch eingetragen.
Viele Netzwerkgeräte bieten heutzutage die Möglichkeit, statisch oder dynamisch MAC-Adressen zu lernen und zu prüfen. Relevante Techniken sind hierbei etwa Port Security, DHCP Snooping, Private VLANs, AID und die Implementierung des 802.1x-Standards.
Es ist nicht sehr schwer, sich vor den beschriebenen Angriffen zu schützen. Entweder setzt der Administrator auf eine Kombination von statischem ARP und Konfigurationsmanagement-Tool oder auf Features seiner Switche. Das Address Resolution Protokoll wurde 1982 standardisiert, als ein Netzwerk noch ausschließlich aus freundlich gesinnten Computern zu bestehen schien. Jeder, der ARP einsetzt, sollte sich darüber im Klaren sein, dass es sich hierbei um kein sicheres Protokoll handelt, und entsprechende Vorsichtsmaßnahmen treffen.
Lucy Pelzer und Bastian Ballmann/jp/ln
Man-in-the-Middle-Angriffe über ARP sind am einfachsten auf dem Client zu erkennen, aber auch Netzwerkgeräte wie Switche können dies, wenn der Traffic des Angriffs über sie läuft. Wie wir schon gesehen haben, wird innerhalb eines internen Netzes ein ARP-Request verschickt, um die zu einer IPv4-Adresse zugehörige MAC-Adresse zu finden. Der Angriff beruht darauf, den Reply auf einen ARP-Request zu fälschen, sodass der Client anstatt der richtigen IP-Adresse die des Angreifers in seinen ARP-Cache einträgt. Die einfachste Art, diesen Angriff zu verhindern, ist es, überhaupt kein ARP-Protokoll zu nutzen, um MAC-Adressen zu verbreiten. Stattdessen werden die MAC-Adressen in allen Geräten des Netzwerks statisch eingetragen.
Viele Netzwerkgeräte bieten heutzutage die Möglichkeit, statisch oder dynamisch MAC-Adressen zu lernen und zu prüfen. Relevante Techniken sind hierbei etwa Port Security, DHCP Snooping, Private VLANs, AID und die Implementierung des 802.1x-Standards.
Es ist nicht sehr schwer, sich vor den beschriebenen Angriffen zu schützen. Entweder setzt der Administrator auf eine Kombination von statischem ARP und Konfigurationsmanagement-Tool oder auf Features seiner Switche. Das Address Resolution Protokoll wurde 1982 standardisiert, als ein Netzwerk noch ausschließlich aus freundlich gesinnten Computern zu bestehen schien. Jeder, der ARP einsetzt, sollte sich darüber im Klaren sein, dass es sich hierbei um kein sicheres Protokoll handelt, und entsprechende Vorsichtsmaßnahmen treffen.
Lucy Pelzer und Bastian Ballmann/jp/ln
