Netzwerkanalyse mit Wireshark Teil 7 - TCP-Fehlerkorrektur am Beispiel FTP

Als Basis für diese Ana­lyse dient eine FTP-Sitzung, bei der wir be­wusst auf den ver­schlüssel­ten Modus ohne TLS oder SSH/Public-Key ver­zichten. Dies gibt uns Gelegen­heit zu demon­strieren, wie ein­fach Hacker mit Wireshark solche Infor­mationen ab­fangen und bei­spiels­weise an das FTP-Pass­wort ge­langen können.

Bevor wir uns mit zweck­gebundenen Analysen befassen, bleiben wir vorerst noch bei der TCP-Fluss­steuerung, 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 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.

TCP-Fehlerkorrektur am Beispiel FTP.

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.

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.