KNX VLAN · Сегментация сети · Брандмауэр · NIS2 · IGMP · 10 мин чтения

Безопасность магистрали KNX: сегментация сети, проектирование VLAN и правила межсетевого экрана

KNX IP использует общую Ethernet-инфраструктуру здания — без выделенной сегментации сети любое устройство в корпоративной LAN может получить доступ к порту KNXnet/IP 3671 и потенциально управлять освещением, шторами, HVAC и дверными замками. Сегментация сети — первый и наиболее эффективный уровень защиты магистрали KNX.

Почему важна безопасность магистрали KNX

Маршрутизация и туннелирование KNXnet/IP работают по стандартным UDP/TCP через Ethernet на порту 3671. Без сегментации сети устройства KNX IP доступны с любого хоста в LAN здания — включая ноутбуки сотрудников, гостевые Wi-Fi устройства и любые IoT-устройства, подключенные к той же сети. Последствия варьируются от нежелательных помех до серьезного нарушения физической безопасности.

Сценарий угрозыВектор атакиМеры защиты
Слежка за occupancy инсайдеромПерехват многоадресного трафика KNXnet/IP в LAN — определение occupancy по групповым адресам датчиков движенияШифрование KNX IP Secure + изоляция многоадресного трафика в VLAN
Несанкционированное управление зданиемОтправка телеграммы записи KNXnet/IP с ноутбука на групповой адрес дверного замкаАутентификация KNX IP Secure + изоляция VLAN + брандмауэр
Внедрение устройства на шинуФизическое подключение вредоносного устройства KNX к TP-шине — инъекция телеграммKNX Data Secure для чувствительных групповых адресов + физическая безопасность TP-шины
Удаленная эксплуатацияОткрытие порта 3671 в интернет — автоматические сканеры найдут егоНет доступа из интернета; только VPN для удаленного доступа

Проектирование VLAN для магистрали KNX IP

Выделенная VLAN для всех устройств KNX IP изолирует трафик KNXnet/IP от корпоративной LAN и гостевых сетей. Требуются управляемые коммутаторы с поддержкой VLAN — потребительские неуправляемые коммутаторы не могут реализовать такое разделение.

Рекомендуемая структура VLAN для коммерческого здания

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-адресация для устройств KNX

Все устройства KNX IP должны использовать статические IP-адреса. Адреса, назначенные по DHCP, меняются при продлении аренды — маршрутизатор KNX IP, изменивший IP-адрес, теряет свои записи таблицы маршрутизации и нарушает маршрутизацию KNXnet/IP для обслуживаемой линии до ручной перенастройки. Статическая адресация предотвращает этот сбой.

План IP-адресов VLAN KNX (пример)

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 и IGMP

Маршрутизация KNXnet/IP использует IP-многоадресную рассылку для широковещательной передачи телеграмм маршрутизации между всеми IP-маршрутизаторами в магистрали. Без IGMP snooping многоадресная рассылка заливает все порты коммутатора — включая порты корпоративной LAN — позволяя любому хосту получать телеграммы маршрутизации KNX даже без сегментации VLAN.

Конфигурация многоадресной рассылки 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)

Правила межсетевого экрана для меж-VLAN доступа

Межсетевой экран обеспечивает контроль доступа между VLAN. Политика по умолчанию для VLAN KNX должна быть deny-all — только явно разрешенный трафик проходит между корпоративной LAN и VLAN KNX. Каждое разрешенное правило должно быть задокументировано с обоснованием.

Набор правил межсетевого экрана — 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

Физическая безопасность шины

Физический доступ к шине KNX TP позволяет злоумышленнику подключить устройство мониторинга или вредоносное устройство KNX. Сетевая сегментация и KNX IP Secure не защищают от физических атак на шину TP — требуются меры физического контроля доступа в качестве дополнения.

Меры контроля физического доступа к шине TP

  • Кабельные стояки и технические помещения: заперты (ключ или карточный доступ)
  • Распределительные коробки в доступных местах: пломбы с индикацией вскрытия или запираемые корпуса
  • Программируемые разъемы KNX: активируемые ключом или запираемые RJ45 (запитываются только во время сеансов программирования)
  • Открытые кабельные лотки: закреплены для предотвращения навесных мониторов шины
  • Шкафы KNX: корпус IP54, замок с навесным замком или ключевой замок

Обнаружение изменений топологии

KNX IP-маршрутизаторы (MDT SCN-IP100.02, ABB IPS/S) поддерживают вывод syslog, включая события топологии шины. Настройка: оповещение при появлении любого нового индивидуального адреса на шине, отсутствующего в таблице программирования ETS6.

Плановая проверка топологии ETS6 (ежемесячно): сравнение с последним базовым сканированием. Любое новое устройство, появившееся без события программирования, является потенциальным инцидентом безопасности. Документируйте результаты сканирования и изменения.

Безопасность удаленного доступа

Удаленный доступ к программированию ETS6 необходим для обслуживания и обновлений системы. Этот доступ ни в коем случае не должен быть реализован путем открытия порта KNXnet/IP 3671 в интернет — автоматические сканеры находят открытые порты в течение нескольких минут, а KNXnet/IP не имеет встроенной аутентификации без IP Secure.

Проектирование безопасного удаленного доступа

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

Мониторинг и обнаружение аномалий

Активный мониторинг KNX IP-маршрутизаторов позволяет обнаруживать аномалии безопасности в режиме, близком к реальному времени. KNX IP-маршрутизаторы с выводом syslog могут передавать события на платформу SIEM для корреляции и оповещения — требуется для объектов, регулируемых NIS2, и сертифицированных по ISO 27001 операций.

Мониторинг KNX и интеграция с 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 investigation

Документация по соответствию

Директива NIS2 (ЕС) и эквивалентные национальные нормативные акты требуют от организаций, эксплуатирующих критическую инфраструктуру, вести документированные меры кибербезопасности, охватывающие системы автоматизации зданий и управления (BACS). Конструкция безопасности магистрали KNX должна быть задокументирована как часть системы управления кибербезопасностью здания.

Результаты документации

  • Диаграмма VLAN KNX (как установлено, с IP-адресацией)
  • Набор правил брандмауэра (экспортирован из интерфейса управления брандмауэром)
  • План IP-адресов (все KNX IP-устройства, статические назначения)
  • Меры физической безопасности (план контроля доступа к кабельным стоякам)
  • Процедура удаленного доступа (VPN-настройка, авторизованные пользователи)
  • Список правил оповещения SIEM и контакты для эскалации

Требования к ежегодному пересмотру

  • Проверить соответствие правил брандмауэра текущей конструкции (без ad-hoc изменений)
  • Проверить, что все KNX IP-устройства находятся в правильной VLAN (сканирование сети vs. план IP)
  • Сканирование топологии ETS6: сравнение с базовым уровнем, расследование новых устройств
  • Восстановление резервной копии проекта ETS6 (проверка целостности резервной копии)
  • Проверка списка авторизованных пользователей VPN (удаление бывших сотрудников)
  • Предоставить результаты проверки CISO клиента для обновления реестра рисков

Нужен дизайн безопасности магистрали KNX для вашего коммерческого здания?

Мы проектируем сегментацию сети KNX с выделенной VLAN, настройкой IGMP snooping, межсетевыми правилами firewall, удаленным доступом через VPN и мониторингом SIEM — полностью документировано для соответствия NIS2 и ISO 27001.

Запросить расчёт →
Загрузка ...
Наверх