WPA Enterprise на дому

ЧАСТЬ 1 Ломаете голову, чем бы заняться дождливым осенним вечером? Андрей Боровский припас для вас учебник по укреплению безопасности домашней сети.

Как появляется домашняя компьютерная сеть? Сначала у вас дома только один компьютер, затем вы покупаете новый. Старую машинку выбрасывать жалко, продать – некому. Вы связываете два компьютера витой парой. Затем вы покупаете ноутбук. Помимо всего прочего, ноутбук – очень подходящее устройство для того, чтобы бродить по всемирной паутине, лежа на диване, или слушать интернет-радио, сидя на балконе. Однако таскать витую пару вслед за ноутбуком неудобно, и поэтому вы устанавливаете беспроводную сеть. В процессе установки беспроводной сети у себя дома большинство пользователей идет по пути наименьшего сопротивления, что, увы, делает их творения крайне небезопасными. Статистические исследования я не проводил, но сканирование эфира в доме, где я живу, выявило три Wi-Fi сети (помимо моей собственной), две из которых вообще не были защищены. Об уязвимости простого протокола защиты WEP было сказано столько, что распространяться на эту тему представляется излишним. Необходимый и достаточный уровень защиты домашних беспроводных сетей может быть обеспечен протоколами WPA/WPA2 с разделяемым ключом (pre-shared key, PSK). Настроить этот протокол не намного сложнее, чем обычный WEP. Недостатки WPA-PSK, главный из которых – использование одного и того же ключа на всех клиентских машинах, в домашней сети несущественны. Однако, хотя WPA-PSK является вполне надежным методом защиты небольшой беспроводной сети, среди пользователей Linux наверняка найдутся такие, которые, как и я, не захотят останавливаться на достигнутом. Ведь каждый домашний пользователь Linux, в некотором смысле, исследователь. Практически каждый стремится выйти за рамки простейшей технологии, ориентированной на «чайников», и опробовать другие, предоставляющие более широкие возможности. Сегодня мы поговорим о том, каким образом домашний Linux-сервер может расширить возможности вашей беспроводной сети с помощью сервера FreeRADIUS, который является наиболее популярной на сегодняшний день реализацией сервера протокола RADIUS.

Радиус чего?

Аббревиатура RADIUS расшифровывается как Remote Authentication Dial-In User Service [Служба удаленной аутентификации входящих пользователей]. Словосочетание Dial-In не должно вводить вас в заблуждение. Протокол RADIUS используется для авторизации, аутентификации и учета пользователей в самых разных системах (в том числе и беспроводных). Для того, чтобы понять, нужен ли вам RADIUS-сервер и как его использовать, вы должны понимать место протокола RADIUS в системе аутентификации и авторизации. Протокол RADIUS полностью абстрагирован не только от технологии связи, но и от протоколов передачи данных в сети, в которой происходит авторизация. Фактически функция сервера RADIUS сводится к тому, что сервер принимает информацию, которую пользователь сети предоставляет в процессе аутентификации, и авторизует пользователя. Это означает, что использование сервера RADIUS не может сделать безопаснее сам процесс передачи данных в сети (оно может обезопасить только процесс передачи данных в ходе аутентификации, что, конечно, тоже немаловажно). После того как процесс авторизации пользователя в сети завершился, сервер RADIUS ему больше не нужен, по крайней мере, до тех пор, пока пользователю не понадобится снова авторизоваться в системе.

Каковы преимущества авторизации с помощью RADIUS перед авторизацией с помощью предустановленного ключа? Прежде всего, использование RADIUS позволяет дифференцировать пользователей. Предустановленный ключ у всех пользователей общий, а RADIUS позволяет выдать каждому пользователю персональное имя учетной записи и пароль (или персональный сертификат). Второе преимущество RADIUS заключается в возможности вести учет сетевой активности пользователей. Беспроводные сети активно замещают собой не только последнюю милю, по которой трафик подается конечным ользователям, но и витую пару, которую жильцы дома могут проложить между квартирами. Впрочем, забудьте, что я это говорил…

Протокол RADIUS применяется уже довольно давно. Несколько лет назад строителям беспроводных сетей был предложен протокол DIAMETER. Этот протокол, как можно догадаться из его названия, представляет собой улучшенную версию RADIUS. Впрочем, не смотря на готовую замену, RADIUS по-прежнему процветает, а дополнительные возможности DIAMETER вряд ли понадобятся администраторам небольших сетей, да и далеко не все сетевое оборудование, доступное на сегодняшний день, поддерживает эти возможности.

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

Не следует, однако, думать, что FreeRADIUS – редкий гость в малых сетях. По данным разработчиков, сервера сети с небольшим числом узлов (до 10) составляют около 14% от общего числа сетей, использующих FreeRADIUS, и это не мало, если учесть широкий спектр применения сервера (в том числе, в сетях с десятками и даже сотнями тысяч узлов).

Враг не пройдет!

Каковы же дополнительные возможности аутентификации, предоставляемые сервером RADIUS? В настройках клиентского ПО беспроводной сети вы можете встретить аббревиатуры EAP, EAP-TLS, PEAP-MSCHAP-V2 и другие. Они обозначают различные протоколы (а иногда и семейства протоколов) аутентификации. Так, EAP (Extensible Authentication Protocol, Расширяемый протокол аутентификации) представляет собой контейнер для протоколов, фактически осуществляющих передачу запросов на аутентификацию и ответов аутентификатора. Поскольку EAP абстрагирован от конкретных процедур аутентификации, сетевое оборудование, поддерживающее EAP, тоже не связано с какими-либо конкретными протоколами (в частности, это означает, что оборудование, поддерживающее WPA и WPA 2, может работать с одними и теми же протоколами аутентификации). Новые протоколы аутентификации могут свободно применяться на старом оборудовании.

Компания Microsoft разработала на основе EAP протокол EAP-TLS, принятый позднее в качестве стандарта. Протокол EAP-TLS (Extensible Authentication Protocol – Transport Layer Security) реализует двустороннюю аутентификацию с использованием сертификатов X.509 обеими сторонами. PEAP (Protected Extensible Authentication Protocol) представляет собой проприетарное расширение протокола EAP. В отличие от EAP, протокол PEAP создает безопасный туннель перед началом процесса аутентификации. Далее по этому туннелю передаются данные для аутентификации. Наличие безопасного туннеля затрудняет перехват данных злоумышленником. Как и EAP, PEAP представляет собой контейнер для высокоуровневых протоколов аутентификации, например, для MSCHAP, в которых аутентификация выполняется с помощью имени учетной записи и пароля (стоит отметить, что изначально PEAP предназначался для более продвинутых протоколов аутентификации, нежели MSCHAP, но в настоящее время устройства доступа поддерживают PEAP-MSCHAP V2). Еще один проприетарный протокол, EAP-TTLS, также использует безопасные туннели для передачи данных. EAP-TTLS интересен тем, что рассматривается IETF как будущий стандарт безопасной аутентификации. Как и в EAP-TLS, в EAP-TTLS реализована двусторонняя аутентификация (сервер удостоверяет себя с помощью сертификата X.509). Мы же рассмотрим аутентификацию с помощью PEAP-MSCHAP V2 и EAP-TLS.

Скорее всего, ваш дистрибутив Linux содержит пакет FreeRADIUS. Последнюю версию сервера (а при работе с программами, связанными с безопасностью, всегда следует использовать последнюю версию) можно загрузить с сайта проекта www.freeradius.org. В этой статье рассматривается новейшая на данный момент версия FreeRADIUS 1.1.7, установленная из исходных текстов.

Установим FreeRADIUS

По умолчанию в системе Linux исполняемый файл FreeRADIUS (RADIUSd) устанавливается в директорию /usr/local/sbin. Директория /usr/local/etc/raddb/ содержит файлы конфигурации сервера. Основные настройки сервера содержатся в файле radiusd.conf. Домашнему сетестроителю, скорее всего, не придется вносить изменения в этот файл. Если же вы хотите, чтобы сервер RADIUS был связан только с одним IP-адресом (по умолчанию сервер регистрируется на всех IP той машины, на которой он запущен) или прослушивал нестандартный порт, подробные комментарии в файле подскажут вам, как его редактировать. Cправку о структуре файла radiusd.conf можно также получить по команде


man 5 radiusd.conf
В процессе настройки сервера я рекомендую запускать его с ключами -fx. Ключ -f позволяет запустить программу в терминале (а не в виде демона), а ключ -x включает режим частичного отображения отладочных сообщений, которые помогут вам найти и исправить неизбежные ошибки, возникающие в процессе настройки сервера. Если во время запуска сервера не возникло никаких проблем, серия сообщений, выводимых сервером в режиме отладки должна закончиться строками


Listening on authentication *:1812
Listening on accounting *:1813
Ready to process requests.
Порт 1812 по умолчанию принимает запросы от аутентификатора, а порт 1813 используется для обработки учетной информации о пользователях сети. После этого сервер переходит в режим ожидания запросов на аутентификацию. Теперь, когда вы убедились, что сервер запускается, вы можете приступить к настройке взаимодействия сервера и точки доступа. Для этого ее адрес, а также некоторые другие параметры, должны быть прописаны в файле clients.conf (название файла объясняется тем, что для сервера RADIUS точки доступа выступают в роли клиентов).

Сервер RADIUS может обслуживать несколько аутентификаторов одновременно, и каждому из них в файле cliens.conf должна соответствовать одна запись вида:


client 192.168.1.50/24 {
secret = ...
shortname = private-network-1
nastype = other
}
Здесь 192.168.1.50/24 – адрес аутентификатора в сети, параметру secret должен быть присвоен секретный ключ аутентификатора. Этот ключ используется для шифрования и подписи сообщений, которые аутентификатор посылает серверу RADIUS. Параметр shortname содержит имя узла точки доступа. Для каждого аутентификатора можно также указать его тип (параметр nastype). Если вашей модели аутентификатора нет в списке моделей, известных серверу, присвойте этому параметру значение other, или просто удалите его из записи. Более подробные сведения о файле clients.conf вам даст вам команда


man 5 clients
После настройки файла clients.conf следует настроить саму точку доступа. Обычно в настройках точки доступа указываются адрес и порт сервера, а также секретный ключ – тот же, что и в параметре secret.

Теперь вы можете проверить, обращается ли точка доступа к серверу RADIUS. При попытки авторизации беспроводного клиента в сети в окне терминала, в котором запущен сервер (напомню, что мы запускаем его с ключами -fx), должна появиться серия сообщений вида


rad_recv: Access-Request packet from host 192.168.1.50:1812, id=7,
length=197
Sending Access-Reject of id 6 to 192.168.1.50 port 1812
Сервер получил запрос от точки доступа, но отказал пользователю в авторизации, поскольку требуемой учетной записи еще не существует.

Однако прежде чем перейти к созданию учетной записи пользователя на сервере рассмотрим, еще один важный файл настроек. Сервер FreeRADIUS имеет модульную структуру, и для того, чтобы он мог обрабатывать запросы по тому или иному протоколу, сервер должен загрузить модуль, в котором реализована поддержка данного протокола. Для наших экспериментов нам понадобятся модули eap, mschapv2, tls, ttls и peap (их названия соответствуют названиям протоколов аутентификации, которые они поддерживают). Загрузкой модулей протоколов и их настройкой управляет файл eap.conf. Чтобы сервер загружал необходимые модули, нам нужно раскомментировать соответствующие им записи в eap.conf. Они имеют следующий вид


имя_модуля {
параметр = значение
...
}
Нам пока не требуется изменять значения параметров модулей – достаточно просто убрать значки комментариев (модули eap и mschapv2 загружаются по умолчанию, так что их записи в файле eap. conf действительны).

Настроим: PEAP MS CHAP V2

Данные учетных записей пользователей для аутентификации по протоколу PEAP MS CHAP V2 хранятся в файле users (а не users.conf, как можно было бы ожидать). Подробную информацию об этом файле вы можете получить с помощью команды >


man 5 users
Сервер FreeRADIUS может хранить данные учетных записей не только в файле users, но и в базах данных на серверах MySQL, SQL Server, Oracle, однако для домашней сети использование сервера БД для хранения данных о пользователях – пустое расточительство вычислительных ресурсов, и мы его рассматривать не будем. Предполагается также, что в вашей домашней сети отсутствуют контроллеры доменов. Кроме того, для простоты изложения мы присвоим клиентской машине статический адрес.

При настройке учетной записи пользователя, проходящего аутентификацию по протоколу MS-CHAP V2, в файл users следует добавить запись вида:


user1 User-Password = "**********"
Service-Type = Framed-User,
Framed-Protocol = SLIP,
Framed-IP-Address = 192.168.1.3,
Framed-IP-Netmask = 255.255.255.0,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = "std.ppp",
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP
Этот фрагмент текста описывает учетную запись пользователя с именем user1. Атрибут User-Password содержит пароль (который должен быть заключен в кавычки). Атрибут Framed-Protocol позволяет указать протокол, используемый для передачи данных между клиентом и сетью. Возможные значения этого атрибута – SLIP и PPP. Протокол PPP обладает более широкими возможностями, но для домашней сети нам вполне достаточно SLIP. Атрибуты Framed-IP-Address и Framed-IP- Netmask указывают адрес нового узла сети и маску подсети. Атрибут Framed-MTU позволяет указать значения MTU. Последние три атрибута должны соответствовать настройкам клиентской машины. После того как вы перезапустите сервер и настроите протокол MS-CHAP V2 на клиентской машине, ваш компьютер может регистрироваться в беспроводной сети с помощью имени пользователя и пароля.

Настроим: EAP-TLS

Настройка аутентификации с помощью сертификатов X.509 требует больших усилий. Прежде всего, нам следует создать сами сертификаты, для чего мы воспользуемся утилитой openssl. Если для обмена почтой по протоколу SMIME нужен сертификат, выданный общепризнанным удостоверяющим центром, то для аутентификации в беспроводных сетях гораздо удобнее создать собственный корневой сертификат и с его помощью подписывать сертификаты сервера и клиентов. Прежде всего нам нужно сгенерировать 2048-битный ключ для корневого сертификата:


openssl genrsa -des3 -out myroot_ca.key 2048
Ключ будет сохранен в файле myroot_ca.key. Теперь создадим сам сертификат:


openssl req -new -x509 -days 730 -key myroot_ca.key -out myroot_ca.crt
Сертификат, действительный в течение 730 дней, сохраняется в файле myroot_ca.crt. В процессе генерации сертификата программа задаст вам несколько вопросов относительно значений полей сертификата.

Для генерации серверного и клиентского сертификатов, подписанных электронной подписью, заверенной нашим корневым сертификатом, нам понадобится создать специальный файл конфигурации, который будет использовать утилита openssl. Пример файла конфигурации вы найдете на диске (он называется ca.config), приводить его полный текст здесь я не буду. Файл конфигурации содержит ответы на стандартные вопросы, которые задает утилита openssl в процессе генерации сертификата (вы, конечно, захотите заменить эти данные своими собственными). Кроме того, этот файл устанавливает пути к некоторым каталогам, используемым в процессе генерации сертификатов и некоторые дополнительные параметры. Строки


[ xpclient_ext ]
extendedKeyUsage = 1.3.6.1.5.5.7.3.2
[ xpserver_ext ]
extendedKeyUsage = 1.3.6.1.5.5.7.3.1
указывают расширенные параметры сертификата. Они понадобятся в том случае, если вы генерируете сертификаты (клиентский и серверный) для сети, в которой предусмотрена авторизация Windows-клиентов. Файл ca.config ссылается на файлы и директории, который должны быть созданы явным образом (приведенная ниже последовательность команд предполагает, что имена файлов и директорий в ca.conf не были изменены). Сами команды выполняются в той директории, в которой мы сохранили корневой сертификат и его ключ.


mkdir newcerts
touch certs.db.index
echo "01" > certs.db.serial
Теперь мы можем приступить к созданию сертификата сервера. Ключ для него получается уже знакомой нам командой:


openssl genrsa -des3 -out myserver.key 2048
Далее мы создаем запрос на подпись сертификата точно так же, как если бы мы обращались к настоящему УЦ:


openssl req -new -key myserver.key -out myserver.csr
На основе этого запроса мы создаем серверный сертификат с подписью, заверенной корневым сертификатом:


openssl ca -config ca.config -in myserver.csr -out myserver.crt –batch
Сертификат клиента создается по той же схеме:


openssl genrsa -des3 -out user1.key 2048
openssl req -new -key user1.key -out user1.csr
openssl ca -config ca.config -in user1.csr -out user1.crt -batch
Важный момент: имя сертификата клиента (параметр CN) не должно совпадать с именем сертификата сервера и корневого сертификата. Для переноса на платформу Windows сертификат user1.csr следует экспортировать в формате PKCS#12:


openssl pkcs12 -export -in user1.crt -inkey user1.key -out user1.p12
Теперь мы переходим к собственно настройке FreeRADIUS. В директории /usr/local/etc/raddb/certs необходимо создать файл с числами Диффи-Хеллмана (Diffie-Hellmann):


openssl dhparam 512 > /usr/local/etc/raddb/certs/dh
Там же создаем файл случайной последовательности из 1024 байтов:


dd if=/dev/urandom of=/usr/local/etc/raddb/certs/random count=2
Теперь скопируем в директорию /usr/local/etc/raddb/certs файлы myroot_ca.crt, myserver.crt и myserver.key. Нам осталось настроить файлы конфигурации FreeRADIUS, а точнее eap.conf. После редактирования раздел параметров модуля tls в этом файле должен выглядеть примерно так (ради сокращения листинга комментарии пропущены):


tls {
private_key_password = ******
private_key_file = ${raddbdir}/certs/myserver.key
certificate_file = ${raddbdir}/certs/myserver.crt
CA_file = ${raddbdir}/certs/myroot_ca.crt
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
fragment_size = 1024
include_length = yes
check_crl = no
check_cert_issuer = "/C=RU/ST=MOSCOW/L=Moscow/O=Inet
Ltd/CN=Andrei Borovsky/emailAddress=anb@symmetrica.net"
#check_cert_cn = %{User-Name}
cipher_list = "DEFAULT"
}
Атрибут private_key_password должен содержать пароль доступа к секретному ключу серверного сертификата (вы указывали этот пароль, когда создавали соответствующий ключ). Назначение параметров certificate_file, CA_file – на файл корневого сертификата, dh_file и random_file должно быть очевидно. Атрибут check_crl указывает, должен ли сервер сверять сертификат клиента со списком отзыва сертификатов. Мы не создавали список отзыва, поэтому устанавливаем значение no. Атрибут check_cert_issuer определяет, должен ли сервер сверять данные об организации-эмитенте сертификатов с данными, записанными в клиентском сертификате. Вы можете закомментировать строку check_cert_issuer, если не хотите выполнять эту проверку, в противном случае сюда следует вписать данные эмитента клиентского сертификата. Атрибут check_cert_cn указывает шаблон имени пользователя, с которым следует сверять значение CN клиентского сертификата. Следует иметь в виду, что система Windows обычно добавляет к имени пользователя разного рода вспомогательную информацию. Мы можем записать в атрибут check_cert_cn шаблон, позволяющий извлечь настоящее имя пользователя из строки, переданной Windows, а можем отменить эту проверку, закомментировав строку (что мы и делаем). На этом настройка сервера закончена. Нам остается установить корневой и клиентский сертификаты на клиентских машинах (мы не рассматриваем процесс настройки Windows-клиентов; если вы хотите получить подробные инструкции, обратитесь, например, к статье http://www.ixbt.com/comm/prac-wpa-eap.shtml, которая содержит пошаговые инструкции настройки Windows, но несколько устарела в том, что касается FreeRADIUS).

В чем же смысл аутентификации EAP-TLS? Фактически сервер проверяет только то, заверена ли подпись клиентского сертификата известным ему корневым сертификатом. Иначе говоря, для предоставления пользователю доступа к сети достаточно выдать пользователю сертификат, подпись которого удостоверена корневым сертификатом, известным FreeRADIUS. Ну, а поскольку подделать эту подпись достаточно тяжело, злоумышленники, желающие посидеть в Интернете за чужой счет, будут держаться подальше от вашей сети!

Врезка

Терминология

Под аутентификацией понимается процесс, который подтверждает, что пользователь, пытающийся зарегистрироваться в системе, действительно тот, за кого он себя выдает. Авторизация – это процесс, подтверждающий определенные права пользователя, прошедшего аутентификацию. Устройство доступа к сети, реализующее физический уровень системы аутентификации, часто называют аутентификатором.

Как работает сервер RADIUS? Для того чтобы иметь возможность авторизовать пользователей в сети с помощью RADIUS, необходимо чтобы аутентификатор (в случае беспроводной сети – точка доступа) поддерживал протокол RADIUS. Получив запрос на авторизацию, RADIUS-аутентификатор направляет запрос RADIUS-серверу, используя, как ни странно, протокол RADIUS. В зависимости от ответа сервера аутентификатор либо предоставляет пользователю доступ к сети, либо отказывает в доступе.