OPC UA сервер для Modbus TCP

[VADR]

Приветствую.

Ищу софт: OPC UA сервер для протокола Modbus TCP. Так уж получилось, что в связи с санкциями купленный нами Kepware активировать не удаётся. Вот так вот: деньги взяли, ключ прислали (до санкций ещё), а активировать не дают. Ну да ладно.
Я понимаю, что вариантов таких чуть более, чем дофига. Однако, у некоторых, известных мне, особенности функционирования, мягко сказать, обескураживают. Потому, как говорится, обжёгшись на молоке, дуем на воду.

[+] например

Всем известный от Insat. Для изменения конфигурации надо останавливать работу самого сервера. То есть - если мне надо добавить тег, я должен остановить сервис, разрегистрировать его (а в это время он может снова запуститься, так как придёт запрос - это было для OPC DA, как для UA - я не в курсе), запустить для редактирования настроек, сделать всё, что надо, запустить для проверки рантайм, проверить, снова остановить, снова зарегистрировать как сервис, запустить сервис. При этом игра с сервисами может по пути запросить перезагрузку машины, а это тоже не всегда приемлемо. Итого - небольшая переконфигурация тянет за собой провал в данных где-то на полчаса, а если этих данных - сотни? Меня же диспетчера съедят за это время. Плюс к тому же - где там у сервера хранилище сертификатов - я на демке так и не нашёл. И ещё весёлый плюс: при хардварном ключе лицензии под каждый ключ - свой инсталляционный файл (опять таки, я это помню из одной несколько устаревшей версии - сейчас не знаю), то есть если у вас куплен резервный ключ, который просто хранится в шкафу, вот так вот просто воткнуть его в комп не получится, надо переинсталировать софт. Очень хорошо, очень весело...

Так вот, чего, собственно, хочется.
1. Сервер, устанавливаемый на ОС Windows в качестве сервиса.
2. Админка, работающая независимо от рантайма. То есть - запустил админку, и пока конфигуришь, рантайм работает. В идеале, чтобы это можно было делать на другом компьютере и заливать по сети. А если ещё и тестировать на другой машине на каком-нибудь получасовом демо-рантайме - ещё лучше.
3. Полный комплект шифрования/электронной подписи/авторизации по имени/паролю. С удобной хранилкой сертификатов. В идеале - с напоминалкой, что какой-то сертификат через полгода-год закончится и в ближайший останов предприятия его надо перевыпускать.
4. Ну и да, для Modbus TCP. Но в идеале - чтобы был модульный, на который можно накрутить кучу разных протоколов. Если протоколы отдельно лицензируются и стоят отдельных денег - пусть будет так.
5. Лицензируемый независимо от внешних факторов. Если он будет куплен и просто лежать в шкафу, а понадобится вдруг только через год/два/пять, то я должен иметь возможность его активировать, даже если производитель совсем исчезнет (закроется, обидится, или диарея его замучает). Опять таки, в идеале - иметь возможность перемещения на виртуалку, ибо почему бы и нет.

Вот, как-то так. Можете что-нибудь дельное посоветовать?

Отправлено спустя 4 минуты 21 секунду:
И ещё. Хорошо, если продукт это будет отечественный.

[Sokolov_Dmitry]

https://ptk-sura.ru/about/elicont-cs/
https://www.cea-energo.ru/ru/products/tmius-linux

[keysansa]

Дополню:
https://owen.ru/product/new_opc_server
Пробовал, работает.

[VADR]

https://ptk-sura.ru/about/elicont-cs/

Я уже смотрел в эту сторону. Можно демку скачать/попробовать? Вроде бы этот продукт мы уже обсуждали - вы говорили, что поддержки шифрования и электронной подписи на стороне сервера пока нет, но планируется. У нас на предприятии мы сейчас идём к тому, чтобы эти вещи сделать обязательными, если идёт обмен по сети.

https://www.cea-energo.ru/ru/products/tmius-linux

С одной стороны - штука интересная. С другой <тут начинается старческое брюзжание> для windows версии инсталлятор явно не допилен, вернее - практически отсутствует. "Разместить программное обеспечение по не длинному пути, например C:\TM_SERVER" - то есть где-то какие-то проблемы с пробелами в именах файлов. Ну да ладно. Непонятно также, зачем нужен WinPcap: на мой взгляд, для сетевого функционала хватило бы обычный функций ОС.</ брюзжание выключаю> А вот кроссплатформенность - это точно хорошо, надо будет покрутить на каких-нибудь dlink'ах под OpenWrt.

Дополню:
https://owen.ru/product/new_opc_server
Пробовал, работает.

Вот тут я не нашёл ни OPC UA, ни запуска в виде сервиса (только OPC DA в виде приложения). И вообще: логи пишет в свой подкаталог программы ниже /Program Files, а туда стандартно есть доступ только у администраторов. То есть - сама софтина должна запускаться с админскими правами. И это софт, работающий через DCOM, дающий возможность внешним клиентам что-то там на сервере запускать. Б - безопасность.

Отправлено спустя 9 минут 4 секунды:
Кстати, ещё по ТМИУС КП: как сказано тут: http://wiki.cea-energo.ru/wiki/Activation, для активации требуется получить некторую информацию из устройства и передать в саппорт, который сгенерит серийник. Как уже писал выше - не хочу зависеть от внешних факторов при активации лицензии. Обжёгшись на молоке - дую на воду.

[Sokolov_Dmitry]

вы говорили, что поддержки

это вы наверное с производителем общались, не со мной, знаю парочку этих производителей ПО для шлюзов ТМ с OPC UA.
еще готовые серваки есть https://www.icpdas.com/en/product/guide ... on__Server

[VADR]

это вы наверное с производителем общались, не со мной,

Это в Телеграме обсуждалось в группе ПТК СУРА. Там ответил человек с именем Dmitriy и ником @Skv_dl:

Но на канале передачи данных (OPC UA сервер) защищённое соединение пока не поддерживает. Но в дальнейшем этот функционал тоже добавим. В планах есть.

Я понимаю, что это разработчик. Думал, это Вы и есть :) Прошу прощения, если ошибся.

[keysansa]

Вот тут я не нашёл ни OPC UA, ни запуска в виде сервиса (только OPC DA в виде приложения).

Хм... Я с ним работал из Linux, где только OPC UA, по идее.

И вообще: логи пишет в свой подкаталог программы ниже /Program Files

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

То есть - сама софтина должна запускаться с админскими правами.

Нет. Выставляется доступ и все. Но дело в следующем:

И это софт, работающий через DCOM, дающий возможность внешним клиентам что-то там на сервере запускать. Б - безопасность.

Вот тут полностью согласен. Однако, OPC = OLE for Process Control, а OLE = DCOM.

ЗЫ. Запуск как интерактивная служба (на Win2000, в последний раз делал) - не проблема. Больше проблем с Guardian этой службы.

[VADR]

Однако, OPC = OLE for Process Control, а OLE = DCOM.

Это раньше так называлось. Потом название сменили, а аббревиатуру оставили: теперь OPC = Open Process Communication. Но даже если и DCOM: одно дело - запустить процесс с ограниченными правами, другое - с админскими.

Нет. Выставляется доступ и все. Но дело в следующем:

То есть - покупатель ПО, после того, как установил софт, должен не забыть залезть в нужную папочку и выставить нужные права. А потом следующий апдейт или антивирусная проверка говорят "не порядок" и рубят нафиг эти костыли. Я о чём: для хранения всяких данных существует ProgramData. А для логов так вообще есть специальный системный механизм.

[keysansa]

Это раньше так называлось. Потом название сменили, а аббревиатуру оставили: теперь OPC = Open Process Communication.

Сменили, так как в Linux нет DCOM. Там своя реализация RPC. В Windows ничего не поменялось.

Но даже если и DCOM: одно дело - запустить процесс с ограниченными правами, другое - с админскими.

У DCOM есть свой менеджер прав доступа. Можно настроить такие же разрешения, как на файловой системе. Однако, та же Wonderware запускает OPC сервер от имени системы (которая лишь немногим уступает администратору), я не от пользователя с только необходимыми правами.

То есть - покупатель ПО, после того, как установил софт, должен не забыть залезть в нужную папочку и выставить нужные права. А потом следующий апдейт или антивирусная проверка говорят "не порядок" и рубят нафиг эти костыли. Я о чём: для хранения всяких данных существует ProgramData. А для логов так вообще есть специальный системный механизм.

Я согласен, что кривовато сделано. Но это общая беда Windows. Разделение на файлы исполняемых программ и файлы данных только недавно появилось. Тот же MS SQL сервер создает файлы базы данных в Program Files до сих пор. плюс, не все программисты умеют работать с Windows Logging System.
Однако, с появлением Power Shell, настройку прав достаточно легко автоматизировать.

Отправлено спустя 59 минут 31 секунду:
Настройки прав DCOM, как пример:
https://www.ibm.com/docs/en/qradar-on-c ... ermissions

[stesl]

У нас на предприятии мы сейчас идём к тому, чтобы эти вещи сделать обязательными, если идёт обмен по сети.

VADR, привет.

[+]

А продукты массово не закупают? Бомбоубежища не роют? У нас последнего пока нет вроде, но оповещение о воздушной тревоге поставили. А безопасники, да - звереют. Тревожно как то )))

[VADR]

Нет, не копают и не роют. Но безопасность - это штука такая: когда начнутся проблемы, меры принимать будет уже поздно. Я, конечно, не сторонник бездумного навтыкания оборудования ИБ где надо и где не надо (пример - видел в описании решений одного немецкого производителя систем ПАЗ в типовой схеме системы с одной резервированной парой контроллеров 13 файрволов :) ), но тут - стандартный функционал, почему бы его не использовать? К тому же в большинстве случаев это не требует дополнительных денег.

[keysansa]

Я, конечно, не сторонник бездумного навтыкания оборудования ИБ где надо и где не надо (пример - видел в описании решений одного немецкого производителя систем ПАЗ в типовой схеме системы с одной резервированной парой контроллеров 13 файрволов :) )

Кстати, а когда на контроллерах начнут фильтровать трафик? Хотя бы на уровне открыть/закрыть порт? Я понимаю, это ресурсы. Но внедрить сразу 2/3 обязательных интерфейса, где один внешний (на нем фильтрация), остальные для доверенных сетей, где в угоду скорости, фильтрацию не осуществлять. Пока что - простое сканирование портов контроллера, вызывает только недоумение.

[stesl]

но тут - стандартный функционал, почему бы его не использовать?

Проблема ИБ не решаема до конца... Только черный ящик или изолированная сеть. Это мое, нубское мнение. У меня нет опыта во всех этих сетевых делах. Вот был бы в штате такой спец, как keysansa, я бы первый глотку рвал, что нужно использовать все разумное и доступное. А пока... Одних только дум - а чо дальше то делать, на чем - выше крыши ;) И внезапно "обозлившиеся" коллеги по ИБ, согласны - изолированная сеть, пока гораздо лучше, чем все шифрования и подписи.

[+]

Но на днях приперли меня к стенке - ты зачем базы ОТК на флэш скопировал?!!! У меня глаза аж круглые сделались ))) Оказалось аппаратная хрень у них там с ИИ теперь есть, в общей сети, и она по контрольным словам и пр. решила, что один из файлов, скопированных мною является не попадающим в разряд допустимых для разглашения. Стали выяснять... Да, екселевский файл об отгрузке ГП... За 2017 год ))) Какая то партия за какое то число. Я даже не помню откуда он у меня. А документы копирую, чтобы когда на межвахте раз в три дня или три раза в день позвонят (может даже они же) - можно было посмотреть в бумажку. О чем речь идет.

[keysansa]

Проблема ИБ не решаема до конца...

Скажу избитое, но она просто мешает работать. Поэтому не популярна и саботируется персоналом.

[+]

- Представляешь, раньше у всех были пароли 123456 и все работали. Пришел новый админ, сделал всем сложные пароли. Теперь, на каждом мониторе приклеен стикер с паролем.

ЗЫ. От себя скажу, на моей первой серьезной работе (2000 год) админ поднял домен Windows, настроил перемещаемые профили, обменку сделал не файлопомойкой, а с разделением прав доступа по группам и отделам. Это было и удобно (занимаешь любой комп и работаешь) и безопасно (права выставлены правильно, никто лишнего не посмотрит и не сотрет). Но дальше, да, IDS (не помню, какая была) - та крови попила. Вставляешь флешку - не дай бог, что-то не понравится, блокирует все файлы на флешке. А ты всего-то приехал с объекта, и хотел актуализировать проект.

[VADR]

Проблема ИБ не решаема до конца... Только черный ящик или изолированная сеть.

До конца нерешаема, это да. Так же, как и замок в двери не исключит кражи со взломом (причём вариантов множество: от отмычек до выдирания дверей и просто нападения в наглую). И тут только необитаемый остров спасёт, и то не всегда. Однако же все почему-то продолжают использовать замки и закрывать их, уходя из дома. Ну это так, лирика. Что имеется в виду под чёрным ящиком - я не очень понял (надеюсь, не security over obscurity - ибо это само по себе идея так себе). а вот изолированная сеть (в смысле - абсолютно изолированная, без точек стыковки через файрволы, пресловутые "два отдельных порта на сервере" и т.п.) сейчас практически невозможна. Системы уже давно стали многоуровневыми, данные из АСУТП нужны где-нибудь в АСОДУ или MES, оттуда - в ERP, сбоку от всего этого ещё LIMS, от которого опять же обратно в MES, АСОДУ, откуда вниз в АСУТП. Во всей этой схеме можно как-то изолировать сети АСУТП, но данные всё равно оттуда нужны. Да и системам между собой общаться зачастую надо, причём не через "верхний уровень", а напрямую. Вот тут и надо думать - где и как изолировать, а где как-то обмен информацией налаживать. И там, где от обмена информацией не уйти, надо его максимально защищать.

[keysansa]

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

Вы как-нить, посмотрите лог своего домашнего роутера. >100 раз в день к нему пытаются подключиться со всех сторон мира. Даже если у вас динамический IP - вас это не спасет, они, если прорвутся, бэкдур через VPN организуют.

security through obscurity

Не скажите, перенос порта SSH с 22 (там просто баннер) на 443, например, вполне отсеивает "школьников". Что облегчает работу.

а вот изолированная сеть (в смысле - абсолютно изолированная, без точек стыковки через файрволы, пресловутые "два отдельных порта на сервере" и т.п.) сейчас практически невозможна.

Вы тут обрисовали систему, взлом которой возможен только изнутри. Но это решаемо, с оговорками или без. Сейчас. Так работают АЭС, например.

Вот тут и надо думать - где и как изолировать, а где как-то обмен информацией налаживать.

Не надо думать, где изолировать, надо думать где разрешить. Это основное.

Отправлено спустя 7 минут 50 секунд:
Кстати, одно из подтверждений работоспособности security through obscurity - нижненовгородские производители автосигнализации Pandora. У них свой алгоритм обмена брелка с сигналкой. Уже лет 8 никто не может вскрыть данный протокол (на 2010 год 1кк руб было предложено), хотя устройство продается (не фига не дешевое).

[stesl]

Не надо думать, где изолировать, надо думать где разрешить

Я так файрволлы и настраиваю ))) Сперва все запретить. А потом уже разрешить ;)

пресловутые "два отдельных порта на сервере"

Да, только они. И пусть над этим севрвером трясется IT. Когда систему строили, точнее надстраивали, я предлагал, как можно не выходя из рамок пром сети организовать все задумки. Сделали по своему... А так да - гальванически обособленная сеть. Гальванически, значит нет ни одного провода между этими сетями. То что его можно воткнуть - уже другая история ;)

[VADR]

Кстати, одно из подтверждений работоспособности security through obscurity - нижненовгородские производители автосигнализации Pandora. У них свой алгоритм обмена брелка с сигналкой. Уже лет 8 никто не может вскрыть данный протокол (на 2010 год 1кк руб было предложено), хотя устройство продается (не фига не дешевое).

1. И что будет, когда (не "если", а именно "когда") эту крутую сигналку взломают? Она превратится в тыкву одну из множества обычных сигналок. Или все тысячи инсталляций быстро менять на другую, ещё более невзламываемую?
2. Кстати, взломали уже. https://www.kaspersky.ru/blog/hacking-s ... ems/22405/ https://alarmforum.ru/forum12/thread14027.html. Способ гуглится несложно, здесь ссылку давать не буду.

пресловутые "два отдельных порта на сервере"

Да, только они. И пусть над этим севрвером трясется IT.

И ещё один плохой вариант. По сути - вместо защиты инфраструктуры и сервера, сервер превращается в инструмент взлома инфраструктуры.

[stesl]

Что имеется в виду под чёрным ящиком - я не очень понял

Термин такой. ПК у которого нет устройств ввода. Совсем. И естественно каких то внешних подключений.

По сути - вместо защиты инфраструктуры и сервера, сервер превращается в инструмент взлома инфраструктуры.

Я примерно так и выразился )) С применением расширенного народного словаря русс языка

[keysansa]

1. И что будет, когда (не "если", а именно "когда") эту крутую сигналку взломают? Она превратится в тыкву одну из множества обычных сигналок. Или все тысячи инсталляций быстро менять на другую, ещё более невзламываемую?

В основу надежности устройств, положен простой принцип - время наработки на отказ. Security through obscurity - выводит из уравнения сразу 2 переменных. Да, если есть инсайд - он ломает систему сразу. Но он так же, экономит много денег.

2. Кстати, взломали уже. https://www.kaspersky.ru/blog/hacking-s ... ems/22405/ https://alarmforum.ru/forum12/thread14027.html. Способ гуглится несложно, здесь ссылку давать не буду.

В первом случае - новость "про угон авто", а не про взлом шифрования. Во втором - вырвана сигнализация с корнем. Это, если, переложить на язык ИТ, 1: У вас увезли сервер из серверной. 2: Из сервера умыкнули жесткий диск. Погуглите еще.

Кстати, во втором случае, скорее всего сигнализация была тупо установлена под рулем, и получается, к сокрытию информации - не имела никакого отношения, так как была установлена "на потоке". И раз, ее вырвали, замкнули провода на стартер, моск - завели и уехали - блокировки по цифровому каналу - просто отсутствовали.
Это, если переложить на IT - выходите в интернет со статическим адресом, с выключенным файерволом.

Отправлено спустя 9 минут 57 секунд:

Термин такой. ПК у которого нет устройств ввода. Совсем. И естественно каких то внешних подключений

Вы немного не правы. Черный ящик - это ПК, у которого есть разъемы, но не понятно, как они внутри соединены.

[VADR]

В первом случае - новость "про угон авто", а не про взлом шифрования. Во втором - вырвана сигнализация с корнем. Это, если, переложить на язык ИТ, 1: У вас увезли сервер из серверной. 2: Из сервера умыкнули жесткий диск. Погуглите еще.

Нифига. В обоих случаях - захват контроля над системой сигнализации в обход их хитрого протокола радиообмена (конкретно - через
приложение для мобильника). Хитрый невзламываемый протокол превратился в "неуловимого Джо" из известного анекдота. И потом: ну не существует абсолютно невзламываемых протоколов. Вот только замена ключей при компрометации (если протокол известен, а в секрете - ключ) куда как проще, чем замена всего протокола.

[keysansa]

захват контроля над системой сигнализации в обход их хитрого протокола радиообмена (конкретно - через
приложение для мобильника).

Мы же обсуждаем радиообмен (точнее его шифрование), а не мобильное приложение.
DXL3000, DXL3500, которые без SIM - не взломали за все время их выпуска.
ЗЫ. Взлом социальной инженерией - да, прокатывает (например, вы выглядываете в окно, а там школьник вам по колесам стучит. Вы пытаетесь его отогнать - он вас нах шлет. Спускаетесь разобраться - а у выхода из подьезда - 2 братка с битой).

ЗЫЫ. Изначально тема шла в контексте "Безопасность через сокрытие информации". Я привел пример именно в таком ключе, Pandora не воспользовалась, RSA или ГОСТ шифрованием, а использовала свой, закрытый протокол (возможно модификацию одного из них). И данный ход - сработал.
Как еще пример - перенос SSH или VPN порта на 443 порт. Да, при анализе трафика можно понять, что это SSH, а не HTTPS, и это не панацея, но часть ботов - отсеит. Из таких кусочков и состоит все.

[VADR]

Изначально тема шла в контексте "Безопасность через сокрытие информации". Я привел пример именно в таком ключе, Pandora не воспользовалась, RSA или ГОСТ шифрованием, а использовала свой, закрытый протокол (возможно модификацию одного из них). И данный ход - сработал.

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

Как еще пример - перенос SSH или VPN порта на 443 порт. Да, при анализе трафика можно понять, что это SSH, а не HTTPS, и это не панацея, но часть ботов - отсеит.

Не знаю, только если очень небольшую часть ботов. Я на своём домашнем д-линке с openwrt на борту (а это что ни на есть обычный линух): судя по логам файрвола, после "пробежки" по стандартным портам почти всегда идёт сканирование по диапазонам.

[keysansa]

Его не поменяешь так вот запросто, как можно поменять ключи шифрования.

Если ломают систему шифрования с открытым исходным кодом - значит, нашли коллизию и смена ключей ничего не даст. С закрытым кодом смена ключей в данном - может помочь, в некоторых случаях, но не факт.
Разница в открытом и закрытом коде - открытый может протестировать любой желающий. И сообщить о том, что он нашел коллизию. Или не сообщить... В закрытом алгоритме - копаются те, которые не хотят сообщать.

Не знаю, только если очень небольшую часть ботов. Я на своём домашнем д-линке с openwrt на борту (а это что ни на есть обычный линух): судя по логам файрвола, после "пробежки" по стандартным портам почти всегда идёт сканирование по диапазонам.

Одно дело - сканирование портов, это делают все боты.
Другое дело, после определения портов, боты начинают эксплуатировать стандартные уязвимости. Да, можно настроить бот, что бы он применял хаки для SSH на всех портах, которые обнаружил. Это не совсем выгодно... Особенно, если повесить SSH и на 443 и на 993 и прочие SSL соединения, и банить через fail2ban (кстати, Openwrt поддерживает fail2ban, настройте его).

ЗЫ. Для Openwrt есть еще BanIP, что бы не думать про те диапазоны IP, из которых принципиально не должно быть соединений.

[keysansa]

Не совсем в тему OPC, но в тему безопасности.
Работал на одном из предприятий, от их интернета.
На ноуте Windows. Показали розетку в офисе. Подключился - все ок.
Инет для справки работает, раздал на телефон через WiFi.
Надо было положить денег на телефон. Клиент Сбера сказал - ОЙ, что то не то. Тинькофф - отработал, деньги пришли.
Работал долго, потом понадобилось пересобрать программку для Linux. Запустил виртуалку, собирается программа, а я, в ожидании, решил обновить Ubuntu. Но менеджер пакетов пишет ошибки, хоть и инет есть.
Забил, приехал домой, запустил обновление - все ок.
Почитал логи - ошибки сертификатов.
Нет доказательств, но думается мне, что на той фирме организовали https mitm proxy с подменой сертификатов.
Вот так и думай...
ЗЫ. Почему решил дома проверить обновления и почитать логи - на том предприятии не смог подключиться ни по VPN ни по SSH к домашнему серверу.