Haben Sie mal Netzwerkmitschnitte untersucht, ohne zu wissen, was genau Sie suchen? Mit Wireshark wird das leicht zu einer Odyssee: Das Analysewerkzeug filtert zwar fabelhaft, reagiert bei großen Datenmengen aber schnell zäh.
Was bei solchen Problemstellungen hilft ist: tshark! Ein Tool, mit welchem Sie auch große Packet Captures einfach anhand gängiger Kriterien durchforsten können.
tshark ist ein Kommandozeilentool, das zu Wireshark gehört und dieselben Protokoll-Dissektoren mitbringt. So kann man Netzwerkmitschnitte (auch Traces oder Captures genannt) ebenso detailliert filtern wie mit Wireshark. Anders als dieses GUI-Werkzeug lässt sich tshark aber mit weiteren Shell-Tools verknüpfen, was ermöglicht, seine Ausgabe weiterzuverarbeiten. Das erleichtert beispielsweise, Verhaltensauffälligkeiten von Clients oder sporadisch auftretenden Fehlern auf die Spur zu kommen. Security-Beauftragte können auch prüfen, ob etwa eine Firewall anfällig für bestimmte Attacken ist.
Die Konzepte lassen sich leicht auch privat für allerlei Analysen nutzen, etwa um zu ermitteln, mit welchen Zielen im Internet das neue Smart-TV spricht. Mit den Ergebnissen speist man dann beispielsweise Filterlisten von Pi-hole & Co.
Am Anfang einer Analyse empfiehlt es sich, die in einem Trace steckenden Informationen auf das Wesentliche zu reduzieren: Man filtert nur die Inhalte bestimmter Paketfelder heraus und schreibt diese in eine neue Datei. Wie bei Wireshark lassen sich Informationen auch mittels der Display-Filter isolieren, denn tshark gibt sie zeilenweise im Terminal aus. Die Ausgabe sortiert man mit den Kommandos “sort” und “uniq”.
Voraussetzungen
Auf Linux bekommt man tshark als einzelnes Element per Paketverwaltung (Beispiel für Debian: sudo apt-get install tshark). Windows- und macOS-Nutzer installieren tshark zusammen mit Wireshark vom Installations-Image des Herstellers.
Windows bringt zwar “sort” mit, aber “uniq” fehlt. Wenn Sie nicht ohnehin schon das Cygwin-Paket oder Microsofts Linux-Subsystem für Windows nutzen, können Sie sich deren Installation sparen: “uniq” steckt in der nicht mal 1 MByte kleinen Tool-Sammlung UnxUtils, die sich im Handumdrehen installieren lässt. Für ein natives Windows-Tool und gegen Microsofts Linux-Subsystem spricht übrigens auch, dass manche Backup-Programme derartige Installationen nicht sichern können.
Die UnxUtils wurden zwar letztmalig im Jahr 2003 aktualisiert. Zumindest uniq funktioniert aber auf Windows bis einschließlich Version 10. Laden und entpacken Sie das Archiv in den Ordner C:\Programme. Benennen Sie in diesem Verzeichnis die Datei sort.exe zu sort2.exe um, was Verwechslungen mit dem Windows-eigenen Befehl vermeidet. tshark liegt auf Windows typischerweise im Ordner C:\Programme\Wireshark. Auf macOS finden Sie tshark im Ordner /Applications/MacPorts/Wireshark.app/Contents/MacOS/tshark, auf Linux in /usr/bin.
Damit Sie auf Windows tshark und uniq ohne komplette Pfadangabe verwenden können, fügen Sie die zugehörigen Verzeichnisse den Windows-Umgebungsvariablen hinzu. Geben Sie im Startmenü die ersten paar Buchstaben von „Umgebungsvariablen für dieses Konto…“ ein und klicken Sie auf den Eintrag in der Trefferliste. Doppelklicken Sie im Bereich „Benutzervariablen“ auf das Feld „Path“ und fügen Sie die beiden Pfade nacheinander über die Buttons „Neu“ und „Durchsuchen“ hinzu (siehe Screenshot). Wenn Sie nun ein neues CMD-Fenster öffnen, sollten Sie tshark ohne Pfadangabe starten können.
Auf dem Mac genügt es, der Variablen PATH ein Unterverzeichnis des Wireshark-Ordners hinzuzufügen. Öffnen Sie dazu die Datei ~/.bash_profile mit einem Editor wie nano und ergänzen Sie diese Zeilen:
#PATH-Variable fuer Wireshark-Tools export PATH=$PATH:/Applications/Wireshark.app/Contents/MacOS/
Unter Linux sind keine Pfaderweiterungen erforderlich.
tshark-Grundlagen
tshark steuert man mit einer Handvoll Kommandozeilenoptionen. Wir stellen kurz die wichtigsten vor und zeigen anschließend, wie man sie zu kompletten Befehlen zusammenfasst und mit weiteren Befehlen verkettet.
Wie Wireshark oder tcpdump kann tshark den ein- und ausgehenden Netzwerkverkehr Ihres PCs mitschneiden. Mit der Option -i wählen Sie das Interface, dessen Verkehr Sie aufzeichnen wollen und mit der Option -w Dateiname.pcap legen Sie die Ausgabedatei fest.
Fertige Aufzeichnungen kann man dem Programm mit der Option -r Dateiname.pcap übergeben. Ohne weitere Parameter würde tshark aber nur den Inhalt des Tracefiles im Fenster herunterrattern. Die von Wireshark bekannten Display-Filter setzt man mittels der Option -Y Filterausdruck ein. Beispielsweise filtert -Y http.request alle HTTP-Anfragen heraus. Verschachtelte Filteraufgaben kann man in Hochkommata eingeschlossen übergeben. Für jedes gefilterte Paket gibt tshark einige Statusinformationen aus: Die laufende Nummer im Trace, den Zeitstempel, Source- und Destination-IP, Portnummer und Info. Der Clou: Mit der Option -T fields -e Feldname extrahiert tshark Inhalte bestimmter Felder.
Um einige Anwendungen durchzuspielen, haben wir eine rund 55 MByte große Beispieldatei eines Smart-TV von LG vorbereitet, die sich gut für Übungen eignet. Sie finden sie hier.
Zunächst geht es darum, die von einem Smart-TV angesprochenen (unverschlüsselten) HTTP-Server zu finden. Dafür filtert man am einfachsten das Feld http.host heraus: -T fields -e http.host. tshark gibt damit jeden Treffer in einer separaten Zeile entsprechend der Reihenfolge im Tracefile aus. Um mehrere Felder zu filtern, setzt man die Option -e Feldname mehrmals hintereinander.
Um weitere Display-Filter oder Feldnamen anzuwenden, testen Sie sie zunächst in Wireshark am selben Tracefile. Syntaxfehler stellt die Software rot hinterlegt dar. Wenn der Filterausdruck korrekt ist, wechselt die Farbe auf Grün.
Im Wireshark-Beispiel (folgender Screenshot) ist zu sehen, dass wir die UPnP-basierte Multicast-Kommunikation ausblenden: http.host and not ip.dst == 239.0.0.0/8. Das empfiehlt sich, weil einige Geräte während der Aufzeichnung viele UPnP-Nachrichten verschickt haben. Diese tun aber nichts zur Sache und stören bloß. Außerdem ist zu sehen, wie ein Klick auf das zu untersuchende Feld (Mitte) Wireshark dazu bringt, den genauen Feldnamen anzuzeigen (unten). In diesem Fall blendet Wireshark http.host ein, also die Variable für den Namen des angesprochenen HTTP-Servers.
tshark-Ausgaben können je nach Verkehrsart und Filter kurz und übersichtlich sein. Oft werden das aber lange Listen, beispielsweise von angesteuerten Domains, und nicht selten kommen im Trace manche Domains immer wieder vor. Dann empfiehlt es sich, die tshark-Ausgabe mit einigen Unix-Befehlen zu sortieren. So erkennt man Zusammenhänge oder Häufigkeitsverteilungen.
Der Befehl sort sortiert die Liste alphabetisch. Mehrfacheinträge stehen danach untereinander. uniq -c fasst Mehrfacheinträge zusammen, also etwa Ziele, die das Smart-TV wiederholt angesprochen hat. Dabei stellt das -c für Count die Anzahl der Aufrufe an den Zeilenanfang. Jeder Eintrag belegt somit nur noch eine Zeile. Das danach folgende sort /R gibt die Liste abnehmend nach Häufigkeit aus, also als Rangliste.
Der gesamte Vorgang lässt sich leicht automatisieren, indem man die Befehle mittels Pipes (|) verkettet. Das sieht komplett unter Windows dann so aus:
tshark -r lg-tv1.pcap -Y "(http.request and not ip.dst == 239.0.0.0/8)" -T fields -e http.host | sort | uniq -c | sort /R
Auf Linux und macOS setzt man anstatt des letzten Sort-Befehls sort -g -r ein. Die Analyse eines von Philips gefertigten Smart-TV brachte hervor, dass das Gerät viele Webserver mittels HTTP-Requests kontaktiert. Neben Erwartbarem wie Netflix-Servern sind aber auch etliche unbekannte Ziele darunter, etwa zeasn.tv und smartclip.net – das Smart-TV ist offensichtlich ein Plappermäulchen.
HTTPS analysieren
Auch HTTPS-verschlüsselte Verbindungen lassen sich untersuchen. Das geht sogar mit vertretbarem Aufwand, denn beim HTTPS-Verkehr sind nur die Nutzdaten verschlüsselt, nicht aber die beim Verbindungsaufbau übertragenen Paket-Header.
Das ist nützlich, denn viele Server-Betreiber bieten über eine einzige IPv4-Adresse mehrere Domains an. Die gewünschte Domain steht im Header des HTTP-Requests im Feld „Server Name Indication“. Anhand dieser SNI liefert der Zielserver dem Browser das zur angefragten Domain passende TLS-Zertifikat und dann die angefragte Webseite aus. Außerdem nutzen auch Load-Balancer die SNI, um in komplexen Server-Umgebungen Anfragen vorzusortieren und weiterzuleiten.
Um HTTPS-Server aus einem Trace zu isolieren, nehmen Sie als Display-Filter tls.handshake.extensions_server_name. Die Option fürs interessierende Feld lautet entsprechend -T fields -e tls.handshake.extensions_server_name und der gesamte Windows-Befehl inklusive sort- und uniq-Pipe setzt sich so zusammen:
tshark -r lg-tv1.pcap -Y tls.handshake.extensions_server_name -T fields -e tls.handshake.extensions_server_name | sort | uniq -c | sort /R
Heraus kommt eine ähnliche Liste wie bei der Filterung der unverschlüsselten Webserver. So kommt man den teils unerwünschten Verbindungen eines Smart-TV auf die Schliche.
Direkte DNS-Anfragen
Neben den HTTP(S)-Zielen gibt es weitere lohnenswerte Kandidaten für die Verkehrsanalyse, allen voran die Source- und Destination-IP-Adressen, also “ipv6.src” und “ipv6.dst” für das IPv6-Protokoll sowie “ip.src” und “ip.dst” für das veraltete IPv4. Aufschlussreicher sind aber schon DNS-Queries “dns.qry.name”, die unverschlüsselte Anfragen aller Clients sichtbar machen, unabhängig davon, ob ein Client später HTTPS-, SMTP- oder sonstige Verbindungen aufbaut.
So fiel in einem unserer Traces auf, dass das Smart-TV nicht nur den per DHCP im LAN konfigurierten DNS-Server befragt, sondern auch direkt mit Googles DNS-Resolver 8.8.8.8 plaudert. Das sollte nicht sein. Der Smart-TV-Hersteller ist aber vermutlich unschuldig: Anhand des Felds dns.flags.response == 0 kann man davon ausgehen, dass die Google-Anfragen von der auf dem Smart-TV installierten Netflix-App kommen und nicht vom TV-Betriebssystem.
Wireshark beschleunigen
Eine der nützlichsten tshark-Anwendungen ist Datenreduktion, um die Analyse mit Wireshark zu beschleunigen. Wireshark kaut nämlich an großen Dateien lange herum, bis es etwas anzeigt, weil das Programm nach jeder Änderung des Display-Filters die komplette Datei neu einliest. Um alle aktuell ausgewählten Pakete einer 600 MByte großen Capture-Datei darzustellen, benötigt selbst ein moderner Rechner mit i7-Dualcore-Prozessor und 16 GByte RAM satte 40 Sekunden – bei jeder Änderung der Filterzeile.
Schon beim Mitschneiden einen reduzierenden Capture-Filter zu verwenden, ist aber kontraproduktiv: Bei Fehleranalysen wissen Sie zu Beginn oft nicht, wonach Sie suchen. Daher lautet die Regel: so viel mitschneiden, wie gerade vertretbar ist.
Um dennoch flüssig mit Wireshark arbeiten zu können, überlegen Sie zunächst, wo anzusetzen ist. Ein guter Startpunkt kann die DNS-Kommunikation sein. Extrahieren Sie also aus dem großen Mitschnitt alle DNS-Pakete in eine neue Datei mit dem Display-Filter udp.port eq 53 or tcp.port eq 53. Der Ausdruck dns wäre zwar viel einfacher, aber er erfasst nur DNS-Verkehr. So würden Sie bei etwaigem TCP-DNS-Verkehr den Verbindungsaufbau verpassen.
Verwenden Sie nun tshark zum Einlesen der ursprünglichen Datei zusammen mit dem Filter, um eine verkleinerte Variante zu erzeugen:
tshark -r inputfile.pcapng -Y "udp.port eq 53 or tcp.port eq 53" -w nur-dns-traffic.pcapng
Längere Mitschnitte segmentiert man geschickterweise, zum Beispiel in mehrere Dateien von je 100 MByte Größe. Denn wenn Sie den Verkehr von sehr schnellen Schnittstellen bei hohem Durchsatz mitschneiden, fallen in kürzester Zeit enorm große Dateien an. Mit tshark und etwas Know-how kann man dann Verdächtiges oder Wesentliches leicht extrahieren und Wireshark als Portiönchen zuführen.
Das erledigt, zusammen mit einer Filterung, einfacherweise ein Shell-Skript, im Beispiel unten als Windows-Batch-Datei. Sie legt die gefilterten Segmente in ein Unterverzeichnis und fasst sie dort mit dem ebenfalls zu Wireshark gehörenden Tool mergecap zusammen:
for %a in (*.pcapng) do tshark -r %a -Y "udp.port eq 53 or tcp.port eq 53" -w subdir\%a cd subdir mergecap -w single-file.pcapng *.pcapng
Firmen-Admins nutzen tshark-Analysen auch zur Qualitätskontrolle: Wer beispielsweise einen öffentlichen autoritativen DNS-Server betreibt, kann die von Clients verwendeten DNS-Flags auslesen. So lassen sich Missetäter identifizieren, die fälschlicherweise rekursive DNS-Anfragen senden: dns.flags.recdesired.
Qualitätskontrolle bei IPv6
Wenn Sie Server betreiben, die auf IPv6 antworten, bietet es sich an, ICMPv6-Fehlercodes zu analysieren. Die kommen von Backbone-Routern und Firewalls, wenn sie IPv6-Antwortpakete Ihres Servers nicht zustellen können. Mögliche Ursachen sind fehlende Routen, Routing-Loops oder auch blockierende Firewall-Policies. Um Fehler innerhalb Ihres eigenen Netzes auszuschließen, hilft der Blick auf die Details. Dabei sind folgende zwei Felder relevant: -e icmpv6.type -e icmpv6.code.
Wenn darin der Fehler „Typ 1 Code 0“ steckt, bedeutet das „no route to destination“. Router senden ihn, wenn sie ein Paket mangels korrekter Route nicht zustellen können. Wenn Ihr Server diesen Fehler beim Versuch erhält, auf eine Anfrage aus dem Internet zu antworten, ist die Source-IPv6-Adresse vielleicht gefälscht oder das Routing des entfernten Netzes vermurkst.
„Typ 1 Code 3“ beziehungsweise „address unreachable“ bedeutet, dass der letzte Router des Übertragungspfads die Ziel-IPv6-Adresse (Layer 3) nicht zur MAC-Adresse (Layer 2) auflösen konnte. Das kann an fehlkonfigurierten IPv6-Stacks von Clients oder versehentlichem Blocken der IPv6-Neighbor-Solicitations liegen – diese sind für die Auflösung erforderlich. In beiden Fällen kann der Client nicht per IPv6 kommunizieren – verwunderlich, dass es noch keinem auffiel.
„Typ 3 Code 0“ beziehungsweise „hop limit exceeded in transit“ ist der Klassiker unter den ICMPv6-Fehlern. Er deutet auf einen Routing-Loop hin: Zwei Router referenzieren sich gegenseitig, womöglich gehören sie zu Ihrem Netzwerk. Ob das der Fall ist, finden Sie mit dem Befehl
traceroute heraus.
Dass solche Fehler alltäglich sind, demonstriert eine Liste von vier Servern des NTP-Pools. Binnen 24 Stunden liefen Tausende von ICMPv6-Fehlermeldungen auf, die mit dem folgenden Skript extrahiert wurden:
tshark -r ntp-outside.pcapng -Y "icmpv6" -T fields -e icmpv6.type -e icmpv6.code | sort | uniq -c
Erstaunlicherweise traten gleich sieben Fehlertypen auf. Da liegt noch einiges im Argen bei der IPv6-Implementierung mancher Netzbetreiber.
Security-Analysen mit tshark
Die Datenaufbereitung mit tshark hilft auch bei der Analyse von Security-Problemen. So hat der Autor damit untersucht, ob Load-Balancer von F5 Networks gegen die Logjam-Attacke anfällig sind. Logjam nutzt aus, dass ältere TLS-Implementierungen bei der Diffie-Hellman-Schlüsselvereinbarung öffentliche Schlüssel (Public Keys) nicht nur einmal, sondern mehrfach verwenden. Das können Angreifer nicht nur nutzen, um verschlüsselte Inhalte mitzulesen, sondern auch um sie zu verfälschen.
Startpunkt für die Analysen ist Wireshark. Im Mitschnitt suchen Sie zunächst ein Paket mit dem Handshake-Type „Server Key Exchange“. Im Bildbeispiel ist dieses Element mit (1) markiert. Den Ausdruck als Display-Filter eingesetzt (2), zeigt Wireshark die Pakete mit diesem Inhalt an. Der Bezeichner dieses Felds (3) erscheint nach einem Klick unten (4). Praktisch: Per Rechtsklick und „Apply as Column“ blendet Wireshark dieses Feld als zusätzliche Spalte in der Paketübersicht ein (5). Schon offenbart sich, dass die ersten vier Einträge – also Public Keys – identisch sind.
Damit ist das Problem bewiesen und man braucht tshark eigentlich nicht mehr, aber Trace-Files lassen sich nicht immer in Wireshark öffnen. Manche liegen auf entfernten Rechnern und wenn sie groß sind, lohnt die Übertragung für solche Analysen kaum. Also nutzt man tshark über ssh direkt auf dem fernen Rechner: Public Keys identifizieren Sie über die Optionen -Y tls.handshake.type == 12 sowie -T fields -e tls.handshake.ys und sortieren die Ausgabe wieder mit sort | uniq -c | sort /R.
Letztlich hängt es stark von der Anwendung ab, welche Paketfelder man isolieren will. tshark bietet Ihnen genau diese Möglichkeit und bewahrt Sie davor, im Morast einer riesigen Trace-Datei zu versinken. Mit wenigen Handgriffen untersuchen Sie das Surfverhalten Ihres Sprösslings oder Ihrer IoT-Geräte selbst – mausschonend und ohne Copy-&-Paste, Zettelwirtschaft oder Excel.
Der Netzwerkverkehr lässt sich je nach Gerät auf unterschiedliche Weise aufzeichnen: Auf dem lokalen PC nimmt man klassisch Wireshark. Das bietet Wireshark direkt nach dem Programmstart an; man muss lediglich die Netzwerkschnittstelle auswählen und den Start-Button klicken.
Den Verkehr von Geräten, auf denen Wireshark nicht läuft, kann die Mitschnitt-Funktion des Routers liefern. Auf den verbreiteten Fritzboxen findet man sie unter der Adresse http://fritz.box/html/capture.html, auf manchen Speedport-Routern unter http://www.speedport.ip/html/capture.html.
Im Firmen-Umfeld gehört Packet-Capturing bei modernen Firewalls wie denen von Palo Alto Networks oder Fortinet zum Pflichtenheft, man startet es über deren Konfigurationsseiten. Um den Durchsatz nicht in die Knie zu zwingen, sollten Sie den Mitschnitt auf die IPv4- und IPv6-Adressen des interessierenden Clients beschränken.
An Firmen-Switchen mit Port-Mirroring, auch SPAN-Port (Switched Port-Analyzer), können Sie den Verkehr ausleiten. Wenn man den Client-Port vorübergehend auf 100 MBit/s drosselt, reicht die Kapazität des Mirror-Ports (1 GBit/s) sicher für beide Richtungen. Aber mit der langsamen Datenrate kann der Fehler verschwinden.
Admins mit größerem Budget greifen deshalb zu einem professionellen Terminal Access-Point (TAP) mitsamt Capture-Card. Erst der schreibt sämtliche Pakete jederzeit korrekt mit und liefert so genaue und zuverlässige Traces.
Unabhängig vom Aufzeichnungsgerät werden die Mitschnittdateien üblicherweise in den Formaten PCAP oder PCAPNG gespeichert, die Wireshark, tshark und Konsorten verstehen.
Photo by Maxim Hopman on Unsplash.