Viele Sicherheitsprobleme entstehen dadurch, dass alle Geräte (PCs, Notebooks, Drucker, Smartphones, IoT-Geräte) in einem großen Netzwerk sind. Leider ist genau das etwas was mir immer wieder Kopfschmerzen macht: Wenn ein Gerät (warum auch immer) eine Sicherheitslücke aufweist, ist es von dem Gerät problemlos möglich, auf alle Ressourcen des Intranets zuzugreifen. Wenn derjenige dann auch noch ein schönes NAS mit allen Bildern und Dokumenten zuhause stehen hat, wird es richtig unschön.
Viele Endanwender machen sich hier natürlich keinerlei Gedanken, denn wenn das Gerät funktioniert ist für sie ja alles in Ordnung.
Hierzu kommt noch eine weitere Problematik: In den meisten Haushalten stehen entweder Fritz!Boxen oder Speedports. Diese Geräte bieten keine vernünftige Möglichkeit, solche Geräte wie Echos oder Netzwerkschaltsteckdosen in ein eigenes Netzwerk zu verfrachten. Hier die Gastnetzwerk-Funktion zu missbrauchen stellt für mich auch keine wirkliche Lösung dar.
Zusätzlich verbauen die Hersteller regelmäßig hier auch generell die Nutzung der Geräte in einem getrennten Netzwerk, indem Sie in Ihren Apps für die Geräteerkennung auf z.B. auf Broadcasts setzen. Die Broadcasts der IoT-Geräte bleiben dann allerdings im getrennten Netzwerk stecken und werden natürlich nicht in das Intranet übertragen. Folglich findet die App das Gerät nicht und dadurch ist man wieder gezwungen, das Gerät in das gleiche Netzwerk zu nehmen.
Genial wäre hier ein zusätzlich zum Gastnetzwerk aktivierbares IoT-Netzwerk. Dann wird eine zusätzliche SSID von dem Router ausgesendet. Im Router sind generell die beiden Netzwerke vorerst getrennt. Auf der Box läuft ein eigener DHCP-Server. Wenn ein IoT-Gerät sich in das Netzwerk einbucht, wird es registriert und taucht auf einer Weboberfläche der Box auf. Nun kann entweder die Verbindung zum Intranet und/oder das Internet blockiert werden, oder z.B. auch nur der Zugriff auf dem SMTP-Port, um den Versand von Spam aus dem Netzwerk zu verhindern. Wenn der Zugriff auf die Geräte vom Intranet aus erlaubt ist, kann jetzt immer noch das Gerät von jedem Gerät im Intranet angesteuert werden. Im Falle einer Kaperung eines Gerätes kann der Angreifer zwar evtl. ins Internet, aber nicht auf das heimische NAS zugreifen.
Diese Funktionalität ist (da ja bereits teilweise durch die Gästenetzwerk-Funktion implementiert) problemlos in die Firmware integrierbar. Natürlich kann man auch einen günstigen TP-Link-WLAN-Router/Access-Point kaufen und dann mittels dd-wrt oder OpenWRT sich so eine Trennung bauen, allerdings kann und will das nicht jeder. Zudem muss dann eine weiteres Gerät dauerhaft betrieben werden (Strom, Platz und Zeit). Es wäre wirklich gut, hier eine Out-Of-The-Box-Lösung in Massenhardware zu implementieren. Denn eines ist klar: Wenn es nicht einfach einzurichten ist, wird es in der Praxis niemand einsetzen.
In diesem Artikel zeige ich, wie IoT-Geräte in ein eigenes Netzwerk verbannt werden können. Ich werde mich hier nur auf Alexa-Geräte á Echo und Echo Dot beziehen, da es hiermit zumindest relativ einfach zu realisieren ist. Es handelt sich hier auch um eine Lösung, welche NICHT nur mit einem Raspberry Pi zu erreichen ist (Router muss mehrere getrennte Subnetzwerke unterstützen, etc.).
Folgende Hardware wird in meinem Beispiel benötigt:
- Mindestens ein Alexa-Gerät (optional noch weitere IoT-Geräte)
- Ein Raspberry Pi (am besten die 3. Generation, da hier ein WLAN-Modul bereits integriert ist)
- Einen Access-Point bzw. Router, welcher Multi-SSID unterstützt (in der Regel alle dd-wrt und openWRT fähigen Router) ODER einen Business-Access-Point
- Ein aktuelles Rasbian, welches auf eine SD/Micro-SD-Karte gebacken wird
- Die aktuelle Version von HABridge
Generell sieht die Idee so aus:
Die Schlüsselrolle nimmt in diesem Fall das Raspberry ein: es ist mit der LAN-Schnittstelle im Intranet und mit dem WLAN-Modul im IoT-Netzwerk, welches der Access-Point bzw. Router aussendet. Wichtig hierbei: Weder auf dem Access-Point noch im Raspberry dürfen die beiden Netzwerke gebrückt sein, sonst ist der Aufbau sinnlos. Der Access-Point oder Router sollte in beiden Netzwerken über DHCP IPs vergeben, alternativ kann natürlich auch eine statische IP vergeben werden. Leider unterstützt das nicht jedes IoT-Gerät. Natürlich sollten um Adresskonflikte zu vermeiden, die Netzwerke in 2 unterschiedlichen IP-Subnetzwerken liegen (Intranet 192.168.0.0/16, IoT 10.10.0.0/16). Sicherheitseinstellungen wie das blockieren der Kommunikation zwischen Geräten in einem WLAN-Netzwerk sowie Unterdrückung/Filterung des Broadcast/Multicast-Verkehrs sind auf dem IoT-WLAN zu deaktivieren. Sinnvollerweise sollte dem Interface des Raspberrys im IoT-Netzwerk eine statische IP-Adresse zugewiesen werden.
Das Raspberry ist in das WLAN mittels wpa_supplicant einzubinden, im Internet findet man hier viele schöne Anleitungen. Falls kein Raspberry Pi v.3 zum Einsatz kommt, ist die Nutzung eines unterstützten USB-WLAN-Adapters möglich. Es wäre auch möglich, direkt 2 WLAN-Interfaces einzurichten. Allerdings muss dann wpa_supplicant umkonfiguriert werden, da hier per Default immer nur ein aktiver WLAN-Adapter genutzt werden kann.
Die HA-Bridge wird auf dem Raspberry entpackt und kommt dort in die rc.conf um auch nach einem Neustart des Gerätes automatisch wieder zu starten. Die Installation und Einrichtung von HA-Bridge ist auf der Projektseite ausführlich beschrieben. Die Installation von Java ist hierbei essenziell. Am besten, HA-Bridge wird als Dienst mit einem Shell-Script im System installiert, dann muss man nicht mehr manuell die Anwendung mit Java aufrufen.
Auf jeden Fall darauf achten, dass das Webinterface von HA-Bridge NUR aus dem Intranet zu erreichen ist!
In der Standardkonfiguration werden die Interfaces nicht gebrückt. Nun muss in der HA-Bridge bei "UPNP IP Address" die IP des Interfaces (in unserem Beispiel die IP-Adresse von wlan0) eingetragen werden. Da auf dem Raspberry nun beide Netzwerke bekannt sind, kann dieses die Schaltbefehle vom IoT-Netzwerk in das Intranet übertragen.
Hierzu muss noch die Hue-Bridge in HA-Bridge über LAN eingebunden werden (Pairing-Knopf drücken).
Es werden nun alle an der Hue-Bridge angelernten Lampen mit ihren Bezeichnungen angezeigt. Die Lampen können nun entweder alle übernommen, oder einzeln angepasst werden. Die HA-Bridge simuliert nun eine virtuelle Hue-Bridge auf der IoT-IP des Raspberrys und leitet dann alle Schaltbefehle über die LAN-Schnittstelle ins Intranet und somit zur Hue-Bridge weiter:
<IoT-Gerät> <<<=>>> <wlan0:Raspberry> <HA-Bridge> <eth0:Raspberry> <<<=>>> <Hue-Bridge>
Nach einem Test der Lampen über die HA-Bridge (diese sollten sich nun schalten lassen) kann nun Alexa aufgefordert werden, neue Geräte zu suchen. Es sollten nun alle Geräte genau so auftauchen, wie diese in HA-Bridge angelegt wurden. Mit einem "Alexa, schalte <Name der Lampe> ein/aus" sollte nun ein Schalten der Geräte möglich sein.
Zusätzlich sollte die Trennung der beiden Netzwerke geprüft werden: Am besten hierzu ein Notebook ins IoT-WLAN hängen und versuchen, eine Intranet-IP zu erreichen. Dies darf nicht funktionieren.
Dieser Aufbau kann natürlich noch beliebig verfeinert werden. Zum Beispiel könnte durch eine Firewall-Regel der Zugriff von Geräten im Intranet auf die IoT-Geräte erlaubt werden, um diese einfacher konfigurieren zu können oder (sehr sinnvoll) die Kommunikation der IoT-Geräte ins Internet nur noch über Port 80/443 erlauben. Vernünftig ist es hier in diesem Zuge, SMTP sowie Filesharing-Ports zu blockieren.
Eine weitere Möglichkeit stellt die Nutzung in Kombination mit FHEM dar, dann können z.B. Netzwerksteckdosen im IoT-Netzwerk auch ohne App des Herstellers geschalten werden. Auch eine Heizungssteuerung mit FHEM, Homematic und Alexa ist hier möglich.
Nach einigen Tagen Betriebszeit stellte sich heraus, dass das WLAN-Modul teilweise Probleme hat, sich dauerhaft mit dem IoT-WLAN zu verbinden, bzw. sich nicht immer wieder automatisch neu mit dem WLAN verbindet. In der Praxis führte das dann dazu, dass Alexa "X.Y. reagiert nicht mehr" ausgegeben hat. Ich habe das Problem bei mir mit einem kleinen Shell-Skript gelöst:
#!/bin/bash
ifconfig wlan0 down
ifconfig wlan0 up
sleep 10
service habridge restartIn der "/etc/crontab" die Zeile
1 * * * * root /opt/restart_wlan.shhinzugefügt. Somit wird jede Stunde das Skript ausgeführt. Es trennt die WLAN-Verbindung, startet die Verbindung erneut, wartet 10 Sekunden und startet dann den habridge-Dienst neu. Seitdem habe ich keine Probleme mehr.