IoT-Geräte (Alexa & Co.) in eigenes Netzwerk verbannen

Gespeichert von Michael Kirgus am Sa., 04.11.2017 - 19:27

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:

Generell sieht die Idee so aus:

Übersicht IoT/Intranet

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 Shellscript 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-Script gelöst:

#!/bin/bash

ifconfig wlan0 down
ifconfig wlan0 up
sleep 10
service habridge restart

In der "/etc/crontab" die Zeile

1 * * * * root /opt/restart_wlan.sh

hinzugefügt. Somit wird jede Stunde das Script 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.

Kommentare

Gespeichert von Martin (nicht überprüft) am Mo., 04.02.2019 - 18:31

Permalink

Hallo,

ich habe mit Begeisterung diesen Artikel gelesen. Leider bin ich mit dem Raspberry nicht firm, weshalb ich anfragen will,
ob die Funktionalität nicht auch mit einem WLAN-Router, der mehrere VLANs unterstützt umgesetzt werden kann.
Wenn ja, haben Sie Vorschläge für einen solchen Router ?  Würde dies zB mit einer Digibox Smart / Premium der Telekom, funktionieren ?


Gruß und Danke
   Martin

Hallo Martin!

Freut mich, dass du meinen Artikel spannend findest.

Um dies mit einem Router umzusetzen, müsste der Router in der Lage sein die habridge mit OpenJDK auszuführen (hier fallen mir nur potente openwrt Router ein).

Eine weitere Möglichkeit (welche ich leider bisher auch im gehobenen Preisbereich noch nicht gefunden habe) wäre, wenn der Router Multicast über Subnetzwerke routen würde.

Da Multicast/Broadcast aber nicht geroutet werden dürfen, müsste der Router eine Art Multicast-NAT beherrschen.

In den LANCOM Systems Geräten ist zumindest bereits ein Bonjour-Proxy eingebaut, das geht dann schon mal in die richtige Richtung.

Im Prinzip müsste der Router nur auf den beiden Subnetzen lauschen (evtl. noch mit MAC-Filter) und dieses Paket dann in das andere Subnetz übertragen.

Ich denke, in den nächsten Jahren wird dies bestimmt von den großen Herstellern implementiert, da es inzwischen auch in Firmenumgebungen immer wieder zu solchen Anforderungen kommt.

Falls noch jemand anderes eine andere Idee hat, gerne kommentieren!

 

Gruß,

Michael

Gespeichert von Marco (nicht überprüft) am Mi., 13.05.2020 - 00:35

Permalink

Hallo Martin,

verstehe ich es richtig, dass aus dem iot-Netz Befehle an die Hue-Box ins Intranet gehen sollen?

Braucht/machen die iot-Geräte wirklich den Broadcast? Das wäre doch eigentlich die Aufgabe der App wenn sie die Geräte finden will.

Ansonsten wäre es nach meinem Verständnis nämlich damit getan -wie du schreibst- zwei getrennte Subnetze (ssid‘s) zu verwenden,

+ Zugriffe aus der Zone ‚Intranet‘ in die Zone ‚Iot‘ zu erlauben.

Ich habe noch wenig Erfahrung mit gekauftem Iot-Zeug, freue mich aber auf deine Antwort um es besser einzuschätzen zu können.

Grüße Marco

Evtl. noch eine kleine Anmerkung: Die Hue Bridge benötigt wirklich in der Theorie keine Internetverbindung. Gelegentlich versucht die Bridge, sich Firmware-Updates von Phillips zu ziehen, aber die Bridge kann wenn man die App auf dem Tablet nutzt auch ganz lokal die Bridge finden. Es gab in der alten Hue App sogar die Möglichkeit, die IP der Bridge statt der Auto-Broadcast-Funktion für die Suche zu verwenden.

Falls man aber die Hue-Bridge mit Alexa lokal (also ohne Hue-Skill) verwenden möchte, benötigt zumindest ein Echo bzw. Amazon Gerät im IoT-Netzwerk Internetzugriff. Wenn du über die Alexa-App oder über die SPA auf der Amazon-Webseite Geräte suchst, wird ein Gerät (keine Ahnung wie Amazon das entscheidet) in deinem Netzwerk "getriggert", einen Broadcast zu senden und für einen gewisse Zeitspanne nach Antworten von den Geräten zu warten. Ist das Amazon-Gerät aber nicht im gleichen Subnetz, bekommt es keine Antwort und es tauchen keine Geräte auf. Leider gibt es nach meinem Wissenstand keine Möglichkeit, hier einfach eine lokale IP angeben zu können. Der Schaltvorgang an sich läuft an sich relativ einfach über TCP/IP und mittels Unicast, also kann auch problemlos geroutet werden. Der Knackpunkt ist leider einfach die "Detection" der Geräte, damit man diese überhaupt in der Amazon-Welt nutzen kann.

Das schlimme ist, das viele an dieser Stelle einfach aussteigen und dann einfach den Hue-Skill nutzen und alles schön nach Hause telefonieren lassen, weil es sonst viel zu kompliziert wird.

Ich selbst habe inzwischen meine Amazon-Echos abgebaut und beschäftige mich seit einigen Monaten mit einem DIY-Projekt namens "Rhasspy" um hoffentlich in naher Zukunft ein "offline only" System zu haben, bei welchem ich um einiges flexibler anpassen kann. Inzwischen gibt es hier auch ganz gute Ansätze. Wenn ich hier ein funktionierendes System gebaut habe, schreibe ich dazu natürlich wieder einen schönen Artikel, aber aktuell mag einiges noch nicht richtig funktionieren und die Zeit ist aktuell knapp...

Gespeichert von Rudolf Ziegaus (nicht überprüft) am Mo., 15.03.2021 - 23:56

Permalink

Hallo,

 

ich habe deinen Artikel gelesen und finde den Ansatz spannend. Ich würde gerne etwas Ähnliches machen, aber dann doch wieder in Details unterschiedlich - vielleicht hast du da eine Idee. Ich kenne mich zwar gut mit Programmierung aus, bin aber im Thema Netzwerke leider nicht so firm.

Ich habe eine Hausautomatisierungssystem auf Basis von FHEM und eines selbst geschriebenen Java-Servers. Dieser holt Daten von Sensoren ab und speichert sie in einer Datenbank. Außerdem gibt es da noch einen REST-Service für eine App sowie für einige selbst gebaute Sensoren, die ihre Daten über den REST-Service einliefern.

FHEM, der Java-Server sowie der REST-Service laufen auf einem Raspi 4, welcher über LAN angebunden ist.

Aktuell sind die selbst gebauten Sensoren  noch in meinem Heimnetzwerk in meiner Fritzbox registriert, ich würde sie aber gerne in ein eigenes WLAN mit einer eigenen SSID und eigenen Zugangsdaten verschieben. Erstens will die Devices schon mal aus grundätzlichen Erwägungen aus meinem Heimnetzwerk verbannen (die haben dort eigentlich nichts zu suchen), zweitens will ich dafür auch ein anderes Passwort vergeben, das ich dann auch unabhängig von meinem Heimnetzwerk ändern kann.

Mein Problem ist nun der Raspi - wenn ich die IoT-Devices z. B. in das Gäste-WLAN verlagere, dann muss ich ja den Raspi auch dort hin verlagern, dann komme ich aber natürlich nicht mehr mit meinem Computer per ssh auf den Raspi, der liegt ja in einem anderen Netzwerk.

Eine mögliche Lösung wäre, den Raspi auch noch per WLAN im zweiten Netzwerk anzumelden, aber das WLAN ist dort nicht so toll.

Gibt es noch andere Möglichkeiten, wie der Raspi und die Sensoren einerseits in einem eigenen Netzwerk kommunizieren können, ich aber den Raspi auch noch administrieren kann? Hast du eine Idee?

 

Viele Grüße,

Rudi

 

 

Hallo Rudi,

ich freue mich über deinen Beitrag. Ja, das Thema ist ein ziemliches Gefrickel 😄

also ich sehe hier 2 Ansätze:

1. Die Lösung welche du bereits kurz angesprochen hast: Das Raspberry zusätzlich mit einem WLAN-USB-Adapter ausstatten und in das IoT-WLAN mit dem externen Adapter das Raspberry anbinden (USB-Adapter mit kurzer Verlängerung etwas weg vom Raspberry führen, sonst stören sich die Chipsätze der Adapter gegenseitig). Damit wärst du mit der Positionierung des Gerätes flexibel. Deine Services könnte man auf dem Raspberry auf 0.0.0.0 laufen lassen und somit wäre der Server auf beiden WLAN-Interfaces erreichbar. Entweder der SSH:Service wird nur noch auf dem Interface des Intranets eingerichtet (also NICHT auf die 0.0.0.0) oder die Firewall wird aktiviert und alle SSH-Pakete vom IoT-Netzwerk zum Raspberry verworfen. Hier ein Tipp: Als Fallback auch auf dem Ethernet-Interface den Zugriff auf das Raspberry erlauben, sichert gegen ungewolltes Aussperren. Den Interfaces dann statische IP-Adressen in den 2 Subnetzen zuweisen, um Probleme bei kurzer Unterbrechung der WLAN-Verbindung zu vermeiden.

Ich würde je nach Stärke des IoT-Netzes bzw. Gastnetzwerkes der Fritzbox empfehlen, einen dedizierter Access-Point (muss nix teueres sein z.B. TP-Link) für das Aufspannen des IoT-Netzwerkes zu verwenden und das Raspberry dann in beiden Netzwerken als Client anzumelden. IoT-Geräte haben oft eine geringe Sende/Empfangsempfindlichkeit und benötigen ein stabiles WLAN. Dann könnte auch der WLAN-Kanal/Sendeleistung angepasst werden und die Fritzbox wird entlastet. Der Access-Point sollte dann auf 20Mhz-Kanalbreite laufen, um nicht mit deinem bereits bei der Fritz!Box eingerichteten WLAN zusammen bereits für alle Nachbarn den Funkbereich zu belegen 😉.

Technisch ist es zwar mit einigen WLAN-Chipsätzen über "hostapd" möglich mit dem Raspberry einen Access-Point aufzuspannen, aber die Sendeleistung/Signalstärke ist nicht besonders gut und es hat bei meinen Tests nie stabil funktioniert.

 

2. Es gibt ein Projekt, mit welchem ein ESP8266 mit einem Betriebssystem beschrieben wird, welches die Funktion eines WLAN-Repeaters (Genauer: WiFi-NAT-Router) übernimmt. Technisch gesehen spannt es ein Netzwerk mit der gleichen SSID auf, unter welches es selbst als Client hängt. Dieses Netz hat dann ein eigenes Subnetzwerk. Ich habe keine Erfahrung mit der Zuverlässigkeit, aber ein ESP ist günstig und der Einstieg nicht so schwer. Hier findet sich die Webseite des Projektes: GitHub - martin-ger/esp_wifi_repeater: A full functional WiFi Repeater (correctly: a WiFi NAT Router).

Wie weit das für die Stabilität einer SSH-Verbindung und REST-Service ausreicht kann ich nicht wirklich bewerten, das müsste einfach getestet werden. Da der Stromverbrauch eines ESP sehr gering ist, wäre es auch möglich, das Gast-WLAN der Fritz!Box über 2 ESPs zu verlängern, falls die Reichweite einfach nicht aúsreicht. Die Leistung der ESPs ist nicht optimiert für den Netzwerkdurchsatz, also wird es mit jedem ESP in der Kette spannender...

 

Leider gibt es - noch immer - von AVM keine wirklich brauchbare Möglichkeit, IoT-Geräte in ein eigenes IoT-Netzwerk zu verbannen, welches den Namen auch verdient. Das Gäste-Netz ist dafür zwar nutzbar, aber ist eigentlich für Gäste gedacht und schottet deshalb natürlich völlig zum Intranet ab. Da es sich bei dem Gäste-Netzwerk bereits auch um eine virtuelle SSID handelt wäre eine Erweiterung um eine 3. SSID optional nur eine Sache der Software. Zusammen mit GUI und einem Multicast/Bonjour/IGMP-Proxy wäre das ein wirklicher Mehrwert und man könnte mit etwas Erweiterung der Firewall-Funktionalität auch einzelne Geräte einsperren oder z.B. nur über Port 80/443 kommunizieren lassen, um bei infzierten Geräten eine "Spamschleuder" in einem Botnetz zu verhindern.

Ich hoffe, ich konnte etwas helfen und würde mich natürlich auch freuen, wenn ich deine Erfahrungen unter dem Beitrag finden würde 😁

Neuen Kommentar hinzufügen

Sind Sie ein Mensch? Schlimm, aber leider notwendig:

Bild-CAPTCHA
Geben Sie die Zeichen ein, die im Bild gezeigt werden.