Построение надежной защиты с помощью Linux

ОС Linux все чаще рассматривается как жизнеспособная альтернатива решениям в области защиты на базе «закрытых систем».

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

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

Конечно, знание последних новинок в разработке ядра UNIX дает право гордиться собой, но система защиты — не лучший полигон для тестирования всего самого-самого из того, что «народная ОС» имеет честь предложить. Версии ядра Linux представлены двумя различными линиями: разрабатываемой экспериментальной линией с нечетным номером версии во второй позиции (например, 2.1.x) и стабильной рабочей линией с четным номером версии во второй позиции (например, 2.2.х). Новые функции и драйверы обкатываются на экспериментальной версии ядра, из-за чего его поведение оказывается чрезвычайно непредсказуемым.

Я настойчиво рекомендую не использовать экспериментальные ядра Linux на ваших устройствах защиты. Вместе с тем я советую скомпилировать и инсталлировать самую последнюю стабильную версию ядра, как только она появится. В новых версиях выявленные дыры в защите, как правило, устранены, правда, версии, которые вы получаете с дистрибутивом, часто оказываются устаревшими к тому времени, когда они занимают свое место на полке.

В этой статье я постараюсь рассмотреть основные строительные блоки, составляющие полную систему защиты на базе Linux. (О том, как выбрать поставщика Linux, смотри врезку «Чей дистрибутив Linux лучше?».)

ФИЛЬТРАЦИЯ НА СЕТЕВОМ УРОВНЕ

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

Эти правила для ядра системный администратор Linux может определить с помощью утилиты ipchains. Название «chains» указывает, что ядро последовательно проверяет правила, относящиеся к одной цепочке. Синтаксис ipchains краток и интуитивно понятен. Например, если пользователь хочет передавать весь исходящий трафик, а входящий трафик ограничить только SMTP, то он может для этого использовать следующие операторы:

% ipchains -A output -s 132.23.44.0/24 
-I eth0 -j ACCEPT
% ipchains -A input -p TCP 
-dport 25 -I eth0 -j ACCEPT
% ipchains -A output -I eth0 -j DENY
% ipchains -A input -I eth0 -j DENY

Первая строка содержит указание изменить цепочку вывода так, чтобы все пакеты, адреса отправителей которых принадлежат подсети 132.23.44.0 (локальная сеть), направлялись на первый интерфейс (eth0). Вторая строка содержит инструкцию ядру принимать входящий трафик из любого источника (параметр -s отсутствует), если номер порта получателя TCP (-dport) соответствует номеру SMTP (25). Третья и четвертая строки просто провозглашают «установку на отказ», т. е. содержат указание на блокирование всего трафика во всех цепочках, если он не разрешен предыдущими правилами. Я настоятельно рекомендую придерживаться именно такой стратегии.

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

Как и в случае многих других систем, работающих по принципу фильтрации, недостаток ipchains состоит в том, что фильтрация некоторых типов высокоуровневых протоколов (наподобие UDP) оказывается затруднена. Такие протоколы часто требуют «контекстной проверки» таблицы соединений, когда решение о разрешении или отказе транзита пакета принимается исходя из наличия или отсутствия исходящего соединения к запрашивающему хосту.

Заметим, что поддержка ядром ipchains не активизирована по умолчанию, так что ядро придется перекомпилировать с исходного кода, при этом вам надо не забыть указать опцию CONFIG_FIREWALL на этапе make config.

Более подробную информацию о фильтрации пакетов в Linux и ipchains можно найти на http://www.rustcorp.com/linux/ipchains.

NAT: МАСКИРОВКА IP

Ввиду того, что свободное адресное пространство IPv4 постоянно сокращается, получить необходимое количество адресов, чтобы каждый корпоративный хост мог иметь зарегистрированный (т. е. глобально маршрутизируемый) IP-адрес, становится все труднее. Из-за этого администраторы сетей вынуждены присваивать большинству корпоративных хостов зарезервированные адреса и использовать преобразование сетевых адресов (Network Address Translation, NAT) по периметру сети для сохранения возможности доступа к хостам Internet.

Преобразование сетевых адресов в Linux осуществляется с помощью функции ядра, называемой «маскировка IP», посредством которой брандмауэр может преобразовывать несколько внутренних (незарегистрированных) IP-адресов в один внешний (маршрутизируемый) адрес. Механизм для достижения этой цели часто называется «преобразование портов сетевых адресов» (Network Address Port Translation, NAPT).

Брандмауэр на базе Linux действует как маршрутизатор по умолчанию для совокупности внутренних хостов и заменяет адрес отправителя исходящего пакета на свой собственный адрес. Затем в качестве источника транслируемого соединения он присваивает большое значение порта TCP, которое им используется для определения инициировавшего соединение внутреннего хоста.

Чтобы активизировать маскировку IP, при компиляции ядра Linux необходимо выбрать опции CONFIG_IP_FIREWALL и CONFIG_IP_MASQUERADE. После перезагрузки компьютера и загрузки нового ядра вам необходимо подать следующую команду:

% echo ?1? > /proc/sys/net/ipv4/ip_forward

После активизации маскировку IP в Linux можно конфигурировать с помощью уже упоминавшейся утилиты ipchains. Например, если вы выбрали в качестве внутренних адресов подсеть класса С (10.10.10.0/24) и хотите скрыть все ваши адреса при прохождении пакетов через брандмауэр, то вам достаточно подать следующую команду:

% ipchains -A forward -s 10.10.10.0/24 
-j MASQ

Известный недостаток маскировки IP (и NAPT в целом) состоит в невозможности для внешних (Internet) хостов инициировать соединения с внутренними хостами. По этой причине маскировка IP является подходящим решением для клиентских сред, таких, как совокупность ПК на базе Windows, когда им необходим доступ в Web и отправка электронной почты Internet (при этом получение электронной почты осуществляется через сервер POP3). Более подробную информацию о маскировке Linux можно найти на http://ipmasq.cjb.net.

ПОСРЕДНИКИ ДЛЯ ПРИЛОЖЕНИЙ

Часто администраторам сетей требуется более высокая степень контроля доступа, чем способны предложить брандмауэры с фильтрацией пакетов. Отслеживать IP-адреса, которым может быть разрешен доступ в сеть, не всегда возможно, к тому же фильтрация на сетевом уровне не оставляет места для аутентификации пользователей и протоколирования сеансов. В случае же брандмауэра на прикладном уровне администраторы защиты могут указать, каким пользователям разрешено пользоваться данным сетевым сервисом (например, HTTP, SMTP, POP3), вне зависимости от адреса отправителя запроса.

IETF благословила протокол SOCKS в качестве стандарта на посредников запросов через брандмауэры прикладного уровня. При попытке SOCKS-совместимого браузера Web установить соединение с внешним ресурсом сервер SOCKS обрабатывает запрос вместо него и берет на себя функции посредника от имени клиента. SOCKS 5 (RFC 1928, 1929 и 1961) поддерживает мощные средства аутентификации пользователей, а также возможность посредничества для соединений TCP и UDP.

Помимо способности идентифицировать пользователей брандмауэры SOCKS имеют еще одно — менее очевидное — преимущество: ввиду того, что все сетевые запросы подаются от имени клиента proxy-сервером, необходим всего один зарегистрированный IP-адрес. Хотя с технической точки зрения это не NAT, данная возможность оказывается весьма кстати для тех администраторов защиты, которые предпочитают не раскрывать внутренние адреса (даже если они зарегистрированы) всему миру Internet.

Реализация SOCKS 5 от NEC включает свободно доступную и полностью функциональную версию proxy-сервера SOCKS для Linux, а также библиотеки, необходимые для SOCKS-ификации Linux- и Windows-приложений конечных пользователей (http://www.socks.nec.com). Помимо идентификации пользователей SOCKS 5 позволяет администраторам защиты вести подробный учет доступа пользователей в Internet и содержит комплект административных средств для манипулирования и сведения воедино этих журналов.

Ввиду грядущего перехода на IPv6 (хотя это и отдаленная перспектива) пакет NEC SOCKS 5 оказывается бесценным инструментом перехода благодаря своей способности общаться на языке IPv4 с внутренней частной сетью и на языке IPv6 — с Internet. Эта функция преобразования доступна в качестве бесплатной заплаты для стандартного сервера Linux SOCKS 5.

Если вы собираетесь реализовать решение по обеспечению защиты на базе SOCKS 5 для перепродажи, то NEC предлагает для этих целей коммерческий программный пакет инструментов под названием SOCKS 5 Border Control Framework, с помощью которого разработчики продуктов защиты могут создавать готовые аппаратно-программные пакеты SOCKS 5.

Альтернативу SOCKS представляет Trusted Information Systems (TIS) Firewall Toolkit, предшественник коммерческого брандмауэра TIS Gauntlet, теперь предлагаемого Network Associates. Firewall Toolkit (FWTK) включает комплект утилит (и все исходные коды), с помощью которых администратор защиты может создать посредников для любых хорошо известных сервисов TCP (telnet, SMTP, POP3, HTTP и т. д.). В отличие от proxy-сервера SOCKS, посредники FWTK могут быть настроены на произвольные порты, а не обязательно на единственный номер порта TCP (1080), как при посредничестве для соединений через SOCKS. Клиентские приложения должны быть переконфигурированы на использование порта посредника FWTK вместо стандартного номера порта сервиса.

Если SOCKS 5 предлагает более полное решение по организации посредников для приложений, то комплект инструментов TIS оказывается полезной альтернативой в случаях, когда посредничество требуется только для одного сервиса. Кроме того, он оказывается хорошим вариантом и в ситуациях, когда сервис имеет отличающийся от стандартных порт TCP (комплект инструментов содержит посредника общего назначения plug-gw именно для таких приложений). TIS Firewall Toolkit можно получить на http://www.fwtk.org.

WEB PKI: OPENCA, SSL И LDAP

Нет никаких причин не использовать преимущества решения на базе PKI для организации аутентификации и авторизации. Например, если ряду ваших партнеров по бизнесу необходим доступ к Web-серверу Extranet в демилитаризованной зоне компании, то вы можете установить небольшой сервер регистрации (Registration Authority, RA) для приема запросов на подпись сертификатов открытых ключей X.509 и выделить уполномоченного по сертификации (Certification Authority, CA) для обработки запросов и подписания сертификатов.

Сертификаты X.509 поддерживаются браузерами Netscape Navigator и Microsoft Internet Explorer, а бесплатные реализации для Linux имеются для серверов RA, CA и LDAP.

Базирующийся в Европе и, как утверждается, имеющий разработчиков по всему миру, OpenCA Project появился в связи с возникновением потребности в комплекте инструментов с открытыми кодами для быстрого внедрения всех необходимых для PKI элементов.

Первым строительным блоком Web PKI является стандартный браузер Web, с помощью которого пользователи могут запросить сертификат у RA. OpenRA реализован как ряд сценариев CGI, написанных на Perl и размещаемых на защищенном сервере Web. Команда OpenCA выбрала проверенный Web-сервер Apache и добавила к нему поддержку стандартного протокола SSL для обеспечения конфиденциальности запросов сертификатов. Получив запрос на подпись сертификата, RA ставит его в очередь для CA (по соображениям защиты, последний обычно функционирует в автономном режиме). После того как CA подпишет запрос и выдаст сертификат, браузер может еще раз обратиться к RA и загрузить сертификат в локальный кэш браузера.

Американский проект OpenLDAP предоставляет реализацию LDAP, часто используемую RA для хранения сертификатов, которые затем могут быть запрошены субъектами PKI. Дистрибутив OpenLDAP содержит сервер LDAP (основной и тиражируемый), а также набор образцов клиентов и ряд инструментов администрирования.

Но давайте вернемся к проблеме доступа в Extranet. Партнер по бизнесу запросил сертификат у вашего RA, а ваш CA удовлетворил запрос. Теперь ваш партнер может представить этот сертификат вашему защищенному узлу Web и использовать мощные средства аутентификации для доступа к сервисам Extranet, которые вы предлагаете в своей демилитаризованной зоне. Это простое и надежное решение, где используются апробированные технологии (серверы HTTP, сценарии CGI и модули Perl) и стандартизованные протоколы (X.509, SSL и LDAP).

Модули OpenCA и OpenRA можно получить на http://www.openca.org. Сервер OpenLDAP предлагается на http://www.openldap.org. Программное обеспечение Apache и OpenSSL можно загрузить с http://www.apache.org и http://www.openssl.org, соответственно.

ВИРТУАЛЬНЫЕ ЧАСТНЫЕ СЕТИ

Разрабатываемые под эгидой IETF стандарты IPSec (RFC 2401) постепенно превратились в наиболее популярные протоколы обеспечения конфиденциальности и целостности данных в VPN. С помощью входящего в IPSec протокола Encapsulated Security Payload (ESP) большие и малые компании могут использовать Internet для передачи частных данных внутри вложенных и шифруемых пакетов, адреса отправителей и получателей которых совпадают с адресами соответствующих шлюзов.

Проект свободной защищенной глобальной сети (Free Secure Wide Area Network, Free S/WAN) появился как инициатива по созданию полнофункциональной реализации IPSec с открытыми кодами для самых разных целевых архитектур, в том числе ОС Linux. В отличие от продукта Secure Wide Area Network (S/WAN), предлагаемого RSA Data Security, Free S/WAN предоставляется бесплатно, а так как все криптографические разработки осуществляются за пределами Соединенных Штатов, то стандартный дистрибутив содержит также мощные средства шифрования.

Пакет Free S/WAN состоит из двух разных компонентов: модуля для ядра и демона Internet Key Exchange (IKE).

Как и в случае других сервисов защиты, IPSec предполагает поддержку шифрования и инкапсуляции полезной нагрузки пакета на уровне ядра. В стандартные исходные коды Linux необходимо включить модули Free S/WAN и скомпилировать новое ядро.

В соответствии с протоколом IPSec, прежде чем туннель IPSec может быть открыт, два шлюза IPSec должны обменяться идентификационной информацией и согласовать ключи. Согласованная с помощью IKE информация порождает Security Association (SA), где содержатся мандаты туннеля, которые каждая конечная точка хранит о своих коллегах. IKE-демон Free S/WAN реализуется в пользовательском пространстве и использует порт 500 протокола UDP для отправки данных удаленному процессу IPSec и их приема. Без этого демона Free S/WAN не сможет корректно работать.

Основное преимущество решения для VPN на сетевом уровне — его простота; хостам позади шлюза IPSec не требуется ничего знать о нем, и в модификации клиентов нет необходимости. IPSec позволяет защищать любые сервисы, если они используют уровень IP, причем обычно с номинальными накладными расходами, даже при выборе самых мощных средств шифрования данных (3DES) и часто на базе относительно недорогой платформы.

Дистрибутив Free S/WAN IPSec для Linux можно получить на http://www.freeswan.org.

Если вы хотите предоставить удаленным пользователям доступ к шлюзу Linux по VPN, но не хотите устанавливать программное обеспечение IPSec на их портативные компьютеры (и обслуживать его), то считайте, что вам повезло: доступный бесплатно сервер Point-to-Point Tunneling Protocol под названием PopTop действует как конечная точка для сеансов VPN со стандартных настольных систем Windows. Microsoft включила поддержку PPTP VPN в Windows 95/98/NT, кроме того, клиент PPTP имеется даже для клиентов Linux. Стандарт PPTP имеет статус проекта Internet (RFC 2637) и реализован многими коммерческими разработчиками.

Помните, что, хотя с принципиальной точки зрения PPTP абсолютно надежен, реализация PPTP компанией Microsoft имеет несколько очевидных дыр в защите. Прежде чем браться за внедрение этого решения, я бы советовал прочитать сообщение Counterpane Systems на http://www.counterpane.com/pptp-faq.html, а кроме того, учесть, что Microsoft объявила о реализации IPSec в своей новейшей ОС Windows 2000.

Сервер PopTop для Linux можно взять на http://www.moretonbay.com/vpn/pptp.html, а клиент PPTP для Linux имеется на http://www.pdos.lcs.mit.edu/~cananian/Projects/PPTP.

ЗРЕЛАЯ ОС

Linux наконец-то достиг того уровня зрелости, когда эта ОС может рассматриваться в качестве жизнеспособной платформы для организации защиты сети. Решения на базе открытых кодов имеют некоторые хорошо известные недостатки (отсутствие поддержки, хаотическая документация), но Linux компенсирует их продуманной архитектурой, надежным ядром и постоянно растущей поддержкой со стороны разработчиков программного обеспечения, которыми Linux рассматривается в качестве столь необходимой смены ландшафта UNIX.

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

Рамон Дж. Онтаньон — специалист по защите Internet в UUNET, подразделении MCI WorldCom. С ним можно связаться по адресу: hontanon@uu.net.

Чей дистрибутив Linux лучше?

Ресурсы Internet