Sécurité du backbone KNX : Segmentation réseau, conception VLAN et règles de pare-feu IP
KNX IP partage l'infrastructure Ethernet du bâtiment — sans segmentation réseau dédiée, tout périphérique du LAN d'entreprise peut atteindre le port KNXnet/IP 3671 et potentiellement contrôler l'éclairage, les stores, le CVC et les serrures de portes. La segmentation réseau est la première et la plus efficace couche de protection du backbone KNX.
Pourquoi la sécurité du backbone KNX est importante
Le routage et le tunneling KNXnet/IP fonctionnent sur UDP/TCP standard via Ethernet sur le port 3671. Sans segmentation réseau, les périphériques KNX IP sont accessibles depuis n'importe quel hôte du LAN du bâtiment – y compris les ordinateurs portables des employés, les appareils Wi-Fi invités et tout appareil IoT connecté au même réseau. Les conséquences vont d'interférences gênantes à une grave brèche de sécurité physique.
| Scénario de menace | Vecteur d'attaque | Atténuation |
|---|---|---|
| Surveillance de l'occupation par un initié | Sniffer le multicast KNXnet/IP sur le LAN – apprendre les schémas d'occupation à partir des GA des détecteurs de mouvement | Chiffrement KNX IP Secure + confinement VLAN du multicast |
| Contrôle non autorisé du bâtiment | Envoyer un télégramme d'écriture KNXnet/IP depuis un ordinateur portable vers l'AG de la serrure de porte | Authentification KNX IP Secure + isolation VLAN + pare-feu |
| Injection de périphérique bus | Connecter physiquement un périphérique KNX malveillant au bus TP — injecter des télégrammes | KNX Data Secure sur les AG sensibles + sécurité physique du bus TP |
| Exploitation à distance | Exposer le port 3671 à Internet — les outils de scan automatisés le trouvent | Pas d'exposition Internet ; VPN pour l'accès à distance uniquement |
Conception VLAN pour le backbone IP KNX
Un VLAN dédié pour tous les périphériques KNX IP isole le trafic KNXnet/IP du réseau local d'entreprise et des réseaux invités. Des commutateurs gérés avec prise en charge VLAN sont requis – les commutateurs non gérés grand public ne peuvent pas implémenter cette séparation.
Structure VLAN recommandée pour un bâtiment commercial
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
Adressage IP pour les périphériques KNX
Tous les périphériques KNX IP doivent utiliser des adresses IP statiques. Les adresses attribuées par DHCP changent lors du renouvellement du bail – un routeur KNX IP qui change d'adresse IP perd ses entrées de table de routage et interrompt le routage KNXnet/IP pour la ligne qu'il dessert jusqu'à ce qu'il soit reconfiguré manuellement. L'adressage statique empêche ce mode de défaillance.
Plan d'adressage IP VLAN KNX (exemple)
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 de routage KNXnet/IP et IGMP
Le routage KNXnet/IP utilise le multicast IP pour diffuser les télégrammes de routage entre tous les routeurs IP du backbone. Sans IGMP snooping, le multicast inonde tous les ports du commutateur – y compris les ports du réseau local d'entreprise – permettant à tout hôte de recevoir les télégrammes de routage KNX même sans segmentation VLAN.
Configuration 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)
Règles de pare-feu pour l'accès inter-VLAN
Le pare-feu applique le contrôle d'accès entre les VLAN. La politique par défaut pour l'accès au VLAN KNX doit être tout-refuser – seul le trafic explicitement autorisé circule entre le LAN d'entreprise et le VLAN KNX. Chaque règle autorisée doit être documentée avec une justification métier.
Ensemble de règles de pare-feu – 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
Sécurité physique du bus
L'accès physique au bus KNX TP permet à un attaquant de connecter un dispositif de surveillance ou un dispositif KNX malveillant. La segmentation réseau et KNX IP Secure ne protègent pas contre les attaques physiques sur le bus TP – des contrôles d'accès physiques sont nécessaires en tant que mesure complémentaire.
Contrôles d'accès physiques au bus TP
- Gaines techniques et locaux techniques : verrouillés (accès par clé ou carte)
- Boîtes de jonction dans les zones accessibles : scellés inviolables ou boîtiers verrouillés
- Prises de programmation KNX : activées par interrupteur à clé ou RJ45 verrouillable (uniquement sous tension pendant les sessions de programmation)
- Chemins de câbles exposés : sécuriser pour empêcher les moniteurs de bus à clip
- Armoires KNX : boîtier IP54, cadenas ou serrure à clé
Détection de changement de topologie
Les routeurs IP KNX (MDT SCN-IP100.02, ABB IPS/S) prennent en charge la sortie syslog incluant les événements de topologie du bus. Configurer : alerter sur toute nouvelle adresse individuelle apparaissant sur le bus qui n'est pas dans la table de programmation ETS6.
Analyse de topologie ETS6 planifiée (mensuelle) : comparer avec la dernière analyse de base. Tout nouvel appareil apparaissant sans événement de programmation est un incident de sécurité potentiel. Documenter les résultats de l'analyse et les modifications.
Sécurité de l'accès à distance
Un accès distant à ETS6 est nécessaire pour la maintenance et les mises à jour du système. Cet accès ne doit jamais être mis en œuvre en ouvrant le port KNXnet/IP 3671 sur Internet – les outils de scan automatisés trouvent les ports ouverts en quelques minutes et KNXnet/IP n'a pas d'authentification intégrée sans IP Secure.
Conception d'accès distant sécurisé
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
Surveillance et détection d'anomalies
La surveillance active des routeurs KNX IP permet de détecter les anomalies de sécurité en quasi-temps réel. Les routeurs KNX IP avec sortie syslog peuvent envoyer des événements vers une plateforme SIEM pour corrélation et alerting – requis pour les bâtiments réglementés par NIS2 et les opérations certifiées ISO 27001.
Surveillance KNX et intégration 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 investigationDocumentation de conformité
La directive NIS2 (UE) et les réglementations nationales équivalentes exigent que les organisations exploitant des infrastructures critiques maintiennent des mesures de cybersécurité documentées couvrant les systèmes d'automatisation et de contrôle des bâtiments (BACS). La conception de la sécurité du backbone KNX doit être documentée dans le cadre du système de gestion de la cybersécurité du bâtiment.
Livrables documentaires
- Schéma VLAN KNX (tel qu'installé, avec adressage IP)
- Ensemble de règles de pare-feu (exporté depuis l'interface de gestion du pare-feu)
- Plan d'adressage IP (tous les périphériques KNX IP, affectations statiques)
- Mesures de sécurité physique (plan de contrôle d'accès aux gaines de câbles)
- Procédure d'accès à distance (configuration VPN, utilisateurs autorisés)
- Liste des règles d'alerte SIEM et contacts d'escalade
Exigences de révision annuelle
- Vérifier que les règles de pare-feu correspondent à la conception actuelle (aucune modification ad hoc)
- Vérifier que tous les périphériques KNX IP sont sur le bon VLAN (scan réseau vs plan IP)
- Scan topologique ETS6 : comparer avec la référence, enquêter sur les nouveaux périphériques
- Test de restauration de sauvegarde de projet ETS6 (vérifier l'intégrité de la sauvegarde)
- Examen de la liste des utilisateurs VPN autorisés (supprimer les anciens employés)
- Fournir les résultats de l'examen au CISO du client pour mise à jour du registre des risques
Besoin d'une conception de sécurité backbone KNX pour votre bâtiment commercial ?
Nous concevons une segmentation réseau KNX avec VLAN dédié, configuration IGMP snooping, règles de pare-feu inter-VLAN, accès distant VPN et surveillance SIEM — entièrement documentée pour la conformité NIS2 et ISO 27001.
Demander un devis →