Netzwerk-Analyse mit Wireshark: Mitschnittfilter versus Anzeigefilter

Der Nachteil besteht darin, dass alles, was nicht mitgeschnitten wurde, nachträglich nicht mehr zugänglich ist, weil die Daten nicht aufgezeichnet wurden. Außerdem weisen Mitschnitt­filter einige Einschränkungen hinsichtlich der Formulier­barkeit bestimmter Ausdrücke auf.

Die Capture-Filter finden sich im Menü Aufzeichnen => Optionen. Dort markiert man im oberen Bereich das gewünschte Interface und formuliert am Fuß des Dialoges bei Mitschnitt­filter für die ausgewählte Schnittstelle den gewünschten Filter gemäß der BPF-Syntax. BPF steht dabei für Berkeley Paket Filter oder kurz Berkeley Filter.

Berkeley Filter

Die Funktion der Berkeley Filter ist als Interpreter in Maschinen­sprache für die BPF-VM imple­mentiert. So können Anwendungen auf einfache Weise Daten aus dem Paket lesen, arith­metische Operationen darauf ausführen, das Ergebnis mit der Filter­definition vergleichen und das Paket dann akzeptieren oder verwerfen.

Erstmals mit WinPcap wird zur Leistungs­verbesserung auch eine Just-in-time-Kompi­lierung unterstützt. Seit diese auch für Linux funktioniert, hat sich BPF in der Unix-Welt zu einer univer­salen virtuellen Maschine im Kernel entwickelt, so dass BPF sogar offizielles Back-End für LLVM ist.

Unter dem Strich verwendet Wireshark also für Capture-Filter dieselbe Syntax wie tcpdump, WinDump, Analyzer und jedes andere Programm, das die Libpcap oder WinPcap-Libs verwendet.

Mitschnittfilter für DNS

Im folgenden Beispiel filtern wir die DNS-Kommunikation des Clients 192.168.1.200 beim Aufruf einer Webseite (google.de).

Hier liefert der DNS-Server im lokalen Netz (192.168.0.12) über UDP Port 53 (DNS-Anfrage/Antwort) den A-Record-Eintrag für www.google.de mit der IP-Adresse 172.217.23.163 an den anfragenden Client (192.168.1.200). Der Source-Port des DNS-Servers ist wie erwartet 53.

Anzeige­filter

Anzeige­filter werden im Anschluss an einen bereits erfolgten (ggf. nicht gefilterten) Mitschnitt nach dem Muster TCP-Port == 80 formuliert. Dies geschieht in der Eingabezeile direkt unterhalb der Werkzeug­leiste.

Hacker, denen es etwa gelingt, ein bestimmtes Interface aufzuzeichnen, werden eher einen vollständigen Mitschnitt bevorzugen, diesen speichern, entwenden und im eigenen Wireshark neu laden, um in aller Ruhe mit Anzeige­filtern experimentieren zu können.

Funktionen zum Speichern und Exportieren bzw. Laden und Importieren von ganzen Mit­schnitten oder speziellen Paketen (so genannten Paket-Dissektionen) finden sich im Menü Datei.

Wir gehen in der Folge davon aus, dass wir den Mitschnitt aus dem obigen DNS-Beispiel zur Verfügung haben und darauf nun jederzeit nachträglich Anzeige­filter anwenden können.

Nach IP-Adresse filtern

Mit

ip.addr == 8.8.8.8

reduzieren wir die Anzeige auf alle Pakete im Mitschnitt, die entweder die IP-Adresse 8.8.8.8 als Absender oder als Zieladresse verwenden. Identisch mit der Verwendung eines Mitschnitt­filters ist, dass die Anzeige beim Formulieren eines validen Filterausdrucks grün wird.

In unserem Beispiel erwischen wir damit genau ein Paket, nämlich die DNS-Antwort des Google-DNS-Servers (8.8.8.8) im Rahmen einer UDP-basierten DNS-Abfrage durch den Client (192.168.1.200) nach der IP-Adresse (A-Record) von googleleads.g.doubleclick.net.

Filterhierarchien

Gehen wir einige weitere Anzeige­filter durch: Beginnt man mit dem Formulieren eines Filters, dann unterstützt der Eingabeassistent den User mit der Anzeige der möglichen Kontexte in verschiedenen Ebenen, jeweils getrennt durch einen Punkt, ähnlich wie bei der objekt­orientierten Program­mierung.

Wir reden also von einem Filterobjekt mit dem Namen "ip", das wiederum eine Reihe von "Methoden" (im Prinzip sind das Unterfilter) kennt.

Fahren wir damit fort, beim Filtern andere Protokolle anzuwenden, wie "tcp", "udp" oder "icmp", ähnlich wie wir es bereits bei den Mitschnitt­filtern getan haben.

Protokollfilter

Beim Filtern nach Protokollen besteht also offenbar kein Unterschied zum Mitschnitt­filter. Allerdings können Mitschnitt­filter nicht auf Anwendungs­protokolle filtern. Das Eingrenzen etwa auf HTTP (Layer 7) ist dort nur indirekt durch Angabe der Ports (80. 443 etc.) möglich. Bei den Anzeige­filtern hingegen können wir statt Port 53 auch direkt nach der DNS-Kommunikation filtern, indem wir "DNS" eingeben.

Wir sehen jetzt nur noch DNS-Pakete, allerdings sowohl TCP- als auch UDP-Pakete. Die weit verbreitete Annahme, die DNS-Kommunikation basiere nur auf UDP gilt nur für DNS-Anfragen und Antworten zwischen Client und Server. Der Austausch zwischen DNS-Servern untereinander - etwa bei Zonen-Transfers - findet via TCP-Port 53 statt.

Wir können jetzt auch direkt nach HTTP filtern, würden dann aber tatsächlich nur Pakete sehen, die HTTP verwenden und nicht etwa die gesamte HTTP-Session im Browser mitsamt ACK-Paketen und dem TCP-Handshake. Auch OCSP-Pakete im Rahmen der Zertifikats­behandlung würden dann nicht erfasst.

Anzeigefilter für FTP

Für folgendes Beispiel starten wir eine ungefilterte Aufzeichnung einer FTP-Kommunikation. Dafür bauen wir eine nicht SSL-gesicherte FTP-Sitzung zum FTP-Server 192.168.1.124 (Ubuntu) vom Windows-Client 192.168.1.200 auf, führen einen Datei-Upload mittels Filezilla durch und beenden die Aufzeichnung.

Je nachdem, wie viel andere Partner in dem entsprechenden Netzwerk­segment aktiv sind und wie lange man für die beschriebenen Aktionen benötigt, kann die Aufzeichnung mehr oder weniger Pakete enthalten, in unserem Fall 2205 Stück.

Nun können wir gezielt Anzeige­filter verwenden. Bei einem Mitschnitt­filter wären wir dabei auf die Port-Ebene (21 für die Control-Port, 20 für die Data-Ports der einzelnen Übertragungs-Sitzungen) beschränkt. Jetzt können wir aber gezielt auf das Anwendungs­protokoll FTP filtern.

Wir sehen hier alle Pakete, bei denen das Anwendungs­protokoll "FTP" beteiligt ist. Die Anzeige lässt sich aber nun über die geschilderte objekt­ähnliche Hierarchie weiter verfeinern, indem wir mit "ftp.request" nur nach FTP-Paketen fahnden, die einen "Request" repräsentieren.

Das klappt nicht nur auf der Anwendungs-, sondern auch auf der Netzwerk­ebene. So filtert

tcp.flags.syn == 1

nach allen TCP-Paketen, bei denen das SYN-Flag gesetzt ist, also nach der jeweils ersten Antwort beim TCP-Handshake.

Filtervorschläge

Filtern auf MAC-Adressen

eth.addr == 00:50:56.14.a2.fb

eth.src == 00:50:56.14.a2.fb

eth.dst == 00:50:56.14.a2.fb

Das Filtern auf IP-Adressen

ip.addr == 192.168.1.33

ip.src == 192.168.1.33

ip.dst == 192.168.1.33

Negieren von Filtern

!ip.addr == 192.168.1.33 bzw. not ip.addr == 192.168.1.33

Logisches Verknüpfen

snmp || icmp || dns

snmp or icmp or dns

tcp.window_size == 0 && tcp.flags.reset != 1

TCP-Pakete nach Strings filtern

tcp matches "String"

tcp contains "String"

http.request.uri matches "gl=se$"