LAN-Karten bedienen sich einer hardwaremässig definierten MAC-Adresse, die für die Aussendung und den Empfang von Datagrammen über das Netzwerk unerlässlich ist. Sie können nur auf Datagramme antworten, die im Empfänger-Feld eine Rundsende-Adresse, eine bekannte Verteilsende-Adresse oder eine auf die betreffende LAN-Karte hinweisende Individual-Adresse aufweisen. Das Internet Protocol verwendet IP-Adressen, die während der Installation des Netzwerks bzw. dem Aufsetzen des an das LAN anzubindende Systems vom Administrator definiert wird. Eine IP-Adresse ist dem Protokollstapel der Vermittlungsschicht zugeordnet und von der individuellen MAC-Adresse unabhängig. Jede Kommunikation mittels TCP/IP wird durch die IP-Adresse eingeleitet, wodurch für den Aufbau des Dialogs die MAC-Adresse als sekundär zurückgestuft wird. End-zu-End-Kommunikationen bedienen sich also der IP-Adresse, wohingegen bei den dazwischen liegenden Knotenpunkten (Hops) die MAC-Adresse genutzt wird.

In den ersten TCP/IP-fähigen Rechnern wurde eine manuell erstellte Tabelle verwendet, die die Zuordnung zwischen MAC- und IP-Adresse indirekt automatisieren sollte. In den meisten rundsendefähigen Netzen werden davon losgelöst zusätzlich oder ersetzend Routing-Informationen komplett automatisch mittels dem Adress Resolution Protocol ausgetauscht, welches in RFC 826 (An Ethernet Address Resolution Protocol) definiert wird. Jeder Knoten verwaltet dabei dynamisch den sogenannten ARP-Cache mit den relationalen IP-/MAC-Einträgen. Wenn das Internet Protokoll die Anforderung erhält ein Datagramm an eine andere IP-Adresse zu senden, sucht es zuerst im ARP-Cache nach der korrespondierenden MAC-Adresse, die von der Datensicherungsschicht bei der Übertragung des Pakets Verwendung finden soll. Falls kein Eintrag vorhanden ist, wird vom Initiator mit der Hilfe von ARP die MAC-Adresse der fraglichen IP-Adresse zu ermitteln versucht. In der Hoffnung diese Frage wenigstens temporär aus der Welt zu schaffen, sendet ARP ein Datagramm inklusive der zu erfragenden IP-Adresse eine sogenannte ARP-Anforderung an alle LAN-Karten mittels der bekannten MAC-Broadcast-Adresse (0xFFFF_FFFF_FFFF). ARP setzt in dieser verhältnismässig globalen Anforderung seinen eigenen Ethernet-Typ 0x08086 ein, damit der Schrei von allen vermeindlich betroffenen Knotenpunkten wahrgenommen wird. Dieses Rundschreiben wird von allen aktiven Maschinen im Netzwerk erkannt und insofern verarbeitet, dass wenn die eigene IP-Adresse in der ARP-Anforderung erkannt wird, das betroffene System die mindestens lokal statisch vermerkte MAC-Adresse retourniert. Diese eingehende Antwort wird im lokalen ARP-Cache vermerkt und steht, solange der Cache nicht aufgrund potentieller Überfüllung überschrieben wird, für eine weitere und vor allem schnellere bzw. effizientere Nutzung bereit. Falls innerhalb eines definierten Timeouts im Sekundenbereich keine Antwort auf die Broadcast-Anfrage eingeht, wird die Anforderung erneut gestellt. Damit jedoch nicht stets das gesamte Netz belästig werden muss, wird aus Gründen der Effizienz eine Kopie der ARP-Anfrage beim Knoten, der auf die ARP-Nachricht antwortet, die Zuordnung von IP- und MAC-Adresse, der geantwortet wurde, zwischengespeichert. Bei der nachfolgenden Anforderung ist es daher auch nicht mehr nötig den ARP-Dialog in umgekehrter Richtung walten zu lassen, da die relevanten Daten beim Zielsystem bereits bekannt sind.

ARP-Datagramme werden von Routern nicht weitergeleitet, da sie in der IP-Schicht operieren und auf MAC-Broadcasts grundsätzlich nicht reagieren können und dürfen. Router stellen daher verwertbare Puffer zwischen einzelnen Rundsende-Subnetzen dar. Mit ihrer Hilfe kann überflüssiger Traffic im gesamten Netzwerk eingedämmt und auf effektiv betroffene Subnetze minimiert werden.

Der ARP-Cache

Der Cache für die ARP-Informationen wird meist solange gehalten, bis die Geräteeinheit zurückgesetzt oder ausgeschalten wird. In einigen TCP/IP-Implementierungen wird für die Einträge ein zeitliches Limit gesetzt: Falls ein Eintrag innerhalt dieses Zeitraums, meist 15 Minuten, nicht verwendet wird, ist das Löschen jener die unweigerliche Folge. Andere Systeme wiederum arbeiten mit zeitgesteuerten Aktualisierungsfunktionen: Alle 15 Minuten wird eine ARP-Anforderung abgesetzt, um sicherzustellen, dass die vorhandenen Einträge noch immer den Eigenschaften der aktuellen Umgebung entsprechen. Das sich MAC-Adressen nur zu ändern pflegen, wenn ein Element ausgetauscht oder verlagert wird, ist diese Information von relativ begrenztem Wert. Manche Produkte erlauben eine manipulative Modifikation der mit dem ARP-Cache in Zusammenhang stehenden Informationen wie Einträge oder Time-Limits. Dieses Feature kann bei der Fehlersuche und Blitzaktionen Gold wert sein.

Der Befehl arp gibt für berichtigte Benutzer; standartmässig nur root bei UNIX- und seinen Derivaten, den Inhalt der ARP-Tabelle aus. Um sich der Einsicht der gesamten ARP-Tabelle zu bemächtigen, bedient man sich erfolgsversprechend der Option -a. Einzelne Einträge werden in Kombination mit dem jeweiligen Hostnamen angezeigt. Wollen Sie sich zum Beispiel den Eintrag für den Rechner zion in der ARP-Tabelle von prometheus ansehen, müssen Sie folgendes eingeben:

root@prometheus:~ > arp zion
zion (192.168.0.10) at 8:0:20:5:21:43

Die Ausgabe aller Einträge der ARP-Tabelle mit der Option -a zeigt unter Linux folgendes Bild:

root@prometheus:~ > arp -a
Net to Media Table
Device    IP Adress           Mask       Flags    Phys Addr
------ ----------------- --------------- ----- ---------------
eth0   gateway.ruef.net  255.255.255.255 SP    08:00:13:00:0e:c9
eth0   rieekan.ruef.net  255.255.255.255       08:01:12:ee:32:00
eth0   zion.ruef.net     255.255.255.255       08:00:20:05:21:43

Anhand dieser Tabelle bringen wir uns in eine priveligierte Situation, da wir wissen, dass von prometheus an zion adressierte Datagramme in Ethernet-Frames verpackt und an die Ethernet-Adresse 08:00:20:05:21:43 weitergereicht werden. Ausserdem erkennen wir anhand des gesetzten S-Flags, dass der erste Eintrag von gateway.ruef.net statisch ist: Er wird durch die lokale Konfiguration bezogen. Das zusätzliche P-Flag des gleichen Eintrags steht für "Published". Dies bedeutet, dass der Eintrag veröffentlich wird. Empfängt ARP also eine Anfrage für die IP-Adresse von gateway, dann antwortet prometheus in seiner Funktion als Proxy ARP-Server mit der jeweils zugeordneten MAC-Adresse; in diesem Fall 08:00:13:00:0e:c9). Ein gesetztes M-Flag deutet auf Mapping hin und wird nur für Multicast-Einträge verwendet. Bei einem Broadcast-Medium (z.B. Ethernet) wird die Broadcastadresse für die Auslieferung an eine Multicast-Gruppe genutzt.

Die Einsicht der ARP-Tabelle unter Windows ist da ein bisschen weniger informationsreich, erfüllt jedoch trotzdem meist seinen Zweck und ist für den Laien leichter verständlich:

C:\WINDOWS>arp -a

Schnittstelle: 62.2.64.137 on Interface 0x1000002
  Internet-Adresse      Physische Adresse      Typ
  62.2.65.231           00-00-00-00-00-00     ungültig
  62.2.65.254           00-b0-8e-c8-cc-70     dynamisch

Automatisch generierte dynamische ARP-Tabellen bedürfen in der Regel keiner Pflege, weil sie ohne Probleme durch das ARP-Protokoll erzeugt werden. ARP arbeitet sehr stabil und verrichtet brav seinen Dienst. Trotzdem kann nachträglich manuell in die ARP-Tabelle eingegriffen werden, wie die jeweiligen Optionen beweisen:

-d hostname entfernt einen Eintrag aus der ARP-Tabelle.
-s hostname ether-adresse fügt einen Eintrag in die Tabelle ein.

Das ARP-Format

,---------------------------------.
| Rahmenkopf | ARP/RARP-Nachricht |
`------------+--------------------|
  __________/                     |
 /                                |
/---------------------------------|
|   Hardware    |    Protokoll    |
|---------------+-----------------|
| HLEN  | PLEN  |    Operation    |
|---------------------------------|
|     Sender HA (0-3 Oktette)     |
|---------------------------------|
|   Sender HA   |    Sender IA    |
| (Oktette 4-5) |  (Oktette 0-1)  |
|---------------+-----------------|
|   Sender IA   |  Empfänger HA   |
| (Oktette 2-3) |  (Oktette 0-1)  |
|---------------------------------|
|    Empfänger HA (Oktette 2-5)   |
|---------------------------------|
|    Empfänger IA (Oktette 0-3)   |
`---------------------------------'

Das Struktur eines ARP-Datagramms wurde als einfaches Standartformat für den Einsatz beliebiger Netzwerktypen entworfen. Als einzige Beschränkung ist das netzwerkseitige Unterstützen von Broadcast-Nachrichten, wie dies zum Beispiel bei Ethernet der Fall ist, vorauszusetzen.

ARP operiert direkt in der Datensicherungsschicht und wird daher in dessen Rahmen codiert. Damit die Datensicherungsschicht die ARP-Rahmen von Rahmen anderer Herkunft unterscheiden kann, wurde für das Adress Resolution Protocol ein eigener Wert für das Ethernet-Fypenfeld (0x8086) bestimmt. ARP-Datagramme erhalten folgende Felder:

• Hardware: Dieses Feld definiert den Typus Netzwerkhardware, die dem Initator zuteil wird. Zulässige Typen sind:
1. Ethernet (10 Mbps)
2. Experimentelles Ethernet (3 Mbps)
3. Amateurfunk AX.25
4. Proteon ProNET Token-Ring
5. Chaos
6. IEEE.802
7. ARCNET
8. Hyperchannel
9. Lanstar
10. Autonet short adress
11. LocalTalk
12. LocalNet (IBM PCNet oder Sytec Inc. LocalNet)
• Protokoll: In diesem Feld wird angegeben, von welchem Protokoll die Operation angefordert wurde. Hier werden dieselben Werte wie im Ethernet-Typenfeld eines Ethernet-Rahmens verwendet. Dem Internet Protocol wird zum Beispiel der Wert 0x0800 zugeschrieben.
• vHLEN: Mit diesem Feld wird die Länge der Hardware-Adresse in Oktetten angegeben. Normalerweise hat eine IEEE-LAN-MAC-Adresse den HLEN-Wert 6.
• PLEN: Dieses Feld dokumentiert in Oktetten die Länge der Vermittlungsschicht-Adresse. IPv4 hat im Normalfall den PLEN-Wert 4.
• Operation: Diesem Feld stehen ARP zwei Optionen zur Auswahl; zudem fallen zwei zusätzliche für RARP an:
1. Fällt die Wahl auf 1, wird eine ARP-Anforderung getätigt.
2. Beim Nutzen des Werts 2 handelt es sich um eine ARP-Antwort.
3. RARP-Anforderungen werden mit dem Wert 3 gekennzeichnet.
4. Antworten mittels RARP bedienen sich des Werts 4.
• Adressen: In diesem Feld wird die Hardware- und IP-Adresse des Absenders, und das gleichnamige Paar des Empfängers vermerkt.

Bedienen wir uns nun zum Verständnis der Arbeitsweise von ARP unserer Phantasie, durch welche wir folgendes Szenario vor dem geistigen Auge projezieren lassen: Der Knoten mit der IP-Adresse 192.168.0.4 und der MAC-Adresse 0x0050baaf3da1 hat von seiner IP-Schicht die Aufforderung zum Herausfinden der MAC-Adresse des Knotens mit der IP-Adresse 192.168.0.12 bekommen.

192.168.0.4 sendet nun in der ersten aktiven Phase eine ARP-Anforderung an alle Knoten im Netz (Broadcast durch 192.168.0.255). 192.168.0.12 erkennt seine IP-Adresse in der Anforderung und sendet eine ARP-Antwort, die er an die MAC-Adresse der eingegangenen Anforderung adressiert. Die ARP-Reply wird weitergeleitet und unverzüglich von nicht betroffenen Systemen verworfen, da es sich um einen Unicast-Rahmen handelt, der eindeutig an eine spezifische Adresse gerichtet ist (in diesem Falle 192.168.0.4).

Die ARP-Anforderungen aussendenden Knoten gehen bei solchen Aktionen davon aus, dass die eingehende Antwort korrekt ist. Normalerweise sind keine Kontrollmechanismen vorhanden, die eine MAC-Adresse im Namen mehrerer IP-Adressen kompetent verifizieren kann. Angreifer können sich diese Eigenheit von ARP zunutze machen: Nähere Informationen dazu finden sich im Kapitel zu ARP-Spoofing.

ARP und Fehlermanagement

ARP neigt dazu eine heimtückische Fehlerquelle darzustellen. In einem gut verwalteten Netzwerk dürften keine Duplikate von IP-Adressen bestehen; sie müssen eindeutig sein. Was passiert nun, wenn doch zweimal die gleiche IP-Adresse im selben Netz genutzt wird? Es ist aus technischer Sicht sehr hilfreich und dementsprechend interessant anzusehen, wie ARP in einer solchen Extremsituation reagiert. In unserem imaginären Beispiel bedienen wir uns dem Szenario, dass in einem brückenverbundenen LAN dieselbe IP-Adresse (192.168.0.19) von zwei Knoten verwendet wird. Wir bezeichnen diese beiden Streithähne nun nachfolgend als Knoten A und Knoten B.

Als erstes stellt der Knoten A eine Verbindung mit dem Host her um im gleichen Durchgang eine ARP-Anforderung zum Austausch der MAC-Adressen anzubringen. Beide Rechner initialisieren ihren ARP-Cache und die Session läuft regulär ohne Komplikationen nach Plan ab... Bis der Knoten B eine Verbindung zum selben Host herstellt. Was dann genau passiert, ist von der jeweiligen Implementierung abhängig. Da Knoten B die gleiche IP-Adresse wie Knoten A hat und jene IP-Adresse schon im ARP-Cache des involvierten dritten Rechners vermerkt ist, ersetzt der Host die MAC-Adresse von Knoten A durch die MAC-Adresse des Knotens B.

Die ursprünglich für den Knoten A bestimmten Daten treffen nun beim Knoten B ein und werden dort aufgrund fehlender Verwertbarkeit optional mit Fehlermeldung verworfen. Der Benutzer am Knoten A wird sich über den unerwünschten Verbindungssabbau ärgern, den sein System aufgrund Erreichens des Timeouts wegen fehlender ankommender Daten auslöst. Die sinnlose Kommunikation zum Knoten B funktioniert so lange gut, bis der Benutzer am Knoten A wiederum den ARP-Cache mittels erneutem Verbindungsaufbau überschreibt.

Ein anderes Horror-Szenario gefällig? Wird einem Client-Rechner aus Versehen die gleiche IP-Adresse wie dem zur Verbindung aufgeforderten Host-System zugeteilt, können diverse Benutzer für kurze Zeit nicht auf die Dienste des Hosts zugreifen. Die verschiedenen Komponente und Eigenheiten des spezifischen Netzwerks lassen dieses Problem polymorph erscheinen, denn die Architektur des Netzes, der Einsatz von Routern, Hubs oder Bridges und die verwendete Hard- und Software haben einen entscheidenden Einfluss auf die Reaktionszeiten von ARP und dadurch auf das ganze Szenario.

Wir wenden uns jetzt nochmals einer Situation zu, die wiederum die drei Beteiligten aus Szenario 1 (Knoten A, Knoten B und der Host-Rechner) voraussetzt: In dieser imaginären Situation haben der Knoten B und der Host-Rechner die gleiche IP-Adresse. Versucht nun Knoten A eine Verbindung zum Host herzustellen, welche eine ARP-Anforderung zur Folge hat, erhält er durch das Adress Resolution Protokoll die IP-Adresse von Knoten B, da sowohl der Host als auch Knoten B antworten. Knoten A kann die Verbindung kaum erfolgreich herstellen, da Knoten B kaum in der Lage ist, mit der korrekten Dienst-Software aufzutrumpfen. Beim zweiten Versuch erhält Knoten A vielleicht die korrekte Antwort des Hosts, kann jedoch noch immer keine Verbindung herstellen. Handelt es sich beim Knoten B um einen PC, wird dieser sehr wahrscheinlich bei längerem Nichtgebrauch ausgeschaltet. In diesem Fall taucht das Problem nur gelegentlich, zum Beispiel während den Arbeitszeiten des Benutzers am Knoten B, auf. Dies kann für genervte Benutzer zwischenzeitlich zum Vorteil werden, behindert jedoch die Fehlersuche des Netzwerkadministrators erheblich.

Das vierte und letzte Szenario beschreibt sich einfacherweise wie folgt: Zwei Host-Rechner bedienen sich der identischen IP-Adresse. In diesem Fall werden die Client-Maschinen gelegentlich eine Verbindung zum falschen Host herstellen, was ein korrekter Ablauf der Kommunikation unterbindet.  Dieser Machtkampf ist selten anzutreffen, da es zu den Hauptaufgaben eines kompetenten Administrators zählt, bei jeder Phase des Netzwerkdesign auf individuelle IP-Adressen zu achten.

Auf einigen Systemen können Benutzer die IP-Adresse des Interfaces selber bestimmen und dadurch die besagten Probleme heraufbeschwören. Böswillige Benutzer können so Denial of Service-Attacken gegen Rechner fahren. In der Theorie wäre so auch das Übernehmen von Verbindungen (z.B.: TCP-Hijacking bzw. IP-Spoofing inkl. DoS-Attacke) möglich. Dies ist aber aufgrund der schwer zu erratenden Sequenznummern trivial.

ARP nach einer Leistungsstörung

ARP kann Probleme verursachen, wenn zuverlässige Dienste einer Leistungsstörung unterworfen werden. Die meisten TCP/IP-Implementierungen versuchen mit einem Wiederholen des Versands den Fehler zu korrigieren bzw. umgehen. Wenn jedoch alle Übertragungsversuche zum Scheitern verurteilt wurden, beginnt der TCP/IP-Stack mit einem erneuten Broadcast der ARP-Anforderung an alle Knoten im Netz, um zu kommunizieren, ob der Ausfall auf unterster Schicht behoben werden kann. Dieses Broadcasting wird erst beim Ausfall von mehreren mehr oder minder wichtigen Knoten für die Performance des Netzes zum Verhängnis. Werden zwei (Teil-)Netze über eine Brücke miteinander verbunden, kann ein Ausfall jener eine potentielle Gefahr darstellen, da relativ viele Verbindungen dadurch gestört werden können. Eine solch grosse Menge von Rundsende-Nachrichten, wir sprechen von zwischen 40 und 80 Broadcasts pro Sekunde, wirkt sich stark negativ auf die Performance der involvierten Netzwerke aus. Das Problem lässt sich leicht vorbeugend umgehen, indem ersetzenderweise Router anstatt Bridges zum Einsatz kommen.

ARP-Ablaufprotokolle

Ich möchte hier nun gerne zum weiteren Verständnis der Funktionsweise des Adress Resolution Protocols einige ARP-Ablaufprotokolle publizieren, die dem normalen alltäglichen Netzwerk-Verkehr entnommen wurden. In den Beispielen sid die Ethernet-Rahmen in hexadezimaler Schreibweise ohne Präambel und CRC-Prüfsumme dokumentiert. Unter dem Rahmen werden die hexadezimalen Werte der Rahmenfelder in einer Tabelle dargestellt.

Im ersten Beispiel versucht der Knoten mit der IP-Adresse 30.0.0.1 zum ersten Mal eine Verbindung zur IP-Adresse 30.0.0.99 herzustellen. Rahmen 1 enthält die ARP-Broadcast-Message vom Initator, in der für die Empfänger-MAC-Adresse Nullen eingesetzt wurden. Im Rahmen 2 wird die ARP-Antwort gezeigt, in der alle Felder mit Daten belegt sind.

Rahmen 1
 

FFFF	FFFF	FFFF	0260	8C0A	C49D	0806	0001	.......`..D.....
0800	0604	0001	0260	08CA	C49D	1E00	0001	.......`..D.....
0000	0000	0000	1E00	0063	0000	0000	0000	.........c......
0000	0000	0000	0000	0000	0000			............

Datensicherung: Empfänger-MAC: FFFFFFFFFFFF Absender-MAC: 02608C 0AC49D Typ (Länge): 0806

ARP: Hardware: 0001 Protokoll: 0800 HLEN: 06 PLEN: 04 Operation: 01 (ARP-Antwort) Absender-IP: 30.0.0.1 Absender-MAC: 02608C 0AC49D Empfänger-IP: 30.0.0.99 Empfänger-MAC: 000000000000

Rahmen 2
 

0260	8C0A	C49D	AA00	0400	0104	0806	0001	.`..D.*.........
0800	0604	0002	AA00	0400	0104	1E00	0063	......*........c
0260	8C0A	C49D	1E00	0001	0000	0000	0000	.`..D...........
0000	0000	0000	0000	0000	0000			............

Datensicherung: Empfänger-MAC: FFFFFFFFFFFF Absender-MAC: 02608C 0AC49D Typ (Länge): 0806

ARP: Hardware: 0001 Protokoll: 0800 HLEN: 06 PLEN: 04 Operation: 01 (ARP-Antwort) Absender-IP: 30.0.0.1 Absender-MAC: 02608C 0AC49D Empfänger-IP: 30.0.0.99 Empfänger-MAC: 000000000000

RARP (Reverse Address Resolution Protocol)

Das in den RFCs 951 (Bootstrap Porotocol (BOOTP)) und 1532 (Clarifications and Extensions for the Bootstrap Protocol) erwähnte Reverse Addresse Resolution Protocol wurde für Geräteeinheiten konzipiert, die ihre IP-Adresse nicht selbst speichern können. RARP findet vorzugsweise Verwendung in Netzwerkumgebungen mit plattenlosen Clients. Es stellt im Grunde nur die Umkehrung von ARP dar, wie das aufgelöste Akronym schon vermuten lässt: Während ARP anhand der IP-Adresse eine MAC-Adresse ermittelt, ermittelt RARP anhand der MAC-Adresse die IP-Adresse. Knoten, die eine RARP-Anforderung stellen, geben die MAC-Adresse in der Anforderung weiter. Wie ARP operiert RARP in der Datensicherungsschicht. RARP wurde eine eigene Ethernet-Typennummer zugeordnet (0x8035), damit es von anderen Protokollen mit Sicherheit unterschieden werden kann.

Als RARP-Server fungierende Knoten suchen in ihrer RARP-Tabelle nach der der MAC-Adresse entsprechenden, zur Weitergabe vorgesehenen IP-Adresse. Dieses System setzt mindestens einen als RARP-Server fungierenden Host voraus, der über eine komplette Tabelle aller MAC-/IP-Adressen verfügt. Das Format der Datagramme von RARP ist identisch mit denen von ARP, nur werden im Operations-Feld die Werte 3 für Anforderung und 4 für Antwort verwendet. Wenn ein Rechner eine RARP-Anforderung aussendet, kennt er nur die MAC-Adresse des Ziels und kann daher nur jene im Datagramm vermerken. Im Antwort-Datagramm sind normalerweise alle Felder mit den entsprechenden Werten belegt. Zudem wird in ihnen meist auch die IP- und MAC-Adresse des RARP-Servers angegeben.

Obwohl RARP seinen Kompetenzbereich hervorragend abzudecken vermag, findet es in der Realität wenig Beachtung. BOOTP (Bootstrap Protocol) hat konnte RARP auf die hinteren Plätze verweisen, da es mit Brücken und Routern kompatibel ist und mehr Informationen übermitteln kann. BOOTP wiederum fand in DHCP (Dynamic Host Configuration Protocol) einen hochkompetenten Gegner...

ARP und Brücken

Eine Brücke, im Fachjargon häufig auch als Bridge bezeichnet, verbindet vollkommen transparent Kabel des selben Typs und erntet dafür wenig technische Beachtung. Probleme tauchen in diesem Zusammenhang erst auf, wenn unterschiedliche Kabelsysteme, wie zum Beispiel IEEE 802.3 und IEEE 802.5 mittels Brücken zu gemeinschaftlichen Interagierung verdammt werden. Der Grund für die Komplikationen liegt in der differenten Darstellungsweise von MAC-Adressen.

Dieses Problem schlägt daher zu Buche, dass in IEEE 802.3- (CSMA/CD) und IEEE 802.5- (Token-Ring) oder IS9314- (FDDI) Kabelsystemen die höherwertigen Bits der MAC-Adressen nicht derselben Schreibweise in den einzelnen Oktetten unterliegen. Die Spezifikationen von IEEE 802.1 definiert eine identische Adress-Struktur der Systeme, was eine ebenfalls gleiche Auslegung in den Rahmen ermöglicht. Anders ist jedoch die Aktion der Weitergabe der MAC-Adressen von der Netz-Hardware an die oberen Schichten. Schwierigkeiten treten also nur auf, wenn MAC-Adressen zwischen Systemen ausgetauscht werden, die über die Datensicherungsschicht agieren, wie dies auch bei ARP der Fall ist.

Das Problem der inkompatiblen Auslegung von MAC-Adressen ist mit dem Ersetzen von dummen Bridges durch intelligente - ARP-Rahmen erkennende und die Adressen in den Hardware-Adressfeldern der Antworten und Anforderung der Darstellungsweise des Empfängernetzes entsprechend modifizierenden -, Brücken.

Proxy ARP

Mit Proxy ARP wird eine von IP-Routern genutzte Technik betitelt, die während den Anfangszeiten der Entwicklung von TCP/IP spezifiziert wurde. Der Sinn in ihr liegt im Schaffen von Abhilfe des begrenzten IP-Adressraums von IP Version 4. Heute in der Zeit von Subnetz-Masken und Brücken verliert Proxy ARP an beachtlichem Wert. Trotzdem wird Proxy ARP von Router-Elementen weiterhin unterstützt.

Aufgrund des Wachtums eines Netzwerkes kann relativ schnell und verhältnismässig unerwartet der Punkt der physikalischen Beschränkung einer Einführung zusätzlicher Knoten in das System erreicht werden. In diesem Falle kann das Netz nur durch ein zweites unabhängiges physikalisches Kabelsystem erweitert werden. In den Kinderjahren von TCP/IP, vor dem Erfinden von Netzmasken und Brücken, konnten zwei Kabelsysteme nur mit einem für zwei verschiedene IP-Ranges konfigurierten Router verbunden werden. Repeater waren aufgrund des Fehlens der Notwendigkeit von Filterungsfunktionen für diese Arbeit nicht geeignet. IP-Adressen wurden damals rigoros und verschwenderisch vergeben - Man konnte es sich ja damals auch noch leisten.

Wenden wir uns einem illustren Beispiel zu: Ein Unternehmen ergatterte sich die registrierte IP-Adresse der Klasse B 130.1.2.3 . Die Firma benutzt die Ethernet-Technologie und möchte 2'048 Host-Rechner mit der Hilfe von TCP/IP untereinander agieren lassen. Mit der Adresse der Klasse B stehen dem Unternehmen 65'534 mögliche Knotenadressen zur freien Verfügung. Da man jedoch Ethernet einsetzt, können maximal 1'024 Knoten in einem Segment eingebunden werden. Die Implementierung weiterer Systeme erfordert das Nutzen eines Routers oder einer Bridge. Um nun trotzdem die erste angestrebte Anzahl Knoten zu erreichen, muss ein zweites autonomes Kabelsystem angelegt werden, welches aufgrund des regen Datenverkehrs mittels Router an das erste angeschlossen wird. Konventionelle Router erfordern, dass den jeweiligen Schnittstellen differente IP-Adressen zugeteilt werden. Obwohl von den 65'534 Adressen der Klasse B nur 1'024 gebraucht wurden, können die restlichen 64'510 Adressen nicht verwendet werden; also offenbahrt sich eine Vergeudung in höchstem Masse. Damit der Router einwandfrei arbeiten kann, muss ihm eine zweite IP-Adresse der Klasse B zugeteilt werden, und damit sind erneut ganze 65'510 IP-Adressen verschwendet. Dieses Vorgehen ist aus technischer Sicht in keinster Weise akzeptabel; abgesehen von privaten autonomen Netzwerksystemen ohne registrierte IP-Adressen.

Das Internet Protokoll bedient sich ARP, um die MAC-Adresse einer Einheit zu ermitteln, sofern die Netznummer in der eigenen IP-Adresse der des Empfängerknotens entspricht. Andernfalls kommt ein routendes Element (Router oder Gateway) zum Einsatz. Damit möglichst wenige IP-Adressen verschleudert werden, ist es aus technischer Sicht wünschenswert den beiden Interfaces des routenden Systems die gleiche Netznummer zuzuteilen. Wird jedoch dieselbe Netznummer verwendet, muss man ein Verfahren finden, mit dem man die Richtung der Weiterleitung von Datagrammen eindeutig erkennen kann. Proxy ARP ist in diesem Fall einer der Schlüssel.

Proxy ARP kann auf verschiedenste Weisen implementiert werden. Als die effizienteste Methode ist die Zuordnung von Bits in der IP-Adresse, anhand derer unterschiedliche Subnetze identifiziert werden können, anzusehen. Das Relais kann als eine Art Puffer die unnötigen ARP-Rundsendenachrichten abblocken, da nur die an andere Subnetze adressierten Broadcasts weitergeroutet werden müssen. Damit kann der überschüssige Netzwerkverkehr eingedämmt und die Performance gewahrt werden. Die einzigen Hops, die die elementaren Bits zur Kennzeichnung der verschiedenen Subnetze erkennen können müssen, sind die Proxy ARP-Geräte. Natürlich erfordert das erreichen dieses Ziels eine durchdachte Zuweisung des richtigen Adressbereichs von seiten des Netzwerkadministrators. Beispielsweise könnten die ersten vier Bits des Host-Anteils der IP-Adresse zur Identifizierung der verschiedenen Subnetze eingesetzt werden. Dabei wird jedoch nicht, wie von vielleicht vielleicht vermutet, mit Subnetz-Masken gearbeitet oder ist die Adressenstruktur des Endknotens bekannt. Es können nun also 14 Subnetze dadurch definiert werden (Die Subnetze 0 und 15 finden in diesem Beispiel aus Gründen der Einfachheit keine Verwendung!). Empfängt nun die Schnittstelle 1 eine ARP-Anforderung, überprüft die Proxy ARP-Vermittlungseinheit die Bits in der Knotenadresse darauf, ob die Nachricht ein anderes Subnetz kennzeichnet. Wird der Gutfall erkannt, findet eine Weiterleitung an die Schnittstelle 2 statt. Dort wird dann die Absenderadresse durch jene der Proxy ARP-Schnittstelle 2 ersetzt und als üblicher ARP-Broadcast ins Neuland geblasen. Die jüngst von der ganzen Aktion betroffene Proxy ARP-Einheit speichert die in der ARP-Antwort vermerkte MAC-Adresse des Absenders-, sowie des Empfängerknotens und vermerkt  an welcher Schnittstelle sich diese befinden. Wird vom Absender nun nocheinmal ein Datagramm an die Schnittstelle 1 des Routers gesandt, enthält dieser bereits die Empfängeradresse der Proxy ARP-Einheit. Das Datagramm wird daher direkt von der Proxy ARP-Einheit angenommen. Die Proxy ARP-Einheit ersetzt nun wiederum die tatsächliche MAC-Adresse des Empfängerknotens und sendet das modifizierte Datagramm an die Schnittstelle 2. Diese Methode funktioniert nur, wenn die beiden Endknoten die Gültigkeit der MAC-Adressen in den jeweiligen ARP-Antworten nicht überprüfen. Es ist durch dieses ganze Prozedere möglich, mit einer beliebigen MAC-Adresse zu antworten, die als Ersatz eines anderen Knotens fungiert. Der ARP-Cache eines Endknotens, der sich in einem Proxy ARP-System befindet, enthält die MAC-Adresse der Proxy ARP-Einheit, die vielen IP-Adressen zugeordnet ist. Diverse Firewall-Systeme erlauben das verwerfen von durch Proxy ARP modifizierte Datagramme, um so entfernte Manipulationen am ARP-Cache zu unterbinden.

Proxy ARP stellt also eine Alternative zum Einsatz von Brücken dar, da es zwei unterschiedliche Kabelsysteme mit derselben IP-Netznummer verbinden kann. Proxy ARP ist für das Übertragen von Rahmen zwischen den verschiedenen Netzen und das Filtern überflüssiges Datenaufkommens zuständig. Proxy ARP ist vor allem in archaischen Netzwerken gern genutzt, die den Internet-Standart der Subnetz-Adressierung nicht unterstützen. Als einziger Nachteil beim Einsatz von Proxy ARP in solch veralteten Netzwerksystemen ist der relativ hohe Verwaltungsaufwand anzusehen, der duch die Abbildung der Subnetz-Adressstruktur auf die jeweils anderen Kabelsysteme entsteht.

Proxy ARP und Router

Viele Router verwenden per Default-Einstellung Proxy ARP, auch wenn keine Subnetz-Adressierungsschema zum Einsatz kommen. Das Router-Element greift insofern beim Empfang einer ARP-Anforderung für ein anderes Netz oder Subnetz manipulativ in das Geschehen ein, indem es seine eigene MAC-Adresse in der ARP-Antwort zurückschickt. Zur Übermittlung des Datagramms an den Empfänger werden die herkömmlichen Routenwahl-Mechanismen eingsetzt. Dieser Fall kann jedoch nur eintreten, wenn ein verwirrter oder falsch konfigurierter Rechner das Gefühl des Befindens in einem anderen Netz hat,und der Router sich an ein anderes Bild der Adressenstruktur klammert. Es läge also ein klassischer Adressierungs-Fehler vor, da zwei Geräteeinheiten die IP-Adresserungsschematas komplett anders interpretieren. Grund dafür kann die Wahl unterschiedlicher Subnetz-Masken sein. Die beiden Geräte würden so mit einer Netzstruktur arbeiten, die für die Opposition nicht erkennbar und verständlich ist.

Denial of Service durch ARP-Stürme

Der Denial of Service-Angriff mittels ARP-Sturm hat die Überlastung einer Netzwerkkomponente oder eines Netz(abschnitt)es zur Folge, was unter Umständen einen weiteren weniger destruktiven Angriff erst ermöglicht (z.B. IP-Spoofing). Die Extremsituation tritt ein, wenn ARP-Broadcasts eine non-existente IP-Adresse in Erfahrung bringen versuchen. Alle an das Netzwerk angeschlossenen Gateways beginnen alsdann mit dem Weiterleiten der Anfrage an die Nachbarnetze. Ganz extrem wird dieser Angriff, wenn nach dem ersten Briadcast-Sturm synthetische ARP-Rückantworten der nicht existierenden Adresse versendet werden, die wiederum von den Gateways per Broadcast zur finalen Verstopfung des Netzes weiterverbreitet werden. Solche Broadcast-Stürme belegen rasch einen Grossteil der Netzwerkkapazität und lassen die Performance in den Keller sinken. Wichtig ist in sensiblen Umgebungen im Vorfeld das sogenannte Media-Speed-Verhalten durch experimentell simulierte Extremsituationen in Erfahrung zu bringen. HAVOC für UNIX/Linux ist ein beliebtes Tool zum Erzwingen von ARP-Stürmen.

Denial of Service durch ARP-Fehlimplenetierungen

Auch auf Fehlimplementierungen der ARP-Funktionalität können Denial of Service-Attacken abzielen, wie im NetBSD Security Advisory 1999-010 (ARP table vulnerability) berichtet wird: obsd_fun.c schickt übergrosse ARP-Pakete an eine OpenBSD 2.6-Maschine, und zwing sie so zur Kernel-Panik. Aber nicht nur UNIX-Derivate sind von solchen Schlampereien betroffen. Auch Microsot Windows kann mit den C-Scripts winarp.c und poink.c auf die Pelle gerückt werden. Diese Angriffs-Form wird im Thread von Joel Jacobson in Bugtraq erstmals vorgestellt. Ähnliche Diskussionen finden sich in den beiden Threads von Andrew Lancashire und Lisa Napier über DoS-Attacken auf Cisco-Systeme, und von Scott Blake über Cabletron-Router, durch das Überfluten der ARP-Tabelle.

Angriffe durch ARP-Spoofing

Ein Angreifer versucht beim ARP-Spoofing seine Hardware-Adresse zu behalten, aber die IP-Adresse eines vertrauenswürdigen Hosts anzunehmen. Dazu manipuliert der Bösewicht remote durch falsche Mapping-Informationen den Cache seines Opfers. Verlauft seine Attacke erfolgreich, werden von da an alle Pakete vom Ziel an die Hardware-Adresse des Angreifers geleitet. Das Opfer glaubt nun faktisch daran, dass der Rechner des Angreifers der vertrauenswürdige Host ist.  Auf Rootshell publizierte Yuri Volobuev einen interessanten Artikel, der auf solche Redirect-Attacken mittels ARP und ICMP eingeht.

ARP-Spoofing unterliegt jedoch einigen Einschränkungen, die es für viele Angreifer nicht gerade attraktiv macht: Zum einen kann intelligente Hardware solche Attacken im Sande verlaufen lassen, zum anderen verlieren unter Umständen Cache-Einträge von ARP schnell ihre Gültigkeit. Der Angreifer muss daher stets den ARP-Cache des Opfers neu überreden, was an der Effizienz des Angriffs zu kratzen vermag. Ausserden ist ein in den Promiscous-Mode geschaltetes Interface in einem Ethernet-System genauso effizient für das unerlaubte Auslesen von Informationen.

Es existieren diverse Programme - wie zum Beispiel die Linux-Utilities ARP-Fun und ARPMITM -, die solche Angriffe auf einfachste Weise ermöglichen. Für ARPTool, ein weiteres Tool dieser Sparte, existiert sogar ein grafisches Frontend mit zusätzlichen Features (z.B. Automatisiertes MAC-Sniffing) namens Switch Fucker. Ein witziges Feature bietet das Paket mit den BSD-Utilities conflict-DoS.c und conflictd.c von Noupe: Durch gespoofte ARP-Pakete können WinPopUp-Nachrichten auf Windows-Clients erzeugt werden. Einen Schritt weiter geht da das simple Smit von Paul Starzetz, welches in ungeswitchten und geswitchten Netzwerken ARP-Hijacking ermöglicht.

Sich ARP-Spoofing bedienenden Angreifern den Gar aus zu machen, bedarf das statische Festlegen der ARP-Tabelle. Dies kann jedoch unter umständen sehr zeitaufwendig und nervenaufreibend sein, wodurch dieser Methode höchstens den Titel Notlösung zugesprochen werden kann. Eine zusätzliche Massnahme oder mindestens gleichwertige Alternative stellt das Utility ARPWwatch von Craig Leres dar, welches nach Veränderungen der IP-/Ethernet-Mappings Ausschau hält. Werden Änderungen bemerkt, findet eine Alarmierung per E-Mail statt. Zudem werden die Manipulationen für eine spätere Analyse protokolliert.