Netzwerk-Analyse mit Wireshark am Beispiel von Ping


    Tags: , ,

    Traffic mitschneiden mit WiresharkDieser Beitrag zeigt anhand von Ping, wie sich Mit­schnitte des Netz­werk-Traffics in Wire­shark aus­werten lassen. Das Sniffing-Tool erlaubt es dem Anwender durch die Auf­teilung des Fensters, sich schnell durch die ver­schie­denen Schich­ten des Netz­werk-Stacks zu hangeln und detail­lierte Infor­mationen auszu­lesen.

    Für dieses Beispiel verwenden wir der Einfach­heit halber und aus Gründen der Sicherheit zwei virtuelle Systeme (Ubuntu und Kali Linux) mit den IP-Adressen 192.160.0.124 (Ubuntu) und 192.168.0.123 (Kali). Auf beiden Systemen ist Wireshark verfügbar, wir können sie daher als Client oder Server verwenden.

    Aufzeichnung starten

    Zuerst klicken wir im Menü Aufzeichnen auf Optionen und markieren das mit­zuschneidende Interface (hier eth0). Wenn Sie etwas länger mit der Maus auf den Eintrag verharren oder das kleine Dreiecksymbol bei Interface aufklappen, wird auch die zugehörige IP-Adresse angezeigt, um ganz sicher zu gehen, das richtige Gerät erwischt zu haben.

    Aufzeichnung des Traffic auf eth0 mit dem Filter icmp in Wireshark starten

    Am Fuß des Dialoges bei "Mitschnittfilter für die ausgewählte Schnitt­stelle" geben wir den Wert "ICMP" ein.

    Sofern es sich um ein gültiges, also von Wireshark akzeptiertes Eingabemuster handelt (erlaubt sind diverses Kombinationen aus Protokollbezeichnung und Ports, die sich auch logisch verknüpfen lassen), wird der Hintergrund grün.

    Leeres Aufzeichnungsfenster in Wireshark vor dem Absenden eines Ping.

    Dann klicken wir auf Start. Wireshark wechselt jetzt in den Aufzeichnungs­modus und sollte ein leeres Aufzeichnungs­fenster zeigen, sofern Sie sich in einer isolierten Labor-Umgebung befinden.

    In realen Umgebungen dagegen wird durchaus auch anderweitiger ICMP-Traffic zu beobachten sein. Dieser muss sich auch nicht explizit an den Host richten, auf dem Wireshark läuft, denn wir benutzen den angegeben Port ja im Promiscuous-Mode.

    Wir können das Ziel im Filter aber auch spezifisch angeben, zum Beispiel mit

    icmp and host 192.168.0.123

    Anschließend pingen wir das System von unserem Ubuntu-Client aus. Im Gegensatz zu Windows läuft ein ping unter Linux bis zu einem Benutzer-Timeout. Da wir wenige Pakete benötigen, brechen wir den ping unmittelbar danach mit Strg+C wieder ab und beenden dann den Mitschnitt mit einem Klick auf das rote Quadrat. Das Ergebnis sollte dann so aussehen wie in folgender Abbildung.

    Ergebnis der Aufzeichnung eines Ping in Wireshark

    Das Beispiel ist trivial, aber wir können die Ausgabe hervorragend nutzen, um den Aufbau der Wireshark-Ausgabe zu erläutern.

    Aufteilung des Fensters

    Im obersten Abschnitt des Fensters finden Sie die komplette Liste der aufge­zeichneten Pakete. Der mittlere Teil zeigt für das oben ausgewählte Frame detaillierte Informationen zu den einzelnen Protokoll-Headern im OSI-Modell in aufsteigender Reihenfolge.

    Der erste Eintrag mit "Frame 1…:" steht dabei allerdings nicht für den Bitübertragungs-Layer 1 im OSI-Modell, sondern enthält eine von Wireshark erstellte Zusammen­fassung mit grundlegenden Informationen zum Frame selbst. So zeigt der Eintrag die Frame-Nummer (hier 1) und die Länge des aufge­zeichneten Paketes (98 Byte = 784 Bit) sowie die Interface-Nummer.

    Umgangs­sprachlich ist im Zusammen­hang mit Wireshark bzw. der Traffic-Analyse im Netzwerk von "Paketen" die Rede. Das ist aber streng genommen nicht ganz richtig, wenn wir uns wie in diesem Beispiel im eigenen lokalen Netzwerk und damit auf Layer-2 bewegen. Daher handelt es sich beim zweiten Eintrag im mittleren Fenster mit der Bezeich­nung "Ethernet II" offen­sichtlich um Details zum von uns aufgezeichneten Ethernet-Frame.

    MAC- und IP-Adresse auslesen

    So gibt Wireshark hier die Quell-MAC-Adresse (Src) mit Alias und tatsächlicher Adresse (00:50:56:b7:30:b4) sowie die Ziel-MAC-Adresse an. Der besseren Lesbarkeit wegen (nur hier in der Zusammen­fassung) erfolgt dies nicht in umge­kehrter Reihenfolge. Bekanntlich steht im tatsächlichen Frame immer erst die Ziel-MAC.

    Aus Alias und Art der MAC-Adresse (die erste 3 Byte sind immer hersteller­spezifisch) ist außerdem ersichtlich, dass es sich um generische Adressen von VMware handelt, denn unsere VMs laufen unter ESXi.

    Die Bezeichnung "Ethernet II …" in Zeile 3 steht dann folgerichtig für das von Layer 2 transportierte, bzw. gekapselte Protokoll, also Internet Protocol Version 4. Zu erkennen ist hier außerdem bereits die Quell-IP (Src) mit 192.168.0.124 und Ziel-IP (Dst) mit 192.168.0.123.

    Zeile 4 bezieht sich dann auf das eingekapselte bzw. im Layer-3 transportierte höher­wertige Protokoll. Das muss aber nicht zwingend eines von Layer 4 (TCP, UDP), sondern kann durchaus auch ein höher­wertiges Protokoll auf Layer 3 sein wie im Fall von ICMP. Es ist zu erkennen an der Bezeichnung "Internet Control Message Protocol".

    Die Paketliste im oberen Teil verrät auch noch so Einiges. Die Nummer in der ersten Spalte wurde von Wireshark selbst der besseren Orientierung wegen angefügt und ist nicht wirklich im Frame enthalten.

    Wir erkennen aber auch hier für jedes einzelne Frame auf dem ersten Blick die Source- und Quell-IP, die zeitliche Länge (Dauer) der Aufzeichnung, das übertragene Protokoll (ICMP) und den ICMP-Typ (hier "echo reply" und "echo request") sowie id, ttl und seq-Number.

    Der Mitschnitt des Frames mit der Nr. 1 im Layer 2 offenbart, dass ein Client mit der Layer-3-IP-Adresse 192.168.0.124 ein Layer-3-ICMP-Paket an das Ziel 192.168.0.123 vom ICMP-Typ "echo-equest" (ping) versendet hat.

    Berechnung der Frame-Länge

    Der Frame ist insgesamt 98 Byte lang, wobei man erwähnen muss, dass man die Länge der Test-Pakete, die der ping-Befehl versendet, per Option einstellen könnte. Warum der Frame 98 Byte lang ist, lässt sich auch beantworten.

    Die Mindest-Frame-Size im Ethernet ist 64Byte. Da die ping-Default-Size nur 32 Byte ist, wird auf 64 Byte aufgefüllt. Hinzu kommen 14 Byte Ethernet-Header + 20 Byte IPv4 Header = 64+14+20 = 98 Byte, denn einen TCP-Header gibt es im Fall von ICMP ja nicht.

    Im unteren Fensterteil schließlich zeigt Wireshark den kompletten Inhalt des aufgezeichneten Pakets (in diesem Fall 98 Bytes) in Raw-Darstellung an. Man achte dabei auf das folgende interessante Detail. Klickt man im mittleren Fenster

    • auf den Eintrag für "Frame 1", ist unten in den Rohdaten das komplette Paket mit seiner Länge von 98 Byte blau markiert.
    • nur auf den Layer-2-Header-Eintrag, dann wird unten nur der Teil des Paketes blau markiert, der den Header eines Ethernet-Frames von 14 Byte umfasst.
    • hingegen in der Mitte auf den Eintrag für das IP-Paket, werden unten exakt 20 Byte markiert und zwar beginnend mit jenem Byte, das sich an den Ethernet-Frame-Header anschließt, denn der IP-Header ist ja der Kapselung wegen Teil der Payload (Nutzdaten) von Schicht 2 (Ethernet).

    Markierte 20 Bytes des IPv4-Headers

    Schauen wir nun die einzelnen Ebenen im Detail an, um an weitere Informationen zu gelangen. Markieren wir Zeile 1 im mittleren Fenster, dann werden also im unteren Fenster die gesamten Rohdaten von 98 Byte markiert.

    Entfalten wir diese durch einen Klick auf das Dreiecks-Icon vor Frame 1, erhalten wir noch mehr Informationen. Das Ergebnis sollte so aussehen, sofern Sie den Untereintrag für "Interface" ebenfalls noch aufklappen.

    Detailinformationen und Rohdaten zu Frame 1

    Für eine tiefere Analyse entfalten wir jetzt die Details für den zweiten Eintrag im mittleren Fenster "Ethernet II ..", also zum Ethernet-Frame-Header auf Layer-2. Achten Sie dabei auf die unten markierten Rohdaten, die genau dessen 14 Byte umfassen. Im mittleren Fenster lassen sich dann weitere Detail­ebenen einblenden.

    Details zum Ethernet-Frame Header auf Layer-2

    Wir erkennen nun Informationen zur Source- und Destination-MAC-Adresse. Im Layer-2, also im Ethernet-Frame-Header, steht immer zuerst die Ziel-MAC. Wie schon erwähnt lässt sich an den jeweils linken 3 Bytes der 6 Byte langen MAC-Adresse erkennen, dass der Hersteller des Netzwerk­geräts VMware ist, wir uns also offenbar in einer virtua­lisierten Umgebung bewegen.

    Am Ende der Anzeige wird noch das Type-Feld des Ethernet-Frames angezeigt, das angibt, welches Protokoll der nächsten höheren Ebene im Frame transportiert wird, hier IPv4 (0x800).

    Noch ein Detail ist interessant. Markieren Sie in der Details-Ansicht beispielsweise die Ziel-MAC-Adresse, dann wird auch unten im Rohdaten-Fenster exakt der zugehörige Bereich markiert. Das Gleiche gilt für die direkt dahinter folgende Source-MAC.

    MAC-Adresse des Quellrechners

    Nun setzen wir die Analyse mit Detail­informationen aus dem Layer-3-Header (Eintrag "Internet Protocol Version 4" im mittleren Fenster) fort. Da der IP-Header mit 20 Byte länger ist und mehr Felder kennt als der Ethernet-Frame, beansprucht das mittlere Fenster auch mehr Platz. Markieren wir hier wieder analog zu oben wieder die Source-IP, dann wird auch nur der zugehörige Bereich in den Rohdaten eingefärbt.

    Detail-Informationen aus dem Layer-3-Header

    Analog zum Typ-Feld im Layer 2 gibt es im Layer 3 das "Protocol"-Feld, das hier den Wert 1 hat, was für ICMP, ebenfalls ein Layer-3-Protokoll, steht. Andere populäre "höherwertige" Protokolle wären zum Beispiel die Layer-4-Protokolle TCP mit 6 oder UDP mit 17.

    Protocol-Feld auf Layer 3 mit Wert 1 für ICMP

    Werfen wir abschließend noch einen Blick auf den Abschnitt "Internet Control Message Protocol" (ICMP), also das nächst­höhere transportierte Protokoll. Offenbar kennt auch dieses verschiedene Typen, die im entsprechenden Feld spezifiziert werden. Unser Frame1 verwendet den Typ 8, der für "echo-request" (ping) steht.

    ICMP Typ 8 steht für "echo-request" (ping)

    Vergleichen Sie diesen Eintrag mit jenem im Frame 2, dann werden Sie feststellen, dass das Layer-3-Protocol-Feld zwar selbst­verständlich auch auf 1 (ICMP) steht, der ICMP-Typ aber folgerichtig 0 ist, was für "echo -reply" (ping) steht.

    Wenn der ICMP-Typ im Layer-4-Header 0 ist, dann liegt ein echo -reply (ping) vor.

    Warum allerdings die IANA den Request (echo = 8) numerisch vor den Reply (echo-reply = 0) gestellt hat, weiß wohl nur der Weihnachtsmann.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet ist seit fast 30 Jahren selb­ständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehe­malige und aktuelle IT-Magazine sowie Blogs.

    Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.

    Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zerti­fi­zierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grund­lagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.

    Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Infor­mationen und Anmel­dung über sein Azure-Blog.

    Verwandte Beiträge

    Weitere Links