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.