Опыт настройки МСЭ и кибербезопасности на промышленных объектах

Привет, Хабр! Меня зовут Артём Чуйков, я инженер компании Innostage — первого кибериспытанного интегратора сервисов и решений в области цифровой безопасности. Я занимаюсь внедрением межсетевых экранов на промышленных предприятиях, и сегодня хочу поделиться практическим опытом.

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

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

Именно поэтому внедрение систем обеспечения информационной безопасности позволяет эффективно противостоять подобным угрозам.

Для объектов критической информационной инфраструктуры внедрение СОИБ является не просто рекомендацией, а требованием регуляторов — ФСТЭК, ФСБ, а также стандартов, таких как ГОСТ Р ИСО/МЭК 27001 и других.

Межсетевой экран — одна из ключевых составляющих комплекса сетевой безопасности. Он используется для фильтрации трафика и обнаружения вторжений в сети предприятия. Грамотная настройка МСЭ позволяет своевременно выявлять и предотвращать атаки киберзлоумышленников.

Сегодня я расскажу об общих подходах к настройке межсетевых экранов и о том, как эти подходы иногда выглядят в реальных условиях эксплуатации.

Харденинг МСЭ. Обезопась сам МСЭ

Ваша организация приняла решение внедрить межсетевой экран. Вот он — полностью ваш, новенький и блестящий, лежит в коробке (а лучше — два) и ждёт распаковки и внедрения в промышленную эксплуатацию. Пока он выключен, то, безусловно, защищён от хакеров. Но давайте попробуем обеспечить ему защиту и после включения, а главное — после подключения к сети.

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

Некоторое время назад я слышал легенду о том, что сети АСУ ТП безопасны, поскольку отделены от корпоративной сети и Интернета так называемым воздушным зазором. Это опасное заблуждение. Люди склонны проявлять удивительную изобретательность, когда речь заходит о нарушении запретов и ограничений доступа в Интернет.

Особенно опасно, когда эта изобретательность усиливается инженерной мыслью специалиста по АСУ ТП. Я лично видел ноутбук, который одним интерфейсом был подключён к сети АСУ ТП, а по Wi-Fi — к телефону с доступом в Интернет. Чтобы минимизировать подобные риски, первый шаг всегда начинается с надёжной базы — а именно с корректного состояния самого межсетевого экрана.

Шаг первый. Мы заливаем на наш МСЭ последнюю стабильную прошивку (а не последнюю по порядковому номеру). Данные о стабильности прошивки можно получить, изучая тематические чаты, где коллеги могут бесплатно делиться наработанным опытом. Некоторые из таких чатов очень даже полезны. В актуальных прошивках помимо добавления полезных фич и удаления бесполезных багов применяются исправления известных уязвимостей, что затрудняет их злодейскую эксплуатацию.

Шаг второй. Отключаем всё ненужное, устаревшее и неиспользуемое. Например, HTTP, Telnet, SNMP v1 -v2. Если всё-таки использование небезопасных сервисов необходимо, ограничиваем доступ к ним только с определённых ресурсов, а в SNMP меняем идентификатор (community), установленный по умолчанию.

Как-то мне задали вопрос: «А как отследить, были ли попытки подключения по telnet?» Оставим за кадром, с какой целью это требуется: раз спросили — значит, надо.

Telnet не только не был включён на том устройстве, но и в принципе им не поддерживался. Я создал запрещающее правило на МСЭ для TCP-порта 23 и включил логирование — после этого попытки подключения стали фиксироваться.

Шаг третий. Ограничиваем доступ к интерфейсу управления: «только с определённых источников». Ни в коем случае не должно быть никакого доступа из Сети.

Итак, лишние сервисы мы отключили, небезопасные и устаревшие протоколы шифрования выключили. На очереди — парольная защита. Пароли, это, конечно, хорошо, но гораздо безопаснее аутентификация по ключам/сертификатам. Если есть возможность использовать второй фактор, обязательно надо использовать.

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

Учётные записи рекомендую делать персональными, однозначно идентифицируемыми — чтобы было понятно, что это именно Иванов И.И. После передачи доступа от подрядчика необходимо менять все пароли.

По моему мнению, использование централизованной аутентификации, при всём её удобстве, несёт в себе потенциальную уязвимость. Компрометация центрального хранилища учётных данных может привести к компрометации всех устройств в сети. В этом вопросе необходимо искать баланс между безопасностью и управляемостью.

Приведу пример. Во времена, когда зарубежные компании ещё работали здесь, волевым решением «сверху» были созданы учётные записи с повышенными привилегиями и сроком действия пароля 12 часов. Пароль должен был содержать не менее 12 символов, включая цифры, буквы и специальные символы. С одной стороны — безопасно, с другой — администратор физически не может запомнить все пароли. В результате пароль фотографировался на телефон, писались самописные скрипты для его автоматического ввода и так далее. В итоге формальное усиление защиты привело к появлению новых потенциальных угроз компрометации.

Напоминаю, что обеспечение безопасности, — это системное мероприятие, как правило, у заказчиков есть SIEM, туда мы направляем логи с наших МСЭ. Если SIEM нет, можем установить. Время синхронизируем с NTP сервером заказчика.

Был случай, когда о том, что один из кластеров МСЭ вышел из строя, мы узнали совершенно случайно. Ноду заменили по гарантии — всё закончилось благополучно.

Необходимо регулярно выполнять резервное копирование конфигураций — именно это и помогло нам восстановить вышедшую из строя ноду. Также требуется контролировать целостность файлов на самом МСЭ: не внесли ли злоумышленники изменения в критически важные файлы?

Вроде бы всё сделали правильно: обновились, доступы ограничили, резервные копии настроили, целостность контролируем. И вот в этот момент обычно возникает ощущение, что система полностью защищена.

Но на практике часто забывают о протоколе IPv6. На IPv4 всё корректно отключено и отфильтровано, а IPv6 остаётся без внимания. При этом локальные адреса канала назначаются автоматически, и протокол продолжает функционировать.

Иногда меня просят полностью отключить IPv6 на МСЭ. Однако даже если я отключу его на межсетевом экране, на других устройствах сети он никуда не исчезнет. Поэтому на уровне ядра операционной системы я оставляю IPv6 включённым, но однозначно запрещаю сетевое взаимодействие по этому протоколу средствами МСЭ и передаю соответствующие логи в SIEM — возможно, они будут использованы в корреляционных правилах.

В зависимости от используемого оборудования можно дополнительно настроить защиту от DoS-атак, ограничить доступ к самому МСЭ средствами встроенного сетевого экрана и реализовать другие механизмы защиты. В конечном счёте безопасность устройства — в ваших руках.

Подключаем МСЭ к АСУ ТП

Рассуждая об обеспечении кибербезопасности промышленного объекта, мы неизбежно касаемся темы АСУ ТП. АСУ ТП — это Автоматизированная Система управления Технологическим процессом. При помощи СОИБ мы будем зачищать именно эту систему. Классическая схема построения АСУ ТП содержит три уровня:

1. Нижний уровень (Полевой уровень / Field Level):

• Компоненты: датчики (сенсоры), измерительные преобразователи, исполнительные механизмы (клапаны, двигатели, приводы).

• Функции: непосредственное взаимодействие с технологическим процессом, сбор первичных данных, преобразование физических величин в сигналы, выполнение команд управления.

2. Средний уровень (Контроллерный уровень / Control Level):

• Компоненты: программируемые логические контроллеры (ПЛК / PLC), модули ввода-вывода, промышленные сети.

• Функции: обработка данных, полученных с нижнего уровня, реализация алгоритмов управления, выдача управляющих воздействий на исполнительные механизмы.

3. Верхний уровень (Уровень операторского управления / Supervisory Level):

• Компоненты: человеко-машинный интерфейс (HMI), рабочие станции операторов (АРМ), серверы, системы SCADA.

• Функции: визуализация технологического процесса, диспетчерское управление, архивирование данных, формирование отчётов, сигнализация аварийных ситуаций. 

АСУ ТП не любит простоев и сбоев в работе. Поэтому все ключевые узлы и элементы дублируются, резервируется и локальная сеть. Чувствительность АСУ ТП к перебоям в работе сети, высокая стоимость ошибок приводят к тому, что локальная сеть вместе со всем оборудованием может быть просто продублирована.

Пример. PRP (Parallel Redundancy Protocol — протокол параллельного резервирования) — это сетевой протокол (стандарт IEC 62439-3), обеспечивающий бесшовное резервирование Ethernet-сетей с нулевым временем восстановления. Он дублирует пакеты и передаёт их одновременно через две независимые сети (LAN A и LAN B).

В зависимости от построения резервирования сетей АСУ ТП появляются нюансы для внедрения МСЭ; МСЭ отделяют уровень Котроллеров (ПЛК) от верхнего уровня; SCADA и Уровень SCADA от Сети предприятия.

АСУ ТП консервативна, часто встречаются плоские сети, представляющее собой единый широковещательный домен. Внесение изменений в существующую схему включения крайне затруднительны, но возможны следующие варианты подключения МСЭ:

1. Мониторинг трафика – на межсетевой кран отправляется зеркалированный (mirroring, SPAN) трафик c порта коммутатора, в такой конфигурации осуществляется анализ трафика, например, системой обнаружения вторжений.

2. Мостовые схемы включения (L2). При использовании мостовой схемы включения возможна фильтрация трафика средствами межсетевого экрана без внесения изменений в существующую плоскую сеть широковещательного домена. Требуется решить проблему отказоустойчивости. Как я уже говорил, если в сети АСУ ТП используется полное резервирование второй локальной сети, можно поставить 2 МСЭ, по одному на каждую сеть и синхронизировать конфигурации между ними.

Так же возможно использование МСЭ, как прокси-сервера. Экзотическое решение, больше подходит для корпоративных, а не технологических сетей. 

На втором уровне можно использовать различные схемы резервирования, в том числе и STP, но требуется поддержка со стороны самого МСЭ. А это всё-таки L3 устройство, и подобное использование скорее компромисс, чем ультимативное решение.

Перейдём к использованию МСЭ на уровне L3. Прежде всего, межсетевой экран необходимо подключить к коммутатору. Мы используем схему двухканального шлюза, dual-homed, с подключением к стеку коммутаторов.

МСЭ может быть подключён как в отдельные access порты коммутатора, так и собрана схема router-on-stick «маршрутизатор на одной ножке» .В этом режиме через него уже будет маршрутизироваться трафик. Мы можем включить его в ядро сети, терминировав на нём VLAN, можем использовать как шлюз для передачи трафика из ядра сети, как нам подскажет фантазия, производственная необходимость и требования регулятора. Маршруты мы можем раздавать динамически, прописывать статически. Благо, что многие современные МСЭ имеют функционал маршрутизатора.

Снова приведу пример из собственной практики. Я приехал на объект, и уже на месте выяснилось, что для взаимодействия с сетью предприятия используется OSPF. Других деталей на тот момент не было. «Ну что же, сейчас настроим», — говорю я. Мне передают параметры: area 0, stub. И здесь выясняется, что версия ПО на МСЭ не умеет stub, OSPF – без проблем, stub нет. Пришлось согласовывать и перезаливать ПО на более свежую, но не факт, что более стабильную версию. Кое-как успел до конца командировки.

И, конечно же, нам надо резервировать наш МСЭ. Для резервирования используем что-то из семейства NHRP (Next Hop Resolution Protocols — протокол определения следующего перехода) , например, VRRP и синхронизацию конфигураций Как правило, используем режим кластера Active-Passive — активный-пассивный. В этом режиме трафик идёт через активную ноду, в случае необходимости переключается на резервную.

Мы настроили маршрутизацию, пустили трафик через МСЭ по правилу Any-Any, которое разрешает прохождение любого трафика (далее Any-Any). Все системы заработали, выключаем! Теперь настраиваем правила файрвола. Включаем логирование. Никаких широких правил, вида Источник — Назначение – все порты. И уж тем более Any-Any.

Хорошо, от нас данные вылетели, пока что между ПЛК и Scada. Так как файрволы контролируют состояния, то в рамках открытых сессий трафик возвращается обратно. Сессии мы также синхронизируем между МСЭ. Иначе неудобно выйдет, если при переключении связь оборвётся и придётся заново всё переподключать.

Я недавно с удивлением узнал, что сессии на файрволах создаются для протоколов UDP и ICMP на основе таймаутов, чтобы получать ответный трафик. Век живи, век учись.

Но если требуется доступ из защищаемого сегмента? А как быть, если необходимо предоставить доступ к ресурсу внутри АСУ ТП?

Никаких прямых взаимодействий с защищаемым сегментом быть не должно, только с использованием промежуточных серверов, расположенных в сегменте DMZ:

DMZ (Демилитаризованная зона) — это изолированный сегмент компьютерной сети, размещённый между локальной сетью (в нашем случае АСУ ТП) и внешней сетью (в нашем случае коммерческая сеть передачи данных, система MES). DMZ содержит общедоступные сервисы (в случае с АСУ ТП это, например, OPC DA шлюз.), обеспечивая доступ к ним снаружи, но при этом изолирует их от внутренних, чувствительных данных, защищая сеть от атак. Все взаимодействия системой АСУ ТП проводим через серверы DMZ, подключённые к МСЭ на границе АСУ ТП и КСПД. Желательно, чтобы это были отдельные МСЭ и другого производителя, отличного от установленного на границе SCADA – ПЛК. Правила взаимодействия между серверами DMZ и защищаемым сегментов и DMZ и внешней сетью также должны создаваться по принципу минимально необходимого.

Итак, правила настроили, DMZ создали, включаем систему обнаружения вторжений.

СОВ также желательно настроить точечно, только проверку необходимых сервисов на необходимых интерфейсах.

Многие МСЭ поддерживанию глубокую инспекцию промышленных протоколов, информируя о нежелательных действиях или блокируя их. Например, можно запретить команду остановки устройства, если команда поступает из внешней сети.

 

Как пройти приёмо-сдаточные испытания и не сойти с ума?

Не знаю, мне это ещё не удалось.

А если серьёзно, то ПСИ – это очень ответственное мероприятие, к котором необходимо подходить со всей ответственностью. Как правило, сдача происходит в присутствии комиссии, задаются вопросы, выходящие далеко за рамки программы методики испытаний. Однажды я сдавал МСЭ заказчику 4 часа. Бывает, что комиссия обнаруживает недоработки, которые не были предусмотрены в техническом задании. Если они возможны, то мы идём на встречу и стараемся их устранить. Если это технически невозможно, обязательно пишется запрос вендору и ждём, что будет устранено в следующем релизе.

Мои любимые моменты из ПСИ:

1. Блокировка учётной записи администратора по перебору пароля. Всё, успешно, заблокировалось. А теперь ждём 10 минут, пока блокировка слетит.

2. Отключение сессии по бездействию. Здесь мы просто сидим и ждём, пока отвалится сессия.

3. Люблю просканировать МСЭ nmap и показать сработки СОВ.

4. Ну и, конечно же, отказоустойчивость. Давайте выдернем все провода из ведущей ноды? А давайте. Работает, трафик идёт. Втыкаем обратно – трафик возвращается на ведущую ноду, всё хорошо. Супер, тогда дёргаем с неё питание…

Один раз нода не вернулась из ребута по питанию… И, слава богу, это были заводские испытания в большом транспортно-доступном городе, а не где-нибудь на объекте, куда доехать можно только на оленях, да и то после того, как снег ляжет. С той нодой всё хорошо, уехала по гарантии и вернулась.

Как бы то ни было, спасибо принимающим, они подсвечивают ошибки, которые были допущены по невнимательности. Не позволяют пропасть труду по обеспечению кибербезопасности из-за ошибок и опечаток.

 

Заключение

Я кратко рассказал о нашей практике в сфере обеспечения кибербезопасности промышленных систем. Безусловно, многое осталось за кадром. Каждая внедрённая система, каждый объект и каждый инцидент заслуживают отдельного разговора.

Главная мысль, которую мне хотелось донести: безопасность — это не разовая настройка и не «галочка» в отчёте. Это процесс, который требует внимания к деталям, здравого смысла и постоянного контроля. Даже самые современные средства защиты не работают сами по себе, они эффективны только при грамотной эксплуатации.

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