Сегодня мы чуть глубже копнем тему защиты беспроводного соединения. Разберемся, что такое тип шифрования WiFi – его еще называют “аутентификацией” – и какой лучше выбрать. Наверняка при вам попадались на глаза такие аббревиатуры, как WEP, WPA, WPA2, WPA2/PSK. А также их некоторые разновидности – Personal или Enterprice и TKIP или AES. Что ж, давайте более подробно изучим их все и разберемся, какой тип шифрования выбрать для обеспечения максимальной без потери скорости.

Для чего нужно шифровать WiFi?

Отмечу, что защищать свой WiFi паролем нужно обязательно, не важно, какой тип шифрования вы при этом выберете. Даже самая простая аутентификация позволит избежать в будущем довольно серьезных проблем.

Почему я так говорю? Тут даже дело не в том, что подключение множества левых клиентов будет тормозить вашу сеть – это только цветочки. Главная причина в том, что если ваша сеть незапаролена, то к ней может присосаться злоумышленник, который из-под вашего роутера будет производить противоправные действия, а потом за его действия придется отвечать вам, так что отнеситесь к защите wifi со всей серьезностью.

Шифрование WiFi данных и типы аутентификации

Итак, в необходимости шифрования сети wifi мы убедились, теперь посмотрим, какие бывают типы:

Что такое WEP защита wifi?

WEP (Wired Equivalent Privacy) – это самый первый появившийся стандарт, который по надежности уже не отвечает современным требованиям. Все программы, настроенные на взлом сети wifi методом перебора символов, направлены в большей степени именно на подбор WEP-ключа шифрования.

Что такое ключ WPA или пароль?

WPA (Wi-Fi Protected Access) – более современный стандарт аутентификации, который позволяет достаточно надежно оградить локальную сеть и интернет от нелегального проникновения.

Что такое WPA2-PSK – Personal или Enterprise?

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

У стандартов защиты WiFi WPA2 и WPA есть еще две разновидности:

• Personal, обозначается как WPA/PSK или WPA2/PSK. Этот вид самый широко используемый и оптимальный для применения в большинстве случаев – и дома, и в офисе. В WPA2/PSK мы задаем пароль из не менее, чем 8 символов, который хранится в памяти того устройства, которые мы подключаем к роутеру.
• Enterprise – более сложная конфигурация, которая требует включенной функции RADIUS на роутере. Работает она по принципу , то есть для каждого отдельного подключаемого гаджета назначается отдельный пароль.

Типы шифрования WPA – TKIP или AES?

Итак, мы определились, что оптимальным выбором для обеспечения безопасности сети будет WPA2/PSK (Personal), однако у него есть еще два типа шифрования данных для аутентификации.

• TKIP – сегодня это уже устаревший тип, однако он все еще широко употребляется, поскольку многие девайсы энное количество лет выпуска поддерживают только его. Не работает с технологией WPA2/PSK и не поддерживает WiFi стандарта 802.11n.
• AES – последний на данный момент и самый надежный тип шифрования WiFi.

Какой выбрать тип шифрования и поставить ключ WPA на WiFi роутере?

С теорией разобрались – переходим к практике. Поскольку стандартами WiFi 802.11 “B” и “G”, у которых максимальная скорость до 54 мбит/с, уже давно никто не пользуется – сегодня нормой является 802.11 “N” или “AC”, которые поддерживают скорость до 300 мбит/с и выше, то рассматривать вариант использования защиты WPA/PSK с типом шифрования TKIP нет смысла. Поэтому когда вы настраиваете беспроводную сеть, то выставляйте по умолчанию

Либо, на крайний случай, в качестве типа шифрования указывайте “Авто”, чтобы предусмотреть все-таки подключение устройств с устаревшим WiFi модулем.

При этом ключ WPA, или попросту говоря, пароль для подключения к сети, должен иметь от 8 до 32 символов, включая английские строчные и заглавные буквы, а также различные спецсимволы.

Защита беспроводного режима на маршрутизаторе TP-Link

На приведенных выше скринах показана панель управления современным роутером TP-Link в новой версии прошивки. Настройка шифрования сети здесь находится в разделе “Дополнительные настройки – Беспроводной режим”.

В старой “зеленой” версии интересующие нас конфигурации WiFi сети расположены в меню “Беспроводной режим – Защита”. Сделаете все, как на изображении – будет супер!

Если заметили, здесь еще есть такой пункт, как “Период обновления группового ключа WPA”. Дело в том, что для обеспечения большей защиты реальный цифровой ключ WPA для шифрования подключения динамически меняется. Здесь задается значение в секундах, после которого происходит смена. Я рекомендую не трогать его и оставлять по умолчанию – в разных моделях интервал обновления отличается.

Метод проверки подлинности на роутере ASUS

На маршрутизаторах ASUS все параметры WiFi расположены на одной странице “Беспроводная сеть”

Защита сети через руотер Zyxel Keenetic

Аналогично и у Zyxel Keenetic – раздел “Сеть WiFi – Точка доступа”

Что ж, сегодня мы разобрались типами шифрования WiFi и с такими терминами, как WEP, WPA, WPA2-PSK, TKIP и AES и узнали, какой из них лучше выбрать. О других возможностях обеспечения безопасности сети читайте также в одной из прошлых статей, в которых я рассказываю о по MAC и IP адресам и других способах защиты.

Видео по настройке типа шифрования на маршрутизаторе

АНДРЕЙ ПЛАТОНОВ

Строим защищённую беспроводную сеть: 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.

Здесь уместно закончить небольшое лирически-теоретическое отступление, которое необходимо, для того чтобы получить примерное представление о том, что кроется в недрах безопасной беспроводной сети. Далее будет предложена практическая реализация описанных выше концепций. В качестве сервера 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.

Для начала несколько слов о настройке беспроводной сети, а затем приведем пример конфигурирования 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.

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

Остальные точки доступа настраиваются аналогичным образом, только у них будут другие 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»):

Organizational Unit Name (eg, section) :megacompany.central.office Common Name (eg, YOUR name) :Administrator

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

Organization Name (eg, company) :MegaCompany Co. Ltd. Organizational Unit Name (eg, section) :RADIUS Common Name (eg, YOUR name) :RADIUS Email Address :[email protected]

Копируем файлы /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) :RU

State or Province Name (full name) :Moskow Locality Name (eg, city) :Moskow Organization Name (eg, company) :MegaCompany Co. Ltd. Common Name (eg, YOUR name) :Andrey Ivanov Email Address :[email protected] 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) :RU State or Province Name (full name) :Moscow Locality Name (eg, city) :Moscow Organization Name (eg, company) :MegaCompany Co. Ltd. Organizational Unit Name (eg, section) :IT Department Common Name (eg, YOUR name) :Mikhail Ivanov Email Address :[email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password :whatever An optional company name :

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

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

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

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

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

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

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

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

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

• Здесь надо ввести пароль, который мы установили для сертификата 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).

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

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

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

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

• На всякий случай нажимаем «Просмотр сертификата», и изучаем, кто поставщик сертификата. Удостоверяемся, что это наш корпоративный CA «Administrator», который мы создали (рис. 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 = 0x 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"

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

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

943:error:0E06D06C:configuration file routines:NCONF_get_string:no value: 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: unique_subject = "yes"

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

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

Certificate Revocation List (CRL): Version 1 (0x0) Issuer: /C=RU/ST=Moskow/L=Moskow/O=MegaCompany Co. Ltd./OU=megacompany.central.office/CN=Administrator/[email protected] 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 – беспрепятственно входит в беспроводную сеть, что и требовалось доказать.

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

Протокол EAP (Extensible Authentication Protocol)

Протокол EAP (Extensible Authentication Protocol) является расширением протокола Point-to-Point Protocol (PPP); на нем основаны несколько методов проверки подлинности, предусматривающих обмен учетными данными и прочими сведениями произвольного объема. Протокол EAP был разработан с учетом растущей потребности в средствах проверки подлинности, использующих более широкий круг устройств системы безопасности; он предлагает стандартную архитектуру для поддержки дополнительных методов проверки подлинности в рамках PPP.

С помощью EAP можно реализовать поддержку нескольких алгоритмов проверки подлинности — так называемых типов EAP, к числу которых относятся генераторы кода доступа, одноразовые пароли, средства проверки подлинности на основе открытых ключей с использованием смарт-карт, сертификатов и др. Протокол EAP, в сочетании со строгими типами EAP, является ключевым компонентом технологии безопасных подключений виртуальных частных сетей (VPN). Строгие типы EAP, например основанные на сертификатах, обеспечивают более надежную защиту от попыток «грубого» взлома системы или подбора пароля, чем другие протоколы проверки подлинности, использующие пароли, такие как CHAP и MS-CHAP.

Чтобы узнать, используется ли в вашей организации какой-либо тип EAP, обратитесь к своему администратору сети.

В Windows XP существует поддержка двух типов EAP:

• EAP-MD5 CHAP (аналог протокола проверки подлинности CHAP);
• EAP-TLS (применяется для проверки подлинности на основе сертификатов пользователей).

EAP-TLS — это метод взаимной проверки подлинности, при котором и клиент, и сервер должны предоставлять доказательства своей подлинности. В ходе сеанса EAP-TLS клиент удаленного доступа отправляет свой сертификат пользователя, а сервер удаленного доступа — свой сертификат компьютера. Если хотя бы один из этих сертификатов не будет передан или окажется недействительным, подключение разрывается.

Примечания

• В процессе проверки подлинности методом EAP-TLS генерируются общие секретные ключи шифрования для алгоритма MPPE (Microsoft Point-to-Point Encryption).

Если нашли ошибку в тексте выделите ее мышкой и нажмите сочетание клавиш Ctrl+ENTER, укажите правильный текст без ошибки.

7 Протокол EAP

Протокол EAP (Extensible Authentication Protocol – расширяемый протокол аутентификации) представляет собой расширение для протокола РРР. Он содержит стандартный механизм поддержки ряда методов аутентификации, включая жетоны, протокол Kerberos, открытые ключи и секретные ключи S/Key. Этот механизм полностью поддерживается как серверами удаленного доступа Windows NT Dial-Up Server, так и сетевыми клиентами удаленного доступа Dial-Up Networking Client. Протокол EAP является крайне важным компонентом безопасных ВЧС, обеспечивающим защиту от силовых атак, подбора пароля по словарю и попыток угадать его.

Применение EAP расширяет возможности ВЧС на базе сервера удаленного доступа Windows NT Remote Access Service, позволяя производить аутентификацию с помощью модулей независимых производителей. Реализация этого протокола в среде Windows NT стала ответом Microsoft на многочисленные просьбы пользователей, которые не хотят отказываться от привычных аппаратных средств безопасности.

Протокол EAP был предложен Целевой группой технической поддержки Интернета в качестве расширения для протокола РРР. Он содержит дополнительные механизмы аутентификации, необходимые для проверки РРР-соединений. Главная задача EAP состоит в динамическом подключении модулей аутентификации на обеих – клиентской и серверной – сторонах такого соединения. Этот протокол отличается очень высокой гибкостью, обеспечивая уникальность и вариативность аутентификации. Практическая реализация EAP включена в Microsoft Windows 2000.

7.1 Обеспечение безопасности на уровне транзакций

Очень высокий уровень безопасности ВЧС обеспечивается за счет применения микропроцессорных карточек и жетонов аутентификации. Микропроцессорные карточки представляют собой миниатюрные устройства размером с кредитную карточку со встроенными в них ЦПУ и небольшим объемом оперативной памяти. Сюда обычно заносятся данные, удостоверяющие личность пользователя (например, сертификаты открытого ключа), ключи шифрования и параметры учетной записи. Некоторые из микропроцессорных карточек содержат также алгоритм шифрования, благодаря которому криптоключи никогда не передаются вовне. В системах обеспечения безопасности удаленного доступа микропроцессорные карточки сегодня используются довольно редко, так как их поддерживают лишь немногие пакеты такого типа. Ситуация должна измениться с появлением Windows 2000. Эта операционная система позволит применять такие карточки при самых различных видах аутентификации, включая RAS, L2TP и PPTP.

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

Поддержку жетонов аутентификации, как и пользовательских сертификатов с открытым ключом, обеспечит синтетический протокол EAP-TLS (Extended Authentication Protocol-Transaction Layer Security – расширяемый протокол аутентификации и обеспечение безопасности на уровне транзакций). Он уже представлен на рассмотрение Целевой группы технической поддержки Интернета в качестве проекта спецификации на метод аутентификации повышенной надежности с применением сертификатов открытого ключа. При работе по схеме EAP-TLS клиент посылает на сервер удаленного доступа пользовательский сертификат, а в ответ получает с него серверный сертификат. Первый из них обеспечивает надежную аутентификацию пользователя на сервере, а второй гарантирует, что клиент вступил в контакт именно с тем сервером, который ему нужен. При проверке достоверности полученных данных оба участника такого обмена полагаются на цепочку доверенных органов сертификации.

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

EAP-TLS представляет собой, по сути, разновидность протокола EAP, реализованную в Windows 2000. Как и MS-CHAP, он служит для получения криптоключа, который используется протоколом MPPE для шифрования всех последующих данных.

7.2 Аутентификация с помощью службы RADIUS

RADIUS (Remote Authentication Dial-in User Service – служба дистанционной аутентификации пользователей по коммутируемым линиям) представляет собой центральный сервер с базой данных аутентификации и служит дополнением к другим протоколам аутентификации запросов. В основу этой службы положены протокол UDP, обслуживающий протоколы РРР, РАР и CHAP, а также функция входа в системы Unix и ряд других механизмов аутентификации. Кроме своего непосредственного предназначения служба RADIUS позволяет также производить учет бюджета ВЧС.

Получив от сетевой службы аутентификации NAS запрос на подключение пользователя, сервер RADIUS сравнивает полученные данные с информацией из своей базы данных. Здесь же находится и центральное хранилище параметров подключений для всех зарегистрированных пользователей. При необходимости сервер не ограничивается простым ответом на запрос (ДА/НЕТ), а сообщает в NAS ряд сведений относительно конкретного пользователя. В частности, он может указать наибольшее время сеанса, выделенный статический IP-адрес и информацию, позволяющую произвести обратный вызов пользователя.

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

7.3 Учет бюджета ВЧС с помощью службы RADIUS

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

7.4 Протокол EAP и RADIUS

Чтобы совместно использовать протокол EAP с сервером RADIUS, необходимо внести коррективы как в службу NAS, так и в службу RADIUS. При традиционной схеме аутентификации эти службы производят одну-единственную транзакцию, состоящую из запроса и ответа на него. Однако при аутентификации по протоколу EAP служба NAS не может самостоятельно собрать информацию о клиенте, необходимую для аутентификации на сервере RADIUS. Для решения этой проблемы системный администратор может настроить службу NAS таким образом, что она будет направлять клиенту идентификатор, включив его в сообщение EAP. Тот в ответ сообщит службе сетевой аутентификации данные об имени пользователя и домене. Служба NAS включает их в запрос EAP-start и в таком виде направляет на сервер RADIUS. Дальнейший процесс аутентификации производится, как обычно: служба RADIUS передает клиенту через службу NAS сообщения EAP и отвечает на них до тех пор, пока аутентификация не даст положительного (или отрицательного) результата.

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

Протоколом VPN является протокол двухточечной туннельной связи (Point-to-Point Tunnelling Protocol – PPTP). Разработан он компаниями 3Com и Microsoft с целью предоставления безопасного удаленного доступа к корпоративным сетям через Интернет. PPTP использует существующие открытые стандарты TCP/IP и во многом полагается на устаревший протокол двухточечной связи РРР. На практике РРР так и остается...

В процессе аутентификации можно выделить три основных участника процесса:

• Аутентификатор (англ. authenticator) - участник процесса требующий провести аутентификацию (WiFi точка доступа , свич и т. д.).
• Узел или клиент (англ. peer) - участник процесса который будет аутентифицирован (компьютер , ноутбук , телефон и т. д.).
• Сервер аутентификации (англ. authentication server) - участник процесса способный по некоторым данным от узла аутентифицировать его.

В некоторых случаях сервер аутентификации и аутентификатор могут быть одним устройством, например домашние устройства использующие метод EAP-PSK. В целом процесс аутентификации происходит следующим образом:

1. Аутентификатор отправляет EAP-запрос для начала аутентификации клиента. Запрос в поле Type содержит в себе информацию о том, какой метод будет использоваться (EAP-TLS, EAP-PSK и т. д.). Аутентификатор не обязательно шлёт этот запрос, например, если аутентификация на порту, к которому подключен клиент, не обязательна, в таком случае для начала процедуры аутентификации клиент должен послать пакет с полем Code, соответствующим типу Initiate.
2. Клиент посылает аутентификатору EAP-ответ в случае правильного запроса от аутентификатора. Ответ содержит в себе поле Type, соответствующее полю Type в запросе.
3. Аутентификатор посылает запрос серверу аутентификации, передавая информацию о том, какой метод аутентификации используется.
4. Сервер аутентификации запрашивает у клиента необходимую информацию через аутентификатор, в этом момент аутентификатор фактически работает как прокси .
5. Клиент отвечает серверу, передавая запрашиваемую информацию. Пункт 4 и 5 повторяются до тех пор, пока сервер аутентификации не примет решение о разрешении доступа, запрете или ошибке.
6. Сервер аутентификации посылает аутентификатору пакет сообщающий о успехе или сбое аутентификации.
7. Аутентификатор посылает клиенту EAP пакет с кодом соответствующим ответу сервера аутентификации (EAP-Success или EAP-Failure).

Сводная таблица кодов пакетов EAP:

Методы

LEAP

Облегченный расширяемый протокол аутентификации (англ. Lightweight Extensible Authentication Protocol ), метод, разработанный компанией Cisco до ратификации IEEE стандарта безопасности 802.11i . Cisco распространил протокол через CCX (Cisco Certified Extensions) как часть протокола 802.1X и динамического WEP из-за отсутствия отдельного промышленного стандарта в индустрии. В операционных системах семейства Windows отсутствует встроенная поддержка протокола LEAP , однако поддержка протокола широко распространена в сторонних программах-клиентах (чаще всего идущих в комплекте с беспроводным оборудованием). Поддержка LEAP в Windows может быть добавлена путём установки клиентского ПО компании Cisco, которое обеспечивает поддержку протоколов LEAP и EAP-FAST. Многие другие производители WLAN оборудования также поддерживают протокол LEAP из-за его высокой распространённости.

LEAP использует модифицированную версию протокола MS-CHAP - слабо защищённого протокола аутентификации , информация о пользователе и пароле в котором легко компрометируется ; в начале 2004 года Джошуа Райтом был написан эксплойт протокола LEAP, названный ASLEAP . Взлом основан на том, что, во-первых, все элементы запроса и ответа, помимо хеша пароля, передаются в незашифрованном виде или легко рассчитываются на основе данных, которые отправляются по сети. Это означает, что злоумышленнику типа человек посередине получения хеша пароля будет достаточно, чтобы повторно авторизоваться. Во-вторых, создание ключей является потенциально слабым. Дополнение 5 байт нулями означает, что последний ключ имеет ключевое пространство 2 16 . Наконец, один и тот же исходный текст шифруется с помощью двух ключей (при отправке хеша серверу и при ответе), что означает, что сложности 2 56 достаточно, чтобы взломать оба ключа. После того, как злоумышленник имеет все ключи, он получает хеш пароля, которого достаточно для повторной аутентификации (подробнее в MS-CHAP).

Встроенная поддержка этого метода есть во всех операционных системах семейства Windows (начиная с Windows 2000 SP4), Linux и Mac OS X (с версии 10.3).

В отличие от многих других реализаций TLS , например в HTTPS , большинство реализаций EAP-TLS требует предустановленного сертификата X.509 у клиента, не давая возможности отключить требование, хотя стандарт не требует этого в обязательном порядке . Это могло помешать распространению «открытых», но зашифрованных точек беспроводного доступа . В августе 2012 года hostapd и wpa_supplicant была добавлена поддержка UNAUTH-TLS - собственного метода аутентификации EAP и 25 февраля 2014 добавлена поддержка WFA-UNAUTH-TLS, метода аутентификации, аутентифицирующий только сервер . Это позволит работать через EAP-TLS так же, как через HTTPS , где беспроводная точка доступа даёт возможность свободного подключения (то есть не требует проверки подлинности клиентов), но при этом шифрует трафик (IEEE 802.11i-2004 , то есть WPA2) и позволяет пройти аутентификации при необходимости. В стандартах также содержатся предложения по использованию IEEE 802.11u в точках доступа, чтобы сигнализировать о доступности метода EAP-TLS, аутентифицирующего только сервер, используя стандартный протокол EAP-TLS IETF, а не стороннего метода EAP .

Требование предустановленного сертификата на стороне клиента - одна из причин высокой защищённости метода EAP-TLS и пример «жертвования» удобства в пользу безопасности. Для взлома EAP-TLS не достаточно скомпрометировать пароль пользователя, для успешной атаки злоумышленнику также потребуется завладеть соответствующим пользователю сертификатом клиента. Наилучшей безопасности можно добиться, храня сертификаты клиентов в смарт-картах .

EAP-TTLS

Tunneled Transport Layer Security (Безопасность Транспортного Уровня через Туннель), метод EAP, расширяющий возможности метода TLS. Он разработан компаниями Funk Software и Certicom и довольно хорошо поддерживается большинством платформ (Windows с версии 8, а Windows Mobile с версии 8.1 ).

Клиент может (но не обязан) быть аутентифицирован сервером при помощи подписанного Центром Сертификации PKI-сертификатом . Необязательность аутентификации клиента сильно упрощает процедуру настройки, так как нет необходимости генерировать и устанавливать на каждый из них индивидуальный сертификат.

После того, как сервер аутентифицирован клиентом при помощи сертификата, подписанного Центром Сертификации и, опционально, клиент-сервером, сервер может использовать получившееся защищённое соединение (туннель) для дальнейшей аутентификации клиента. Туннель позволяет использовать протоколы аутентификации, рассчитанные на каналы, защищённые от атаки MITM и от «прослушки». При использовании метода EAP-TTLS никакая информация, используемая для аутентификации, не передается в открытом виде, что ещё больше затрудняет взлом.

EAP-PSK

Pre-Shared Key (Заранее известный ключ) , метод определённый в RFC 4764 , использующий для взаимной аутентификации и обмена сессионным ключом заранее оговорённый ключ. Метод разработан для работы в незащищённых сетях, таких как IEEE 802.11 , и в случае успешной аутентификации обеспечивает защищённое двустороннее соединение между клиентом и точкой доступа.

EAP-PSK задокументирован в экспериментальной RFC и обеспечивает лёгкий и расширяемый EAP метод, не использующий асимметричное шифрование . Этот метод требует четырёх сообщений (минимально возможное количество) для взаимной аутентификации.

Напишите отзыв о статье "EAP"

Примечания

Отрывок, характеризующий EAP

– Соня! Соня! – послышался опять первый голос. – Ну как можно спать! Да ты посмотри, что за прелесть! Ах, какая прелесть! Да проснись же, Соня, – сказала она почти со слезами в голосе. – Ведь этакой прелестной ночи никогда, никогда не бывало.
Соня неохотно что то отвечала.
– Нет, ты посмотри, что за луна!… Ах, какая прелесть! Ты поди сюда. Душенька, голубушка, поди сюда. Ну, видишь? Так бы вот села на корточки, вот так, подхватила бы себя под коленки, – туже, как можно туже – натужиться надо. Вот так!
– Полно, ты упадешь.
Послышалась борьба и недовольный голос Сони: «Ведь второй час».
– Ах, ты только всё портишь мне. Ну, иди, иди.
Опять всё замолкло, но князь Андрей знал, что она всё еще сидит тут, он слышал иногда тихое шевеленье, иногда вздохи.
– Ах… Боже мой! Боже мой! что ж это такое! – вдруг вскрикнула она. – Спать так спать! – и захлопнула окно.
«И дела нет до моего существования!» подумал князь Андрей в то время, как он прислушивался к ее говору, почему то ожидая и боясь, что она скажет что нибудь про него. – «И опять она! И как нарочно!» думал он. В душе его вдруг поднялась такая неожиданная путаница молодых мыслей и надежд, противоречащих всей его жизни, что он, чувствуя себя не в силах уяснить себе свое состояние, тотчас же заснул.

На другой день простившись только с одним графом, не дождавшись выхода дам, князь Андрей поехал домой.
Уже было начало июня, когда князь Андрей, возвращаясь домой, въехал опять в ту березовую рощу, в которой этот старый, корявый дуб так странно и памятно поразил его. Бубенчики еще глуше звенели в лесу, чем полтора месяца тому назад; всё было полно, тенисто и густо; и молодые ели, рассыпанные по лесу, не нарушали общей красоты и, подделываясь под общий характер, нежно зеленели пушистыми молодыми побегами.
Целый день был жаркий, где то собиралась гроза, но только небольшая тучка брызнула на пыль дороги и на сочные листья. Левая сторона леса была темна, в тени; правая мокрая, глянцовитая блестела на солнце, чуть колыхаясь от ветра. Всё было в цвету; соловьи трещали и перекатывались то близко, то далеко.
«Да, здесь, в этом лесу был этот дуб, с которым мы были согласны», подумал князь Андрей. «Да где он», подумал опять князь Андрей, глядя на левую сторону дороги и сам того не зная, не узнавая его, любовался тем дубом, которого он искал. Старый дуб, весь преображенный, раскинувшись шатром сочной, темной зелени, млел, чуть колыхаясь в лучах вечернего солнца. Ни корявых пальцев, ни болячек, ни старого недоверия и горя, – ничего не было видно. Сквозь жесткую, столетнюю кору пробились без сучков сочные, молодые листья, так что верить нельзя было, что этот старик произвел их. «Да, это тот самый дуб», подумал князь Андрей, и на него вдруг нашло беспричинное, весеннее чувство радости и обновления. Все лучшие минуты его жизни вдруг в одно и то же время вспомнились ему. И Аустерлиц с высоким небом, и мертвое, укоризненное лицо жены, и Пьер на пароме, и девочка, взволнованная красотою ночи, и эта ночь, и луна, – и всё это вдруг вспомнилось ему.
«Нет, жизнь не кончена в 31 год, вдруг окончательно, беспеременно решил князь Андрей. Мало того, что я знаю всё то, что есть во мне, надо, чтобы и все знали это: и Пьер, и эта девочка, которая хотела улететь в небо, надо, чтобы все знали меня, чтобы не для одного меня шла моя жизнь, чтоб не жили они так независимо от моей жизни, чтоб на всех она отражалась и чтобы все они жили со мною вместе!»

Возвратившись из своей поездки, князь Андрей решился осенью ехать в Петербург и придумал разные причины этого решенья. Целый ряд разумных, логических доводов, почему ему необходимо ехать в Петербург и даже служить, ежеминутно был готов к его услугам. Он даже теперь не понимал, как мог он когда нибудь сомневаться в необходимости принять деятельное участие в жизни, точно так же как месяц тому назад он не понимал, как могла бы ему притти мысль уехать из деревни. Ему казалось ясно, что все его опыты жизни должны были пропасть даром и быть бессмыслицей, ежели бы он не приложил их к делу и не принял опять деятельного участия в жизни. Он даже не понимал того, как на основании таких же бедных разумных доводов прежде очевидно было, что он бы унизился, ежели бы теперь после своих уроков жизни опять бы поверил в возможность приносить пользу и в возможность счастия и любви. Теперь разум подсказывал совсем другое. После этой поездки князь Андрей стал скучать в деревне, прежние занятия не интересовали его, и часто, сидя один в своем кабинете, он вставал, подходил к зеркалу и долго смотрел на свое лицо. Потом он отворачивался и смотрел на портрет покойницы Лизы, которая с взбитыми a la grecque [по гречески] буклями нежно и весело смотрела на него из золотой рамки. Она уже не говорила мужу прежних страшных слов, она просто и весело с любопытством смотрела на него. И князь Андрей, заложив назад руки, долго ходил по комнате, то хмурясь, то улыбаясь, передумывая те неразумные, невыразимые словом, тайные как преступление мысли, связанные с Пьером, с славой, с девушкой на окне, с дубом, с женской красотой и любовью, которые изменили всю его жизнь. И в эти то минуты, когда кто входил к нему, он бывал особенно сух, строго решителен и в особенности неприятно логичен.
– Mon cher, [Дорогой мой,] – бывало скажет входя в такую минуту княжна Марья, – Николушке нельзя нынче гулять: очень холодно.
– Ежели бы было тепло, – в такие минуты особенно сухо отвечал князь Андрей своей сестре, – то он бы пошел в одной рубашке, а так как холодно, надо надеть на него теплую одежду, которая для этого и выдумана. Вот что следует из того, что холодно, а не то чтобы оставаться дома, когда ребенку нужен воздух, – говорил он с особенной логичностью, как бы наказывая кого то за всю эту тайную, нелогичную, происходившую в нем, внутреннюю работу. Княжна Марья думала в этих случаях о том, как сушит мужчин эта умственная работа.

Князь Андрей приехал в Петербург в августе 1809 года. Это было время апогея славы молодого Сперанского и энергии совершаемых им переворотов. В этом самом августе, государь, ехав в коляске, был вывален, повредил себе ногу, и оставался в Петергофе три недели, видаясь ежедневно и исключительно со Сперанским. В это время готовились не только два столь знаменитые и встревожившие общество указа об уничтожении придворных чинов и об экзаменах на чины коллежских асессоров и статских советников, но и целая государственная конституция, долженствовавшая изменить существующий судебный, административный и финансовый порядок управления России от государственного совета до волостного правления. Теперь осуществлялись и воплощались те неясные, либеральные мечтания, с которыми вступил на престол император Александр, и которые он стремился осуществить с помощью своих помощников Чарторижского, Новосильцева, Кочубея и Строгонова, которых он сам шутя называл comite du salut publique. [комитет общественного спасения.]
Теперь всех вместе заменил Сперанский по гражданской части и Аракчеев по военной. Князь Андрей вскоре после приезда своего, как камергер, явился ко двору и на выход. Государь два раза, встретив его, не удостоил его ни одним словом. Князю Андрею всегда еще прежде казалось, что он антипатичен государю, что государю неприятно его лицо и всё существо его. В сухом, отдаляющем взгляде, которым посмотрел на него государь, князь Андрей еще более чем прежде нашел подтверждение этому предположению. Придворные объяснили князю Андрею невнимание к нему государя тем, что Его Величество был недоволен тем, что Болконский не служил с 1805 года.
«Я сам знаю, как мы не властны в своих симпатиях и антипатиях, думал князь Андрей, и потому нечего думать о том, чтобы представить лично мою записку о военном уставе государю, но дело будет говорить само за себя». Он передал о своей записке старому фельдмаршалу, другу отца. Фельдмаршал, назначив ему час, ласково принял его и обещался доложить государю. Через несколько дней было объявлено князю Андрею, что он имеет явиться к военному министру, графу Аракчееву.
В девять часов утра, в назначенный день, князь Андрей явился в приемную к графу Аракчееву.
Лично князь Андрей не знал Аракчеева и никогда не видал его, но всё, что он знал о нем, мало внушало ему уважения к этому человеку.
«Он – военный министр, доверенное лицо государя императора; никому не должно быть дела до его личных свойств; ему поручено рассмотреть мою записку, следовательно он один и может дать ход ей», думал князь Андрей, дожидаясь в числе многих важных и неважных лиц в приемной графа Аракчеева.
Князь Андрей во время своей, большей частью адъютантской, службы много видел приемных важных лиц и различные характеры этих приемных были для него очень ясны. У графа Аракчеева был совершенно особенный характер приемной. На неважных лицах, ожидающих очереди аудиенции в приемной графа Аракчеева, написано было чувство пристыженности и покорности; на более чиновных лицах выражалось одно общее чувство неловкости, скрытое под личиной развязности и насмешки над собою, над своим положением и над ожидаемым лицом. Иные задумчиво ходили взад и вперед, иные шепчась смеялись, и князь Андрей слышал sobriquet [насмешливое прозвище] Силы Андреича и слова: «дядя задаст», относившиеся к графу Аракчееву. Один генерал (важное лицо) видимо оскорбленный тем, что должен был так долго ждать, сидел перекладывая ноги и презрительно сам с собой улыбаясь.
Но как только растворялась дверь, на всех лицах выражалось мгновенно только одно – страх. Князь Андрей попросил дежурного другой раз доложить о себе, но на него посмотрели с насмешкой и сказали, что его черед придет в свое время. После нескольких лиц, введенных и выведенных адъютантом из кабинета министра, в страшную дверь был впущен офицер, поразивший князя Андрея своим униженным и испуганным видом. Аудиенция офицера продолжалась долго. Вдруг послышались из за двери раскаты неприятного голоса, и бледный офицер, с трясущимися губами, вышел оттуда, и схватив себя за голову, прошел через приемную.
Вслед за тем князь Андрей был подведен к двери, и дежурный шопотом сказал: «направо, к окну».
Князь Андрей вошел в небогатый опрятный кабинет и у стола увидал cорокалетнего человека с длинной талией, с длинной, коротко обстриженной головой и толстыми морщинами, с нахмуренными бровями над каре зелеными тупыми глазами и висячим красным носом. Аракчеев поворотил к нему голову, не глядя на него.
– Вы чего просите? – спросил Аракчеев.
– Я ничего не… прошу, ваше сиятельство, – тихо проговорил князь Андрей. Глаза Аракчеева обратились на него.
– Садитесь, – сказал Аракчеев, – князь Болконский?
– Я ничего не прошу, а государь император изволил переслать к вашему сиятельству поданную мною записку…
– Изволите видеть, мой любезнейший, записку я вашу читал, – перебил Аракчеев, только первые слова сказав ласково, опять не глядя ему в лицо и впадая всё более и более в ворчливо презрительный тон. – Новые законы военные предлагаете? Законов много, исполнять некому старых. Нынче все законы пишут, писать легче, чем делать.
– Я приехал по воле государя императора узнать у вашего сиятельства, какой ход вы полагаете дать поданной записке? – сказал учтиво князь Андрей.
– На записку вашу мной положена резолюция и переслана в комитет. Я не одобряю, – сказал Аракчеев, вставая и доставая с письменного стола бумагу. – Вот! – он подал князю Андрею.
На бумаге поперег ее, карандашом, без заглавных букв, без орфографии, без знаков препинания, было написано: «неосновательно составлено понеже как подражание списано с французского военного устава и от воинского артикула без нужды отступающего».
– В какой же комитет передана записка? – спросил князь Андрей.
– В комитет о воинском уставе, и мною представлено о зачислении вашего благородия в члены. Только без жалованья.
Князь Андрей улыбнулся.
– Я и не желаю.
– Без жалованья членом, – повторил Аракчеев. – Имею честь. Эй, зови! Кто еще? – крикнул он, кланяясь князю Андрею.

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