destina - Fotolia

Wie Sie Ihr IPv6-Address-Management schützen

Ob Ihre IPv6-Address-Komponenten anfällig für DoS-Angriffe sind, können Sie relativ einfach überprüfen. Wir zeigen Ihnen, wie das funktioniert.

IPv6 ND (Neighbor Discovery) ist ein essentieller Teil der IPv6-Protokoll-Suite. Es kommt unter anderem für IPv6-Adressauflösung und die zustandslose Address-Autokonfiguration (SLAAC/Stateless Address Autoconfiguration) zum Einsatz. Wir sehen uns in diesem Beitrag diverse Komponenten an, inwiefern IPv6 anfällig für ND-basierte Angriffe sein kann.

IPv6-Nodes müssen IPv6 SLAAC implementiert haben. Bei SLAAC geben lokale Router Informationen über das IPv6-Netzwerk an lokale Hosts weiter. Diese verwenden die Informationen, um die IPv6-Verbindungen zu etablieren. Dies umfasst unter anderem die Konfiguration einer IPv6-Adresse. Anders als bei Dynamic Host Configuration Protocol (DHCP) Version 6 gibt es keine sogenannten Address-Leases. Die Hosts konfigurieren ihre Adressen hingegen selbständig. SLAAC führt Router-Solicitation- und Router-Advertisement-Meldungen ein, um Konfigurationsinformationen zu IPv6-Netzwerk- und IPv6-Address-Management zu vermitteln. Der automatische Konfigurationsprozess für die Adressen funktioniert ungefähr so:

  1. Der Host konfiguriert eine Link-Local-Adresse.
  2. Der Host überprüft, dass die Adresse einzigartig ist. Er führt zum Beispiel Duplicate Address Detection (DAD) für diese (vorläufige) Adresse durch.
  3. Der Host schickt eine Router-Solicitation-Meldung.
  4. Wird ein Router Advertisement (RA) empfangen, konfiguriert der Host eine oder mehrere vorläufige IPv6-Adressen für jeden der Präfixe, wie in den empfangenen RAs angezeigt.
  5. Der Host überprüft, ob die Adresse tatsächlich einzigartig ist. Er führt DAD für diese eventuelle Adresse durch.
  6. Ist die Adresse wirklich einzigartig, wird sie normalerweise zur preferred (bevorzugten) Adresse und lässt sich ab sofort aktiv für die Kommunikation im Netzwerk nutzen.

Unterm Strich bedeutet dies, dass ein Node zunächst eine Link-Local-IPv6-Adresse konfiguriert, der eine globalere IPv6-Adresse folgt, die wiederum auf den Präfix-Informationen aus den RA-Meldungen basiert. RA-Nachrichten beinhalten möglicherweise auch andere Informationen zur Netzwerkkonfiguration, die IPv6-Routen zu spezifischen Netzwerken enthalten. Denkbar sind auch Adressen rekursiver DNS-Server (Domain Name System) und die Maximum Transmission Unit (MTU), also die maximale Paket-Größe, die einzusetzen ist.

Einige IPv6-Implementierungen scheitern an der Implementierung von Validierungsprüfungen für die Informationen, die sie via RA-Meldungen empfangen. Möglicherweise limitieren sie auch die Größe der dazugehörigen Datenstrukturen nicht.

Zum Beispiel konfigurieren einige Implementierungen eine Adresse pro Präfix, die aus einer RA-Meldung stammt. Eine maximale Anzahl erlaubter IPv6-Adressen geben sie allerdings nicht vor. So könnte ein Angreifer ein potenzielles Opfer mit mehreren RA-Meldungen fluten, die außerdem mehrere Autokonfigurationspräfixe enthalten. Das Opfer wird daraufhin so viele IPv6-Adresse automatisch konfigurieren, bis es abstürzt oder nicht mehr ansprechbar ist.

Um zu verstehen, was hinter so einem Angriff steckt, könnte beispielsweise ein IT-Administrator das ra6-Tool zu Rate ziehen, das sich im IPv6 Toolkit von SI6 Networks befindet. Danach hat er die Möglichkeit, einen Angriff mit folgendem Befehl durchzuführen:

ra6 -i eth0 --flood-prefixes 10 -d ff02::1 -l -z 1 -v

Dieser Befehl schickt jede Sekunde eine RA-Nachricht an alle lokalen Nodes, die zehn zufällige Präfixe enthält. Das veranlasst jeden Node, eine IPv6-Adresse für jede der zufälligen Präfixe zu generieren.

In Unix-ähnlichen Systemen kann man mithilfe des Befehls ifconfig auf jedem Ziel-Node überprüfen, ob die IPv6-Adressen automatisch konfiguriert wurden.

Abbildung 1: Sie können den Befehl ifconfig nutzen, um eine Überprüfung nach automatisch konfigurierten Adressen durchzuführen.

Bei einer realen Attacke würde der Angreifer die RA-Nachrichten natürlich wesentlich konzentrierter schicken. Wir sprechen hier zum Beispiel von mindestens 100 pro Sekunde. Da so ein Angriff allerdings alle lokalen Nodes zum Absturz bringen kann, sind wir in unserem Beispiel mit einer sehr konservativen Paketrate ans Werk gegangen.

Alle RA-Meldungen enthalten einen Wert für die Router Lifetime. Diese weist darauf hin, wie lange der Router, der die Nachricht schickt, als Standard-Router eingesetzt werden soll. Die lokalen Hosts erfahren diesen Wert aus den RA-Nachrichten und überwachen ihn mithilfe eines lokalen Timers. Lokale Router versuchen den am lokalen Host zugehörigen Timer aufzufrischen, indem sie in regelmäßigen Abständen (nicht angeforderte) RA-Nachrichten schicken. Aus diesem Grund erlischt die Lifetime eines Routers in einem normalen Szenario eigentlich nie. Ein Angreifer könnte diesen Timer oder Parameter allerdings für Denial of Service (DoS) missbrauchen. Wenn sich ein Angreifer als lokaler Router ausgeben kann und eine RA-Nachricht mit einer Router Lifetime von 0 schickt (oder einer anderen kleinen Zahl), würde das Opfer-System diesen Router aus der Liste der Standard-Router nehmen und somit hätten wir ein DoS-Szenario.

Nehmen wir an, dass der legitime, lokale Router für ein bestimmtes Subnetz fe80::1 ist. Dann könnte ein Cyberkrimineller einen DoS-Angriff auf alle lokalen Nodes mithilfe von ra6 wie folgt ausführen:

ra6 -i eth0 -s fe80::1 -d ff02::1 -t 0

Dabei spezifiziert -i eth0 die Netzwerk-Schnittstelle, mithilfe derer man die Attacke durchführt. Das -s fe80::1 steht für die Quelladresse des Angriffspaketes. In diesem Beispiel haben wir uns als den legitimen, lokalen Router ausgegeben. Der Parameter -d ff02::1 spezifiziert das Angriffspaket, das man an alle Nodes Link-Local Multicast-Adressen schickt. Schlussendlich setzen wir mittels -t 0 die Router Lifetime auf 0.

Im Anschluss könnten Sie den Befehl netstat bemühen, um die Routing-Tabelle auf dem Opfer-Node zu untersuchen. Damit ließe sich bestätigen, dass die Standard-Route entfernt wurde, die auf den Node fe80::1 zeigt.

Lecks bei der Erkennung von Duplikaten stopfen

Bevor sich eine IPv6-Adresse für die Netzwerkkommunikation aktiv nutzen lässt, muss man diese Adresse auf Einzigartigkeit prüfen. Offiziell nennt sich das DAD oder Dupliate Address Detection. DAD funktioniert grob gesagt wie folgt:

  • Ein Node, der eine IPv6-Adresse verwenden möchte, schickt eine NS-Nachricht (Neighbor Solicitation) für die zuvor bereits erwähnte (vorläufige) Adresse.
  • Wird eine Neighbor Advertisement (NA) als Antwort erhalten, stuft man diese Adresse als Duplikat ein. Folgerichtig scheitert DAD.
  • Wird keine NA-Nachricht für diese Adresse empfangen (möglicherweise wird die NS-Nachricht mehrmals übertragen), stuft man die Adresse als einzigartig ein. Somit ist DAD erfolgreich.

Die zu DAD gehörigen NS-Nachrichten werden mit der Quelladresse an die nicht spezifizierten Adressen (::) gesendet. Somit ist es einfach, sie von NS-Nachrichten zu unterscheiden, die für Adressauflösung und nicht für die Erkennung von Duplikaten bestimmt sind.

Ein Cyberkrimineller kann recht einfach einen DoS-Angriff gegen lokale Nodes fahren, indem er das Tool na6 wie folgt einsetzt:

na6 -i eth0 -b :: -L -v

Dieser Befehl weist na6 an, nach NS-Nachrichten zu lauschen (-L), bei denen die Quelladresse auf die nicht weiter spezifizierte Adresse (-b ::) gesetzt ist. Die Netzwerkschnittstelle ist dabei eth0. Das Tool soll mit einer NA-Nachricht antworten, wenn eine solche Adresse empfangen wird. Immer wenn ein Node anfänglich startet und versucht, eine IPv6-Adresse automatisch zu konfigurieren, wird jede Adresse als Duplikat angesehen, die dieser zu konfigurieren versucht. Die Konsequenz daraus ist, dass SLAAC scheitert.

Mit dem Befehl ifconfig können Sie die Konfiguration einer potenziellen Opfer-Netzwerkkarte untersuchen. Das sieht dann so aus:

Abbildung 2: So kann man die Konfiguration einer Netzwerkkarte prüfen.

In Abbildung 2 sind mindestens zwei interessante Dinge zu beobachten. Zunächst einmal ist die Link-Local-Adresse als Duplikat markiert. Weiterhin gibt es keine globalen IPv6-Adressen, die für diese Netzwerkschnittstelle konfiguriert sind. Der Grund dafür ist das Scheitern von DAD für die vorläufige Link-Local-Adresse. Ist das der Fall, wird SLAAC abgebrochen. Auf diese Weise kann man sehen, dass ein DoS-Angriff im Gange ist.

Network Unreachability Detection (NUD) ist eine weitere Komponente von IPv6. Sie besteht aus dem Testen des Pfades zu den benachbarten Nodes. Damit wird die Wahl eines alternativen Pfades erlaubt, falls der momentan verwendete ausfällt. An dieser Stelle kann ein Angreifer NUD nur soweit kompromittieren, dass er das Protokoll verwirrt. Das Protokoll wird dann glauben, dass der Pfad einwandfrei funktioniert, obwohl das Gegenteil der Fall ist.

Verglichen mit den restlichen ND-basierten Angriffen ist das für Cyberkriminelle weniger interessant. Aus diesem Grund brauchen Sie sich hinsichtlich dieser Taktik eigentlich keine Gedanken machen.

Über den Autor:
Fernando Gont arbeitet für SI6 Networks als Consultant für Internet Security and Engineering. Er ist aktives Mitglied der IETF und wirkt in diversen Arbeitsgruppen mit. Er hat diverse Request for Comments (RFCs ) und Internet-Entwürfe ausgearbeitet. Fernando Gont trifft man regelmäßig als Sprecher auf Konferenzen, Messen und technischen Meetings. Seine Spezialgebiete sind Informationssicherheit, Betriebssysteme und Internet Engineering. Sie finden weitere Informationen auf seiner Website.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im November 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Best Practice: Netzwerk-Sicherheit und -Tools

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close