ОРС и сетевая безопасность

[Машинский Юрий]

Добрый день, коллеги!
Есть проблема:
Существует две системы АСУТП построеные на разном оборудовании, имеющие разные локальные сети. Руководством была поставлена, и успешно осуществлена, связать эти системы по ОРС. После этого возникла проблема с тем что в сети OPCклиента установлен зоопарк техники, есть станции работающие под Win98, и оттуда регулярно выползают вирусы. Сетка эта чужая и доступа к ней у меня нет.
В связи с этим вопрос как можно обеспечить хоть какой-нибудь уровень сетевой безопасности при использовании OPC, используя firewall или иные средства?

П.С. у себя поставили доп. сетевую карту в ОРС сервак и соединили клиента и сервер напрямую. Плюс поставили на эти машины Symantec.

[Jackson]

Я бы поставил FIREWALL и закрыл бы абсолютно всё, кроме OPC. Больше ничего не сделаешь.

[Машинский Юрий]

а такое возможно в аппаратном firewall, или надо выделять отдельную машину под шлюз?

[Marrenoloth]

Это возможно и там и там. Ввиду того, что все данные внутри двух локалок (не требуется кеширование данных для уменьшения траффика), я бы посоветовал взять железный фаервол. Если не жадничать, то он и логи нормально писать будет!

[Jackson]

Да можно и обычный firewall поставить, программный.
Если Ваш сервер работает под Windows, то например Outpost, он и логи сможет писать тоже (если понадобится). Сильно машину не загрузит - я им пользуюсь сам достаточно давно. На примере Outpost надо будет отключить к чертям контроль вэб-трафика, почты, локальный контроль, в общем оставить только контроль сетевого трафика. Указать правила разрешения трафика для подсетей, если вы удалённо администрируете Ваш сервер, то указать правила для telnet, RDP или того чем именно Вы администрируете, после чего перевести firewall в режим блокировки - он пропустит только тот трафик и только с тех адресов, которые разрешёны явно, остальной трафик - как входящий так и исходящий, молча завернёт.

[hell_boy]

Файервол, в том числе железный, не поможет, т.к. классический OPC DA использует DCOM, не имеющий ТСР/IP портов. Рекомедую погуглить на тему OPC Tunneller или SplitOPC Просьба не считать за рекламу

[Jackson]

Файервол, в том числе железный, не поможет, т.к. классический OPC DA использует DCOM, не имеющий ТСР/IP портов. Рекомедую погуглить на тему OPC Tunneller или SplitOPC Просьба не считать за рекламу

Почему не поможет? Ведь вирусы и прочая дрянь летят по TCP - от них и удастся закрыться. А OPC пусть себе работает. Или я не прав?

[Михайло]

Может я сейчас брякну какую-нибудь чушь, но вроде современные файрволлы перехватывают и COM/DCOM-связи, записи в реестр, наверное только до контроля WinAPI не дошли...

[hell_boy]

классический OPC DA использует DCOM, не имеющий ТСР/IP портов

Сам ошибся, сам себя и поправляю :D Для работы DCOM нужен 135 TCP порт, через который проходит червь Blaster и который в бизнес сетях сисадмины закрывают первым делом. Так что читайте следующие документы:
Understanding OPC and How it is Deployed
OPC Exposed
Hardening Guidelines for OPC Hosts

[VADR]

Файервол, в том числе железный, не поможет, т.к. классический OPC DA использует DCOM, не имеющий ТСР/IP портов. Рекомедую погуглить на тему OPC Tunneller или SplitOPC Просьба не считать за рекламу

Почему не поможет? Ведь вирусы и прочая дрянь летят по TCP - от них и удастся закрыться. А OPC пусть себе работает. Или я не прав?

Не совсем так. DCOM работает по TCP/IP, причём по тем же портам, по которым и виндовый "доступ к файлам и принтерам", поэтому файрвол в "чистом виде" может помочь, если настраивать ограничения по адресу источника запросов.

[Jackson]

Не совсем так. DCOM работает по TCP/IP, причём по тем же портам, по которым и виндовый "доступ к файлам и принтерам", поэтому файрвол в "чистом виде" может помочь, если настраивать ограничения по адресу источника запросов.

Конечно! Именно это я и имел в виду. Не просто нужные порты открыть, а только для тех кому положено.

[Машинский Юрий]

Спасибо! Ссылки почитаю. На первый взгляд есть одно "НО", в нескольких статьях посвященных ОРС читал что, нельзя закрывать порты так как OPC выбирает номер порта случайным образом из диапазона 1024-65535.
Программный firewall ставить не будем, бывали всякие глюки. Самый противный был c 4-й версией, которая регулярно завешивала ноут, причем ноут был у меня демонстрационной машиной на обучении персонала заказчика.

[hell_boy]

Осилил "Hardening Guidelines for OPC Hosts". Все по шагам и в картинках расписано. Можно с помощью указания "Endpoints" заставить OPC сервер работать на нужном статическом порту TCP, правда, с пометкой, "если позволяет это сделать вендор". Или, если "не позволяет", ключами в реестре ограничить диапазон портов.
Сегодня вот в рассылке пришло:

http://www.expressinterface.com/ OPC Express Interface (OPC Xi) is the newest OPC specification from the OPC Foundation. Based on Microsoft's .NET framework, OPC Xi enables a smooth migration from Classic OPC and supports communication through firewalls

[san]

Спасибо! Ссылки почитаю. На первый взгляд есть одно "НО", в нескольких статьях посвященных ОРС читал что, нельзя закрывать порты так как OPC выбирает номер порта случайным образом из диапазона 1024-65535.
Программный firewall ставить не будем, бывали всякие глюки. Самый противный был c 4-й версией, которая регулярно завешивала ноут, причем ноут был у меня демонстрационной машиной на обучении персонала заказчика.

Єто диапазон клиентских портов. На сколько я помню у всяких там брандмауэров и в конфигураторе DCOM настройки клиентских и серверных портов в фильтрах отличаются.
В DCOM конфигураторе еасть много настроек, что кому можно, что кому нельзя. По умолчанию запретите все на Вашем компе, а для вашего ОРС-сервера дайте разрешения только конкретному юзеру, который будет зарегистрирован только на клиентской и на серверной машине. А в брандмауэре Виндовса машины ОРС Сервера разрешите входящие только конкретным IP. Работы конечно много, но кто сказал что будет легко.
А вобще такими вещами должны заниматься Айтишники, в работу которых входит настройка сетевой безопасности.

[Машинский Юрий]

Все выше сказанное подходит привыделении отдельного шлюза для работы с внешней подсетью. Примерно подобное и было сделано.
Кстати, в справке для Siemens WinCC 6.0 явно указно, что работа через firewall не поддерживается.

[Jackson]

Спасибо! Ссылки почитаю. На первый взгляд есть одно "НО", в нескольких статьях посвященных ОРС читал что, нельзя закрывать порты так как OPC выбирает номер порта случайным образом из диапазона 1024-65535.

Во-первых, по этим портам описанные Вами гадости вряд ли прилетят. Гадости из локалки летят по 80-му порту, по NETBIOS, может и RDP - это можно закрывать. Очень часто бывает достаточно просто запретить NETBIOS-трафик для подсети, чтобы отрезать себя от гадостей из этой подсети.
Во-вторых, версия 4.0 - имелась в виду версия OutPost firewall 4.0 ? Это версия для старых машин под ОС ниже чем WinXP - и немудрено что вылетала. Для ОС WinXP и выше Outpost предлагает другую версию firewall, называется Security Package, последняя актуальная версия 6.7.3. Эта и предыдущие версии (начиная с пятой) я использовал, в частности уже говорил что сейчас работает 6.7.3. BSODы помню на пятой версии, иногда бывали, в 6-й версии это пофиксили, по крайней мере у меня ни одного BSODа с июля прошлого года (когда обновил до 6-й версии) не было.
Из глюков замечено (не только мной лично, а вообще) только два:

1. некорректно обрабатывает подключение удалённой сети по VPN (в момент подключения firewall должен быть отключен, в противном случае NETBIOS-трафик этой блокируется без объяснения причин)
2. только в версии х64 клиентский процесс загружает ЦП на 20-50% в outpost 6.7.2 и на 10-20% в outpost 6.7.3 - это только для 64-разрядной версии и только под 64-разрядными ОС (WinXPx64, Vistax64, Win7x64). Вообще версия outpost х64 сейчас тестовая, хотя вполне работает себе, в марте планируется выход Outpost 7, где будет уже нормальная поддержка ОС х64. А версии х86 (32-разрядные) прекрасно работают.

Про эти глюки Outpost прекрасно знает и занимается их устранением. Так что если Ваш сервер не использует VPN и работает под WinXP х86, то не вижу никаких проблем. А так - ставить отдельный firewall - это же всё равно серверная машина с каким-то брандмауэром, ну не Outpost а каким-то другим.... Из пушки по воробьям. Ну не CISCO же Вы собрались ставить?

P.S. Я не работаю в Augnitum :)

[Машинский Юрий]

Так что если Ваш сервер не использует VPN и работает под WinXP х86, то не вижу никаких проблем. А так - ставить отдельный firewall - это же всё равно серверная машина с каким-то брандмауэром, ну не Outpost а каким-то другим....
P.S. Я не работаю в Augnitum :)

В том-то и дело, что у нас сервер одновременно сосет данные по разным сетевым протоколам с разных машин, а второе отягчающее обстоятельство что частенько на этом сервере стоит EMBEDDED XP и в имеются жесткие ограничения на размер "дискового пространства" на мегабайты счет идет. Поэтому я думал о возможности установки простенького аппаратного firewall например какой-нибудь Dlink недорогой.
Но это все про существующие и работающие проекты.
А если брать в общем то мне кажется самым дешевым из надежных будет решение с выделением отдельного сервера-шлюза на границу сети.

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

[Jackson]

Я Вас понял. Раз Embedded - то всё понятно, не разбежишься.

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

"У нас в электроэнергетике" - это звучит гордо. И, я извиняюсь, у Вас в электроэнергетике, в той же сети на базе которой построена АСУ, публике позволено порнуху с интернета смотреть? :amazement: (вирусы и гадости в основном оттуда). Как бы это помягче сказать..... "Я худею, дорогая редакция!" Н-да.... Тогда, по моему разумению, не там Вы брандмауэр ставите, точнее - его надо ставить и на стыке сетей тоже. Но по-хорошему, я думаю, Вы меня поняли: либо персонал энергетикой управляет, либо по соц.сетям шарится. Идеальное решение - физически разные сети, т.е. компы с доступом в АСУ и компы с доступом в Инет, с контролем доступа в сеть АСУ по МАК-адресам и IP-адресам. За попытку воткнуть комп не в ту сеть - расстрел на месте.

Как это у наших Датских коллег на фирме: на рабочих компах должно стоять только лицензионое ПО, за обнаружение контрафакта следует немедленное увольнение и это правда, были случаи. При этом купи себе домой компьютер, ноутбук, таскай его на работу и делай на нём что хочешь, не втыкая в ЛВС фирмы. За включение ничего не будет - будет если контрафакт найдут. Доступ в инет тоже ограничен - на личный ноут Wi-MAX ставь и лазай где хочешь и когда хочешь. И всё работает, сеть годами не падает, мусора нет, а все желающие сидят на фейсбуке и майспейсе сколько хотят - со своих личных ноутов со своим же личным интернетом. Рабочая сеть для работы, такова дисциплина.

Я ведь тоже электроэнергетик, только с приставкой "микро" (один агрегат до 2,5 МВт), и на тех объектах где мы отметились, такого бардака нет.

Извините за многословность - задело за живое. В общем, разделяйте сети физически и будет Вам счастье. А так... Могу рассказать про то как в известной software-фирме начальство отдало распоряжение позакрывать доступ к развлекательным сайтам и чем дело кончилось. :)

[Машинский Юрий]

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

не обижайтесь. Я изначально и спрашивал о возможности установки firewallа на стык сетей. в нашей сети у персонала даже к системнику доступа нет, только клавиатура и монитор с принтером. Про домашние ноуты, мы шли дальше: заранее в спецификацию включали один избыточный компьютер, для развлекаловки операторов. Но когда появляется необходимость подключения к смежникам тогда проблемы и появляются.
А мой предыдущий ПС был вызван вашими словами об установке циски, смысл его был в том что если надо будет, для решения проблемы, поставить циску - поставим циску.
Думаю тему можно заканчивать. Спасибо всем за внимание.

[Pashkevich]

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

Во-во, у меня та же фигня, аж весь трафик через сервак в Вашингтоне идет...

При этом купи себе домой компьютер, ноутбук, таскай его на работу и делай на нём что хочешь, не втыкая в ЛВС фирмы.

Ага, и спасаемся так же - по 2 ноута на столе, вот только с инетом не очень здорово получается - только EDGE и Скайлинк.

Рабочая сеть для работы, такова дисциплина.

В общем-то это правильно, но слишком жесткие правила иногда все-же мешают работать.

Я ведь тоже электроэнергетик, только с приставкой "микро" (один агрегат до 2,5 МВт)

Это скорее мини, коллега! Микро - это где-то до 100кВт.

[Jackson]

Да я не обижаюсь ни грамма, что Вы! Это я так удивляюсь. Ибо ответственность объекта какая. Объект - надеюсь, не АЭС? :)
Собственно мне сейчас все коллеги хором подсказали один и тот же способ решения Вашей проблемы - физическое разделение сетей. Даже для удалённых сетей это возможно (только проверить сложно, но опять же можно). А когда узнали что объект в энергетике - тоже глаза округлили.
Ни в коей мере никаких обид! Но очень сильное удивление.

По сути да, всё понятно.

Датчане - вообще нация очень педантичная и дисциплинированная, русскому там тоска. Я специально такой пример и привёл - как максимум возможного.

Микро- или мини- - а я, честно говоря, не разделяю. Бывает что три агрегата по 50 кВт вместе подружим, бывает по 14-16 штук по 2,5 МВт - принципы и оборудование те же самые. Кстати, оффтопиком, на Кубе построена интересная энергосеть - 500 агрегатов по 2 МВт в параллель, вот как считать такую энергетику? :)

[Jackson]

Я разбил тему и перенёс сообщения про мега-электростанции в раздел "отчетность" - вот сюда: http://asutpforum.spb.ru/viewtopic.php?f=8&t=808