sdecoret - stock.adobe.com
Netzwerk-Protokolle mit Wireshark und Dissektoren richtig interpretieren
Dissektoren erlauben die Interpretation von Netzwerkverkehr mit Wireshark. Wir zeigen, wie Sie verbogenen Netzwerkverkehr richtig interpretieren.
Jeglicher Netzwerkverkehr von Anwendungen, der nicht über die üblichen Standard-Portnummern fließt, sorgt bei IT-Profis für ein deutliches Stirnrunzeln. Möglicherweise handelt es sich ja um eine bewusste Verschleierung des eigentlichen Anwendungszwecks, beispielsweise lässt sich über diesen Weg eine Port-basierte Firewall austricksen.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seinem IT-Grundschutz im Abschnitt 4.98 nicht ohne Grund, die Kommunikation durch Paketfilter auf das notwendige Minimum zu beschränken. Webserver sollten, entsprechend der Empfehlung, nur auf Port 80, beziehungsweise 443 für SSL/TLS, TCP/ack kommunizieren und ansonsten auf keinem weiteren Port lauschen.
Abbildung 1: So sieht üblicherweise eine Namensauflösung über DNS auf Port 43 aus.
Mit dem kostenlosen Wireshark hat der Administrator die Möglichkeit, Datenverkehr zu identifizieren, der nicht über die Standard-Portnummern läuft. In den Grundeinstellungen versucht das Programm anhand der Portnummer automatisch den Netzwerkkehr zu erkennen.
Arbeitet beispielsweise ein FTP-Server, was sehr außergewöhnlich ist, über Port 137, so identifiziert Wireshark diesen Transfer möglicherweise als „NetBIOS-Namensdienst“. Jedoch unterscheidet sich die Gestalt von FTP-Verkehr recht deutlich von NetBIOS-Anfragen und deren Beantwortung.
In diesem Fall würde zwar in der Spalte „Protocol“ TCP und als Port „netbios-ns“ stehen, in der Spalte „Info“ jedoch die üblichen Details für normalen NetBIOS-Namensdienst fehlen. Ähnliches geschieht bei einem HTTP-Server, der über den klassischen DNS-Port 53 arbeitet oder eine „verbogener Remote-Desktop-Server“, der anstelle 3389, über einen gänzlich anderen Port zu Werke geht. Im Wireshark-Jargon nutzt der Sniffer einen falschen „Dissektor“, sprich der Verkehr wird missinterpretiert und die Analyse so erschwert.
Abbildung 2: Klassischer http-Verkehr eines Webservers mit einem Client, jedoch über Port 53.
Der Netzwerk-Analyst kann die Verwendung eines Dissektors bei Wireshark erzwingen und hierfür gibt es üblicherweise auch nur zwei Gründe. Der erste Grund ist die hier benannte Fehlinterpretation durch die Software selbst.
Der zweite Grund ist das Fehlen einer Entscheidungsregel für die Auswahl eines Dissektors. Die Software nutzt zur Erkennung so genannte „heuristische Dissektoren“. Jeder dieser Dissektoren sucht in den mitgeschnittenen Netzwerkströmen nach erkennbaren Mustern, um herauszufinden, um welche Kommunikationsform es sich bei den Paketen handelt.
Gelingt diese Erkennung nicht, so signalisiert der Dissektor Wireshark den Misserfolg und die nächste Prüfung wird angestoßen. Mit jeder neuen Programmversion wird die Erkennungsrate übrigens immer besser, so dass es heute in vielen Fällen überhaupt nicht mehr zu dem Phänomen kommt, dass ein nicht erkannter, reiner „DATA“-Netzwerkverkehr identifiziert wird.
Dissektor erzwingen
Verhaut sich die heuristische Paket-Identifikation von Wireshark, so hat der Netzwerk-Administrator stets die Möglichkeit, die Anwendung eines anderen Dissektors zu erzwingen. In der Paketliste muss der Anwender hierzu mit der rechten Maustaste auf das nicht oder fehlerhaft dekodierte Paket einen Klick machen.
In der Menüliste gilt es nun „Decode As“, zu Deutsch „Dekodieren als“, auszuwählen und aus der Auflistung auf der rechten Seite das gewünschte Protokoll zu markieren. Es ist nicht notwendig, durch die komplette Liste zu scrollen. Wireshark akzeptiert in der Auflistung auch die Eingabe von Buchstaben – so ist der Benutzer beispielsweise recht zügig beim Buchstaben „h“ für „http“ angelangt.
In unserem Beispiel (siehe Abbildung 3) erkannte Wireshark nach dem Setzen des passenden Dissektors beispielsweise den http-Strom eines Jana2-Servers, den wir zu diesem Zweck auf Port 53 (Domain Name Service) umgestellt hatten. Der Aufruf für das FAVICON – das kleine Favoriten-Symbol in der Adresszeile des Browsers – wurde daraufhin korrekt interpretiert.
Abbildung 3: Wireshark soll diesen Verkehr auf Port 53 als http interpretieren.
Eigenen Dissektor anlegen
Nicht selten verwenden Administratoren im Intranet bewusst andere Port-Adressen, um beispielsweise Informationen gegenüber dem Querzugriff auch per Firewall schützen zu können. Mit wenigen Mausklicks ist beispielsweise ein virtuelles Verzeichnis eines Microsoft IIS auf Port 50.000 umgesetzt. Möchte der IT-Profi diesen Transfer – sofern die Heuristik nicht eh eine Interpretation erwirkt – stets mit http interpretieren, so kann er die Grundeinstellungen von Wireshark dahingehend anpassen.
Weitere Praxisartikel zu Wireshark:
Wireshark richtig einsetzen: Vier Schlüssel-Funktionen im Überblick
Best Practices für das Network-Sniffing mit Wireshark
WiFi-Sniffer Wireshark: Netzwerk-Verkehr richtig mitschneiden
Werkzeuge für Cloud-Monitoring: Problembehebung mit Wireshark
Für den Eintrag von Port 50.000 für den http-Dissektor muss der Benutzer im Menüpunkt „Edit“ auf „Preferences“ klicken. Anschließend in der rechten Funktionsauflistung den Knoten „Protocols“ erweitern und „http“ in der Protokollauflistung auswählen.
Auch hier unterstützt das Programm die Verwendung von Texteingaben über die Tastatur. In der Detailansicht auf der rechten Seite nun 50.000 unter TCP-Ports einfügen und mit „OK“ oder „Apply“ die Erweiterung bestätigen. Von nun an versucht Wireshark den Traffic stets als http-Datenstrom zu interpretieren.
Weitere Informationen zur Verwendung und zum Erzwingen von Dissektoren finden Sie in der englischsprachigen Wireshark-Dokumentation unter http://goo.gl/AmdXJx.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+ und Facebook!
