Auf was kommt es an?

IPv6 bringt einen komplett eigenständigen Protokoll-Stack mit sich. In den meisten Fällen wird IPv6 parallel zu IPv4 im sogenannten Dual-Stack-Betrieb genutzt. Hier stellt sich zunächst die Frage, ob die vorhandene Firewall mit IPv6-Regeln ergänzt oder eine neue dedizierte IPv6-Firewall aufgebaut werden soll, zu der sämtlicher IPv6-Traffic geroutet wird. Der Vorteil einer separaten IPv6-Firewall ist die Unabhängigkeit von der IPv4-Infrastruktur. Damit ist es möglich, eine eigene, optimierte IPv6-Netzwerk-Infrastruktur aufzubauen und Altlasten der gewachsenen IPv4-Infrastruktur zu beseitigen. Dies ist allerdings aufwendig und nur in wenigen Umgebungen einfach zu realisieren.

Die Konfiguration einer ausgereiften IPv6-Netzwerk-Firewall erfordert fundiertes Know-how über IPv6. Zwar lassen sich einfache Regelwerke auch mit wenigen Zeilen erzeugen, jedoch bringen diese auch nur eingeschränkte Sicherheit beziehungsweise Funktionen. Da die Firewall bei IPv6 den einzigen Schutz für den Zugriff aus dem Internet darstellt, kommt ihr jetzt eine fundamentale Bedeutung zu. Konnte der Administrator bei IPv4 noch notfalls auf den Schutzmechanismus von NAT bauen, entfällt dies bei IPv6 in der Regel komplett.

Eine weitere Aufgabe ist die Konfiguration von Antispoofing-Regeln. Firewall-Regeln können möglicherweise umgangen werden, wenn der Angreifer Adressen fälscht, die erlaubt sind. Hier muss sichergestellt werden, dass nur gültige Adressen über die jeweiligen Interfaces kommunizieren.

Weiterhin nutzt IPv6 einige Kommunikationsformen, die ebenfalls berücksichtigt werden sollten. Allen voran die verschiedenen Tunnel-Mechanismen, wie 6to4, ISATAP oder Teredo. Hier wird IPv6 in IPv4-Paketen getunnelt und über das IPv4-Netzwerk übertragen. Dies ist oft unerwünscht, führt zu unnötigen Risiken und muss daher unterbunden werden – und zwar in der IPv4-Firewall!

Das Regelwerk vorbereiten

Die Konfiguration von »ip6tables« erfolgt in der Regel innerhalb eines Firewall-Skripts. Dieses kann beim Systemstart zum Beispiel über das Verzeichnis »/etc/rc.local« oder als eigenes Init-Skript aufgerufen werden. Aus Gründen der Flexibilität hat es sich bewährt, die Interfaces zunächst als Variablen anzulegen, um in den Regelzeilen darauf zu verweisen. Auch Netzwerke beziehungsweise Präfixe lassen sich in dieser Form definieren. Ändert sich ein Interface oder ein Subnetz-Präfix, reicht die einmalige Anpassung der Variablen.

# Interface-Definitionen
WAN_IF=eth1
LAN_IF=eth0
DMZ_IF=eth2
LAN_NET=2001:db8:1::/64
DMZ_NET=2001:db8:2::/64

Als nächstes setzen Sie die Firewall-Regeln komplett zurück, um alle vielleicht noch vorhandenen Regeln zu löschen. Hierzu dient die Option »-F« . Außerdem ist es erforderlich, eine sogenannte Policy festzulegen, also eine Default-Regel, die zutrifft, wenn keine andere Regel greift. Generell gilt für Firewalls: Alles, was nicht explizit erlaubt wird, ist verboten. Dementsprechend setzen Sie die Policy für alle drei Ketten (Chains):

# Das Regelwerk loeschen
ip6tables -F
# Eine Policy definieren
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP

Zu diesem Zeitpunkt ist überhaupt keine Kommunikation mehr von oder zu diesem System sowie durch das System hindurch möglich, nicht einmal Loopback-Traffic (Abbildung 3). Da aber gerade dies immer erlaubt sein sollte, fügen Sie eine Loopback-Regel ein:

Abbildung 3: Zu dicht: Beim aktuellen Zustand erlaubt die Firewall nicht mal mehr den Verkehr zum Localhost.

# Loopback-Kommunikation erlauben
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT

Ein weiterer wichtiger Schritt ist das Aktivieren von Stateful Inspection. Hierzu erlauben Sie alles, was zu einer vorhandenen Kommunikation gehört:

# Stateful Inspection aktivieren
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Für alle anderen Kommunikationsformen folgen nun entsprechende Abschnitte mit passenden Regeln.