В профессиональной среде принято считать ЦОД образцом контролируемой среды. Многоуровневый физический периметр, строгий СКУД, видеонаблюдение – все это создает ощущение тотального контроля. Однако за последние несколько лет конфигурация угроз заметно сместилась. Физическая инфраструктура дата-центров – чиллеры, ИБП, прецизионные кондиционеры, интеллектуальные блоки розеток – окончательно стала цифровой и, что существенно, сетевой. И, судя по доступным данным, с защитой этих систем есть проблемы.
Автор: Алексей Карабась, эксперт по сетевой безопасности в ЦОД
Речь не об абстрактных рассуждениях, а о вполне конкретном феномене: штатные функции инженерных протоколов могут использоваться для нанесения физического урона инфраструктуре. При этом классический SOC, ориентированный на мониторинг трафика North-South и вооруженный SIEM, такие атаки чаще всего пропускает.
Откуда взялась проблема?
Лет пятнадцать назад инженерные системы ЦОД существовали в изолированном контуре. Проприетарные шины, аналоговые датчики, отдельные пульты управления создавали массу неудобств для эксплуатации, но гарантированно защищали от сетевых атак хотя бы за счет отсутствия подключения к сети.
Запрос рынка на централизацию управления и удаленный мониторинг сделал свое дело. Производители OT-оборудования, такие как Schneider Electric, Siemens, Vertiv, пошли по пути конвергенции. Контроллеры получили стандартные ОС, Ethernet-порты и веб-интерфейсы. Этот переход проходил без органичного усвоения культуры информационной безопасности. Приоритетом оставалась отказоустойчивость – MTBF, резервирование каналов. Но на втором плане оказались управление уязвимостями, регулярное обновление прошивок, безопасная разработка. В результате инженерные системы получили весь набор уязвимостей корпоративных ИТ-систем, но сохранили детскую наивность промышленных протоколов, закладывавшихся в эпоху, когда о сетевых атаках никто не думал.
Как это работает?
Ключевая проблема – в свойствах протоколов управления инженерными системами: BACnet/IP и Modbus/TCP. Они создавались для замкнутых сред и не предусматривают аутентификации критических команд.
На конференции Black Hat USA в 2016 г. исследователи Кристофер Уэйд и Крис Уильямс продемонстрировали: любой узел в одном сегменте сети с BACnet-устройством может отправить контроллеру команду WriteProperty и изменить его параметры. Никакого взлома, только штатный функционал протокола.
Цепочка событий выглядит так. Фишинг открывает доступ в офисный сегмент. Дальше – движение в сторону слабо сегментированной сети инженерной инфраструктуры (BMS), к которой часто имеют доступ подрядчики. Сканирование, обнаружение BACnet-устройств, отправка команды на повышение порогового значения температуры в чиллере. Температура в зоне серверных стоек растет, срабатывает аварийная защита – стойка или модуль обесточиваются. Формально атака не оставляет следов: все действия выполнены легитимными командами из авторизованного сегмента.
Вспомним масштабный инцидент в Южной Корее в сентябре 2025 г., когда за несколько часов до проверки ЦОД на предмет хакерского взлома в машинном зале вспыхнул пожар, уничтоживший серверы местных госуслуг. Официальная причина – техническое возгорание, но хронология событий заставила экспертов говорить о неслучайности совпадения.
Почему не работает мониторинг?
Здесь возникает закономерный вопрос: почему SIEM и SOC не видят таких атак? По данным экспертов, специализирующихся на OT-безопасности, большинство инцидентов в конвергентных средах обнаруживаются не по данным мониторинга, а по физическим последствиям – задымлению, срабатыванию пожарной сигнализации или аварийному отключению оборудования.
Аналитики SOC обучены выявлять аномалии в HTTP, DNS, SQL-трафике. Но Modbus и BACnet для них – терра инкогнита. Этот трафик либо не попадает в периметр мониторинга, либо воспринимается как легитимный шум инженерных систем. Сигнатурные IPS не содержат правил на команды WriteProperty – формально это не эксплуатация уязвимости, а разрешенная операция.
Что можно сделать?
Проблема не решается простой установкой патча или закупкой очередного сканера. Но есть несколько рабочих направлений.
- Сегментация OT-сетей на уровне, исключающем бесконтрольный доступ из корпоративного сегмента к инженерным системам. Физическая или логическая изоляция сетей BMS/DCIM должна стать стандартом – таким же обязательным, как выделение DMZ.
- Инструментальное. Нужны решения класса NDR, которые понимают семантику промышленных протоколов. Мониторинг должен сместиться с учета пакетов на анализ содержания команд: изменение уставки температуры, переключение фаз питания, отключение вентиляторных групп – эти события должны вызывать реакцию SOC.
- Организационное. Модель взаимодействия команд ИБ и инженерной эксплуатации нуждается в пересборке. Кросс-функциональное обучение, совместные учения и единая система классификации событий – изменение параметра в BACnet-протоколе должно расцениваться как инцидент, потенциально ведущий к отказу оборудования.
Проблема киберфизической уязвимости ЦОД не решится сама собой. Инженерная инфраструктура – это уже не просто железо, она стала полноценным участником сетевого взаимодействия, и относиться к ней нужно соответственно. А пока мониторинг инженерных протоколов не стал рутиной, атаки на физическую инфраструктуру будут оставаться за пределами видимости.