Комментарии 3
может стать причиной сбоя в ПЛК, для которого каждый лишний сетевой пакет - повод надолго задуматься или уйти в перезагрузку.
Не совсем корректное утверждение. У большинства ПЛК (вернее у всех нормальных) сетевой обмен идёт асинхронно с основным циклом программы. В противном случае было бы невозможно обеспечить низкое время выполнения основного цикла. Плюс вылет коммуникаций никак не связан с остальным циклом.
Поэтому отправка лишних пакетов не повлияет на задумчивость и уж тем более не отправит в ребут. Но в случае если распределённая периферия сидит на Industrial Ethernet (именно на нём, а не Profinet так как последний может в RT и IRT) - можно опоздать с отправкой на цикл, например. Ну плюс теоретически СКАДА может получить пакет на один цикл отправки позже.
То есть в целом, при однократном опросе (или многократном разумной частоты) в активном сканировании в сетях АСУ ТП нет никакой опасности для системы. Но в целом пассивное сканирование это действительно интересно.
Хорошему ПЛК от флагманов рынка действительно такие мелочи не страшны.
Но есть еще всякие древние устройства с непредсказуемым поведением, а также такой зверь как SoftPLC – где нет четкого деления на коммуникационные и процессорные блоки, и по факту весь код прошивки ПЛК выполняется под управлением ОС общего назначения.
В общем, уход ПЛК в перезагрузку вследствие элементарного сканирования портов – это не оборот для красного словца, а отголосок реального печального опыта на производственных объектах.
SoftPLC
Которые выпускают в том числе флагманы рынка. И в некоторых случаях СофтПЛК вертятся поверх ОСРВ или ядер ОСРВ с преферансом и куртизанками. В некоторых случаях СКАДА системы имеют в себе рудименты и/или полноценные софтовые ПЛК с МЭКовскими языками.
Ну и в целом, на системах с СофтПЛК поверх ОС общего назначения, крутить что-то ответственное и важное это "производствоубийство".
древние устройства с непредсказуемым поведением
Вообще в мире с розовыми понями и единорогами надо не анализом такого железа заниматься, а техническим перевооружением. Нестабильные ПЛК могут встать не то, что от сканирования портов, а прямо во время исполнения основного цикла потерять данные на ROM... a few moments later... в силу тех, или иных, причин ребутнуться и линия встанет.
То есть в любом случае если сканирование портов привело к отвалу ПЛК - тут стоит задуматься не только о пассивном способе анализа сети, но и о замене ПЛК.
Кстати, в целом тоже интересный вариант использования. Нагрузочное тестирование ПЛК :)
Определение классов сетевых узлов и выявление аномалий в их активности по сетевому трафику в пассивном режиме