Fritzchens Netzwerkanalyse mit Hausmitteln - Teil 1: Aufzeichnung von DNS-Anfragen

Die Hausmittel sind eine Fritzbox und ein PC, auf dem die Freeware Wireshark installiert wird. Teil 1 konzentriert sich auf das DNS-Protokoll.

Wer den Abfluss persönlicher Daten über das Internet kontrollieren will, kommt nicht daran vorbei, diesen Datenverkehr vernetzter Geräte mit geeigneten Werkzeugen zu überwachen und zu beschränken. Dazu gibt es verschiedene Möglichkeiten:

- Analyse mit Firewall- und Filterapps wie RethinkDNS (Android), AdguardPro (iOS), Portmaster (PC), direkt auf dem vernetzten Gerät 
Ein Nachteil dieser Methode ist, dass sie nur auf Geräten funktioniert, die Installation solcher Software erlauben. Spielekonsolen oder vernetzte Smart Home Systeme fallen nicht darunter. Eine Einschränkung ist, dass Betriebssysteme einen Teil des Netzverkehrs an solchen Apps oder ihren VPN-Tunneln vorbeileiten, womit dieser Teil des Datenverkehrs unsichtbar wird. Für Android ist dies z.B. für Closed-Portal Anfragen dokumentiert [1]. Zuletzt lässt sich im wesentlichen nur DNS- und IP-basierter Datenverkehr analysieren, andere Protokolle, wie WLAN Probe-Requests dagegen nicht.

- Analyse mit DNS-Servern und -Diensten, wie Pihole, NextDNS
Auch diese Verfahren sind auf das Überwachen des DNS- und IP-basierten Datenflusses beschränkt. Ein eigener DNS-Server wie Pihole muss erst eingerichtet werden, wer Dienstleister wie NextDNS in Anspruch nimmt, muss diesen vertrauen, da sie jede aufgerufene Internetseite selbst protokollieren können.

Hier soll eine weitere Methode vorgestellt werden. Mit ihr lassen sich alle Protokolle und der komplette Datenstrom im Heimnetz aufzeichnen und die Mittel dazu sind in vielen Haushalten bereits vorhanden: Eine Fritzbox und ein PC (Linux, Windows, MAC), auf dem die Freeware Wireshark installiert wird. Fritzboxen haben ein Debugmenu, das die Aufzeichnung des Datenverkehrs erlaubt, der durch die Fritzbox geschleust wird, unabhängig davon ob der Verkehr innerhalb des Heimnetzes über WLAN, LAN läuft oder hinaus ins Internet geht. Das Verfahren eignet sich, um den Datenverkehr eines Gerätes stichprobenartig und auf Wunsch in der Tiefe zu analysieren. Für ein dauerhaftes Monitoren und Filtern ist die Methode wenig geeignet. Dafür empfehlen sich die genannten DNS-basierten Verfahren oder eine Filterliste in der Fritzbox.
Ich zeichne beispielsweise bei neuen, vernetzten Geräten beim ersten Hochfahren, sowie gängigen Betriebszuständen, wie einem längeren Stand-by den Datenverkehr mit der Fritzbox auf, vor allem das DNS-Protokoll. Das verschafft einen Überblick wohin gefunkt wird. Wenn alles ok ist, darf das Gerät uneingeschränkt in Betrieb gehen, bei kleineren Verstößen werden unerwünschte Verbindungen blockiert und wenn es ganz schlimm kommt, kann das Gerät zu dem Zeitpunkt zurück zum Händler gehen. Mit Gerät ist hier alles gemeint, was selbständig Internetverbindungen aufbauen kann, von Software, wie einem Druckertreiber über WLAN-vernetzte Heimgeräte, wie Roboterstaubsauger bis hin zu Spielekonsolen, PCs, Smartphones, Tablets. Unbedingt empfehlenswert ist dieses Vorgehen bei allem, was das Präfix "Smart-" im Namen trägt, also z.B. bei Smart-TVs, Smart-Home Ausrüstung...
Zwar haben alle Fritzboxen, die mir begegnet sind, das Debugmenü. Es ist dennoch nicht immer empfehlenswert an einer Fritzbox den Datenverkehr aufzuzeichnen, während sie von anderen Haushaltsmitgliedern gleichzeitig zum Streamen, Surfen, Zocken verwendet wird. Die verschiedenen Datenströme lassen sich nachträglich an Hand der IP-Adressen wieder separieren, die aufgezeichnete Datenmenge kann in einem solchen Fall jedoch schon nach kurzer Zeit Gigabyte erreichen und ist dann schwer zu verarbeiten. Ich verwende daher für bestimmte Analysen eine alte, sonst ausrangierte Fritzbox. Diese ist dafür völlig ausreichend, in meinem Fall selbst ein über 10 Jahre alter DSL-Vertragsrouter. Es muss nur sichergestellt sein, dass die Box das zu untersuchende Protokoll beherrscht. Meine Uralt-Fritzbox ist eine 7330SL aus einem DSL-Vertrag. Sie kann z.B. nicht im 5GHz-Band über WLAN funken. Dieses Band kann ich mit ihr also nicht aufzeichnen, das 2,4Ghz-Band dagegen schon. Ich betreibe sie im Routermodus, schließe sie also an den LAN-Ausgang des Hauptrouters an und das zu untersuchende Gerät an einen LAN-Ausgang oder das WLAN-Netz der 7330SL. Dazu in dieser Box in den Einstellungen / Internet / Zugangsdaten "Externes Modem oder Router" aktivieren. Der Hauptrouter, der über sein Modem die Verbindung zum Internet herstellt, muss dabei keine Fritzbox sein, diese Analyse ist also in Verbindung mit jedem Router möglich. Alte Fritzboxen wie die 7330SL bekommt man für kein Geld angeboten, in vielen Haushalten schlummern sie auf dem Dachboden oder im Keller. Das Debugmenü wird bei Fritzboxen über diesen Browserlink erreicht:
http://[IP-Adresse]/html/capture.html
[IP-Adresse] ist die IP-Adresse der Fritzbox im Heimnetz. Mit nur einer Fritzbox im Netz funktioniert auch "fritz.box" an Stelle der IP-Adresse. Der Browser muss mit demselben Netz, wie die Fritzbox verbunden sein. Nach Login mit der regulären Nutzerkennung öffnet sich die Seite Paketmitschnitte, wie sie in Abb. 1 für zwei unterschiedliche Fritzboxen abgebildet ist. Ein alternativer Zugang führt über "Hilfe und Einstellungen" in der Bedienoberfläche, dann FRITZ!BoxSupport / Paketmitschnitte.

Abb. 1: Die Menüs für Paketmitschnitte innerhalb des Debugmenüs. Erste beiden Spalten: Fritz!Box 6591 Cable. Rechte Spalte: Fritz!Box 7330SL

Der Umfang des Menüs für Paketmitschnitte variiert von Fritzbox zu Fritzbox. AVM gibt leider keine Anleitung dazu heraus, außer einer sehr kurzen [2]. Bis zu einem Punkt ist das Menü selbsterklärend. Bei den gelisteten Schnittstellen, wie "eth0", "eth1", "wifi0" oder "Internetverbindung" handelt es sich anscheinend um die jeweiligen Hardware- und Softwareschnittstellen der Fritzbox. Da die 7330SL nur zwei Ethernetbuchsen (LAN) hat, gibt es auch nur "eth0", "eth1". Die 6591 hat dagegen 4 Buchsen und daher im Menü auch vier dieser Schnittstellen. Experten für Netzwerktechnik, die u.a. mit dem OSI-Schichtmodell vertraut sind, werden sich mehr dieser Schnittstellen erschließen können bis hin zu rätselhaften wie ":erspan0". Ich habe herausgefunden, dass es sich bei "wifi0" um die Hardwareschnittstelle und bei "ath0" um die Logikschnittstelle des WLAN-Netzes handelt [3]. Die Logikschnittstellen liefern im Vergleich zu den Hardwareschnittstellen die für den Anwender interessanteren Daten, wie den DNS-Verkehr und Probe-Requests. Zwischen den mit "0" und "1" bezeichneten Schnittstellen, z.B. "AP(2,4GHz, ath0) - Schnittstelle 0" und "..-1" konnte ich keinen Unterschied feststellen. Dort scheinen jeweils dieselben Daten anzufallen. Offensichtlich nutzen die Fritzboxen das Debugtool DTrace zur Aufzeichnung der Paketmitschnitte. Profis können auch hier mehr herausholen und das Tool mit Parametern programmieren. Laien sollten sich von all diesen technischen Details nicht abschrecken lassen. Die diversen Schnittstellen können einfach durchprobiert werden, um herauszufinden, wo gesuchte Daten zu finden sind. Da ein Datenstrom mehrere Schnittstellen einer Fritzbox durchläuft z.B. zuerst vom WLAN kommend "ath0", dann in Richtung Internet die "Internetverbindung" können dieselben Daten an mehreren Schnittstellen anfallen. Gestartet wird die Aufzeichnung an einer Schnittstelle durch Druck der "Start" Taste, gestoppt durch die "Stopp" Taste. Es können mehrere Aufzeichnungen parallel laufen. Das Ergebnis wird pro Schnittstelle als ETH-Datei im Downloadverzeichnis des Browsers abgelegt. Die Verbindung zur Fritzbox darf während der Aufzeichnung natürlich nicht unterbrochen werden.
Zur Durchsicht und Analyse der ETH-Dateien muss das freie Programm Wireshark auf einem PC installiert sein. Es sind keine Add-ons wie Npcap notwendig, da der Netzverkehr von der Fritzbox und nicht dem PC erfasst wird. Doppelklick auf eine ETH-Datei öffnet sie normalerweise in Wireshark in einer Tabellenansicht.
Im Folgenden stelle ich wenige, beispielhafte Analysen vor, zuerst des DNS-Verkehrs, in einem folgenden zweiten Artikel über WLAN Probe-Requests. Das DNS-Protokoll ist von Interesse, da es einen Überblick bietet, welche Internetadressen bzw. URLs kontaktiert werden. Dies sind Analysen, die ohne große Vorkenntnisse möglich sind. Wer tiefer einsteigen will, findet unbegrenzte Möglichkeiten und vielfältige Anleitungen im Internet, bis hin zum Auslesen von verschlüsseltem Datenverkehr mit einem Man in the Middle Angriff, wie z.B. hier beschrieben [4]. Damit würden wir uns allerdings vom Einsteigerniveau und dem Thema dieser Anleitung entfernen.

1. Beispiel eines Paketmitschnitts

Im ersten Beispiel wurde an der "ath0" Schnittstelle der Fritzbox 7330SL eine Aufzeichnung des WLAN-Verkehrs gestartet und dann ein Androidgerät von Samsung mit diesem WLAN-Netz verbunden. Nach wenigen Sekunden, ohne auf dem Androidgeräte besondere Aktionen auszuführen, wurde die Aufzeichnung gestoppt und die ETH-Datei in Wireshark geladen. Das Ergebnis ist in Abb. 2 zu sehen.

Abb. 2: Die ersten Sekunden des WLAN-Mitschnitts eines frisch verbundenen Androidgerätes des Herstellers Samsung. Private IP-Adressen gekürzt, geschwärzt.

Wireshark zeigt den Mitschnitt tabellarisch an. In der ersten Spalte sind die aufgezeichneten Datenpakete mit laufender Nummer versehen. Die zweite Spalte gibt die Zeit in Sekunden, die seit dem Start der Aufzeichnung vergangen ist. Als nächste Spalten folgen "Source" und "Destination", also Absender und Adressat. Mein Samsunggerät und die Fritzbox geben sich hier mit Herstellernamen zu erkennen ("SamsungE...", "AVM"). Ansonsten werden hier IP-Adressen angegeben. Dreierblöcke aus Zahlen mit Punkten, wie 192.168... sind Adressen im IPv4-Format. Viererblöcke mit Doppelpunkt dazwischen, wie 2a02:81... sind Adressen im neueren IPv6 Format. In der Spalte Protocol ist das Protokoll des Datenpakets angegeben. Alle aufgezeichneten Protokolle in Summe bilden die Internet-, LAN- oder WLAN-Protokollfamilien. Diese Familien bestehen aus mehreren hundert Einzelprotokollen. Den größten Teil der Protokolle, die in Wireshark angezeigt werden, ignorieren wir daher im Folgenden und beschränken uns in diesem Artikel auf das DNS-Protokoll. In Abb. 2 handelt es sich bei den Datenpaketen #12 und #16 um DNS-Anfragen. #12 ist eine DNS-Anfrage ("query") für die URL- oder Domainadresse "www.google.com", wie in der Spalte "Info" zu lesen ist. #16 gibt die Antwort auf diese Anfrage ("query response") und zwar in Form der IP-Adresse 142.250.186.36, die zur URL "google.com" gehört, wie wieder in der Spalte "Info" in Wireshark nachzulesen ist.
Das DNS-Protokoll bildet das Adressbuch des Internets. DNS-Anfragen richten sich an einen Server, den DNS-Resolver, der im Betriebssystem, einer App, dem Router oder vom Internet-Serviceprovider vorgegeben wird. Eine DNS-Anfrage sendet die URL einer gesuchten Internetseite an den DNS-Resolver, dieser gibt die IP-Adresse der gesuchten Seite zurück. Erst danach kommt über die IP-Adresse die eigentliche Verbindung zustande. Es gibt verschiedene Gründe, weshalb dieser Umweg gegangen wird, anstatt direkt eine Anfrage an die IP-Adresse zu senden. Menschen können sich Namen wie Google besser merken, als eine lange Nummer. Andererseits können Betreiber von Internetadressen den Datenverkehr über das DNS-Protokoll steuern und z.B. eine IP-Adresse des nächsten Servers zurückgeben, anstatt einer Adresse auf der anderen Seite des Globus. Daher starten fast alle Internetverbindungen mit einer DNS-Anfrage. Für den Datenschutz ist dieses System ein Bonus, denn unerwünschte Verbindungen lassen sich in diesem Protokoll leicht blockieren, indem auf eine DNS-Anfrage mit einer ungültigen IP-Adresse geantwortet wird, so dass die Verbindung das gewünschte Ziel nicht erreichen kann. Um die Verbindung zu Google oben zu blockieren, könnte ein Filter, der irgendwo zwischen Gerät und DNS-Resolver arbeitet, in der DNS-Response die echte IP-Adresse 142.250.186.36 von Google durch eine Dummy-Adresse wie 0.0.0.0 ersetzen, die ins Nirgendwo führt.
Diese in Abb. 2 beobachtete DNS-Anfrage für eine Verbindung zu Google ist tatsächlich nicht so harmlos, wie sie zunächst aussieht. Androidgeräte prüfen jedes Mal, wenn sie sich neu mit einem WLAN-Netz verbinden, ob sie Verbindung ins Internet haben, indem sie einen Closed-Portal Verbindungscheck starten. Bei Androidgeräten ist dafür z.B. die URL "www.google.com" voreingestellt. Die eigentliche Problematik ist, dass diese Verbindungen an einem aktiven VPN vorbeigeleitet werden, falls ein solches auf dem Androidgerät aktiv ist [1]. Dies ist in diesem Beispiel der Fall. Auf dem Gerät arbeitete während der Aufzeichnung die Firewall-App Rethink-DNS, die lokal auf dem Gerät ein VPN aufbaut, um möglichst den gesamten Datenverkehr darüber zu leiten und zu filtern. Da der Verbindungscheck zu Google aber am VPN vorbeigeleitet wird, ist er in Rethink-DNS und vergleichbaren Firewalls nicht zu beobachten und damit auch nicht zu filtern. Gegenüber der Fritzbox als Router lässt sich ein solches VPN-Leak jedoch nicht verstecken. VPN-Leaks lassen sich also erkennen, indem der Datenverkehr innerhalb und außerhalb des VPN-Tunnels aufgezeichnet und verglichen wird. Beim untersuchten Samsung-Tablet lässt sich dieses VPN-Leak abstellen, indem in den Einstellungen für Verbindungen / VPN beim betreffenden VPN der Schalter "Verbindungen ohne VPN sperren" aktiviert wird. Das hat aber zur Folge, dass die Internetverbindung und andere Netzwerkprotokolle gelegentlich blockiert sind.

2. Mitschnitt des DNS-Verkehrs

In der zweiten Analyse wird der DNS-Verkehr einer Drucker-Scannerkombination des Herstellers HP aufgezeichnet. Der Drucker dient hier als einfaches Beispiel für alle möglichen vernetzten Geräte im Haushalt, mit eingeschränkter Bedienoberfläche, die dennoch "nach Hause" funken können. Er verfügt über eine Ethernetbuchse, die mit der Ethernetbuchse 1 der Fritzbox 7330SL verbunden wird. Der Paketmitschnitt wird daher an der Schnittstelle "eth1" im Debugmenü gestartet. Während des Mitschnitts wird der Drucker gestartet, ausgeschaltet, neu gestartet, es wird ein Blatt gedruckt und gescannt. Für ca. 15min werden somit die Betriebszustände durchgespielt, bis der Mitschnitt wieder gestoppt wird.
In Abb. 2 ist zu sehen, dass ein Paketmitschnitt Dutzende unterschiedliche Protokolle enthält. Es ist daher mühsam in einem solchen Mitschnitt die gesuchten Datenpakete zu finden, insbesondere bei längeren Mitschnitten über einige Minuten oder Stunden. Aus diesem Grund verfügt Wireshark über Filter. Damit lässt sich z.B. nach Protokollen filtern. Filter für das DNS-Protokoll sind:
udp.port==53        DNS Queries und Responses
udp.dstport==53        DNS Queries
udp.srcport==53        DNS Responses
Der DNS-Verkehr läuft also über Port 53. Im Fall des Druckers interessiert hier, wohin er sich verbinden will. Es reicht also nach den Queries zu filtern. Der Filter wird in die Befehlszeile von Wireshark eingegeben. Abb. 3 zeigt das Ergebnis mit dieser Filterung.

Abb. 3: Die DNS-Queries einer HP Drucker-Scannerkombination über eine Betriebsdauer von ca. 15min

Der Drucker verbindet sich offensichtlich nach jedem Einschalten mit der URL "ccc.hpeprint.com" und im laufenden Betrieb alle paar Minuten mit der URL "deviceregistration.avatar.ext.hp.com". Diese letzte Verbindung hängt zeitlich nicht direkt mit Betriebszuständen zusammen. Der Drucker sendet also Daten zu seiner Nutzung zurück an HP. Es muss daher davon ausgegangen werden, dass hier Nutzertracking stattfindet. Dies ist wohlgemerkt der Datenverkehr des Druckers selbst. Zusätzlich könnte auch auf einem PC installierte Druckersoftware wie Treiber oder Wartungsprogramme Datenverkehr verursachen. Um das zu verifizieren müsste der Datenverkehr des PCs überwacht werden.
Wer sich nicht derart von einem Drucker und vergleichbaren Geräten überwachen lassen will, kann diese URLs blockieren. Fritzboxen, die als Modem den Internetzugang verwalten, erlauben das Anlegen einer Sperrliste oder das komplette Sperren des Internetzugangs für ein Gerät im Heimnetz. Wer DNS-Filter wie Pi-Hole oder NextDNS verwendet, kann die URLs dort der Sperrliste hinzufügen. Ein Drucker kann zudem ohne Netzzugang über einen USB-Anschluss betrieben werden und sendet bei dieser Anschlussart selbst keine Daten ins Internet.
Falls Zweifel bestehen, ob bestimmte Internetverbindungen von Nutzen für einen Anwender sind, kann eine Internetrecherche weiterführen. Die beiden URLs des Druckers sind tatsächlich rudimentär online dokumentiert. Die erste wird für "HP Customer Care Center Logging (CCC)" benutzt, die zweite für "HP Cloud Services".
Fortgeschrittene können versuchen, den Paketmitschnitt selbst weiter zu analysieren, über die Datenpakete, die dem DNS-Request folgen und an die im DNS-Response offengelegte IP-Adressen von HP gehen.
Soweit der erste Teil zur Netzwerkanalyse mit der Fritzbox zur Aufzeichnung des DNS-Datenverkehrs. Im folgenden zweiten Teil steigen wir dann mit WLAN Probe-Requests tiefer in die Thematik ein.

[1] https://www.darkreading.com/cloud-security/android-leaks-wi-fi-traffic-vpn-protection-features-on 
[2] https://fritz.com/apps/knowledge-base/FRITZ-Box-7590/1572_Paketmitschnitt-LAN-Support-Daten-der-FRITZ-Box-erstellen/ 
[3] https://community.ui.com/questions/Meaning-of-wifi0-wifi1-and-ath0-interfaces-on-NBE-5AC-19/4bc8acca-0358-4fe7-8cd2-203a6378d67e 
[4] https://www.kuketz-blog.de/android-grapheneos-calyxos-und-co-unter-der-lupe-custom-roms-teil1/