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:
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:
- Time Exceeded. Dieser Dienst wird ausgelöst, wenn der
angegebene Zeitwert (TTL) eines IP-Datagramms abgelaufen ist und der
Rechner dieses Datagramm verworfen hat. - Parameter Unintelligible. Der Zielhost kann diesen Dienst
ansprechen, falls er Probleme hat, einen Teil des IP-Headers zu bearbeiten. - 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. - 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. - 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). - 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. - Timestamp. Mit dem Zeitstempeldienst können Hosts oder
Gateways Verspätungen im Datenverkehr erkennen. - 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. - 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:
- können (gefälschte) ICMP-Nachrichten gezielt zur Auslösung
von Funktionsstörungen benutzt werden, - können allgemeine Implementierungsfehler in TCP/IP-Stacks ausgenutzt
werden, wobei der Urheber gespoofter Pakete schwer zu ermitteln ist, - 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. - 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:
- 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: - Destination Unreachable (ggf. beschränkt auf die Codes 0-4 und
13) - Source Quench (könnte gesperrt werden, was aber zu Störungen
bei stark belasteten Verbindungen führen kann) - Time Exceeded
- 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:
- Destination Unreachable (ggf. beschränkt auf die Codes 0-4)
- Time Exceeded (nur, wenn der Paketverkehr im inneren Netzwerk eventuell
über weitere Router geleitet wird) - 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:
- Destination Unreachable (ggf. beschränkt auf die Codes 0-4 und
13) - Source Quench (könnte gesperrt werden, was aber zu Störungen
bei stark belasteten Verbindungen führen kann) - Time Exceeded
- 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.
- Login to post comments
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ß