vkladimirov a a wi fu phần 7 pps

284 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
и возврат всех деталей конфигурации клиенту, который будет предоставлять пользо-
вателю определенные сервисы. Кроме того, RADIUS-сервер может выступать в виде
proxy-клиента для других RADIUS-серверов или иных серверов аутентификации;
о сетевая безопасность. Во время аутентификации пользователя обмен данными меж-
ду клиентом и сервером шифруется с помощью разделяемого секрета, который ни-
когда не передается по сети в открытом виде. Пароли пользователей клиент переда-
ет RADIUS-серверу также в зашифрованном виде, чтобы исключить возможность
прослушивания;
о гибкие механизмы аутентификации. RADIUS-сервер допускает различные методы
аутентификации пользователей. Получив имя пользователя и его пароль, он может
аутентифицировать его по протоколу РАР или CHAP, выполнить стандартную проце-
дуру входа в ОС UNIX или поискать информацию в иных хранилищах, например РАМ,
LDAP, SQL и т.д.;
о расширяемый протокол. Все данные передаются в виде троек переменной длины:
атрибут-длина-значение (Attribute-Length-Value - ALV). Можно добавлять новые зна-
чения атрибутов, не нарушая корректность работы существующей реализации, за счет
чего протокол становится более гибким и динамичным, способным к расширению.
Форматы пакетов
Пакеты протокола RADIUS инкапсулированы в поток данных протокола UDP без состоя-
ния. Для этого протокола зарезервированы порты 1812, 1813 и 1814, предназначенные
соответственно для доступа, учета и организации proxy. Ради совместимости и по истори-
ческим причинам некоторые серверы продолжают работать через порты 1645 и 1646. Так
повелось еще со времен ранних этапов разработки RADIUS, а теперь вступает в противоре-
чие со службой «метрик данных».
В RFC специфицирована структура пакета протокола RADIUS (рис. 13.1).
Рис. 13.1. Структура пакета протокола RADIUS
Ниже описаны отдельные элементы этого пакета:
о код. Поле кода длиной в один октет определяет тип пакета. Получив пакет с некор-
ректным значением кода, сервер игнорирует его без каких-либо уведомлений. До-
пустимые типы пакетов рассматриваются в следующем разделе;

о идентификатор. Это поле длиной также в один октет позволяет клиенту RADIUS
сопоставить полученный от сервера ответ с ранее посланным запросом;
о длина. Это поле занимает два октета. В нем хранится длина сообщения, то есть сум-
ма длин полей кода, идентификатора, длины, аутентификатора и атрибутов;
о аутентификатор. Длина поля равна 16 октетам, оно используется для аутентифи-
кации и верификации ответа от RADIUS-сервера, а также как механизм сокрытия
паролей. В поле могут передаваться значения двух типов: запрос (Request) и ответ
RADIUS 285
(Response). Поле запроса может встречаться в пакетах типа Access (Доступ) и
Accounting Request (Запрос учетной информации), его значение должно быть слу-
чайно и уникально. Поле ответа встречается в пакетах типа Access-Accept (Доступ
разрешен), Access-Reject (Доступ запрещен) и Access-Challenge (Запрос). Оно долж-
но содержать одностороннюю МБ5-свертку, вычисленную по значениям полей кода,
идентификатора, длины, аутентификатора, атрибутов и по разделяемому секрету;
о атрибуты. В этом поле передаются различные характеристики службы, обычно для
анонсирования конкретных предлагаемых или запрашиваемых возможностей. Шесть
атрибутов и их допустимые значения представлены в табл. 13.1.
Таблица 13.1. Типы атрибутов в протоколе RADIUS
ТИПЫ
пакетов
RADIUS-сервер идентифицирует типы сообщений по значению поля кода. Возможные коды
описаны в табл. 13.2. Мы не будем вдаваться в подробности, поскольку считаем, что назва-
ния понятны без пояснений. Но, если хотите, можете прочитать раздел «Packet Types»
(Типы пакетов) в RFC 2138.
286 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
11 Access-Challenge (Запрос)
12 Status-Server (Состояние сервера) - экспериментальный
13 Status-Client (Состояние клиента) - экспериментальный
255 Зарезервирован
Инсталляция FreeRADIUS

Мы уже обсудили модель ААА, лежащую в основе протокола RADIUS, а также структуру
протокола, допустимые типы и значения полей. Теперь займемся более практическим воп-
росом - инсталляцией сервера FreeRADIUS. На официальном сайте проекта FreeRADIUS
() читаем: «Проект FreeRADIUS - это попытка создать высокопро-
изводительный и конфигурируемый в широких пределах RADIUS-сервер, распространяе-
мый по лицензии GPL. Сервер аналогичен продукту Livingston 2.O. FreeRADIUS - это вари-
ант сервера Cistron RADIUS, но общего у них мало. FreeRADIUS имеет гораздо больше
возможностей, чем Cistron или Livingston, и при этом намного лучше конфигурируется».
Для промышленной эксплуатации мы рекомендуем устанавливать стабильную версию
продукта, в момент работы над книгой это была версия FreeRADIUS 0.8.1. Но, возможно, вы
сочтете, что последняя версия в CVS-хранилище лучше отвечает вашим потребностям, по-
скольку поддерживает больше функций. И стабильную, и CVS-версию можно скачать со
страницы Далее мы будем говорить о версии, взя-
той из CVS-хранилища 26 мая 2003 года. Процедура инсталляции последней стабильной
версии не должна сильно отличаться.
Для того чтобы начать процедуру сборки и инсталляции из исходных текстов, скачайте
и разверните дистрибутив FreeRADIUS:
arhontus:~$ wget -с />freeradius-snapshot-20030526.tar.gz
arhontus:~$ tar -xvzf freeradius-snapshot-20030526.tar.gz
arhontus:~$ cd freeradius-snapshot-20030526
Чтобы настроить FreeRADIUS под свои нужды, вы, возможно, захотите отредактировать
файл Makefile или указать дополнительные флаги сценарию configure. Подробно об имею-
щихся возможностях можно узнать, набрав команду
arhontus:$ ./configure help
Затем выполните конфигурирование и запустите компиляцию:
arhontus:$ ./configure
arhontus:$ make
Для инсталляции FreeRADIUS вам потребуются привилегии пользователя root. Выпол-
ните команды:
arhontus:$ su

arhontus:# make install
Чтобы настроить FreeRADIUS под свои нужды, вы, возможно, захотите отредактировать
файл Makefile или указать дополнительные флаги сценарию configure. Подробно об имею-
щихся возможностях можно узнать, набрав команду
Затем выполните конфигурирование и запустите компиляцию:
Для инсталляции FreeRADIUS вам потребуются привилегии пользователя root. Выпол-
ните команды:
ИНСТАЛЛЯЦИЯ FREERADIUS 287
Чтобы инсталлировать двоичный пакет в Debian Linux, выполните команду
arhontus:# dpkg -i radiusd-freeradius_O.8.I_i386.deb
или
arhontus:# dpkg -i radiusd-freeradius_O.8.1+0.9pre20030526-l_i386.deb
в зависимости от того, хотите вы установить стабильную или CVS-версию. Кроме того, мож-
но установить различные дополнительные модули к серверу, реализующие такие схемы
аутентификации, как Kerberos V, SQL или LDAP.
По завершении инсталляции переходите к следующему разделу, в котором описывают-
ся процедуры конфигурирования RADIUS-сервера.
Конфигурирование
Во время работы над этой книгой конфигурационные файлы для стабильной версии на-
ходились в каталоге /etc/raddb, а для CVS-версии - в каталоге /etc/freeradius, так что,
возможно, ваши действия будут слегка отличаться от описанных ниже. Предлагаем вам
сразу познакомиться со структурой каталогов и наиболее важными конфигурационны-
ми файлами.
288
А
ВОРОТА
КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
clients, conf
Информация, хранящаяся в этом файле, более приоритетна, чем та, что находится в файлах
clients или naslist. Конфигурация включает все данные из этих двух файлов, а также до-

полнительные возможности. Чтобы сконфигурировать сервер с учетом особенностей ва-
шей сети, редактируйте именно файл clients.conf. Вот пример одной записи:
Файл /etc/freeradius/radiusd.conf - это сердце RADIUS-сервера. Именно в нем прописыва-
ется большая часть параметров и директив. Ниже для иллюстрации приведен небольшой
фрагмент этого файла. Его необходимо отредактировать в соответствии с вашими требова-
ниями. Можете также посмотреть наш пример файла radiusd.conf, в котором прописаны
многие возможности FreeRADIUS, в том числе аутентификация посредством LDAP, EAP-TLS
или паролей UNIX.
Настоятельно рекомендуем в качестве разделяемого секрета выбирать строки, отсут-
ствующие в словаре, и употреблять в них символы разных типов: буквы, цифры, знаки
препинания и др. Если вы не измените принятые по умолчанию значения, то поставите
безопасность сети под угрозу!
naslist
Далее отредактируйте файл /etc/freeradius/naslist, указав в нем канонические названия,
сокращенные названия и типы всех NAS-серверов, которые будут обращаться к данному
RADIUS-серверу. Полный перечень поддерживаемых видов NAS-серверов можно узнать на
странице руководства или из самого файла naslist. Ниже приведен пример:
realms
Файл /etc/freeradius/realms будет полезен, если вы захотите развернуть несколько RADIUS-
серверов и потребовать, чтобы мобильные пользователи переходили с одного на другой.
В последних версиях FreeRADIUS этот файл уже не используется и заменен файлом proxy.conf,
в котором хранятся настройки для организации proxy.
users
В этом файле описываются методы и процедуры аутентификации пользователей. Мы по-
местим сюда разных пользователей вместе с указанием тех сервисов, к которым у них есть
доступ, а также применяемых по умолчанию механизмов аутентификации. Более подроб-
ную информацию об этом файле можно найти на странице руководства man 5 users. Ниже
приведен пример:
Если вы работаете на платформе Microsoft Windows, то можете скачать утилиту NTRadPing
для тестирования RADIUS-сервера со страницы />Окно утилиты показано на рис. 13.2.

Успешно завершив тестирование сервера, можете переходить к следующему разделу,
в котором речь идет об основах мониторинга и учета в RADIUS. Это важно знать для по-
вседневного администрирования, а также на случай, если все-таки произойдет вторже-
ние в сеть.
В протоколе сервера должна появиться запись об авторизации такого вида:
Успешно запустив FreeRADIUS-сервер, вы сможете протестировать аутентификацию
пользователя, причем несколькими разными способами. Первый способ - воспользо-
ваться утилитой radtest, которая пытается установить соединение с сервером, отпра-
вив ему указанные «верительные грамоты», и выводит полученный от сервера ответ.
Вот пример:
Если это не так, запустите FreeRADIUS в режиме отладки, чтобы из диагностических
сообщений понять, в чем причина ошибки:
Если сервер запустился успешно, то, выполнив показанную ниже команду, вы увидите
что-то типа:
arhontus:~# /etc/init.d/freeradius start
УЧЕ Г РАБОТЫ ПОЛЬЗОВАТЕЛЕЙ 291
Учет работы пользователей
В документе RFC 2139 перечислены основные возможности службы учета RADIUS
Accounting:
о модель клиент-сервер. NAS-сервер работает как клиент учетного RADIUS-сервера.
Клиент передает учетную информацию о пользователе учетному серверу. Учетный
сервер принимает запрос и возвращает клиенту отве г о том, что запрос получен. Учет-
ный сервер может выступать в роли proxy-клиента ^ля других учетных серверов;
о сетевая безопасность. Транзакции между клиенток и сервером аутентифицируют-
ся с помощью разделяемого секрета, который никогда не передается по сети;
о расширяемый протокол. В ходе любой транзакции [передается тройка атрибут-дли-
на-значение переменной длины. Новые значения! атрибутов можно добавлять, не
нарушая работу существующей реализации протокола.
Любой вид оборудования, входящий в состав сервера доступа к сети (NAS), должен под-
держивать учетные функции RADIUS. Должна быть возможность сконфигурировать его так,

чтобы протоколировалась информация о типичных для Пользователя способах доступа в
сеть. Ниже приведен пример учетной информации о сеансе с точки доступа Orinoco, но
ясно, что в реальности картина будет зависеть от вида обррудования NAS и способа учета,
заданного администратором.
Прочитать об утилитах для анализа учетных данных и формирования отчетов на их
основе можно ниже в разделе «Инструменты, относящиеся к RADIUS».
Уязвимости RADIUS
Известен целый ряд слабостей RADIUS, причиной которых является как сам протокол, так
и неудачная реализация клиентов. Сам по себе протокол UDP, не имеющий состояния, по-
зволяет подделывать пакеты. Уязвимости, о которых пойдет речь в этом разделе, не исчер-
пывают весь список проблем протокола, а призваны лишь продемонстрировать несколько
способов обойти аутентификацию пользователя. Атаки можно отнести к следующим кате-
гориям:
о подбор «верительных грамот» пользователя методом полного перебора;
о DoS-атака;
о повтор сеанса;
о внедрение поддельных пакетов.
Атака на аутентификатор ответа
Аутентификатор ответа (Response Authenticator) - это, по существу, МО5-свертка. Если
противник сумел перехватить корректную последовательность пакетов типа Access-Request,
Access-Accept или Access-Reject, то он может, уже не находясь в сети, попробовать вскрыть
разделяемый секрет путем полного перебора. Противник может вычислить МО5-свертку
от комбинации полей кода+идентификатора+длины+аутентификатора+атрибутов, посколь-
ку большая часть составных частей аутентификатора известны, а затем повторять эту свер-
тку при каждой попытке угадать разделяемый секрет.
Атака на разделяемый секрет на основе атрибута Password
Мандат, содержащий пару имя-пароль, является защищенным, но противник может полу-
чить информацию о разделяемом секрете, если будет следить за попытками аутентифика-
ции. Если взломщик предпримет попытку аутентифицироваться с известным паролем, а
затем перехватит отправляемый в результате пакет Accept-Request, то он сможет выпол-

нить XOR между защищенной частью атрибута User-Pas sword с паролем, который он
сообщил клиенту ранее. Поскольку аутентификатор ответа известен (его можно увидеть в
пакете Accept-Request), то противник получает возможность провести атаку методом пол-
ного перебора на разделяемый секрет, уже не находясь в сети.
292 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
ИНСТРУМЕНТЫ, ОТНОСЯЩИЕСЯ К RADIUS 293
Атака на пароль пользователя
Она аналогична предыдущей: зная разделяемый секрет, противник может пробовать раз-
личные пароли путем модификации и воспроизведения пакетов типа Access-Request. Если
сервер не ограничивает число безуспешных попыток аутентификации одного пользовате-
ля, то атакующий сумеет выполнить полный перебор всех паролей, пока не отыщет пра-
вильный. Не забывайте, что применение стойкой схемы аутентификации в пакете Access-
Request сделает такую атаку почти невозможной.
Атаки на аутентификатор запроса
Безопасность пакета в протоколе RADIUS зависит от содержимого поля аутентификатора зап-
роса (Request Authenticator). Оно должно быть уникальным и непредсказуемым. Однако в
спецификациях протокола важности способа генерирования этого поля не уделено долж-
ного внимания, поэтому существует много реализаций, в которых алгоритм оставляет же-
лать лучшего. Если клиент пользуется генератором псевдослучайных чисел с коротким
периодом, то желаемый уровень безопасности протокола не будет достигнут. Вспомните,
что говорилось в главах о прикладной криптографии по поводу работы и тестирования
генераторов псевдослучайных чисел.
Повтор ответов сервера
Противник может создать базу данных с аутентификаторами запросов, идентификатора-
ми и соответствующими им ответами сервера, если будет периодически прослушивать и
перехватывать трафик между клиентом и сервером. Увидев запрос с уже встречавшимся
ранее аутентификатором, противник замаскирует себя под сервер и повторит наблюдав-
шийся ранее ответ. Кроме того, противник может воспроизвести похожий на правду от-
вет сервера типа Access-Accept и тем самым аутентифицироваться, не представив кор-
ректных «верительных грамот».

Проблемы, связанные с разделяемым секретом
Стандарт протокола RADIUS допускает использование одного и того же разделяемого секрета
многими клиентами. Это небезопасно, так как позволяет некорректно реализованным клиен-
там скомпрометировать сразу много машин. Мы рекомендуем задавать разные разделяемые
секреты для каждого клиента, причем выбирать слова, отсутствующие в словаре, чтобы их не-
возможно было угадать. При этом позаботьтесь и о физической безопасности клиентов.
Инструменты, относящиеся к RADIUS
Ниже перечислен ряд альтернативных RADIUS-серверов, а также несколько утилит для
администрирования и мониторинга работы пользователей:
о Cistron. Этот бесплатный сервер, написанный Мигелем ван Смуренбургом (Miquel
van Smoorenburg) на базе исходных текстов сервера Livingston, нашел широкое
294 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
применение. На посвященной ему странице можно най-
ти более подробную информацию;
о ICRADIUS. Это вариант Cistron с поддержкой MySQL и интерфейсом для Web. Страни-
ца проекта размещена по адресу ;
о XtRADIUS. Еще один вариант Cistron с расширениями для запуска внешних программ
аутентификации и учета. Детали см. на странице ;
о OpenRADIUS. Совершенно новая реализация сервера, управляемая подключаемыми
модулями. Страница проекта размещена по адресу ;
о GNU-radius. Еще один вариант Cistron. Значительная часть кода переписана. Подроб-
ности на странице />о YARD RADIUS. Основан на открытых исходных текстах сервера Livingston Radius
Server 2.1. Имеет альтернативную схему конфигурирования и много дополнитель-
ных возможностей. Дистрибутив можно скачать со страницы />projects/yardradius;
о Accounting logparser. Это написанный на Perl сценарий для анализа учетного прото-
кола RADIUS. Он включает средства формирования различных отчетов. Подробнее
см. на странице />о RadiusReport. Это тоже утилита для анализа протоколов, написанная на Perl. Она
позволяет генерировать разнообразные отчеты на основе одного или нескольких
файлов протоколов RADIUS. Подробнее о реализации см. />projects/radiusreport;
о RadiusSplit. Этот сценарий предназначен для сортировки учетных файлов RADIUS,

чтобы их затем можно было обработать с помощью RadiusReport. В результате на-
много сокращается время, необходимое для анализа. Скачать программу можно со
страницы />о RadiusContext. Это набор утилит для быстрого и эффективного анализа протоко-
лов. Утверждается, что они работают намного быстрее и потребляют существен-
но меньше памяти, чем сценарий RadiusReport. Программы написаны на языке
Python и доступны для скачивания на странице />radiuscontext.
802.1х: на страже беспроводной крепости
802.1х - это стандарт, в котором определена безопасность на уровне портов для гетеро-
генных сетей. Первоначально он был разработан для проводных сетей, а теперь адаптиро-
ван и для беспроводных и стал частью стандарта 802.Hi. Необходимость адаптации была
вызвана, главным образом, желанием авторизовать законных пользователей и ограничить
всем остальным доступ к принципиально небезопасной беспроводной среде. Стандарт
802.11 и протокол ЕАР стали очень популярны по мере роста числа беспроводных сетей,
так что все большее число компаний принимают на вооружение эту комбинацию. Тому есть
следующие причины:
о ее сравнительно легко реализовать, поскольку для аутентификации и инфраструктуры
безопасности в целом применяются уже давно известные средства, к примеру RADIUS;
о она обеспечивает высокую степень безопасности;
802.1Х: НА СТРАЖЕ БЕСПРОВОДНОЙ КРЕПОСТИ 295
о в схеме аутентификации применяются сеансовые и пакетные ключи, в том числе
основанные на инфраструктуре PKI;
о имеется поддержка для одноразовых паролей и смарт-карт;
о она легко масштабируется по мере роста сети.
В этом разделе мы продемонстрируем методику внедрения схемы безопасного доступа к бес-
проводной сети на базе стандарта 802.1х и протокола стойкой аутентификации на уровне 2,
например, EAP-TLS. Кроме того, мы покажем, как на практике сочетание 802.1х и EAP-TLS
можно применить в различных сценариях на базе модели клиент-сервер в Windows и UNIX.
Основы EAP-TLS
В документе RFC 2284 протокол ЕАР описан следующим образом: «Расширяемый протокол
аутентификации (ЕАР) - это общий протокол для аутентификации поверх протокола РРР, ко-

торый поддерживает несколько механизмов аутентификации. ЕАР не выбирает конкретный
механизм аутентификации на этапе управления каналом, а откладывает выбор до этапа аутен-
тификации. Это позволяет аутентификатору запросить больше информации еще до выбора
конкретного механизма. Это также открывает возможность для применения поддерживающе-
го сервера, который и реализует различные механизмы, тогда как аутентификатор на уровне
РРР просто пропускает через себя все необходимые для аутентификации сообщения».
После того как канал установлен, аутентификация по протоколу ЕАР выполняется в сле-
дующем порядке:
о первоначально аутентификатор посылает запросы для аутентификации претенден-
та. В запросе есть поле типа, показывающее, что именно запрашивается. Вот не-
сколько примеров запросов разных типов: идентификация, МБ5-запрос, одноразовый
пароль, некая карта с записанной на ней информацией и т.д. Аутентификатор посы-
лает начальный запрос идентификации (Identity Request), за которым следует один
или несколько запросов о предоставлении информации для аутентификации;
о затем претендент посылает ответ на каждый запрос. В пакете, содержащем ответ,
также есть поле типа, соответствующее полю типа в запросе;
о аутентификатор завершает процесс аутентификации отправкой пакета об успехе
или неудаче аутентификации.
На рис. 13.3 показан процесс аутентификации по протоколу EAP-TLS.
296
А
ВОРОТА
КРЕПОСТИ:
АУТЕНТИФИКАЦИЯ
ПОЛЬЗОВАТЕЛЕЙ
У протокола ЕАР много достоинств, в том числе поддержка различных методов аутенти-
фикации без необходимости фиксировать какой-то механизм на этапе управления кана-
лом. Кроме, того, оборудование NAS-сервера не обязано понимать все типы запросов и
может просто работать как агент, переадресующий запросы RADIUS-серверу. Следователь-
но, само устройство должно лишь отслеживать ответы сервера об успешной или неудач-

ной аутентификации, чтобы знать, каков был результат.
Формат пакета
Согласно RFC 2284, «один пакет РРР ЕАР инкапсулируется в поле Information фрейма
канального уровня РРР, причем поле протокола должно содержать шестнадцатеричное
значение С227 (РРР ЕАР)». На рис. 13.4 представлена структура пакета протокола ЕАР.
Структура сообщения ЕАР аналогична структуре пакета RADIUS, которая рассматрива-
лась в первой части этой главы, поэтому здесь мы ее подробно обсуждать не будем. Де-
тальная информация о типах пакетов ЕАР приведена в RFC 2284.
Ознакомившись с основными идеями аутентификации на базе стандарта 802.1х с про-
токолом ЕАР, мы можем перейти к следующей части, где будет приведен практический
пример того, как интегрировать описанную схему в работающую домашнюю или корпо-
ративную беспроводную сеть. Мы будем предполагать, что имеется операционная систе-
ма Debian Linux с сервером FreeRADIUS и точкой доступа Orinoco AP-2000, выступающей
в роли NAS-сервера для аутентификации клиентов на платформах Linux и Windows. Нам
понадобятся еще некоторые утилиты и сценарии, с которыми мы ознакомимся по ходу
изложения.
Создание сертификатов
Для построения механизма аутентификации пользователей на базе архитектуры PKI нуж-
но выпустить сертификаты для клиентов и сервера, для чего понадобится развернуть удо-
стоверяющий центр (СА - Certification Authority).
С этой целью мы воспользуемся набором сценариев, взятых из написанного Раймондом
Мак-Кеем (Raymond McKay) документа EAP/TLS H0WT0 и слегка подправленных. Сценарии
называются CA.root, CA.server и CA.client. Еще нам понадобится файл xpextensions. Прежде
чем пользоваться ими, убедитесь, что установлен пакет OpenSSH, и измените в тексте сце-
нариев путь к каталогу SSL в соответствии со своим сервером, если, конечно, в вашем ди-
стрибутиве Debian Linux они уже не подправлены. Кроме того, рекомендуется изменить
повсюду пароль в запросе с testinglll на что-нибудь более подходящее.
802.1Х: НА СТРАЖЕ БЕСПРОВОДНОЙ КРЕПОСТИ 297
Для начала сгенерируем корневой удостоверяющий центр, запустив сценарий CA.root и
ответив на вопросы об организации: местоположение, название, организационная едини-

ца и т.д. В результате будут созданы следующие файлы:
После создания удостоверяющего центра можно выпустить сертификат для сервера, за-
пустив сценарий CA.server и указав в качестве параметра имя сервера, например:
arhontus:-# ./CA.server radius.core.arhont.com
В результате будет создан набор файлов с сертификатом сервера, которые позже нужно
будет интегрировать с RADIUS-сервером. Вот эти файлы:
Последний шаг - создание сертификатов для каждого пользователя с помощью сцена-
рия CA.client, которому передается имя пользователя без пробелов в том виде, в котором
оно представлено в файле users RADIUS-сервера:
В результате для каждого клиента будут созданы такие файлы:
Создав все необходимые сертификаты, скопируйте файлы root.der и <usemame>.pl2 на
каждый из клиентских компьютеров и установите их для всех клиентов на платформе
Windows. Процедура установки сертификатов рассматривается ниже в разделе «Претенден-
ты». Кроме того, файлы root.pem и <servemame>.pem понадобятся для настройки
FreeRADIUS-сервера, о которой будет рассказано в следующем разделе. Из соображений
совместимости мы рекомендуем также поместить копию сгенерированных сертификатов в
каталог OpenSSL, указанный в файле openssl.cnf (обычно /etc/ssl).
Как практически все в мире UNIX, процедура конфигурирования сервера FreeRADIUS в ОС
Linux проста, изящна и логична. В предыдущем разделе вы уже познакомились с протоко-
лом RADIUS и, надеемся, установили и сконфигурировали сервер. Здесь мы расскажем, как
298^ ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
активизировать поддержку протокола EAP-TLS, чтобы мобильные пользователи смогли ав-
торизоваться в вашей беспроводной сети по технологии PKI.
В этом примере мы предполагаем, что вы создали каталог /etc/lx с правами, разре-
шающими читать его FreeRADIUS-серверу. Поместите в этот каталог файлы root.pem и
<servername.pem> и тоже разрешите серверу их читать. Поскольку вы уже отредакти-
ровали файл clients.conf и разрешили оборудованию доступа к сети соединяться с сер-
вером, то осталось лишь изменить файлы users и radiusd.conf, после чего интеграция
802.1x/EAP/RADIUS будет завершена.
Файл radiusd.conf

Найдите раздел, посвященный конфигурации ЕАР. Он начинается с таких строк:
# Extensible Authentication Protocol
#
# For all ЕАР related authentications
eap {
802.1Х: НА СТРАЖЕ БЕСПРОВОДНОЙ КРЕПОСТИ 299
Затем отредактируйте раздел Authentication и раскомментарьте все ссылки на ЕАР. Прежде
чем приступать к редактированию файла users, нужно будет создать два файла со случайными
данными и сделать их доступными для чтения процессу FreeRADIUS. В файле radiusd.conf пути
к этим файлам являются значениями переменных dh_f Ней random_f i I e. Например, мож-
но создать их следующим образом:
arhontus:~# dd if=/dev/urandom of=/etc/lx/DH bs=lK count=2048
arhontus:~# dd if=/dev/urandom of=/etc/lx/randomH bs=lK count=2048
Файл users
Для каждого пользователя, который будет проходить аутентификацию по протоколу ЕАР-
TLS, добавьте в файл users следующую строку (в ней <clientname> должно в точности
совпадать со значением поля Common Name, указанным при создании клиентского серти-
фиката):
"<clientname>" Auth-Type := ЕАР
Теперь можно перезапустить FreeRADIUS-сервер. Далее мы опишем процедуры конфи-
гурирования аутентификации клиентов.
Претенденты
До сих пор мы имели дело, главным образом, с серверной стороной процедуры аутентифика-
ции, теперь перейдем к клиентской. Сначала опишем конфигурацию клиента на платформе
Linux с помощью приложения XSupplicant, а затем утомительную последовательность щелч-
ков мышью, необходимую для конфигурирования Windows-клиентов. Ладно, я и без вас знаю,
что справедливость искать бесполезно! Вам не только приходится платить за этот «стабиль-
ный, дружественный и работающий софт», но еще и тратить драгоценное время, пробиваясь
сквозь дебри его настроек, аки обезьяна! Но в конце-то концов разве администратору платят
не за это? Не станем ввязываться в споры о том, что лучше - Windows или Linux.

Linux
Приводимые ниже инструкции должны работать в любом дистрибутиве Linux. Сначала нужно
скачать с сайта и установить программу Xsupplicant. Во время работы
над книгой последней стабильной версией была 0.6, но можно взять версию и из CVS-хранили-
ща, которая обычно работает не хуже, зато имеет больше возможностей. Скачав дистрибутив,
выполните следующие команды, чтобы развернуть архив, собрать и установить пакет:
arhontus:~$ tar zxvf xsupplicant-0.б.tar. gz
arhontus:~$ cd xsupplicant
arhontus:~$ ./configure
arhontus:~$ make
arhontus:~$ make install
Успешно завершив установку, скопируйте файл ./etc/lx.conf в каталог /etc/lx и отре-
дактируйте его, как показано ниже, заменив <clientname> точно той строкой, которая
была указана в качестве значения поля Common Name при создании сертификата.
300 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
802.1Х: НА СТРАЖЕ БЕСПРОВОДНОЙ КРЕПОСТИ 301
параметры сетевого интерфейса. На этом процедура Инсталляции клиента Xsupplicant в
Linux завершена.
Windows 2000 и Windows XP
В этом разделе обсуждается процедура установки сертификата, а также настройка сетево-
го соединения, для которого аутентификация будет производиться по протоколу 802.1х/
EAP-TLS. К счастью, в Windows XP имеется встроенная поддержка для аутентификации по
протоколу 802.1х, так что скачивать из сети дополнительные программы не понадобится.
Пользователи же Windows 2000 должны будут поставить патч, который дает возмож-
ность аутентифицироваться по протоколу 802.1х. Загрузить его можно с сайта Microsoft
( />После установки и перезапуска компьютера можно будет активизировать этот сервис, от-
крыв Панель управления (Control Panel), выбрав пункты Administrative Tasks => Services
(Административные задачи => Сервисы) и установив для сервиса Wireless Configuration ав-
томатический режим запуска (Automatic). Затем этот сервис надо будет запустить.
Следующие инструкции должны работать и в Windows 2000, и в Windows XP. Активизи-

ровав сервис Wireless Configuration Service, вы сможете импортировать сертификаты root.der
и <clientname>.pl2, выполнив следующие действия: дважды щелкните мышью по файлу
root.der и следуйте инструкции для его установки в папку Trusted Root Certificate Authrities
(Доверенные корневые удостоверяющие центры) - рис. 13.5 и 13.6.
Покончив с этим, вы должны будете установить закрытый ключ, дважды щелкнув по
файлу <clientname>.p!2 и выполнив инструкции Мастера (рис. 13.7 и 13.8).
302 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
После установки сертификата вы должны будете разрешить использовать на данном се-
тевом соединении протокол 802.1х/ЕАР. Для этого откройте Панель управления, выберите
пункт Network Connections (Сетевые соединения), щелкните правой кнопкой мыши по
802.1Х: НА СТРАЖЕ БЕСПРОВОДНОЙ КРЕПОСТИ 303
беспроводному соединению (представленному, например, иконкой Local Area Connection
(Локальное соединение)), выберите из контекстного меню пункт Properties (Свойства), пе-
рейдите на вкладку Authentication (Аутентификация) и отметьте флажки, как показано
на рис. 13.9 и 13.10.
304 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
После выполнения всех этих инструкций ваш сертификат должен автоматически аутен-
тифицироватъся RADIUS-сервером. Если возникнут сложности, запустите сервер FreeRADIUS
в режиме отладки, например с флагами -X -А, и исправьте все ошибки, о которых говорится
в диагностических сообщениях. Если это не получается, обратитесь к группе пользователей
FreeRADIUS ( и попросите у них совета.
Пример конфигурирования точки доступа Orinoco AP-2000
Порядок включения аутентификации по протоколу 802.1х/ЕАР на оборудовании для дос-
тупа в сеть должен быть одним и тем же вне зависимости от производителя. В качестве
примера опишем процедуры настройки точки доступа Orinoco AP-2000, которая была лю-
безно предоставлена компании Arhont для тестирования фирмой Proxim.
Зайдите на точку доступа, выберите в меню пункт Configure и щелкните по элементу
RADIUS. Введите параметры вашего FreeRADIUS-сервера, в том числе разделяемый секрет,
который был задан в файле clients.conf. Необходимо также включить учетный протокол
RADIUS. Окно должно выглядеть примерно так, как показано на рис. 13.11 и 13.12.

Теперь перейдите на вкладку Security (Безопасность) и в списке 802.IX Security Mode
(Режим безопасности для 802.1х) выберите элемент Mixed Mode (Смешанный режим), ко-
торый обеспечивает совместимость с существующими пользователями WEP и клиентами с
поддержкой 802.1х. Если вы вообще не хотите использовать WEP, оставьте только прото-
кол 802.1х, а шифрование по протоколу WEP отключите вовсе.
Чтобы новые параметры вступили в силу, точку доступа придется перезагрузить (рис. 13.13
и 13.14). Все, можете наслаждаться аутентификацией по протоколу EAP-TLS.
802.1Х: НА СТРАЖЕ БЕСПРОВОДНОЙ КРЕПОСТИ 305
306 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
Служба каталогов LDAP
Обзор
Что такое служба каталогов
Каталог - это база данных, оптимизированная для чтения, поиска и навигации. Обычно каталоги
содержат различные описания и информацию, основанную на атрибутах, и применяются для
осуществления быстрого и точного поиска. Каталоги надо настраивать для получения быстрого
ответа на запросы, требующие просмотра большого объема информации. Каталог может под-
держивать репликацию между схожими серверами для повышения доступности и надежности
предлагаемого сервиса. Когда база данных реплицируется, возможны временные рассогласо-
вания между репликами, которые должны устраняться в максимально сжатые сроки.
Что такое LDAP
Аббревиатура LDAP означает Lightweight Directory Access Protocol (Облегченный протокол
службы каталогов). Информационная модель в LDAP состоит из ряда отдельных записей
(Entries), имеющих глобально уникальные различимые имена (Distinguished Name - DN),
в каждой из которых хранится набор атрибутов. У каждого атрибута в записи есть тип и
одно или несколько значений. Типы обычно представляют собой строки, например, uid
СЛУЖБА КАТАЛОГОВ LDAP 307
(идентификатор пользователя), сп (полное имя), sn (фамилия) или mail (адрес элект-
ронной почты). Например, значением атрибута сп может быть строка Gordon Collins,
а атрибут mail может иметь значение gordon@arhont. com.
В модели LDAP записи каталога организованы в виде иерархического дерева. На рис. 13.15

показан пример структуры каталога. По традиции структура отражает географические или
организационные границы. Записи, относящиеся к странам, находятся на вершине дерева, а
ниже них - записи, представляющие национальные организации. Далее могут располагать-
ся записи, описывающие организационные единицы, людей, принтеры, документы, да и во-
обще все что угодно. Можно предложить и иную структуру, основанную на доменных име-
нах; она приобретает все большую популярность. Как видно из рис. 13.15, структура каталога
для нашей компании Arhont базируется на доменном имени (то есть dc=arhont, dc=com),
а не на географическом делении (o=arhont, c=UK).
Рис. 13.15. Структура каталога LDAP
Запись каталога идентифицируется своим различимым именем DN, которое составлено
из имени самой записи и всех ее предков. Так, запись, описывающая человека по имени
Gordon Collins из предыдущего примера, адресуется следующим образом:
Как работает LDAP
Служба каталогов LDAP основана на модели клиент-сервер. На одном или нескольких LDAP-
серверах хранятся данные, составляющие информационное дерево каталога. Клиент соеди-
няется с LDAP-сервером и запрашивает конкретную информацию. Сервер обращается к базе
308 ВОРОТА КРЕПОСТИ: АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
данных и возвращает ответ или указывает на другой сервер, где можно найти необходи-
мую информацию. С каким бы LDAP-сервером ни соединился клиент, он видит одинаковое
представление каталога. Иными словами, имя, передаваемое в запросе, одинаково для всех
серверов, и это важная отличительная особенность глобальной службы каталогов.
Установка OpenLDAP
В этом разделе мы опишем процедуру установки LDAP-сервера. В этой книге рассматрива-
ется только сервер OpenLDAP, хотя вы можете выбрать любую другую реализацию по сво-
ему усмотрению. Во время работы над этой книгой последней версией OpenLDAP была
2.1.20, а последней стабильной - 2.1.17. Мы рекомендуем пользоваться стабильной верси-
ей пакета, хотя в более поздних могут быть реализованы и дополнительные возможности.
Ознакомиться с информацией об этом проекте и скачать дистрибутив можно на сайте
/>Зависимости
Пакет OpenLDAP зависит от ряда других программных пакетов. Возможно, вам придется

установить и дополнительные инструменты. В этом разделе мы расскажем о наиболее рас-
пространенных пакетах, которые приходится устанавливать и конфигурировать для сбор-
ки OpenLDAP. У некоторых из них могут быть и дополнительные зависимости, которые тоже
придется учесть.
Transport Layer Security (TLS). Для клиентов и серверов OpenLDAP требуется установить
библиотеки OpenSSL TLS, предоставляющие сервисы безопасности транспортного уровня
(TLS). Эти библиотеки входят в состав пакета OpenSSL, который можно скачать с сайта
.
Сервисы аутентификации Kerberos. В OpenLDAP имеется поддержка сервисов аутенти-
фикации на базе Kerberos. В частности, OpenLDAP поддерживает механизм аутентифика-
ции SASL/GSSAPI с помощью пакетов Heimdal или MIT KerberosV. Если вы собираетесь ис-
пользовать механизм SASL/GSSAPI, то потребуется установить хотя бы один из этих пакетов.
Пакет Heimdal Kerberos можно скачать с сайта а пакет MIT
Kerberos - с сайта />Simple Authentication and Security Layer (Слой простой аутентификации и обеспечения
безопасности - SASL). Чтобы OpenLDAP предоставлял сервис SASL, необходимо установить
библиотеки Cyrus SASL. В некоторых операционных системах они входят в состав базового
дистрибутива, в других требуют отдельной инсталляции. Скачать пакет можно со страни-
цы />Базы данных. Сервер OpenLDAP, который мы в дальнейшем будем называть просто slapd,
в качестве основного хранилища использует базу данных Sleepycat Software Berkeley DB
версии 4. Этот пакет может входить в базовый дистрибутив операционной системы или
включаться в качестве необязательного компонента. Если это не так, то придется собрать
его самостоятельно. Скачать пакет можно с сайта компании Sleepycat Software по адресу
/>TCP Wrappers. Slapd поддерживает технологию обертывания TCP (фильтры управления досту-
пом на уровне IP), если этот пакет заранее установлен. Для промышленных серверов рекоменду-
ется пользоваться либо TCP Wrappers, либо другими фильтрами на уровне IP (например, Netfilter).