ICMPv6 für den Firewall-Administrator

ICMPv6 macht für IPv6, was ICMP für IPv4 macht und noch einiges mehr. So ist die Zuordnung von Link-Layer-Adressen (Adressen der OSI-Schicht 2), für die bei IPv4 die Protokolle ARP und RARP zuständig sind, Bestandteil von ICMPv6 und als Neighbor Discovery in RFC 4861 beschrieben. Die Verwaltung von Multicast-Gruppen, für die es bei IPv4 das Protokoll IGMP gibt, ist ebenfalls Aufgabe von ICMPv6.

RFC 4443 beschreibt das Protokoll. Für den Firewall-Administrator gibt es mit RFC 4890 “Recommendations for Filtering ICMPv6 Messages in Firewalls” handfeste Empfehlungen für die Behandlung von ICMPv6.

Konkret hat ICMPv6 die folgenden Aufgaben:

• Fehlermeldungen an den Absender von Datagrammen senden
• Verbindungen überprüfen
• das Netzwerk erkunden:
  • Nachbarn im gleichen Netzsegment finden und ihre IP- und Link-Layer-Adresse bestimmen
  • Die Erreichbarkeit von Nachbarn überwachen
  • Router finden und die Netzwerk-Konfiguration von diesen übernehmen
  • Informationen wie Netzwerkpräfixe und MTU von Routern an Hosts senden
  • Authentifizieren von Nachbarn mit SEND
  • Bestimmen der Path-MTU für Verbindungen
  • IPv6-Adressen für Link-Layer-Adressen bestimmen
  • Multicast-Gruppenmitgliedschaften verwalten
  • Multicast-Router finden
• Rekonfiguration
  • Weiterleitung zu anderen Routern mit Redirect-Nachrichten
  • Unterstützung der Umnummerierung von Netzen
• Unterstützung von Mobile IPv6
• experimentelle Erweiterungen

Klassifizierung von ICMPv6-Nachrichten

ICMPv6-Nachrichten können nach verschiedenen Kriterien klassifiziert werden. In RFC 4890 finden sich die folgenden:

• Fehler- und Informationsnachrichten

  ICMPv6-Nachrichten mit Typ 0 bis 127 sind Fehlermeldungen, die in den meisten Fällen erlaubt sein sollten. Nachrichten mit Typ 128 bis 255 sind Informationsnachrichten, die eher einer Policy unterliegen sollten.

• Adressen

  Die Absenderadresse einer ICMPv6-Nachricht ist üblicherweise eine Unicast-Adresse. Während der Autokonfiguration des Interfaces und bevor eine gültige IPv6-Adresse konfiguriert wurde, können ICMPv6-Nachrichten mit unspezifizierter Adresse [::] gesendet werden. Die Zieladresse ist bei Fehler-Nachrichten eine Unicast-Adresse, bei Informationsnachrichten kann es eine Unicast- oder Multicast-Adresse sein.

• Netzwerktopologie und Geltungsbereich der Adresse

  Einige ICMPv6-Nachrichten sind nur für den lokalen Link bestimmt, wie zum Beispiel bei der Neighbor Discovery, während andere über mehrere Links gesendet werden können, wie die meisten Fehlermeldungen.

• Rolle beim Aufbau und der Aufrechterhaltung von Kommunikation

  Neighbor Discovery und Stateless Automatic Address Configuration arbeiten mit ICMPv6 Paketen. Die ICMPv6-Nachricht mit Type 2 “Packet Too Big” sind entscheidend für eine erfolgreiche Verbindung über Pfade mit kürzerer MTU.

Sicherheitsüberlegungen

Während es bei IPv6 generell möglich ist, Datenpakete kryptographisch abzusichern, trifft das auf ICMPv6 nur bedingt zu. Dadurch, dass legitime ICMPv6-Nachrichten von beliebigen Hosts oder Routern im Internet kommen können, ist es nicht möglich, zu allen Sendern von ICMPv6-Nachrichten Security Associations aufzubauen.

Aus diesem Grund ist die Filterung von ICMPv6-Nachrichten der häufigste Weg, mit diesem Problem umzugehen. Dabei muss ich eine Balance finden zwischen dem Verwerfen von Datagrammen um die Site zu schützen und dem Zulassen von Datagrammen um sicherzustellen, dass effiziente Kommunikation möglich ist.

Wenn ich ICMPv6 mit einer Firewall kontrolliere, habe ich dabei die folgenden Sicherheitsbedenken im Sinn:

Denial of Service Attacken (DoS)

ICMPv6 kann auf zwei Arten für DoS verwendet werden: es können einfach übermäßig viele ICMPv6-Nachrichten geschickt werden oder es wird versucht, durch Konfigurationsnachrichten legitime Adressen ungültig zu machen oder Interfaces zu deaktivieren.

Probing

Angreifer können mit Datagrammen, die ICMPv6-Fehlermeldungen provozieren, die Topologie des Netzes erkunden und so Ziele für weitere Attacken finden. Dieser Ansatz ist durch den riesigen Adressraum von IPv6 allerdings nicht so effektiv wie bei IPv4. In RFC 4890 wird dieses Thema weiter ausgeführt.

Redirection

Durch Umleitung des Datenverkehrs kann ein Angreifer Man-in-the-middle-Angriffe aufsetzen. Diese Angriffe erfolgen häufig lokal, wenn der Angreifer bereits Zugang zum Netz hat.

Als Administrator muss ich einschätzen, ob die Effizienzverbesserung durch Redirect-Nachrichten das Risiko eines derartigen Angriffes wert ist. Bei dieser Entscheidung ist die Sicherheit der Verkabelung, des Gebäudes und der anderen Hosts im Netzwerk ebenso zu berücksichtigen, wie die Komplexität der Adressen und Routen.

Renumbering

Nachrichten zur Umnummerierung des Netzes können ein Netzsegment unerreichbar machen. Diese Nachrichten will ich auf jeden Fall am Border-Router filtern. RFC 2894 beschreibt das Verfahren.

Probleme durch ICMPv6-Transparenz

Da ICMPv6-Nachrichten in beiden Richtungen zugelassen werden müssen, können diese für verdeckte Kommnikationskanäle benutzt werden. Diesem kann ich mit Connection Tracking begegnen, um sicherzustellen, dass die ICMP-Nachrichten zu legitimen Datenverkehr gehören.

Empfehlungen zur Filterung

RFC 4890 teilt Filter-Regeln für ICMPv6 in zwei Klassen ein:

• Regeln für Datenverkehr, der die Firewall passiert
• Regeln für Datenverkehr, der an die Firewall gerichtet ist.

Innerhalb dieser Klassen werden die Regeln für ICMPv6 Datagramme kategorisiert in Regeln für Nachrichten, die

• nicht verworfen werden dürfen,
• nicht verworfen werden sollten, es sei denn, es gibt einen triftigen Grund,
• verworfen werden können, aber aus anderen Gründen sowieso nicht akzeptiert werden,
• entsprechend einer Richtlinie verworfen werden können oder nicht,
• immer verworfen werden sollten.

Generell sollten Firewalls, die als Bridge in einem Netzsegment arbeiten, link-lokale ICMPv6-Nachrichten beachten, während Firewall-Router diese einfach ignorieren können.

Eine Host-Firewall kann man sich als Spezialfall einer Firewall-Bridge vorstellen, die aus dem Netz nur Pakete für das eigene Interface durchläßt.

Empfehlungen für Transitverkehr

Unbedingt durchgehen sollten die folgenden Fehlernachrichten:

• Destination Unreachable (Typ 1), alle Codes
• Packet Too Big (Typ 2)
• Time Exceeded (Typ 3), Code 0
• Parameter Problem (Typ 4), Codes 1 und 2

Außerdem diese Nachrichten für Verbindungstests:

• Echo Request (Typ 128)
• Echo Reply (Typ 129)

Bei IPv4 werden die Nachrichten zur Verbindungstests oft gesperrt, um einen Netzwerk-Scan zu verhindern. Bei IPv6 ist das Risiko eines Netzwerk-Scans sehr viel geringer. In RFC 4890 wird das Thema ausführlicher betrachtet.

Die folgenden Fehlernachrichten sollten normalerweise nicht verworfen werden, wenn nicht gute Gründe für das Verwerfen sprechen:

• Time Exceeded (Typ 3), Code 1
• Parameter Problem (Typ 4), Code 0

Außerdem die folgenden Nachrichten zur Unterstützung von mobile IP (RFC 6275):

• Home Agent Address Discovery Request (Typ 144)
• Home Agent Address Discovery Reply (Typ 145)
• Mobile Prefix Solicitation (Typ 146)
• Mobile Prefix Advertisement (Typ 147)

Hier kann ich selektive Regeln verwenden, je nachdem, ob ich mobiles IP für eigene oder fremde Knoten unterstützen will.

Die folgenden Nachrichten verwirft ein Router sowieso, hier ist keine zusätzliche Maßnahme nötig:

Nachrichten zur Konfiguration und Auswahl des Routers (RFC 4620, 4861):

• Router Solicitation (Typ 133)
• Router Advertisement (Typ 134)
• Neighbor Solicitation (Typ 135)
• Neighbor Advertisement (Typ 136)
• Redirect (Typ 137)
• Inverse Neighbor Discovery Solicitation (Typ 141)
• Inverse Neighbor Discovery Advertisement (Typ 142)

Nachrichten für link-lokale Multicast-Empfänger (RFC 2710):

• Multicast Listener Query (Typ 130)
• Multicast Listener Report (Typ 131)
• Multicast Listener Done (Typ 132)

SEND Certificate Path Notification Messages (RFC 3791):

• Certification Path Solicitation (Typ 148)
• Certification Path Advertisement (Typ 149)

Nachrichten für Multicast-Router (RFC 4286)

• Multicast Router Advertisement (Typ 151)
• Multicast Router Solicitation (Typ 152)
• Multicast Router Termination (Typ 153)

Für die folgenden Datagramme sollte in einer Policy festgelegt sein, ob sie durchgelassen oder verworfen werden:

• Seamoby Experimental (Typ 150), siehe RFC 4065
• momentan nicht verwendete Fehlernachrichten (Typ 5-99, 102-126)
• momentan nicht verwendete Informationsnachrichten (Typ 154-199, 202-254)

Die folgenden Nachrichten sollten verworfen werden, wenn nicht triftige Gründe für das Weiterleiten sprechen:

• Node Information Query (Typ 139), siehe RFC 4620
• Node Information Response (Typ 140), siehe RFC 4620
• Router Renumbering (Typ 138), siehe RFC 2894
• Private Experimentation (Typ 100, 101, 200, 201), siehe RFC 4443
• Reserved for Expansion (Typ 127, 255), siehe RFC 4443

Empfehlungen für lokalen ICMPv6-Verkehr

Die folgenden Datagramme dürfen an Host-Firewalls nicht verworfen werden:

Fehlermeldungen (RFC 4443):

• Destination Unreachable (Typ 1), alle Codes
• Packet Too Big (Typ 2)
• Time Exceeded (Typ 3), Code 0
• Parameter Problem (Typ 4), Code 1 und 2

Nachrichten zur Verbindungsüberprüfung (RFC 4443):

• Echo Request (Typ 128)
• Echo Reply (Typ 129)

Nachrichten zur Konfiguration und Routerauswahl (RFC 3122, 4861):

• Router Solicitation (Typ 133)
• Router Advertisement (Typ 134)
• Neighbor Solicitation (Typ 135)
• Neighbor Advertisement (Typ 136)
• Inverse Neighbor Detection Solicitation (Typ 141)
• Inverse Neighbor Detection Advertisement (Typ 142)

Nachrichten für link-lokale Multicast-Empfänger (RFC 2710, 3810):

• Multicast Listener Query (Typ 130)
• Multicast Listener Report (Typ 131)
• Multicast Listener Done (Typ 132)
• Version 2 Multicast Listener Report (Typ 143)

SEND Certification Path Notification (RFC 3971):

• Certification Path Solicitation (Typ 148)
• Certification Path Advertisement (Typ 149)

Multicast Router Discovery (RFC 4286):

• Multicast Router Advertisement (Typ 151)
• Multicast Router Solicitation (Typ 152)
• Multicast Router Termination (Typ 153)

Die folgenden Datagramme sollten normalerweise nicht verworfen werden:

• Time Exceeded (Typ 3), Code 1
• Parameter Problem (Typ 4), Code 0

Die folgenden Datagramme werden sowieso verworfen, dafür ist keine besondere Aufmerksamkeit nötig:

• Router Renumbering (Typ 138), RFC 2894

Mobile IP-Nachrichten (RFC 6275):

• Home Agent Address Discovery Request (Typ 144)
• Home Agent Address Discovery Reply (Typ 145)
• Mobile Prefix Solicitation (Typ 146)
• Mobile Prefix Advertisement (Typ 147)

Diese experimentelle Nachricht wird verworfen, wenn das Protokoll nicht unterstützt wird:

• Seamoby Experimental (Typ 150), siehe RFC 4065

Die folgenden Datagramme sollten in einer Policy berücksichtigt werden:

Redirect-Nachrichten (RFC 4861) stellen ein erhebliches Sicherheitsrisiko dar. Als Administrator muss ich daher von Fall zu Fall entscheiden ob die Vorteile dieser Nachricht den potentiellen Schaden bei einem Missbrauch überwiegen.

• Redirect (Typ 137)

Falls ein Knoten den Node Information Dienst (RFC 4620) unterstützt, muss ich entscheiden ob und an welchen Schnittstellen er auf entsprechende Anfragen reagieren soll. Wenn der Dienst deaktiviert oder nicht vorhanden ist, werden die Anfragen ignoriert und es ist keine Filterung notwendig.

• Node Information Query (Typ 139)
• Node Information Response (Typ 140)

Gegenwärtig nicht definierte Fehlermeldungen

• ICMPv6-Typ 5-99, 102-126

Die Spezifikation von ICMPv6 besagt, dass unbekannte ICMPv6-Fehlermeldungen an das Protokoll der höheren Ebene weitergereicht werden soll. Dieses höhere Protokoll wird aus dem in der ICMP-Nachricht enthaltenen Anfang des auslösenden Datagramms bestimmt. Es besteht die Möglichkeit, dass diese Nachrichten für einen versteckten Datenkanal benutzt werden.

Der folgende Datenverkehr sollte verworfen werden, wenn nicht triftige Gründe für seine Verwendung gefunden werden:

• Private Experimentation (Typ 100, 101, 200, 201)
• Reserved for Expansion (Typ 127, 255), siehe RFC 4443
• momentan nicht verwendete Informationsnachrichten (Typ 154-199, 202-254)