УДК 004

Архитектурные решения по однонаправленной передаче данных

Грачев Александр Сергеевич – старший преподаватель кафедры КБ-1 «Защита информации» МИРЭА – Российского технологического университета

Федоров Вадим Валерьевич – преподаватель кафедры КБ-1 «Защита информации» МИРЭА – Российского технологического университета

Ершов Никита Сергеевич – преподаватель кафедры КБ-1 «Защита информации» МИРЭА – Российского технологического университета

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

Ключевые слова: однонаправленная передача информации, Компьютерные сети, Протоколы передачи данных, Сетевые устройства, Оптоволоконные кабели, Мосты и шлюзы, Канальный уровень, Физический уровень, TCP-трафик, SYN-запросы, UDP-трафик, VLAN, arp-proxy, модель OSI.

В настоящее время трудно переоценить значимость простых и эффективных мер по обеспечении информационной безопасности в компьютерных сетях и автоматизированных системах. Одним из таких решений является однонаправленный шлюз (диод данных).

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

image001

Рисунок 1. Схема применения однонаправленного шлюза между защищенным и незащищенным сегментами сети (схема точка-точка).

На первом рисунке изображена классическая ситуация с применением однонаправленного шлюза. Ее можно назвать простейшей. Два СВТ соединены через оптическую (или даже витапарную) гальваническую развязку, которая гарантирует однонаправленное прохождение трафика. Без применения специальных программных "заглушек", отвечающие на SYN-запросы, TCP-трафик работать через такую развязку не будет. Возможен проход трафика UDP, для тестирования можно использовать ICMP (например ping request). Чтобы заставить пакеты идти через интерфейс в сторону однонаправленной развязки, необходимо решить задачу на уровне L2 модели OSI, а именно ликвидировать ARP-запросы от передающего хоста. В следующих случаях архитектурного применения диодов мы будем отвечать на такие ARP-запросы, искусственно генерируя ответы. В обычных сетях здорового человека перед тем, как отправить любой пакет до ближайшего шлюза или до хоста в той же подсети (и с той же маской, пример 10.8.0.2/24 и 10.8.0.1/24), инициирующий хост посылает arp-запрос, с целью выяснить мак-адрес получателя. Если ответа за вменяемое время и количество попыток не поступает, то протокол более высокого уровня просто не посылает пакеты получателю.

Для того, чтобы избавиться от ARP-request фреймов, нужно на передающем хосте прописать статическую ARP-запись в таблицу с IP-адресом получателя и (в данном случае желательно, в других последующих обязательно) валидный MAC-адрес сетевой карты принимающего хоста. После этого, протоколы верхнего уровня будут посылать пакеты в требуемый интерфейс в сторону развязки без ARP-запроса. 

image002

Рисунок 2. Схема применения однонаправленного шлюза между защищенным и незащищенным сегментами сети (схема лес-точка).

На рисунке 2 изображена немного усложненная ситуация. Целая сеть из хостов будет иметь возможность однонаправленно отправить информацию через развязку в отдельно стоящий хост. При такой конфигурации мы либо на каждой из передающих машин прописываем статическую arp запись с мак- адресом получателя, либо делаем такую запись на порту коммутатора, который смотрит в сторону однонаправленного шлюза. Явные ограничения первого случая - коммутатор не видит мак-адрес получателя у себя в таблице и рассылает такой по всем портам, создавая в сети (в vlan, в домене широковещания) шторм шириной с величину передаваемого потока. Такое поведение является стандартным для всех коммутаторов от самых дешевых без управления, до весьма дорогих. Пакеты искусственно попадают в сеть. Стоит отметить, что поле TTL в данном случае не будет уменьшатся, т. к. пакеты будут бродить по сети без маршрутизации. Пакет, попадая на входной порт одного коммутатора, попадает на все, кроме входящего. Далее, на следующем коммутаторе ситуация повторяется. Таким образом, в случае попадания через диод потока в 100 Мегабит/секунду, мы увидим эту скорость и эти пакеты на всех портах коммутатора в этом vlan. Ситуация будет иной, если принимающий хост будет иногда посылать в сеть какие-либо пакеты (например, стандартное не «зарезанное» широковещание от ОС windows или linux), за период меньший, чем время жизни mac-записей в таблице коммутатора (во многих моделях cisco стандартное значение 300 секунд). В случае, если такой коммутатор является изолированным от другой сети, то этим относительно можно пренебречь в случае, если трафик, передаваемый через однонаправленную развязку небольшой.

image003

Рисунок 3. Применение однонаправленной оптической развязки в качестве шлюза.

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

  1. На любой arp-запрос, содержащий как destination IP-адрес принимающего хоста, необходимо отправлять arp-ответ. MAC-адрес в этом ответе будет подставлен ближайшего к свитчу сетевого интерфейса eth
  2. После того, как передающий хост начал направлять данные, которые необходимо передать через однонаправленную развязку, эти данные необходимо перенаправить с интерфейса eth0 на интерфейс eth1, в сторону другого сегмента сети, отделенного диодом.
  3. При попадании такого фрейма в другой сегмент, в нем необходимо заменить MAC-адрес получателя на валидный адрес получателя.

 Еще одним способом избавления от лишних запросов является прописание статического маршрута до (и даже как частного случая шлюза по умолчанию), до нашей машины «arp-proxy», разделяя адресное пространство до после развязки на разные подсети.

По сравнению с предыдущим рисунком, мы видим некое дополнительное усложнение схемы. После однонаправленного шлюза у нас не один хост, а целый сегмент, набор хостов, со своим сетевым оборудованием. Если правильно заменить MAC-адрес на валидный, такой трафик будет доставлен через сетевое оборудование, при учете того, что запись есть в arp-таблице коммутатора (-ов). При отсутствии таковой, в сети будет наблюдаться «шторм». Отсутствие записи в таблице может быть в двух случаях:

  1. Хост не посылает никаких пакетов (в т.ч. широковещательных), не общается с другими хостами. Молчит. Зависит от его настроек сетевого стека ОС.
  2. Хост выключен.

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

image004

Рисунок 4. Использование приемного хоста во избежание сетевых штормов сегмента после оптической однонаправленной развязки.

Чтобы не допустить данной ситуации необходимо поступать, как изображено на рисунке 4. На приемной стороне однонаправленной развязки необходимо поставить некий «шлюз», который уже будет распределять нагрузку по потребителям в дальнейшей сети, осуществляя arp-запрос.

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

Следующий случай, когда такие приемные хосты находятся на виртуальном кластере. В таком случае, мало того, что оптическую развязку необходимо помещать в специальный изолированный коммутатор, чтобы этот трафик попадал на все хосты-гипервизоры в кластере, и далее на соответствующие виртуальные машины, необходимо выделить отдельный private vlan (не выходящий за пределы коммутатора) и скомутировать отдельный виртуальный свитч (vSwitch в терминалогии vmware), и соответствующую порт-группу.

Далее рассмотрим оптический шлюз. Стоит понимать, что применимость такого решения может заключаться исключительно в соединении физически изолированных машин. Никаких соединений vlan между одним физическим сегментом. Таким образом, мы создаем, например, т.н. «дружелюбный air gap», т.е. более доверенный сегмент без подключения к сетям общего пользования, с возможностью проброса в него гарантировано без обратного канала свежих версий ПО, обновлений антивируса и прочего.

Заключение

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

Список литературы

  1. Positive Technologies: Актуальные киберугрозы: итоги 2019 года [Электронный ресурс]. – Режим доступа: https://www.ptsecurity.com/ru-ru/research/analytics/cybersecurity-threatscape-2019/. Дата обращения: 15.03.2023.
  2. Positive Technologies: Эксперты Positive Technologies обнаружили уязвимости в программном обеспечении систем видеонаблюдения [Электронный ресурс]. – Режим доступа: https://www.ptsecurity.com/ru-ru/about/news/eksperty-positive-technologies-obnaruzhili-uyazvimosti-v-programmnom-obespechenii-sistem-videonablyudeniya/. Дата обращения: 01.02.2023.
  3. Олифер.В., Олифер.Н.,Компьютерные сети. Принципы, технологии, протоколы.
  4. Доктор Веб: Риски и угрозы в Интернете вещей (IoT) [Электронный ресурс]. – Режим доступа: https://news.drweb.ru/show/?i=13353. Дата обращения: 15.03.2023.
  5. Positive Technologies: Эксперты Positive Technologies составили рейтинг уязвимых IoT-девайсов [Электронный ресурс]. – Режим доступа: https://iot.ru/bezopasnost/eksperty-positive-technologies-sostavili-reyting-uyazvimykh-iot-devaysov. Дата обращения: 12.02.2023.
  6. IXBT: Описание технологии Fast Ethernet [Электронный ресурс]. – Режим доступа: https://www.ixbt.com/comm/tech-fast-ethernet.shtml. Дата обращения 12.03.2023.

Интересная статья? Поделись ей с другими: