ARP-Guard[5] ist ein recht neues Produkt der Firma ISL. Es arbeitet mit einer Sensor-Management-Architektur: Mehrere Sensoren beobachten an beliebiger Stelle im Netz die ARP-Informationen und leiten sie an das Managementsystem weiter, das die Meldungen analysiert und im Angriffsfall die Administratoren alarmiert. Das Programm verfügt über einen LAN- und einen SNMP-Sensor. Der LAN-Sensor arbeitet ähnlich wie Arpwatch oder ein IDS-Sensor. Er analysiert Pakete, die ihn erreichen. Der SNMP-Sensor greift dagegen per SNMP auf vorhandene Endgeräte zu und fragt deren ARP-Tabelle ab.

Intrusion-Detection-Systeme (siehe Kasten “Snort und ARP”) könnten zwar ebenfalls ARP-Attacken erkennen, sie werden meist aber nur am Übergang zu fremdem Netzen eingesetzt. Für viele Firmen rechnet sich der Einsatz im internen Netz nicht. Zudem hat der Betriebsrat meist etwas dagegen, weil der Administrator des IDS-Systems als Big Brother handeln kann: Er sieht den gesamten Netzverkehr und damit alle Zugriffe der Mitarbeiter. Der Nutzen wäre auch begrenzt, da viele IDS-Produkte das ARP-Protokoll nicht beachten. Spätestens an ARP-Poisoning-Angriffe bei dynamischen IP-Adressen scheitern sie.

Kryptographie hilft

Wenn Vertraulichkeit, Authentizität und Integrität der Daten durch kryptographische Protokolle (vor allem IPsec) garantiert werden, beschränken sich ARP-Attacken auf Denial-of-Service-Angriffe. Abhör- und Manipulationsangriffe scheitern dagegen. Es wird aber noch einige Zeit dauern, bis IPsec und andere Kryptoprotokolle umfassend zum Einsatz kommen, korrekt konfiguriert sind und von allen Anwendern auch richtig verstanden und angewendet werden.

Eine Forschergruppe schlägt vor, das herkömmliche ARP durch eine sichere Version zu ersetzen[7]. Ihre Entwicklung S-ARP nutzt Kryptographie, eine CA (Certifcation Authority) und digital signierte ARP-Nachrichten. Es ist fraglich, ob der Aufwand lohnt: IPsec bietet einen wesentlich weiter reichenden Schutz bei ähnlichem Aufwand, während S-ARP nur ARP sichert. Allein die geringere Rechenlast auf den beteiligten Systemen spricht für S-ARP.

Hersteller von Firewalls oder Routern behaupten gern, ihre Produkte könnten ARP-Spoofing-Angriffe erkennen. Das trifft aber nur eingeschränkt zu, denn diese Systeme können höchstens die Änderung eines ARP-Eintrags in ihrer ARP-Tabelle erkennen und protokollieren. Sie können nicht wissen, aus welchem Grund die Änderung erfolgt. Mögliche Ursachen sind dynamische IP-Adressen, Adresskonflikte, Netzänderungen sowie Hochverfügbarkeits- und Lastverteilungslösungen (High Availability, HA, und Load Balancing, LB). Darüber hinaus bemerkt eine Firewall meist nur ARP-Angriffe gegen sie selbst. Attacken auf den Server direkt nebenan bleiben im Verborgenen.

Der Netzverkehr lässt sich auch mit managebaren Switches einschränken. Dieses Mittel hilft nicht nur gegen ARP-Angriffe, sondern eignet sich für Verkehrsbeziehungen im Netz generell. Damit laufen allerdings einige Anwendungen nicht mehr. VLANs (virtuelle LANs), Port Protection und Zugriffskontrolllisten von Layer-3/4/5/6/7-Switches zählen zu diesen Ansätzen. Neben der Einschränkung der Verkehrsbeziehungen sind diese Techniken teils recht teuer, ein Layer-3-Switch kostet etwa das Vierfache eines programmierbaren Layer-2-Switch. Zudem steigt der Aufwand beim Administrieren, da man die Switches individuell konfigurieren muss.

Denkbar wäre es auch, ein Netz in so viele Subnetze aufzuteilen, dass sich möglichst wenige Mitarbeiter ein Subnetz teilen. Ideal wäre eine einzelne IP pro Subnetz. Die Hersteller von Routern könnten diese Lösung sicherlich empfehlen, da hohe Investitionen in entsprechende Geräte nötig wären. Der Administrationsaufwand wäre ebenfalls unangemessen hoch.

Gegenmaßnahmen im Stapel

Einige Entwickler versuchen Schutzfunktionen in den IP-Stack zu integrieren. Mit dem Antidote-Patch[8] sendet Linux vor der Änderung eines ARP-Eintrags erst einen Request an die alte MAC-Adresse. Nur wenn dieser unbeantwortet bleibt, ändert das System den Eintrag. Die Schutzwirkung ist begrenzt: Der Angreifer muss nur dafür sorgen, dass die Änderung dann erfolgt, wenn der andere Rechner nicht aktiv oder nicht erreichbar ist. Bei vielen HA- oder LB-Lösungen kann dieses Patch zudem die Kommunikation mit den – meist sehr wichtigen – Systemen stören.

Ein weiterer Ansatz, sich vor ARP-Poisoning zu schützen, ist das Unterbinden jeder Änderung vorhandener MAC-IP-Zuordnungen. Das Anticap-Patch[9] implementiert dieses Verhalten für Linux, FreeBSD und NetBSD. Solaris verfügt über eine ähnliche Option, es erlaubt Änderungen erst nach Ablauf eines Timers. Das Verhalten lässt sich frei konfigurieren. Es schützt jedoch ebenfalls nur ständig aktive Systeme – nach dem Rausaltern des Eintrags können Angreifer neue Felder fälschen.

Seit Kernel 2.4 reagiert Linux nicht mehr auf unverlangt zugesandte ARP-Replys. Leider ist auch dieser Schutz leicht zu umgehen, wie die Readme-Datei von Ettercap erklärt (siehe Kasten “ARP-Angriffssoftware”). Der Hintergrund: Einen ARP-Request muss der Kernel immer verarbeiten. Da er dabei auch eine Kombination aus IP und MAC erfährt (die des Absenders), trägt er diese vorsorglich in seinen ARP-Cache ein. Der Angreifer muss also nur einen gefälschten ARP-Request senden. Ettercap schickt eine Kombination aus ARP-Request und -Reply: Auf einen der beiden Angriffe reagiert jedes System.