Привет друг, kotu на связи, В прошлый раз я рассказывал об основах OT Security - Purdue Model, угрозы, регуляторика. Уж очень понравилась эта тема. Сегодня хотел бы поведать для тебя и углубится в то, как на самом деле общаются промышленные системы. Речь пойдёт о двух протоколах, которые ты встретишь на любом объекте АСУ ТП - Modbus и OPC UA. И поверь, их подходы к безопасности очень сильно отличаются.
Промышленные протоколы: зачем они нужны
Если коротко - промышленные протоколы это язык, на котором контроллеры, датчики, исполнительные механизмы и SCADA-системы разговаривают друг с другом. Без них завод не завод, а трубопровод просто труба. Они передают команды типа "открой клапан на 30 процентов", "датчик давления показывает 5 бар", "включи насос номер три" и.т.д.
Проблема в том, что большинство этих протоколов придумали в эпоху, когда слово "кибербезопасность" ещё не существовало. Инженеры думали о надёжности, скорости, совместимости - но не о конфиденциальности, целостности и доступности. И сегодня, в 2025 году, мы имеем то, что имеем - сети, где 70 процентов устройств используют либо открытые протоколы вроде Modbus, либо их более безопасные, но не всегда правильно сконфигурированные аналоги вроде OPC UA.
Атаки на Modbus: как это выглядит на практике
Первая и самая простая атака - пассивный сбор, то есть - sniffing. Подключился к сети, запустил Wireshark с фильтром tcp.port 502, и ты видишь всё. Какие Function Codes используются, какие адреса регистров читаются, какие значения передаются.
Вторая атака - command injection. Поняв структуру сети из sniffing-трафика, ты можешь отправить свой пакет с нужным Function Code. Например, код 5 для записи single coil, который управляет двигателем или клапаном. Или код 16 для записи multiple registers, чтобы изменить уставку давления или температуры. Главное знать unit ID и адрес, а их мы уже узнали из трафика.
Третья атака - Modbus flooding (лавинная рассылка Modbus). Отправляешь огромное количество запросов на устройство, оно не справляется с нагрузкой, перестаёт отвечать на легитимные запросы от реального master. Это простейший DoS, но в промышленной сети последствия могут быть серьёзными.
Modbus: учимся защищать то, что защитить невозможно
Первое правило - сегментация. Да, я уже писал про сегментацию, но лишь хочу напомнить что - Modbus не должен ходить через всю сеть. Его место - в Control Zone, на первом уровне Purdue Model. Если тебе нужно передавать данные наружу - используй DMZ, OPC UA, MQTT, что угодно, только не открывай Modbus наружу.
Второе - protocol-aware firewalls (межсетевые экраны с поддержкой протоколов). Обычный файрвол, который фильтрует по IP и port, бесполезен для Modbus. Нужен файрвол, который понимает протокол - Tofino от MTL Instruments, например, или специализированные промышленные файрволы. Они могут фильтровать не просто трафик на порт 502, а конкретные Function Codes, адреса, диапазоны регистров. Можно настроить правило - "разрешить только read-операции, запретить write", или "разрешить чтение только с этих адресов".
Третье - DPI и anomaly detection (обнаружение аномалий или выбросов). Специализированные системы вроде Claroty или Nozomi Networks анализируют Modbus-трафик, строят исходный уровень нормального поведения, и детектируют аномалии. Если обычно устройство отвечает за 50 миллисекунд, а сегодня отвечает за 5 секунд - это триггер. Если обычно используются только коды 1-4, а тут появился код 15 - это тревога.
Четвёртое - VPN для удалённого доступа. Если нужно дотянуться до Modbus-сети удалённо - только через VPN, и лучше с двухфакторной аутентификацией. Никаких открытых портов!
OPC UA: новое поколение, которое умеет в безопасность
OPC Unified Architecture появился в 2006 году как замена старому OPC DA. И главное отличие - его проектировали уже с учётом того, что сети бывают не только дружескими, но и враждебными. Поэтому безопасность встроена в сам протокол, а не прикручена сверху как заплатка.
Архитектура OPC UA гибкая. Есть классическая клиент-серверная модель, где клиент подключается к серверу, читает и пишет данные. А есть pub-sub модель, где издатель рассылает данные множеству подписчиков через брокер - удобно для IoT и облачных сценариев. Мы в основном видим клиент-сервер в старых системах, а pub-sub начинает появляться в новых.
Информационная модель OPC UA - тут вообще песня. В отличие от Modbus, где передаются просто адреса и значения, OPC UA передаёт семантику. Ты не просто читаешь "значение 42 по адресу 1", ты читаешь "температура реактора, измеряется в градусах Цельсия, диапазон 0-500, текущее значение 42". Это самоописываемая структура, которая позволяет системам понимать друг друга без дополнительной договорённости.
Security Model OPC UA: как оно устроено
OPC UA имеет три режима безопасности. None - никакой защиты, трафик в открытом виде. Sign - пакеты подписываются, но не шифруются, целостность обеспечена, но конфиденциальности нет. SignAndEncrypt - и подпись, и шифрование, полная защита.
Вот тут кроется первая ловушка. Многие системы настраивают Security Mode None для простоты. "А зачем нам шифрование, у нас внутренняя сеть?" - говорят инженеры. И получают открытый OPC UA, который по безопасности ненамного лучше Modbus. Я видел такие системы - с виду современный OPC UA, а по факту трафик в открытом виде, и Wireshark легко его читает.
Аутентификация в OPC UA работает через сертификаты X.509. Клиент и сервер обмениваются сертификатами, проверяют их валидность, доверие, срок действия. Это хорошо, но требует управления инфраструктурой сертификатов. И знаешь, что чаще всего ломается? Правильно - сертификаты протухают, и система перестаёт работать. Или админ, не разбирающийся в сертификатах, просто отключает проверку.
User authentication - тут есть несколько вариантов. Anonymous access - без аутентификации вообще, заходи кто хочет. Username/password – классика и Certificate-based - самый надёжный, но требует управления сертификатами.
Атаки на OPC UA: когда современный протокол работает в режиме "старого"
Первая и самая распространённая проблема - anonymous access. Сервер настроен принимать любого клиента без проверки. Подключился, прочитал, записал - никаких вопросов. Это как вход в подъезд без домофона - любой может зайти.
Вторая - Security Mode None. Администратор отключил шифрование и подписи для простоты, или потому что "у нас внутренняя сеть". Результат - весь трафик в открытом виде, и Wireshark с анализатором OPC UA показывает всё как на ладони.
Третья - манипуляции с сертификатами. Если сервер принимает любой сертификат без проверки CA, или если у злоумышленника есть доступ к хранилищу сертификатов, он может подделать свой и выдать себя за легитимного клиента. Или просто украсть приватный ключ легитимного клиента.
Четвёртая - неправильная конфигурация прав доступа. OPC UA поддерживает role-based access control. Клиент может не только читать, но и писать, и даже менять конфигурацию сервера.
Миграция с Modbus на OPC UA: мечта или реальность
Вот тебе вопрос - если OPC UA такой крутой и безопасный, почему Modbus до сих пор жив? Почему бы просто не перейти на OPC UA везде?
Ответ простой - деньги и риски. Миграция с Modbus на OPC UA требует замены или обновления контроллеров, SCADA-систем, переписывания интеграций, обучения персонала. На крупном заводе это миллионы долларов и месяцы работы. И главное, то о чем мы с тобой уже говорили - риск остановки производства во время перехода.
Поэтому в реальном мире мы видим гибридные схемы. Modbus остаётся на нижнем уровне, внутри Control Zone, где он работал десятилетиями. А OPC UA используется как мост - шлюз, который читает Modbus с одной стороны и отдаёт данные по OPC UA с другой, уже с шифрованием и аутентификацией. Так DMZ и корпоративная сеть получают безопасный доступ к данным, не трогая legacy на нижних уровнях.
Что делать с этим всем
Если ты встретишь Modbus на объекте - не пытайся его "защитить на уровне протокола". Это бесполезно, протокол не предназначен для этого. Защищай на уровне сети - сегментация, файрволы, VPN, мониторинг.
Если ты встретишь OPC UA - проверь конфигурацию. Security Mode None с anonymous access это не OPC UA, это Modbus в красивой обёртке. Требуй SignAndEncrypt, certificate-based auth, role-based access control. Но будь готов к тому, что это сломает связь с какими-то старыми клиентами, и тебе придётся разбираться с сертификатами.
И помни главное правило OT Security - доступность превыше всего. Любое изменение конфигурации протокола может повлиять на работу производства. Тестируй на отдельном стенде, планируй на окно обслуживания, согласовывай с вендором и инженерами АСУ ТП.
Ведь никому не нужен самый защищённый протокол, если производство стоит. Правда?)
Последнее редактирование:
