ICMP und IGMP

ICMP

Bereits 1981 beschrieb Jon Postel in RFC 792 das Internet Control Message Protocol. Später kamen Ergänzungen in den RFCs 950, 4884, 6633 und 6918 hinzu. Es dient vor allem zur Kommunikation von Fehlerzuständen, aber auch um Informationen zum Zustand des Netzwerks auszutauschen.

Als Firewall-Administrator muss ich den grundlegenden Aufbau von ICMP-Nachrichten kennen und wissen, welche Datagramme ich unbedingt durchlassen sollte, welche ich auf jeden Fall sperren kann und warum ich mich bei den restlichen für die eine oder andere Art der Behandlung entscheide.

ICMP-Pakete nutzen IPv4 zum Transport, haben also ebenfalls einen IP-Header. Im darauf folgenden ICMP-Header werden die Datagramme nach dem Typ der ICMP-Nachricht und einem zu dem Typ gehörenden Code unterschieden. Da viele ICMP-Nachrichten als Reaktion auf Probleme mit bestimmten Datagrammen generiert werden, enthalten sie oft im Anhang den Anfang des Datagramms, auf das sich die ICMP-Nachricht bezieht.

Diese Daten am Ende der ICMP-Nachricht können für versteckte Kommunikation verwendet werden, deshalb sollte ich ICMP-Datagramme nicht wahllos durchlassen. Ein weiterer Grund ist, dass die ICMP-Nachrichten selbst sehr viele Informationen über IP-Netze preisgeben.

Immer durchlassen sollte ich ICMP-Datagramme vom Typ 3 “Destination Unreachable” mit Code 4 “Fragmentation Needed”. Diese werden für die Path-MTU-Discovery bei TCP benötigt. Ein Blockieren dieser Nachricht führt nicht automatisch zum Blockieren aller TCP-Verbindungen, kann bei manchen Verbindungen aber Fehler hervorrufen, die für unerfahrene Administratoren schwer einzugrenzen sind. Selbst wenn das Problem erkannt ist - zu geringe MTU auf einem Teilstück der Verbindung - ist die Abhilfe oft ineffizient.

Die RFCs 6633 und 6918 diskutieren ICMP-Nachrichten, die ich bedenkenlos sperren kann. Das sind ICMP-Nachrichten, für die es keine weitverbreiteten Implementierungen gibt, deren Aufgaben anderweitig besser gelöst sind oder die eher schädlich als nützlich sind. Konkret kann ich die folgenden ICMP-Nachrichten unterdrücken:

  • Typ 4 “Source Quench” (Deprecated in RFC 6633): Dieser Typ diente der Signalisierung von Überlast bei Routern. Die Nachrichten erwiesen sich als ineffektives Mittel gegen Überlast und gelten bereits seit 1995 bei Routern als veraltet. Seit etwa 2005 berücksichtigt kaum noch ein Betriebssystem diese Nachrichten.
  • Typ 15 “Information Request” und Typ 16 “Information Reply”, Typ 17 “Address Mask Request” und Typ 18 “Address Mask Reply”, Typ 30 “Traceroute” bis Typ 39 “SKIP” (Deprecated in RFC 6918). Diese Typen sind in der Praxis technisch überholt und in genanntem RFC förmlich missbilligt. Dort steht auch eine Diskussion zu den einzelnen Typen.

Bleibt als dritte Gruppe die ICMP-Nachrichten, bei denen ich von Fall zu Fall entscheiden muss, ob ich sie durchlasse. Gehen wir diese der Reihe nach durch.

Typ 0 “Echo Reply” ist die Antwort zu Typ 8 “Echo Request”. Innerhalb meiner Netze will ich diese Datagramme durchlassen, weil damit einfache Tests auf Erreichbarkeit mit dem Programm ping möglich sind. Aus meinem Netz in andere Netze will ich das auch, wenn ich die Erreichbarkeit von Rechnern in diesen Netzen mit ping prüfen will. Dann lasse ich Typ 8 von innen (meinem Netz) nach außen (dem fremden Netz) und Typ 0 von außen nach innen zu. Will ich auch Rechner in meinem Netz von außen prüfen lassen, gebe ich die beiden Typen auch in der anderen Richtung frei, eventuell beschränkt auf bekannte Netze oder Adressen.

Bei Typ 3 “Destination Unreachable” gibt es außer Code 4 “Fragmentation needed and DF bit set”, den ich immer freigeben will, noch die Codes 0 “Network unreachable”, 1 “Host unreachable”, 2 “Protocol unreachable” und 3 “Port unreachable”, die Hinweise bei der Fehlersuche im Netz liefern. Diese will ich im internen Netz auf jeden Fall haben. Von außen nach innen will ich diese Nachrichten auch. Von innen nach außen will ich diese Nachrichten aber höchstens an jemand senden, der mein Netz analysieren darf. Wer das ist, sollte in einer Policy festgelegt sein.

Code 5 “Source route failed” tritt nur bei Source Routing auf. Verwende ich dieses nicht, kann ich getrost auch die ICMP-Nachrichten sperren.

Code 13 “Administratively prohibited” wird von Firewalls generiert. Das ist eine klare Ansage an jemanden, der probiert, ob bestimmte Rechner oder Dienste erreichbar sind. Es hat den Vorteil, dass Verbindungsversuche von normalen Programmen sofort beendet werden, die bei einfachem Verwerfen der Anfragen automatisch weitere Versuche unternommen hätten. Der Mehrwert dieser ICMP-Nachricht für einen Angreifer, der systematisch Netzwerkadressen ausprobiert, ist gering. Bei einer großen Anzahl derartiger Tests sollte ich allerdings ein Rate-Limit aktiviert haben, insbesondere bei einer asymmetrischen Anbindung. Wichtig ist, dass diese Nachrichten nur vom Border-Gateway generiert und nicht durchgeleitet werden, da sonst die TTL Informationen zur internen Netzwerkstruktur preisgibt.

Nachrichten vom Typ 5 “Redirect” werden regulär vom Router an Hosts in einem direkt angeschlossenen Netz gesendet, wenn diese für bestimmte Verbindungen ein anderes Gateway verwenden soll. Ein Host sollte diese Nachrichten von seinem Default-Gateway akzeptieren, wenn es mehrere Router in dem Netzsegment gibt. Gibt es nur ein Gateway, sollten Hosts diese Nachrichten ignorieren.

Typ 8 hatte ich bereits bei Typ 0 abgehandelt.

Typ 9 “Router Advertisement” und Typ 10 “Router Solicitation” benötige ich nur, wenn die Hosts in einem Netzsegment ihr Gateway nicht kennen. Kann ich die Hosts auf andere Art konfigurieren, benötige ich diese Nachrichten nicht. Das Problem mit diesen beiden Typen und Typ 5 ist, dass ein Rechner damit Datenverkehr auf sich umleiten und dann MITM-Angriffe gegen andere Rechner ausführen kann. Aus diesem Grund muss ich, wenn ich mit solchen Angriffen rechne, mein Netz nicht nur mit Paketfiltern schützen, sondern auch mit IDS auf Anomalien überwachen. Das ist aber nicht Thema dieses Buches.

Typ 11 “Time Exceeded” wird zum Beispiel vom traceroute Programm ausgewertet, um die Topologie eines Netzes zu erkunden. Innerhalb meiner eigenen Netze will ich das in den meisten Fällen, weil es bei der Fehlersuche helfen kann. Von außen nach innen will ich diese ICMP-Nachrichten auch, von innen nach außen nicht, wenn ich die Struktur meines internen Netzes nicht preisgeben will.

Typ 12 “Parameter Problem” kann bei der Fehlersuche helfen. Es verweist auf Probleme mit dem ursprünglich gesendeten Datagramm. Nach außen will ich diese Information nicht geben, weil sie Eigenschaften des IP-Stacks auf dem sendenden Rechner preisgeben.

Typ 13 “Timestamp Request” und Typ 14 “Timestamp Reply” können zur Synchronisation der Uhren von Rechnern verwendet werden. Wenn andere Protokolle für die Synchronisation der Uhren verfügbar sind, sehe ich kein Problem darin, diese Datagramme zu sperren.

IGMP

Das Internet Group Management Protocol ermöglicht die Verwaltung von IPv4-Multicast-Gruppen. Die Gruppen werden dabei in den Routern verwaltet, an denen die Empfänger angeschlossen sind. Es gibt drei Versionen von IGMP:

  • IGMPv1 (RFC 1112) erlaubt einem Host, einer Gruppe beizutreten. Seine Mitgliedschaft erlischt automatisch nach einem Timeout, wenn er sie nicht erneuert.
  • Mit IGMPv2 (RFC 2236) kann ein Host eine Gruppe mit einer “Leave Group” Nachricht verlassen, so dass ein Router eher mitbekommen kann, ab wann er Datagramme für eine Gruppe nicht mehr senden braucht.
  • ICMPv3 (RFC 3376) erlaubt es, Multicast-Gruppen mit bestimmten Quellen beizutreten.

Üblicherweise verwaltet der IP-Stack des Routers die Mitgliedschaft in Multicast-Gruppen. Als Firewall-Administrator entscheide ich lediglich, ob ich Multicast über Router überhaupt zulasse oder nicht.

Einen Sonderfall stellt Multicast-DNS (mDNS) dar. Dieses ist beschränkt auf das lokale Netzsegment und wird unter anderem von Bonjour verwendet, der automatischen Netzwerk-Konfiguration von Apple-Rechnern. Normalerweise habe ich bei einem Paketfilter nichts mit diesem Protokoll zu tun, da es nicht geroutet wird. Betreibe ich meinen Paketfilter jedoch als Bridge, dann muss ich mich entscheiden, ob ich Bonjour darüber unterstützen will oder nicht.

Multicast-DNS verwendet die Adresse 224.0.0.51 bei IPv4 sowie FF02::FB bei IPv6 und den UDP-Port 5353. Im Gegensatz zum normalen DNS, bei dem die Antworten von einer überschaubaren Anzahl von DNS-Servern kommen können, antwortet bei mDNS üblicherweise der Rechner, der den entsprechenden Record für sich beansprucht. Das muss ich berücksichtigen, wenn ich mDNS regulieren will.

Will ich einzelne Gruppen oder Quellen sperren, muss ich die IGMP-Nachrichten analysieren und selektiv sperren.

Up next

ICMPv6 für den Firewall-Administrator