227 lines
6.3 KiB
Markdown
227 lines
6.3 KiB
Markdown
|
---
|
||
|
author: Carl Kittelberger
|
||
|
date: 2018-03-22
|
||
|
title: "ITS: Ethernet und ARP"
|
||
|
institute: "Ferdinand-von-Steinbeis Berufsschule"
|
||
|
lang: de-DE
|
||
|
babel-lang: ngerman
|
||
|
babel-otherlangs:
|
||
|
- english
|
||
|
polyglossia-lang:
|
||
|
name: german
|
||
|
options:
|
||
|
- spelling=new
|
||
|
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} \\ Ethernet und ARP}}}
|
||
|
- \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
|
||
|
|
||
|
# Aufzeichnen und Analysieren von Ethernet-Frames
|
||
|
|
||
|
Statt der IP-Addresse, die in der Aufgabe vorgegeben wurde, wird während der
|
||
|
Analyse die IP-Addresse `212.83.173.97` verwendet. Auf der IP-Addresse läuft
|
||
|
der gleiche Webserver wie bei der zuvor genutzten URL http://test.icedream.tech,
|
||
|
außer dass der Webserver hier mit HTTP-Fehler 404 antwortet.
|
||
|
|
||
|
Zuerst die Ansicht mit aktiviertem IPv4-Protokollmodul:
|
||
|
|
||
|

|
||
|
|
||
|
Frame `44453` ist der Frame in dem unsere Anfrage abgeschickt wird, und Frame
|
||
|
`45270` enthält unsere Antwort, den `404 Not Found` HTTP-Status.
|
||
|
|
||
|
\clearpage
|
||
|
|
||
|
## Anfrage
|
||
|
|
||
|
Nach Deaktivieren des IPv4-Moduls sieht der Anfrageframe wie folgt aus:
|
||
|
|
||
|

|
||
|
|
||
|
Der Inhalt ist wie folgt:
|
||
|
|
||
|

|
||
|
|
||
|
### MAC-Adresse des eigenen Rechners
|
||
|
|
||
|
Die MAC-Adresse lässt sich aus dem `Source` Feld des `Ethernet II` Frames auslesen.
|
||
|
In diesem Fall ist die eigene MAC-Adresse `00:0c:29:d6:b4:3d`.
|
||
|
|
||
|
### MAC-Adresse des Zielrechners
|
||
|
|
||
|
Die MAC-Adresse lässt sich aus dem `Destination` Feld des `Ethernet II` Frames auslesen.
|
||
|
In diesem Fall ist die MAC-Adresse des Zielservers `38:10:d5:64:53:ed`.
|
||
|
Tatsächlich ist dieser Frame nicht der einzige bei dem diese MAC-Addresse als
|
||
|
Ziel gesetzt ist. So gut wieder jeder weitere Frame der ins Internet geht enthält
|
||
|
diese MAC-Adresse als Ziel. Das Ziel ist tatsächlich der lokal installierte
|
||
|
AVM Fritz!Box Router, der die Pakete ins Internet leitet, auch erkennbar am
|
||
|
angezeigten Herstellernamen, den Wireshark daneben anzeigt (`AvmAudio_64:53:ed`).
|
||
|
|
||
|
### Typ-Feld
|
||
|
|
||
|
Der Hexwert ist auf den Wert `0x0800` gesetzt.
|
||
|
|
||
|
### Offset in Daten
|
||
|
|
||
|
Der Buchstabe `G` der `GET`-Anfrage kann in den Rohdaten des Frames am Byte-Offset
|
||
|
`0x0042` (dezimal `66`) gefunden werden.
|
||
|
|
||
|
## Antwort
|
||
|
|
||
|

|
||
|
|
||
|
### MAC-Adresse des Quellrechners
|
||
|
|
||
|
Im `Source`-Feld des Antwortframes ist nun die MAC `38:10:d5:64:53:ed` und damit
|
||
|
wie oben auch identifizierbar unser Router gesetzt.
|
||
|
|
||
|
### MAC-Adresse des Zielrechners
|
||
|
|
||
|
Als `Destination` MAC ist jetzt unsere eigene MAC, `00:0c:29:d6:b4:3d` gesetzt.
|
||
|
|
||
|
### Typ-Feld
|
||
|
|
||
|
Der Hexwert ist wieder auf den Wert `0x0800` gesetzt.
|
||
|
|
||
|
### Offset in Daten
|
||
|
|
||
|
In diesem Fall ist die Antwort leider keine `200 OK`-Antwort. Hier wird
|
||
|
stattdessen nun nach den Buchstaben `N` und `F` der `404 Not Found`-Nachricht
|
||
|
gesucht.
|
||
|
|
||
|
Der Buchstabe `N` findet sich an Position `0x004f` (dezimal `79`). Der Buchstabe
|
||
|
`F` findet sich danach an Position `0x0053` (dezimal `83`).
|
||
|
|
||
|
\clearpage
|
||
|
|
||
|
# ARP-Datagramme
|
||
|
|
||
|
## Cache
|
||
|
|
||
|
Beim Ausführen des Befehls `arp -a` gibt der Rechner wie folgt seinen Cache aus:
|
||
|
|
||
|

|
||
|
|
||
|
Sichtbar sind der Router (`_gateway`/`192.168.188.1`), der Host-PC der virtuellen
|
||
|
Maschine in dem die Analysen stattfinden (`Icedream-HomePC.fritz.box`/`192.168.188.21`)
|
||
|
und die virtuelle Maschine selbst (`vm-dev-archlinux.fritz.box`/`192.168.188.33`).
|
||
|
|
||
|
## Protokollanalyse
|
||
|
|
||
|
Vor der Analyse wird der ARP-Cache gelöscht. Gelöscht wird mit dem Befehl `ip -s -s neigh flush` mit `root`-Rechten:
|
||
|
|
||
|

|
||
|
|
||
|
Jetzt wird Firefox gestartet und http://bild.de aufgerufen und folgende ARP-Anfrage
|
||
|
und dazugehörige Antwort werden sichtbar:
|
||
|
|
||
|

|
||
|
|
||
|

|
||
|
|
||
|
\clearpage
|
||
|
|
||
|
### Request
|
||
|
|
||
|
#### Adressen
|
||
|
|
||
|
- Die Ziel-MAC ist `00:00:00:00:00:00` (Alias für *unbekannte MAC*)
|
||
|
- Die Quell-MAC ist `00:0c:29:d6:b4:3d`, die der analysierenden Maschine
|
||
|
|
||
|
#### Typ
|
||
|
|
||
|
Das Typenfeld für das Protokoll ist auf `0x0800` (*IPv4*) gesetzt.
|
||
|
|
||
|
### RFC 826
|
||
|
|
||
|
#### Offset des `opcode`-Felds
|
||
|
|
||
|
Das `opcode`-Feld beginnt nach 16 + 16 + 8 + 8 = **48 Bits** im ARP-Payload.
|
||
|
|
||
|
#### IP-Adresse in ARP-Message
|
||
|
|
||
|
Eine ARP-Message beinhaltet grundsätzlich Verweise auf MAC-Adressen und IP-Adressen
|
||
|
von Sender und Empfänger (oder sie werden auf null gesetzt wenn die Daten dafür
|
||
|
nicht verfügbar sind). Die des Senders ist in der Anfrage dabei definitiv enthalten.
|
||
|
|
||
|
#### `opcode` für Anfragen
|
||
|
|
||
|
Das `opcode`-Feld wird für Anfragen in Ethernetframes laut RFC auf den Wert
|
||
|
von `ares_op$REQUEST` bzw. `1` oder binär `01` gesetzt.
|
||
|
|
||
|
#### Platzierung der "Frage"
|
||
|
|
||
|
Im ARP-Paket wird die "Frage" durch das `opcode` Feld und den genullten Wert der
|
||
|
Ziel-MAC und -IP dargestellt.
|
||
|
|
||
|
### Reply
|
||
|
|
||
|
#### Offset des `opcode`-Felds
|
||
|
|
||
|
In der Antwort beginnt das `opcode`-Feld `0x14 - 0x0e = 20 - 14 = 6` Bytes
|
||
|
und damit wieder nach **48 Bits** im ARP-Payload.
|
||
|
|
||
|
#### `opcode` für Anfragen
|
||
|
|
||
|
Das `opcode`-Feld wird für die Antwort auf `2` (*reply*) gesetzt.
|
||
|
|
||
|
#### Platzierung der "Frage"
|
||
|
|
||
|
Die Frage selbst ist nicht mehr wirklich im Paket enthalten bis auf die Tatsache,
|
||
|
dass als Empfänger dieser Antwort exakt der Sender der Anfrage eingetragen ist.
|
||
|
|
||
|
#### MAC-Adressen
|
||
|
|
||
|
- Ziel-MAC: `00:0c:29:d6:b4:3d`
|
||
|
- Quell-MAC: `38:10:d5:64:53:ed`
|
||
|
|
||
|
\clearpage
|
||
|
|
||
|
# Quellenangaben
|
||
|
|
||
|
Alle Quellen zuletzt abgerufen am 21.03.2018.
|
||
|
|
||
|
- RFC 826: https://tools.ietf.org/html/rfc826
|