--- author: Carl Kittelberger date: 2018-03-01 title: "ITS: IP und ICMP" institute: "Ferdinand-von-Steinbeis Berufsschule" lang: de-DE babel-lang: ngerman babel-otherlangs: - english polyglossia-lang: name: german options: - spelling=new #subtitle: "Internet Protocol und Internet Control Message Protocol" #classoption: draft classoption: oneside colorlinks: true documentclass: report fontsize: 12pt logo: img/steinbeis.png mainfont: Arial papersize: a4 sansfont: Arial tables: true template: template.tex toc: true header-includes: # For \pageref{LastPage} - \usepackage{lastpage} # For \textcolor - \usepackage{xcolor} # Long tables (used by pandoc latex template itself) #- \usepackage{longtable} # Localization to German for all package injections #- \usepackage[ngerman]{babel} # Fancy header! - \usepackage{fancyhdr} - \usepackage{graphicx} - \pagestyle{fancy} - \fancyhf{} - \fancyhead[L]{\large{\textit{\textbf{ITS} \\ IP und ICMP}}} - \fancyhead[R]{\raisebox{-0.1\height}{\includegraphics[height=32pt]{img/steinbeis.png}}} - \fancyfoot[L]{\textcolor{gray}{Carl Kittelberger}} - \fancyfoot[R]{\textcolor{gray}{\bfseries{Seite \thepage{}/\pageref*{LastPage}}}} - \renewcommand{\headrulewidth}{0.4pt} - \renewcommand{\footrulewidth}{0.4pt} - \setlength\headheight{36pt} - \fancypagestyle{plain}{} # monospace - \lstset{basicstyle=\footnotesize\ttfamily,breaklines=true} - \lstset{framextopmargin=50pt} --- \newpage # Analyse eines Pings Im Folgenden wurde die IP-Adresse `8.8.8.8` als Ziel für die Pinganfragen verwendet, die untersucht werden. Die Pinganfragen wurden von einer VM mit Netzwerkbrücke auf einem Ethernetadapter durchgeführt und Wireshark wurde zur Aufzeichnung innerhalb der VM verwendet. ![](img/02-ip/cmd_ping.png) ![](img/02-ip/wireshark_ping.png) ![](img/02-ip/wireshark_ping_reply.png) Im ersten Screenshot lässt sich ablesen, dass die *IP-Adresse des Computers* von dem die Pinganfrage verschickt wurde **`192.168.188.52`** lautet. Der *Typ* des IP-Pakets ist als Wert **`1` (`ICMP`)** angegeben. Im IP-Paket sind insgesamt laut Wireshark **84 Bytes** enthalten, davon belegt der *IP-Header* **20 Bytes**, die restlichen **64 Bytes** sind die tatsächliche *Nutzlast* des IP-Pakets, die aus der ICMP-Nachricht besteht. Die *Roundtrip Time (RTT)* ist der Zeitabstand zwischen Versand des Anfragepakets und Erhalten des Antwortpakets. Im Screenshot sieht man als Interval für die erste Anfrage (Pakete 1 und 2) **etwa 15,05 Millisekunden**. Die *Identifikationsnummern* lauten laut Wireshark für das IP-Paket selbst `0x7566 (30054)` und das ICMP-Paket selbst hat die Identifikationsnummern im *Big-Endian-Format (BE)* `3533` oder `0x0dcd` bzw. im *Little-Endian-Format (LE)* `52493` oder `0xcd0d`. Im zweiten Screenshot sieht man, dass die Identifikationsnummern für das Antwortpaket genau gleich sind. Wären diese Nummern verschieden, könnte die Antwort der Anfrage nicht mehr zugeordnet werden. Das IP-Paket der Anfrage wurde nicht fragmentiert. Fragmentiert ist ein Paket erst dann, wenn es beim Versenden in mehrere Teile aufgespalten wurde und der entsprechende Flag für die Fragmentierung im IP-Header gesetzt wurde, was hier nicht der Fall ist (der Flag ist `0x4000` was Wireshark entsprechend als `Don't fragment` anzeigt). ## Analyse eines fragmentierten Pings ### Ping mit 2000 Bytes Inhalt ![](img/02-ip/wireshark_ping_2000.png) Die *IP-Adressen* haben sich nicht geändert. Der IP-Header enthält als *Typ* ebenso noch den gleichen Wert. Die Headergröße hat sich ebenfalls nicht verändert, aber die Größe der *Nutzlast* ist jetzt auf **1500 Bytes** angewachsen. Die restlichen **500 Bytes** finden sich in einem Folgepaket das aufgrund der Fragmentierung mitgeschickt wurde. Die *Roundtrip Time* beträgt jetzt **16,93 Millisekunden** (Unterschied Paket 1 zu 3). ### Ping mit 3500 Bytes Inhalt ![](img/02-ip/cmd_ping_3500.png) ![](img/02-ip/wireshark_ping_3500.png) Die Änderungen sind ähnlich wie oben, außer dass die *Nutzlast* des ersten Pakets sich nicht mehr ändert und **1500 Bytes** beträgt. Dafür ist ein weiteres Teilpaket dazugekommen, bei dem der zusätzliche Inhalt angehängt wurde. Die *Roundtrip Time* beträgt jetzt **15,80 Millisekunden** (Unterschied Paket 1 zu 4). \clearpage # Analyse der Fragmentierung In dieser Analyse scheinen Daten über 1500 Bytes fragmentiert zu werden. Beide Pakete (2000 Bytes und 3500 Bytes) wurden in max. 1500 Bytes große Datenteile aufgespalten und dann nacheinander verschickt. Die wichtige Identifikationsnummer für fragmentierte Pakete ist die `Identification` im IP-Header, nicht die `Identifier`-Felder im ICMP-Paket, denn dieses wurde in mehrere Teile zerspaltet und um das Paket zusammensetzen zu können muss stattdessen die Quelle mehrere Pakete mit dem gleichen Identifizierer verschicken. Entsprechend sehen wir im obigen Screenshot, dass die IP-ID der Folgepakete in der Übersicht die gleiche ID haben wir der IP-Header des ersten Pakets. Während der Analyse konnten wir kaum wertvolle Informationen zur Änderung der *Roundtrip Time* abhängig von der Fragmentierung gewinnen. In der Theorie braucht es länger, größere Datenmengen zu verschicken, vor allem wenn diese vorher in mehrere Teile aufgespalten wurden und für jeden Teil ein weiterer Header mitverschickt wird. Die Übertragung läuft jedoch hier in der Praxis so schnell ab, dass andere Abweichungen in der Übertragung sich stärker in der RTT abbilden. \clearpage # Analyse einer Routenverfolgung Im Folgenden wurde `reutlingen.de` explizit über IPv4 als Ziel für die Routenverfolgung verwendet. Das Tool das eingesetzt wurde ist `tracepath` (mit entsprechendem `-4` Flag). ![](img/02-ip/tracepath_reutlingen.png) ![](img/02-ip/wireshark_tracepath_1.png) ![](img/02-ip/wireshark_tracepath_2.png) Wireshark registriert eine Sequenz von Paketen vom Typ DNS, UDP und meistens ICMP als Antwort. Die Pakete der eigentlichen Anfragen zur Routenverfolgung werden über **UDP** versendet. Dabei fällt auf, dass die UDP-Pakete von oben nach unten beginnend von einer *Time-To-Live (TTL)* **von `1` inkrementierend größere Werte** (`2`, dann `3`, usw.) zugewiesen bekommen. Die *Antwort* auf alle Pakete ist immer ein **ICMP**-Paket. Alle Antworten bis auf das letzte Paket sind ein **ICMP-Paket mit der Nachricht "Time-to-live exceeded"**. Diese Antwort wird von dem jeweiligen routenden Knotenserver selbst verschickt und daran misst `tracepath` die Zeit und die Reaktionsfähigkeit des jeweiligen Knotens. Die *ersten beiden Knotenpunkte* in diesem Fall sind: - `192.168.188.1` (`fritz.box`) - der Router im lokalen Netzwerk. - `62.214.63.94` (`i59F4DCE4.versanet.de`) - der erste externe Router aus dem ISP-Netzwerk. \clearpage # ICMP ![](img/02-ip/wireshark_icmp.png) Ein ICMP-Paket ist wie folgt aufgebaut: - **`Type`** - ein Wert der die Art der ICMP-Nachricht angibt, z. B. `8` für eine Echo-Anfrage oder `11` für *Time-to-live exceeded*. **Weitere Typen** wären: - `0` - Echo Reply - `3` - Destination Unreachable - `5` - Redirect (IP-Umleitung) - `9` - Router Advertisement (wird benutzt um einem Rechner den Router bekannt zu machen zur IP-Vergabe). Gegenstück dazu: `10` (Router Solicitation) - `12` - Parameter Problem (bei ungültigen Inhalten in einer ICMP-Anfrage) - `13` - Timestamp. Gegenstück: `14` (Timestamp Reply) - **`Code`** - ein separater Code zur Angabe einer Fehlerursache oder eines anderen Details - **`Checksum`** - ein Hash des Pakets zum Sicherstellen einer korrekten Übertragung - **Informationen zu ursprünglichen Anfragepaketen**, meisten IP-Paket und dessen Inhalt. Aufgrund der Informationen die hier enthalten sind (wie der Identifizierer) weiß der Empfänger der Nachricht **basiend auf diesen Informationen auf welche ursprünglich gesendeten Pakete sich diese ICMP-Meldung bezieht.** \clearpage # Quellenangaben - https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types