Aktive Systeme in IPv6-Netzen aufspüren
Im Klaren
Die Annahme, der Suchraum eines klassischen IPv6-Subnetzes sei mit 264 möglichen Adressen zu groß zum Auffinden aktiver Systeme, hat RFC 7707 widerlegt. Denn das „neue“ Internetprotokoll hat einige zum Teil unbeabsichtigte Eigenschaften, die Hosts auffliegen lassen.
Eine Suche nach Systemen in IPv6-Netzen kann unterschiedliche Gründe haben. Ein Administrator prüft etwa eine Konfiguration, während ein Penetrationstester aktive Systeme auf Schwachstellen hin abklopft. IPv6 eignet sich zum Aufspüren von Systemen insbesondere dadurch, dass das Protokoll unter Windows inzwischen obligatorisch und das Deaktivieren nicht mehr empfehlenswert ist. In gängigen BSD- und Linux-Derivaten läuft IPv6 standardmäßig und einige Anwendungen setzen es bereits voraus. Dieser Artikel stellt einfache, überwiegend nicht invasiv wirkende Methoden und Werkzeuge zum Ermitteln von IPv6-Systemen vor.
IPv6-Adressen bestehen aus einem Netzwerkpräfix und dem Interface Identifier, beide umfassen jeweils 64 Bit. Die Internet Assigned Numbers Authority (IANA) verwaltet die Adressen und verteilt sie an regionale Adressverwalter – in Europa das RIPE NCC – zur Weitergabe an deren Mitglieder. Einer Empfehlung in RFC 3177 zufolge gab es anfangs je 280 IPv6-Adressen als /48-Subnetz. Allerdings stellte sich bald heraus, dass dies den vorhandenen Adressraum unnötig einschränkt, da kaum jemand 216 Teilnetze nutzen konnte. Daher empfiehlt RFC 6177 kleinere Adressräume, beispielsweise /56 (272 IPv6-Adressen, siehe Abbildung 1).
Die IANA hat ihren regionalen Adressverwaltern bisher lediglich einen Teil der denkbaren IPv6-Adressen zugewiesen, was den Suchraum für aktive IPv6-Systeme deutlich einengt (zu Quellenangaben siehe „Alle Links“ am Ende des Artikels). Dennoch ist es keineswegs trivial, das gesamte IPv6-Internet zu durchsuchen. Wie man sogar ganz ohne aktive Suche an Adressdaten gelangt, hat die Schwachstellen-Suchmaschine Shodan gezeigt: Sie stellte einen Zeitgeberdienst über das NTP Pool Project zur Verfügung und sammelte dadurch IPv6-Adressen aktiver Systeme. Das fiel Anfang 2016 erst nach Monaten auf und die Server von Shodan flogen aus dem NTP-Pool-Cluster.
Automatische Adressvergabe
Die weiteren Betrachtungen betreffen den rechten Teil der IPv6-Adresse: den Interface Identifier. Bei automatisch mittels Stateless Address Autoconfiguration (SLAAC) vergebenen Adressen stammte er ursprünglich aus der eindeutigen MAC-Adresse der Netzwerkkarte. Ein Ziel von SLAAC besteht darin, Adressen ohne manuelles Konfigurieren oder zusätzliche Komponenten wie einen DHCP-Server zu verteilen. Über SLAAC generierte Adressen sind am Wort 0xfffe zwischen dem Organizationally Unique Identifier (OUI) und dem Rest der MAC-Adresse erkennbar. Aufgrund des eingefügten festen Wortes gibt es 246 mögliche IPv6-Adressen eines Teilnetzes einer Organisation, da 46 Bit der SLAAC-generierten Adressen variabel sind. Wer diese erkennt, kann den Suchbereich für weitere IPv6-Adressen in einem Subnetz entsprechend verkleinern.
Wer zudem den Hersteller der Netzhardware und somit deren möglichen MAC-Adressenbereich kennt, kann den Suchraum noch weiter einschränken. Die einem Hersteller zugeordneten OUIs sind öffentlich bekannt. Wer eine oder mehrere MAC-Adressen kennt, kann benachbarte mit hoher Erfolgswahrscheinlichkeit testen, da zumindest größere Organisationen oftmals beim selben Hersteller viele Hardwarekomponenten auf einmal bestellen. So kommen fortlaufende oder nahe gelegene MAC-Adressen in der IPv6-Umgebung vor (RFC 7707).
Der mögliche MAC-Adressenbereich ist außerdem beim Einsatz von Virtualisierungssoftware oftmals bekannt: Wer die Umgebung kennt, kann sie recht zielsicher nach IPv6-Systemen abgrasen (Tabelle „Typische MAC-Adressen“).
Aufgrund der sich daraus ergebenden Eindeutigkeit und Unveränderbarkeit der IPv6-Adressen gab es rasch Datenschutzbedenken. Die daraufhin entwickelten Privacy Extensions sollen den SLAAC-generierten Adressen einen dynamischen Charakter verleihen. Temporäre IPv6-Adressen dienen der Kommunikation mit Dritten – allerdings gibt es die SLAAC-generierte Adresse weiterhin. Sie lässt sich auch von außen ansprechen, sofern keine lokale Firewall dagegen einschreitet (RFC 4941).
Manuelle Adressvergabe
Adressen lassen sich nicht nur automatisiert, sondern auch manuell vergeben. Das kann etwa bei Routern notwendig sein. Gewohnheit oder der Wunsch nach Vereinfachung können dazu führen, dass Administratoren dabei erkennbare Strukturen erzeugen (Tabelle „Nach durchschaubaren Regeln verteilte IPv6-Adressen“).
Die in der Tabelle genannten Muster treten auch kombiniert auf, etwa in Gestalt von Mischformen aus Low-Byte- und Wortadressen wie 2001:db8::cafe:21.
Da IPv6 zu IPv4 nicht rückwärtskompatibel ist, sind Tunnel- oder Übersetzungsmethoden in einem gemeinsamen Netz notwendig (siehe Tabelle „Tunnel- und Übersetzungsmechanismen“). Zu den Tunnelmethoden gehört das Intra-Site Automatic Tunneling Protocol (ISATAP). Es transportiert IPv6-Pakete über IPv4-Router. Die ISATAP-Adresse beginnt entweder mit einem globalen Netzwerkpräfix, einem 6to4-Präfix oder dem Link-lokalen Adresspräfix. Die letzten 64 Bit setzen sich aus 0000:5efe für lokale Adressen respektive 0200:5efe für globale Adressen und der IPv4-Adresse in hexadezimaler Form zusammen (RFC 5214).
Erkennen von Tunnel- und Übersetzungsmethoden
Anders als beim Tunneln übersetzt im Rahmen der Stateful Network Address Translation 64 (Stateful NAT64) ein NAT64-Gateway IPv4- in IPv6-Adressen und umgekehrt, was eine Kommunikation zwischen IPv4- und IPv6-Umgebungen ermöglicht. Das NAT64-Gateway arbeitet ähnlich wie NAT und merkt sich die einzelnen Kommunikationspartner in einer NAT64-Tabelle (RFC 6144). Das Format der NAT64-IPv6-Adressen entspricht den sogenannten IPv4-embedded-IPv6-Adressen. Die bestehen aus einem Adresspräfix und der IPv4-Adresse in hexadezimaler Schreibweise. Es folgt ein mit Nullen aufgefülltes Suffix. Das Adresspräfix darf 32, 40, 48, 56, 64 oder 96 Bit lang sein. Aufgrund des „u“-Byte sind an den Bit-Stellen 64 bis 71 Nullen eingefügt. Neben den allgemeinen Adresspräfixen des Netzwerks sind „Well-known-Adressen“ mit dem Präfix 64:ff9b::/96 verwendbar (RFC 6052).