Ein vernetztes Haus ist praktisch, bis es zum Problem wird. Heizung, Licht, Rollläden, Türstation, Kameras, Saugroboter, Sprachassistent, Lautsprecher und Garagentor hängen am Netz und tauschen Daten aus. Genau das ist auch die Angriffsfläche. Das Mirai-Botnetz hat 2016 gezeigt, wie das aussieht: Schlecht gesicherte IP-Kameras, Router und andere IoT-Geräte wurden massenhaft übernommen, in der Spitze rund 600.000 gleichzeitig.
In deutschen Haushalten sieht man beides. Auf der einen Seite sauber gebaute KNX-Anlagen mit lokalem Server, ordentlicher Firewall und getrennten Netzen. Auf der anderen Seite Häuser, in denen Dutzende IoT-Geräte aus fünf Hersteller-Apps im selben WLAN hängen, jedes mit eigener Verbindung in irgendein Rechenzentrum, und die Türklingel noch mit dem Passwort ab Werk läuft.
Dieser Beitrag zeigt, wie ein Smart Home im Alltag funktioniert und trotzdem nicht zur offenen Tür wird: mit konkreten Maßnahmen, Standards und den Kompromissen, die dazugehören.
Die Risiken konkret
Wie Angriffe aussehen
Botnetze wie Mirai. Mirai ist Schadsoftware, die das Internet nach IP-Kameras, Rekordern und Routern mit Standardpasswörtern absucht und sie übernimmt. Die Geräte werden dann für Angriffe auf Dritte missbraucht. Der Quellcode ist seit 2016 öffentlich, Nachfolger in vielen Varianten sind bis heute aktiv.
Günstige WLAN-Geräte ohne Updates. Billige Schalter, Steckdosen und Sensoren kommen oft mit schwacher Firmware. Vergisst der Hersteller die Geräte, gibt es keine Updates mehr, und bekannte Lücken bleiben offen.
Unsichere Repeater und Mesh-Knoten. Manche WLAN-Repeater im Niedrigpreissegment haben fest eingebaute Zugänge oder Weboberflächen mit Lücken, die nie geschlossen werden. Über solche Geräte landet ein Angreifer mitten im Heimnetz.
Smart-TVs ohne Sicherheitsupdates. Fernseher werden viele Jahre genutzt, bekommen Sicherheitsupdates aber oft deutlich kürzer. Ein übernommener Fernseher im Hauptnetz erreicht alle anderen Geräte in diesem Netz: Drucker, Rechner, Netzwerkspeicher.
Geräte mit Cloud-Zwang. Wird die Cloud eines Herstellers oder ein Kundenkonto kompromittiert, sind alle daran hängenden Geräte betroffen, bis hin zu Kamerabildern und Steuerbefehlen.
Der Gesetzgeber zieht nach. Seit dem 01.08.2025 müssen neue Funkgeräte mit Internetanbindung in der EU grundlegende Anforderungen an Cybersicherheit und Datenschutz erfüllen (Delegierte Verordnung (EU) 2022/30 zur Funkanlagenrichtlinie). Ab dem 11.12.2027 verpflichtet der Cyber Resilience Act Hersteller vernetzter Produkte, Sicherheitslücken über die Lebensdauer ihrer Produkte zu behandeln und Updates bereitzustellen. Die Meldepflichten der Hersteller für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle (Art. 14) gelten schon seit dem 11.09.2026. Für die Geräte, die heute schon im Haus hängen, hilft das nicht.
Angriffswege im Überblick
| Angriffsweg | Wie der Angriff aussieht | Schutz |
|---|---|---|
| Standardpasswörter | „admin/admin“ oder „1234“, ab Werk gleich für eine ganze Geräteserie | sofort ändern, eigene Passwörter aus einem Passwortmanager |
| unsichere Updates | Firmware über unverschlüsselte Verbindung, ohne Signaturprüfung | Geräte ohne signierte Updates meiden |
| schwache WLAN-Verschlüsselung | WEP, WPA, WPA2 mit kurzem Passwort | WPA3, bei WPA2 lange Passwörter mit 20 und mehr Zeichen |
| fehlende Netztrennung | alle Geräte im selben Netz, ein übernommenes IoT-Gerät erreicht den Büro-PC | getrennte VLANs, Firewall mit „alles verboten, was nicht erlaubt ist“ |
| veraltete Firmware | bekannte Lücken bleiben offen, weil niemand aktualisiert | Update-Plan festlegen, auf Wunsch im Wartungsvertrag |
| übernommenes Cloud-Konto | Angreifer steuert die Geräte über das Hersteller-Konto | Geräte ohne Cloud-Zwang bevorzugen, Zwei-Faktor-Anmeldung, wo möglich |
| unverschlüsselte Kommunikation | Bus- oder Funkverkehr lässt sich mitlesen | KNX Secure, WPA3, verschlüsselte Funkprotokolle |
| Zugriff vor Ort | offene Service-Schnittstellen auf der Platine | Montageort, verschlossene Gehäuse bei kritischen Geräten |
KNX Secure
Warum KNX eine gute Grundlage ist
KNX, früher EIB, liegt seit den 90er Jahren als Zweidrahtbus in deutschen Häusern: verkabelt, robust, herstellerübergreifend und über die KNX Association standardisiert. Die klassische KNX-Busleitung (Twisted Pair) ist von außen schwer angreifbar. Wer dort eingreifen will, muss ins Haus.
Was klassisches KNX nicht hatte, ist Verschlüsselung. Auf dem Bus lief alles im Klartext. Solange die Anlage ohne IP-Anbindung lief, war das vertretbar. Mit KNX-IP-Schnittstellen und Visualisierungen im Heimnetz, heute der Normalfall, sollte die Kommunikation verschlüsselt sein.
Die zwei Teile von KNX Secure
| Standard | Was er schützt | Wo er greift |
|---|---|---|
| KNX Data Secure | Telegramme zwischen den Geräten, auf dem Bus und über IP | wird je Gerät in der ETS eingerichtet |
| KNX IP Secure | Tunneling und Routing über das IP-Netz | an IP-Routern und IP-Schnittstellen |
KNX Data Secure verschlüsselt die Kommunikation zwischen Aktoren, Sensoren und Visualisierung mit AES-128. Wer den Bus mitliest, sieht nur verschlüsselte Daten. Dafür müssen alle beteiligten Geräte Secure-fähig sein. Bei neueren Geräten ist das üblich, ältere lassen sich oft nicht nachrüsten.
KNX IP Secure schützt die Verbindung über das Netzwerk, etwa zwischen IP-Router, Visualisierungsserver und Programmier-PC. Ins Internet gehört ein KNX-IP-Gerät trotzdem nie direkt. Fernzugriff läuft über ein VPN ins Heimnetz.
Hinweise aus der Praxis
- Projektpasswort und Schlüssel der ETS sicher aufbewahren. Wer das Projekt verliert, kann die Secure-Einstellungen nicht mehr ändern, ohne alle Geräte zurückzusetzen und neu zu programmieren.
- Visualisierungsserver wie Gira X1, MDT VisuControl oder Hager domovea hinter die Firewall, nie direkt ans Internet. Von außen nur über VPN.
- Tunneling und Routing trennen: Routing nur im internen Netzsegment, Tunneling für Programmierung und Visualisierung.
Getrennte Netze sind die Grundlage
Warum ein flaches Netz unsicher ist
Im typischen Heimnetz hängen alle Geräte im selben Netz. Hat der Saugroboter eine Sicherheitslücke, kann er jedes andere Gerät erreichen. Über übernommene Kameras und Fernseher gelangen Angreifer auf diesem Weg zu Rechnern und Speichern.
VLANs lösen das. Ein VLAN teilt das Netz logisch in getrennte Bereiche. Geräte in einem VLAN erreichen andere VLANs nur, wenn die Firewall das ausdrücklich erlaubt.
Eine VLAN-Struktur für das Smart Home
| VLAN | Name | Geräte | Internet | Zugriff auf andere VLANs |
|---|---|---|---|---|
| 10 | Verwaltung | Switch, Access Points, Router, Rekorder-Verwaltung | eingeschränkt | nur vom Admin-Rechner |
| 20 | Familie | Laptops, Smartphones, Tablets | ja | gezielt auf den Smart-Home-Server |
| 30 | IoT | Saugroboter, Smart-TV, Sprachassistent, WLAN-Steckdosen | eingeschränkt, nur DNS und Hersteller-Server | nein |
| 40 | Gebäudetechnik | KNX-IP-Schnittstelle, Home Assistant, ioBroker, Gira X1 | eingeschränkt | nur Familie und Verwaltung |
| 50 | Kameras | IP-Kameras, Rekorder, Türstation | nein, nur lokal | nur Verwaltung |
| 60 | Gäste | Gäste-WLAN | ja, mit Bandbreitenlimit | keine |
| 70 | Homeoffice | Firmen-Laptop, Diensttelefon | ja | streng getrennt |
Worauf es bei der Umsetzung ankommt
- Je VLAN ein eigenes WLAN, zum Beispiel Familie auf VLAN 20, IoT auf VLAN 30, Gäste auf VLAN 60
- Firewall nach dem Grundsatz: Alles ist verboten, was nicht ausdrücklich erlaubt ist
- mDNS für ausgewählte Dienste wie AirPlay oder Chromecast gezielt zwischen den Netzen weiterleiten, sonst funktionieren manche Bequemlichkeiten nicht
- ein zentraler DNS-Filter, etwa Pi-hole oder NextDNS, der Tracking-Adressen blockiert und protokolliert
- Protokollierung einschalten: Wer wann welche Grenze zwischen den Netzen überschreitet, ist oft der einzige Hinweis auf eine Auffälligkeit
Smart-Home-Server und Plattformen
Lokal oder Cloud
| Eigenschaft | Lokaler Server | Cloud-Plattform |
|---|---|---|
| funktioniert ohne Internet | lokale Grundfunktionen ja, eingebundene Cloud-Dienste nicht | nein |
| Datenhoheit | beim Nutzer | beim Hersteller |
| Reaktionszeit | sehr kurz | abhängig von der Cloud |
| Verantwortung für Updates | Nutzer oder Errichter | Hersteller |
| Pflegeaufwand | regelmäßig | gering für den Nutzer |
| Risiko, wenn der Hersteller aufgibt | gering | hoch, Geräte können nutzlos werden |
| Beispiele | Home Assistant, ioBroker, openHAB, Gira X1, MDT VisuControl | Apple Home, Google Home, Alexa, Tuya |
Unsere Empfehlung: ein lokaler Server als Kern, die Cloud nur dort, wo sie wirklich etwas bringt, etwa für die Sprachsteuerung bei Bewohnern, die das ausdrücklich wollen. Auch dann läuft die Logik lokal, die Cloud ist nur eine weitere Bedienoberfläche.
Updates für lokale Server
Home Assistant läuft meist auf einem kleinen Rechner, etwa Home Assistant Green oder einem Mini-PC, und bekommt jeden Monat ein neues Release. Die Pflicht dazu: regelmäßig aktualisieren, vor jedem Update automatisch sichern, einen festen Wartungstermin im Monat einplanen.
ioBroker auf Linux: Adapter und Kern getrennt aktualisieren, vor größeren Updates einen Snapshot anlegen.
Gira X1, Hager domovea und MDT VisuControl: Updates kommen vom Hersteller und werden über dessen Software eingespielt. Das übernimmt meist der Errichter, weil die Bewohner es selten selbst tun.
Was eine gute Update-Strategie ausmacht:
- Sicherung vor jedem Update, automatisch oder per Skript
- Updates zu einer Zeit, in der man reagieren kann, nicht am Freitagabend
- Rückweg planen: Welche Version lief vorher, wie kommt man zurück?
- Update-Protokoll: Was wurde wann aktualisiert, was fiel danach auf?
Container und Reverse Proxy
Wer Home Assistant, ioBroker, Pi-hole und weitere Dienste auf einem Server betreibt, trennt sie am besten in Containern, etwa mit Docker, und setzt einen Reverse Proxy (Nginx, Caddy oder Traefik) davor, der die Verbindungen mit TLS-Zertifikaten verschlüsselt. Unverschlüsselter Zugriff auf interne Dienste ist auch im eigenen Netz nicht mehr zeitgemäß.
Die Verkabelung trägt den Rest
Sicherheit im Smart Home beginnt nicht beim Server, sondern bei der Verkabelung. Wer mit drei WLAN-Repeatern aus dem Onlinehandel ein Funknetz zusammenflickt, kann Verschlüsselung und VLANs einstellen, wie er will, die Grundlage bleibt wackelig.
Was wir bei jeder Smart-Home-Installation als Grundlage bauen:
- Cat 6A oder Cat 7 sternförmig zum zentralen Netzwerkschrank, mit Patchfeld und Beschriftung
- Access Points an der Decke mit PoE statt Repeater
- VLAN-fähige Switches, etwa von UniFi oder MikroTik, keine einfachen Billigswitches
- eine Firewall nach dem Grundsatz „alles verboten, was nicht erlaubt ist“, etwa UniFi, MikroTik oder OPNsense
- eine USV mindestens für den Netzwerkschrank und den Smart-Home-Server
Ohne diese Grundlage wirkt jede Sicherheitsmaßnahme in der Software nur halb. Mehr zur Verkabelung im Beitrag Netzwerk und WLAN planen.
Anmeldung und Zugänge
Was wir im Alltag empfehlen
- Passwortmanager (zum Beispiel Bitwarden, 1Password oder KeePassXC) für alle Smart-Home-Konten und Geräte, kein Passwort doppelt
- Zwei-Faktor-Anmeldung für jedes Cloud-Konto, das etwas Wichtiges steuert: Türschloss, Kamera, Heizung. Am besten mit einer App für Einmalcodes oder einem Hardwareschlüssel, SMS nur als letzte Wahl.
- eigene Benutzerkonten je Familienmitglied auf dem Smart-Home-Server statt eines gemeinsamen Admin-Kontos, sonst ist später nichts nachvollziehbar
- Zugangstoken statt Passwörtern für Integrationen und Skripte, regelmäßig erneuert
Fernzugriff richtig gemacht
Falsch ist eine Portweiterleitung vom Router direkt auf Home Assistant. Automatische Scanner finden offene Ports schnell und probieren Standardanmeldungen durch.
Richtig ist ein VPN ins Heimnetz, etwa mit WireGuard oder OpenVPN auf dem Router oder einem eigenen Gerät. Im VPN greift man dann auf den Smart-Home-Server zu.
Eine Alternative für gezielten Zugriff von außen ist ein Tunnel-Dienst mit vorgeschalteter Anmeldung, zum Beispiel Cloudflare Tunnel. Er öffnet keinen Port nach innen, sondern baut die Verbindung von innen nach außen auf. Das kann sinnvoll sein, wenn ein VPN nicht praktikabel ist. Dabei läuft der Verkehr aber über den Dienstleister.
Häufige Fehler
Alle IoT-Geräte im Familien-WLAN. Der Klassiker. Die günstige WLAN-Steckdose hängt im selben Netz wie der Rechner mit der Steuererklärung. Eine übernommene Steckdose wird so zum Brückenkopf. Ein eigenes IoT-VLAN mit eigenem WLAN und passenden Firewall-Regeln begrenzt, was die Steckdose im Büronetz erreichen kann.
Geräte mit Cloud-Zwang für wichtige Funktionen. Ein Türschloss, das ohne Hersteller-Cloud nicht öffnet. Eine Kamera, die ohne App-Anmeldung kein Bild liefert. Damit ist man von einer Cloud abhängig, die jederzeit teurer werden oder abgeschaltet werden kann. Wichtige Funktionen bauen wir mit Geräten, die lokal funktionieren.
Updates nach dem Motto „läuft schon“. Smart-Home-Server, Router, Access Points, Kameras: Alles braucht regelmäßige Updates. Wer einmal im Jahr aktualisiert, hat die meiste Zeit bekannte Lücken im Netz. Einen festen Rhythmus festlegen, am besten als monatlichen Termin im Kalender.
KNX-IP-Gerät ohne Secure und von außen erreichbar. Ein typischer Fehler bei älteren Anlagen: Der KNX-IP-Router hängt im Hauptnetz, manchmal sogar mit Portweiterleitung ins Internet. Wer Zugang hat, kann das ganze Haus steuern. Was hilft: prüfen, ob das Gerät KNX IP Secure beherrscht, und es dann einschalten. Geräte ohne Secure-Fähigkeit kommen in ein eigenes, abgeschottetes VLAN und werden bei Bedarf ersetzt. Zugriff von außen nur über VPN.
Sprachassistenten in jedem Raum. Alexa, Google und andere reagieren auf ein Aktivierungswort, verarbeiten die Anfragen aber in der Cloud. In sensiblen Räumen wie Arbeits- oder Schlafzimmer haben sie nichts verloren. Wer es lokal will, nimmt Home Assistant Voice mit lokaler Spracherkennung.
Saugroboter mit Kamera und Cloud. Manche Modelle laden Grundrisse und teils Bilder in die Hersteller-Cloud. Vor dem Kauf prüfen, ob ein Modell lokal betrieben werden kann, etwa Modelle, die sich mit der freien Software Valetudo betreiben lassen.
Familien-WLAN für den Fernseher. Wer den Smart-TV mit dem Familienpasswort ins Hauptnetz holt und er später keine Updates mehr bekommt, hat ein unsicheres Gerät im Hauptnetz. Fernseher gehören ins IoT-VLAN, mit eigenem WLAN-Passwort.
Standard-Adressbereich des Routers. 192.168.0.x, 192.168.1.x oder 192.168.178.x kennt jeder. Ein eigener Adressbereich schützt nicht vor ernsthaften Angriffen, vermeidet aber Adresskonflikte, wenn man sich per VPN aus einem anderen Netz verbindet.
Was wir bei der Übergabe mitgeben
- Netzwerkkonzept mit VLAN-Struktur, Firewall-Regeln und IP-Plan
- Geräteliste mit Hersteller, Modell, Firmwarestand, MAC-Adresse und VLAN
- Update-Plan für Server, Router, Access Points, Kameras und Busgeräte
- Sicherungskonzept: automatisch vor Ort und zusätzlich extern, etwa auf eine Nextcloud oder eine separate Festplatte
- Notfallunterlagen: Was tun, wenn das Internet ausfällt? Wie wird der Server zurückgesetzt? Wo liegen die Sicherungen?
- VPN-Zugang für die Wartung statt eines Hersteller-Cloudkontos mit Vollzugriff
- Datenschutzhinweise, wenn Kameras im Spiel sind (siehe Beitrag über Alarmanlagen und Videoüberwachung)
Bei Wartungskunden kommt ein regelmäßiger Sicherheitscheck dazu: Firmwarestand aller Geräte, neue bekannte Lücken, Auffälligkeiten im Firewall-Protokoll, Updates des Servers.
Was wir für Sie tun
Sicherheit im Smart Home ist keine Frage einer bestimmten Software, sondern von Disziplin: saubere Verkabelung, getrennte Netze, eine ordentliche Firewall, KNX Secure, ein lokaler Server und Updates, die wirklich stattfinden. Unser Grundsatz: lokal vor Cloud, getrennt vor flach, geprüft vor „läuft schon“.
Mehr unter KNX Smart Home und Netzwerktechnik. Wenn Sie wissen wollen, was das für Ihr Haus heißt: Kontakt oder direkt 06202 9530190.
Verwandte Beiträge und Leistungen
- KNX Smart Home: KNX Secure, lokaler Server, Visualisierung
- Netzwerktechnik und IT-Infrastruktur: Cat 6A, VLAN, Firewall, PoE-Switches
- Überwachungstechnik: IP-Kameras im eigenen VLAN, lokale Aufzeichnung
- Netzwerk und WLAN planen: die Grundlage für jedes Smart Home
- KNX im Einfamilienhaus: KNX in Neubau und Bestand
- Alarmanlagen und Videoüberwachung: Einbruchmeldeanlage, Video, DSGVO
- Brandschutz und Brandschotts: Sicherheitsleitungen durch Brandabschnitte