Протокол EAP (Extensible Authentication Protocol). Тип Шифрования WiFi – Какой Выбрать, WEP или WPA2-PSK Personal-Enterprise Для Защиты Безопасности Сети? Psk eap что выбрать

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

Строим защищённую беспроводную сеть: 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 (протокол расширенной аутентификации) беспроводных пользователей в локальной базе данных сервера RADIUS на точке доступа, работающей под управлением Cisco IOS®.

Благодаря пассивной роли, которую играет точка доступа в EAP (она преобразует беспроводные пакеты клиентов в пакеты, передающиеся по проводам, и направляет их на сервер аутентификации, и наоборот), данная конфигурация используется практически со всеми методами EAP. Эти методы включают (но не ограничиваются) LEAP, защищенный EAP (PEAP)-MS-протокол взаимной аутентификации (CHAP) версии 2, PEAP-плата Generic Token (GTC), гибкая аутентификация EAP через безопасный туннель (FAST), EAP-протокол безопасности транспортного уровня (TLS) и EAP-Tunneled TLS (TTLS). Необходимо соответствующим образом настроить сервер аутентификации для каждого из методов EAP. Данная статья содержит только сведения по настройке точки доступа.

Требования

При проведении настройки могут понадобиться следующие знания:

  • Общее представление о Cisco IOS GUI или CLI.
  • Общее представление о концепции аутентификации EAP.

Используемые компоненты

  • Точка доступа Cisco Aironet, работающая под управлением Cisco IOS.
  • Виртуальная LAN (VLAN), предположим, что в сети она только одна.
  • RADIUS сервер аутентификации, успешно выполняющий интеграцию в базу данных пользователя.
    • Cisco LEAP и EAP-FAST поддерживают следующие серверы аутентификации:
      • Сервер контроля доступа (ACS) Cisco Secure
      • Регистратор доступа Cisco (CAR)
      • Funk Steel Belted RADIUS
      • Interlink Merit
    • Microsoft PEAP-MS-CHAP версии 2 и PEAP-GTC поддерживают следующие серверы аутентификации:
      • Microsoft Internet Authentication Service (IAS)
      • Cisco Secure ACS
      • Funk Steel Belted RADIUS
      • Interlink Merit
      • Авторизацию могут выполнять любые другие серверы аутентификации Microsoft.
    Примечание: GTC или единоразовое введение пароля требуют подключения дополнительных служб, в свою очередь требующих наличия на стороне клиента и на стороне сервера дополнительного программного обеспечения, а также наличия аппаратного или программного генератора маркеров.
    • Необходимо проконсультироваться с производителем оборудования, установленного у клиента, чтобы уточнить при каких условиях сервера аутентификации, работающие по методам EAP-TLS, EAP-TTLS и другим EAP-методам, поддерживаются их продуктами.

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

Настройка

Данная конфигурация предполагает настройку EAP-аутентификации на точке доступа, работающей под управлением IOS.

Как большинство алгоритмов аутентификации, основанных на применении пароля, Cisco LEAP чувствителен к словарным атакам. Речь не идет о новом виде атаки или новом уязвимом месте Cisco LEAP. Для того, чтобы смягчить словарные атаки, необходимо разработать политику стойкого пароля. Это включает в себя использование устойчивых паролей и периодическую их смену.

Сетевой EAP или открытая аутентификация с EAP

При любом методе аутентификации, основанном на EAP/802.1x, может возникнуть вопрос о том каковы различия между сетевым EAP и открытой аутентификацией с EAP. Это относится к значениям в поле Authentication Algorithm в заголовках пакетов управления и связывания. Большинство производителей беспроводных клиентских устройств устанавливают значение этого поля равным 0 (открытая аутентификация), а затем сообщают о желании проводить аутентификацию EAP позднее, во время процесса ассоциации. В продуктах Cisco это значение задается по-другому, а именно с начала ассоциации с флагом сетевого протокола EAP.

Если в сети есть клиенты, которые являются:

  • Клиентами Cisco – необходимо использовать сетевой EAP.
  • Клиентами стороннего производителя (в том числе продукты, совместимые с CCX) – необходимо использовать открытую аутентификацию с EAP.
  • Сочетанием клиентских устройств Cisco и сторонних производителей – необходимо выбрать и сетевой EAP и открытую аутентификацию с EAP.

Определение сервера аутентификации

Первым шагом в настройке EAP является определение сервера аутентификации и установление связи с ним.

1. На закладке точки доступа Server Manager (пункт меню Security > Server Manager ), необходимо выполнить следующие действия:

  1. Ввести IP адрес сервера аутентификации в поле Server.
  2. Указать общий секретный ключ и порты.
  3. Нажать Apply для того, чтобы создать определение и заполнить выпадающие списки.
  4. Задать IP адрес сервера в поле Default Server Priorities > EAP Authentication type > Priority 1.
  5. Нажать Apply .


AP#configure terminal

AP(config)#aaa group server radius rad_eap

AP(config-sg-radius)#server 10.0.0.3 auth-port 1645 acct-port 1646

AP(config-sg-radius)#exit

AP(config)#aaa new-model

AP(config)#aaa authentication login eap_methods group rad_eap

AP(config)#radius-server host 10.0.0.3 auth-port 1645
acct-port 1646 key labap1200ip102

AP(config)#end

AP#write memory

2. Точка доступа должна быть настроена на сервере аутентификации как ААА клиент.

Например, на сервере контроля доступа Cisco Secure это настраивается на странице Network Configuration, на которой определены имя точки доступа, IP адрес, общий секретный пароль и метод аутентификации (RADIUS Cisco Aironet или RADIUS Cisco IOS/PIX). Для получения информации по серверам аутентификации, не принадлежащим к разряду серверов контроля доступа, обратитесь к документации их производителя.

Необходимо убедиться в том, что сервер аутентификации настроен на применение желаемого метода аутентификации EAP. Например, для сервера контроля доступа Cisco Secure, применяющего LEAP, необходимо настроить аутентификацию LEAP на странице System Configuration - Global Authentication Setup. Нажать System Configuration , затем нажать Global Authentication Setup . Для получения информации по серверам аутентификации, не принадлежащим к разряду серверов контроля доступа, или другим методам EAP обратитесь к документации их производителя.

На следующем рисунке показана настройка ACS Cisco Secure на применение PEAP, EAP-FAST, EAP-TLS, LEAP и EAP-MD5.

Определение методов аутентификации клиента

Как только точка доступа определит, куда необходимо отправить запрос на аутентификацию клиента, ее необходимо настроить на применение следующих методов.

Примечание: Эти инструкции предназначены для установки, основанной на WEP.

1. На закладке точки доступа Encryption Manager (пункт меню Security > Encryption Manager ) необходимо выполнить следующие действия:

  1. Указать использование WEP encryption .
  2. Указать, что использование WEP является обязательным Mandatory .
  3. Убедиться в том, что для размера ключа установлено значение 128-bits .
  4. Нажать Apply .

Также можно выполнить из CLI следующие команды:

AP#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

AP(config)#interface dot11radio 0

AP(config-if)#encryption mode wep mandatory

AP(config-if)#end

AP#write memory

2. Выполнить следующие действия на закладке точки доступа SSID Manager (пункт меню Security > SSID Manager ):

  1. Выбрать желаемый SSID.
  2. В пункте "Authentication Methods Accepted," установить флажок Open и использовав выпадающий список выбрать With EAP .
  3. Установить флажок Network-EAP при наличии клиентской карты Cisco.
  4. Нажать Apply .

Также можно выполнить из CLI следующие команды:

AP#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

AP(config)#interface dot11radio 0

AP(config-if)#ssid ssid labap1200

AP(config-if-ssid)#authentication open eap eap_methods

AP(config-if-ssid)#authentication network-eap eap_methods

AP(config-if-ssid)#end

AP#write memory

Как только правильная работа основной функциональной возможности с основной настройкой EAP будет подтверждена, можно будет добавить дополнительные функциональные возможности и управление ключами. Расположите более сложные функции на вершине функциональной базы для того, чтобы сделать поиск и устранение неисправностей легче.

Проверка

В данном разделе содержатся сведения, которые могут быть использованы при проверке работы конфигурации.

Некоторые команды show поддерживаются инструментом Output Interpreter Tool (только для зарегистрированных пользователей), который позволяет просмотреть анализ выходных данных команды show .
show radius server-group all – Выводит список всех настроенных групп RADIUS-серверов на точке доступа.

Поиск и устранение неисправностей

Процедура поиска и устранения неисправностей

Для того, чтобы осуществить поиск и устранение неисправностей в своей конфигурации, необходимо выполнить следующие действия.

  1. В утилите на стороне клиента или в программном обеспечении необходимо создать новый профиль или соединение с теми же или похожими параметрами для того, чтобы убедиться в том, что в настройках клиента ничего не было повреждено.
  2. Для того, чтобы исключить возможность влияния радиочастотных помех на успешную аутентификацию, необходимо временно отключить аутентификацию при помощи показанных ниже действий:
  3. Из CLI выполнить команды no authentication open eap eap_methods, no authentication network-eap eap_methods и authentication open .
  4. Из GUI на странице SSID Manager необходимо снять флажок Network-EAP , установить флажок Open и установить выпадающий список обратно в No Addition .
  5. Если клиент будет успешно сопоставлен, то радиочастота не вызовет проблем сопоставления.
  6. Необходимо убедиться в том, что общие секретные пароли синхронизированы между точкой доступа и сервером аутентификации.
  7. Из CLI выбрать строку radius-server host x.x.x.x auth-port x acct-port x key .
  8. Из GUI на странице Server Manager повторно ввести общий секретный ключ для соответствующего сервера в поле "Shared Secret."
  9. Общая секретная запись для точки доступа на RADIUS сервере должна содержать тот же общий секретный пароль, который упоминался ранее.
  10. Удалите все группы пользователей с сервера RADIUS. Иногда могут возникать конфликты между группами пользователей, определенными RADIUS-сервером, и группами пользователей на базовом домене. Проверьте записи журнала сервера RADIUS на предмет неудачных попыток и причин, по которым эти попытки были неудачными.

Команды поиска и устранения неисправностей

Некоторые команды show поддерживаются средством Output Interpreter Tool (только для зарегистрированных пользователей), что позволяет просматривать результаты выполнения команды show .

Раздел Отладка аутентификации содержит значительное количество подробностей того, как можно собрать и интерпретировать выходные данные команд отладки, связанных с EAP.

Примечание: Перед тем, как выполнять команды debug , необходимо ознакомиться с разделом Важная информация о командах отладки .

  • debug dot11 aaa authenticator state-machine – Выводит основные разделы (или состояния) согласования между клиентом и сервером аутентификации.
    Примечание: В программном обеспечении Cisco IOS релизов, предшествующих 12.2(15)JA, синтаксис команды debug является следующим debug dot11 aaa dot1x state-machine .
  • debug dot11 aaa authenticator process – Выводит единичные записи диалогов согласования между клиентом и сервером аутентификации.
    Примечание: В программном обеспечении Cisco IOS релизов, предшествующих 12.2(15)JA, синтаксис команды отладки следующий debug dot11 aaa dot1x process .
  • debug radius authentication – Выводит согласования RADIUS между сервером и клиентом, связанными мостом с точкой доступа.
  • debug aaa authentication – Выводит согласования ААА для аутентификации между клиентским устройством и сервером аутентификации.

Есть вопросы?
Обращайтесь в "Аквилон-А", чтобы узнать подробности и получить именно то, что вам требуется.

Authentication Protocol version 2 – Протокол аутентификации с предварительным согласованием вызова версии 2 компании Microsoft).
  • MS- CHAP (Microsoft Challenge Handshake Authentication Protocol ).
  • CHAP (Challenge Handshake Authentication Protocol ).
  • SPAP (Shiva Password Authentication Protocol – Протокол аутентификации пароля для клиентов Shiva).
  • PAP (Password Authentication Protocol ).
  • Неаутентифицированный доступ.
  • Эти методы аутентификации, показанные на рисунке 4.9 , можно найти в консоли управления RRAS, выбрав соответствующий сервер в правой панели и выбрав пункт Properties (Свойства). Затем во вкладке Security (Безопасность) щелкните на кнопке Authentication Methods (Методы аутентификации). Чтобы использовать нужные методы аутентификации, установите флажки рядом с названиями соответствующих методов.


    Рис. 4.9.

    EAP

    Протокол EAP – это расширение PPP, которое позволяет согласовывать произвольный метод аутентификации между удаленным клиентом и сервером. После создания соответствующего канала клиент и сервер согласовывают, какой тип механизма аутентификации EAP будет использоваться. К вариантам выбора относятся EAP -MD5, CHAP , EAP -TLS, смарт-карты и т.д. После принятия решения клиент использует выбранный механизм аутентификации для получения доступа к серверу RRAS и к сети.

    Как следует из названия EAP (Расширяемый протокол аутентификации), любое количество типов (методов) EAP может быть добавлено в любой момент. Чтобы увидеть, какие методы EAP вы используете на данный момент, выполните следующие шаги.

    1. Откройте консоль управления RRAS, выбрав Start/Programs/Administrative Tools (Пуск/Программы/Администрирование).
    2. В правой консоли щелкните на нужном сервере RRAS и выберите пункт Properties.
    3. Во вкладке Security щелкните на кнопке Authentication Methods , после чего появится окно Authentication Methods .
    4. Щелкните на кнопке EAP Methods (Методы EAP ), после чего вы увидите методы EAP , установленные на данный момент (см. рис. 4.10).

    Методы EAP . Система Windows Server 2003 может поддерживать любые типы методов EAP (например, смарт-карты) в виде встраиваемых модулей (plug-ins), но она автоматически предоставляет следующие два метода EAP .

    • EAP -MD5 CHAP . EAP - Message Digest 5 CHAP – это обязательный метод EAP , который поддерживает много одинаковых атрибутов с методом CHAP , но, кроме того, поддерживает отправку вызовов и ответов в виде сообщений EAP .
    • EAP -TLS ( EAP -Transport Level Security). Этот метод безопасности транспортного уровня осуществляет аутентификацию с помощью сертификатов. Данный метод является обязательным, если вы используете смарт-карты. EAP -TLS является в настоящее время наиболее сильным типом аутентификации, и для него требуется, чтобы сервер RRAS был членом домена. Он обеспечивает взаимную аутентификацию (аутентифицируются как клиент, так и сервер), шифрование, а также обмен секретными личными ключами .


    Рис. 4.10.
    CHAP

    CHAP , видимо, является наиболее употребительным протоколом аутентификации в настоящее время. RRAS Windows Server 2003 поддерживает три версии CHAP .

    • CHAP . Как отраслевой стандарт CHAP является протоколом аутентификации в форме "вызов-ответ", который поддерживает одностороннее шифрование ответов на вызовы. Для выполнения процесса аутентификации используются три шага. Сначала сервер направляет клиенту вызов, чтобы тот доказал свою идентичность. Затем клиент отправляет шифрованное сообщение CHAP в ответ на этот вызов. После этого сервер проверяет ответ, и если все правильно, то клиенту предоставляется доступ.
    • MS- CHAP . MS- CHAP – это модифицированная собственная версия CHAP от компании Microsoft. Главным отличием между MS- CHAP и CHAP в Windows Server 2003 является то, что пароль пользователя используется в обратной шифрованной форме.
    • MS-CHAPv2. Версия 2 MS- CHAP – это более сильный и более защищенный метод аутентификации, чем предыдущие реализации. К наиболее заметным отличиям относится то, что он больше не поддерживает NTLM (его можно использовать только с Windows Server 2003), он обеспечивает взаимную аутентификацию, а для отправки и приема данных используются отдельные криптографические ключи.
    SPAP

    Протокол аутентификации пароля для клиентов Shiva – это более старый, и, тем не менее, широко распространенный метод для дистанционного доступа. Клиенты, использующие программное обеспечение Shiva, должны аутентифицироваться с помощью SPAP. SPAP – это относительно простой метод аутентификации, с помощью которого происходит шифрование паролей, передаваемых через канал связи. Этот вариант аутентификации поддерживается системой Windows Server 2003 только для клиентов Shiva, которых вам, может быть, приходится обслуживать.

    PAP

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

    Неаутентифицированный доступ

    Этот вариант совершенно очевиден, и поэтому он не требует обсуждения. Ясно, что вам никогда не следует использовать этот вариант, если вы заинтересованы в защите вашей сети. Фактически этот вариант предоставляет открытый доступ любому, кто хочет подсоединиться дистанционным образом.

    Ответный вызов (Callback)

    Смысл этого термина следует из его названия. Удаленный клиент набирает номер сервера RRAS, после чего происходит проверка опознавательных данных этого клиента (пользовательское имя и пароль). После проверки опознавательных данных соединение прерывается, что позволяет серверу RRAS сделать ответный вызов удаленного клиента. Номер, по которому делает ответный вызов сервер RRAS, может быть указан во время начального вызова, или может потребоваться, чтобы сервер RRAS выполнил вызов по определенному номеру. Второй вариант является наиболее защищенным способом, поскольку он позволяет ограничить возможные источники удаленных соединений . Еще одним преимуществом обратного вызова является то, что он позволяет экономить затраты на соединение клиента.

    Идентификация вызова (Caller ID)

    Многие люди знакомы с идентификацией вызова, когда на дисплее телефона представлен номер телефона, с которого вам звонят. Ту же функцию можно применять к дистанционному доступу для повышения уровня безопасности.

    Идентификацию вызова можно использовать для проверки того, что удаленный клиент, набравший номер сервера RRAS, звонит с определенного заданного номера. Если клиент звонит не с этого номера, то соединение запрещается и происходит разъединение. Иногда оказывается, что телефонная компания не может снабдить вас номером вызывающей стороны, так как в некоторых местах POTS (обычная телефонная сеть) не может получать номер вызывающей стороны или вызывающая сторона блокировала свой номер, чтобы он не выводился на дисплее телефона. Если номер не может быть выведен на дисплее по какой-либо причине, то соединение отклоняется.

    Основы виртуальных частных сетей (VPN)

    О сетях VPN говорят очень много, но, что удивительно, они труднее всего для понимания среди понятий, касающихся Интернет и дистанционного доступа. Сети VPN известны уже много лет, но они не привлекали особого внимания до недавнего времени. Они стали поддерживаться Microsoft, начиная с реализации RRAS в Windows NT 4, и продолжают поддерживаться в RRAS Windows Server 2003.

    Путаница возникает в особенности из-за смысла слова "частные". Например, компании давно используют для своих отделений (филиалов) соединения через выделенные арендуемые линии. Это фактически частная сеть , которая расширена для связи с удаленными частями. Их также называют VPN через выделенную линию связи. ISP (поставщики услуг интернет ) или телефонные компании создают виртуальные каналы между различными местами. В этом случае имеется два типа виртуальных каналов: постоянные виртуальные каналы ( PVC ) и коммутируемые виртуальные каналы ( SVC ), которые обеспечивают частные соединения. Наиболее распространены PVC -каналы.

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

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

    Аутентификация

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

    Можно использовать любой из методов аутентификации, описанных выше в разделе "Защита соединений RRAS". Единственным недостатком является то, что если удаленные клиенты являются клиентами более ранних версий Windows, то они, возможно, не поддерживают протокол EAP . И действительно, клиенты Windows NT и Windows 9x не поддерживают этот протокол. Принимая решение, какой протокол использовать, помните, что важно обеспечить максимально возможный уровень аутентификации. Это означает, что нужно использовать такие протоколы аутентификации, как EAP , MS- CHAP или MS-CHAPv2.

    Туннелирование

    Туннелирование используется для инкапсуляции сетевых протоколов (TCP/IP, AppleTalk и NetBEUI ) в пакете IP, который может перемещаться через интернет. TCP/IP может перемещаться через интернет и сам по себе, но тогда он не будет частью туннеля или VPN. Туннель можно представить себе как путь, который прокладывает в земле крот для перемещения из одного места в другое.

    Прежде чем создать туннель, нужно убедиться, что две конечные точки соответствуют данным, с помощью которых они себя идентифицируют. После их аутентификации создается туннель и происходит пересылка информации между этими конечными точками, см. рис. 4.11 . Создание туннелей VPN в Windows Server 2003 происходит с помощью двух протоколов – PPTP и L2TP , которые описаны выше. L2TP является расширением относительно протокола туннелирования PPTP , и он использует аутентификацию и протокол шифрования IPSec.

    L2TP имеется только в версии RRAS для Windows 2000 и Windows Server 2003, и его могут использовать только клиенты Windows, начиная с Windows 2000. В таблице 4.4 описывается, какие клиенты поддерживают различные протоколы туннелирования. Вы можете добавить поддержку L2TP /IPSec к Windows 98, Windows Me и Windows NT 4, загрузив и установив L2TP /IPSec VPN Client с веб-сайта Microsoft.

    Шифрование

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


    Рис. 4.11.

    Windows Server 2003 поддерживает две технологии шифрования, Microsoft Point-to-Point Encryption ( MPPE ) и IPSec. В обеих моделях используется ключ шифрования для шифрования и дешифрования информации в точках отправки и получения. Вы можете потребовать, чтобы удаленные клиенты или сайты использовали любой из этих методов. Если они не используют указанный вами метод шифрования, то вы можете сконфигурировать RRAS, чтобы запретить данное соединение.

    Таблица 4.4. Клиенты и протоколы туннелирования, которые они поддерживают
    Клиент VPN Поддерживаемые протоколы туннелирования
    Windows Server 2003 PPTP , L2TP
    Windows XP PPTP ,

    Вопросы реализации VPN

    То, что сети VPN представляют наиболее передовые технологии для дистанционного доступа, не обязательно означает, что VPN являются подходящим решением для вашей ситуации. Прежде чем реализовать такое решение в вашем сетевом окружении Windows Server 2003, вы должны учесть следующие факторы.

    • Безопасность . Вопросы безопасности должны быть одним из наиболее важных факторов, влияющих на ваше решение использовать VPN. Вы должны задаться двумя вопросами. Во-первых, не будет ли VPN "излишеством" для типа информации, которую вы передаете? Например, вы можете просто отправлять неконфиденциальную электронную почту. Во-вторых, будет ли VPN удовлетворять вашим требованиям безопасности. В качестве примера обычно приводят государственные учреждения. Например, военные даже не будут рассматривать возможность использования VPN через открытую сеть, несмотря на уровень безопасности, который предполагает эта технология.
    • Финансовые вопросы . Начальные и текущие расходы на реализацию VPN в сетевом окружении Windows Server 2003 ничтожны по сравнению с арендуемыми линиями. VPN, несомненно, дает вам экономию средств, поскольку в настоящее время сайты и удаленные клиенты могут подсоединяться к сети компании защищенным образом без дополнительных расходов на оплату телефона и т.п. Ясно, что удаленные пользователи могли бы использовать номер 800 (код бесплатных звонков), но это не решает проблему в целом и все же требует существенных затрат.
    • Пропускная способность , Поскольку для сетей VPN требуется аутентификация и шифрование, скорость передачи данных (по определению) будет ниже, чем без них. При использовании VPN можно наблюдать снижение производительности от 30 до 50 процентов. Вам потребуется сравнить это снижение производительности с получаемым уровнем безопасности.

    Имеется довольно много факторов, которые требуется продумать, прежде чем реализовать VPN. Но если вы рассмотрели эти три вопроса, то будете более уверены в своем решении включать (или не включать) возможности VPN в свою сеть Windows Server 2003.

    Выбор варианта реализации VPN

    Имеются два основных типа реализации VPN: коммутируемое VPN-соединение (dial-up VPN) и соединение между сайтами (site to site). Сочетание этих двух типов можно определить как третий тип.

    • Коммутируемое VPN-соединение . Обычно удаленные клиенты набирают номер телефона своего локального провайдера услуг Интернет (ISP) и затем "звонят" на сервер VPN Windows Server 2003, чтобы установить VPN-соединение между этим сервером VPN и удаленным клиентом. Это дает экономию расходов на междугородние телефонные соединения для удаленного клиента, а также дает экономию в том месте, где находится сервер VPN, так как во многих случаях это позволяет избежать установки большого числа модемов и других устройств дистанционного доступа, используемых для соединений.
    • Соединение между сайтами . Этот вариант является наиболее распространенным вариантом реализации VPN. При этом сценарии вы используете два или более серверов VPN Windows Server 2003 для создания VPN между ними. Между этими двумя сайтами определяется защищенный обмен информацией. Пользователи любой из этих сетей могут взаимодействовать с другим удаленным сайтом.
    • Сочетание этих типов . В окружениях Windows Server 2003, где имеются как удаленные клиенты, так и сайты, можно создавать реализации VPN, которые могут обслуживать оба типа соединений.

    Ещё один компьютерный пост.

    Недавно построил WiFi-сетку с аутентикацией по 802.1x, использующую сертификаты для опознания юзеров. В числе прочего, пришлось настраивать для работы с ней устройства на Android – смартфоны и планшетки. Тут-то и выяснилось, что нормального howto, как это сделать, найти не получается – те, которые были, касались сценариев с паролями, а мне от них-то и хотелось избавиться. Потому и решил свести информацию по вопросу в один пост.


    Что такое 802.1x и как его использовать на Windows и Linux , написано предостаточно, поэтому тут будет только про настройку клиента на Android.

    Итак, в чём цель? Надо создать сетку с приличным шифрованием и надёжной аутентикацией, при этом требуется, чтобы аутентикация была как можно более удобна для юзера, но при этом защищена от юзера же. То есть я, в качестве админа, не хочу, чтобы юзер мог передать кому другому свой пароль или файл с секретным ключом, или же подключился с устройства, с которого я не хочу позволять ему подключаться – например, личного лэптопа. В общем, мрак и диктатура.

    Для этого делаем следующее: на устройство (телефон, планшетку) ставится сертификат с секретным ключом (на каждый девайс – отдельный ключ). Управление ключами в Андроиде весьма примитивно, однако даёт ровно тот минимум, какой нам требуется – даёт импортировать ключ и использовать его, но не извлекать обратно (по крайней мере, без пароля, который мы выдавать не собираемся). Эти ключи и будут выдаваться access point’у в ответ на требование представиться.

    Процедурка вся укладывается в 4 шага:

    1. Подготовка “credential storage” :
    Перед тем, как заводить в девайсину какие-либо секретные ключи, надо подготовить для них хранилище, где ключи будут сохраняться в зашифрованном виде. Шифрование будет происходить на основе пароля, который вводится лишь при создании хранилища. Для использования секретного ключа пароль вводить не нужно – лишь для его экспорта (который к тому же невозможно осуществить через обычный андроидный UI). Посему пароль мы этот оставим у себя, а юзеру выдавать отнюдь не будем. Evil laughter прилагается.

    [Update : увы, не выйдет. При выключении девайса пароль уходит, и для использования ключей его придётся вводить заново. У этого есть и хорошие, и плохие стороны:
    * Сохранять пароль в тайне от юзера не выйдет - иначе придётся вводить его всякий раз при включении.
    * Это значит, что теоретически юзер может скопировать из девайса секретный ключ - что с админской точки зрения плохо. Но, насколько я понимаю, ему для этого требуется рутовый доступ. Получение такого доступа хлопотно, но возможно.
    * Хорошая сторона в том, что сам пароль в флэш-памяти не сохраняется - а криптоключи, которые сохраняются, шифруются этим паролем по AES.
    * Ну и к тому же, если пароль при включении введён ещё не был, то это даёт защиту от кого-то постороннего, кто попытается использовать ключ, пароля не зная.
    ]

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

    Собственно процесс: Settings --> Location and security --> Set password . Ввести пароль дважды. После чего галочка “Use secure credentials ” включится автоматически.

    Чтобы поменять пароль: “Set password ” повторно.

    Чтобы обнулить всё нафиг: “Clear storage ” там же.

    2. Импорт корневого сертификата :
    Нужно забросить в девайс файл с расширением .crt (.cer не принимается) и в формате PEM, также известном как Base-64. Можно это сделать через USB, можно через Bluetooth. Файл должен быть скопирован в директорию /sdcard – та, что видна как корень при подключении девайса через USB или при просмотре файлов через “My Files ”.

    Затем: Settings --> Location and security --> (хоть в данном случае сертификат и не encrypted). Сертификат будет добавлен в список доверяемых, а файл в /sdcard стёрт.

    Более удобный способ: опубликовать сертификат на каком-нибудь веб-сайте и просто открыть его URL в родном андроидном браузере (для пущей надёжности, использовать известный вебсервис через https или же сугубо внутренний сайт). Тот сразу запросит, добавить ли сертификат в список доверяемых, или нет. Чтобы не набивать URL руками, можно сгенерировать QR-code с ним, и затем просто отсканить его.

    3. Импорт сертификата юзера с секретным ключом :
    Файл с секретным ключом в формате PKCS#12 и с расширением .p12 кладётся в /sdcard (.pfx , опять же, игнорируется). Способов создать такой файл множество – не буду их перечислять, но отмечу, что обязательно стоит задать для него одноразовый пароль, шифрующий ключ.
    Затем, опять же, Settings --> Location and security --> Install encrypted certificates . На этот раз будет запрошен пароль. Это не тот, что задавался при создании хранилища, а тот, который нужен для расшифровки ключа из файла. После введения пароля, ключ будет дешифрован и сохранён зашифрованным заново – на этот раз, паролем от хранилища. Файл же будет стёрт из /sdcard , что нас вполне устраивает.

    Можно также забросить файл .p12 через URL, но я бы не стал – в отличие от сертификатов, расползания ключей, хоть и в шифрованном виде, стоит избегать.

    4. Подключение к собственно сети :
    После того, как ключ задан, остались лишь настройки WiFi-сети. Ничего секретного в этом этапе нет, можно оставить его юзерам, выслав инструкцию.
    Итак: Settings --> Wireless and network --> Wi-Fi settings . Найти сеть в списке, либо, если SSID скрыт, жмякнуть на “Add Wi-Fi network ”.
    Затем:



    На более продвинутых устройствах можно задать также для каждой сети настройки proxy, что очень удобно.

    Всё. После этого юзеру останется только жмякнуть по названию сетки и подключиться. Если же он по недомыслию как-нибудь нажмёт на “Forget network ” и сотрёт настройки, для восстановления достаточно лишь пройти заново шаг 4 – процедура несекретная, юзер её может проделать сам.

    Примечания:
    В принципе, есть также опция PEAP. Протокол PEAP-EAP-TLS считается чуть более защищённым – к примеру, юзерский сертификат в нём пересылается в зашифрованном виде по установленному туннелю TLS. Однако мои усилия заставить Андроид работать в этом режиме ни к чему не привели. Подозреваю, что дело в том, что поле “Phase 2 authentication ” не содержит опции для использования юзерского сертификата – поэтому приходится удолетворяться EAP-TLS, которому никакой phase 2 не нужен. Но разница минимальна и несущественна.

    Понятия не имею, зачем нужен. В принципе, юзер должен опознаваться по полю CN в сертификате.

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

    Думаю не нужно напоминать, что скрытие SSID точки доступа не защищает Вас. Ограничение доступа по MAC адресу не эффективно. Поэтому только современные методы шифрования и сложный пароль.

    Зачем шифровать? Кому я нужен? Мне нечего скрывать

    Не так страшно если украдут пин-код с кредитной карты и снимут с нее все деньги. Тем более, если кто-то будет сидеть за ваш счет в интернете, зная Wi-Fi пароль. И не так страшно если опубликуют ваши фото с корпоративных вечеринок где вы в неприглядном виде. Куда обидней когда злоумышленники проникнут в ваш компьютер и удалят фотографии как Вы забирали сына из роддома, как он сделал первые шаги и пошел в первый класс. Про бэкапы отдельная тема, их конечно нужно делать… Но репутацию со временем можно восстановить, деньги заработать, а вот дорогие для вас фотографии уже нет. Думаю у каждого есть то, что он не хочет потерять.
    Ваш роутер является пограничным устройством между личным и публичным, поэтому настройте его защиту по полной. Тем более это не так сложно.

    Технологии и алгоритмы шифрования

    Опускаю теорию. Не важно как это работает, главное уметь этим пользоваться.
    Технологии защиты беспроводных сетей развивались в следующем хронологическом порядке: WEP , WPA , WPA2 . Также эволюционировали и методы шифрования RC4, TKIP, AES.
    Лучшей с точки зрения безопасности на сегодняшний день является связка WPA2-AES. Именно так и нужно стараться настраивать Wi-Fi. Выглядеть это должно примерно так:

    WPA2 является обязательным с 16 марта 2006 года. Но иногда еще можно встретить оборудование его не поддерживающее. В частности если у Вас на компьютере установлена Windows XP без 3-го сервис пака, то WPA2 работать не будет. Поэтому из соображений совместимости на маршрутизаторах можно встретить варианты настроек WPA2-PSK -> AES+TKIP и другой зверинец.
    Но если парк девайсов у Вас современный, то лучше использовать WPA2 (WPA2-PSK) -> AES, как самый защищенный вариант на сегодняшний день.

    Чем отличаются WPA(WPA2) и WPA-PSK(WPA2-PSK)

    Стандартом WPA предусмотрен Расширяемый протокол аутентификации (EAP) как основа для механизма аутентификации пользователей. Непременным условием аутентификации является предъявление пользователем свидетельства (иначе называют мандатом), подтверждающего его право на доступ в сеть. Для этого права пользователь проходит проверку по специальной базе зарегистрированных пользователей. Без аутентификации работа в сети для пользователя будет запрещена. База зарегистрированных пользователей и система проверки в больших сетях как правило расположены на специальном сервере (чаще всего RADIUS).
    Упрощённый режим Pre-Shared Key (WPA-PSK, WPA2-PSK) позволяет использовать один пароль, который хранится непосредственно в маршрутизаторе. С одной стороны все упрощается, нет необходимости создавать и сопровождать базу пользователей, с другой стороны все заходят под одним паролем.
    В домашних условиях целесообразней использовать WPA2-PSK, то есть упрощенный режим стандарта WPA. Безопасность Wi-Fi от такого упрощения не страдает.

    Пароль доступа Wi-Fi

    Тут все просто. Пароль к вашей беспроводной точке доступа (роутеру) должен быть более 8 символов и содержать буквы в разном регистре, цифры, знаки препинания. И он никаким боком не должен ассоциироваться с вами. А это значит, что в качестве пароля нельзя использовать даты рождения, ваши имена, номера машин, телефонов и т.п.
    Так как сломать в лоб WPA2-AES практически невозможно (была лишь пара случаев смоделированных в лабораторных условиях), то основными методами взлома WPA2 являются атака по словарю и брут-форс (последовательный перебор всех вариантов паролей). Поэтому чем сложней пароль, тем меньше шансов у злоумышленников.

    … в СССР на железнодорожных вокзалах получили широкое распространение автоматические камеры хранения. В качестве кодовой комбинации замка использовались одна буква и три цифры. Однако мало кто знает, что первая версия ячеек камеры хранения использовала в качестве кодовой комбинации 4 цифры. Казалось бы какая разница? Ведь количество кодовых комбинаций одинаково — 10000 (десять тысяч). Но как показала практика (особенно Московского Уголовного Розыска), когда человеку предлагалось в качестве пароля к ячейке камеры хранения использовать комбинацию из 4-х цифр, то очень много людей использовало свой год рождения (чтобы не забыть). Чем небезуспешно пользовались злоумышленники. Ведь первые две цифры в дате рождения абсолютного большинства населения страны были известны — 19. Осталось на глазок определить примерный возраст сдающего багаж, а любой из нас это может сделать с точностью +/- 3 года, и в остатке мы получаем (точнее злоумышленники) менее 10 комбинаций для подбора кода доступа к ячейке автоматической камеры хранения…

    Самый популярный пароль

    Человеческая лень и безответственность берут свое. Вот список самых популярных паролей:

    1. 123456
    2. qwerty
    3. 111111
    4. 123123
    5. 1a2b3c
    6. Дата рождения
    7. Номер мобильного телефона

    Правила безопасности при составлении пароля

    1. Каждому свое. То есть пароль маршрутизатора не должен совпадать с любым другим Вашим паролем. От почты например. Возьмите себе за правило, у всех аккаунтов свои пароли и они все разные.
    2. Используйте стойкие пароли, которые нельзя угадать. Например: 2Rk7-kw8Q11vlOp0

    У Wi-Fi пароля есть один огромный плюс. Его не надо запоминать. Его можно написать на бумажке и приклеить на дно маршрутизатора.

    Гостевая зона Wi-Fi

    Если ваш роутер позволяет организовать гостевую зону. То обязательно сделайте это. Естественно защитив ее WPA2 и надежным паролем. И теперь, когда к вам домой придут друзья и попросятся в интернет, вам не придется сообщать им основной пароль. Более того гостевая зона в маршрутизаторах изолирована от основной сети. И любые проблемы с девайсами ваших гостей не повлияют на вашу домашнюю сеть.