ICMPv6

Mit IPv6 sind diverse neue Kommunikationsformen hinzugekommen. Somit empfiehlt es sich dringend, diese Kommunikation auch in den Firewall-Regeln zu berücksichtigen. Dazu zählt insbesondere ICMPv6 mit und ohne Autoconfiguration sowie Path-MTU-Discovery. ICMPv6 ist bei IPv6 integraler Bestandteil und damit obligatorisch – im Gegensatz zu IPv4, wo ICMP(v4) optional ist. ICMPv6 realisiert verschiedene, elementare Kommunikationsprozesse bei IPv6: Neighbor Discovery (ICMPv6-Typen 135 und 136), Router Discovery (ICMPv6-Typen 133 und 134) und Path-MTU-Discovery (ICMPv6-Typ 2) Während Neighbor Discovery und Router Discovery nur für die INPUT- und OUTPUT-Chains interessant sind, müssen andere ICMPv6-Typen für einen reibungslosen Betrieb auch in der FORWARDING-Chain erlaubt werden. Insbesondere Typ 2 (Packet too big) ist notwendig für den Path-MTU-Discovery-Prozess (PMTU). Danach ermittelt ein Absender die kleinste MTU auf dem Weg zum Ziel, um die IPv6-Pakete in ihrer Größe entsprechend anzupassen. Dies ist deswegen essenziell, weil bei IPv6 die Router Pakete nicht mehr fragmentieren – dies geschieht nur noch durch den Absender.

Um die PMTU zu ermitteln, werden Pakete mit der maximalen Größe versendet (zum Beispiel 1500 Bytes im Ethernet). Stellt ein Router auf dem Pfad zum Zielsystem fest, dass das Paket für das nächste Segment, über das die Route verläuft, zu groß ist, verwirft er es und meldet einen ICMPv6-Typ 2 (Packet too big) an den Absender. In dieser Meldung steht der Wert für die MTU, die überschritten wurde. Dementsprechend passt der Absender die Paketgröße an. Wird diese Rückmeldung geblockt, kann es passieren, dass die Kommunikation zu bestimmten Systemen gar nicht möglich ist, da der Absender nicht wissen kann, dass sein Paket verworfen wurde.

Weitere ICMPv6-Typen, die meist erwünscht sind und nicht geblockt werden sollten, betreffen Problemmeldungen: Typ 1 (Destination unreachable), Typ 3 (Time exceeded) und Typ 4 (Parameter problem). Zumindest aus dem Internet sollten diese ICMPv6-Typen in der Regel ebenfalls erlaubt werden. Doch auch Typen, die Informationen austauschen, sind häufig erwünscht: Multicast Listener Discovery (130, 131 und 132, INPUT und OUTPUT) und Ping (128 und 129, INPUT, OUTPUT und FORWARDING).

Wollen Sie dem Protokoll ICMPv6 keine Generalvollmacht ausstellen und es allgemein erlauben, kommen Sie daher um einige Detail-Regeln nicht herum, die Listing 2 zeigt.

01 # Problem-Rueckmeldungen
02 ip6tables -A INPUT -p icmpv6 --icmpv6-type 1 -j ACCEPT
03 ip6tables -A INPUT -p icmpv6 --icmpv6-type 2 -j ACCEPT
04 ip6tables -A INPUT -p icmpv6 --icmpv6-type 3 -j ACCEPT
05 ip6tables -A INPUT -p icmpv6 --icmpv6-type 4 -j ACCEPT
06 ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 1 -j ACCEPT
07 ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 2 -j ACCEPT
08 ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 3 -j ACCEPT
09 ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 4 -j ACCEPT
10
11 # Router und Neighbor Discovery ein- und ausgehend
12 ip6tables -A INPUT -p icmpv6 --icmpv6-type 133 -j ACCEPT
13 ip6tables -A INPUT -p icmpv6 --icmpv6-type 134 -j ACCEPT
14 ip6tables -A INPUT -p icmpv6 --icmpv6-type 135 -j ACCEPT
15 ip6tables -A INPUT -p icmpv6 --icmpv6-type 136 -j ACCEPT
16 ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 133 -j ACCEPT
17 ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 134 -j ACCEPT
18 ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 135 -j ACCEPT
19 ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 136 -j ACCEPT
20
21 # Ping-Request an Firewall aus LAN und DMZ
22 ip6tables -A INPUT ! -i $WAN_IF -p icmpv6 --icmpv6-type 128 -j ACCEPT
23 # Ping-Request von Firewall, LAN und DMZ
24 ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 128 -j ACCEPT
25 ip6tables -A FORWARD ! -i $WAN_IF -p icmpv6 --icmpv6-type 128 -j ACCEPT

Sind Multicast-Verbindungen erforderlich, müssen die entsprechenden ICMPv6-Typen ebenfalls berücksichtigt werden. Dies funktioniert analog zu den hier gezeigten Regeln. Es ist durchaus möglich, dass weitere ICMPv6-Typen in Ihrer Produktivumgebung wünschenswert oder erforderlich sind. Hierzu ist jedoch eine Einzelanalyse der jeweiligen Infrastruktur notwendig.

Zusammenfassung und Ausblick

In diesem Artikel wurde ein Basis-Regelwerk für eine IPv6-Firewall erstellt, auf dem Sie diverse umgebungsspezifische weitere Regeln aufbauen können. Viele Regeln gelten für beide Welten, IPv4 wie auch IPv6. Während sowohl die grundsätzlichen Konfigurationsschritte als auch die Syntax bei »ip6tables« für IPv6 im Vergleich zu »iptables« für IPv4 sehr ähnlich bleiben, sind doch bei IPv6 Besonderheiten zu berücksichtigen, die eine eigenständige Behandlung der Kommunikation erfordern.

Hierzu zählt insbesondere der Tunnel-Traffic und die ICMPv6-Problematik. Selbst in einer kleinen Umgebung kann das IP6Tables-Regelwerk bereits recht umfangreich werden. Somit stellt sich immer die Frage, ob die Regeln global oder auf Interfaces und Subnetze beziehungsweise Präfixe oder sogar einzelne Hosts angewendet werden sollen. Je genauer das Regelwerk filtern soll, desto aufwendiger wird es. Hierbei ist eine Grundproblematik zu beachten, die nicht IPv6-spezifisch ist: Ein komplexes Regelwerk provoziert Administrationsfehler. Manchmal ist daher weniger auch mehr.

Ein weiterer Aspekt, der bisher nicht angesprochen wurde, ist die Verwendung eigener Chains. So ist es in der Regel wünschenswert, dass die Firewall protokolliert, was ein- und ausgeht und was geblockt wurde. Dies geschieht durch die selbst erstellten Chains, in denen zunächst protokolliert wird und anschließend erst die Aktion, also in der Regel DROP oder ACCEPT, durchgeführt wird. In den Filterregeln wird dann auf die passenden Chains verwiesen. Dies entspricht »iptables« mit IPv4.

Autor

Eric Amberg ist seit vielen Jahren im Bereich IT-Infrastruktur als Trainer und Consultant tätig und verfügt über langjährige Projekterfahrung. Sein besonderer Fokus liegt auf Netzwerkthemen. In seinen Seminaren legt er großen Wert auf eine praxisnahe Schulung. Mehr Informationen sind unter http://www.atracon.de zu finden.