Als Basis für diese Analyse dient eine FTP-Sitzung, bei der wir bewusst auf den verschlüsselten Modus ohne TLS oder SSH/Public-Key verzichten. Dies gibt uns Gelegenheit zu demonstrieren, wie einfach Hacker mit Wireshark solche Informationen abfangen und beispielsweise an das FTP-Passwort gelangen können.
Bevor wir uns mit zweckgebundenen Analysen befassen, bleiben wir vorerst noch bei der TCP-Flusssteuerung, diesmal aber im Rahmen der Datenübertragung. Da nun auch Daten transferiert werden, wird die Berechnung der Sequence- und Acknowledgment-Nummern mit realen 32-Bit-Werten aufwändiger.
Berechnung von SEQ und ACK
Wer deshalb Wireshark wieder auf relative Sequenznummern zurücksetzt, 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 Sequenznummer in Rahmen der Datenübertragung. Grundsätzlich gilt, dass sich die vom Client verwendete Sequence-Number zusammensetzt 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 Acknowledgment-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 auszuhandeln, was aber aufgrund der vorbereiteten Konfiguration von proftpd und Filezilla scheitern musste.
Da wir den Mitschnittfilter 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 dazwischenmogeln. Im Vergleich zum bloßen Handshake ist schon in der zusammenfassenden Zeilenansicht zu erkennen, dass das „Protocol“ nun FTP ist.
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 auszuhandeln, was aber aufgrund der vorbereiteten Konfiguration von proftpd und Filezilla scheitern musste.
Da wir den Mitschnittfilter 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 dazwischenmogeln. Im Vergleich zum bloßen Handshake ist schon in der zusammenfassenden Zeilenansicht zu erkennen, dass das „Protocol“ nun FTP ist.