Comments 10
Вспомним протокол Modbus, активно использующийся в автоматизации где только можно, и у которого защиты нет от слова «вообще»
Если Modbus TCP доступен со внешнего окружения — проблема не в нем. а в разработчике системы. Использоваться он должен только в сети технологического управления, не имеющей моста с внешним миром.
Проблема в том, что Modbus уязвим от несанкционированного доступа и внутри. Притащил какой нибудь инженер флешку, а там зловред. А так как нет абсолютно никакой авторизации в модбасе, то пиши в любые порты что хочешь, с соответствующими возможными последствиями
Вот яркий пример из реального мира: Stuxnet: война 2.0:
Поэтому проблема не только в разработчике системы, но и в используемых элементах системы. Прописную истину, что надежность любой системы равна её надежности слабейшего элемента, еще никто не отменял. У modbus защиты от несанкционированного доступа нет от слова вообще.
А самый мой первый пост видимо минусуют те, кто прячет голову в песок ))))
И действительно, «слабым звеном» оказался человеческий фактор – Stuxnet был занесен в систему посредством обычного USB-накопителя, который по неосторожности вставил в рабочую станцию нерадивый сотрудник.Читаем дальше:
Следует отметить, что Stuxnet поражает лишь конкретный тип контроллеров Siemens, а именно SIMATIC S7, который, по сведениям МАГАТЭ, используется Ираном.Думаю не нужно объяснять, каким образом шел обмен между контроллером и вирусом на компах — через вышеупомянутый modbus.
Поэтому проблема не только в разработчике системы, но и в используемых элементах системы. Прописную истину, что надежность любой системы равна её надежности слабейшего элемента, еще никто не отменял. У modbus защиты от несанкционированного доступа нет от слова вообще.
А самый мой первый пост видимо минусуют те, кто прячет голову в песок ))))
Думаю не нужно объяснять, каким образом шел обмен между контроллером и вирусом на компах — через вышеупомянутый modbus
Откуда Вы знаете, что использован был Modbus, а не ProfiNet, к примеру? А Вы можете перечислить все протоколы, которые поддерживают контроллеры семейства Simatic S7? И какие из них поддерживают ограничение доступа и шифрование? Мне вот, например, кроме OPC UA ничего в голову не приходит.
В промышленности используются сотни протоколов, и подавляющее большинство не решает вопросы ограничения доступа и шифрования. И это не потому, что протоколы старые, а разработчики ленивые. У промышленной сети предназначение — работать внутри периметра доверия. И основные приоритеты — надежность, скорость, экономичность.
Stuxnet был занесен в систему посредством обычного USB-накопителя.Вот где была точка отказа. Дальше уже не важно было -по защищенному или нет протоколу ОС АРМ оператора связывается с контроллером, будет шифрование или нет — поскольку доверие к командам вирусной программы = доверию командам оператора.
Откуда Вы знаете, что использован был Modbus, а не ProfiNet, к примеру?ознакомиться самостоятельно с исходниками вируса у меня нет возможности, поэтому руководствуюсь информацией из интернета. Опровержений об использовании именно modbus не видел, поэтому использую версию именно с модбасом
А Вы можете перечислить все протоколы, которые поддерживают контроллеры семейства Simatic S7?Ммм, зачем мне вам что то перечислять? )))) Достаточно того факта, что симатик поддерживает модбас
И какие из них поддерживают ограничение доступа и шифрование? Мне вот, например, кроме OPC UA ничего в голову не приходит.Вот в этом то и проблема, что практически все протоколы, используемые в автоматизации, небезопасные
У промышленной сети предназначение — работать внутри периметра доверия. И основные приоритеты — надежность, скорость, экономичность.Вот именно, должна обеспечиваться надежность. И под надежностью понимается не только бесперебойная работа оборудования, его резервирование и т.д., но и защита от человеческого фактора, от случайных или преднамеренных ошибок. Современные протоколы, используемые в автоматизации, этого практически не обеспечивают.
Легко представляю себе в этой стране сценарий "у асушника украли рабочий ноутбук", из-за которой действующие системы никто переделывать не станет. Максимум — пароли поменяют, если они там были вообще
Вы просто не представляете, как сейчас работают производители всяких супер-станков с ЧПУ. Покупаете вы станок за ахулиард денег. Приезжают представители производителя, производят пуско-наладку и привязывают его месторасположение. Вы подписываете всякие договоры на обслуживание, акты всякие и прочее. Так вот, каждый день, станок лезет на сервак изготовителя и проверяет, по зашифрованному протоколу конечно, не истекла ли лицензия. Если лицензия истекла, то вы её либо продляете, либо получаете тыкву. Если вы передвинули станок, вы нарушили договор и получаете тыкву. Но это еще полбеды. Где гарантия, что каждый день станок не сливает по этому самому протоколу, программу в G-кодах, которую он отработал? Э? Ясен пень, что производитель знает, что это за завод (например эээ хм… завод искусственного химволокна ) и ясно же, что он может там производит. И тут ты начинаешь получать в чистом виде детальки, которые станок точит.
А вы вредоносный код, взлом… Тут в открытом виде всё лежит ивсе кому надо, тот воруют.
А вы вредоносный код, взлом… Тут в открытом виде всё лежит и
Да, безопасность у роботов — беда-беда. Universal Robot роборуки например живут со стандартным логин/паролем в ssh и линуксом, который уже 2 года как не поддерживается, т.е. нет заплаток безопасности. Ну т.е. немного волосы шевелятся при таком подходе.
Sign up to leave a comment.
Уязвимости и вредоносный код в системах промышленной автоматизации