Internet Control Message Protocol: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
'''ICMP''' ('''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol) tausche Statusinformationen der IP-Verbindung aus | '''ICMP''' ('''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol) tausche Statusinformationen der IP-Verbindung aus | ||
= Beschreibung = | '''topic''' kurze Beschreibung | ||
* Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebige Pfade. | == Beschreibung == | ||
== Installation == | |||
== Anwendungen == | |||
== Syntax == | |||
=== Optionen === | |||
=== Parameter === | |||
=== Umgebungsvariablen === | |||
=== Exit-Status === | |||
== Konfiguration == | |||
=== Dateien === | |||
== Sicherheit == | |||
== Dokumentation == | |||
=== RFC === | |||
=== Man-Pages === | |||
=== Info-Pages === | |||
== Siehe auch == | |||
== Links == | |||
=== Projekt-Homepage === | |||
=== Weblinks === | |||
=== Einzelnachweise === | |||
<references /> | |||
== Testfragen == | |||
<div class="toccolours mw-collapsible mw-collapsed"> | |||
''Testfrage 1'' | |||
<div class="mw-collapsible-content">'''Antwort1'''</div> | |||
</div> | |||
<div class="toccolours mw-collapsible mw-collapsed"> | |||
''Testfrage 2'' | |||
<div class="mw-collapsible-content">'''Antwort2'''</div> | |||
</div> | |||
<div class="toccolours mw-collapsible mw-collapsed"> | |||
''Testfrage 3'' | |||
<div class="mw-collapsible-content">'''Antwort3'''</div> | |||
</div> | |||
<div class="toccolours mw-collapsible mw-collapsed"> | |||
''Testfrage 4'' | |||
<div class="mw-collapsible-content">'''Antwort4'''</div> | |||
</div> | |||
<div class="toccolours mw-collapsible mw-collapsed"> | |||
''Testfrage 5'' | |||
<div class="mw-collapsible-content">'''Antwort5'''</div> | |||
</div> | |||
[[Kategorie:Entwurf]] | |||
= TMP = | |||
== Beschreibung == | |||
* Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebige Pfade. | |||
* Treten dabei Fehler auf, kann ICMP den Absender informieren | * Treten dabei Fehler auf, kann ICMP den Absender informieren | ||
| Zeile 13: | Zeile 61: | ||
Das ICMP-Protokoll wird als Teil der OSI-Schicht 3 betrachtet | 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. | * 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. | * 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. | ||
= Paketstruktur = | == Paketstruktur == | ||
== ICMP-Header == | === ICMP-Header === | ||
[[File:ICMP4.png|750px]] | [[File:ICMP4.png|750px]] | ||
| Zeile 74: | Zeile 122: | ||
|} | |} | ||
== ICMP-Daten == | === ICMP-Daten === | ||
* Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, einen unterschiedlichen Inhalt und sind verschieden strukturiert. | * Je nach Typ der ICMP-Nachricht haben die, sich dem ICMP-Header anschließenden Daten, einen unterschiedlichen Inhalt und sind verschieden strukturiert. | ||
* Oft wird der IP-Header wiederholt und im Anschluss daran die ersten 64 Bit des ursprünglichen Datagramms. | * Oft wird der IP-Header wiederholt und im Anschluss daran die ersten 64 Bit des ursprünglichen Datagramms. | ||
* Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht. | * Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht. | ||
= Anwendungen = | == Anwendungen == | ||
Oft wird ICMP zur Fehlerermittlung genutzt. | Oft wird ICMP zur Fehlerermittlung genutzt. | ||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
| Zeile 104: | Zeile 152: | ||
|} | |} | ||
== ping == | === ping === | ||
'''ping''' prüft die Verbindung zu einem Zielsystem, indem es einen '''Echo Request''' sendet und einen '''Echo Reply''' erwartet | '''ping''' prüft die Verbindung zu einem Zielsystem, indem es einen '''Echo Request''' sendet und einen '''Echo Reply''' erwartet | ||
| Zeile 122: | Zeile 170: | ||
[[File:Ping.png|750px|none]] | [[File:Ping.png|750px|none]] | ||
== Trace Route == | === Trace Route === | ||
Mit '''traceroute''' kann der Weg eine IP-Datagramms ermittelt werden | Mit '''traceroute''' kann der Weg eine IP-Datagramms ermittelt werden | ||
$ '''traceroute google.de''' | $ '''traceroute google.de''' | ||
traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets | traceroute to google.de (172.217.19.67), 30 hops max, 60 byte packets | ||
| Zeile 136: | Zeile 184: | ||
Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden | Das Programm kann zur Analyse von Netzwerkproblemen genutzt werden | ||
* Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? | * Nimmt ein Paket den erwarteten Weg, oder kommt es über Umwege dorthin? | ||
* Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens? | * Welche alternativen Wege beschreitet ein Paket beim Ausfall eines Netzknotens? | ||
Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so dass überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt. | Es werden die Laufzeiten zwischen den einzelnen Stationen (Hops) ermittelt, so dass überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt. | ||
=== Funktionsweise === | ==== Funktionsweise ==== | ||
[[File:ICMP-traceroute.png| 600px |right]] | [[File:ICMP-traceroute.png| 600px |right]] | ||
Der Absender sendet eine ICMP-Nachricht vom Typ ''Echo Request'' an den Zielrechner. | 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''). | * 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. | 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 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. | 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. | * 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. | 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. | ||
| Zeile 152: | Zeile 200: | ||
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. | 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. | ||
== Path MTU Discovery == | === Path MTU Discovery === | ||
* Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' zu einem entfernten IP-Netzwerk | * Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' zu einem entfernten IP-Netzwerk | ||
* Muss von jedem Router unterstützt werden | * Muss von jedem Router unterstützt werden | ||
| Zeile 161: | Zeile 209: | ||
* Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden. | * Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden. | ||
== Umleitung im Netzwerk == | === Umleitung im Netzwerk === | ||
[[File:ICMP-Redirect.png|600px|right]] | [[File:ICMP-Redirect.png|600px|right]] | ||
| Zeile 170: | Zeile 218: | ||
* Rechner '''B''' sendet fortan die Daten direkt zu Router '''R1''' (4) | * Rechner '''B''' sendet fortan die Daten direkt zu Router '''R1''' (4) | ||
= Sicherheit = | == Sicherheit == | ||
== Ping flood == | === Ping flood === | ||
* Bei der einfachsten Variante dieser Angriffsmethode sendet ein angreifender Rechner in schneller Folge ''Echo Request''-Nachrichten an das Opfer. | * 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 dass ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. | * Dabei wird die eigene Adresse (also die des Absenders) gefälscht, so dass ein zufälliger Rechner mit den resultierenden ''Echo Reply''-Antworten des Opfers bombardiert wird. | ||
* Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird. | * Ziel solcher Angriffe ist es, die Nichtverfügbarkeit eines Dienstes ('''D'''enial '''o'''f '''S'''ervice) herbeizuführen, da das Opfer mit der Beantwortung der ICMP-Anfragen beschäftigt wird. | ||
== Ping of Death == | === 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. | * 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. | * 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. | * 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. | ||
= Konfiguration = | == Konfiguration == | ||
= Links = | == Links == | ||
== Dateien == | === Dateien === | ||
== Man-Pages == | === Man-Pages === | ||
== Intern == | === Intern === | ||
== Weblinks == | === Weblinks === | ||
# https://tools.ietf.org/html/rfc792 | # https://tools.ietf.org/html/rfc792 | ||
=Kontrollfragen= | ==Kontrollfragen== | ||
<div class="toccolours mw-collapsible mw-collapsed"> | <div class="toccolours mw-collapsible mw-collapsed"> | ||
''Testfrage 1'' | ''Testfrage 1'' | ||
Version vom 4. August 2022, 10:43 Uhr
ICMP (Internet Control Message Protocol) tausche Statusinformationen der IP-Verbindung aus
topic kurze Beschreibung
Beschreibung
Installation
Anwendungen
Syntax
Optionen
Parameter
Umgebungsvariablen
Exit-Status
Konfiguration
Dateien
Sicherheit
Dokumentation
RFC
Man-Pages
Info-Pages
Siehe auch
Links
Projekt-Homepage
Weblinks
Einzelnachweise
Testfragen
Testfrage 1
Antwort1
Testfrage 2
Antwort2
Testfrage 3
Antwort3
Testfrage 4
Antwort4
Testfrage 5
Antwort5
TMP
Beschreibung
- Das Internet-Protokoll ermöglicht die Kommunikation von Geräten über beliebige Pfade.
- Treten dabei Fehler auf, kann ICMP den Absender informieren
Mögliche Probleme
- Gerät oder Dienst ist nicht erreichbar
- Header-Daten wurden 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.
Paketstruktur
ICMP-Header
Der ICMP-Header folgt direkt auf den IPv4-Header und wird dort an der Protokollnummer erkannt
- Erweitert den IP-Header und ist als integraler Bestandteil des IP-Protokolls zu sehen
- Länge: 8 Byte + Datenabschnitt variabler Größe
Format der ersten vier Bytes
- 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 vier Bytes 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) |
| 9 | Router Solicitation | 0 | Suche nach einem Router |
| 10 | Router Advertisement | 0 | Bekanntmachung eines Routers |
| 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, einen unterschiedlichen Inhalt und sind verschieden strukturiert.
- Oft wird der IP-Header wiederholt und im Anschluss daran die ersten 64 Bit des ursprünglichen Datagramms.
- Damit wird dem Zielrechner die Zuordnung der Nachricht ermöglicht.
Anwendungen
Oft wird ICMP zur Fehlerermittlung genutzt.
| Grund | Auslöser |
|---|---|
| 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
ping prüft die Verbindung zu einem Zielsystem, indem es einen Echo Request sendet und einen Echo Reply erwartet
$ 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 traceroute kann der Weg eine IP-Datagramms ermittelt werden
$ 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 dass überprüft werden kann, ob es auf dem Weg zum Ziel zu Engpässen oder Überlastungen kommt.
Funktionsweise
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.
Path MTU Discovery
- Ermittlung der Maximum Transfer Unit zu einem entfernten IP-Netzwerk
- Muss von jedem Router unterstützt werden
Ermittlung der MTU
- Der Sender generiert ein IP-Paket mit der MTU des lokalen Netzes und gesetztem Don't Fragment-Bit
- Wird auf dem Weg ein Transfernetz erreicht, dessen MTU überschritten wird, sodass dessen Router das Paket fragmentieren müsste, wird das Paket verworfen und der Absender durch eine ICMP-Nachricht vom Typ 3 Code 4 (Destination Unreachable,Fragmentation required, and DF flag set) benachrichtigt.
- Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden.
Umleitung im Netzwerk
Wird von einem Router bemerkt, daß es für ein IP-Paket einen schnelleren Weg zum Ziel gibt, kann er den Absender darüber informieren. Dies geschieht mit einer ICMP-Nachricht vom Typ Redirect:
- Rechner B möchte Daten an Rechner A versenden und sendet diese an seinen Standard-Router R2 (1)
- Router R2 übergibt die Daten an Router R1, der diese an den Zielrechner A weiterleitet (2)
- Router R2 erkennt jedoch, daß es für Rechner A günstiger wäre, sich gleich an Router R1 zu wenden und teilt ihm dieses durch eine ICMP-Nachricht vom Typ Redirect mit (3)
- Rechner B sendet fortan die Daten direkt zu Router R1 (4)
Sicherheit
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 dass 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.
Konfiguration
Links
Dateien
Man-Pages
Intern
Weblinks
Kontrollfragen
Testfrage 1
Antwort1
Testfrage 2
Antwort2
Testfrage 3
Antwort3
Testfrage 4
Antwort4
Testfrage 5
Antwort5