Построение демилитаризованной зоны DMZ в системах АСУ ТП с помощью протоколов Modbus и МЭК-60870-5-104

    Всем здравствуйте! Статься предназначена для специалистов в области АСУ ТП. Остальным она может оказаться непонятной из-за обилия специфических терминов.

    Как правило в АСУ ТП реализация демилитаризованной зоны выглядит следующим образом:

    image

    В сети №1 есть OPC-сервер от которого должен получать данные OPC-клиент в сети №2. Есть сервер DMZ. Firewall 1 разрешает только соединения из сети 1, остальные соединения запрещает. Firewall 2 разрешает только соединения из сети 2, остальные соединения запрещает. Передача по стандарту OPC DA в таких условиях невозможна.

    Какие стандартные протоколы обмена есть в АСУ ТП? Конечно же первым на ум приходит Modbus. Для TCP/IP есть Modbus TCP. Ещё есть режим Modbus-RTU поверх TCP/IP: те же самые пакеты, которые проходят по RS-485 передаются по TCP/IP. Режим Modbus-RTU поверх TCP/IP стал стандартом де-факто, но остался нестандартным де-юре.

    Определимся с терминами:

    • Modbus-Slave – программа, которая отдаёт данные по протоколу Modbus
    • Modbus-Master — программа, которая принимает данные от Slave по протоколу Modbus

    Итак, рассмотрим такую схему:

    image

    В сети №1 «преобразователь ОРС в Modbus TCP» является Modbus-slave, он получает данные от ОРС-сервера. «Преобразователь ОРС в Modbus TCP» сам устанавливает ТСР соединение с ОРС-сервером Modbus TCP (Modbus-Master) в DMZ (в нем есть режим пассивного ожидания соединений), преобразователь ОРС в Modbus TCP (Modbus-slave) в демилитаризованной зоне получает данные от ОРС-сервера. ОРС-сервер Modbus TCP (Modbus-Master) в сети 2 устанавливает соединение с «Преобразователем ОРС в Modbus TCP» в DMZ и передает данные ОРС-клиенту.

    В этой схеме нестандартно то, что «преобразователь ОРС в Modbus TCP», являясь Modbus-slave, сам устанавливает соединение с Modbus-Master. Именно для этого и потребовалось написать свой преобразователь.

    Упростим схему:

    image

    Для сервера демилитаризованной зоны создадим простую программу с условным названием TCP connections Convertor. Она открывает 2 ТСР порта. Из сети №1 «преобразователь ОРС в Modbus TCP» устанавливает соединение с ней по порту 1000, ОРС-сервер Modbus TCP устанавливает соединение с ней по порту 1001. Пакет, приходящий на порт 1000, отсылается клиенту, подсоединенному к порту 1001. Пакет, приходящий на порт 1001, отсылается клиенту, подсоединенному к порту 1000.

    Можно сказать, что потенциальный злоумышленник может взломать «преобразователь ОРС в Modbus TCP», посылая ему нехорошие пакеты. Тогда в TCP connections Convertor можно ввести запрет в подключении к нему с неизвестных IP-адресов, ввести контроль длины пакетов и проверять пакеты на соответствие стандарту Modbus TCP.

    Теперь перейдем к МЭК-60870-5-104. Этот протокол более совершенен по сравнению с Modbus. С помощью него можно пересылать достоверности сигналов и метки времени. Так же стандарт МЭК-60870-5-104 поддерживает режим, когда Slave устанавливает соединение с Master.

    Master по стандарту называется контролирующей станцией, Slave называется контролируемой станцией.

    Перерисуем схему:

    image

    Повторим описание: В сети №1 «преобразователь ОРС в МЭК-104» является slave, он получает данные от ОРС-сервера. «Преобразователь ОРС в МЭК-104» сам устанавливает ТСР соединение с ОРС-сервером МЭК-104 (Master) в DMZ, преобразователь ОРС в МЭК-104 (slave) в демилитаризованной зоне получает данные от ОРС-сервера МЭК-104. ОРС-сервер МЭК-104 (Master) в сети 2 устанавливает соединение с «Преобразователем ОРС в МЭК-104» в DMZ и передает данные ОРС-клиенту.

    Опять же эту схему можно упростить с помощью программы TCP connections Convertor. Ещё одна идея!

    image

    С появлением беспроводных GSM/GPRS-модемов, обеспечивающих передачу данных в сети по стеку протоколов TCP/IP стало удобно организовывать каналы связи с удаленными объектами. Однако не всегда удаётся получить статический IP-адрес для GSM/GPRS-модема. В таком случае статический IP-адрес присваивается серверу. GSM/GPRS-модем устанавливает соединение с сервером, на сервер устанавливается программа TCP connections Convertor. ОРС-сервер отправляет запрос к серверу на порт 1000, GSM/GPRS-модем, подключенный к порту 1001 принимает этот пакет, передает его счетчику, счетчик отвечает, GSM/GPRS-модем передает ответ серверу на порт 1001, сервер через порт 1000 отдает ответ ОРС-серверу. ОРС-сервер «думает», что общается со счетчиком напрямую, компьютер с ОРС-сервером оказывается изолированным от внешней сети (интернета).

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 314 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 16

      0
      Так же стандарт МЭК-60870-5-104 поддерживает режим, когда Slave устанавливает соединение с Master.

      А можно ссылку на пункт стандарта?
        0

        7.1 Инициализация станции
        Установление соединения проводится:
        ...


        • фиксированным выбором (параметром) — в случае двух эквивалентных контролирующих станций или партнеров (см. рисунок 1).
          0
          По моему мнению это не то.
          0
          Да-да, мне тоже интересно про это!
          0
          По последнему рисунку: Россети запрещают (по крайней мере на своих объектах) передачу по воздуху для АСУ ТП.

          По передаче ОРС DA… выкиньте его и используйте UA.
            0
            Помимо Россетей есть еще много других организаций.
            В ОРС UA сервер может устанавливать соединение с клиентом?
            0
            Передача по стандарту OPC DA в таких условиях невозможна.
            Чем не угодил OPC Tunneller? Или OPC шлюз?
              0
              В статье как раз и описывается OPC шлюз.
              0
              в opc da есть асинхронный режим когда клиент оформляет подписку на элементы opc сервера. И когда значения этих элементов меняются, то opc сервер сам посылает клиенты уведомление.

              этот режим как-то будет поддерживаться у вас?
              0
              интересно.
              то есть ваш прокси это в итоге настоящий opc сервер внутри локальной сети OPC-клиента (самый правый на картинках), который:
              1. содержит все те же элементы, что и удаленный opc сервер
              2. поддерживает все интерфейсы и операции, которые поддерживает удаленный opc сервер
              3. вызов операции — в итоге приводит к вызову операции на удаленном opc сервере
              я правильно понял?
                0
                Нет.
                OPC-клиент получает те же аналоговые и дискретные значения (или часть их), которые есть в OPC-сервере.
                +1
                Преобразовать OPC DA во что нибудь, чтобы передать через защиту, или куда то далеко-далеко, на той стороне снова прикинуться ОРС-сервером, чтобы СКАДА ничего не поняла — ну это задача понятная, уже есть и решения по этой теме.
                В вашей реализации непонятно другое — зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Зачем нужно такое двойное преобразование? Просто потому что это проще всего реализовать? Но при этом теряется куча функциональности в изначальном ОРС — разные типы значений, временные метки, признаки качества, дата-коллбеки по изменению параметров. Конечно можно выпендриться и придумать формат передачи всего этого и через самопальный Модбас, но это будет жесть, никакому нормальному инженеру АСУТП такая система в работе не нужна, и еще офигенная сложность в настройке.
                Использование в этом плане в промежутке протокола МЭК-104 — уже гораздо лучше, понятнее. И мы подобные вещи тоже делали на базе своего ПО, когда надо было передать телеметрию вдаль, и там принять в ОРС в Скаде, которая не знает МЭК-104.
                Но главный вопрос, который мне непонятен совершенно — зачем двойное преобразование информации в середине? Зачем в середине делать преобразование из МЭК в ОРС, а потом снова из ОРС в МЭК? Чего бы полученный из сети 1 МЭК сразу не передать в сеть 2, без конвертации в ОРС и обратно?
                  0
                  Зачем из ОРС делать Модбас, затем снова из Модбаса делать ОРС? Я за стандартизацию. Вам ещё не надоело объединять в одну систему устройства с разными протоколами обмена?
                  Зачем двойное преобразование информации в середине? Это один из вариантов. Я же писал
                  Опять же эту схему можно упростить с помощью программы TCP connections Convertor.
                  по аналогии с рисунком 3. Не стал разрисовывать для МЭК-104, думал и так понятно будет.
                  0
                  Я не понял из статьи — как «защитить» modbus-протокол?
                    0

                    Ваш вопрос непонятен. В статье даже слова "защита" нет.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое