Sicurezza del backbone KNX: Segmentazione di rete, progettazione VLAN e regole firewall IP
KNX IP condivide l'infrastruttura Ethernet dell'edificio — senza una segmentazione di rete dedicata, qualsiasi dispositivo sulla LAN aziendale può raggiungere la porta KNXnet/IP 3671 e potenzialmente controllare illuminazione, tapparelle, HVAC e serrature delle porte. La segmentazione di rete è il primo e più efficace strato di protezione del backbone KNX.
Perché la sicurezza del backbone KNX è importante
Il routing e il tunneling KNXnet/IP funzionano su UDP/TCP standard su Ethernet utilizzando la porta 3671. Senza segmentazione di rete, i dispositivi KNX IP sono accessibili da qualsiasi host nella LAN dell'edificio – inclusi laptop dei dipendenti, dispositivi Wi-Fi ospiti e qualsiasi dispositivo IoT connesso alla stessa rete. Le conseguenze vanno da interferenze fastidiose a una grave violazione della sicurezza fisica.
| Scenario di minaccia | Vettore di attacco | Mitigazione |
|---|---|---|
| Sorveglianza dell'occupazione da parte di insider | Sniffare il multicast KNXnet/IP sulla LAN – apprendere i modelli di occupazione dai GA dei sensori di movimento | Crittografia KNX IP Secure + confinamento VLAN del multicast |
| Controllo non autorizzato dell'edificio | Invia un telegramma di scrittura KNXnet/IP dal laptop al GA della serratura della porta | Autenticazione KNX IP Secure + isolamento VLAN + firewall |
| Iniezione di dispositivo bus | Collegare fisicamente un dispositivo KNX dannoso al bus TP — iniettare telegrammi | KNX Data Secure su GA sensibili + sicurezza fisica del bus TP |
| Sfruttamento remoto | Esporre la porta 3671 a Internet — gli strumenti di scansione automatica la trovano | Nessuna esposizione a Internet; solo VPN per accesso remoto |
Progettazione VLAN per backbone KNX IP
Una VLAN dedicata per tutti i dispositivi KNX IP isola il traffico KNXnet/IP dalla LAN aziendale e dalle reti ospiti. Sono richiesti switch gestiti con supporto VLAN – gli switch non gestiti consumer non possono implementare questa separazione.
Struttura VLAN consigliata per edifici commerciali
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
Indirizzamento IP per dispositivi KNX
Tutti i dispositivi KNX IP devono utilizzare indirizzi IP statici. Gli indirizzi assegnati via DHCP cambiano al rinnovo del lease – un router KNX IP che cambia indirizzo IP perde le voci della tabella di routing e interrompe il routing KNXnet/IP per la linea che serve fino a quando non viene riconfigurato manualmente. L'indirizzamento statico previene questa modalità di guasto.
Piano indirizzi IP VLAN KNX (esempio)
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
Multicast di routing KNXnet/IP e IGMP
Il routing KNXnet/IP utilizza il multicast IP per trasmettere telegrammi di routing tra tutti i router IP sul backbone. Senza IGMP snooping, il multicast inonda tutte le porte dello switch – incluse le porte della LAN aziendale – consentendo a qualsiasi host di ricevere telegrammi di routing KNX anche senza segmentazione VLAN.
Configurazione multicast KNXnet/IP
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)
Regole firewall per accesso inter-VLAN
Il firewall impone il controllo degli accessi tra VLAN. La politica predefinita per l'accesso alla VLAN KNX deve essere deny-all – solo il traffico esplicitamente consentito fluisce tra la LAN aziendale e la VLAN KNX. Ogni regola consentita deve essere documentata con una giustificazione aziendale.
Set di regole firewall – VLAN KNX (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
Sicurezza fisica del bus
L'accesso fisico al bus KNX TP consente a un attaccante di collegare un dispositivo di monitoraggio o un dispositivo KNX malevolo. La segmentazione di rete e KNX IP Secure non proteggono da attacchi fisici al bus TP – sono necessari controlli di accesso fisico come misura complementare.
Controlli di accesso fisico al bus TP
- Percorsi cavi e locali tecnici: chiusi a chiave (accesso con chiave o badge)
- Scatole di derivazione in aree accessibili: sigilli anti-manomissione o involucri chiusi a chiave
- Presa di programmazione KNX: attivata da interruttore a chiave o RJ45 bloccabile (alimentata solo durante le sessioni di programmazione)
- Vassoi portacavi esposti: fissare per impedire monitor bus a clip
- Quadri KNX: involucro con grado IP54, lucchetto o serratura a chiave
Rilevamento modifiche topologia
I router IP KNX (MDT SCN-IP100.02, ABB IPS/S) supportano l'output syslog inclusi gli eventi di topologia del bus. Configurare: avviso su qualsiasi nuovo indirizzo individuale che appare sul bus e non è nella tabella di programmazione ETS6.
Scansione topologia ETS6 pianificata (mensile): confrontare con l'ultima scansione di base. Qualsiasi nuovo dispositivo che appare senza un evento di programmazione è un potenziale incidente di sicurezza. Documentare i risultati della scansione e le modifiche.
Sicurezza dell'accesso remoto
L'accesso remoto a ETS6 è necessario per la manutenzione e gli aggiornamenti del sistema. Questo accesso non deve mai essere implementato aprendo la porta KNXnet/IP 3671 su Internet – gli strumenti di scansione automatizzata trovano le porte aperte in pochi minuti e KNXnet/IP non ha autenticazione integrata senza IP Secure.
Progettazione dell'accesso remoto sicuro
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
Monitoraggio e rilevamento anomalie
Il monitoraggio attivo dei router KNX IP consente il rilevamento di anomalie di sicurezza in tempo quasi reale. I router KNX IP con output syslog possono inviare eventi a una piattaforma SIEM per correlazione e allerta – richiesto per edifici regolamentati NIS2 e operazioni certificate ISO 27001.
Monitoraggio KNX e integrazione SIEM
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 investigationDocumentazione di conformità
La direttiva NIS2 (UE) e le normative nazionali equivalenti richiedono che le organizzazioni che gestiscono infrastrutture critiche mantengano misure di cybersicurezza documentate che coprano i sistemi di automazione e controllo degli edifici (BACS). Il progetto di sicurezza del backbone KNX deve essere documentato come parte del sistema di gestione della cybersicurezza dell'edificio.
Documenti da consegnare
- Diagramma VLAN KNX (come installato, con indirizzamento IP)
- Set di regole del firewall (esportato dall'interfaccia di gestione del firewall)
- Piano degli indirizzi IP (tutti i dispositivi KNX IP, assegnazioni statiche)
- Misure di sicurezza fisica (piano di controllo accessi ai percorsi cavi)
- Procedura di accesso remoto (configurazione VPN, utenti autorizzati)
- Elenco delle regole di allarme SIEM e contatti di escalation
Requisiti di revisione annuale
- Verificare che le regole del firewall corrispondano al progetto corrente (nessuna modifica ad hoc)
- Verificare che tutti i dispositivi KNX IP siano sulla VLAN corretta (scansione di rete vs. piano IP)
- Scansione topologica ETS6: confrontare con la baseline, indagare sui nuovi dispositivi
- Test di ripristino del backup del progetto ETS6 (verificare l'integrità del backup)
- Revisione dell'elenco utenti VPN autorizzati (rimuovere ex dipendenti)
- Fornire i risultati della revisione al CISO del cliente per l'aggiornamento del registro dei rischi
Hai bisogno di un progetto di sicurezza backbone KNX per il tuo edificio commerciale?
Progettiamo segmentazione della rete KNX con VLAN dedicata, configurazione IGMP snooping, regole firewall inter-VLAN, accesso remoto VPN e monitoraggio SIEM — completamente documentato per conformità NIS2 e ISO 27001.
Richiedi un preventivo →