<WRAP doku>

====== Ключевые уязвимости и угрозы для ЦОД ======
<WRAP box round>
Раздел описывает ключевые уязвимости в промышленных протоколах управления (SNMP, Modbus/TCP, BACnet), которые лежат в основе взаимодействия IT- и OT-систем. Исторически эти протоколы разрабатывались без учёта современных требований кибербезопасности и потому представляют риск несанкционированного доступа, манипуляции уставками и повреждения оборудования.
</WRAP>

===== Общие предпосылки уязвимостей =====
<WRAP info>
Большинство коммуникационных протоколов для IT и OT были разработаны в конце XX века, когда угрозы кибератак на инфраструктуру не рассматривались как значимые. Основное внимание уделялось совместимости оборудования и простоте интеграции, а не защите данных.
</WRAP>

Ключевые причины уязвимостей:
  * Отсутствие аутентификации и шифрования по умолчанию.
  * Использование открытых текстовых сообщений (plain text).
  * Сохранение устаревших реализаций для обратной совместимости.
  * Сложность внедрения обновлённых версий в существующие ЦОД.
  * Недостаток изоляции и сегментации сетей управления.

===== SNMP =====
<WRAP info>
SNMP (Simple Network Management Protocol) — основной протокол мониторинга и управления оборудованием ЦОД. Поддерживается практически всеми IT- и OT-устройствами (UPS, PDU, кондиционеры, свитчи).
</WRAP>

Эволюция SNMP:
  * **v1 (1988)** — без шифрования, идентификатор доступа (community string) передаётся открытым текстом.
  * **v2 (1993)** — добавлены функции bulk-опроса, но безопасность осталась прежней.
  * **v3 (1999)** — введены аутентификация и шифрование, однако реализация оказалась слабой для современных стандартов.

<WRAP important>
Исследование Georgia Tech (Dr. Patrick Traynor, 2012) показало, что SNMPv3 не обеспечивает заявленных гарантий безопасности: реализация допускает эксплуатацию уязвимостей независимо от платформы.  
**Вывод:** даже при SNMPv3 устройства остаются уязвимыми к перехвату, подмене данных и несанкционированному управлению.
</WRAP>

Типичные последствия атак на SNMP:
  * отключение портов и свитчей (DoS);
  * изменение уставок температур и порогов тревог;
  * выключение ИБП и распределителей питания;
  * нарушение синхронизации данных мониторинга.

===== Modbus/TCP =====
<WRAP info>
Modbus/TCP — один из старейших промышленных протоколов, разработан в 1978 году. Использует открытый текст без шифрования, что делает его уязвимым для атак типа *man-in-the-middle*.
</WRAP>

<WRAP center>
**Пример из практики (Wireshark):** пакет запроса Modbus "Read multiple registers" полностью виден в открытом виде.  
Любой пользователь сети может прочитать или изменить значения регистров (уставки, токи, температуры).
</WRAP>

<WRAP important>
Modbus не имеет встроенных средств аутентификации и защиты целостности.  
Любой, кто имеет доступ к сети управления, может:
  * изменить управляющие регистры (вкл/выкл насосы, выключатели);
  * изменить пороги аварий и токовые уставки;
  * вызвать физическое повреждение оборудования.
</WRAP>

Ключевая угроза: простота эксплуатации — не требуется высокая квалификация злоумышленника.

===== BACnet =====
<WRAP info>
BACnet (Building Automation and Control Network) — стандарт ASHRAE, используется в системах вентиляции и кондиционирования (HVAC). Разработан в 1990-х, стандартизован в 1995 году.  
Протокол универсален, но почти всегда развёртывается **без шифрования** и **без аутентификации**.
</WRAP>

<WRAP important>
BACnet Network Security (Clause 24) основан на слабом 56-битном DES и **является опциональным**, поэтому редко включается в реальных системах.  
Даже при его использовании защита не отвечает современным требованиям.
</WRAP>

Последствия атак на BACnet:
  * изменение уставок температуры и давления;
  * управление заслонками и вентиляцией;
  * нарушение работы кондиционирования серверных зон;
  * физический ущерб от перегрева оборудования.

===== Примеры атак и последствий =====

^ Устройство ^ Возможность злоумышленника ^ Последствия ^
| HVAC | Скрыть ошибки, изменить температуру/влажность, перезапустить цикл | Физическое повреждение оборудования |
| Управляемый коммутатор | Изменить авторизацию, выключить/включить порты | Потеря сетевого доступа (DoS) |
| PDU | Изменить пороги тока/напряжения | Физическое повреждение |
| Датчики движения | Отключить или скрыть срабатывания | Незаметный физический доступ |
| UPS | Изменить параметры зарядки/пороги | Повреждение аккумуляторов или ИБП |

===== Итоговая оценка рисков =====
<WRAP info>
Все три протокола — SNMP, Modbus/TCP и BACnet — разрабатывались в эпоху, когда физическая безопасность считалась достаточной.  
В современных ЦОД, где инженерные сети связаны с IT-инфраструктурой, эти протоколы стали точкой входа для атак.
</WRAP>

<WRAP important>
Основная уязвимость — **отсутствие встроенных механизмов защиты и обновлений**.  
Даже при корректной настройке «в лоб» доступен полный контроль над устройствами.
</WRAP>

===== Ключевые направления защиты =====
  * Полный отказ от SNMP v1/v2c, переход на SNMPv3 с authPriv.
  * Использование шлюзов с TLS для Modbus и BACnet.
  * VLAN/VRF-сегментация OT-сетей, фильтрация портов (161, 502, 47808).
  * Мониторинг сетевой активности (анализ аномалий).
  * Логирование всех действий операторов (syslog, OT-SIEM).
  * Контроль физического доступа и аудит подключений подрядчиков.
  * Резервирование каналов связи и автоматическое ограничение уставок.

===== Сводная диаграмма уязвимостей =====
<mermaid>
flowchart TB
  classDef big font-size:14px,stroke-width:1.2px,padding:10px;
  A["Открытые протоколы SNMP/Modbus/BACnet"]:::big --> B["Нет шифрования / plain text"]:::big
  B --> C["Перехват и подмена пакетов"]:::big
  A --> D["Нет аутентификации пользователей"]:::big
  D --> E["Удалённое управление устройствами"]:::big
  E --> F["Физический ущерб / отказ сервисов"]:::big
  C --> F
</mermaid>

===== Ключевые идеи =====
<WRAP tip>
  * Исторически SNMP, Modbus и BACnet не проектировались с учётом киберугроз.  
  * Даже современные версии (SNMPv3, BACnet Clause 24) имеют слабую защиту.  
  * Любой доступ в сеть управления = потенциальный полный контроль над инженеркой.  
  * Требуется сегментация, шлюзы с TLS, ограничение write-доступа и централизованный мониторинг.  
  * Безопасность OT должна рассматриваться как часть общей стратегии ИБ ЦОД, а не как вспомогательная функция.  
  * В российской практике эти протоколы относятся к защищаемым сегментам КИИ и требуют реализации мер по ФСТЭК.
</WRAP>

</WRAP>