1771138592617.webp


Ребята, давайте честно. SIS - это такой же программируемый логический контроллер (ПЛК). Часто - тот же Siemens, тот же ABB, тот же Honeywell, только воткнутый в другую стойку и прошитый под соусом «безопасности». Да, там есть дублирование, есть диагностика, есть специальные протоколы. Но это не магический артефакт. Это железка с прошивкой. А значит, у нее есть баги, у нее есть интерфейсы, и к ней, сука, есть доступ.

Я не призываю вас сейчас бежать и отключать защиту на АЭС или на химическом комбинате (хотя, если ты это читаешь и работаешь на АЭС - напиши мне в личку, есть разговор). Я призываю посмотреть на это трезво. Мы не хотим, чтобы взорвалось, но мы обязаны знать, как можно сделать так, чтобы оно взорвалось - чтобы это предотвратить.

В этой статье мы разберем SIS от железа до софта, от физики до логики. Я покажу те инструменты, которыми можно пощупать эту систему на прочность (в лабораторных условиях, естественно! А то знаю я вас...). Мы пройдемся по векторам атак, по типовым ошибкам проектировщиков и по «человеческому фактору», который закопан глубоко в прошивке.

Дисклеймер: Вся информация ниже предназначена исключительно для специалистов по промышленной безопасности, пентестеров АСУ ТП и студентов, чтобы они понимали, с чем имеют дело. Если ты, прочитав это, решишь пойти подрывать завод - ты долбоеб, и проблемы у тебя будут исключительно твои. Мы тут за безопасность, а не за фейерверки.

Что есть SIS на самом деле? Разрушаем мифы.​

Так, народ. В предыдущем посте я пробежался по верхам, но чувствую - надо копать глубже. Потому что тема SIS - это такая кроличья нора, где на каждом уровне тебя ждет либо просветление, либо жесткий фейспалм от того, как это все реализовано на реальных объектах.

Давайте теперь разбирать первый уровень - аппаратуру и архитектуру - с микроскопом в руках и с паяльником наготове. Потому что без понимания того, из чего эти системы сделаны и как они связаны с остальным миром, любая дискуссия о безопасности - это просто сотрясание воздуха.


1.1. Аппаратная часть: Железо, которое выдает себя за неприкасаемое​

Давай сразу договоримся: SIS - это не какой-то там засекреченный военный компьютер в титановом корпусе, который питается от веры в безопасность. Это вполне себе серийная промышленная электроника. Часто - та же самая, что стоит в соседней стойке и управляет обычным технологическим процессом. Просто с двойным процессором, сертификатом и, самое главное, с другой логикой работы.

1.1.1. Архитектура процессорных модулей: 1oo2, 1oo2D, TMR и прочая математика

Если ты когда-нибудь открывал документацию на safety-контроллер, ты натыкался на эти загадочные аббревиатуры. Давай расшифруем их на пальцах, без маркетингового буллшита.

1oo2 (One out of Two) - классическая схема для систем, где нужно, чтобы система не отказывала без необходимости (высокая доступность), но при этом была защита от поломок. Суть: стоят два одинаковых процессора (канала), которые делают одно и то же. Сравнивают результаты на каждом такте. Если результаты совпадают - выполняют команду. Если не совпадают - стоп, ошибка, система переходит в безопасное состояние. Это защита от сбоя одного канала. Но есть нюанс: если один канал сдох, система не может отличить, кто врет - живой или мертвый. Поэтому она просто падает.

1oo2D (One out of Two with Diagnostics) - эволюция. Тут к двум каналам добавили мощную самодиагностику. Каждый канал проверяет сам себя (тесты памяти, тесты тактового генератора и т.д.). Если один канал говорит "я сломался", второй берет управление на себя, и система продолжает работать. Это уже ближе к реальности. Такая схема используется в Siemens S7-400F/FH и в ABB 800xA High Integrity.

TMR (Triple Modular Redundancy) - это уже для совсем упоротых, например, для Triconex (ныне Schneider Electric) или для авионики. Три канала, голосование 2 из 3. Если один канал сошел с ума, два других его переголосуют. Самый надежный, но и самый дорогой способ. На заводах средней руки такое редкость, разве что на особо опасных объектах типа FCC (Fluid Catalytic Cracking) установок или на атомных станциях.

Вывод для хакера: Вся эта математика защищает от случайных отказов железа. От целенаправленной атаки на софт она не защищает вообще. Если мы сможем подменить данные в памяти обоих каналов (а они синхронизируются), то оба канала будут согласно врать. TMR тут поможет чуть лучше, но если атака идет на общую шину данных или на источник питания - все каналы лягут одновременно.

1.1.2. Модули ввода-вывода (I/O): Там, где цифра встречается с аналогом

Вот тут, братцы, самое интересное. Процессор - это мозг. А руки и глаза - это модули ввода-вывода. Они стоят либо в той же стойке, либо вынесены прямо к объекту (удаленная периферия).

Что мы видим в типовом шкафу SIS?
  • Аналоговые входные модули (AI). На них приходят сигналы 4-20 мА от датчиков давления, температуры, расхода. В safety-исполнении эти модули умеют делать крутые вещи: они постоянно мониторят ток, проверяют его на обрыв (сигнал < 2 мА) и на короткое замыкание (сигнал > 22 мА). Они могут даже подавать тестовые импульсы, чтобы убедиться, что линия цела.
  • Дискретные входные модули (DI). Сюда приходят сигналы от кнопок аварийного останова, от концевых выключателей задвижек, от реле давления. Тут тоже фишки: питание на контакты подается импульсное, чтобы можно было отличить короткое замыкание от реального замыкания контакта.
  • Выходные модули (DO/AO). Это самое ответственное звено. Они выдают команды на исполнительные механизмы: открыть/закрыть клапан, включить насос, дать искру на запальник. В safety-системах выходные модули часто имеют так называемую "темную" архитектуру. То есть они находятся под напряжением только в момент выдачи команды. В спокойном состоянии они обесточены. Это сделано для того, чтобы при обрыве провода или поломке транзистора система не выдала ложную команду.
Практический инструмент №1 (расширенная версия): Wireshark и анализ протоколов полевого уровня.

Мы уже говорили про зеркалирование портов. Теперь идем дальше. Если ты подключился к сети и увидел PROFINET, EtherNet/IP или Modbus TCP, это еще не все. Тебе нужно понять, какие данные передаются между процессором и удаленной периферией.
  1. Захват трафика на линии CPU - Remote I/O. В managed-коммутаторах обычно есть возможность зеркалировать не только порт, но и VLAN. Найди VLAN, в котором общается SIS.
  2. Фильтрация. PROFINET использует протокол PNIO (PROFINET IO). В Wireshark есть отличные фильтры: pnio, profisafe, profinet. Включай их.
  3. Анализ циклических данных. Ты увидишь, что каждые несколько миллисекунд (цикл PROFINET IO обычно 4-32 мс) идет обмен пакетами фиксированной длины. Это циклические данные (cyclic data). В них упакованы все входы и выходы. Разбери этот пакет. Смотри, какие байты меняются, когда ты дергаешь за датчик. Сравни с документацией.
  4. Атака на циклические данные (теоретическая).Если у тебя есть доступ в сеть (а ты нашел Wi-Fi-точку у шкафа или залез в оптический кросс), ты можешь попробовать атаку типа "человек посередине" (MITM). Инструмент - ettercap или написанный на Python скрипт с использованием библиотек scapy и socket.
    • Суть: ты становишься между CPU и I/O-устройством.
    • Ты принимаешь пакет от CPU к I/O.
    • Меняешь в нем байты, отвечающие за выходные команды.
    • Пересчитываешь контрольную сумму (если она есть в протоколе - в PROFINET IO ее нет на этом уровне, она есть в PROFIsafe выше).
    • Отправляешь измененный пакет на I/O.
    • Результат: I/O-модуль выполнит твою команду, а CPU будет думать, что он послал свою.
Конечно, PROFIsafe добавит сюда сложности с F-CRC (Fail-safe Cyclic Redundancy Check), но базовый PROFINET IO - открытая книга. И если SIS использует обычные модули ввода-вывода (не F-модули) для каких-то небезопасных сигналов, ты можешь их дрыгать как хочешь.


1.2. Архитектурные решения: Миф о "независимости"​

Самая любимая мантра проектировщиков и экспертов по безопасности: "SIS полностью независима от DCS". Звучит красиво. Но на практике это означает лишь то, что у них могут быть отдельные датчики и отдельные исполнительные механизмы. Все остальное - вопрос реализации и бюджета.

1.2.1. Полная независимость: Дорого и редко

Представь себе идеал:
  1. Свои датчики на технологическом аппарате.
  2. Свои кабельные трассы (идут в обход кабеленесущих систем DCS).
  3. Свой контроллер в отдельной стойке.
  4. Своя операторская станция (или как минимум отдельный монитор).
  5. Своя сеть, физически отделенная от всех остальных.
  6. Свой источник питания (отдельный UPS, а лучше - от другого фидера).
Это стоит как крыло самолета. Поэтому такое встретишь либо на новых заводах, построенных по западным стандартам после крупных аварий, либо на объектах, где деньги не считают (нефтепереработка, атомная энергетика). В 90% случаев - компромисс.

1.2.2. Функциональная независимость в одной стойке

Самый распространенный вариант: SIS и DCS стоят в соседних стойках в одной серверной или в одном шкафу управления. Они питаются от одного UPS (ну ладно, от двух разных, но от одного вводного щита). Их сети сходятся в одном коммутаторе (пусть и в разных VLAN). Их инженерные станции - это один и тот же компьютер, просто запущенный с разными правами.

Что это означает для нас?
  • Общая инфраструктура электропитания. Если хакерская атака направлена на UPS (а современные UPS управляются по сети, да-да, у них есть SNMP-карты), можно вырубить питание и на DCS, и на SIS одновременно. Безопасное состояние? Система упадет в защиту? Не всегда. Если пропадет питание, клапаны с пневмоприводом останутся в том положении, в котором были (если нет пружинного возврата). Это может быть опасно.
  • Общая инженерная станция. Классика. Инженер АСУ ТП сидит за одним компом. У него открыт проект DCS и проект SIS. Он ковыряется в DCS, а потом, не закрывая сессию, лезет в SIS что-то посмотреть. Если на этом компе вирус (а на инженерных станциях антивирусы часто отключают "чтобы не тормозило"), он имеет доступ к проектам обоих систем. Может слить логику, может модифицировать.
  • Общая сеть уровня L2/L3. Даже если SIS в отдельном VLAN, трафик идет через одни и те же железки. Если злоумышленник смог скомпрометировать core-коммутатор (а они часто на базе Linux или Cisco IOS с известными уязвимостями), он может попасть в любой VLAN.
Практический инструмент №2 (расширенный): Nmap и сканирование промышленных протоколов.

Ладно, допустим, тебе дали доступ к сегменту сети. Как понять, где DCS, а где SIS?
  1. Сканирование хостов: nmap -sP 192.168.1.0/24 - найдешь живые устройства.
  2. Определение ОС: nmap -O ip - PLC-шки часто определяются как "Siemens SIMATIC" или "Schneider Electric Modicon". Это зацепка.
  3. Сканирование портов: nmap -sU -p 161 ip - ищешь SNMP (UDP 161). На PLC часто включен SNMP для мониторинга. По SNMP можно вытащить кучу инфы: имя устройства, описание, серийный номер, версию прошивки. Комьюнити (community string) часто "public". Да-да, в 2026 году это все еще работает.
  4. Специализированные сканеры:Используй nmap с скриптами для промышленных протоколов.
    • nmap -sV -p 102 --script s7-info ip - для Siemens S7 (порт 102 TCP). Скрипт покажет тип модуля, версию, имя станции.
    • nmap -sV -p 502 --script modbus-discover ip - для Modbus (порт 502 TCP). Скрипт попытается прочитать идентификатор устройства и регистры.
    • Для PROFINET используй nmap -p 34964,34962-34964 ip или специализированные утилиты типа profinet-utils.
Что мы ищем? Мы ищем устройства с именами, содержащими "SIS", "ESD", "Safety", "F-", "Tricon", "Quadlog". Это наши цели. Запоминаем их IP и MAC.


1.3. "Независимость" датчиков и исполнительных механизмов: А если все-таки общее?​

Бывает архитектура, где датчики общие. Это называется "black channel" для данных. Один датчик давления стоит на трубе. Его сигнал (4-20 мА) идет параллельно: на вход DCS (для регулирования) и на вход SIS (для защиты). Это удешевляет проект.

Технически это реализуется через пассивный разветвитель сигнала (часто - просто гальваническая развязка или повторитель). С точки зрения физики, один датчик питает две системы.

В чем проблема?
Если датчик врет (вышел из строя, засорился импульсный трубопровод, обрыв), он обманет обе системы сразу. DCS будет показывать неверное давление, и SIS будет видеть то же самое. Это называется "отказ по общей причине" (common cause failure). Для борьбы с этим применяют архитектуру "2oo3" (два из трех), где ставят три датчика и голосуют. Но это опять деньги.

Практический инструмент №3: Мультиметр, токовые клещи и осциллограф.

Если ты физически добрался до датчика:
  1. Измерение токовой петли. Подключи мультиметр последовательно в цепь. Посмотри реальный ток.
  2. Анализ формы сигнала осциллографом. На некоторых умных датчиках (HART-протокол) поверх тока 4-20 мА модулируется цифровой сигнал частотой ~1 кГц. Осциллографом можно увидеть эту модуляцию. Можно попробовать записать и расшифровать HART-команды, если они используются для настройки или диагностики датчика (а они используются).
  3. Физическое воздействие. Никто не отменял "тупые" методы: пережать импульсную трубку перед датчиком. Давление на датчике упадет, SIS увидит "давление упало". Или наоборот, слегка подогреть датчик температуры зажигалкой (осторожно!). SIS увидит рост температуры. Если это датчик, работающий на защиту, можно инициировать аварию.

1.4. Время: Четвертое измерение SIS​

В SIS критически важна скорость реакции. Обычный DCS может обновлять данные раз в секунду, и это норм. Для регулирования температуры в колонне это ок. Аварийная защита должна сработать за миллисекунды. Если давление растет со скоростью 100 бар в секунду, промедление в 200 мс - это взрыв.

Поэтому в SIS используются:
  • Детерминированные сети. PROFINET IRT (Isochronous Real-Time) или EtherCAT гарантируют доставку пакета за строго определенное время. Никаких "подожди, пока освободится шина".
  • Аппаратные таймеры. В логике SIS практически не используют программные задержки (типа "подожди 5 секунд" в коде). Используют аппаратные watchdog-таймеры.
  • Short scan time. Цикл сканирования программы в SIS обычно 10-50 мс. В DCS - 100-500 мс.
Как это влияет на безопасность?
Атака, направленная на задержку трафика (network latency injection), может быть фатальна для SIS. Если мы добавим 100 мс задержки в сеть PROFINET IRT, контроллер не получит данные от удаленной периферии вовремя. Он посчитает, что связь потеряна, и уйдет в безопасное состояние. Завод встал. DDoS на время.

Практический инструмент №4: tc (traffic control) на Linux.

Если у тебя есть Linux-машина, включенная в разрыв сети (bridge), ты можешь использовать утилиту tc для управления трафиком.
  • tc qdisc add dev eth0 root netem delay 100ms - добавит задержку в 100 миллисекунд на все пакеты, идущие через интерфейс eth0.
  • Поставь такую машинку между коммутатором уровня SIS и контроллером (физически или через тот же Port Mirroring с возможностью инжекта, если коммутатор поддерживает).
  • Наблюдай, как SIS начнет орать "потеря связи с устройством" и дергать защиту.
Это чистейшая демонстрация того, как уязвимость сетевого уровня убивает физическую безопасность.
  1. SIS - это не магия. Это компьютер с железом, на котором работает софт. Он такой же уязвимый, как и любой другой компьютер, просто с другим софтом и другими последствиями отказа.
  2. Физический уровень - самый честный. Если есть доступ к проводам, можно делать что угодно: подавать ток, ставить перемычки, резать кабель. Никакой firewall не защитит от перемычки на клеммах.
  3. Сеть - зона риска. Сетевые протоколы SIS (PROFINET, EtherNet/IP, Modbus TCP) не предназначены для защиты от умного злоумышленника. Они предназначены для скорости и надежности при случайных сбоях. Задержки и MITM - реальны.
  4. Независимость часто фиктивна. Общее питание, общие инженерные станции, общие коммутаторы - это точки отказа, через которые можно добраться до "святая святых".
  5. Время - деньги. Для SIS время - это жизнь. Атаки на тайминги (timing attacks) могут вывести систему из строя без изменения единого бита данных.

Датчики, искры и «грязное» поле

С сетями разобрались. Идем дальше вниз, на уровень так называемого «поля» (field level). Это датчики давления, температуры, расхода, задвижки с конечниками.

Нам рассказывают про надежность датчиков, про их самодиагностику и защиту от дурака. А в реальности - это аналоговый мир, и он полон сюрпризов.

2.1. Аналоговый вход 4-20 мА: Классика жанра

Большинство датчиков для SIS (и DCS) до сих пор работают по токовой петле 4-20 мА. Почему? Потому что это надежно, просто и позволяет передавать сигнал на километры. 4 мА - это всегда живой ноль (обрыв провода даст 0 мА, что сразу диагностируется как ошибка).

Но давайте посмотрим на это глазами человека, который хочет проверить систему. Токовая петля - это аналоговый сигнал. Его можно исказить, если добраться до проводов.

Практический инструмент №2: Аналоговый инжектор сигнала (Fluke 705 или китайский клон).

Представь: ты на объекте. Ты нашел шкаф управления, где стоят клеммные ряды. На одной клемме висит датчик давления с маркировкой PIT-101 (Pressure Indicating Transmitter), который идет в SIS.

Если у тесть доступ к этим клеммам, ты можешь:
  1. Отключить датчик.
  2. Подключить вместо него свой токовый генератор.
  3. Начинать подавать сигнал.
Подал 4 мА (0 бар) - все тихо. Подал 8 мА (условно 5 бар) - тихо. Подал 20 мА (16 бар) - тихо.
А теперь представь, что уставка срабатывания защиты - 15 бар. Подаешь 20.5 мА (16.5 бар) - и вуаля! Система защиты думает, что давление выросло выше крыши. Если в логике SIS прописано «при превышении P > 15 бар открыть сбросной клапан и перекрыть подачу», то ты сейчас инициировал аварию, просто подав ток на клеммы.

Конечно, умные люди ставят искробезопасные барьеры, гальваническую развязку. Но физику не обмануть: если ты имеешь физический контакт с проводом - ты имеешь контроль над сигналом.

2.2. Дискретные входы: Сухой контакт или есть потенциал?

Задвижки, концевики, кнопки аварийного останова - это обычно «сухой контакт». Замкнуто/разомкнуто.
В безопасных системах часто используется принцип «fail-safe»: нормально замкнутый контакт. То есть когда давление в норме, контакт замкнут, ток течет. Как только давление превысило уставку - контакт размыкается, ток пропадает, и система валится в аварию. Это защита от обрыва провода.

Как это взломать?
  • Механически: Зафиксировать концевик изолентой или спичкой, чтобы он не размыкался.
  • Электрически: Зашунтировать контакты. Подошел к клеммнику, поставил перемычку поверх проводов - и вуаля, хоть там реактор взорвись, SIS будет видеть «контакт замкнут» и думать, что всё ок.
Практический инструмент №3: Мультиметр с функцией прозвонки и пара крокодилов.

Самый хардкорный инструмент. Залез в шкаф, нашел клеммы нужного клапана или датчика. Прозвонил цепь. Убедился, что это «сухой контакт». Если он в нормальном состоянии замкнут, ставишь свою перемычку параллельно. Система перестанет видеть размыкание этого контакта, даже если оно произойдет физически. Опасность? Еще какая. Эффективность? 100%.

Это называется «атака на физическом уровне». И никакой киберзащитой тут не отобьешься, если злоумышленник имеет доступ в шкаф управления.

Логика SIL и магия сертификатов

Теперь переходим к самому интересному - к софту. Точнее, к логике, которая зашита в этот самый safety-контроллер.

Тут мейнстрим любит рассказывать про сертификаты SIL (Safety Integrity Level). SIL 1, SIL 2, SIL 3. Чем выше уровень, тем меньше вероятность отказа при выполнении функции безопасности.

Звучит как мантра. На деле, SIL - это про вероятности, про математику. Это не про "не взломаешь". Это про то, что железо само по себе сдохнет с вероятностью 1 раз в 1000 лет (для SIL 3, PFDavg от 10^-4 до 10^-3).

Но никто не считает вероятность того, что программист-технолог нарежет в этой логике такого... что мама не горюй.

3.1. Человеческий фактор в FBD/LD

SIS программируется на специальных языках - обычно это FBD (Function Block Diagram) или LD (Ladder Diagram). Это не C++ и не Python, это графические языки для инженеров-технологов.

И вот тут начинается треш. Как выглядит идеальная логика безопасности?

Код:
IF (Pressure > High_High) THEN
    Close_Inlet_Valve();
    Open_Vent_Valve();
END_IF;

Все четко.

А как выглядит реальная логика, которую я видел своими глазами на одном заводе?
Там была конструкция из 15 таймеров, каких-то RS-триггеров, перекрестных связей и ручных кнопок-«заглушек», которые позволяли технологу "временной отключить защиту", если датчик "врет", чтобы "план горел".

И вот это - золотая жила для атакующего. Не надо ломать криптостойкие протоколы. Надо просто найти этот "костыль". На инженерной станции открыть проект, найти эту логику и понять, как дернуть за нужную ниточку.

Практический инструмент №4: Инженерное ПО (TIA Portal, Control Builder, CBF).

Если ты на пентесте и тебе дали доступ к инженерной станции (часто на ней нет антивируса и стоит старый Windows 7) - это джекпот.
  1. Запускаешь Siemens TIA Portal (или что там у них).
  2. Открываешь проект (а пароль от проекта часто висит на стикере на мониторе, потому что "забывают").
  3. Ищешь блоки безопасности (обычно они или в отдельной папке, или помечены специальным значком).
  4. Анализируешь логику. Ищешь, нет ли возможности повлиять на входные данные через HMI/SCADA.
В 90% случаев ты найдешь хотя бы один флаг "Manual Override", который выведен на операторскую. А если этот флаг можно выставить удаленно - все, считай, защита отключена.

И вот тут мы подходим к главной иронии. Система безопасности, напичканная сертифицированным Siemens F-железом, с софтом, разработанным по всем методикам V-model, может быть отключена одним битом в Modbus-регистре, пришедшим из корпоративной сети через шлюз OPC.

Сети и протоколы безопасности: PROFIsafe и другие сказки

Теперь про сетевые технологии. Когда модные вендоры начали пихать полевые шины везде, встал вопрос: как передавать данные безопасности по той же сети, что и обычные данные? Чтобы SIS-контроллер мог пожать руку удаленной SIS-периферии (блоки ввода-вывода, установленные прямо у реактора) по той же витой паре, что и обычный I/O.

Придумали "черный канал". Это когда безопасный протокол (например, PROFIsafe) заворачивается в обычный (PROFINET). Идея в том, что безопасный уровень добавляет свои контрольные суммы, таймауты и сквозное подтверждение. Даже если пакет исказится в "черном канале", безопасный уровень на приемнике это заметит и переведет выходы в безопасное состояние.

Звучит надежно? Да, с точки зрения случайных ошибок - да. С точки зрения целенаправленной атаки? Есть нюансы.

4.1. Атака на время

PROFIsafe (и его аналоги) использует так называемое "кросс-сообщение" и следит за временем доставки. Если пакет идет дольше, чем заданный watchdog timer - система падает в safety (отключается). То есть, если мы начнем задерживать трафик (атака типа "store and forward"), мы можем вызвать ложное срабатывание защиты. Не отключить ее, а именно вызвать аварию. Завод встал. Молодцы.

Практический инструмент №5: Ethernet-адаптер с поддержкой режима "monitor" и Scapy.

Scapy - это мощнейший инструмент для работы с пакетами в Python. Ты можешь написать скрипт, который будет:
  1. Слушать PROFINET-трафик.
  2. Выделять пакеты PROFIsafe.
  3. Немного изменять в них время (или просто задерживать их пересылку на несколько миллисекунд).
  4. Пересылать их дальше.
Если тебе удастся сломать тайминг, удаленный блок I/O подумает, что связь с контроллером потеряна, и переведет все свои выходы (те самые задвижки и клапаны) в безопасное состояние (обычно закрыто/открыто в зависимости от логики). Или наоборот, если мы сможем подменить пакет так, что контрольная сумма сойдется, а данные будут изменены... Но там криптография? Нет, там не криптография, там CRC с ключом. И если ты не знаешь ключ, подделать сложно. Но задержать - легко.

1771138621424.webp


HMI и оператор: последний рубеж или первая линия фронта?

Мы спустились с небес на землю, прошлись по железу, софту и сетям. Кто же стоит на страже всего этого безобразия? Оператор. Бедный Вася, который смотрит на 20 мониторов 12 часов подряд, пьет кофе и мечтает о выходных.

На HMI (Human-Machine Interface) оператора выводятся и сигналы от DCS, и сигналы от SIS. И тут вендоры любят рисовать красивые лампочки: зеленые - всё хорошо, желтые - предупреждение, красные - авария.

Но как часто оператор проверяет, валидны ли эти сигналы? Он доверяет системе. А мы знаем, что доверие - главный враг безопасности.

5.1. Фейковые сообщения

Если у нас есть возможность внедриться в SCADA-систему (а она часто на базе Windows и с кучей дырок), мы можем подменить сообщения для оператора.
  • Вместо "Давление в норме" показать "КРИТИЧЕСКОЕ ДАВЛЕНИЕ! АВАРИЯ!"
  • Оператор в панике нажимает кнопку ручного останова.
  • Завод встал.
Или наоборот, скрыть реальную аварию. Защита сработала, клапан открылся, но на экране у оператора всё зелено. Он думает, что процесс идет, а на самом деле продукт улетает в факел. Вовремя не среагирует - последствия могут быть серьезными.

Практический инструмент №6: Инструменты для реверс-инжиниринга SCADA-проектов.

Разные SCADA (Wonderware, Citect, WinCC) хранят свои проекты в файлах определенного формата. Часто они не шифруются как следует, или используют простой XOR. Утилиты типа WinCC Explorer (для старых версий) или специализированные скрипты позволяют вытащить все теги и понять, откуда берутся данные для отображения. Если мы сможем подменить DDE/OPC сервер, с которого SCADA тянет данные, или просто найти точку внедрения в рантайм-память - мы сможем рисовать оператору любую картинку.

Эпилог: Как защищаться, если ты на нашей стороне?

Мы тут нафорсили тему, рассказали, как всё плохо. Теперь давай по-честному: что с этим делать? Как защитить SIS, если ты не злобный хакер, а инженер или безопасник, который реально хочет, чтобы завод работал и не взрывался?

1. Физическая изоляция (Air Gap? Ха-ха).
Забудьте про "воздушный зазор". Его нет. Сеть SIS так или иначе связана с корпоративной для сбора архивов и отчетов. Значит, нужен Data Diode. Это железка, которая позволяет данным идти только в одну сторону. Из SIS-сети в корпоративную можно, обратно - нельзя. Никаких команд. Только read-only.

2. Сетевая сегментация по-взрослому.
SIS-сеть должна жить в своем VLAN'е, с отдельными firewall'ами, которые режут всё, кроме строго необходимого. И никаких «а давайте мы тут порт откроем для тест-инженера, ему по RDP зайти надо». RDP в промышленной сети - это моветон. Используйте jump-серверы с двухфакторной аутентификацией и полным логированием.

3. Мониторинг целостности.
Нужно следить, не изменился ли проект в контроллере. Современные системы (Siemens с его Certified Boot) позволяют проверять контрольные суммы прошивок. Если кто-то залил измененную логику - система должна орать благим матом.

4. Обучение (не тошнотворное, а реальное).
Расскажите операторам и технологим, как работают атаки. Проведите учения. Пусть Вася поймет, что если ему на почту пришло письмо "Скачай обновление для CODESYS" - он долбоеб, если скачает. Человек - самое слабое звено. Но он может стать самым сильным, если его научить не доверять слепо и сообщать о странностях.

5. Аудит физического доступа.
Шкафы управления должны закрываться не на "собачку", а на нормальные замки, и доступ туда должен быть по спискам. Каждый, кто открыл шкаф, должен оставить запись в журнале. Потому что перемычка на клеммах - это самый быстрый способ похоронить защиту.

Заключение.​

Так, народ. Мы с вами пропахали огромный пласт. От транзисторов в модулях ввода-вывода до высокоуровневых протоколов типа PROFIsafe. Мы залезали в шкафы с мультиметром, слушали трафик Wireshark'ом, ковыряли логику в инженерном ПО и смотрели, как оператор скролит мнемосхемы.

Но прежде чем мы разойдемся, я хочу, чтобы мы вместе посмотрели на всю эту картину целиком. Без розовых очков, без корпоративных регламентов, без этой дурацкой политкорректности, которая мешает называть вещи своими именами.


6.1. Главное разочарование: SIL - это не про безопасность от хакера​

Знаешь, что меня бесит больше всего? Когда какой-нибудь вендор или интегратор начинает впаривать заказчику железку, размахивая сертификатом SIL 3, и утверждает, что это "защитит от любых угроз". Ребята, давайте уже взрослыми станем.

SIL (Safety Integrity Level) - это математическая вероятность того, что оборудование не сломается само по себе за определенное время. Это про отказ аппаратуры (random hardware failures). Это про то, что транзистор не сгорит, резистор не уйдет в обрыв, а память не перепутает бит от космического излучения.

SIL - это НЕ про безопасность от злоумышленника (security). Это вообще разные вселенные. Можно иметь SIL 3-сертифицированный контроллер с сертифицированной SIL 3-логикой, но если на инженерной станции стоит пароль "12345" или висит доступ в интернет через 3G-модем для "удаленного мониторинга начальством", то вся эта SIL-защита рассыпается в прах. Злоумышленнику плевать на вероятность отказа железа. Он не будет ждать, пока транзистор сгорит. Он просто зайдет по RDP и отключит защиту программно.

И вот тут мы подходим к главному парадоксу. Всё, что мы делаем для повышения надежности SIS (дублирование, резервирование, диагностика), может быть использовано против нас. Два канала вместо одного? Отлично, можно атаковать шину синхронизации между ними. Диагностика, которая постоянно проверяет линию связи? Прекрасно, можно вызвать ложное срабатывание диагностики, и система сама себя вырубит.

Вывод: Не ведись на сертификаты. Смотри на систему в целом. SIL - это просто цифра в паспорте. Реальная безопасность - это когда ты понимаешь, как именно твоя система может быть скомпрометирована, и закрываешь эти дыры, даже если они не описаны ни в одном ГОСТе.


6.2. Признай, что ты уязвим​

Самое трудное для любого инженера или руководителя - признать, что его система неидеальна. Особенно если это SIS. Особенно если за нее плачены большие деньги. Особенно если на нее получены все сертификаты.

Но давайте честно. У любой SIS есть как минимум три группы уязвимостей, которые невозможно закрыть на 100%:

1. Человек. Оператор Вася, который может перепутать кнопки. Инженер Петя, который может залить "кривую" прошивку. Начальник, который требует отключить защиту "на часок, чтобы план выполнить". Злоумышленник, который заходит под видом командированного. Человека не пропатчишь. Человека не обновишь по воздуху. С человеком можно только работать - учить, контролировать, мотивировать. И это самый сложный участок работы.

2. Физика. Если у злоумышленника есть доступ к проводам - он хозяин положения. Можно сколько угодно ставить файрволлы и IDS, но перемычка на клеммах концевика задвижки решит всё. Шкафы должны закрываться. Доступ должен быть строго по спискам. Кабельные трассы должны быть защищены от механических повреждений. Физическая безопасность - это база, без которой всё остальное бессмысленно.

3. Сложность. Современные SIS - это сложные системы. Тысячи строк кода (пусть и в графическом виде), десятки устройств в сети, интеграция с верхним уровнем. В такой сложности всегда найдется место для ошибки. Для недокументированной функции. Для "временного решения", которое стало постоянным. Для забытого порта. Для тестового аккаунта. Сложность - главный враг безопасности. Чем проще система - тем легче ее защитить. Но простые системы плохо продаются.


6.3. Как думает тот, кто хочет тебя сломать​

Мы с тобой, читатель, одной крови. Мы - технари. Мы любим, чтобы работало. Чтобы колонна грелась, насос качал, клапан открывался. Мы не хотим аварий. Но чтобы защитить систему, мы должны уметь думать как тот, кто хочет ее сломать.

Вот как думает атакующий (не важно, злобный хакер или просто любопытный студент):
  • "Где самое слабое место?" Он не будет ломиться в защищенный шлюз с паролем. Он пойдет к старому датчику, который висит на неэкранированной витой паре, и наведет туда электромагнитную наводку мощным трансформатором. Сработает защита? А если повезет, то и нет.
  • "Что здесь самое ценное?" Ему не нужны твои техпроцессы. Ему нужна одна конкретная задвижка, которая перекрывает подачу опасного вещества. Он будет искать, как на нее повлиять. Через сеть, через инженерную станцию, через физический доступ.
  • "Кто здесь самый уставший?" Он будет ждать, когда оператор после 12-часовой смены отвлечется на кофе и не заметит странного сообщения. Он будет атаковать в 3 часа ночи, когда в диспетчерской один человек и тот клюет носом.
  • "Что здесь сделано 'для галочки'?" Он найдет тот самый "временный костыль", который воткнули пять лет назад и забыли убрать. Найдет пароль от инженерной станции, записанный в блокноте у охраны. Найдет отключенную сигнализацию, потому что она "мешала работать".
Понимая это, ты можешь выстраивать защиту. Не абстрактную "от всех угроз", а конкретную: закрыть доступ к проводам, сменить все пароли по умолчанию, убрать костыли из логики, обучить персонал не кликать на подозрительные ссылки.


6.4. SOS: Что делать прямо сейчас (план действий для инженера)​

Ладно, теории было много. Давай конкретику. Если ты сейчас сидишь на объекте и отвечаешь за SIS, или просто хочешь проверить свою систему на прочность, вот тебе чек-лист. Пройди по нему - и сразу увидишь, где у тебя дыры.

Шаг 1. Инвентаризация.
Возьми лист бумаги (или Excel, если не хочешь пачкаться). Пройди по всем шкафам управления, которые имеют отношение к SIS.
  • Запиши все модели контроллеров и модулей ввода-вывода.
  • Запиши все IP-адреса и названия устройств в сети.
  • Нарисуй схему сети: где стоят коммутаторы, куда идут кабели, есть ли связь с корпоративной сетью.
  • Найди все точки физического доступа: замки на шкафах, дверцы, незакрытые патч-панели.
Шаг 2. Проверка паролей.
Это больно, но надо.
  • Зайди на инженерную станцию SIS. Проверь, какой там пароль на вход в Windows. "1"? "password"? А где он записан? На стикере на мониторе? Отлично, ты нашел дыру.
  • Проверь пароль на проекте в инженерном ПО (TIA Portal, Control Builder и т.д.). Он есть вообще? Или проект открывается без пароля?
  • Проверь пароли на коммутаторах. Они стандартные? Cisco: cisco/cisco? HP: admin/admin? Если да - бегом менять.
Шаг 3. Анализ сетевого трафика.
Подключи ноутбук с Wireshark к зеркальному порту коммутатора, где сидит SIS. Посиди час-два, запиши трафик.
  • Есть ли Modbus TCP команды от DCS или SCADA в сторону SIS? Если есть - смотри, что это за команды. Может быть, это "сброс защиты"?
  • Есть ли незашифрованные протоколы типа HTTP, Telnet? Может, кто-то забыл выключить веб-интерфейс на контроллере?
  • Есть ли трафик в неизвестные тебе IP-адреса (может, утечка данных или связь с внешним миром)?
Шаг 4. Физический осмотр.
Надень каску, возьми фонарик и иди в поле.
  • Открой любой шкаф удаленной периферии SIS (рядом с реактором или колонной). Закрыт ли он на ключ? Или открыт "для удобства обслуги"?
  • Посмотри на датчики, подключенные к SIS. Есть ли к ним свободный доступ? Можно ли подойти и пережать трубку или подключиться к клеммам?
  • Посмотри на кабельные трассы. Идут ли кабели SIS в одной траншее с кабелями DCS? Идут ли они открыто по земле, где их можно перерезать лопатой?
Шаг 5. Анализ логики.
Если у тебя есть доступ к проекту SIS (с разрешения начальства, конечно), открой его.
  • Найди все места, где используются "ручные режимы" (manual mode), "байпасы" (bypass), "принудительные значения" (force).
  • Как они активируются? Через HMI? Через отдельную переменную? Есть ли защита от несанкционированного включения этих режимов?
  • Посмотри на таймеры. Нет ли там задержек, которые позволяют оператору "успеть нажать кнопку"? Это может быть лазейкой.
Если по любому из этих шагов у тебя возникло чувство "ой, а у нас тут все плохо" - значит, время не прошло даром. Ты нашел проблему. Теперь ее можно решать.


6.5. Прощание с иллюзиями: SIS - это не панацея, а инструмент​


SIS - это не волшебная палочка. Это просто еще один слой техники. Он может спасти, а может и подвести. Всё зависит от того, как его спроектировали, как эксплуатируют и как защищают от дурака и от злоумышленника.

Мой тебе совет: относись к SIS с уважением, но без фанатизма. Не думай, что раз система сертифицирована, то она неуязвима. Проверяй ее. Тестируй. Ищи дыры. И главное - помни, что за любой автоматикой стоят люди. Операторы, технологи, инженеры, начальники. Они могут ошибаться. Они могут уставать. Они могут быть невнимательными. Твоя задача - сделать так, чтобы система прощала их ошибки и не позволяла ошибке превратиться в катастрофу.


6.6. Последний совет: Будь человеком​

Мы тут с тобой наговорили про хакеров, про атаки, про уязвимости. Это всё интересно, это драйвово. Но давай не забывать, ради чего всё это.

За каждым манометром, за каждым клапаном, за каждой строчкой кода в SIS стоит реальная опасность. Высокое давление, ядовитые вещества, взрывоопасные смеси. Ошибка может стоить жизни. Не абстрактных "пользователей", а конкретных людей - твоих коллег, которые работают рядом.

Поэтому, когда ты лезешь в SIS с мультиметром или с ноутбуком, делай это с холодной головой и с чувством ответственности. Не ради "понтов", а ради дела. Ради того, чтобы система работала надежно и безопасно. Ради того, чтобы вечером все разошлись по домам.

Это про понимание. Про то, чтобы знать, как работает система, глубже, чем написано в инструкции. Про то, чтобы видеть скрытые связи и неочевидные последствия. Используй это знание во благо.

Итог:
SIS уязвимы. Это факт.
Их можно взломать. Это факт.
Последствия могут быть фатальными. Это факт.

Но знание об этих уязвимостях дает нам силу. Силу защитить. Силу предотвратить. Силу сделать промышленность по-настоящему безопасной, а не безопасной "на бумажке".

Так что включай голову, бери в руки инструменты и делай мир чуть более защищенным. Потому что кроме нас с тобой, это сделать некому. Вендоры будут продавать, начальники будут экономить, операторы будут уставать. А мы - мы будем думать. И проверять. И исправлять.
 
Последнее редактирование модератором:
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab