Abbildung 7: Ettercap wartet auf Verbindungen zwischen 192.168.1.120 und 192.168.1.124 (Source und Destination, links oben). Unverschlüsselte Protokolle wie Telnet und FTP kann es problemlos abhören. Bei SSHv1 greift es als Man in the Middle aktiv ein, um die Verbindung zu entschlüsseln.
Abbildung 8: Während des Ettercap-Angriffs (Abbildung 7) erhält der Client (hier »odo«) einen falschen Host-Key vom Server (Name »bashir«, IP-Adresse 192.168.1.124). Der Key stammt vom Angreifer und nicht vom gewünschten Server (»bashir«). Wer diese Warnung ignoriert, ist abhörbar.
Angriffe erkennen
Für den Netzbetreiber bedeutet dies, dass beinahe jede interne Kommunikation angreifbar ist. Es gibt sogar Einsteiger-taugliche Software, die Passwörter in über 50 Protokollen analysiert. Da die Angriffe auf ARP-Ebene arbeiten, aber meist nur IP-Zugriffe geloggt werden, darf sich der Angreifer heutzutage sogar recht sicher sein, dass niemand seine Taten aufdeckt. Damit drängt sich die Frage auf, wie ein Admin verhindern kann, dass interne Mitarbeiter ARP-Angriffe durchführen.
Ein Ansatz ist, das Herunterladen und Ausführen fremder Software zu unterbinden. Das ist aber kaum durchzusetzen: Die Internet-Anbindung wäre stark einzuschränken, schließlich ist es mit HTTP, HTTPS, FTP und E-Mail leicht, Software in das interne Netz zu holen. Auch mobile Datenträger wie Disketten oder CDs müssten die Admins verbieten, ebenso mobile Geräten wie Notebooks oder PDAs. Wegen der gravierenden Einschränkungen eignet sich diese Lösung nur in Ausnahmefällen.
Wer im internen Netz nur Linux einsetzt und seinen Benutzern keine Root-Rechte gibt, vermeidet die meisten Angriffe von vornherein, denn das Senden gefälschter ARP-Paket erfordert Root-Rechte. Allerdings sollte sich kein Admin zu sicher sein, dass nicht doch ein Mitarbeiter einen Rechner von CD bootet oder sein privates Notebook anschließt.
Statische Einträge in den ARP-Tabellen
Auch statische ARP-Einträge (per »arp -s« gesetzt) können ARP-Angriffe scheitern lassen. Wegen des hohen Aufwands wird kaum jemand mehr als die wichtigsten Systeme (Router und Server) manuell eintragen. Bei Microsoft-Betriebssystemen können Angreifer selbst diese Einträge durch ARP-Poisoning ändern – es gibt letztlich keinen Schutz.
Der Ansatz ist aber nur für kleine Netze sinnvoll, da die Anzahl der ARP-Einträge quadratisch mit der Zahl der Netzwerkkarten steigt: Für 100 Systeme wären 9900 Einträge erforderlich (je 99 pro System). Der Administrationsaufwand ist besonders beim Suchen und Beheben von Netzwerkfehlern enorm.
Wachsames Auge
Mit Arpwatch[4] gibt es seit vielen Jahren ein Open-Source-Tool für Unix-Plattformen, das auffällige ARP-Aktivitäten aufspürt. Jedem ARP-Paket, das den Arpwatch-Rechner erreicht, entnimmt es Adressinformationen und speichert sie in einer Datenbank. Stimmen die Daten nicht mit früher gesammelten Adresspaarungen überein, warnt das Tool den Admin per E-Mail. Arpwatch soll Geräte auch per SNMP abfragen können. Das hat im Test eines der Autoren dieses Artikels aber nicht funktioniert.
Viele Netze verwenden heute dynamische IP-Adressen, die ein interner Server per DHCP (Dynamic Host Configuration Protocol) verteilt. In diesem Umfeld liefert Arpwatch häufig Fehlalarme (false positive), da es jede geänderte IP-MAC-Zuordnung meldet.
