Netzwerk-Analyse mit Wireshark: FTP unter der Lupe

Wer deshalb Wireshark wieder auf relative Sequenz­nummern zurück­setzt, darf trotzdem nicht vergessen, dass Client und Server in Wahrheit mit zufälligen und daher nicht identischen Sequenznummern starten.

Werfen wir jetzt ein Blick auf die weitere Entwicklung der Sequenz­nummer in Rahmen der Daten­übertragung. Grund­sätzlich gilt, dass sich die vom Client verwendete Sequence-Number zusammen­setzt aus der vorherigen Sequence-Number plus der Anzahl der vom Client im entsprechenden Abschnitt versendeten Daten-Bytes., also

SEQ Client = alte SEQ Client + Anzahl Datenbytes Client

Die Acknowledg­ment-Number des Clients errechnet sich dagegen aus der Sequence-Number vom Server plus der Anzahl der Daten-Bytes, die der Server versendet hat.

ACK Client = SEQ Server + Anzahl Datenbytes Server

Es handelt sich also bei der ACK-Nummer also um eine Art Prüfsumme, mit welcher der Server herausfindet, ob der Client tatsächlich alle vom Server gesendeten Daten empfangen hat.

FTP-Mitschnitt untersuchen

Überprüfen wir diesen Sachverhalt anhand des FTP-Mitschnitts und betrachten dazu die Zeilen 14 bis 17.

Beginnen wir mit Zeile 14. Sie fragen sich, was davor passiert ist, also im Rahmen der Pakete 4 bis 13? Hier haben Client und Server erst einmal versucht, eine TLS-Verbindung auszu­handeln, was aber aufgrund der vor­bereiteten Konfi­guration von proftpd und Filezilla scheitern musste.

Da wir den Mit­schnitt­filter zudem nur auf den Ziel-Host 192.168.1.24 und nicht explizit auf das FTP-Protokoll beschränkt hatten, konnten sich zudem noch einige andere Pakete dazwischen­mogeln. Im Vergleich zum bloßen Handshake ist schon in der zusammen­fassenden Zeilen­ansicht zu erkennen, dass das "Protocol" nun FTP ist.

In Zeile 14 übermittelt der Client dem Server dann den gewünschten User-Namen für die Anmeldung: "USER ftpuser". Im Detail-Fenster ist außerdem zu erkennen, dass die Sequenz­nummer des Clients inzwischen 3759279698 ist.

Die "Next sequence Number" hingegen ist 3842592692, da der Client 14 Byte übertragen hat, was das Len-Feld verrät.

Wir können die Länge durch Subtrahieren der beiden Sequenz-Nummern überprüfen, schalten dazu aber wieder auf relative Sequenz­nummern um und rechnen 35-21=14, was exakt dem Feld "Len:"  für die Länge der Nutz­daten entspricht.

Diese Anzeige taucht noch einmal auf in der letzten Zeile des Detail­fensters bei "TCP payload (14 bytes)" auf. Markiert man im mittleren Teil an genau dieser Stelle den Payload-Teil, dann werden die Nutzdaten auch unten in der hexa­dezimalen Roh­daten­ansicht angezeigt und tatsächlich ist hier, wie zu erwarten, das über­gebene Passwort "ftpuser" zu erkennen.

TCP-Flusssteuerung als Schema

Hier das Prüfsummen-Szenario noch einmal in einer Schema-Ansicht mit ange­nommenen relativen Sequenz­nummern. Da wir uns jetzt nicht mehr in der Phase des Verbindungs­aufbaus befinden, reden wir auch nicht mehr explizit von Client und Server, sondern von Host A und B. Der linke Host A startet mit SEQ 101, der rechte Host B mit 201.

Noch mal zur Erinnerung: Grundsätzlich ist

• die SEQ-Number, die Host A nutzt, immer die vorherige SEQ-Nummer plus die Anzahl der versendeten Daten-Bytes
• und die ACK-Nummer von Host A die SEQ-Number von B plus die Anzahl der von B versendeten Daten-Bytes.

	Host A setzt seine SEQ auf 101, seine ACK auf 201, also der Wert, den er als nächsten vom Host B als SEQ erwartet, und sendet dann 100 Byte Daten. Zudem ist das ACK-Flag gesetzt, was Host B signalisiert, dass nun ein Wert kommt, den B überprüfen soll (Prüfsumme).
	Host B verwendet nun, wie von A erwartet, die  SEQ 201, weil dies seine aktuelle SEQ ist. Zudem muss B nun seine ACK so setzten, dass sie die nächste erwartete SEQ von A enthält, also nach der Formel vorherige SEQ von A + Anzahl der von A gesendeten Datenbytes. Das sind 101 + 150 = 251. Das ist wiederum der Wert, den Host B als nächstes von Host A als SEQ erwartet. Host B sendet nun 200 Bytes Daten.
	Dass Host B 200 Bytes Daten versendet, bedeutet, dass Host A nun als ACK die alte SEQ von B + die Anzahl der versendeten Bytes, also 201+200=401 verwendet. Die SEQ, die A nun verwendet, ist genau die, die er vorher als ACK vom Host B zurück­gespiegelt be­kommen hat, also 251, da ja Host B die 150 Bytes Daten korrekt erhalten hat. Nun sendet A seinerseits wieder 100 Bytes Daten.
	Das wiederum hat zur Folge, dass Host B nun eine ACK von 251 (SEQ A) + 100 Byte = 351 verwendet. Da er seiner­seits vorher 200 Byte Daten versendet hat, setzt er seine neue SEQ auf SEQ B (alt) + 200 = 201 +200 = 401 und versendet wieder 200 Bytes an Daten.