Сетевой стек ОС «Нейтрино»: встроенная технология data diode

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

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

Что такое диод данных?

Одним из наиболее прямых и в то же время радикальных способов обеспечения надёжности и безопасности системы является её изоляция. Вместо того, чтобы пытаться как-то разграничивать допустимые и недопустимые способы воздействия на систему, с помощью изоляции ряд воздействий можно исключить как класс. В контексте компьютерных сетей изоляция может рассматриваться как один из подходов к организации безопасности сети. Так или иначе, большая часть из них сводится к предотвращению попыток негативным образом повлиять на узлы сети или на сеть в целом. Для этого создают сложные системы фильтрации, DMZ, механизмы аутентификации. Если в сети можно выделить сегмент, не требующий двусторонней коммуникации с внешним миром, то его можно изолировать, полностью отключив возможность передачи данных в одном из направлений. Для этого используется элемент, обеспечивающий однонаправленную передачу, — так называемый диод данных (англ. data diode).

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

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

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

Коротко о сетевой подсистеме ОС «Нейтрино»

Для тех из читателей, кто ещё не знаком с сетевой подсистемой нашей ОС, сделаем небольшое отступление о том, как она устроена.

Центральным элементом сетевой подсистемы является сетевой менеджер io-pkt — работающий в фоне сервис, обеспечивающий работу сетевого API для прикладного ПО. С точки зрения ОС это обычный процесс, работающий в пространстве пользователя (user space networking). Прикладное ПО взаимодействует с сетевым менеджером через библиотеки libc и libsocket, которые в свою очередь используют низкоуровневые механизмы передачи сообщений, обеспечиваемые микроядром ОС. С сетевым оборудованием io-pkt взаимодействует с помощью динамически загружаемых драйверов, представленных в виде разделяемых библиотек (shared objects).

Реализация диода данных на уровне сетевой подсистемы

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

Драйвер в такой схеме является важнейшим уровнем реализации технологии. Однако, не менее важно подходить к вопросу централизованно, учитывая потенциальную масштабируемость и степень доверия конкретному диод-драйверу. В связи с этим было принято решение разработать не только новый класс однонаправленных драйверов, но и отдельный вариант сетевого менеджера — io-pkt-diode. Он загружает только диод-драйверы и не имеет возможности принимать входящие кадры от драйверов — соответствующие интерфейсы представляют собой заглушки. При этом возможность локальной коммуникации сохраняется — loopback-интерфейс работает в нормальном режиме.

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

Пользовательский интерфейс для запуска io-pkt-diode аналогичен интерфейсу обычного io-pkt, с той лишь разницей, что в качестве драйверов он может загружать только диод-драйверы.
Простейшая команда запуска io-pkt-diode с диод-драйвером выглядит так:

io-pkt-diode -d e1000-diode

В данном случае загружается диод-драйвер devnp-e1000-diode.so — адаптация драйвера devnp-e1000.so для работы в однонаправленном режиме.

Разработчикам ПО для ОС «Нейтрино» будет доступна возможность создания собственных диод-драйверов, реализующих однонаправленность для конкретного железа. Раздел о разработке диод-драйверов появится в Руководстве разработчика, но, учитывая чувствительность данной технологии и возможность недобросовестного её применения, рекомендуем обращаться за поддержкой в надёжном преобразовании обычных драйверов в диоды.

Разницу в поведении io-pkt и io-pkt-diode можно увидеть на системной трассе. По диаграмме, сформированной утилитой TraceKev, видно, что при попытке двусторонней передачи через диод данных RX-прерывания сетевого контроллера не срабатывают.

Работа в условиях однонаправленности

При однонаправленной передаче через диод данных на сетевое ПО накладывается ряд ограничений. В частности, отсутствует возможность узнавать MAC-адреса с помощью ARP. При попытке передачи данных на хост, MAC-адрес которого неизвестен, io-pkt-diode отправит ARP-запрос, но не сможет получить ответ.
На хосте-получателе tcpdump покажет примерно следующее:

11:04:49.613094 ARP, Request who-has 192.0.2.2 tell 192.0.2.1, length 46
11:04:49.613094 ARP, Reply 192.0.2.2 is-at 00:00:5e:00:53:02 (oui IANA), length 28

при этом по выводу команды arp -a на хосте с io-pkt-diode будет видно, что ответ не был получен:

? (192.0.2.2) at (incomplete) on wm0

Поэтому для отправки данных по IP требуется предварительная настройка ARP-таблицы, например, с помощью упомянутой утилиты arp. К примеру, если требуется отправлять данные на хост с IP-адресом 192.0.2.2 и MAC-адресом 00:00:5E:00:53:02, соответствующая команда для настройки ARP-таблицы будет выглядеть следующим образом:

arp -s 192.0.2.2 00:00:5e:00:53:02

Может возникнуть вопрос: зачем же тогда io-pkt-diode отправляет ARP-запросы, если он не в состоянии получить ответ? Один из вариантов использования такого поведения — сбор информации о запросах с последующей конфигурацией ARP-таблиц на соответствующих узлах через выделенный канал управления.

Помимо ARP, не представляется возможным использование и других протоколов, предполагающих двустороннюю передачу данных (таких как TCP, DNS, DHCP, Qnet). Программы, использующие эти протоколы, либо не смогут установить соединение, либо, если протокол не подразумевает установку соединения, никогда не дождутся ответа, как это уже было показано на примере ARP. Один из основных доступных вариантов — односторонняя передача по UDP, например отправка сообщений syslog (RFC 5426). Организовать передачу по UDP с хоста под управлением ОС «Нейтрино» можно тем же образом, что и на любой другой Unix-подобной системе:

int sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock == -1) {
    // error
}

int ret = connect(sock, addr, addr_size);
if (ret == -1) {
    // error
}

ssize_t bytes_sent = send(sock, buffer, bytes_to_send, 0);
if (bytes_sent == -1) {
    // error
}

Со стороны получателя так же не требуется ничего особенного:

int sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock == -1) {
    // error
}

int ret = bind(sock, addr, addr_size);
if (ret == -1) {
    // error
}

ssize_t bytes_received = recv(sock, buffer, buffer_size, 0);
if (bytes_received == -1) {
    // error
}

Часть POSIX API, связанная с сетевым взаимодействием, у нас вынесена в библиотеку libsocket, поэтому необходимо указать её на этапе компоновки программы.

Заключение

В следующем релизе ОС «Нейтрино» появится поддержка data diode — полезной технологии для информационной изоляции сетевых коммуникаций, позволяющей гарантировать однонаправленное движение трафика. Поддержка реализована на уровне сетевой подсистемы, в виде однонаправленного сетевого менеджера io-pkt-diode и специализированного диод-драйвера devnp-e1000-diode.so, соответствующего драйверу devnp-e1000.so. Также в Руководстве разработчика появится раздел о разработке своих диод-драйверов.

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

Телеграм-канал, в котором публикуются последние новости разработки нашей ОС