Raspberry Pi VPN – Teil 10: Datenanalyse mit Wireshark

Helmut 25. August 2019 0 Kommentare

Im Rahmen dieser Artikelserie haben wir aus Sicherheitserwägungen heraus einen VPN-Tunnel vom Smartphone ins heimische Netzwerk aufgebaut. Zentraler VPN-Server ist dabei ein Raspberry Pi. Auf ihm haben wir zusätzlich Pi-Hole installiert, um durch Beeinflussung der DNS Namensauflösung, Werbung und Tracking-Dienste blockieren zu können. Die Web-Oberfläche von Pi-Hole bietet dabei einen aufschlussreichen Blick auf alle Domänennamen, die durch Browser und Apps auf dem Smartphone angefragt werden. Und damit auf alle Kommunikationsbeziehungen, die das Smartphone eingehen möchte. Nun wollen wir einen Schritt weiter gehen. Pi-Hole zeigt nur die Domänennamen der Kommunikationswünsche an, mit Wireshark sehen wir jedes Datenpaket.

Was ist Wireshark?

Ich zitiere mal Wikipedia:

Wireshark (englisch wire „Draht“, „Kabel“ und shark „Hai“) ist eine freie Software zur Analyse und grafischen Aufbereitung von Datenprotokollen (Sniffer), die 2006 als Fork des Programms Ethereal (englisch „himmlisch“, „ätherisch“, Anspielung auf Ethernet) entstanden ist.
Wikipedia

Wireshark ist also ein Schnüffler für Netzwerkdaten, der alle Datenpakete auf einer Leitung dekodieren und in einer grafischen Bedienoberfläche visualisieren kann.

Wer die ganze Artikelserie aufmerksam gelesen hat, dem könnte jetzt ein kleiner Widerspruch aufstoßen: Grafische Bedienoberfläche auf Raspbian Lite? Das geht natürlich nicht, Raspbian Lite ist ja die Version ohne grafischem Desktop.

Wie funktioniert das?

Wireshark bringt eine schlaue Funktion mit, nämlich remote probes, also entfernte Sonden. Was in der Übersetzung etwas sperrig klingt, ist nichts anderes als die Fähigkeit des Programms, nicht nur am eigenen Rechner zu sniffen, sondern auch auf anderen. Wir installieren Wireshark auf einem anderen Rechner unter Linux mit grafischen Desktop oder Windows und auf den Raspberry Pi kommt ein remote probe, also eine Sondensoftware, die dort die Daten aufzeichnet.

Installation

a) Wireshark Vollversion mit grafischer Bedienoberfläche

Für Windows und macOS können wir die Software hier herunterladen: https://www.wireshark.org/#download
und dann betriebssystemüblich installieren.
Mit Linux geht das ganz einfach mit:

sudo apt install wireshark

b) Remote Probe am Raspberry Pi

Hier gibt es (mindestens) zwei Varianten, Wireshark selbst bietet eine remote probe Software an mit dem Namen Tshark, die installiert sich am Raspberry Pi einfach mit:

sudo apt install tshark

Empfehlen möchte ich aber tcpdump anstelle von Tshark, damit wird die Konfiguration ein bisschen leichter. Tcpdump installieren wir am Raspberry Pi wie folgt

sudo apt install tcpdump

Nach der Installation können wir uns ansehen, welche Interfaces tcpdump erkennt:

sudo tcpdump -D
1.wlan0 [Up, Running]
2.tun0 [Up, Running]
3.any (Pseudo-device that captures on all interfaces) [Up, Running]
4.lo [Up, Running, Loopback]
5.eth0 [Up]
6.bluetooth0 (Bluetooth adapter number 0)
7.usbmon1 (USB bus number 1)

Interessant für uns ist tun0, das VPN-Tunnelinterface. Wir können auch tcpdump gleich mal etwas sniffern lassen:

sudo tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
19:10:53.833286 IP 10.8.0.2.54959 > ws-in-f188.1e100.net.5228: Flags [P.], seq 4098271724:4098271826, ack 4254323531, win 821, options [nop,nop,TS val 2387026 ecr 3591683413], length 102
19:10:53.887223 IP ws-in-f188.1e100.net.5228 > 10.8.0.2.54959: Flags [.], ack 102, win 253, options [nop,nop,TS val 3592334699 ecr 2387026], length 0
19:10:54.280333 IP 10.8.0.2.49647 > 10.8.0.1.domain: 57842+ A? apps.n-tv.de. (30)
19:10:54.315707 IP 10.8.0.1.domain > 10.8.0.2.49647: 57842 5/0/0 CNAME d1rorojlyakfyp.cloudfront.net., A 99.84.92.98, A 99.84.92.70, A 99.84.92.41, A 99.84.92.14 (137)

Mit Strg-C lässt sich die Ausgabe der Datenpakete wieder stoppen. Die Anzeige ist recht kryptisch, wir sehen aber auf jeden Fall im Beispiel ein paar Mal die IP-Adresse 10.8.0.2, das ist unser VPN-Client.

Konfigurieren und Aufzeichnen

Nachfolgend gehe ich davon aus, dass am Raspberry Pi tcpdump als remote probe installiert ist und nicht Tshark. Wir gehen also zum Desktop PC und starten dort Wireshark. Als erstes müssen wir ein Interface auswählen, auf dem Wireshark sniffen soll.

Dazu klicken wir auf das kleine schwarze Zahnrad vor SSH remote capture sshdump und bekommen dann ein Fenster mit den Schnittstellenoptionen.

In diesem Fenster konfigurieren wir alles, was Wireshark braucht um per SSH auf den Raspberry Pi zuzugreifen und dort einen Capture zu starten. Das sind:

Remote SSH server address: Der Name oder die IP-Adresse des Raspberry Pi
Remote SSH server port: Für SSH immer 22
Remote SSH server username: Ein User am Raspberry Pi, typischerweise Pi
Remote SSH server password: Das Passwort vom User Pi
Remote interface: Das Tunnelinterface (das wir nach der Installation ermittelt hatten)
Remote capture command: Kann bei Verwendung von tcpdump leer bleiben, denn tcpdump ist der default. Wer Tshark verwendet, muss hier tätig werden.
Use sudo on the remote machine: Kästchen bitte aktivieren
Remote capture filter: Hier muss nichts eingegeben werden, das macht Wireshark von alleine

Wer zwischen Raspberry Pi und PC eine Public Key Authentifizierung konfiguriert hat, um per SSH zum RasPi kein Passwort mehr eingeben zu müssen (was ich sehr empfehle), der kann unter Path to ssh private key seine .ssh/id_rsa Datei auswählen und das Passwort weg lassen.

Anhänger von Tshark als remote probe müssen mit den Einstellungen ein wenig experimentieren, denn hier muss explizit in der Konfigurationsmaske ein Remote capture command eingegeben werden. Bei mir hat es mit
/usr/bin/tshark -i tun0 -s0 -w -
gut funktioniert.

Mit einem Klick auf Start beginnt der Capture und nach wenigen Sekunden sollten die ersten Daten ankommen. Das sieht dann in etwa wie folgt aus.

Das Capturefenster ist dreigeteilt. Oben (bläulich hinterlegt) sieht man die einzelnen Frames (Datenpakete). Klickt man eins davon an (orange hinterlegt) dann wird im mittleren Fenster dieses Datenpaket analysiert und im unteren Fenster (rötlich hinterlegt) auf Byte- und Zeichenebene angezeigt.
Die Aufzeichnung lässt sich mit einem Klick auf das rote Quadrat oben in der Symbolleiste stoppen, danach kann die Aufzeichnung auch gespeichert werden.

Aufzeichnen und Auswerten

Wie kann man vorgehen und genau das aufzuzeichnen, was man haben möchte? In Wireshark lassen sich Aufzeichnungs- und Auswertungsfilter konfigurieren, wir können also das beschränken, was wir aufnehmen wollen und danach auch noch einmal die Anzeige. Aber leider lässt sich dabei kein Bezug zur jeweiligen App am Smartphone herstellen. Wir können Wireshark leider nicht sagen: „Nimm alles auf, was die App soundso sendet“. Das macht es ein bisschen schwierig. Sinnvoll könnte die folgende Vorgehensweise sein:

Für den Fall, dass Pi-Hole installiert ist, sollten wir uns zuerst entscheiden, ob Pi-Hole während der Aufzeichnung filtern soll, oder ob wir alle Kommunikationsbeziehungen sehen wollen.
Auf dem Smartphone sollten möglichst wenige Apps aktiv sein, die möglicherweise auch ins Internet kommunizieren wollen. Ggf. vielleicht das Smartphone einmal neu starten.
Jetzt am PC in Wireshark eine neue Aufzeichnung starten.
Und dann die App starten, deren Kommunikation wir aufzeichnen wollen.
Wenn zu erwarten ist, dass alle Daten übertragen wurden, dann können wir die Aufzeichnung stoppen und uns der Auswertung zuwenden.
Ggf. die Aufzeichnung speichern.

Ich habe eben von einer App am Smartphone gesprochen, das kann natürlich auch ein Browser sein, mit dem wir auf eine Webseite surfen. Ein solches Beispiel sehen wir uns nun an.

Das ist das obere der drei Anzeigefenster von Wireshark. Hier sehen wir alle Datenframes in ihrer zeitlichen Reihenfolge. Schauen wir uns beispielhaft einige davon an.

Frame 9: Hier sendet das Smartphone (hier IP-Adresse 10.8.0.3) eine HTTP GET-Anfrage an die Adresse hinter jsonp.eu. Da wird also eine Webseite abgerufen.
Frame 14: Und hier kommt die Webseite auch schon. Diesen Frame 14 werden wir uns gleich noch näher ansehen.
Frame 19: Hier schickt das Smartphone (10.8.0.3) eine DNS-Anfrage an die Adresse 10.8.0.1. Das ist die VPN-Tunneladresse des Raspberry Pi und der Raspberry Pi ist für das Smartphone der zuständige DNS-Server. Das hatten wir ja so konfiguriert. Abgefragt wird der Name vg08.met.vgwort.de. Erstmal wissen wir nicht, ob das überhaupt mit der Webseite etwas zu tun hat, die eben geladen wurde, aber aufgrund der zeitlichen Nähe können wir das vermuten.
Frame 20: Das ist die DNS-Antwort, die der Raspberry Pi an den Browser zurückschickt und in den darauffolgenden Frames kommuniziert der Browser mit dem VG-Wort Server um ein Trackingpixel zu laden.

Gehen wir weiter ins Detail und zwar für Frame 14, also den Empfang der Webseite.

Das mittlere Fenster zeigt die Details zum jeweils oben markierten Frame an und liefert gleich eine Auswertung auf verschiedenen Protokollebenen.
Ganz oben geht es um den Datenframe und seine Länge, dann kommt die Ebene des IP-Protokolls. Hier sehen wir die IP-Adressen von Sender und Empfänger. Auf dem Internet Protocol baut das Transmission Control Protocol TCP und danach werden die 4 Segmente aufgelistet, die dann die nächste Ebene bilden – das sind die vorhergegangenen Frames 11 bis 14. Alle diese Protokollebenen habe ich im Beispielbild eingeklappt gelassen. Man kann auf die Dreiecke am Zeilenanfang klicken und bekommt dann noch mehr Informationen.
Aufgeklappt habe ich die nächste Ebene, das Hypertext Transfer Protocol HTTP, hier Blau hinterlegt, Hier sieht man zum Beispiel, dass es sich um HTTP Version 1.1 handelt und dass der Status 200 OK zurückgeliefert wird. Danach folgen weitere Detailinformationen, zum Beispiel, dass es sich um einen Apache-Server handelt und schließlich erscheint unter Line-based text data der eigentliche Inhalt des Frames (die Payload). Das ist der HTML-Text der Webseite, den man recht gut lesen kann. Den Text sehen wir auch wenn wir uns nun auf die Byte-Ebene der Auswertung begeben.

Wenn wir im mittleren Fenster eine Zeile markieren, bekommen wir den Inhalt im unteren Fenster byteweise angezeigt. Hier im Beispiel also den Line-based text aus dem HTTP-Antwort-Frame. Hier sehen wir wieder den Beginn des HTML-Codes der Webseite – links als Bytes und rechts übersetzt in lesbare Zeichen.

So weit ein Kurzeinstieg in die Arbeit mit Wireshark. Das Programm ist komplex und Netzwerkdatenstrukturen sind es auch. Niemand muss sich also Gedanken machen, wenn er nicht alles versteht, was Wireshark ihm anzeigt – ich habe da auch nur ein rudimentäres Wissen. Im folgenden Teil 11 dieser Artikelserie gibt es auch ein Netzwerkdiagramm zu Wireshark.

Alle Apps sind ab jetzt gläsern? Leider nein!

Mit Wireshark haben wir ein Sniffer-Programm auf unserem VPN-Server installiert, mit dem wir alle Datenpakete zwischen Smartphone und Internet aufzeichnen können. Aber können wir jetzt analysieren, was einzelne Apps auf dem Smartphone an Daten versenden? Leider nein, denn diese Daten sind nahezu immer verschlüsselt.

In meinem Analysebeispiel oben habe ich eine HTTP-Webseite aufgezeichnet – die ist nicht verschlüsselt, deshalb kann man den HTML-Inhalt als Klartext in der Datenaufzeichnung lesen. Wäre das eine verschlüsselte HTTPS-Webseite, dann ginge das nicht, denn es ist ja das Ziel einer Verschlüsselung, dass die Daten eben nicht mitgelesen werden können. Und bei Apps ist das genau so. Alles, was ich an App-Kommunikation bei der Vorbereitung dieses Artikels gesehen habe, läuft über HTTPS. Damit sehen wir zwar mit wem kommuniziert wird – das ergibt sich aus der Namensauflösung – in die Datenpakete können wir allerdings nicht hinein sehen. Einen Nachweis, dass beispielsweise die App xyz die Standortdaten des Smartphones ausliest und an den Hersteller der App meldet, einen solchen Nachweis können wir mit dieser Technik leider nicht erbringen.

Weitere Artikel in dieser Kategorie: