Встраивание сервиса VPN в операционные системы BSD UNIX

© Панасенко Сергей, 2002.

В предыдущей статье были рассмотрены способы встраивания подсистемы VPN в операционные системы Windows NT/2000. В продолжение данной темы – описание возможностей реализации VPN для UNIX-систем.

Операционные системы семейства Microsoft Windows не предоставляют понятных и хорошо документированных способов перехвата сетевого трафика. В данном смысле встраивать какую-либо дополнительную функциональность в UNIX-системы существенно проще: во-первых, многие из них поставляются в исходных кодах на языке С, что позволяет квалифицированным программистам обходиться вообще без документации; во-вторых, они сопровождаются электронным справочником man, содержащим подробное описание как системных вызовов и библиотечных функций ОС, так и прикладных утилит. Причем, в отличие от встроенной в Windows справочной информации, которая ориентирована на пользователя, справочник man предоставляет все, что необходимо именно разработчику.
Рассмотрим операционные системы семейства BSD UNIX, абсолютное большинство из которых поставляются с исходными текстами ядра.

Последовательность действий сетевых модулей BSD UNIX при отправке информации в сеть (см. рис. 1) такова:

• При активизации системного вызова send или write информация помещается в буфер передачи указанного в вызове сокета. Буфер передачи сокета представляет собой набор специальных буферных структур mbuf, упорядоченных в виде связанного списка (см. рис. 2). Информация записывается в один или несколько создаваемых и добавляемых к списку mbuf.
• Производится вызов модуля, реализующего протокол транспортного уровня (скажем, TCP). Конкретный протокол выбирается, исходя из информации о протоколе, содержащейся в структуре socket.
• По мере необходимости (как известно, TCP-модуль может вносить технологические задержки в отправку данных) активизируется IP-модуль путем вызова функции ip_output.
• IP-модуль выбирает необходимый маршрут из таблицы маршрутизации (или использует маршрут, указанный в вызове ip_output), по которому определяется конкретный сетевой интерфейс.
• Сетевой интерфейс выполняет отправку пакета.

Несомненно, есть много общего в реализации стека TCP/IP в различных операционных системах, поскольку поведение сетевых модулей должно соответствовать достаточно определенным стандартам. Однако, принципиальное отличие UNIX-систем от Windows состоит в том, что работа сетевой подсистемы здесь более прозрачна. Довольно легко проследить процесс обработки конкретных данных и постепенное "наслаивание" на них пакетных заголовков различных уровней стека "сверху-вниз". Соответственно, несравнимо проще найти наиболее удобные точки перехвата сетевого трафика.

Перехват данных можно осуществлять практически на любом уровне стека TCP/IP:

• На уровне сетевого интерфейса. Например, возможно модифицировать входящий в поставку ОС FreeBSD драйвер для NE2000-совместимых сетевых карт, внеся в него прозрачное шифрование всех проходящих данных. Ничто не мешает поместить шифрование и на аппаратный уровень, совместив таким образом сетевой адаптер и устройство шифрования. Кроме того, на базе этого "гибрида" возможно также осуществление аппаратной защиты от несанкционированного доступа и контроля целостности системных файлов до загрузки ОС. Такой подход обеспечивает наибольшую безопасность системы в целом. Однако, основным его недостатком является привязка VPN-функций к определенному типу или семейству сетевых адаптеров.
• На межсетевом уровне. По всей видимости, это наиболее удобное решение, которое позволяет, с одной стороны, совершенно не зависеть от конкретного сетевого интерфейса; с другой стороны, автоматически позволит шифровать данные для всех протоколов транспортного уровня. Причем, имея возможность анализа номера протокола верхнего уровня, можно пропускать без шифрования информацию выбранных протоколов, например, ICMP, для которого шифрование менее актуально. На данном уровне наиболее удобно и фильтровать трафик, исходя из выбранной политики безопасности.
• На транспортном уровне. Внедрение защиты, например, в TCP-модуль несомненно является менее универсальным решением, но, на первый взгляд, более простым в реализации. То же самое относится и к уровню приложений: внедрение защиты в демоны и клиенты telnet или ftp сузит ее использование; это вполне возможно технически, но вряд ли обоснованно.

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

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

• Анализируются правила политики безопасности. По входным данным (адреса отправителя и получателя, номер протокола транспортного уровня и т.д.) выбираются ключи шифрования и ЭЦП (вместо ЭЦП может использоваться имитовставка или просто CRC; кстати, IPSec допускает использование нескольких различных алгоритмов шифрования/контроля целостности, выбор конкретного из них должен производиться здесь же).
• IP-пакет шифруется и подписывается. Если используется инкапсуляция IP-пакетов (что особенно актуально для маршрутизаторов с функциональностью VPN для сокрытия топологии защищаемой сети), пакет шифруется полностью, после чего формируется новый заголовок. В противном случае шифруется только поле данных пакета.
• При превышении MTU и отсутствии флага DF производится фрагментация пакета и его отправка частями.

Конкретная реализация зависит от задач, для решения которых разрабатывается VPN-модуль. Существует масса спорных вопросов обработки IP-пакетов, например:

• менять ли значение поля Protocol отправляемого пакета на собственное, зарезервированное для защищенных пакетов, что потенциально ускорит разбор пакетов при приеме, но усложнит фильтрацию по протоколам транспортного уровня;
• фрагментировать ли пакет при превышении MTU, игнорируя флаг DF (что, в частности, сделает невозможной реализацию алгоритма Path MTU Discovery при шифровании ICMP-пакетов).

Автору известны реализации VPN-модулей с прямо противоположным поведением в таких случаях.

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

Поскольку BSD UNIX имеет в своем составе firewall ipfw, предоставляющий широкие возможности фильрации IP-пакетов, при встраивании в функции ip_output и ip_input достаточно реализовать шифрование и контроль целостности данных, положившись в части фильтрации на ipfw. Однако, выше описана только методика перехвата сетевого трафика, для реализации полноценного VPN-модуля придется сделать еще, как минимум, следующее:

• Программный шифратор или драйвер к устройству шифрования.
• Модуль, реализующий алгоритм контроля целостности.
• Утилиту администрирования политики безопасности.

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

1. Робачевский А. Операционная система UNIX. – Санкт-Петербург, БХВ. – 1997.
2. Мамаев М., Петренко С. Технологии защиты информации в Интернете. – Санкт-Петербург, Питер. – 2002.
3. www.freebsd.org.ru/security.

Названия рисунков:
1. Обработка данных сетевыми модулями BSD UNIX.
2. Структуры буферов сокета.

Перейти на главную страницу Карта сайта Список статей