ICMP - Internet Control Message Protocol

1.1 Internet Control Message Protocol (ICMP)

1.1.1 Einsatzumgebung

Das Internet Control Message Protocol [RFC 792] hat die Aufgabe, Fehler-
und Diagnoseinformationen für IP zu transportieren. Es wird intern
von IP, TCP oder UDP angestoßen und verarbeitet. Auf der Benutzerebene
kann es zum Beispiel durch den Befehl ping angesprochen werden. Es
kommt zum Einsatz, wenn

• Datagramme nicht ausgeliefert werden können,
• ein Gateway Datenverkehr über eine kürzere Route leitet
  oder
• ein Gateway nicht genügend Pufferkapazität besitzt, um
  eine Protocol Data Unit (PDU) zu halten und weiterzuleiten.

Mit Hilfe von ICMP wird der Absender benachrichtigt, wenn ein Empfänger
nicht erreichbar ist. Ferner verwaltet oder erstellt ICMP eine zeitkritische
Nachricht, falls die Lebensdauer eines Datagramms ausläuft. Außerdem
führt es gewisse Editorfunktionen aus, um zu bestimmen, ob der IP-Header
fehlerhaft oder unverständlich ist. Die wesentliche Charakteristika
von ICMP sind:

• IP verpackt die ICMP-Dateneinheiten in IP-Datagramme, um sie über
  das Internet zu transportieren.
• IP verwendet ICMP, um Fehlermeldungen zu generieren.
• ICMP macht IP nicht verlässlich („reliable“). Es
  hat nur die Funktion, Fehler mitzuteilen.
• ICMP berichtet über Fehler in IP-Datagrammen, jedoch nicht in
  ICMP-Dateneinheiten selbst. Anderenfalls wären Endlosschleifen
  in der Fehlermitteilung möglich.
• Werden IP-fragmentierte Datagramme verwendet, so berichtet ICMP nur
  über Fehler des ersten empfangenen Fragments des Datagramms.

1.1.2 Dienste von ICMP

ICMP bietet als Dienstleistung Fehler- und Statusmeldungen an. Es besitzt
folgendes Paketformat:

Folgende Meldungen bzw. Meldungsklassen stehen zur Verfügung:

1. Time Exceeded. Dieser Dienst wird ausgelöst, wenn der
   angegebene Zeitwert (TTL) eines IP-Datagramms abgelaufen ist und der
   Rechner dieses Datagramm verworfen hat.
2. Parameter Unintelligible. Der Zielhost kann diesen Dienst
   ansprechen, falls er Probleme hat, einen Teil des IP-Headers zu bearbeiten.
3. Destination Unreachable. Dieser Dienst wird von einem Gateway
   oder dem Zielhost benutzt, falls das Gateway das in der IP-Zieladresse
   angegebene Netzwerk bzw. den Zielhost nicht erreichen kann oder auf
   dem Zielhost ein Protokoll höherer Schicht nicht verfügbar
   oder ein Port nicht erreichbar ist. Das Codefeld enthält eine nähere
   Information über die Fehlerursache.
4. Source Quench. Dieser Dienst bietet eine einfache Form einer
   Flusssteuerung durch ein Gateway und wird benutzt, wenn eine Maschine
   unzureichenden Pufferplatz hat, um ankommende Nachrichten zu speichern.
   Wird dadurch ein Datagramm fallengelassen, so sendet das Gateway die
   Nachricht Source Quench zu demjenigen Host, der das Datagramm erzeugt
   hat. Sie wirkt wie eine Aufforderung an den übertragenden Host,
   die Anzahl der Datagramme, die zum Zielhost gesendet werden, zu reduzieren.
   Der Dienst unterstützt also Flusssteuerung auf der Ebene des Internet-Protokolls.
5. Echo Request und Echo Reply. Dieser Dienst ist wertvoll,
   um den Zustand eines Netzes oder Internets zu bestimmen. Er kann zu
   jeder IP-Adresse gesendet werden, also auch zu einem Gateway. Der Empfänger
   wird aufgefordert, dem Absender zu antworten. Bleibt die Antwort aus,
   so weiß der Absender, dass Unregelmäßigkeiten aufgetreten
   sind. Dieser Dienst kann auch dazu benutzt werden, zu erkennen, ob ein
   Host aktiv oder verfügbar ist. In manchen Systemen heißt
   dieser Dienst ping. Dazu sendet
   ping ein echo request
   mit der IP-Adresse des Zielhosts und der eigenen IP-Absenderadresse.
   Wenn der Zielhost aktiv ist, sendet er ein echo reply zum Quellhost.
   Dabei wird der Inhalt des Datenfeldes, das mit dem echo request
   gesendet wird, mit dem echo reply unverändert zurückgesandt.
   Üblicherweise werden vom Absender eine Sequenznummer und ein Zeitstempel
   als Dateninhalt eingetragen. Das ermöglicht die Erkennung von Paketverlusten
   oder –vertauschungen und eine Messung der Zeitspanne zwischen
   dem Senden des Requests und dem Empfang des Echos, der sogenannten Round
   Trip Time (RTT).
6. Redirect. Dieser Dienst wird von Gateways benutzt. Die ICMP-Nachricht
   wird zum Quellhost gesendet und signalisiert diesem, dass eine bessere
   (kürzere) Route verfügbar ist.
7. Timestamp. Mit dem Zeitstempeldienst können Hosts oder
   Gateways Verspätungen im Datenverkehr erkennen.
8. Information Request und Information Reply. Durch diesen
   Dienst kann ein Host die IP-Adresse des Netzes bestimmen, mit dem er
   verbunden ist. Dieser Dienst wurde aber weitgehend durch das Reverse
   Address Resolution Protocol (RARP) ersetzt.
9. Address Mask. Mit diesem Dienst kann ein Host die benutzte
   Subnetzmaske auf dem lokalen Netz ermitteln.

In der folgenden Tabelle sind alle ICMP-Nachrichtentypen und –codes
zusammengestellt (vgl. RFC 1700).

1.1.3 Protokolldatenstruktur

Das Format der ICMP-Nachrichten ist in dargestellt. ICMP-Nachrichten
werden im Benutzerteil der IP-Datagramme befördert. Das Protokollfeld
im IP-Header wird auf 1 gesetzt, um den Gebrauch von ICMP zu signalisieren.
Alle ICMP-Nachrichten beinhalten drei Felder:

• Das Typfeld, um den Typ der Nachricht anzugeben,
• das Codefeld, um den Typ der Fehler- oder Statusinformation zu beschreiben,
• ein Prüfsummenfeld.

Ferner beinhaltet die ICMP-Nachricht den Internet-Header und die ersten
64 Bits des IP-Paketes, das die ICMP-Nachricht verursacht hat, wenn es
sich um eine Fehlernachricht handelt.

1.1.4 Sicherheitsbedrohungen

ICMP als verbindungsloses Protokoll bietet eine Reihe von Missbrauchsmöglichkeiten,
die vor allem in Trojanischen Pferden und DoS- bzw. DDoS-Angriffen ausgenutzt
werden:

1. können (gefälschte) ICMP-Nachrichten gezielt zur Auslösung
   von Funktionsstörungen benutzt werden,
2. können allgemeine Implementierungsfehler in TCP/IP-Stacks ausgenutzt
   werden, wobei der Urheber gespoofter Pakete schwer zu ermitteln ist,
3. können alle ICMP-Nachrichten im Datenfeld Informationen übertragen,
   auch wenn diese Informationen keinerlei Zusammenhang zur ICMP-Nachricht
   aufweisen; das kann zum Tunneln von Paketfilter-Firewalls ausgenutzt
   werden.
4. Die folgenden Abschnitte beschreiben verschiedene Angriffsmöglichkeiten
   und bekannte Angriffe.

1.1.4.1 Time-to-Live-Exceeded, Redirect, Destination Unreachable, Source
Quench

Bedrohung: Denial-of-Service
Grundsätzlich versenden einige ICMP-Implementierungen unnötige
Status- und Fehlermeldungen, was zu einem erhöhten Datenverkehrsaufkommen
führt.

Viele ICMP-Nachrichten, die einen Host erreichen, sind nur für bestimmte
Verbindungen relevant oder durch ein bestimmtes Paket ausgelöst.
In diesen Fällen finden sich der IP-Header und die ersten 64 Bit
des IP-Rumpfes im Informationsteil der Nachricht wieder. Dies soll die
Auswirkungen der ICMP-Nachricht begrenzen. so sollte sich eine Redirect-
oder Destination Unreachable-Nachricht lediglich auf eine bestimmte
Verbindung beziehen. Jedoch nutzen alte ICMP-Implementierungen diese zusätzliche
Information nicht. Werden solche Nachrichten empfangen, so wirken sie
auf alle Verbindungen zwischen den beteiligten Hosts. Dies gilt selbst
dann, wenn die Nachricht durch eine Firewall erzeugt wurde, die den Verkehr
auf dem gewünschten Zielport filtert. Eine Firewall sollte daher
vermeiden, ICMP-Nachrichten zu erzeugen, die möglicherweise bestehende
legitime Verbindungen mit der Quelle des Paketes abbrechen. Es existieren
sogar Programme, die mit Hilfe von ICMP-Nachrichten Verbindungen kappen.

Die Meldung Source Quench dient zur Reduzierung der Datenrate und
kann ebenfalls für eine Denial-of-Service-Attacke benutzt werden,
indem legitime Verbindungen „ausgebremst“ werden.

Auch die Meldung Time to Live Exceeded eignet sich für eine
Denial-of-Service-Attacke: Sie signalisiert ein Routing-Problem, was in
der Regel zu einem Schließen der Verbindung führt.

1.1.4.2 Ping Flooding

Bedrohung: Denial-of-Service Ping Flooding stellt eine einfache brute-force DoS-Attacke dar: Der Angreifer
sendet eine „Flut“ von ICMP-Paketen an die Zielmaschine. Besitzt
der Rechner des Angreifers einen Netzwerkanschluss mit größerer
Bandbreite als der Zielrechner, so kann der Zielrechner keine Datenpakete
mehr ins Netzwerk senden.
Anstelle von ICMP Echo Requests („Ping“) können auch
andere ICMP-Nachrichtentypen verwendet werden.

1.1.4.3 Smurf

Bedrohung: Denial-of-Service

Die als „Smurf“ bekannte Attacke stellt eine Kombination von
Ping Flooding und IP-Spoofing dar: Der Angreifer sendet ICMP Echo Requests
(„Ping“) an einen anderen Rechner, wobei er seine Absenderadresse
fälscht und durch die des Zielrechners ersetzt. Der quasi als Relaisstation
fungierende Rechner beantwortet die Echo Requests mit Echo Replies, die
an die Zielmaschine gesendet werden und diese „fluten“. Der
Angreifer ist schwieriger zu orten als beim einfachen Ping Flooding, da
die Pakete vom Zielsystem aus nur zur Relaisstation zurückverfolgt
werden können.

Eine für den Angreifer besonders effiziente Form des Smurf-Angriffes
besteht in der Verwendung einer Broadcastadresse als Absender- oder Zieladresse:
Ist die Absenderadresse der gefälschten Echo-Requests die Broadcastadresse
des anzugreifenden Netzwerkes, so wird der als Relaisstation fungierende
Rechner mit Echo Replies an diese Broadcastadresse antworten und damit
alle Rechner dieses Netzes gleichzeitig belasten. Ist die Empfängeradresse
der gefälschten Echo-Requests die Broadcastadresse eines Relais-Netzwerkes,
so werden alle Rechner dieses Netzwerkes mit Echo-Replies an die Zieladresse
antworten und dadurch dieses Ziel blockieren. Beide Varianten lassen sich
kombinieren.

1.1.4.4 Ping o’ Death

Bedrohung: Denial-of-Service

Sendet ein Angreifer ein ICMP-Paket mit der Größe des Nutzdatenpaketes
von mindestens 65.510 Bytes ab, so wird dies fragmentiert und zum Opfer
gesendet. Auf der Opferseite werden die Fragmente wieder zusammengesetzt.
Inklusive des ping-Headers ergibt dies eine Länge von mehr als 65.535
Bytes. Dies führt bei Treiber-Implementierungen, die einen Overflow
nicht abfangen, zu einem Systemabsturz [CERT-Advisory CA-96.26].

1.1.4.5 Redirect

Bedrohung: Eindringen

Die Meldung Redirect wird ausgesandt, wenn ein Gateway erkennt,
dass das Paket direkt an ein anderes Gateway geschickt werden kann, also
bisher ein Umweg benutzt wurde. Der kürzere Weg wird dann in die
Routing-Tabelle des Absenders eingetragen. Dies kann missbraucht werden,
um unerwünschte Routen zu konfigurieren und dadurch in Systeme eindringen
zu können. Nur Hosts (also Endsysteme), niemals jedoch Router sollten
Redirect-Nachrichten Glauben schenken, und auch nur dann, wenn
sie von einem Router im lokalen Netz stammen.

Eine Firewall sollte sicherstellen, dass die Meldungen Redirect
und Destination Unreachable nicht durch die Filter gelassen werden.
Bei den anderen Meldungen ist abzuwägen, ob die nach außen
gelieferte Information für einen Angriff missbraucht werden kann.

1.1.4.6 Subnet Mask Request, Information Request

Bedrohung: Eindringen

Durch einen ICMP Subnet Mask Request oder Information Request
versucht der Angreifer, Informationen über die interne Netzwerkstruktur
zu erlangen.

1.1.4.7 Tunneln

Bedrohung: Eindringen

Verschiedene Angriffe beruhen darauf, im Datenteil von ICMP-Paketen Informationen
zu übermitteln. Da der Datenteil der ICMP-Pakete von Paketfiltern
in der Regel nicht inspiziert wird, können dadurch Paketfilter-Firewalls
häufig überwunden werden.

Ein Beispiel ist das Trojanische Pferd Loki benutzt ICMP
Echo Requests und Echo Replies, um einen bidirektionalen
Kanal aufzubauen, über denen Kommandos empfangen und Ergebnisse,
z.B. Dateiinhalte, zurückgesendet werden können.

Grundsätzlich könnten hierfür, je nach Netzwerk- und Filterstruktur,
auch Nachrichten vom Typ Time Exceeded oder Destination Unreachable
verwendet werden.

Siehe auch http://www.w3.org/Security/Faq/wwwsf6.html

1.1.5 Filterungsmöglichkeiten

ICMP-Pakete enthalten keine Quell- und Ziel-Portnummern und auch kein
ACK-Bit, sondern ein einzelnes Feld für den ICMP-Meldungstyp. Somit
ist nur eine unzureichende Basis für eine Filterung vorhanden. Daher
sollten ICMP-Pakete abgewiesen werden. Ist dies nicht möglich oder
unerwünscht, so kann man anhand des ICMP-Meldungstyps Pakete ausfiltern.
Ein dynamisches Paketfilter kann ICMP-Nachrichten den zugehörigen
UDP- oder TCP-Paketen zuordnen und unerwartete Nachrichten verwerfen.
Eine Inspektion des Datenbereiches von ICMP-Nachrichten wäre wünschenswert,
wird aber bisher kaum unterstützt.

1.1.5.1 ICMP-Filterung bei einem reinen Client-Netzwerk

Die folgenden ICMP-bezogenen Regeln sollten für ein Paketfilter
eingestellt werden, welches ein inneres Netzwerk schützen soll, in
dem ausschließlich Client-Applikationen (Web-Browser, Mail-Clients,
...) Verbindungen mit dem äußeren Netzwerk herstellen:

1. Keine ICMP-Nachrichten von innen nach außen.
   Versuche, Nachrichten von innen nach außen zu senden, sollten
   protokolliert werden.

   Von außen nach innen müssen in der Regel die folgenden Nachrichten
   akzeptiert werden, um die Funktionalität zu gewährleisten:

2. Destination Unreachable (ggf. beschränkt auf die Codes 0-4 und
   13)
3. Source Quench (könnte gesperrt werden, was aber zu Störungen
   bei stark belasteten Verbindungen führen kann)
4. Time Exceeded
5. Parameter Problem (relativ selten, könnte ggf. auch gesperrt
   werden)

Ungewöhnliche Nachrichtentypen sollten protokolliert werden; das
sind insbesondere Redirect, aber auch Innformation Request und Reply,
Netmask Request und Reply, Timestamp Request und Reply, Router Advertisement
und Solicitation.

Um Fragment-Attacken auszuschließen, sollte das Paketfilter grundsätzlich
defragmentieren.

Es sollte ein dynamisches Paketfilter eingesetzt werden, welches ICMP-Nachrichten
den auslösenden TCP- oder UDP-Paketen zuordnen und von unerwarteten,
in der Regel gefälschten, unterscheiden kann.

1.1.5.2 ICMP-Filterung bei einem Server-Netzwerk

Die folgenden ICMP-bezogenen Regeln sollten für ein Paketfilter
gelten, welches ein inneres Netzwerk schützen soll, in dem Server-Applikationen
(Webserver, Mailserver, DNS-Server, ...) vom äußeren Netzwerk
aus angesprochen werden. Zu berücksichtigen ist, dass die Server
in der Regel selbst Verbindungen zu anderen Servern, beispielsweise DNS-
oder Mail-Servern sowie häufig auch dem Authentication-Service, herstellen
und sich dabei wie Clients verhalten.

Von innen nach außen müssen in der Regel folgende Pakete
akzeptiert werden:

1. Destination Unreachable (ggf. beschränkt auf die Codes 0-4)
2. Time Exceeded (nur, wenn der Paketverkehr im inneren Netzwerk eventuell
   über weitere Router geleitet wird)
3. Parameter Problem (relativ selten, könnte ggf. auch gesperrt
   werden)

Bei exakter Definition, welche Dienste auf welchem inneren Server aktiv
sind, kann das Paketfilter die Erzeugung der Destination Unreachable Nachrichten
übernehmen, so dass der ICMP-Paketfluss von innen nach außen
weiter eingeschränkt, im Extremfall sogar völlig unterbunden
werden kann.

Versuche, nicht erlaubte Nachrichten von innen nach außen zu senden,
sollten protokolliert werden.

Von außen nach innen müssen in der Regel die folgenden Nachrichten
akzeptiert werden:

1. Destination Unreachable (ggf. beschränkt auf die Codes 0-4 und
   13)
2. Source Quench (könnte gesperrt werden, was aber zu Störungen
   bei stark belasteten Verbindungen führen kann)
3. Time Exceeded
4. Parameter Problem (relativ selten, könnte ggf. auch gesperrt
   werden)

Ungewöhnliche Nachrichtentypen sollten protokolliert werden; das
sind insbesondere Redirect, aber auch Information Request und Reply, Netmask
Request und Reply, Timestamp Request und Reply, Router Advertisement und
Solicitation.

Um Fragment-Attacken auszuschließen, sollte das Paketfilter grundsätzlich
defragmentieren.

Es sollte ein dynamisches Paketfilter eingesetzt werden, welches ICMP-Nachrichten
den auslösenden TCP- oder UDP-Paketen zuordnen und von unerwarteten,
in der Regel gefälschten, unterscheiden kann.