Комментарии 10
Этап 4 – сброс существующей сессии TCP. TCP-соединения используются для всех коммуникаций протокола IEC 104. Одновременно к главной контролирующей станции, мастер-устройству, могут подключаться несколько подчинённых устройств, но для передачи данных может использоваться только одно активное соединение. Для внедрения ложной команды в существующее соединение необходимо, чтобы действующее TCP-соединение было прервано. В дальнейшем атакующий ПК должен создать постоянное TCP-соединение.
А можно подробнее, что имеется ввиду?
И как данные парсеры защищают от рассказанных сценариев?
Написав парсеры для необходимых протоколов, можно применять сурикатные правила запрещающие передачу потенциально вредоносных команд на устройство (допустим, установить условие для проверки допустимых значений адреса ASDU)
Допустимые значение выставляются шкалой в контроллере / датчике . И опять же а что если это реально пришло такое значение а его ограничили на firewall? Как понять в таком случае ?
Есть кейс где это реально необходимо?
Ещё бы понять откуда в контроллере берутся потенциально опасные команды. И как это понимать. Есть у меня плк с опс ua, Я сам программирую ему теги и настраиваю им доступы (чтение/запись) в какой момент там появляются потенциально опасные команды?
Хочу понять реальный применение этому, вот как например s7 там можно отправить контроллер в стоп командой по сети ( не уверен но может и это настраивается) в этом случае все понятно, если команда стоп придет с станции оператора где нет инженерного софта. А вот с тегами не понимаю)))
Из потенциальных кейсов - у вас есть SCADA система под управлением INEA ME RTU, доступ к которой получили с использованием уязвимости в самой системе (допустим, CVE-2023-2131). К SCADA подключены контроллеры, управляемые по протоколу DNP3. Потенциальный злоумышленник может направить на контроллеры команды, способные нарушить нормальный производственный цикл. FW с корректно настроенными правилами СОВ способен предотвратить отправку команд, которые определены как потенциально вредоносные, на контролируемые устройства. Подробнее про атаки с использованием DNP3 можно прочитать здесь.
Если данные команды могут быть направлены легитимным пользователем - можно установить расписание сработки правил таким образом, чтобы запретить выполнение подобных команд только в то время, когда администратор не должен их направлять.
Примеры успешно реализованных атак, где злоумышленники получив доступ к SCADA системе, направили вредоносные команды на подключенные устройства можно найти, например, здесь и здесь.
Кейсы с тегами приведены скорее для иллюстрации написания парсера, в реальной среде обычно применяются правила СОВ, ограничивающие именно управляющие команды.
DNP3 к сожалению не знаком, вообще в РФ не встречал его)))Но судя по PDF там примерно, как и S7 есть команды рестарт и т.д
1) Запрет команд на время - ну если только в случае S7 stop и DNP3 restart - имеет место жить.
2) в примерах с захватами скады не понимаю как помог бы разбор пром протоколов и блокировка команд. У меня доступ к СКАДЕ я с нее просто хожу по мнемосхемам и нажимаю волшебную кнопку отключить. Если мы ее заблочим на FW)) то тогда оператор не сможет отключить оборудование и не известно что еще лучше. Когда хакер просто все отключил или когда оператор в нужный момент не может отключить обородувание, при вне штатной ситуации.
3) Про управляющие команды я так понял речь как раз идет про протоколы в типа DNP3 или S7. Вот интересно в IEC104 есть такие команды?)
Я просто основываюсь на простом и понятном мне Modbus, OPС UA, (он конечно не простой) с 104 глубоко не работал) Поэтому интересно что там за управляющие команды, раз вы написали на него парсер думаю вам известно для чего все это и даете рекомендации какие команды там блочить.
Про какие-то конкретные команды по IEC104 сказать не могу. В случае с IEC - заблокировать можно любую команду, отфильтровав её по любым возможным полям, но конкретный перечень блокируемых команд вместе с их содержимым зависит от того, какие команды используются на предприятии, и с какими данными они гоняются. Данный перечень индивидуален и составляется на этапе настройки FW на предприятии.
Исходя из нашего опыта - часто на FW устанавливают правила, задающие допустимые команды, и уведомляющие администратора ИБ в случае отправки команд не из разрешённого перечня. Правила напрямую блокирующие недопустимые действия (режим IPS) применяются действительно значительно реже, как раз из-за рисков, описанных вами в п.2
задающие допустимые команды, - Опять же не понимаю в какой момент берутся не допустимые команды (кроме Stop в S7 и DNP3 reset) )) Я сам пиши логику контроллера и добавляю теги. Я же не будут делать функцию уничтожить все если отправить единицу в тег bad_tag
ну вот да, так никто не может мне сказать что они блокирует))))
Но я верю что я найду тех кому это реально надо))
Спасибо!)
Препарируем промышленные протоколы — как и зачем