Популярность сетей Wi-Fi не оставляет равнодушными как потенциальных пользователей, так и злоумышленников. Хотя, и последних можно назвать пользователями, с той лишь разницей, что цели у них совсем другие.

Проблемами безопасности производители беспроводного оборудования Wi-Fi занялись давно и всерьез, ведь изначально стандарты 802.11x имели значительные недостатки в плане защищенности соединений. Если в редакции «g» уже есть подвижки в сторону улучшения стойкости ко взлому, то аппаратура с поддержкой более раннего (и более распространенного) стандарта «b» имеет нарекания в плане целостности передаваемой информации.

О какой защите инвестиций можно говорить в данном случае? Предположим, компания развернула беспроводную сеть стандарта 802.11b два года назад. А это означает, что были закуплены соответствующие точки доступа и клиентские адаптеры, причем как первые, так и вторые стоили недешево (на тот момент). Проходит немного времени, и оказывается, что беспроводная сеть передачи данных открыта для взлома, невзирая на попытки администраторов хоть как-то обезопасить сеть стандартными методами (в числе которых, напомним, 64- и 128-битное WEP-шифрование трафика, запрет широковещательной передачи идентификатора SSID, разграничение доступа, основанное на MAC-аутентификации).

Но этих методов сегодня уже недостаточно. WEP-шифрование базируется на алгоритме RC4, который ненадежен и легко поддается взлому. Да и с собственно шифрованием все далеко не однозначно — и в случае 64-, и 128-битного ключа присутствует некоторая условность. Дело в том, что эффективная длина ключа в первом составляет 40 бит, во втором — 104 бит. Недостающие до заявленных служебные 24 бит используются для дешифрования информации на принимающей стороне.

Таким образом, цифры «64» и «128» хороши лишь для маркетинговых уловок производителей и операторов, но не для реальной безопасности сети. Кроме того не будем забывать, что ключи статические — значит, их нужно периодически менять. Если в случае беспроводной сети, состоящей из точки доступа и нескольких клиентов, это не представляет особой проблемы, то для корпоративных сетей с огромным количеством одновременно подключенных беспроводных пользователей такое решение явно не подходит. Более того, для обеспечения достаточного уровня безопасности при использовании WEP-шифрования требуется смена 64-битного ключа раз в полчаса, а 128-битного — раз в час (в реальности ключи прописывают один раз и затем их не меняют).

Запрещение трансляции SSID не способствует увеличению безопасности беспроводной сети. Такой шаг способен привести лишь к появлению потенциальных проблем у подключаемых клиентов, так как конфигурирование сети станет гораздо менее гибким. Отключение широковещательной передачи SSID создает лишь иллюзию надежности: значение этого идентификатора все равно можно подслушать — оно находится во фреймах Probe Response.

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

Как видим, ситуация плачевная. Остается лишь один путь: использовать беспроводную связь только в виде «носителя», совершенно не отягощаясь заботами по настройке собственных средств безопасности. Если абстрагироваться от WEP-шифрования, списков MAC-доступа и широковещательной передачи SSID, беспроводную сеть можно сделать надежной, и даже очень надежной. Для этого требуется применить сторонние средства, наиболее популярное из которых — IPSec.

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

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

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

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

IPSec — наиболее популярное, и пожалуй, наилучшее решение для создания виртуальных частных сетей, но имеются определенные ограничения. В случае применения IPSec в транспортном режиме не исключается возможность атак со стороны — это вызвано некоторыми ограничениями протокола ISAKMP, но сложность проведения такой атаки не сравнится со взломом беспроводной сети, защищенной средствами «из коробки».

Пример реализации защищенного беспроводного соединения

Рассмотрим организацию защищенного соединения для наиболее типичной, в силу своей гибкости, конфигурации: имеется локальная сеть с выделенным сервером под управлением ОС 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 запросит следующие сведения:

• пароль закрытого ключа
• двухсимвольный код страны (US, RU, UA и т. д.)
• название штата или области
• название населенного пункта
• название компании
• название подразделения компании
• имя (например имя администратора, создающего сертификат)

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

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. В новой консоли добавляем следующие оснастки:

• Certificates (на локальном компьютере);
• IP Security Policies (на локальном компьютере);
• IP Security Monitor.

Для добавления сертификата и ключа необходимы некоторые файлы с сервера — 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 перед такими решениями.

В статье использована документация с сайта www.freebsddiary.org