Строим защищённую беспроводную сеть: WPA-Enterprise, 802.1x EAP-TLS::Журнал СА 5.2005
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1894
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1936
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1497
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1097
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1667
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 Строим защищённую беспроводную сеть: WPA-Enterprise, 802.1x EAP-TLS

Архив номеров / 2005 / Выпуск №5 (30) / Строим защищённую беспроводную сеть: 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 используется несколько обязательных логических элементов:

  • Клиент. В роли клиента выступает Supplicant– программа на клиентском компьютере управляющая процессом аутентификации.
  • Аутентификатор. Это точка доступа, которая выполняет функции посредника между клиентом и сервером аутентификации. Аутентификатором в том числе может быть и проводной коммутатор, т.к. 802.1x используется в различных сетях.
  • Сервер аутентификации – RADIUS-сервер.

В 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

Рисунок 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/ (все основные действия будут производиться в этом каталоге):

  • Удаляем всё содержимое папки ./certs.
  • Находясь в той же папке (./certs), даём команду:

# openssl gendh > dh

создаётся файл dh.

  • Там же даём команду:

# dd if=/dev/random of =random count=2

создаётся файл random.

  • Создаём папку raddb/sample и переносим в неё из raddb все файлы с расширением .sample. Из sample обратно в raddb копируем с изменением имени (без расширения .sample) файлы: acct_users, clients.conf, dictionary, eap.conf, hints, huntgroups, preproxy_users, proxy.conf, radiusd.conf, snmp.conf, sql.conf, users.
  • Правим следующие конфигурационные файлы:

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.

  • Заходим на веб-интерфейс точки доступа (как это сделать, написано в инструкции к точке), сразу меняем пароль по умолчанию на вкладке TOOLS/ADMIN/.
  • На вкладке HOME/LAN назначаем точке доступа IP-адрес, который задали в clients.conf: 192.168.0.220.

Рисунок 2. Присваиваем D-Link DWL-2100AP IP-адрес, отличный от адреса по умолчаниюРисунок 2. Присваиваем D-Link DWL-2100AP IP-адрес, отличный от адреса по умолчанию

Рисунок 2. Присваиваем D-Link DWL-2100AP IP-адрес, отличный от адреса по умолчанию

  • На вкладке HOME/WIRELESS делаем всё, как показано на рис. 3; в поле «Radius Secret» указываем пароль, который соответствует данной точке в clients.conf (мы указали «12345»).

Рисунок 3. Настраиваем D-Link DWL-2100AP на взаимодействие с RADIUS

Рисунок 3. Настраиваем D-Link DWL-2100AP на взаимодействие с RADIUS

Остальные точки доступа настраиваются аналогичным образом, только у них будут другие IP-адреса, каналы (если они задаются вручную), а также значение поля «Radius Secret».

Создаём сертификаты

Для начала несколько общих слов о том, что такое PKI. Это некая инфраструктура, каждый субъект которой обладает уникальным цифровым сертификатом, удостоверяющим его личность; помимо прочего, цифровой сертификат содержит секретный ключ. Закодированные с его помощью сообщения можно расшифровать, зная соответствующий открытый ключ. И наоборот – сообщения, зашифрованные открытым ключом, можно расшифровать только при помощи секретного ключа. Каждый субъект PKI обладает открытым и секретным ключом.

Субъектом PKI может быть как пользовательский компьютер или КПК, так и любой другой элемент сетевой инфраструктуры – маршрутизатор, веб-сервер и даже сервер RADIUS, что и имеет место в нашем случае. Во главе всей этой системы стоит главный орган CA (Certificate Autority), предполагается, что ему все доверяют и его все знают – он занимается подписью сертификатов (удостоверяет, что предъявитель сертификата действительно тот, за кого себя выдаёт). Ему помогают специальные службы по приёму запросов на сертификаты и их выдаче; номера всех выданных и отозванных сертификатов хранятся в специальном реестре. В реальности всё это вроде бы большое хозяйство умещается на одном компьютере, и с ним легко управляется один человек.

Для создания сертификатов мы будем использовать скрипты, которые идут в комплекте с FreeRADIUS.

  • Для начала создадим свой CA – для этого надо будет сгенерировать цифровую подпись, которой будут подписываться все выданные им сертификаты, а также открытый ключ.
  • Затем создадим серверный сертификат, установим его на RADIUS.
  • И в заключение сгенерируем сертификаты для установки на клиентские компьютеры.

Создаём директорию /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:

  • в строке 1 исправим путь – она должна выглядеть так:

SSL=/usr/local/openssl

  • в строке 32 исправим путь – она должна выглядеть вот так:

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

State or Province Name (full name) [Some-State]:Moscow

Locality Name (eg, city) []:Moscow

Organization Name (eg, company) [Internet Widgits Pty Ltd]:MegaCompany Co. Ltd.

Organizational Unit Name (eg, section) []:megacompany.central.office

Common Name (eg, YOUR name) []:Administrator

Email Address []:admin@megacompany.ru

Создаём сертификат для RADIUS:

Country Name (2 letter code) [AU]:RU

State or Province Name (full name) [Some-State]:Moskow

Locality Name (eg, city) []:Moskow

Organization Name (eg, company) [Internet Widgits Pty Ltd]:MegaCompany Co. Ltd.

Organizational Unit Name (eg, section) []:RADIUS

Common Name (eg, YOUR name) []:RADIUS

Email Address []:admin@megacompany.ru

 

Please enter the following "extra" attributes

to be sent with your certificate request

A challenge password []:whatever

An optional company name []: (press enter)

Копируем файлы /raddb/CA/cert_srv.pem и /raddb/CA/demoCA/cacert.pem в папку /raddb/certs – установили сертификаты на сервер RADIUS.

Создаём клиентские сертификаты

Для генерации клиентских сертификатов используем наш сценарий CA_users.all. Для примера создадим сертификат для пользователя user1:

  • Открываем CA_users.all , заменяем в нём все слова cert-clt.* на user1.* (это нужно для того чтобы по имени файла различать какой сертификат для какого пользователя предназначен, в противном случае будет создаваться сертификат с одним и тем же именем файла (cert-clt.*). Мы же создадим сразу несколько сертификатов для user1, user2,3,4,5). Как вариант можно использовать говорящие названия файлов содержащих сертификат, например, SergeyPetrov, IvanIvanov и т. д.
  • Пароль – «whatever» в строках 3, 4 заменяем на реальный, как это показано в листинге:

Файл 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» – этот пароль будет спрашиваться при установке сертификата на поль-зовательский компьютер, его необходимо запомнить. Это, как я уже сказал, дополнительное средство аутентификации при действиях, связанных с эмиссией сертификата.

  • Сохраняем и запускаем скрипт, получаем три файла user1.der, user1.pem, user1.p12 – последний есть сертификат в формате PKСS#12 для установки на Windows клиента.

Запускаем изменённый CA_users.all. Создаём сертификат для user1:

Country Name (2 letter code) [AU]:RU

State or Province Name (full name) [Some-State]:Moskow

Locality Name (eg, city) []:Moskow

Organization Name (eg, company) [Internet Widgits Pty Ltd]:MegaCompany Co. Ltd.

Organizational Unit Name (eg, section) []:IT Department

Common Name (eg, YOUR name) []:Andrey Ivanov

Email Address []:andrey@megacompany.ru

 

Please enter the following "extra" attributes

to be sent with your certificate request

A challenge password []:whatever

An optional company name []:  (press enter) 

Теперь генерируем пароль для пользователя user2:

  • Открываем CA_users.all, заменяем в нём user1.* на user2.*
  • Заменяем пароль «user1_password» на «user2_password» (не забываем его запомнить, чтобы потом установить сертификат).
  • Сохраняем и запускаем скрипт – получаем файл user2.p12.

Создаём сертификат для user2:

Country Name (2 letter code) [AU]:RU

State or Province Name (full name) [Some-State]:Moscow

Locality Name (eg, city) []:Moscow

Organization Name (eg, company) [Internet Widgits Pty Ltd]:MegaCompany Co. Ltd.

Organizational Unit Name (eg, section) []:IT Department

Common Name (eg, YOUR name) []:Mikhail Ivanov

Email Address []:mikhail@megacompany.ru

 

Please enter the following "extra" attributes

to be sent with your certificate request

A challenge password []:whatever

An optional company name []:

И так далее… (я сразу создал целых 5 сертификатов).

Каждый сертификат сохраняем на отдельную дискету, пишем на ней пароль для установки («userX_password»), на ту же дискету пишем открытый ключ root.der (он у всех одинаковый) и выдаём пользователю. Пользователь устанавливает сертификат на свой компьютер (об этом будет рассказано чуть позже) и кладёт дискету в сейф.

Устанавливаем сертификаты на клиентский компьютер

Итак, пользователь (предположим тот, которого мы назвали user1) получил дискетку, содержимым которой являются два файла root.der и user1.p12. Также на дискете написан пароль «user1_password».

Начнём с установки root.der

  • два раза щелкнем мышью по файлу root.der;
  • нажимаем «Установить сертификат»;
  • жмём «Далее»;
  • выбираем опцию «Поместить все сертификаты в следующее хранилище», жмём «Обзор» (рис. 4);

Рисунок 4

Рисунок 4

  • выбираем «Доверенные корневые центры сертификации», жмём «ОК» (рис. 5);

Рисунок 5

Рисунок 5

  • жмём «Далее», затем «Готово»;
  • выдаётся предупреждение системы безопасности: «Невозможно проверить, что сертификат принадлежит «Administrator …. Установить данный сертификат?» жмём «Да»;
  • выдаётся сообщение «Импорт успешно выполнен.», жмём «ОК» два раза.

Устанавливаем пользовательский сертификат user1.p12.

  • Два раза щелкаем мышью по файлу user1.p12, жмём «Далее» два раза.

Рисунок 6

Рисунок 6

  • Здесь надо ввести пароль, который мы установили для сертификата user1. В нашем примере это «user1_pass-word» (ну или то, что вы придумали), он условно написан на дискетке с сертификатом. Вводим его и нажимаем «Далее».
  • Жмём «Далее», затем «Готово» – выдаётся сообщение «Импорт успешно выполнен», жмём «ОК».

Примечание: все сертификаты, которые мы установили, можно просмотреть через 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.

  • Достаём адаптер из коробки, откладываем его в сторону; ставим драйверы с диска, который идёт в комплекте. После установки драйвера убираем родную утилиту для настройки адаптера из автозагрузки, потому что мы будем использовать для этих целей службу настройки беспроводного оборудования, встроенную в Windows XP. Вставляем адаптер в компьютер.
  • Щелкаем один раз левой кнопкой мыши по перечёркнутому значку беспроводного подключения (в системном лотке), далее выбираем пункт «Изменить дополнительные параметры» (рис. 7).

Рисунок 7

Рисунок 7

  • Выбираем вкладку «Беспроводные сети», выделяем там нашу беспроводную сеть (megacompany_DWL-2100AP), заходим в «Свойства» (рис. 8).

Рисунок 8

Рисунок 8

  • На вкладке «Связи» в выпадающем меню «Шифрование данных» выбираем протокол TKIP. Перемещаемся на вкладку «Проверка подлинности» (рис. 9).

Рисунок 9

Рисунок 9

  • Здесь всё оставляем без изменений, заходим в «Свойства» EAP (рис. 10).

Рисунок 10

Рисунок 10

  • Ставим переключатели, как показано на рис. 11, в окне «Доверенные корневые центры сертификации», выбираем наш CA – он будет называться Administrator (если всё сделано точно так, как описывается в разделе «Создание сертификатов»).

Рисунок 11

Рисунок 11

  • На всякий случай нажимаем «Просмотр сертификата», и изучаем, кто поставщик сертификата. Удостоверяемся, что это наш корпоративный CA «Administrator», который мы создали (рис. 12).

Рисунок 12

Рисунок 12

  • Нажимаем «OK», на этом настройка сетевой карты и супликанта завершена.

Проверяем работу WPA-Enterprise в нашей сети

Теперь пришло долгожданное время проверить все настройки в работе. Запускаем FreeRADIUS в отладочном режиме командой «radiusd -X» и видим на экране:

radius# radiusd –X

Starting - reading configuration files ...

reread_config:  reading radiusd.conf

В конце значатся строки:

Listening on authentication 192.168.0.222:1812

Listening on authentication 192.168.0.222:1813

Listening on authentication 192.168.0.222:1814

Ready to process requests.

Ну или в худшем случае написано, почему FreeRADIUS не запустился, – не стоит отчаиваться, если это произойдёт. Нужно внимательно изучить сообщение об ошибке и проверить все настройки.

Щелкаем по значку беспроводного сетевого подключения, затем по беспроводной сети с именем «mega-company_DWL-2100AP». Затем переводим свой взор на монитор, на котором запущен radiusd и отображается процесс успешной аутентификации (весь серверный вывод показывать не будем, потому что он довольно большой, приведём лишь начальные и завершающие строки).

Начало вывода:

rad_recv: Access-Request packet from host 192.168.0.220:1044, id=0, length=224

Message-Authenticator = 0x19ca5978137669db3043b8f9e8fc0803

Service-Type = Framed-User

User-Name = "Andrey Ivanov"

Framed-MTU = 1488

Called-Station-Id = "00-11-95-8E-BD-30:megacompany_DWL-2100AP"

Calling-Station-Id = "00-0D-88-88-D5-46"

NAS-Identifier = "D-Link Access Point"

Далее идёт всё, что изображено на рис. 1, в том числе обмен сертификатами.

Окончание вывода:

User-Name = "Andrey Ivanov"

Finished request 4

Going to the next request

Waking up in 6 seconds...

--- Walking the entire request list ---

Cleaning up request 0 ID 0 with timestamp 4294d303

Cleaning up request 1 ID 1 with timestamp 4294d303

Cleaning up request 2 ID 2 with timestamp 4294d303

Cleaning up request 3 ID 3 with timestamp 4294d303

Cleaning up request 4 ID 4 with timestamp 4294d303

Nothing to do.  Sleeping until we see a request.

Аутентификация прошла успешно, компьютер получает 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

Using configuration from /etc/ssl/openssl.cnf

943:error:0E06D06C:configuration file routines:NCONF_get_string:no value:

/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_lib.c:

329:group=CA_default name=unique_subject

Enter pass phrase for ./demoCA/private/cakey.pem:

DEBUG[load_index]: unique_subject = "yes"

Revoking Certificate D734AD0E8047BD8F.

OpenSSL ругается, но делает то, что нам нужно. В ходе выполнения команды необходимо ввести секретную фразу-пароль («whatever»). При этом в /raddb/CA/demoCA/index.txt сертификат будет помечен как отозванный, в чём мы можем убедиться, просмотрев данный файл. Напротив записи, соответствующей отозванному сертификату, стоит буква «R».

Шаг 2

Создаём список отзыва (CRL). Если он уже есть, то он обновится. Находясь в /usr/local/etc/raddb/CA, даём команду:

radius# openssl ca -gencrl -out ca.crl

Using configuration from /etc/ssl/openssl.cnf

963:error:0E06D06C:configuration file routines:NCONF_get_string:no value:

/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/conf/conf_lib.c:

329:group=CA_default name=unique_subject

Enter pass phrase for ./demoCA/private/cakey.pem:

DEBUG[load_index]: unique_subject = "yes"

Снова по ходу выполнения команды требуется ввести секретный пароль «whatever». В результате в директории /raddb/CA/ появляется файл ca.crl – это и есть список отзыва. Внутри он похож на шифровку, просмотреть его можно так:

radius# openssl crl -in ca.crl -text –noout

Certificate Revocation List (CRL):

        Version 1 (0x0)

        Signature Algorithm: md5WithRSAEncryption

        Issuer: /C=RU/ST=Moskow/L=Moskow/O=MegaCompany Co. Ltd./OU=megacompany.central.office/CN=Administrator/emailAddress=admin@megacompany.ru

        Last Update: May 27 23:33:19 2005 GMT

        Next Update: Jun 26 23:33:19 2005 GMT

Revoked Certificates:

    Serial Number: D734AD0E8047BD8D

        Revocation Date: May 27 23:13:16 2005 GMT

    Signature Algorithm: md5WithRSAEncryption

        d4:22:d6:a3:b7:70:0e:77:cd:d0:e3:73:c6:56:a7:9d:b2:d5:

        0a:e1:23:ac:29:5f:52:b0:69:c8:88:2f:98:1c:d6:be:23:b1:

        b9:ea:5a:a7:9b:fe:d3:f7:2e:a9:a8:bc:32:d5:e9:64:06:c4:

        91:53:37:97:fa:32:3e:df:1a:5b:e9:fd:95:e0:0d:35:a7:ac:

        11:c2:fe:32:4e:1b:29:c2:1b:21:f8:99:cd:4b:9f:f5:8a:71:

        b8:c9:02:df:50:e6:c1:ef:6b:e4:dc:f7:68:da:ce:8e:1d:60:

        69:48:ad:

Видим в нём один отозванный сертификат с серийным номером D734AD0E8047BD8D (он же user2, он же Mikhail Ivanov).

Обратите внимание, важным свойством CRL является срок его действия. Он должен быть обновлён не позднее его истечения (Update: Jun 26 23:33:19 2005 GMT). Срок действия CRL можно задать в файле openssl.cnf (у нас был default_crl_days = 30).

Шаг 3

Подключаем список отзыва к FreeRADIUS:

  • копируем файл /raddb/CA/ca.crl в /raddb/certs/ (поверх старого ca.crl, если он там есть);
  • заходим в /raddb/certs/ и приклеиваем ca.crl к файлу cacert.pem:

cat cacert.pem  ca.crl > ca.pem

  • вносим небольшие изменения в секцию TLS-файла /raddb/eap.conf

# здесь мы изменили  cacert.pem на ca.pem

CA_file = ${raddbdir}/certs/ca.pem

CA_path = ${raddbdir}/certs #добавляем эту строку

check_crl = yes  # и эту строку

Попробуем аутентифицировать в сети компьютер с сертификатом user2. Аутентификация не проходит, а user1 – беспрепятственно входит в беспроводную сеть, что и требовалось доказать.

Вот теперь защищённую беспроводную сеть можно считать построенной.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru