 |
|
|
|
Строим защищённую беспроводную сеть: WPA-Enterprise, 802.1x EAP-TLS
Строим защищённую беспроводную сеть: WPA-Enterprise, 802.1x EAP-TLS Существует добрая сотня статей о небезопасности беспроводных сетей. Причём многие совершенно идентичны и бесполезны: в них говорится о том, что WEP-это плохо, что MAC-адреса подменяются легко, и в заключение пишется: «Есть единственный выход и спасение. Нужно использовать WPA.» И точка. Данный материал содержит именно то, что вы хотели услышать после «точки» – практическое руководство по организации хорошо защищённой беспроводной сети. Безопасный небезопасный Wi-Fi На сегодняшний день становится очевидным, что, несмотря на все проблемы, связанные c безопасностью, надёжностью и сложностью эксплуатации, беспроводные решения семейства 802.11a/b/g всё же стали неотъемлемой частью инфраструктуры многих корпоративных, домашних и даже операторских сетей. Отчасти это произошло, потому что большинство этих проблем на современном этапе развития Wi-Fi ушли в прошлое. Беспроводные сети во всех отношениях стали намного умнее и быстрее: появился QoS, интеллектуальные антенны (технология MIMO), реальные скорости достигли 40 Мбит/c (например, технологии SuperG, SuperAG от Atheros). Кроме этого, большие изменения произошли и в наборе технологий, обеспечивающих безопасность беспроводных сетей. Об этом поговорим более подробно. Во времена, когда Wi-Fi был только для избранных, для защиты беспроводных сетей использовалось WEP-шифрование и MAC-фильтры. Всего этого быстро стало не хватать, WEP признали небезопасным из-за статичности ключей шифрования и отсутствия механизмов аутентификации, MAC-фильтры особой безопасности тоже не придавали. Началась разработка нового стандарта IEEE 802.11i, который был призван решить все назревшие проблемы безопасности. На полпути к 802.11i появился набор технологий под общим названием WPA (Wi-Fi Protected Access) – часть ещё не готового стандарта 802.11i. WPA включает в себя средства для аутентификации пользователей, шифрование при помощи динамических WEP-ключей (TKIP/MIC). Затем 802.11i наконец-то закончили, и на свет появился WPA2. Ко всему вышеперечисленному добавилась поддержка более стойкого шифрования AES (Advanced Encryption Standard), которое работает совместно с протоколом безопасности CCMP (Counter with Cipher Block Chaining Message Authentication Code Protocol – это более совершенный аналог TKIP в WPA). WPA2 постепенно стал появляться в новых моделях точек доступа (например, D-Link DWL-3200AP), но пока это скорее экзотика. Все продукты, поддерживающие WPA2, обратно совместимы с оборудованием, поддерживающим WPA. И WPA, и WPA2 включают в себя развитые средства контроля доступа к беспроводной сети на основе стандарта IEEE 802.1x. В архитектуре 802.1x используется несколько обязательных логических элементов:
В IEEE 802.1x допускается использование различных методов и алгоритмов аутентификации. Это возможно благодаря протоколу EAP (Extensible Authentication Protocol), в который «вкладываются» атрибуты, соответствующие тому или иному методу аутентификации. Поэтому существует много разновидностей 802.1x EAP: EAP-MD5, EAP-PEAP, EAP-LEAP, EAP-SIM и т. д. В данной статье будет описана реализация аутентификации в беспроводной сети на основе цифровых сертификатов – 802.1x EAP-TLS. Этот метод наиболее часто используется в корпоративных беспроводных сетях и отличается достаточно высокой степенью защищённости. Кроме того, EAP-TLS иногда является одним из основных методов защиты в сетях беспроводных провайдеров. Аутентификация 802.1x EAP-TLS В основе EAP-TLS лежит протокол SSL v3.0, однако в отличие от традиционной аутентификации по протоколу SSL (например, при организации защищенного http-соединения – HTTPS) в EAP-TLS происходит взаимная аутентификация клиента и сервера. Клиент (супликант) и сервер RADIUS должны поддерживать метод аутентификации EAP-TLS; точка доступа должна поддерживать аутентификацию 802.1x/EAP и не обязательно должна знать, какой метод аутентификации используется в конкретном случае. На рисунке ниже изображён процесс аутентификации в беспроводной сети с использованием EAP-TLS.
Рисунок 1. Процесс аутентификации 802.1x EAP-TLS Здесь уместно закончить небольшое лирически-теоретическое отступление, которое необходимо, для того чтобы получить примерное представление о том, что кроется в недрах безопасной беспроводной сети. Далее будет предложена практическая реализация описанных выше концепций. В качестве сервера RADIUS будет использоваться компьютер под управлением FreeBSD 5.3 c пакетом FreeRADIUS. Для организации инфраструктуры PKI (Public Key Infrastructure) будет применен пакет OpenSSL. Вся беспроводная сеть будет строиться на базе недорогого и надёжного беспроводного оборудования D-Link. Предполагается, что на клиентских машинах установлена Windows XP SP2, т.к. в этой операционной системе есть встроенный супликант, а недавно выпущенный корпорацией Microsoft update добавляет и поддержку WPA2. Устанавливаем и настраиваем OpenSSL и FreeRADIUS Предполагается, что в системе FreeBSD 5.3 установлена одна сетевая карта, обновлена коллекция портов, присутствует Midnight Commander, а сам компьютер подключён к Интернету. В дальнейшем будем предполагать, что беспроводная сеть развёртывается в корпоративной сети c маской 192.168.0.0/24. Загружаем с ftp://ftp.openssl.org/snapshot последний стабильный «снимок» (snapshot) OpenSSL (я, например, использовал openssl-0.9.7-stable-SNAP-20050524.tar.gz ). Распаковываем, конфигурируем, компилируем и инсталлируем его стандартным образом: # ./config shared --prefix=/usr/local/openssl # make # make install В принципе на этом работу с OpenSSL можно и завершить. В дальнейшем он потребуется нам для генерации сертификатов. FreeRADIUS – довольно объёмный пакет, поэтому его, в отличие от OpenSSL, мы будем устанавливать из портов, что обеспечит автоматическое разрешение зависимостей и установку всех необходимых библиотек и приложений. Перемещаемся в директорию /usr/ports/net/freeradius/, затем даём команду make – ничего не выбираем из предложенных установочным сценарием опций, нажимаем «Ok». Начинается процесс автоматической инсталляции (загрузка и компиляция необходимых приложений); по ее завершению следует набрать make install. На этом с установкой FreeRADIUS покончено, можно переходить к его настройке. Выбираем директорию FreeRADIUS: /usr/local/etc/raddb/ (все основные действия будут производиться в этом каталоге):
# openssl gendh > dh создаётся файл dh.
# dd if=/dev/random of =random count=2 создаётся файл random.
clients.conf client 192.168.0.220 { # IP-адрес точки доступа # Секретное слово, которое задаётся на точке доступа secret = 12345 shortname = D-Link_DWL-2100AP nastype = other } client 192.168.0.219 { # IP-адрес точки secret = 54321 # Секретное слово shortname = D-Link_DWL-2700AP nastype = other } # и т.д. eap.conf # В самом начале, после « eap {» default_eap_type = tls tls { private_key_password = whatever private_key_file = ${raddbdir}/certs/cert-srv.pem certificate_file = ${raddbdir}/certs/cert-srv.pem CA_file = ${raddbdir}/certs/demoCA/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1750 } radiusd.conf bind_address = 192.168.0.222 port = 1812 log_auth = yes # для отладки log_auth_badpass = yes log_auth_goodpass = yes На этом настройка RADIUS завершена. Настраиваем точки доступа Для построения беспроводной сети мы будем использовать несколько точек доступа D-Link DWL-2100AP и одну более мощную точку D-Link DWL-2700AP. Это сертифицированные точки доступа стандарта 802.11b/g (до 54 Мбит/c), в них реализована полная поддержка WPA (впрочем, как и во всех остальных точках доступа D-Link). Во всех точках используются последние прошивки, которые можно загрузить отсюда: ftp://ftp.dlink.ru/pub/Wireless. Для начала несколько слов о настройке беспроводной сети, а затем приведем пример конфигурирования D-Link DWL-2100AP для обеспечения взаимодействия с сервером RADIUS. Внутриофисная беспроводная сеть обычно состоит из нескольких точек доступа (всё покрытие разбивается на небольшие ячейки), которые подключены к проводному коммутатору. Часто для построения WLAN используются коммутаторы со встроенной поддержкой Power over Ethernet (802.3af) на портах (например, D-Link DES-1316K). При их помощи удобно подавать питание на точки доступа, разбросанные по офису. Находящиеся рядом точки настраиваются на непересекающиеся каналы диапазона, для того чтобы они не создавали друг для друга помех. В диапазоне 2.4 ГГц, в котором работает оборудование 802.11b/g, доступно 3 непересекающихся канала для оборудования, в котором 11 каналов, и 4 непересекающихся канала для оборудования, в котором можно выбрать 13 каналов (широкополосный сигнал точки доступа занимает 3 канала диапазона). Точки доступа D-Link DWL-2100AP и DWL-2700AP можно настроить на любой из 13 каналов, кроме того, можно включить функцию автоматической настройки на свободный канал. Так мы и сделаем. Если в сети есть мобильные абоненты, которые перемещаются по всей зоне покрытия, можно задать всем точкам одинаковое имя беспроводной сети – SSID, тогда абонент будет автоматически подключаться к новой точке, при потере соединения с предыдущей. При этом он будет проходить повторную аутентификацию, которая в зависимости от супликанта будет занимать от нескольких секунд и более. Так реализуется самый простой неинтеллектуальный роуминг внутри сети. Ещё один вариант: если у каждой точки свой SSID, то можно настроить несколько профилей беспроводной сети в свойствах беспроводного подключения и там же отметить опцию «подключаться к любой доступной сети». Таким образом при потере соединения, клиент будет подключаться к новой точке. Настраиваем DWL-2100AP на взаимодействие с RADIUS.
Рисунок 2. Присваиваем D-Link DWL-2100AP IP-адрес, отличный от адреса по умолчанию
Рисунок 3. Настраиваем D-Link DWL-2100AP на взаимодействие с RADIUS Остальные точки доступа настраиваются аналогичным образом, только у них будут другие IP-адреса, каналы (если они задаются вручную), а также значение поля «Radius Secret». Создаём сертификаты Для начала несколько общих слов о том, что такое PKI. Это некая инфраструктура, каждый субъект которой обладает уникальным цифровым сертификатом, удостоверяющим его личность; помимо прочего, цифровой сертификат содержит секретный ключ. Закодированные с его помощью сообщения можно расшифровать, зная соответствующий открытый ключ. И наоборот – сообщения, зашифрованные открытым ключом, можно расшифровать только при помощи секретного ключа. Каждый субъект PKI обладает открытым и секретным ключом. Субъектом PKI может быть как пользовательский компьютер или КПК, так и любой другой элемент сетевой инфраструктуры – маршрутизатор, веб-сервер и даже сервер RADIUS, что и имеет место в нашем случае. Во главе всей этой системы стоит главный орган CA (Certificate Autority), предполагается, что ему все доверяют и его все знают – он занимается подписью сертификатов (удостоверяет, что предъявитель сертификата действительно тот, за кого себя выдаёт). Ему помогают специальные службы по приёму запросов на сертификаты и их выдаче; номера всех выданных и отозванных сертификатов хранятся в специальном реестре. В реальности всё это вроде бы большое хозяйство умещается на одном компьютере, и с ним легко управляется один человек. Для создания сертификатов мы будем использовать скрипты, которые идут в комплекте с FreeRADIUS.
Создаём директорию /usr/local/etc/raddb/CA, копируем туда из папки /usr/ports/net/freeradius/work/freeradius-1.0.2/scripts/ файл CA.all и файл xpextensions. CA.all – интерактивный скрипт, создающий CA, клиентский и серверный сертификаты. Xpextensions – файл, содержащий специальные ключи Microsoft «Extended Key Usage», – они необходимы для того, чтобы EAP-TLS работал с Windows-системами. Открываем файл CA.all:
SSL=/usr/local/openssl
echo “newreq.pem” | /usr/local/openssl/ssl/misc/CA.pl -newca Копируем CA.all в файл СA_users.all. Затем открываем последний и оставляем текст с 48 строки по 64-ю, остальные строки удаляем – оставшееся – это секция CA.all, в которой генерируются клиентские сертификаты. Она будет многократно использоваться, поэтому её удобно выделить в отдельный скрипт. Открываем CA.all , удаляем из него строки с 48 по 64-ю – всё то, что выделили в отдельный скрипт и сохраняем его. Примечание: файлы CA.all и CA_users.all – содержат секретную фразу-пароль «whatever», которая используется как дополнительное средство обеспечения безопасности, при эмиссии сертификатов и их отзыве. Человек, не знающий эту фразу не сможет ни подписать, ни отозвать сертификат. В принципе, кроме оператора CA, она больше никому не понадобится. Для повышения безопасности нужно заменить все встречающиеся в скрипте CA.all и CA_users.all слова «whatever» на придуманный вами пароль. Его также нужно будет вписать в eap.conf в строку «private_key_password = whatever». Далее я предполагаю, что мы оставили везде пароль «whatever» без изменений. Его и будем вводить, создавая клиентские, серверные сертификаты, а также отзывая их. Создаём CA и серверный сертификат Запускаем CA.all. Первое, что он генерирует в интерактивном режиме – корневой сертификат CA (cacert.pem), пару открытый закрытый ключ (cakey.pem), открытый ключ корневого сертификата в формате PKCS#12 (root.der), затем серверный сертификат (cert_srv.pem), который мы установим на RADIUS. Все перечисленные файлы (и даже некоторые не перечисленные) появятся в папке CA. Создаём CA (он будет называться «Administrator»): Country Name (2 letter code) [AU]:RU
Создаём сертификат для RADIUS:
Копируем файлы /raddb/CA/cert_srv.pem и /raddb/CA/demoCA/cacert.pem в папку /raddb/certs – установили сертификаты на сервер RADIUS. Создаём клиентские сертификаты Для генерации клиентских сертификатов используем наш сценарий CA_users.all. Для примера создадим сертификат для пользователя user1:
Файл CA_users.all 1| openssl req -new -keyout newreq.pem -out newreq.pem -days 730 -passin pass:whatever -passout pass:whatever 2| openssl ca -policy policy_anything -out newcert.pem -passin pass:whatever -key whatever -extensions xpclient_ext \ -extfile xpextensions -infiles newreq.pem 3| openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out user1.p12 -clcerts -passin pass:whatever -passout pass:user1_password 4| openssl pkcs12 -in user1.p12 -out user1.pem -passin pass:user1_password -passout pass:user1_password 5| openssl x509 -inform PEM -outform DER -in user1.pem -out user1.der Для примера вводим «user1_password» – этот пароль будет спрашиваться при установке сертификата на поль-зовательский компьютер, его необходимо запомнить. Это, как я уже сказал, дополнительное средство аутентификации при действиях, связанных с эмиссией сертификата.
Запускаем изменённый CA_users.all. Создаём сертификат для user1: Country Name (2 letter code) [AU]:RU
Теперь генерируем пароль для пользователя user2:
Создаём сертификат для user2:
И так далее… (я сразу создал целых 5 сертификатов). Каждый сертификат сохраняем на отдельную дискету, пишем на ней пароль для установки («userX_password»), на ту же дискету пишем открытый ключ root.der (он у всех одинаковый) и выдаём пользователю. Пользователь устанавливает сертификат на свой компьютер (об этом будет рассказано чуть позже) и кладёт дискету в сейф. Устанавливаем сертификаты на клиентский компьютер Итак, пользователь (предположим тот, которого мы назвали user1) получил дискетку, содержимым которой являются два файла root.der и user1.p12. Также на дискете написан пароль «user1_password». Начнём с установки root.der
Рисунок 4
Рисунок 5
Устанавливаем пользовательский сертификат user1.p12.
Рисунок 6
Примечание: все сертификаты, которые мы установили, можно просмотреть через MMC при помощи оснастки «Certificates -> Current User (Personal -> Certificates)». Настраиваем беспроводные адаптеры D-Link DWL-G650 (DWL-G520/DWL-G120) и супликант D-Link DWL-G650 – это CardBus-адаптер, DWL-G520 – это PCI-адаптер, a DWL-G120 – это USB-адаптер. Настраиваются они совершенно идентично. Рассмотрим процедуру на примере DWL-G650.
Рисунок 7
Рисунок 8
Рисунок 9
Рисунок 10
Рисунок 11
Рисунок 12
Проверяем работу WPA-Enterprise в нашей сети Теперь пришло долгожданное время проверить все настройки в работе. Запускаем FreeRADIUS в отладочном режиме командой «radiusd -X» и видим на экране: radius# radiusd –X
В конце значатся строки:
Ну или в худшем случае написано, почему FreeRADIUS не запустился, – не стоит отчаиваться, если это произойдёт. Нужно внимательно изучить сообщение об ошибке и проверить все настройки. Щелкаем по значку беспроводного сетевого подключения, затем по беспроводной сети с именем «mega-company_DWL-2100AP». Затем переводим свой взор на монитор, на котором запущен radiusd и отображается процесс успешной аутентификации (весь серверный вывод показывать не будем, потому что он довольно большой, приведём лишь начальные и завершающие строки). Начало вывода:
Далее идёт всё, что изображено на рис. 1, в том числе обмен сертификатами. Окончание вывода:
Аутентификация прошла успешно, компьютер получает IP-адрес от DHCP-сервера и теперь может работать в беспроводной сети. К слову сказать, если на компьютере установлено несколько клиентских сертификатов (такое тоже бывает), то супликант предложит выбрать, какой из них использовать для конкретной аутентификации. Отзыв сертификатов Казалось бы, уже всё ясно – защищённая беспроводная сеть уже построена, но на самом деле остался ещё один важный аспект, который мы сейчас рассмотрим. Предположим, что надо запретить доступ в беспроводную сеть одному из компьютеров (например, личному ноутбуку одного из сотрудников), на который ранее мы установили сертификат. Причины могут быть самыми банальными – увольнение сотрудника, сокращение и т. д. Для решения этой задачи необходимо пометить в реестре (/usr/local/etc/raddb/CA/demoCA/index.txt), в котором хранится список всех подписанных сертификатов, сертификат пользователя, которому мы хотим запретить доступ в сеть, как отозванный. После этого необходимо создать (или обновить, если он уже есть) список отзыва сертификатов (CRL – Certificate Revocation List). А затем настроить RADIUS таким образом, чтобы при аутентификации пользователей он обращался к этому списку и проверял, не состоит ли в нём предъявляемый клиентский сертификат. В ходе наших предыдущих экспериментов мы создали два сертификата для user1 (Andrey Ivanov) и user2 (Mikhail Ivanov). Для примера запретим доступ в беспроводную сеть последнему. Проделаем следующие три шага. Шаг 1 Помечаем в реестре сертификат user2 как отозванный: находясь в /usr/local/etc/raddb/CA даём команду: radius# openssl ca -revoke user2.pem
OpenSSL ругается, но делает то, что нам нужно. В ходе выполнения команды необходимо ввести секретную фразу-пароль («whatever»). При этом в /raddb/CA/demoCA/index.txt сертификат будет помечен как отозванный, в чём мы можем убедиться, просмотрев данный файл. Напротив записи, соответствующей отозванному сертификату, стоит буква «R». Шаг 2 Создаём список отзыва (CRL). Если он уже есть, то он обновится. Находясь в /usr/local/etc/raddb/CA, даём команду: radius# openssl ca -gencrl -out ca.crl
Снова по ходу выполнения команды требуется ввести секретный пароль «whatever». В результате в директории /raddb/CA/ появляется файл ca.crl – это и есть список отзыва. Внутри он похож на шифровку, просмотреть его можно так: radius# openssl crl -in ca.crl -text –noout
Видим в нём один отозванный сертификат с серийным номером D734AD0E8047BD8D (он же user2, он же Mikhail Ivanov). Обратите внимание, важным свойством CRL является срок его действия. Он должен быть обновлён не позднее его истечения (Update: Jun 26 23:33:19 2005 GMT). Срок действия CRL можно задать в файле openssl.cnf (у нас был default_crl_days = 30). Шаг 3 Подключаем список отзыва к FreeRADIUS:
cat cacert.pem ca.crl > ca.pem
# здесь мы изменили cacert.pem на ca.pem CA_file = ${raddbdir}/certs/ca.pem CA_path = ${raddbdir}/certs #добавляем эту строку check_crl = yes # и эту строку Попробуем аутентифицировать в сети компьютер с сертификатом user2. Аутентификация не проходит, а user1 – беспрепятственно входит в беспроводную сеть, что и требовалось доказать. Вот теперь защищённую беспроводную сеть можно считать построенной. |
АНДРЕЙ ПЛАТОНОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
