Ein vernetztes Haus ist ein produktives Haus, bis es zum Problem wird. Smart Home heißt: Heizung, Licht, Rollläden, Türstation, Kameras, Saugroboter, Sprachassistenten, Lautsprecher, Klingel und Garagentor hängen am Netz und reden miteinander. Praktisch im Alltag. Genau das ist auch die Angriffsfläche, mit der ein Hacker im Mirai-Botnet-Stil Millionen von Geräten gleichzeitig kapern konnte, schlecht gesicherte IP-Kameras, Router und IoT-Geräte aus dem Niedrigpreis-Segment.
Die Realität in deutschen Haushalten ist gemischt. Auf der einen Seite stehen sauber gebaute KNX-Installationen mit lokalem Bus-Server, ordentlicher Firewall und VLAN-getrennten Funknetzen. Auf der anderen Seite stehen Häuser, in denen 30 IoT-Geräte aus fünf Hersteller-Apps im gleichen WLAN hängen, jeder Sensor seine eigene Cloud-Verbindung in irgendein Rechenzentrum aufbaut und das Standardpasswort der Türklingel “1234” lautet. Die zweite Variante ist häufiger.
Dieser Artikel zeigt, wie Smart Home so gebaut wird, dass es technisch zuverlässig funktioniert und nicht zur Eintrittstür wird, mit konkreten Maßnahmen, konkreten Standards und ehrlichen Trade-offs.
IoT-Risiken, konkret, nicht abstrakt
Was die Bedrohung wirklich aussieht
Mirai-Botnet (2016, weiterhin aktiv in Varianten): Selbstreplizierender Schadcode, der das Internet nach IP-Kameras, DVRs und Routern mit Standard-Passwörtern absucht. Bei Erfolg wird das Gerät Teil eines Botnets, das DDoS-Angriffe ausführt. Die ursprüngliche Variante hat über 600.000 IoT-Geräte gleichzeitig kontrolliert. Nachfolger laufen bis heute.
Kompromittierte ESP-Geräte: Günstige WLAN-Schalter, Steckdosen und Sensoren mit ESP8266/ESP32-Chip werden oft mit unsicherer Firmware ausgeliefert. Wenn der Hersteller die Geräte vergisst, gibt es keine Updates mehr. Bekannt sind Fälle, in denen Geräte still und leise Teil von Botnetzen wurden, ohne dass der Besitzer es jemals gemerkt hat.
Ungesicherte Funk-Repeater und Mesh-Knoten: Manche WLAN-Repeater im Niedrigpreis-Segment haben fest verdrahtete Admin-Zugänge oder unaktualisierbare Web-Interfaces mit Sicherheitslücken. Über solche Geräte landet ein Angreifer mitten im Heimnetz.
Veraltete Smart-TV-Software: Smart-TVs werden 8-10 Jahre genutzt, bekommen aber nach 3-5 Jahren keine Sicherheitsupdates mehr. Ein gehackter Smart-TV im Wohnzimmer-Netzwerk hat Zugriff auf alle Geräte im selben Subnetz, Drucker, Computer, Speicher.
Zigbee/Z-Wave-Hubs mit Cloud-Zwang: Wenn die Hersteller-Cloud kompromittiert wird, sind alle daran angebundenen Geräte exponiert. Mehrere große Hersteller hatten in den letzten Jahren Vorfälle, bei denen Kontodaten und teils Steuerbefehle abgegriffen wurden.
Angriffsvektoren im Überblick
| Vektor | Wie der Angriff aussieht | Schutzmaßnahme |
|---|---|---|
| Default-Passwörter | ”admin/admin”, “1234”, werkseitig identisch über ganze Geräteklassen | Sofort ändern, individuelle Passwörter aus Passwort-Manager |
| Ungesicherte Update-Channels | Firmware-Update über HTTP statt HTTPS, ohne Signaturprüfung | Geräte ausschließen, die keine signierten Updates liefern |
| Schwache WLAN-Verschlüsselung | WEP, WPA, WPA2-PSK mit kurzem Passwort | WPA3 (Personal/Enterprise), 20+ Zeichen lange Pre-Shared Keys |
| Fehlende VLAN-Trennung | Alle Geräte im gleichen Subnetz, kompromittiertes IoT erreicht Bürorechner | Strikte VLAN-Trennung, Firewall mit Default-Deny |
| Veraltete Firmware | Bekannte Sicherheitslücken bleiben offen, weil niemand updatet | Update-Strategie definieren, ggf. Wartungsvertrag |
| Cloud-Account-Kompromittierung | Hersteller-Konto wird gehackt, Angreifer steuert Geräte | Geräte ohne Cloud-Zwang bevorzugen, 2FA wo möglich |
| Unverschlüsselter Funk | KNX-IP, WLAN, Zigbee ohne Verschlüsselung, mithörbar mit Software-Radio | KNX Secure, WPA3, verschlüsselte Zigbee-Profile |
| Physischer Zugriff | UART/JTAG-Pins zugänglich, lokales Auslesen | Gerätestandort, Gehäuse-Plomben bei kritischen Anwendungen |
KNX Secure, der Bus mit Verschlüsselung
Warum KNX immer noch der Goldstandard ist
KNX (vorher EIB) läuft seit den 90ern als zweiadriger Bus durch deutsche Häuser. Verkabelt, robust, herstellerunabhängig, mit echter Standardisierung über die KNX Association. Die klassische KNX-TP-Verkabelung (Twisted Pair) ist physikalisch schwer angreifbar, wer dort manipulieren will, muss ins Haus.
Was klassisches KNX nicht hatte: Verschlüsselung. Auf dem Bus selbst lief alles im Klartext. Solange das KNX-System rein als lokaler Bus ohne IP-Anbindung lief, war das in Ordnung. Sobald aber KNX-IP-Gateways oder KNX-IP-Visualisierungen ins Spiel kommen, und das ist heute die Regel -, wird verschlüsselte Übertragung Pflicht.
KNX Secure, die zwei Säulen
| Standard | Was er sichert | Wann er greift |
|---|---|---|
| KNX Data Secure | Telegramme auf dem Bus selbst (TP und IP) | Auf Geräteebene konfiguriert in ETS |
| KNX IP Secure | KNX-Tunneling und KNX-IP-Routing über das Netzwerk | An IP-Gateways und Routern |
KNX Data Secure verschlüsselt die Kommunikation zwischen Aktoren, Sensoren und Visualisierung mit AES-128. Wer den Bus mithört, sieht nur verschlüsselten Datenverkehr. Damit das funktioniert, müssen alle beteiligten Geräte Secure-fähig sein, das ist bei neueren KNX-Komponenten Standard, bei älteren oft nicht nachrüstbar.
KNX IP Secure sichert die Anbindung von Visualisierung, Smart-Home-Servern und externen Zugriffen ab. Pflicht bei jedem KNX-IP-Gateway, das über das Internet erreichbar gemacht werden soll, auch über VPN.
Praxis-Hinweise
- ETS-Projektpasswort und Backup-Codes sicher verwahren, wer das Projekt verliert, kann das Secure-Setup nicht mehr ändern, ohne alle Geräte neu zu programmieren
- Visualisierungs-Server (Gira X1, MDT VisuControl, Hager domovea) hinter Firewall, nicht direkt ans Internet hängen, Zugriff von außen ausschließlich über VPN ins Heimnetz
- Tunneling und Routing klar trennen: Routing nur im internen Netz, Tunneling für Konfigurations- und Visualisierungs-Anbindung
Netzwerksegmentierung, die wichtigste Einzelmaßnahme
Warum ein flaches Netz unsicher ist
Im klassischen Heimnetzwerk hängen alle Geräte im gleichen Subnetz. Wenn der Saugroboter eine Sicherheitslücke hat, kann er theoretisch jedes andere Gerät erreichen. Das ist nicht hypothetisch, bekannte Angriffe haben über Smart-TVs, IP-Kameras und Saugroboter laterale Bewegung in lokale Netzwerke vollzogen.
VLANs lösen das. Ein VLAN trennt das Netzwerk logisch in mehrere isolierte Segmente. Geräte in einem VLAN können andere VLANs nur erreichen, wenn die Firewall das explizit erlaubt.
Konkrete VLAN-Struktur für ein modernes Smart Home
| VLAN-ID | Name | Geräte | Internet | Zugriff andere VLANs |
|---|---|---|---|---|
| 10 | Management | Switch, AP, Router, NVR-Management | restriktiv | nur vom Admin-Client |
| 20 | Familie/Hauptnetz | Laptops, Smartphones, Familien-Tablets | voll | gezielt auf Smart-Home-Server |
| 30 | IoT/Smart Home | Saugroboter, Smart-TVs, Sprachassistenten, smarte Steckdosen | restriktiv (nur DNS und Hersteller-Server) | nein |
| 40 | KNX/Bus-Server | KNX-IP-Gateway, Home Assistant, ioBroker, Gira X1 | restriktiv | nur Hauptnetz und Management |
| 50 | Kameras/Sicherheit | IP-Kameras, NVR, Türstation | nein (lokal) | nur Management |
| 60 | Gäste | Gäste-WLAN | voll, Bandbreitenlimit | keine anderen VLANs |
| 70 | Arbeit (falls Homeoffice) | Firmen-Laptop, Diensttelefon | voll | streng isoliert |
Worauf bei der VLAN-Implementierung zu achten ist
- Mehrere SSIDs für unterschiedliche VLANs: Familien-WLAN auf VLAN 20, IoT-WLAN auf VLAN 30, Gäste-WLAN auf VLAN 60, getrennt nach Funktion
- Firewall-Default-Deny: alles, was nicht explizit erlaubt ist, wird blockiert
- mDNS-/Broadcast-Reflexion für ausgewählte Dienste (z. B. AirPlay, Chromecast) gezielt freigeben, sonst funktionieren manche bequemen Smart-Home-Features nicht
- DNS über das Management-VLAN: zentraler DNS-Resolver (Pi-hole oder NextDNS), der Tracking-Domains blockiert und Logs erstellt
- Logging einschalten: Wer welche VLAN-Grenze wie oft überschreitet, das ist die einzige Chance, später eine Auffälligkeit zu erkennen
Bus-Server und Smart-Home-Plattformen
Lokal vs. Cloud, die Grundsatzentscheidung
| Eigenschaft | Lokaler Server | Cloud-Plattform |
|---|---|---|
| Funktioniert ohne Internet | ja | nein |
| Datenhoheit | beim Nutzer | beim Hersteller |
| Latenz | sehr niedrig | abhängig von Cloud |
| Update-Verantwortung | Nutzer/Errichter | Hersteller |
| Wartungsaufwand | regelmäßig | gering bei Nutzer |
| Risiko Hersteller-Pleite | irrelevant | hoch (Bricking) |
| Typische Vertreter | Home Assistant, ioBroker, openHAB, Gira X1, MDT VisuControl | Apple Home, Google Home, Alexa, Tuya |
Unsere Empfehlung: Lokale Server als Kern, Cloud nur dort, wo sie tatsächlich einen Mehrwert bringt (z. B. Sprachsteuerung mit Alexa/Google bei Nutzern, die das ausdrücklich wollen). Selbst dann läuft die Bus-Logik lokal, die Cloud ist nur die Bedienoberfläche.
Update-Strategie für lokale Bus-Server
Home Assistant läuft typischerweise auf einem Mini-Server (Home Assistant Yellow, Green oder selbstgebautes NUC mit HAOS) und bekommt monatlich (am ersten Mittwoch im Monat) ein Core-Release mit Bugfixes und Sicherheitspatches. Die Pflicht: regelmäßig updaten, automatische Backups vor jedem Update, einen geplanten Wartungstag pro Monat.
ioBroker auf Linux (Debian, Ubuntu): Adapter-Updates und Core-Updates getrennt prüfen, vor größeren Updates Snapshot anlegen.
Gira X1 / Hager domovea / MDT VisuControl: Hersteller-Software-Updates über ETS oder Hersteller-Tool, etwa 2-3 mal pro Jahr. Hier ist der Errichter in der Pflicht, der Hausherr macht das selten selbst.
Was eine ordentliche Update-Strategie ausmacht:
- Backup vor jedem Update, automatisiert oder per Skript
- Test in nicht-kritischer Zeit (nicht Freitagabend, wenn man am Wochenende keine Lust hat zu fixen)
- Rollback-Plan: Welche Version war vorher drauf, wie wird zurückgerollt
- Update-Log: Wann wurde was aktualisiert, welche Auffälligkeiten gab es danach
Container und Reverse Proxy
Wer Home Assistant, ioBroker, Pi-hole und weitere Dienste auf einem Server kombiniert, sollte das in Docker-Containern isolieren, und einen Reverse Proxy (Nginx, Caddy, Traefik) davor setzen, der TLS-Terminierung mit Let’s-Encrypt-Zertifikaten übernimmt. Direkter HTTP-Zugriff auf interne Dienste ist auch im LAN heute nicht mehr zeitgemäß.
Strukturierte Verkabelung, die unsichtbare Basis
Smart-Home-Sicherheit fängt nicht beim Server an, sondern bei der Verkabelung. Wer mit drei WLAN-Repeatern aus dem Onlinehandel ein Funkfeld zusammenflickt, kann Verschlüsselung und VLANs konfigurieren wie er will, die physische Grundlage ist instabil.
Was wir bei jeder Smart-Home-Installation als Basis bauen:
- Cat6A oder Cat7 sternförmig zu zentralem Netzwerkschrank, mit Patchpanel und Beschriftung
- Access Points an der Decke per PoE, keine Repeater-Lösungen
- VLAN-fähiger Switch (UniFi USW, MikroTik CRS), kein 30-Euro-Plastik aus dem Discounter
- Firewall mit Default-Deny (UniFi Dream Machine, MikroTik mit RouterOS, OPNsense)
- USV für mindestens den Hauptverteiler und den Bus-Server
Ohne diese Grundlage ist jede Sicherheits-Software-Maßnahme darüber halb wirkungslos. Details zur strukturierten Verkabelung im Artikel zu Netzwerkinstallation und WLAN-Optimierung.
Authentifizierung und Zugangsmanagement
Was wir im Alltag empfehlen
- Passwort-Manager (Bitwarden, 1Password, KeePassXC) für alle Smart-Home-Accounts und Geräte-Logins, kein Passwort doppelt verwenden
- Zwei-Faktor-Authentifizierung für jeden Cloud-Account, der einen kritischen Dienst betreibt (Türschloss, Kamera, Heizungssteuerung). Idealerweise per TOTP-App (Aegis, Authy) oder Hardware-Schlüssel (YubiKey), SMS nur als letzte Wahl.
- Eigene Benutzerkonten pro Familienmitglied im Bus-Server statt eines geteilten Admin-Accounts, das macht spätere Nachvollziehbarkeit überhaupt erst möglich
- API-Tokens statt Passwörter für Integrationen (Home Assistant Long-Lived Tokens, Skript-Anbindungen) und diese rotieren
Fernzugriff, sauber gemacht
Falsch: Port-Forwarding vom Router direkt auf Home Assistant. Innerhalb von Tagen sucht ein Bot die offene Port und probiert Standard-Logins durch.
Richtig: VPN-Tunnel ins Heimnetz. Dafür WireGuard (modern, schnell, schlank) oder OpenVPN auf dem Router oder einer dedizierten Box. Innerhalb des VPN-Tunnels läuft dann der Zugriff auf den Smart-Home-Server.
Alternative für gezielten externen Zugriff: Cloudflare Tunnel (Argo Tunnel) als Zero-Trust-Lösung mit Authentifizierung vor dem eigentlichen Dienst. Der Tunnel öffnet keinen Inbound-Port, sondern baut eine Verbindung von innen nach außen auf, gute Lösung, wenn VPN nicht praktikabel ist.
Häufige Fehler bei Smart-Home-Sicherheit
Alle IoT-Geräte im Familien-WLAN. Klassiker. Der billige Smart-Plug aus China sitzt im selben Netz wie der Steuer-Computer. Eine kompromittierte Steckdose ist damit ein Brückenkopf. Lösung: dediziertes IoT-VLAN mit eigenem SSID.
Cloud-Zwang-Geräte für Kernfunktionen. Türschloss, das ohne Hersteller-Cloud nicht aufgeht. Kamera, die ohne App-Login keinen Stream liefert. Wer hier nicht aufpasst, ist abhängig von einer Cloud, die jederzeit Preise erhöhen oder den Dienst einstellen kann. Wir bauen Kernfunktionen ausschließlich mit lokal funktionierenden Geräten.
Updates “läuft schon”. Smart-Home-Server, Router-Firmware, AP-Firmware, Kamera-Firmware, alles braucht regelmäßige Updates. Wer das einmal pro Jahr macht und sonst nicht, hängt nach 6 Monaten mit bekannten Sicherheitslücken im Netz. Update-Rhythmus festlegen, am besten als monatlichen Termin im Kalender.
KNX-IP-Gateway ohne Secure und direkt erreichbar. Klassischer Konfigurationsfehler bei älteren Anlagen: KNX-IP-Router hängt im Hauptnetz, manchmal sogar mit Port-Forwarding. Wer ETS und das Projekt-Passwort kennt, kann das ganze Haus fernsteuern. Lösung: KNX IP Secure aktivieren, IP-Gateway ins eigene VLAN, externer Zugriff nur per VPN.
Sprachassistenten als Universal-Mikrofon. Alexa, Google Home und Co. hören “ständig zu”, formal nur auf das Wake Word, faktisch fließen aber Audio-Snippets in die Cloud. Wer datensensible Räume hat (Arbeitszimmer, Schlafzimmer), platziert solche Geräte nicht dort. Wer maximale Lokalität will, setzt auf lokale Alternativen wie Rhasspy oder Home Assistant Voice mit lokal verarbeiteter Spracherkennung.
Saugroboter mit Kamera und Cloud-Sync. Manche Modelle laden Wohnungs-Grundrisse und teilweise Bildmaterial in Hersteller-Clouds. Vor dem Kauf prüfen, ob ein Modell mit ausschließlich lokaler Verarbeitung erhältlich ist (Valetudo-fähige Roborock-Modelle z. B.).
WLAN-Passwort als Smart-TV-Passwort. Wer mit dem Familien-WLAN-Passwort einen Smart-TV einrichtet, der drei Jahre später keine Updates mehr bekommt, gibt einem unsicheren Gerät Zugang zum Hauptnetz. Smart-TVs gehören ins IoT-VLAN, mit eigenem WLAN-Passwort, das nicht das Familien-Passwort ist.
Standard-IP-Bereich vom Router unverändert. 192.168.0.1 / 192.168.1.1 / 192.168.178.1, die kennt jeder Bot. Eigene IP-Range hilft nicht gegen ernsthafte Angriffe (Security by Obscurity), reduziert aber automatisierte Scans und vermeidet IP-Konflikte beim VPN-Roaming.
Was wir bei einer Smart-Home-Installation übergeben
- Netzwerkkonzept mit VLAN-Struktur, Firewall-Regeln, IP-Plan
- Geräteinventar mit Hersteller, Modell, Firmware-Stand, MAC-Adresse, VLAN
- Update-Plan für Server, Router, AP, Kameras, Bus-Komponenten
- Backup-Strategie: lokal automatisiert, zusätzlich extern (z. B. Nextcloud, separate Festplatte)
- Notfall-Doku: Was tun, wenn Internet ausfällt; wie wird der Bus-Server zurückgesetzt; wo liegen die Konfigurations-Backups
- VPN-Zugang für Wartungspersonal, kein Hersteller-Cloud-Konto mit Vollzugriff
- DSGVO-Hinweise, wenn Kameras im Spiel sind (siehe Alarmanlagen-Artikel)
Bei Wartungskunden kommt ein regelmäßiger Sicherheits-Check dazu: Firmware-Stand aller Geräte, neue Sicherheitslücken, Firewall-Log-Auffälligkeiten, Bus-Server-Updates.
Fazit
Smart-Home-Sicherheit ist keine Software-Frage, sondern eine Disziplin. Sie beginnt bei der strukturierten Verkabelung, läuft über VLAN-Segmentierung und eine ordentliche Firewall, geht durch KNX-Secure und lokal betriebene Bus-Server, und endet bei einer Update-Strategie, die nicht in der Schublade liegt.
Wer das ernst nimmt, bekommt ein Haus, das funktioniert, und nicht zur Eintrittstür wird. Wer es ignoriert, hat eine Sammlung vernetzter Geräte, von denen jedes einzelne ein potentielles Risiko ist. Unsere Empfehlung: lokal vor Cloud, getrennt vor flach, geprüft vor “läuft schon”.
Mehr zur Substanz unter KNX Smart Home und Netzwerktechnik. Konkretes Objekt? Kontakt oder 06202 9530190.
Verwandte Beiträge und Leistungen
- KNX Smart Home, KNX Secure, lokaler Bus-Server, Visualisierung
- Netzwerktechnik & IT-Infrastruktur, Cat6A, VLAN, Firewall, PoE-Switching
- Überwachungstechnik, IP-Kameras im eigenen VLAN, lokale Aufzeichnung
- Netzwerkinstallation & WLAN-Optimierung, strukturierte Basis für jedes Smart Home
- KNX Smart Home und Energieeinsparung, KNX im Bestand und Neubau
- Alarmanlagen & Videoüberwachung, EMA, KI-Video, DSGVO
- Brandschutz & Brandschotts, sicherheitstechnische Leitungen über Brandabschnitte
