Netzwerk-Analyse mit Wireshark: TCP-Handshake beim Aufbau einer Sitzung untersuchen

    Diagramm TCP-HandshakeNeben UDP ist TCP das meist­ver­wendete Proto­koll der TCP/IP-Familie auf der OSI-Schicht 4. Es arbeitet ver­bindungs­orientiert, wozu es eine Sitzung aufbaut. Dies passiert mit Hilfe eines 3-Wege-Hand­shakes. Die folgende An­leitung zeigt, wie man diesen Hand­shake für eine FTP-Kommu­nikation in Wireshark visualisiert.

    Bei unserem Mitschnitt greifen wir mit einem FTP-Client auf einen im lokalen Netzwerk befind­lichen FTP-Server zu. Der Client hat die IP-Adresse 192.168.1.200, der Server auf Basis von Ubuntu 18.04 LTS ist unter 192.168.1.124 erreichbar.

    Mitschnitt beginnen

    Als Client nutzen wir Filezilla auf einer Windows-Maschine. Wir verwenden den Passiv-FTP-Mode. Dies und der Verzicht auf SFTP (FTP via TLS) muss auch am Client ent­sprechend konfi­guriert werden. Außer­dem ist darauf zu achten, dass keine Firewall-Regel auf dem Server oder Client den Verbindungs­aufbau verhindert.

    Das Mitschneiden in Wireshark soll auf dem Client erfolgen. Wir starten daher dort die Windows-Version und definieren im Menü Aufzeichnen => Optionen nach dem Markieren der gewünschten Netzwerk­schnittstelle unter dem Eingabe-Dialog in der Zeile Mitschnittfilter für die ausgewählte Schnittstelle einen neuen Mitschnittfilter.

    Netzwerkschnittstelle für die Aufzeichnung der FTP-Kommunikation auswählen

    Diesmal wollen wir den Mitschnitt auf den gewünschten Ziel-Host beschränken. Das klappt mit dem Schlüsselwort host gefolgt von der Ziel-IP, also "host 192.160.0.124".

    Dann starten wir den Mitschnitt und initiieren anschließend einen FTP-Zugriff mit Filezilla und betätigen, dass wir unverschlüsseltes FTP auf Port 21 erlauben möchten.

    Verzeichnisinhalt des FTP-Users für den Mitschnitt anzeigen

    Nach dem Verbindungs­aufbau zeigen wir zum Beispiel den Verzeichnis­inhalt des FTP-Users an und beenden die Aufzeichnung. 

    Aufzeichnung auswerten

    Werfen wir nun einen Blick auf den Mitschnitt.

    Ergebnis der Aufzeichnung einer FTP-Kommunikation in Wireshark

    Relevant für den TCP-Handshake sind hier die 3 Zeilen mit den Flags [SYN], [SYN] und [ACK]. Diese drei Pakete werden zu Beginn jeder TCP-Sitzung ausgetauscht, wie die Abbildung weiter unten illustriert.

    Zeile 1 zeigt die Verbindungs­aufnahme vom Client (192.168.1.200) zum Server (192.168.1.124). FTP baut den Kontroll­kanal über einen vom FTP-Client frei gewählten High-Port (hier 23913) zu Ziel-Port 21 des Servers auf.

    Bereits in der Zeilen­darstellung ist das SYN-Flag in eckigen Klammern zu erkennen, ebenso wie in der Detail­darstellung im mittleren Fenster, das heißt, es handelt sich um ein SYN-Paket (streng genommen "Segment") im Rahmen des TCP-3-Wege-Handshakes.

    Verlauf eines TCP-Handshakes

    Der Client, der die Verbindung aufbauen möchte, sendet dem Server also ein SYN-Paket (für "synchronize") mit einer so genannten Sequenz­nummer, hier "0". Übrigens sind während der späteren Daten­übertragungs­phase (active open) die Rollen von Client und Server (aus TCP-Sicht) symmetrisch, sodass jeder der beiden Partner einen Verbindungs­abbau initiieren kann.

    Mit Hilfe der Sequenz-Nummern stellt TCP im Rahmen der Verbindungs­steuerung die Voll­ständigkeit einer Übertragung in der korrekten Reihenfolge und ohne Duplikate sicher. Das SYN-Paket ist ein spezielles Paket, bei dem das SYN-Flag (SYN-Bit) im TCP-Header gesetzt ist.

    Bei der Start-Sequenz­nummer handelt es sich eigentlich um eine beliebige Zahl, deren Generierung von der jeweiligen TCP-Imple­mentierung abhängt.  Zwecks nutzer­freundlicher Verfolg­barkeit einer TCP-Kommu­nikation verwendet Wireshark allerdings per Default so genannte relative Sequenz­nummern, weshalb die Kommu­nikation hier mit der Sequenz-nummer 0 beginnt.

    Dies lässt sich, falls gewünscht, in der Protokoll­konfiguration im Dialog Wirehark-Einstellungen unter Bearbeiten => Einstellungen im Knoten Protocols bei TCP ändern.

    Einstellung für relative TCP-Sequenz­nummern in Wireshark

    Die echte Sequence-Number sollte möglichst zufällig sein, um Sicherheits­risiken zu vermeiden. Wir bleiben aber bei relativen Sequenz­nummern und betrachten das Paket im mittleren Fenster etwas genauer.

    Die Darstellung beginnt mit der Zusammenfassung in der Zeile

    Transmission Control Protocol, Src. Port: <Port>, Dst Port: 21, Seq: 0, Len:0

    Hat man die Ansicht mit einem Klick auf den Rechtspfeil entfaltet, folgen die Zeilen:

    • Source Port:
    • Destination Port:
    • [Stream index:]
    • TCP Segment Len:
    • Sequence number:
    • Next sequence number:
    • Ack­nowledge­ment-Number:

    Daran anschließend findet sich der Knoten Flags, der sich ebenfalls mit einem Klick auf den Rechts­pfeil entfalten lässt.

    Flags des TCP-Pakets beim Handshake

    Dahinter folgen noch die so genannte TCP-Window-Size als Sende- bzw. Empfangspuffer, eine Checksum, der Checksum Status und der noch eingeklappte Bereich Options.

    Die drei Schritte des Handshakes

    Im Rahmen des 3-Wege-TCP-Handshakes mit (SYN, SYN/ACK, SYN) muss im ersten Paket des Handshakes immer das SYN-Flag gesetzt sein. Ist der Port geöffnet, antwortet der Server von seinem Port (hier 23913) auf Port 21 des Clients und bestätigt den Erhalt des ersten SYN-Pakets.

    Das tut er, indem er dem gewün­schten Verbindungs­aufbau durch Senden eines SYN/ACK-Paket zustimmt. Dabei handelt es sich ebenfalls um ein spezielles Paket, bei dem im TCP-Header sowohl das SYN-Flag als auch das ACK-Bit (Acknowledgement) gesetzt sind.

    Flags des SYN/ACK-Pakets beim Handshake in Wireshark

    Im dritten Paket des 3-Wege-Handshakes ist dann nur das ACK-Flag gesetzt, womit der Client signalisiert, dass er die Zustimmung des Servers zur Verbindungs­aufnahme registriert hat und jetzt bereit für die Übertragung ist. Damit ist die Verbindung aufgebaut und die Sitzung steht. Alles, was hierauf folgt, ist anwendungs­spezifisch.

    1 Kommentar

    Bild von Finn
    Finn sagt:
    7. Mai 2019 - 20:52

    Guter Artikel - meines Wissens wird jedoch bei der Antwort des Servers als Source Port der vorangegangene Destination Port (in diesem Fall 21) verwendet und nicht der Port des Clients, wie im letzten Abschnitt des Artikels beschrieben.

    Zitat:
    "Ist der Port geöffnet, antwortet der Server von seinem Port (hier 23913) auf Port 21 des Clients und bestätigt den Erhalt des ersten SYN-Pakets."

    Lass mich aber auch gern eines besseren belehren :)

    Gruß
    Finn