KNX Backbone Security: Netzwerksegmentierung, VLAN-Design und IP-Firewall-Regeln
KNX IP nutzt die Gebäude-Ethernet-Infrastruktur gemeinsam – ohne dedizierte Netzwerksegmentierung kann jedes Gerät im Unternehmens-LAN den KNXnet/IP-Port 3671 erreichen und potenziell Beleuchtung, Jalousien, HLK und Türschlösser steuern. Netzwerksegmentierung ist die erste und effektivste Schutzschicht des KNX-Backbones.
Warum KNX-Backbone-Sicherheit wichtig ist
KNXnet/IP-Routing und -Tunneling laufen über standardmäßiges UDP/TCP auf Ethernet mit Port 3671. Ohne Netzwerksegmentierung sind KNX-IP-Geräte von jedem Host im Gebäude-LAN aus erreichbar – einschließlich Mitarbeiter-Laptops, Gast-Wi-Fi-Geräten und jedem IoT-Gerät, das mit demselben Netzwerk verbunden ist. Die Folgen reichen von lästigen Störungen bis hin zu einem schwerwiegenden physischen Sicherheitsverstoß.
| Bedrohungsszenario | Angriffsvektor | Abhilfe |
|---|---|---|
| Überwachung der Anwesenheit durch Insider | Sniffen von KNXnet/IP-Multicast im LAN – Erkennen von Anwesenheitsmustern aus Bewegungsmelder-GAs | KNX IP Secure-Verschlüsselung + VLAN-Einkapselung von Multicast |
| Unbefugte Gebäudesteuerung | Senden Sie ein KNXnet/IP-Schreibtelegramm vom Laptop an die GA des Türschlosses | KNX IP Secure Authentifizierung + VLAN-Isolation + Firewall |
| Busgeräte-Einschleusung | Physisch ein schädliches KNX-Gerät an den TP-Bus anschließen – Telegramme einschleusen | KNX Data Secure bei sensiblen GAs + physische TP-Bus-Sicherheit |
| Remote-Ausnutzung | Port 3671 dem Internet aussetzen – automatisierte Scan-Tools finden ihn | Keine Internet-Exposition; VPN nur für Fernzugriff |
VLAN-Design für KNX-IP-Backbone
Ein dediziertes VLAN für alle KNX-IP-Geräte isoliert den KNXnet/IP-Datenverkehr vom Firmennetzwerk und Gastnetzwerken. Verwaltete Switches mit VLAN-Unterstützung sind erforderlich – nicht verwaltete Switches für Endverbraucher können diese Trennung nicht umsetzen.
Empfohlene VLAN-Struktur für gewerbliche Gebäude
VLAN 10 — Corporate LAN Employee workstations, printers, VoIP phones DHCP from corporate DHCP server Internet access: full (via firewall) VLAN 20 — Guest Wi-Fi Visitor devices, bring-your-own-device Internet access only, isolated from all other VLANs No access to corporate LAN, KNX VLAN, or IoT VLAN VLAN 30 — IoT Sensors Building sensors (CO2, temperature, occupancy — IP type) No access to KNX VLAN or corporate LAN Data collected to BMS server only (explicit allow rule) VLAN 100 — KNX Automation ← dedicated KNX VLAN All KNX IP routers (by floor and line) All KNX IP tunnelling interfaces HomeServer / ARISTO / Gira X1 visualisation servers DALI gateways with IP connectivity ETS6 commissioning laptop (during commissioning only) Switch port configuration: KNX IP router ports: access mode, VLAN 100 untagged Server ports (HomeServer, X1): trunk mode, VLAN 10 + 100 Commissioning port: access mode, VLAN 100 (remove after handover) Uplink to firewall: trunk mode, all VLANs tagged
IP-Adressierung für KNX-Geräte
Alle KNX-IP-Geräte müssen statische IP-Adressen verwenden. DHCP-vergebene Adressen ändern sich bei Verlängerung der Lease – ein KNX-IP-Router, der seine IP-Adresse ändert, verliert seine Routing-Tabelleneinträge und unterbricht das KNXnet/IP-Routing für die von ihm bediente Linie, bis er manuell neu konfiguriert wird. Statische Adressierung verhindert diesen Fehlerfall.
KNX-VLAN-IP-Adressplan (Beispiel)
Subnet: 192.168.100.0/24 (KNX VLAN 100) Gateway: 192.168.100.254 (firewall inter-VLAN interface) KNX IP routers — by floor and line: .1 — Ground floor, line 1 (KNX area 1.1) .2 — Ground floor, line 2 (KNX area 1.2) .10 — First floor, line 1 (KNX area 2.1) .11 — First floor, line 2 (KNX area 2.2) .20 — Second floor, line 1 (KNX area 3.1) (continue per floor/line combination) Servers and gateways: .100 — Gira HomeServer / ARISTO server .101 — Gira X1 (if separate from HomeServer) .102 — DALI gateway (if IP-connected) .103 — KNX to BACnet / Modbus gateway Commissioning devices (temporary): .200 — ETS6 commissioning laptop (remove after handover) .201 — Thermography camera / test laptop Document IP plan in: Building technical manual (as-installed) Network diagram (Visio or draw.io, stored with O&M documentation) ETS6 project: each IP router properties → IP address field
KNXnet/IP-Routing-Multicast und IGMP
KNXnet/IP-Routing verwendet IP-Multicast, um Routing-Telegramme zwischen allen IP-Routern im Backbone zu übertragen. Ohne IGMP-Snooping flutet Multicast alle Switch-Ports – einschließlich Firmennetzwerk-Ports – sodass jeder Host KNX-Routing-Telegramme empfangen kann, selbst ohne VLAN-Segmentierung.
KNXnet/IP Multicast-Konfiguration
KNXnet/IP routing multicast address: 224.0.23.12 (IANA assigned) UDP port: 3671 All KNX IP routers join and send to this multicast group IGMP snooping — required on KNX VLAN switch: Enable IGMP snooping on VLAN 100 Function: switch tracks which ports have joined multicast group Result: multicast sent only to ports with KNX IP routers Without IGMP snooping: multicast floods ALL ports in VLAN 100 IGMP querier: Enable IGMP querier on the VLAN 100 switch or L3 interface Querier sends periodic IGMP membership queries KNX IP routers respond with IGMP join — switch maintains table Without querier: IGMP snooping table expires → multicast floods Multicast containment to VLAN 100: Firewall / L3 switch: block multicast routing between VLANs 224.0.23.12 should NEVER appear on VLAN 10 (corporate LAN) Verify: Wireshark capture on corporate LAN port → no 224.0.23.12 packets visible Alternative: KNXnet/IP unicast routing (newer installations) ETS6 6.x supports unicast routing between IP routers Avoids multicast entirely — better for strict networks Requires compatible IP routers (check manufacturer support)
Firewall-Regeln für Inter-VLAN-Zugriff
Die Firewall erzwingt die Zugriffskontrolle zwischen VLANs. Die Standardrichtlinie für den KNX-VLAN-Zugriff muss Deny-All sein – nur explizit erlaubter Datenverkehr fließt zwischen dem Unternehmens-LAN und dem KNX-VLAN. Jede erlaubte Regel sollte mit einer geschäftlichen Begründung dokumentiert werden.
Firewall-Regelsatz – KNX-VLAN (VLAN 100)
Default policy: DENY ALL (inbound and outbound) ALLOW rules (corporate LAN VLAN 10 → KNX VLAN 100): Source: engineering workstation subnet (192.168.10.50-60) Dest: HomeServer (192.168.100.100) Port: TCP 443 (HTTPS) — visualisation access Log: YES, all connections Source: ETS6 commissioning laptop (192.168.100.200) Dest: all KNX IP routers (192.168.100.1-.30) Port: UDP/TCP 3671 — ETS6 programming Note: commissioning rule only — remove after handover Log: YES, all connections DENY rules (explicit — logged for audit): Source: any VLAN 10 host Dest: KNX VLAN 100 Port: UDP 3671 — all other KNXnet/IP access Action: DENY + LOG ALLOW rules (KNX VLAN 100 → internet/management): Source: HomeServer (192.168.100.100) Dest: NTP server (pool.ntp.org or internal NTP) Port: UDP 123 Source: HomeServer (192.168.100.100) Dest: Gira cloud (for Gira X1 remote feature) Port: TCP 443 (HTTPS outbound only) DENY rules (KNX VLAN → internet, all other): Source: KNX IP routers (192.168.100.1-.30) Dest: any internet Action: DENY (KNX IP routers should not reach internet) Log: YES — alert if any router attempts internet connection
Physische Bussicherheit
Physischer Zugriff auf den KNX-TP-Bus ermöglicht einem Angreifer, ein Überwachungsgerät oder ein schädliches KNX-Gerät anzuschließen. Netzwerksegmentierung und KNX IP Secure schützen nicht vor physischen TP-Bus-Angriffen – physische Zugriffskontrollen sind als ergänzende Maßnahme erforderlich.
Physische TP-Bus-Zugriffskontrollen
- Kabeltrassen und Technikräume: verschlossen (Schlüssel- oder Kartenzugang)
- Abzweigdosen in zugänglichen Bereichen: manipulationssichere Siegel oder verschlossene Gehäuse
- KNX-Programmierdosen: schlüsselschalteraktiviert oder verriegelbarer RJ45 (nur für Programmier-Sitzungen unter Spannung)
- Freiliegende Kabeltrassen: sichern, um Clip-on-Busmonitore zu verhindern
- KNX-Schaltschränke: IP54-Schutzart, Vorhängeschloss oder Schlüsselschloss
Topologieänderungserkennung
KNX-IP-Router (MDT SCN-IP100.02, ABB IPS/S) unterstützen Syslog-Ausgabe mit Bus-Topologie-Ereignissen. Konfigurieren: Alarm bei jeder neuen Einzeladresse am Bus, die nicht in der ETS6-Programmiertabelle steht.
Geplante ETS6-Topologiescan (monatlich): mit letztem Basisscan vergleichen. Jedes neue Gerät ohne Programmierereignis ist ein potenzieller Sicherheitsvorfall. Scanergebnisse und Änderungen dokumentieren.
Fernzugriffssicherheit
Für Wartung und Systemaktualisierungen ist ein Fernzugriff auf ETS6 erforderlich. Dieser Zugriff darf niemals durch Öffnen des KNXnet/IP-Ports 3671 ins Internet erfolgen – automatisierte Scan-Tools finden offene Ports innerhalb von Minuten, und KNXnet/IP verfügt ohne IP Secure über keine integrierte Authentifizierung.
Sicherer Fernzugriff – Design
Recommended: VPN to management VLAN → ETS6 via KNX VLAN VPN gateway options: WireGuard: modern, fast, cryptographically strong (ChaCha20) OpenVPN: established, widely supported, certificate-based IPsec IKEv2: enterprise standard, compatible with Windows/macOS VPN authentication: certificate (client cert) + password (2FA) Never: username + password only (too weak for building access) MFA options: TOTP (Google Authenticator), FIDO2 hardware key Access flow: Engineer → VPN (WireGuard, certificate + TOTP) → Management VLAN gateway → Firewall allow: engineer VPN IP → KNX VLAN 100 port 3671 → ETS6 connects to KNX IP router via IP Secure tunnelling → Programming session (authenticated and encrypted) Log all VPN connections: Source IP, VPN user, connect time, disconnect time Send to SIEM or centralised log server Alert on: off-hours connections, unusual source IPs, multiple failed authentication attempts Alternative (if Gira X1 in design): Gira X1 Remote Access feature: proprietary encrypted tunnel via Gira cloud infrastructure — no VPN gateway required Authentication: Gira account with 2FA Acceptable for ETS6 tunnelling IF X1 already in design
Überwachung und Anomalieerkennung
Die aktive Überwachung von KNX-IP-Routern ermöglicht die Erkennung von Sicherheitsanomalien in nahezu Echtzeit. KNX-IP-Router mit Syslog-Ausgabe können Ereignisse an eine SIEM-Plattform zur Korrelation und Alarmierung weiterleiten – erforderlich für NIS2-regulierte Gebäude und ISO 27001-zertifizierte Betriebe.
KNX-Überwachung und SIEM-Integration
KNX IP router syslog configuration (MDT SCN-IP100.02):
Enable: syslog output (UDP 514 to log server)
Log events:
- New device individual address on bus (topology change)
- Programming mode activation (ETS6 download started)
- Bus restart / reset events
- IP Secure authentication failures (if IP Secure enabled)
- High telegram rate events (potential bus flooding)
SIEM platforms (forward KNX syslog):
Splunk: KNX IP router syslog source → custom alert rules
Elastic SIEM: Filebeat agent ingests syslog → Kibana alerts
Wazuh (open source): agent-based, lower cost for small buildings
Alert rules for security events:
New KNX individual address on bus (not in programming session):
→ Alert: "Possible rogue KNX device detected"
→ Action: initiate ETS6 topology scan, physical inspection
Programming mode activation outside maintenance window:
→ Alert: "Unscheduled ETS6 download detected"
→ Action: verify with on-site engineer
High telegram rate (> 2× normal baseline for 60 seconds):
→ Alert: "Possible KNX bus flooding attack"
→ Action: check IP Secure log for auth failures
IP Secure authentication failure (> 3 in 10 minutes):
→ Alert: "Repeated IP Secure auth failure — possible brute force"
→ Action: block source IP at firewall pending investigationCompliance-Dokumentation
Die NIS2-Richtlinie (EU) und entsprechende nationale Vorschriften verlangen von Organisationen, die kritische Infrastrukturen betreiben, dass sie dokumentierte Cybersicherheitsmaßnahmen für Gebäudeautomations- und Steuerungssysteme (BACS) vorhalten. Das Sicherheitsdesign des KNX-Backbones muss als Teil des Cybersicherheitsmanagementsystems des Gebäudes dokumentiert sein.
Dokumentationsliefergegenstände
- KNX-VLAN-Diagramm (wie installiert, mit IP-Adressierung)
- Firewall-Regelsatz (exportiert aus der Firewall-Verwaltungsoberfläche)
- IP-Adressplan (alle KNX-IP-Geräte, statische Zuweisungen)
- Physische Sicherheitsmaßnahmen (Zugangskontrollplan für Kabeltrassen)
- Fernzugriffsverfahren (VPN-Einrichtung, autorisierte Benutzer)
- SIEM-Alarmregelliste und Eskalationskontakte
Anforderungen an die jährliche Überprüfung
- Überprüfen, ob die Firewall-Regeln mit dem aktuellen Design übereinstimmen (keine Ad-hoc-Änderungen)
- Überprüfen Sie alle KNX-IP-Geräte im richtigen VLAN (Netzwerkscan vs. IP-Plan)
- ETS6-Topologiescan: mit der Baseline vergleichen, neue Geräte untersuchen
- ETS6-Projekt-Backup-Wiederherstellungstest (Backup-Integrität prüfen)
- Überprüfung der autorisierten VPN-Benutzerliste (ehemalige Mitarbeiter entfernen)
- Prüfungsergebnisse dem CISO des Kunden zur Aktualisierung des Risikoregisters vorlegen
Benötigen Sie ein KNX-Backbone-Sicherheitsdesign für Ihr Gewerbegebäude?
Wir entwerfen KNX-Netzwerksegmentierung mit dediziertem VLAN, IGMP-Snooping-Konfiguration, Inter-VLAN-Firewall-Regeln, VPN-Fernzugriff und SIEM-Überwachung – vollständig dokumentiert für NIS2- und ISO-27001-Konformität.
Angebot anfordern →