Netzwerk-Analyse mit Wireshark: Mitschnittfilter versus Anzeigefilter


    Tags: , ,

    Wireshark AnzeigefilterMittschnitt- bzw. Capture-Filter werden in Wireshark primär verwendet, um die Größe einer Paket­erfassung zu reduzieren, sind aber weniger flexibel. Anzeige­filter dagegen blenden im Anschluss an einen (vollständigen) Mitschnitt bestimmte Pakete wieder aus. Dieser Beitrag zeigt, wie man diese Filtertypen nutzt.

    Grundsätzlich handelt es sich bei Mitschnitt­filtern um eine Art Server-seitiges Filtern, man zeichnet also von vorne herein nur diejenigen Pakete einer Kommunikation auf, für die man sich interessiert. Der Vorteil ist, dass sich die Menge der Daten gezielt eingrenzen und so erheblich reduzieren lässt.

    Weniger Daten, geringere Flexibilität

    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).

    Wireshark-Mitschnittfilter für die DNS-Kommunikation

    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.

    Ergebnis der DNS-Aufzeichnung auf Basis eines Capture-Filters

    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.

    Wireshark bietet bei der Formulierung von Anzeigefiltern eine Type-ahead-Unterstützung.

    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.

    Die von Wireshark angezeigten Subfilter hängen vom gewählten Protokoll ab.

    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.

    Anzeigefilter für die DNS-Kommunikation

    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.

    Anzeigefilter für die FTP-Kommunikation

    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.

    Einschränken des Anzeigefilters auf FTP-Requests

    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.

    Einschränken der Anzeige auf TCP-Pakete, bei denen das SYN-Flag gesetzt ist.

    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$"

    Keine Kommentare