Internet Control Message Protocol

Aus Foxwiki

Das Internet Control Message Protocol (ICMP) kommt in TCP/IP-Netzwerken zum Einsatz, um Informationen über Probleme und den Status des Netzwerks auszutauschen oder Funktionen zu prüfen.

Historie

  • ursprünglich definiert von Jon Postel, einem Wegbereiter des Internets
  • Verabschiedung des ersten Standards im April 1981 als RFC 777
  • mehrmalige Aktualisierungen führten zur aktuellen Definition RFC 792

Grundlagen

Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebig lange Pfade. Da es sich nicht vermeiden läßt, daß bei dieser Datenübertragung Fehler auftreten, wurde mit ICMP eine Möglichkeit geschaffen, den Absender der Datagramme über etwaige Probleme zu informieren. Mögliche Probleme sind:

  • ein Gerät oder Dienst ist nicht ereichbar
  • einzelne Bits der Datagramme wurden auf dem Weg verfälscht
  • die Lebenszeit (TTL) eines Datagramms ist abgelaufen
  • die Pufferkapazität des Empfängers ist erschöpft

Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet. Die Daten werden jedoch in IP-Paketen transportiert, wie dies bei TCP & UDP geschieht, obwohl ICMP kein Transportprotokoll ist. ICMP nutzt somit das IP-Protokoll, als wäre es ein Protokoll einer höheren Schicht (im OSI-Modell), obwohl es eigentlich integraler Bestandteil des IP-Protokolls ist.

Die Paketstruktur

ICMP-Header

Der Header einer ICMP-Nachricht:

  • folgt direkt auf den IPv4-Header und wird dort an einer Protokollnummer erkannt
  • erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
  • besitzt eine Länge von 8 Byte, gefolgt von einem Datenabschnitt variabler Größe

Die ersten vier Bytes des Headers haben ein festgelegtes Format:

  • Mit dem ersten Byte wird der Typ der Nachricht kodiert.
  • Das zweite Byte enthält einen, vom jeweiligen Typ abhängigen Code
  • Das dritte und vierte Byte bilden eine Prüfsumme des Headers

Die folgenden (und letzten) vier Bytes des Headers sind vom Typ der ICMP-Nachricht abhängig.



Typ Typname Code Bedeutung
0 Echo Reply 0 Echo-Antwort
3 Destination Unreachable 0 Netzwerk nicht erreichbar
1 Host (Zielstation) nicht erreichbar
2 Protokoll nicht erreichbar
3 Port nicht erreichbar
4 Fragmentierung nötig, Don’t Fragment aber gesetzt
5 Route nicht möglich
13 Paket wird von der Firewall des Empfängers geblockt
4 Source Quench 0 Datagramm verworfen, da Warteschlange voll
5 Redirect Message 0 Benachrichtigung über eine Umleitung für das angegebene Netzwerk
1 Benachrichtigung über eine Umleitung für den ausgewählten Host
2 Umleitung für den angegebenen Dienst & das Netz
3 Umleitung für den angegebenen Dienst & den Host
8 Echo Request 0 Echo-Anfrage (Ping)
11 Time Exceeded 0 TTL (Time To Live, Lebensdauer) abgelaufen
1 Zeitlimit während der Defragmentierung überschritten

ICMP-Daten

Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, eine unterschiedlichen Inhalt und sind verschieden strukturiert. Oft wird der IP-Header wiederholt und im Anschluß daran die ersten 64 Bit des ursprünglichen Datagramms. Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.

Anwendungen

Am häufigsten wird ICMP zur Fehlerermittlung genutzt. Situationen, die eine ICMP-Fehlermeldung auslösen sind:

  • Ziel nicht erreichbar (Destination Unreachable): Dieser Fehler tritt auf, wenn der Zielrechner nicht mehr existiert, oder auf diesem kein passendes Protokoll gefunden werden kann. Tritt dieser Fall ein, wird der Absender entsprechend benachrichtigt.
  • Zeit überschritten (Time Exceeded)
  • Ungültige Parameter (Parameter Problem)
  • Senderate reduzieren (Source Quench)
  • Umleitung im Netzwerk (Redirect)
  • Prüfung auf die Erreichbarkeit eines Gerätes
  • Ermittlung des Pfades, den ein Datagramm durch das Netz beschreitet
  • Ermittlung der maximalen Größe des Datagramms auf diesem Pfad

Ping

Mit diesem Programm kann die Erreichbarkeit eines Netzwerkteilnehmers geprüft werden. Das Programm sendet die ICMP-Nachricht Echo Request an eine IP-Adresse & wartet daraufhin auf eine Antwort, dem Echo Reply. 

$ ping  google.de
PING google.de(ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003)) 56 data bytes
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=1 ttl=119 time=25.7 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=2 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=3 ttl=119 time=22.6 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=4 ttl=119 time=22.9 ms
64 bytes from ham02s17-in-x03.1e100.net (2a00:1450:4005:80b::2003): icmp_seq=5 ttl=119 time=23.1 ms
^C
--- google.de ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.572/23.416/25.650/1.130 ms

Trace Route

Mit dem Kommandozeilenbefehl traceroute kann der Pfad ermittelt werden, der von einem IP-Paket vom Sender zum Empfänger beschritten wird: 

$ traceroute google.de
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets
 1  fritz.box (192.168.100.1)  0.450 ms  0.593 ms  0.743 ms
 2  ber1005dihr001.versatel.de (62.214.63.92)  12.670 ms  12.750 ms  12.693 ms
 3  62.214.37.245 (62.214.37.245)  13.746 ms  13.787 ms  13.825 ms
 4  62.214.37.130 (62.214.37.130)  23.674 ms  23.716 ms 62.214.37.158 (62.214.37.158)  41.595 ms
 5  72.14.222.28 (72.14.222.28)  22.010 ms  22.063 ms 89.246.109.250 (89.246.109.250)  29.791 ms
 6  108.170.251.145 (108.170.251.145)  26.073 ms 108.170.252.18 (108.170.252.18)  37.669 ms 108.170.252.19 (108.170.252.19)  24.852 ms
 7  209.85.245.203 (209.85.245.203)  18.491 ms 209.85.242.79 (209.85.242.79)  44.834 ms 209.85.244.219 (209.85.244.219)  23.396 ms
 8  ham02s17-in-f3.1e100.net (172.217.19.67)  18.911 ms  17.654 ms  19.136 ms
  • Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden: Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens?
  • Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so daß überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.

Funktionsweise von traceroute:

  • Der Absender sendet eine ICMP-Nachricht vom Typ Echo Request an den Zielrechner. Von besonderer Bedeutung ist hierbei die Lebenszeit der Nachricht von eins (TTL=1).
  • Die nächste Station auf dem Weg zum Zielrechner vermindert den Wert von TTL um eins, so daß dieser Wert jetzt Null beträgt und die Nachricht daraufhin verworfen wird. Der Absender wird jedoch über diesen Vorgang informiert und erhält eine ICMP-Nachricht vom Typ time to live exceeded in transit, die auch die IP-Adresse der Zwischenstation enthält.
  • Der Absender verschickt daraufhin erneut ein Echo Request an den Zielrechner - dieses Mal jedoch mit einer TTL von zwei. Somit erreicht die Nachricht die zweite Zwischenstation auf dem Weg zum Ziel, bevor auch diese verworfen und der Absender benachrichtigt wird.
  • Der Absender versendet nun weitere Nachrichten vom Typ Echo Request - und erhöht jeweils den Wert der Lebenszeit - bis der Zielrechner erreicht wird und eine ICMP-Nachricht vom Typ Echo Reply erhalten wird.
  • Am Ende des Programmablaufs wird von traceroute eine nummerierte Liste erhalten, die die IP-Adressen der durchlaufenen Zwischenstationen und der dazugehörigen Laufzeiten enthält.


Missbrauch

Ping flood

Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge Echo Request-Nachrichten an das Opfer. Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so daß ein zufälliger Rechner mit den resultierenden Echo Reply-Antworten des Opfers bombardiert wird. Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes (Denial of Service) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird.

Ping of Death

Diese Variante eines Denial-of-Service-Angriffs sollte heute nicht mehr zum Ziel führen, da die dafür anfälligen Betriebssysteme inzwischen entsprechende Updates erhielten. Beim Ping of Death wurden ICMP-Nachrichten versendet, bei denen die zulässige Größe überschritten wurde, so daß diese für den Transport fragmentiert werden mussten. Das letzte Fragment einer solchen Nachricht enthielt dann eine Kombination der Werte für Offset und Fragmentgröße, die das Gesamtpaket größer werden ließen, als die erlaubten 65'535 Byte. Dies konnte zu einem Stapelüberlauf und somit zum Absturz des Zielrechners führen.

Kontrollfragen

?

A:

?

A:

?

A:

Abgerufen von „https://wiki.foxtom.de/index.php?title=Internet_Control_Message_Protocol&oldid=24635“