Информационная безопасность
Пример реализации защищенного беспроводного соединения
Рассмотрим организацию защищенного соединения для наиболее типичной, в силу своей гибкости, конфигурации: имеется локальная сеть с выделенным сервером под управлением ОС FreeBSD (ветка 5.X) и всем необходимым для беспроводных клиентских подключений оборудованием — точка доступа, коммутатор и т. д. В качестве клиентов в данном случае подразумеваем портативные компьютеры, снабженные беспроводными сетевыми адаптерами и работающие под ОС Windows XP.
Клиентам выделяется динамический IP-адрес — наиболее удобное и гибкое решение для крупных сетей, значительно упрощающее общее администрирование. Для ОС FreeBSD существуют весьма качественные реализации DHCP-серверов, выполняющие данную задачу, и мы остановимся на общепризнанном фаворите — DHCP-сервере от ICS (версия 3.0.14).
Являясь наиболее типичной, с одной стороны, с другой — данная конфигурация подразумевает не самый легконастраиваемый способ организации защищенных соединений. Это объясняется тем, что изначально сервер «не знает» IP-адрес клиента, а для организации шифрованного туннеля необходимо знание как адреса сервера (точки «А»), так и адреса клиента (точки «В»). Поэтому полностью шифрованный туннель отпадает за громоздкостью реализации, а мы остановимся на не менее надежном методе — транспортном. (Туннель же хорош в случае заблаговременно известных IP-адресов — например, если необходимо связать серверы центрального офиса и филиалов, имеющие статические IP-адреса, выделенные им интернет-провайдерами.)
Для обеспечения безопасности на транспортном уровне можно применить три подхода: использование статических политик шифрования, секретного ключа (pre-shared key) и аутентификации с открытым ключом — сертификатов X.509. Первые два случая значительно проигрывают третьему с точки зрения той же безопасности, поэтому мы остановимся на самом надежном методе, аутентификации с открытым ключом, благо как FreeBSD, так и Windows XP имеют достаточно мощные средства поддержки X.509.
Теоретически, при соблюдении должных мер безопасности, сертификат X.509 нельзя подделать (и, как следствие, подключить к серверу нежелательного клиента).
Для этого необходимо строго ограничить доступ к серверу, на котором хранится корневой сертификат, выбрать надежный пароль и т. д. — все действия администратора в этом случае хрестоматийны и не нуждаются в перечислении. Кроме того, невозможно получить сертификат X.509 и с машины-клиента, так как при экспорте сертификата закрытый ключ не экспортируется. А это именно тот компонент, который и необходимо уберечь от кражи.
Для успешной работы на начальном этапе нам необходимо пересобрать ядро операционной системы FreeBSD с поддержкой IPSec. Сделать это достаточно просто, необходимо добавить в файл конфигурации ядра строки:
OPTIONS IPSEC OPTIONS IPSEC_ESP OPTIONS IPSEC_DEBUG
Затем сконфигурировать, скомпилировать и инсталлировать новое ядро с последующей перезагрузкой. После данных манипуляций появляется поддержка IPSec.
Необходимо также несколько изменить конфигурацию межсетевого экрана, так как взаимодействие сервера с клиентом потребует доступности некоторых специфических портов, но об этом ниже.
Предполагается, что на сервере с FreeBSD уже установлен пакет OpenSSL, который необходим как для генерации ключей и сертификатов, так и для интегрирования с программой racoon, которая отвечает за обмен ключами сервера с клиентом. Таких программ, обслуживающих протокол ISAKMP, две: racoon, который мы будем использовать, и isakmpd, «демон».
На стадии подготовки ключей и сертификатов следует крайне внимательно отнестись к процедуре генерации с помощью OpenSSL, так как в подавляющем большинстве случаев «все сделано правильно, но ничего не работает» — именно на этом этапе ошибки приводят к невозможности установить связь.
Сначала необходимо сгенерировать закрытый ключ для корневого сертификата сервера. 1024-битный ключ, зашифрованный при помощи алгоритма TRIPLE-DES, запишем в файл server.key:
openssl genrsa -des3 -out server.key 1024
На этом этапе необходимо со всей ответственностью отнестись к паролю, который программа OpenSSL затребует в конце генерации закрытого ключа.
Во-первых, пароль должен быть, по возможности, не «подбираемым влет», что обеспечит надежность всех выдаваемых впоследствии сертификатов, во-вторых, его ни в коем случае нельзя забыть, так как придется генерировать заново все сертификаты. Восстановить или взломать пароль нельзя, поэтому стоит положиться исключительно на собственную память.
По сгенерированному закрытому ключу server.key создадим корневой сертификат server.crt на следующих условиях: срок действия сертификата 5 лет (1825 дней).
openssl req -new -x509 -days 1825 -key server.key -out server.crt
В процессе создания сертификата OpenSSL запросит следующие сведения:
По окончании генерирования корневого сертификата на руках у администратора окажется необходимый инструментарий для создания сертификатов клиента и сервера, которые они будут «предъявлять» друг другу при установке защищенного соединения. Создадим ключ и сертификат для сервера:
openssl genrsa -out server-side.key 1024
Процедура создания ключа сервера схожа с созданием закрытого ключа для корневого сертификата. Далее необходимо сгенерировать запрос на сертификат server-side.csr (отвечая по ходу процедуры на стандартные вопросы):
openssl req -new -key server-side.key -out server-side.csr
В заключение генерируем сертификат со сроком действия 1 год для сервера server-side.crt, обозначив его сигнатурой закрытого ключа server.key для корневого сертификата server.crt:
openssl x509 -req -days 365 -in server-side.csr -CA server.crt -CAkey server.key -out server-side.crt
Кажущаяся громоздкость описываемых процедур на самом деле логична и хорошо документирована, тем более, что данный путь позволит обеспечить реальную безопасность беспроводного соединения (в отличие от мнимой стойкости WEP-шифрования).
Процедура создания сертификатов для клиента совершенно идентична:
openssl genrsa -out client-side.key 1024 openssl req -new -key client-side.key -out client-side.csr openssl x509 -req -days 365 -in client-side.csr -CA server.crt -CAkey server.key -out client-side.crt
Единственный дополнительный шаг на этом этапе — экспорт клиентского закрытого ключа client-side.key и сертификата client-side.crt в файл формата pl2 (client-side.pl2) для удобства импорта сертификата в ОС Windows XP.
После генерации ключей и сертификатов переместим их в каталог, например /usr/local/etc/secret.
Если на сервере установлен межсетевой экран (а он должен быть установлен), необходимо разрешить UDP-подключения на 500 порту — из файла /etc/services узнаем, что это порт isakmp:
ipfw allow udp from 192.168.1.0/24 to me dst-port 500 via fxp0 ipfw allow udp from me to any dst-port 500 via fxp0
Здесь 192.168.1.0/24 — локальная сеть организации, частью которой становится подключаемый клиент, me — IP-адрес сервера, fxp0 — сетевой интерфейс, обслуживающий локальную сеть.
Подготовительную стадию можно считать оконченной, теперь необходимо настроить ПО сервера и клиента. Как уже говорилось, в качестве программы управления ключами выбрана racoon (ныне часть пакета ipsec-tools). Программу можно установить либо в виде готового скомпилированного пакета, либо, что предпочтительнее, из портов (/usr/ports/security/racoon).
После установки требуется переименовать конфигурационный файл /usr/local/etc/racoon.conf.dist в /usr/local/etc/racoon.conf и внести в него соответствующие правки.
Закомментируем строку
path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
так как в этом файле находятся статические секретные ключи, от которых мы сразу отказались, и вместо нее впишем свою с путем к файлам ключей и сертификатов:
path certificate "/usr/local/etc/secret" ;
Также установим избыточный уровень отладки:
log debug2;
В остальном же файл racoon.conf снабжен исчерпывающими комментариями и настраивается без особых трудностей. Стоит лишь обратить особое внимание на секции anonymous — именно они определяют поведение сервера при подключении клиентов с динамическими IP-адресами.
Запуск racoon производится со следующими параметрами:
/usr/local/sbin/racoon -f /usr/local/etc/racoon.conf -l /var/log/racoon.log
На этом настройка сервера завершена, пора приступить к «поднятию» IPSec на клиентском ноутбуке. Кстати, настройка защищенного соединения в операционных системах Windows XP/2000 выполняется весьма громоздко и сопровождается многочисленными программными помощниками.
Для начала нужно убедиться, что запущена служба IPSec Services. Затем создаем новую управляющую консоль: из командной строки дадим команду mmc. В новой консоли добавляем следующие оснастки:
Для добавления сертификата и ключа необходимы некоторые файлы с сервера — client-side.pl2 и server.crt. Импортируем server.crt в контейнер Trusted Root Certification Authorities и client-side.pl2 в контейнер Personal оснастки Certificates.
В оснастке IP Security Policies создаем новую политику безопасности и называем ее, например FreeBSD. Здесь также придется пройти ряд мастеров настройки, но основной момент: важно не забыть деактивировать список фильтров по умолчанию и активировать вновь созданный — иначе опять «ничего не будет работать». В качестве точки источника и точки приемника определяем собственный IP-адрес ноутбука и фиксированный IP-адрес сервера соответственно. Также необходимо разрешить любой протокол на этом маршруте («Any»).
В заключение настройки клиента запускаем политику FreeBSD («Assign»). Если все настроено верно, это тотчас отразится в оснастке IP Security Monitor (см. скриншот). Самое время протестировать соединение — в командной строке запускаем элементарный ping. В случае правильной организации соединения появится сообщение Negotiating security и данные пинга сервера. Тому есть подтверждение и со стороны сервера, в логе racoon.log наблюдаются заветные строки:
ISAKMP-SA established 192.168.1.1[500]-192.168.1.253[500] spi:d8f9676430defba8:29ef37b543b950ea
Как видим, IPSec успешно функционирует в транспортном режиме. Конечно, было бы гораздо спокойнее и безопаснее построить полностью криптованный туннель «сервер — ноутбук», но это решение достаточно нетривиальное. Существуют и другие подходы, например организация виртуальных частных сетей с протоколами PPTP и L2TP, но специалисты по безопасности однозначно признают преимущество IPSec перед такими решениями.
В статье использована документация с сайта
