„Mal eben in eine Netzwerk-Verbindung hineinschauen“ – Level2 Bridge auf einem Raspberry Pi

Vorrede

Vor kurzem hatte ich ein Problem: Ich wollte eine IP-Telefonanlage hinter einer Fritzbox anschließen. Die Installation verlief problemlos und alle Netzwerkeinstellungen schienen zu stimmen, aber es wollte einfach nicht funktionieren.
Wenn ich das gleiche Problem an meinem PC gehabt hätte, hätte ich „schnell mal eben“ Wireshark gestartet, um mir den Datenstrom anzuschauen und in den Netzwerk-Paketen Hinweise darauf zu finden, was schief geht. Nun ist es aber so, dass Wireshark und ähnliche Programme den Datenstrom „sehen“ können müssen, um ihn zu analysieren. Das bedeutet zumeist, dass diese Programme auf einem der beiden Endpunkte installiert sein müssen, da in modernen Netzen die Daten von Gerät A an Gerät B nicht bei Gerät C vorbei kommen.

In meinem Fall war das schwierig, denn weder die Fritzbox noch die IP-Telefonanlage ließen mich in den Datenstrom hineinschauen und Software konnte ich dort auch nicht installieren.
Ich hätte mich also ZWISCHEN die beiden Geräte hängen müssen, um sie zu belauschen: eine klassische „Man-In-The-Middle“ Attacke.

ACHTUNG: Das Abfangen und Abhören von Daten anderer ist illegal. Die hier gezeigte Technik darf nur für die Fehlersuche der eigenen(!) Netzwerke verwendet werden. Andere Teilnehmer im Netz müssen zuvor informiert werden!

Da ich schon vorher mal in einer ähnlichen Situation war, wollte ich fürs nächste Mal vorbereitet sein, und habe mir meinen Raspberry Pi geschnappt, um ihn in ein Netzwerk-Analyse-Tool zu verwandeln:

Vorbereitung

Der Linux-Kernel enthält bereits die notwendigen Werkzeuge: Netzwerk-Brücken. In manchen fällen muss jedoch noch das Paket „bridge-utils“ installiert werden (Beispiel für Debian, Ubuntu etc.):

sudo apt install bridge-utils

Beim Erstellen einer Bridge werden zwei oder mehr Netzwerk-Schnittstellen zu einem virtuellen Netzwerkgerät zusammengefügt und alles was auf einer Seite an Datenverkehr geschieht, wird auf die jeweils andere(n) Seite(n) „gespiegelt“.
Ein Netzwerkteilnehmer an Port 1 der Bridge kann also durch die Bridge hindurch mit dem restlichen Netzwerk so kommunizieren, als wäre die Bridge nicht da. Das gilt nicht nur für TCP und UDP sondern auch für die Anmeldung im Netz via DHCP, da die Schnittstellen schon auf Level 2 miteinander verbunden sind (vgl. OSI-Schichtenmodell).

Da Raspberry Pis nur eine einzige physische Netzwerk-Schnittstelle haben, benötigt man noch einen USB-Ethernet-Adapter, den man für wenige Euros bekommt – ich habe für meinen unter 10€ bezahlt (USB 3 mit 1000Mbit) .

Je nach verwendeten Geräten und Betriebssystem bekommen die Schnittstellen unterschiedliche Namen, ich werde im folgenden „eth0“ für die eingebaute Schnittstelle verwenden und „eth1“ für das USB-Gerät (die Schnittstellen erhalten aber zuweilen auch sehr lange Bezeichner wie enp3s0f1 oder noch längeres, das sollte nicht abschrecken). Welche Schnittstellen vorhanden sind, kann man mit dem Befehl „ip addr“ sehen. Die Schnittstelle „lo“ ist nur für die interne Kommunikation und kann ignoriert werden.

Da die Schnittstellen eth0 und eth1 demnächst nur noch Teil der Bridge sein werden, dürfen sie selbst nicht mehr als Netzwerk-Verbindungen konfiguriert sein. Bei meinem RaspberryPi musste ich hierfür zunächst den Network-Manager deinstallieren, damit er nicht dazwischenfunkt:

sudo apt remove network-manager

Achtung: Das Entfernen des Netzwerk-Managers kann zur Folge haben, dass Sie sich nicht mehr (ohne Weiteres) mit dem Netzwerk verbinden können. Entfernen Sie den Netzwerk-Manager nur auf einem Gerät, bei dem Sie nicht darauf angewiesen sind (z.B. ein Rechner, den Sie nur per Netzwerk erreichen).

Einrichten der Bridge

Man kann die Bridge zwar auch „on-the-fly“ mit dem Befehl „brctl“ erstellen, aber auf diesem Wege wäre sie nach einem Reboot wieder weg. Ich halte es daher für sinnvoller, sie in der Datei /etc/network/interfaces einzutragen, so dass sie immer sofort bereitsteht.
Die Netzwerk-Schnittstellen eth0 und eth1 müssen wir dort auf „manual“ stellen, damit sie dem System zwar bekannt sind, aber nicht automatisch eine Konfiguration verpasst bekommen. Der Bridge geben wir hier auch einen beliebigen Namen, ich werde hier br0 verwenden:

#/etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

auto br0
   iface br0 inet dhcp
   bridge_ports eth0 eth1

Hierbei ist zu beachten, das eth0 und eth1 zwar weiterhin zusehen sind, aber br0 ist die Schnittstelle, über die das System ins Internet kommt, also wird sie hier auch so konfiguriert, ihre eigene IP-Adresse per DHCP zu beziehen. eth0 und eth1 bekommen keine IP-Adressen. Dies kann man auch  – nach einem Reboot – durch einen Aufruf von ip addr sehen:

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel master br0 state DOWN group default qlen 1000
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.222.22/24 brd 192.168.222.255 scope global dynamic br0

(Diese Ausgabe wurde zur Übersichtlichkeit etwas gekürzt – nicht wundern, wenn bei Ihnen deutlich mehr steht)

Verwendung der Bridge

Ab nun ist alles eigentlich recht simpel. Ich verwende eth0 (also die eingebaute Schnittstelle), um mich mit meiner Fritzbox zu verbinden, dank DHCP geht das auch vollautomatisch.

Das zu untersuchende Netzwerkgerät stöpsele ich von der Fritzbox ab und stecke es in den USB-Ethernet-Adapter – dass es nun hinter der Bridge hängt, bekommt es nicht mit. Es kann aber gut sein, dass der Netzwerkverkehr nun etwas langsamer ist, da er ja nun durch die beiden Schnittstellen und den Prozessor des Raspberry Pi muss – es ist also keine Dauerlösung, sondern sollte nur zur Fehlersuche verwendet werden.

Auf dem Raspberry Pi kann ich nun mit der Software meiner Wahl alles mitlesen, was durch die Bridge hindurch geht. Wireshark ist dabei ein mächtiges Tool, welches aber mit seiner speicherhungrigen graphischen Oberfläche auf älteren Raspberry Pis etwas träge läuft. Auf die schnelle sehen, was so läuft, kann man mit tcpdump und iptraf-ng. Wie üblich installieren wir diese via:

sudo apt install iptraf tcpdump wireshark

iptraf-ng und tcpdump laufen im Terminalfenster, man kann sich damit an die virtuelle Schnittstelle br0 hängen, dann sieht man aber auch die Kommunikation die vom eigenen RasperryPi ausgeht. Wenn man dagegen an eth1 lauscht sieht man nur die Kommunikation die vom und zum zu untersuchenden Gerät übermittelt wird (incl. Network-Broadcasts).

Was man noch machen kann

Hiervon ausgehend kann man natürlich weiter arbeiten. Hat man einen USB-WLAN-Adapter oder ein RasPi-Modell, welches mit eingebauten WiFi aufwarten kann, kann man dieses so konfigurieren, dass es als WLAN-Access-Point für andere Geräte fungiert. Die Bridge würde man dann zwischen eth0 und wlan0 erstellen und kann dann die Pakete einsehen, die darüber laufen.
Heutzutage sollte eigentlich jegliche wichtige Kommunikation verschlüsselt sein, daher ist es meist nicht möglich den Inhalt der Kommunikation einzusehen, aber es ließe sich so feststellen, ob eine bestimmte App „nach Hause telefoniert“ oder ob Daten wirklich – wie vom Hersteller versprochen – verschlüsselt werden.
Oder man kann, wie ich, sehen, dass ein Gerät eine falsche Absender-IP-Adresse zur Kommunikation verwendet.

VPN als Sicherheitsmaßnahme

Für jemanden mit ein bisschen Linux Erfahrung ist es also möglich in Windeseile einen RaspberryPi Zero-W so zu konfigurieren, dass er als WLAN eines Cafes erscheint oder zwischen einem PC und dem DSL-Router des Ex-Freunds oder der Ex-Freundin geklemmt wird. Dies ist, wie Eingangs erwähnt, illegal und wird empfindlich bestraft, dennoch wird es solche Attacken immer wieder geben.
Wie ich wunderbar beobachten konnte, ist ein VPN eine gute Schutzmaßnahme: Nachdem ich mich auf dem zu analysierenden PC mit dem VPN der Uni Köln verbunden habe (wichtig: Option „Full Tunnel“), konnte mein lauschender RasPi als Angreifer nur noch verschlüsselte VPN-Pakete sehen, die ohne Schlüssel nur Datenmüll enthalten und keine Rückschlüsse mehr darauf zulassen, ob ich gerade auf Facebook bin, oder per IP-Telefonie mit meiner Oma telefoniere.

Aber Achtung: VPNs bieten keine Ende-Zu-Ende-Verschlüsselung! Im Falle des VPN der Uni Köln wird der Internetverkehr lediglich dorthin umgeleitet. Ein Angreifer dort oder ein unseriöser VPN-Anbieter können den Netzverkehr wieder mitlesen. Ab dem VPN-Server laufen die Daten wieder genau so (unverschlüsselt) wie ohne VPN. Sitzt der Angreifer jedoch nicht an meinem DSL-Router, sondern zapft die Leitung meiner Oma an, kann er wohl möglich trotzdem mitlauschen, wie sie mir ihr Geheim-Rezept für ihren Apfelkuchen mitteilt.

Hinweis: Diese Dinge wurden nicht auf einem RaspberryPi sondern auf einem BananaPi mit Armbian Linux getestet. Es sollte so jedoch auf jedem Linux-Gerät umzusetzen sein, dessen Kernel die Bridge-Module enthält, und auf dem die benötigten Pakete bridge-util, iptraf, tcpdump und ggf. wireshark vorhanden sind. Die Befehle zum installieren von Pakten und die Dateien in denen das Netzwerk konfiguriert werden muss, können dabei abweichen.