© AllzweckJack, photocase.com

IPv6 stammt aus der Frühzeit des World Wide Web und enthält so manche Neuerung, die in den Neunzigern wirklich wichtig war. Nach heutigen Maßstäben gemessen bringt das neue Protokoll in Sachen Sicherheit keinen großen Gewinn mehr. Der umsichtige Admin bleibt also gefragt.

IPv6 ändert manches: Am bekanntesten sind sicher die Erweiterung des IP-Adressraums von 32 auf 128 Bit und die einfacheren Netzmasken. Statt variabler Länge (VLSM) unterstützt IPv6 nur mehr 64 Bit (»/64« ), Broadcasts entfallen, es gibt nur noch Unicast-, Multicast- und Anycast-Adressen.

Neben dem globalen Scope, der die Erreichbarkeit im IPv6-Internet sicherstellt, kennt das Protokoll unterschiedliche Local Scopes (Gültigkeitsbereiche), die diese auf kleine Bereiche beschränken. Der Link Local Scope limitiert die Reichweite der IP-Adresse auf das lokale Netz, der Site Local Scope und der Organization Local Scope fassen mehrere Netze über Router zusammen.

Auch bei IPv6 benötigen die Systeme für die Kommunikation untereinander die MAC-Adressen der beteiligten Netzkarten. Diese Informationen ermittelt das ICMPv6-Protokoll auf der Schicht 3 – bei IPv4 macht das noch das Address-Resolution- Protokoll (ARP) in Schicht 2. Die Entwickler haben dem Vorgang auch einen neuen Namen gegeben: Neighbor Discovery Protocol (NDP, [1]).

Auch die Path-MTU-Discovery ist bei IPv6 verpflichtend, ICMPv6 spielt daher eine wesentlich wichtigere Rolle als bei IPv4. Ebenfalls integriert ist die Unterstützung der IPsec-Protokollfamilie – eine alte Bekannte aus der Security-Welt, die Admins schon unter IPv4 häufig für den Aufbau von virtuellen privaten Netzen heranzogen [2].

Die Fans der Network Address Translation (NAT) schauen bei IPv6 erst mal in die Röhre: Auch wenn Entwickler immer wieder Vorstöße unternehmen [3], ist bis heute keine NAT von IPv6 auf IPv6-Adressen (NAT66) spezifiziert. Jedes System, das mit anderen Systemen im IPv6-Internet kommunizieren möchte, benötigt also eine globale IPv6-Adresse. Damit ist das System, ob Uralt-Netzwerkdrucker, ungewarteter Windows-Client oder die vergessene Appliance, immer erreichbar, wenn eine Firewall das nicht unterbindet – ein Feature, das Admins erschauern lässt.

Nichts wirklich Neues?

Es mag überraschen, aber andere sicherheitsrelevante Dinge ändert IPv6 gegenüber dem Version-4-Stack nicht. Die Transportprotokolle auf der Schicht 4 (TCP, UDP) funktionieren wie bisher, auch die Applikationsprotokolle wie HTTP, SMTP und FTP muss der Admin nicht anders konfigurieren, abgesehen von den neuen Adressen. Hier verbessert IPv6 die Sicherheit der Protokolle auch nicht, ein Angreifer führt beispielsweise einen »SYN« -Flood bei IPv6 genau so durch wie unter IPv4.

Auch auf OSI-Layer 2 ändert sich wenig. Dass das ARP-Protokoll wegfällt, hilft gegen Spoofing (Kasten “ARP-Spoofing”) nur teilweise. Ein Angreifer erzielt den gleichen Effekt mit NDP-Spoofing. Die IPv6-Entwickler haben aber diesen Angriffsvektor erkannt und Modifikationen des Protokolls in RFC 3791 (Secure Neighbor Discovery Protocol, SEND, [4]) spezifiziert. SEND verwendet kryptographisch erzeugte Adressen mit öffentlichen Schlüsseln für die Authentifizierung der NDP-Nachrichten. Leider unterstützen nur wenige Betriebssysteme diese Erweiterung, auch Windows 7 nicht.

Ein Admin kann NDP-Spoofing heute nur mit intelligenten Multilayer-Switches begegnen, die eine interne Tabelle mit allen IPv6- und MAC-Adressen pflegen und gefälschte Nachrichten erkennen und verwerfen. Hersteller bezeichnen dieses Vorgehen bei IPv4 als Dynamic ARP Inspection (DAI, [5]).

Dass NAT (Network Address Translation) wegfällt, bisher völlig ersatzlos, ist nicht ausschließlich eine gute Nachricht. Erst mal freuen sich Admins, die es mit FTP, Oracle SQL Net oder H.323 nun einfacher haben. Diese Protokolle handeln dynamisch während des Betriebs neue Ports aus. Diese korrekt mit Address Translation abzubilden erwies sich nicht selten als echte Herausforderung: Der NAT-Algorithmus muss das Protokoll verstehen und verfolgen, damit er den neu ausgehandelten Port erkennt.

Auch andere IP-Protokolle, die über keine Ports verfügen, zum Beispiel das ESP-Protokoll von IPsec, kommen ohne Workarounds wie NAT-Traversal durch UDP-Encapsulation endlich so zum Einsatz, wie es ihre Entwickler ursprünglich beabsichtigt hatten.

Privatsphäre gefährdet

Die Kehrseite der Medaille betrifft vor allem den Datenschutz:

• Administratoren haben zunächst keine Chance mehr, ihre interne Netzstruktur und die verwendete IP-Adressen zu verbergen.
• Dienstleister im Internet können die einzelnen Verbindungen von unterschiedlichen Rechnern in einem Client-Netz ohne Cookies einzelnen Rechner zuordnen.
• Die Rechner sind unter ihren IPv6-Adressen auch von außen erreichbar.

Heimanwender brauchen jetzt zwar nicht mehr umständlich ein Portforwarding in ihren DSL-Routern zu konfigurieren, um von draußen auf heimische Systeme zuzugreifen. Aber der neue, direkte Weg nach drinnen steht jetzt auch einem Angreifer offen: Starke Firewallrichtlinien sind unbedingt geboten, um solche immer von überall erreichbaren Systeme zu schützen.

Da ein IPv6-Betriebssystem klassischerweise seine IPv6-Adresse auf seiner MAC-Adresse aufbaut (siehe den Abschnitt zur Autokonfiguration weiter unten in diesem Artikel), wird dieser Rechner eindeutig und sogar über mehrere Tage hinweg identifizierbar. Das ist besonders deshalb kritisch, weil der Rechner standardmäßig den Host-Anteil seiner IP-Adresse (den so genannten EUI-Identifier) immer gleich, nämlich basierend auf der MAC-Adresse, bildet (Abbildung 1). Handelt es sich um einen Laptop, der sich in unterschiedlichen Netzen befindet, ändert sich dann nur die Netzadresse. Greift der Anwender auf einen Server im Internet zu, kann dessen Betreiber anhand des identischen Identifier in der IPv6-Adresse feststellen, dass es dasselbe Gerät ist.

Abbildung 1: Die ID einer IPv6-Adresse bildet sich aus der MAC-Adresse. Hierzu werden »FFFE« eingeschoben und das zweite Bit im ersten Byte gekippt.

Zusätzlich kann beispielsweise ein Webseitenbetreiber nach wiederholten Besuchen nachvollziehen, aus welchen Netzen der Laptop-Besitzer sich seine Site angesehen hat: Er muss nur mit »whois« nach der Netzadresse fragen (Listing 1). IPv6-Adressen werden genau wie ihre Vorgänger Provider-weise registriert, »whois« ermittelt, welcher Firma eine Adresse zugeordnet ist. Im schlimmsten Fall lässt sich so recht einfach, zum Beispiel bei einem Außendienstmitarbeiter, ein komplettes Bewegungsprofil erstellen.

01 [Querying whois.ripe.net] 02 [whois.ripe.net] 03 inet6num: 2001:67c:24::/48 04 netname: SPE6-NET 05 descr: OpenSource Training Ralf Spenneberg 06 country: DE 07 org: ORG-OTRS1-RIPE 08 admin-c: RS9110-RIPE 09 tech-c: RS9110-RIPE 10 status: ASSIGNED PI 11 mnt-by: RIPE-NCC-END-MNT 12 mnt-by: MNT-Jansen 13 mnt-lower: RIPE-NCC-END-MNT 14 mnt-routes: MNT-Jansen 15 mnt-domains: MNT-JANSEN 16 source: RIPE # Filtered

Zufälliger Identifier

Um das Tracken zu verhindern, führte RFC 4941 die IPv6 Privacy Extensions ein [6]. Sie ermöglichen es dem Betriebssystem, den Identifier zufällig zu bilden, wichtig ist ja zunächst nur dessen Eindeutigkeit im lokalen Netz. Alle modernen Betriebssysteme unterstützen diese Funktion, Microsoft Windows Vista und 7 aktivieren sie auch per Default. Unter Linux schaltet der Admin sie mit dem folgenden Kommando temporär ein:

sysctl -w net.ipv6.conf.all.use_tempaddr=2

Dauerhaft ändert er dies in der Datei »/etc/sysctl.conf« . Einstellungen für einzelne Distributionen und andere Betriebssysteme benennt [7].

Doch auch dieses Zuordnen hat seine Schattenseite: Jedes Mal, wenn das Betriebssystem die Netzwerkkarte aktiviert (oder aber mindestens einmal pro Tag), erzeugt es einen neuen Identifier. Kommt es in einem Netz zu einem Virus- oder Wurmausbruch, den der Administrator erst am nächsten Tag entdeckt, kann er die protokollierten IP-Adressen in seinen Firewallprotokollen nicht mehr einzelnen Systemen zuordnen, weil niemand die zufälligen IPv6-Adressen festhält.

Firewalling statt NAT

Der Administrator kommt bei IPv6 nicht um starke Firewallrichtlinien herum. Erfreulicherweise kann er dabei mit zustandsorientierten Regeln die gleiche einfache Sicherheit erreichen, die auch ein NAT-Setup bietet. Clients dürfen dann Netzwerkverbindungen nur in einer Richtung aufbauen.

Tatsächlich bringt pures NAT sogar weniger Sicherheit, da es lediglich die IP-Adressen versteckt und Zugriffe nicht unterbindet. Mit Source-Routing und Kenntnis der IP-Adressen baut ein Angreifer sogar Verbindungen zu “genatteten” Systemen auf, wenn die Firewall es erlaubt. Allerdings vermag der Linux-Kernel auch erst seit Version 2.6.20 IPv6 zustandsorientiert zu filtern. Ältere Distributionen, zum Beispiel RHEL 5 und Centos 5, lassen sich deshalb nicht als IPv6-Firewall einsetzen.

Damit nur interne Clients sich mit Systemen im Internet verbinden dürfen, gleichzeitig aber keinerlei Verbindungen aus dem Internet auf die lokalen Rechner erlaubt sind, setzt der Administrator die Firewallregeln mit dem einfachen Skript aus Listing 2. Die vier Regeln erlauben alle Pakete, die zu bereits aufgebauten Verbindungen gehören (»ESTABLISHED« ) oder Fehlermeldungen für diese Verbindungen enthalten (»RELATED« ). Neue Verbindungen (»NEW« ) sind nur gestattet, wenn sie aus dem internen LAN stammen. Will er auch Protokolle wie FTP unterstützt wissen, die dynamisch neue Ports aushandeln, muss der Administrator die entsprechenden Module laden, zum Beispiel mit »modprobe nf_conntrack_ftp« .

01 LAN=eth0 02 INTERNET=ppp0 03 IPT=/sbin/ip6tables 04 05 $IPT -P FORWARD DROP 06 $IPT -F FORWARD 07 $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 08 $IPT -A FORWARD -i $LAN -o $INTERNET -m state --state NEW -j ACCEPT

Schwieriger ist es jedoch, die Firewall selbst zu schützen. Bei einer reinen IPv4-Firewall kann der Admin einfach alle Pakete in der »INPUT« – und »OUTPUT« -Kette verwerfen, wenn er nicht übers Netz auf das Firewallsystem zugreifen muss. Tut er dies auch bei IPv6, ist aber auch keine Kommunikation mehr über die Firewall möglich.

Das hängt damit zusammen, dass statt ARP jetzt ja NDP zum Einsatz kommt. Jedes System, das über die Firewall kommunizieren soll, benötigt deren MAC-Adresse. Die IPv4-Firewall, die der Administrator mit IPtables verwaltet, ignoriert die ARP-Pakete auf Schicht 2 und lässt sie ungehindert passieren. Die MAC-Adressenauflösung funktioniert hier unabhängig von den IPtables-Regeln.

Bei IPv6 erfolgt die MAC-Adressenauflösung mit ICMPv6 auf OSI-Layer 3. Verwerfen die IP6tables-Regeln sämtliche Pakete, dann schließt das auch die ICMPv6-Nachrichten ein und die MAC-Adressenauflösung der Firewall funktioniert nicht mehr. Der Administrator muss folglich zumindest die ICMPv6-Nachrichten erlauben. Weil IPv6 das ICMPv6-Protokoll für sehr viele Zwecke einsetzt, gibt RFC 4890 [8] eine detaillierte Anleitung, die den Firewall-Administrator beim Aufsetzen der Regeln unterstützt.

Autokonfiguration

Eine sehr angenehme Eigenschaft des IPv6-Protokolls ist die zustandslose, automatische Konfiguration der IPv6-Adresse durch die einzelnen Systeme (Stateless Automatic Autoconfiguration, SLAAC, [9]). Welch Freude: Der Admin muss keinen DHCP-Server mehr aufsetzen, ein weiterer Single Point of Failure ist eliminiert. Wie oben erwähnt, erzeugen die Systeme aus ihrer MAC-Adresse einen Identifier. Mit ihm generieren sie zunächst eine Link-Local-Adresse, indem sie den Identifier an das Netz »fe80/64« anhängen (Abbildung 2). Schon mit der Adresse können Hosts im lokalen Netz kommunizieren, so wie das unter IPv4 mit APIPA (Windows, [10]) oder Avahi (bei Linux, [11]) unter dem Namen “Verbindungslokale IP-Adresse” via Zeroconf Networking [12] möglich war.

Abbildung 2: Die Link-Local-Adresse kann der Rechner selbst und ohne zusätzliche Hilfe erzeugen.

Anschließend senden Hosts via ICMPv6 Router-Solicitation-Nachrichten [1] aus, welche die Router mit ICMPv6-Router-Advertisements beantworten, die ein globales Präfix enthalten. Das System errechnet sich daraus eine globale IP-Adresse, indem es den Identifier an das globale Präfix anhängt (Abbildung 3). Antworten mehrere Router oder enthält das Advertisement mehrere Präfixe, erzeugt sich das System aber auch mehrere IPv6-Adressen.

Abbildung 3: Mit der Link-Local-Adresse kommuniziert der Client mit allen Routern im Netz über die Multicast-Adresse »ff02::2«.

Der Teufel steckt im Detail

Damit die Autokonfiguration funktioniert, müssen die Firewallregeln natürlich auch diese ICMPv6-Nachrichten zulassen. Diese Meldungen lassen sich aber nicht zustandsorientiert filtern, weil der Konfigurationsserver sie per Multicast verschickt hat. Dummerweise sind die Router-Solicitation- und -Advertisement-Nachrichten auch nicht authentifizierbar. Ein Angreifer kann also ebenfalls derartige Router-Advertisement-Nachrichten verschicken und damit Router erfolgreich spoofen. Die passenden Werkzeuge dafür existieren ebenfalls [13].

In der Praxis ist die zustandslose Autokonfiguration für moderne Netze ohnehin nicht wirklich geeignet. Die Entwickler haben es vor 15 Jahren versäumt, in der Autokonfiguration auch die Verteilung von DNS-Servern und weiteren Informationen zu berücksichtigen. Das RFC 5006 [14] rüstet dies für DNS-Server nach, wird aber leider noch nicht von allen Betriebssystemen unterstützt. Administratoren sind es aber ohnehin gewöhnt, über DHCP Informationen wie die DNS-Domäne, NTP-Server oder den PXE-Bootserver zu verteilen.

Unter IPv6 kommt der Admin somit um DHCP meist nicht herum, zumindest um dessen zustandslose Variante. Hier nutzt das Betriebssystem die Autokonfiguration, um selbst die IPv6-Adresse zu ermitteln, und erfragt über DHCP nur zusätzliche Informationen wie den DNS-Server und die DNS-Domäne. Windows Vista und 7 nutzen das automatisch, wenn im Router Advertisement das »OtherConfig« -Flag gesetzt ist.

DNS-Einträge per Stateful DHCP

Schließlich existieren auch Setups, in denen der DNS-Server die Hostnamen der Systeme nach deren Boot automatisch in sein Verzeichnis aufnehmen soll, wie das für Active-Directory-Landschaften typisch ist. Linux-Systeme tun sich damit traditionell schwerer, weshalb viele Administratoren bei IPv4 einen Umweg nehmen und den DHCP-Server berechtigen, die Informationen in der DNS-Zone dynamisch zu ändern.

Mit IPv6 kann der Administrator aber nicht die Autokonfiguration und das zustandslose DHCP nutzen, da der DHCP-Server die IPv6-Adresse des Clients kennen muss, um sie einzutragen. Ein Stateful-DHCP-Server muss her, der IPv6-Adressen aus einem Pool vergibt (Abbildung 4). Windows-Clients unterstützen das automatisch, wenn das Router Advertisement das »ManagedFlag« enthält. Für Linux-Systeme muss der Administrator entsprechende DHCP-Clients nachrüsten und konfigurieren. Redundanz ist hier geboten, denn ein Ausfall des DHCP-Servers hat in diesem Setup wieder die bekannten Auswirkungen aufs lokale Netz.

Abbildung 4: An der betagten IP-Ausgabe per DHCP führt trotz IPv6-Autokonfiguration selten ein Weg vorbei.

Es hat sich ausgesmurft

IPv6 hat den Broadcast abgeschafft – und das ist auch gut so. Einfache Amplification Attacks wie die SMURF-Attacke [15] sind jetzt nicht mehr möglich, auch Broadcast-Stürme gehören der Vergangenheit an. Das Neighbor-Discovery-Protokoll nutzt zwar ebenfalls Multicast-Adressen, um die MAC-Adresse des Kommunikationspartners zu ermitteln. Die Multicast-Gruppen sind jedoch so intelligent gewählt, dass die Kommunikation in vielen Fällen nur mit dem einen Rechner stattfindet, dessen MAC-Adresse ermittelt werden soll.

Auch viele andere Dienste, die in der Vergangenheit auf Broadcast-Kommunikation setzten, verwenden jetzt Multicast, DHCPv6 zum Beispiel die beiden well known Adressen »ff02::1:2« und »ff05::1:3« . Die erste ist eine Link-Local-Multicast-Adresse (»ff02« ), die für alle DHCP-Agenten (Server und Relays) reserviert ist. Die zweite Adresse ist als Site-Local-Multicast-Adresse (»ff05« ) DHCP-Servern vorbehalten.

Dank dieser Aufteilung schafft es IPv6, dass in den meisten Fällen nur noch die beteiligten Systeme die Pakete im IP-Stack bearbeiten. Für die IP-Adressen gelten dann auch entsprechende Multicast-MAC-Adressen. Im Vergleich zur Broadcast-Kommunikation unter IPv4 ergibt sich so eine deutlich geringerer Netzwerklast.

IPv6 unterstützt verpflichtend die IPsec-Protokollfamilie. Aber das verbessert nicht automatisch die Sicherheit: Ohne eine Konfiguration durch den Administrator findet nämlich keine Verschlüsselung des Datenverkehrs gemäß der IPsec-Protokolle statt. Deren bloße Anwesenheit erhöht die Sicherheit nicht, der Administrator spart sich lediglich die Software-Installation, die bei IPv4 meist zusätzlich notwendig war. Probleme bei der Interoperabilität und Fehler in der Konfiguration – wie sie [2] schildert – werden auch weiterhin auftreten.

Verfolger wird zum Verfolgten

In Anbetracht der damaligen Kenntnisse und für die vor 15 Jahren üblichen Netzwerke haben die Erfinder von IPv6 viel Kluges geleistet. Die Betriebssysteme und die Verwaltung der Netze im IPv4-Bereich haben sich aber in den letzten anderthalb Jahrzehnten weiterentwickelt, IPv6 dagegen kaum: Die Autokonfiguration dient nur zur Konfiguration der IP-Adresse – und bei entsprechend aktuellen Clients zur Vergabe des DNS-Servers. Für alle anderen Informationen bedarf es weiterhin eines DHCP-Servers.

DNS und Firewalls gewinnen an Bedeutung und ohne IPsec erhöht IPv6 auch die Sicherheit in einem Unternehmensnetz nicht. Im Gegenteil: In vielen Fällen kommt es deutlich stärker auf die Aufmerksamkeit des Administrators an, ob seine Clients geschützt oder weltweit erreichbar sind.