Tags: Netzwerk, Monitoring, FTP
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.
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 Sequenznummer 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 Sequenznummern um und rechnen 35-21=14, was exakt dem Feld "Len:" für die Länge der Nutzdaten entspricht.
Diese Anzeige taucht noch einmal auf in der letzten Zeile des Detailfensters 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 hexadezimalen Rohdatenansicht angezeigt und tatsächlich ist hier, wie zu erwarten, das übergebene Passwort "ftpuser" zu erkennen.
TCP-Flusssteuerung als Schema
Hier das Prüfsummen-Szenario noch einmal in einer Schema-Ansicht mit angenommenen relativen Sequenznummern. Da wir uns jetzt nicht mehr in der Phase des Verbindungsaufbaus 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige 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 zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse 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 Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
- Netzwerk-Analyse mit Wireshark: Mitschnittfilter versus Anzeigefilter
- Fortgeschrittene Techniken mit Nmap: TCP-Window-, FIN-, NULL- und XMAS-Scans
- Nmap: Firewalls umgehen mit Ping- und TCP-ACK-Scans
- Portscanner Nmap: die wichtigsten Funktionen im Überblick
- Netzwerk- und Cloud-Monitoring mit NetCrunch 12
Weitere Links