ICMP - Internet Control Message Protocol


By admin - Posted on 14 April 2009

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:

IP-Header
Typ
(8)
Code
(8)
Prüfsumme

(16)

nicht genutzte
Parameter
(32)
Informationen

(variabel, 32*N)

Abbildung 1: Format einer ICMP-Nachricht

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).

Messagetype Messagecode Name Bedeutung
0   Echo Reply Antwort auf einen Echo Request
3   Destination Unreachable Nachricht wird ausgelöst, wenn die Verbindung
zu einem adressierten Netzwerk, Rechner oder Dienst nicht hergestellt
werden kann.
  0 Network Unreachable Keine Route zum Netzwerk
  1 Host Unreachable Keine Route zum Zielrechner (down?)
  2 Protocol Unreachable Protokoll auf dem Zielrechner nicht verfügbar
  3 Port Unreachable Port auf dem Zielrechner nicht aktiv/nicht erreichbar
  4 Fragmentation Needed Fragmentierung erforderlich, aber “Don’t
Fragment”-Bit im IP-Header gesetzt
  5 Source Route failed Fehler beim Source-Routing
  6 Network Unknown Unbekanntes Netzwerk
  7 Host Unknown Unbekannter Rechner
  8 Host Isolated Zielrechner ist isoliert
  9 Network Prohibited Zugang zum Netzwerk verweigert
  10 Host Prohibited Zugang zum Zielrechner verweigert
  11 Network Unreachable TOS Netzwerk für gewünschten Servicetyp nicht
erreichbar
  12 Host Unreacheable TOS Zielrechner für gewünschten Servicetyp
nicht erreichbar
  13 Packet filtered Paketweiterleitung verweigert (Paketfilter-Firewall)
  14 Precedence violation
  15 Precedence cut off
4
Source Quench Nachricht wird ausgelöst, wenn ein Router überlastet
ist; Flusssteuerung auf der Ebene des Internet-Protokolls.
5
Redirect (change route) Nachricht wird ausgelöst, wenn ein Router feststellt,
dass es eine bessere (kürzere) Route gibt.
  0 Redirect Net Änderung einer Netzwerk-Route
  1 Redirect Host Änderung einer Hostroute
  2 Redirect Net for TOS Änderung einer Netzwerk-Route für einen
bestimmten Servicetyp
  3 Redirect Host for TOS Änderung einer Hostroute für einen bestimmten
Servicetyp
8
Echo Request Anforderung eines Echo Reply’s
9
Router Advertisement
10
Router Solicitation
11
Time Exceeded Nachricht wird von einem Router ausgelöst,
wenn der TTL-Wert eines IP-Datagramms abgelaufen ist und dieses verworfen
wurde.
  0 TTL Count exceeded TTL abgelaufen
  1 Fragment Reassemblation time exceeded Wartezeit auf IP-Fragmente abgelaufen
12
Parameter Problem Nachricht signalisiert Fehler im IP-Header..
13
Timestamp Request Anforderung eines Zeitstempels.
14
Timestamp Reply Antwort auf einen Timestamp Request
15
Information Request Anfrage nach der IP-Netzwerkadresse eines Netzes
16
Information Reply Anwort auf einen Information Request
17
Address Mask Request Anfrage nach der Subnetzmaske eines Netzes
18
Address Mask Reply Antwort auf einen Address Mask Request

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.

Hallo. Super Seite. Ich habe mal eine spezielle Frage zu ICMP. Wenn in einem Web-Server der TCP-IP Stack abgestürzt ist und ein Rechner der den Web-Server erreichen möchte bekommt einen ICMP Fehlercode. Ich frage mich nur welchen er dann bekommt? Ist es der Code 2, weil das TCP/IP Protocol nicht mehr erreichbar ist oder Code 3 für den Port für TCP/IP? Danke für die Hilfe. Viele Grüße

Sorry, kann ich Dir keine Hilfreiche Antwort geben.

Studium liegt leider schon ein Wenig zurück

Gruß

Diese Frage beschäftigt mich auch da diese in den Lernaufgaben des ILS Fernstudiums zum Netzwerker LAN vorkommt. Ich selbst bin der Meinung das der ICMP mit dem Code 2 antworten wird, da der TCP/IP Stack auf dem Web-Server nicht mehr zur Verfügung steht. 

Oder hast Du schon eine konkrete Antwort auf Deine Frage erhalten.

 

Gruss

Stephan

Zwei Leute fragen die gleiche Frage.

Da werde ich bis zum Wochenende dochmal die Unterlagen rausholen und schauen ob ich die korrekte Lösung finden kann.

Gruß

Kommentar hinzufügen

Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
CAPTCHA
Diese Frage dient dazu festzustellen, ob Sie ein Mensch sind und um automatisierte SPAM-Beiträge zu verhindern.
By submitting this form, you accept the Mollom privacy policy.

Get Firefox!
follow me on twittercounter