Меню

Wpa2 enterprise radius настройка

unboxIT

Если информация была полезной для вас, вы можете поблагодарить за труды Яндекс деньгами: 41001164449086 или пластиковой картой:

WPA-Enterprise или WiFi по логину и паролю

Проблема безопасности для беспроводных сетей является первоочередной по той причине, что фактически любой желающий имеет доступ к среде распространения сигнала — радиоканалу. Сегодня встретить беспроводную сеть WiFi в которой не применяется шифрование или применяется но уже довольно давно взломанный WEP довольно сложно. Чаще всего используется WPA(2)-PSK или так называемый WPA(2)-Personal, который строиться на всё том-же одном ключе шифрования зная который пользователи и подключаются к сети. Это решение является оптимальным лишь только когда количество беспроводных клиентов достаточно мало. Ведь в случае необходимости смены ключа по какой-то причине (например его кража) его придётся менять и на всех клиентских устройствах, а для большой сети это просто не приемлемо. Ответ вполне очевиден – необходимо использовать аутентификацию оттренированную на каждого пользователя в отдельности, а если говорить по простому то у каждого пользователя должен быть свой логин и пароль. Ведь в случае необходимости его смены (или отключения), это достаточно будет сделать только на единожды (на сервере и клиенте). Вот тут и приходит на помощь WPA-Enterprise ориентированный на беспроводные сети с большим числом беспроводных устройств. Статья в большей степенью является практическим руководством, которое получилось в результате моего желания разобраться с этой темой.

Итак, что нам для этого понадобиться.
Беспроводной клиент (ака ноутбук с WiFi), точка доступа и сервер под управлением Linux c FreeRADIUS.

Протестировано на:
FreeRADIUS 2.1.9
Mandriva free 2010
Dlink DWL-2100AP, DWL-3200AP
WindowsXP professional.

1. Установка и первичная настройка FreeRADIUS

Для того чтобы работала WPA-Enterprise (не вдаваясь в подробности далее я буду называть её PEAP) авторизация в системе должны также присутствовать пакеты openssl и openssl-devel. Установим их (или убедимся что они присутствуют):

Ставить FreeRADIUS будем из сырцов, чтоб разобраться в деталях с его установкой. Качаем от сюда: freeradius.org

После того как скачали и распаковали надо поправить один файл:
/src/main/modules.c
вытащив из ifdef endif

#define lt__PROGRAM__LTX_preloaded_symbols lt_libltdl_LTX_preloaded_symbols

чтобы было определенно наверняка, потому как условие ifdef походу не выполняется.

Если этого не сделать то в процессе компиляции вылезет ошибка. С чем она связана я толком так и не понял, но появляется она в основном в дистрибутивах Ubuntu, хотя на моём дистрибутиве она тоже присутствовала.

По умолчанию всё ставиться в /usr/local. Если необходимо то можно добавить опцию —prefix к ./configure.
Далее всё стандартно:

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

Формат записи по сравнению с первой версией FreeRADIUS несколько изменён, но думаю тут всё вполне очевидно. Единственное о чём тут следует упомянуть, так это то что если в имени пользователя присутствуют символы пробела то его имя при записи в файл надо взять в двойные кавычки, например: «test 123».

Теперь необходимо задать тип eap’а по умолчанию, который будет использоваться для авторизации.
Отредактируем файл:
/usr/local/etc/raddb/eap

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

2. Настройка точки доступа

В моём распоряжении оказалось 2 точки доступа от Dlink это довольно популярная модель DWL-2100AP и её промышленный собрат DWL-3200AP. Забегая вперёд скажу, что обе они прекрасно заработали с FreeRADIUS. С точки зрения настройки RADIUS’а они практически идентичны, да и точки доступа от других производителей не сильно будут отличаться по настройкам. В качестве примера я всё же будут рассматривать DWL-3200AP, поскольку она изначально позиционируется как промышленное решение направленное в первую очередь на корпоративную среду.

В настройках точки доступа необходимо указать ряд параметров относящихся к безопасности:

Вот скриншот с примером настройки DWL-3200AP

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

3. Настройка компьютера пользователя.

Под рукой у меня оказался только нетбук под управлением WindowsXP по этому далее опишу процесс настройки именно под этой ОС.
После того как система найдёт нашу беспроводную сеть, необходимо настроить дополнительные параметры, для чего щёлкним на соответствующий пункт.
Далее в списки сетей выберем необходимую сеть и нажмём на «Свойства»

Убедившись ещё раз что используется требуемая проверка подлинности и шифрования данных перейдём на вкладку «Проверка подлинности».
Тип EAP укажем PEAP, и нажмём на «Свойства». В открывшемся окне выберем в качестве метода проверки EAP-MSCHAP v2, нажмём «Настроить». После чего в вновь открывшемся окне уберём галочку «Автоматически использовать имя входа и пароль Windows. ».

Читайте также:  Сбились настройки экрана компьютера windows

Дале Ok Ok Ok ну и т.д.
После того как настроены дополнительные параметры, при попытки подключиться к нашей беспроводной сети Windows предложит щёлкнуть по значку Беспроводного соединения для того чтобы указать учётные данные.

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

4. Расширенная настройка FreeRADIUS

Если помните при настройках в свойствах соединения мы убирали галочку «Автоматически использовать имя входа и пароль Windows. », давая тем самым возможность пользователю в ручном режиме ввести имя пользователя и пароль. Но что если упростить задачу для пользователя, и использовать автоматический ввод его учётных данных (т..е. тех которые он использует в Windows локально). При этом в качестве логина и пароля будут использоваться его имя в системе и соответственно его пароль. Но тут возникает небольшая сложность.
Дело всё в том, что в случае использования автоматического имя входа и пароля Windows, серверу RADIUS будет послана связка ИМЯКОМПЬЮТЕРА\\ИМЯПОЛЬЗОВАТЕЛЯ или ИМЯДОМЕНА\\ИМЯПОЛЬЗОВАТЕЛЯ (если компьютер состоит в домене, но этот случай я рассматривать не буду) в качестве его логина ну и конечно его пароль. Можно конечно прописать логины пользователей в FreeRADIUS с учётом имени компьютеров, но это не всегда удобно и как-то не слишком красиво, или если ещё по какой-то причине вам необходимо отбрасывать имя компьютера (название домена) при авторизации то далее я покажу как это сделать.

Для начала поправим главный конфиг /usr/local/etc/raddb/radiusd.conf

Именно $INCLUDE proxy_realm.conf заменив этой строчкой $INCLUDE proxy.conf

Создадим файл:
/usr/local/etc/raddb/proxy_realm.conf

realm DEFAULT <
type = radius
authhost = LOCAL
accthost = LOCAL
>
realm LOCAL <
>

Теперь в двух словах о том зачем это сделано. реалм DEFAULT говорит о том что все логины, которые не попали ни в один другой реалм который обрабатывался ранее, будет проверен в RADIUS локально, но уже с отрезанной доменной частью. Для чего также необходимо раскаментировать в файле /usr/local/etc/raddb/sites-available/inner-tunnel в секции authorize <>

Реалм (realm) — это перенаправление, ну или если хотите ссылка. Наверное не совсем понятно, но для настройки вполне достаточно. Более подробно узнать об этом можно пожалуй пожалуй прочитав весь мануал по FreeRADIUS.

Теперь поправим файл
/usr/local/etc/raddb/modules/mschap

mschap <
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes
>

Особое внимание следует уделить строчке with_ntdomain_hack = yes Дело в том что как уже было отмечено ранее MS Windows посылает связку ИМЯДОМЕНА\\ИМЯПОЛЬЗОВАТЕЛЯ а в ответ (challange responce) получает только ИМЯПОЛЬЗОВАТЕЛЯ. Но это уже тонкости. Кто хочет разобраться — гугл в помощь 🙂
Теперь опять запустим наш сервер в режиме отладки:

Теперь, если всё было сделано верно, то какие бы данные мы не вводили в поле домен (для проверки) они автоматически должны отбрасываться и процесс авторизации должен проходить успешно, разумеется при правильном логине и пароле.

Теперь в /usr/local/etc/raddb/users можно прописать имена пользователей и их пароли которыми они пользуются в Windows. Также как я думаю уже всем понятно требуется вернуть назад галочку «Автоматически использовать имя входа и пароль Windows. » в настройках беспроводного соединения.
Честно говоря в моём случае было необходимо только отбрасывать имя домена при авторизации, и по этому как себя поведёт система в случае если скажем в качестве имени пользователя на компьютере используется кириллица я не знаю. Однако даже если нет необходимости отбрасывать доменную составляющую, то всё равно рекомендую настроить файлы конфигураций то как это показано выше.

5. Запуск FreeRADIUS в фоновом режиме и автозапуск

Mandriva как например Fedora (до недавнего времени) да и многие другие дистрибутивы используют System-V систему загрузки. После установки в системе уже присутствует вполне рабочий скрипт запуска по адресу: /usr/local/sbin/rc.radiusd. И в принципе чтоб запустить сервис в нормальном режиме достаточно дать команду:
/usr/local/sbin/rc.radiusd start

Однако по скольку в моём случае дистрибутив Mandriva, с его System-V системой загрузки, то скрипт необходимо несколько модифицировать чтоб он в полной мере соответствовал формату chkconfig. Для этого в самое начало скрипта добавляем строки:

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

cat /usr/local/sbin/rc.radiusd >> /etc/rc.d/init.d/radius_server

Переименовать файл пришлось из-за того что по непонятным мне причинам chkconfig не воспринимает точек в именах файлов. Да и не забываем поставить права доступа в 755 для вновь скопированного скрипта.
Теперь дадим команды для того чтоб добавить его в список сервисов и добавим его в автозапуск на 3-тем и 5-том уровнях запуска:

Для того чтоб лишний раз убедиться что всё работает так как надо можно перезагрузить сервер и проверить в процессах radiusd, командой:

Для того кого интересуют более подробная информация могу посоветовать прочитать соответсвующие мануалы и статью:
www.ixbt.com/comm/prac-wpa-eap.shtml

Читайте также:  Dir 320 asus прошивка настройка

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

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

Если информация была полезной для вас, вы можете поблагодарить за труды Яндекс деньгами: 41001164449086 или пластиковой картой:

Источник

Инструменты пользователя

Инструменты сайта

Делаем закрытую сеть Wi-Fi с авторизацией по МАС-адресу на основе двух точек TP-Link TL-WR842ND.

Содержание

Цель: организовать закрытую сеть WiFi cо списком доступа по MAC-адресу и централизованным управлением этим списком на точках доступа TP-Link TL-WR842ND.

Требуемый уровень безопасности допускает организацию доступа к беспроводной сети на основе списка разрешенных MAC-адресов. В тоже время есть потребность ограничить любого желающего от доступа к сети. Хотя с другой стороны, любой желающий, просканировав эфир, может определить MAC-адреса разрешенных пользователей, и подключиться к сети скопировав полученный MAC на свой беспроводной интерфейс. Это противоречие и предстоит разрешить в работе: ограничить возможность доступа к сети «любому желающему» наиболее простыми методами с возможностью централизованного управления доступом (без надобности вносить изменения на каждой точке доступа в отдельности).

Введение

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

RADIUSPicking Auth-TypeAuthenticating

И на всякий случай синхронизирую термины:

Ни вы, ни радиус не знает и не решает, что клиент вам пришлет в запросе. Ответственность за то, что содержится в запросе лежит 100% на клиенте.

Радиус сервер смотрит на запрос и говорит:

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

Сервер начинает опрашивать модули этапа авторизации (в конфиге есть отдельная секция authorize <> ):

В какой-то момент один из модулей скажет:

Модули делают это на основании просмотра ключевых атрибутов пришедших в запросе, таких как MS-CHAP-Challenge (для MS-CHAP ), или CHAP-Challenge (для CHAP ), or EAP-Message (для EAP ). Или же на основании предположения, что надо бы добавить что-то в каждый запрос.

Если модуль думает, что у него есть шанс чтобы ещё и аутентифицировать пользователя, он скажет:

Если модуль ничего не распознаёт, или знает, что нет необходимости что-то искать, то он просто ничего не делает.

В конце авторизации, сервер проверит добавлен ли Auth-Type к запросу. Если нет, то немедленно отклонит запрос.

Таким образом, сервер снова обратится к модулю pap, но уже на стадии аутентификации ( она также имеет свою секцию в конфиге authenticate <> ), pap ответит:

Итак, затем идет сравнение локального заранее известного правильного пароля с тем, который ввел пользователь (пришел в запросе). Это то, как работает аутентификация.

Что, если клиент отправит MSCHAP запрос? Что будет с этим запросом делать радиус-сервер?

В этом случае, модуль mschap ищет в запросе атрибут MS-CHAP на этапе авторизации и когда находит устанавливает атрибут Auth-Type на себя (mschap), но уже для этапа аутентификации. Модуль базы данных (например, такой как LDAP, выше) получает информацию о «правильном» пароле и добавляет её в запрос. Затем модуль mschap вызывается уже для процесса аутентификации. Он просматривает запрос в поисках «правильного» пароля либо в виде текста, либо в виде NT-HASH (почему? Смотрите таблицу протоколов http://deployingradius.com/documents/protocols/compatibility.html ). Если ни один требуемый вид пароля не будет предоставлен хранилищем данных, то mschap скажет:

Но сервер уже исчерпал варианты, его единственный вариант был mschap, так как это то, что клиент послал в запросе. Mschap модуль не смог ничего сделать, потому что ему не предоставили «правильный» пароль. Таким образом сервер за неимением вариантов запрос отклоняет. MSCHAP данные могли быть корректными, но у сервера не было способа убедиться в этом. Поэтому он ответил отказом.

Выводы

1. Обоснование

На имеющихся беспроводных маршрутизаторах TP-Link TL-WR842ND с заводской прошивкой у нас есть возможность использовать следующие типы защиты: WPA2–PSK, WPA2–Enterprise. Остальные варианты не рассматривались из-за их неактуальности: открытая сеть не соответствует поставленной цели; WEP – давно скомпрометирован; WPA-PSK/Enterprise – есть же WPA2 c более строгим подходом к шифрации.

WPA2-PSK – использует Pre-shared key, который в общем случае устраивал бы, но так как было желание управлять допущенными к сети MAC-адресами пользователей централизованно, а не на каждой точке в отдельности, доставляет некоторое неудобство.

WPA2-Enterprise – использует RADIUS-сервер для авторизации/аутентификации; учет пользователей (accounting) не поддерживается точкой доступа TP-Link TL-WR842ND. Отправляет в запросе к RADIUS MAC-адрес пользователя – следовательно можно вести список разрешенных MAC на RADIUS-сервере. WR842ND не умеет подставлять MAC-адрес вместо имени пользователя и пароля (такая возможность есть, например, в RouterOS от Mikrotik), поэтому придется заводить учетные данные (пользователь/пароль) либо на каждого пользователя можно с привязкой к MACy, либо одну общую учетку, о которой будут осведомлены все заинтересованные пользователи, а список MAC-адресов будет вестись отдельно.

Читайте также:  Настройка часов на брелке starline a92

Так как централизованно управлять списком доступа на основании MAC-адресов позволяет RADIUS-сервер, то выбор защиты Wi-Fi сети пал на WPA2-Enterprise.

WPA2-Enterprise поддерживает ряд методов аутентификации EAP. Для Window актуальны EAP-TLS и EAP-PEAPv0. EAP-TLS – поможет избавить пользователя от введения логина и пароля, но здесь встанет другая задача по разворачиванию инфраструктуры открытых ключей и распределению сертификатов. Причем встанет проблема установки сертификатов на мобильных устройствах. Хоть данный метод самый надёжный, но из-за сложности развёртывания и сопровождения для наших нужд он отпадает.

EAP-PEAPv0 с MS-CHAPv2 – от пользователя требуется доверие к точке доступа/серверу и знание связки логин/пароль. Доверие к точке доступа/серверу достигается проверкой предъявляемого сервером сертификата, либо отключением этой проверки. Суть метода состоит в создании защищённого туннеля внутри которого осуществляется аутентификация пользователя по методу MS-CHAPv2. Простое развёртывание и сопровождение, особенно если слепо доверять точке доступа/серверу. Но страдает безопасность от «активных» злоумышленников.

Метод EAP-PEAPv0 с MS-CHAPv2 существенно проще в реализации, чем EAP-TLS и позволит организовать закрытую сеть, тем самым «любому желающему» будет гораздо сложнее, нежели просто определить разрешенный MAC-адрес, если конечно у него не будет альтернативного метода получения доступа к учетным данным.

Реализация метода EAP-PEAPv0 с MS-CHAPv2 во FreeRADIUS позволяет выдавать пользователю индивидуальную связку логин/пароль и привязывать их к MAC-адресу его оборудования. Хотя для наших целей это было признано нецелесообразным из-за дополнительной нагрузки на администраторов сети по сопровождению пользователей. Поэтому будет общий логин/пароль на всех, так как некоторые wi-fi клиенты не дают возможности оставлять данные поля пустыми.

Итог: беспроводной маршрутизатор TP-Link TL-WR842ND будет работать в режиме точки доступа с методом безопасности WPA2-Enterprise, который предполагает использование RADIUS-сервера. RADIUS-сервер на базе FreeRADIUS будет реализовывать список доступа на основе MAC-адресов и производить аутентификацию пользователей по методу EAP-PEAPv0 с MS-CHAPv2. При данном методе, пользователю необходимо доверять точеке доступа/серверу (или проверять сертификат для установки доверия) и знать учетные данные (логин/пароль) для прохождения MS-CHAPv2 аутентификации.

2. Реализация

Следует отметить, что приведенные команды и фрагменты конфигурации тестировались на Debian 7.5 c FreeRADIUS 2.1.12+dfsg-1.2

2.1 Создание production-сертификатов

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

Инструменты для создания сертификатов нужных freeradius у Debian лежат по пути /usr/share/doc/freeradius/examples/certs. Содержимое этого каталога следует скопировать в /etc/freeradius/certs. Необходимы файлы:

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

Для работы скриптов понадобится openssl и make.

Создаем файл с параметрами Диффи-Хеллмана, если он вдруг отсутствует в каталоге /etc/freeradius/certs:

Результат работы: файл dh

Создаём корневой сертификат или сертификат удостоверяющего центра. Если до этого уже были какие-то сертификаты (обычно тестовые), то удаляем:

Результат работы: помимо прочих файлы server.pem и server.key – сертификат и закрытый ключ сервера.

В конфигурации пути к сертификатам сгенерированным в папке /etc/freeradius/certs прописаны по умолчанию.

Если был изменён пароль на закрытый ключ сервера ( output_password ), то его придется указать в конфиге. А также нужно закомментировать путь к скрипту создания временных сертификатов. Это делается в файле /etc/freeradius/eap.conf в следующей секциии:

2.2 Описываем RADIUS-клиентов (точки доступа)

Добавляем в файл /etc/freeradius/clietns.conf следующее:

2.3 Заводим учетные данные для аутентификации по логину и паролю

В файл /etc/freeradius/users добавляем первую строку следующего содержания:

2.4 Добавляем список доступа на основе MAC-адресов

Вариант1.

Тем самым на одну пару логин/пароль вешаем три различных MAC-адреса.

Вариант2.

Чтобы проверка MAC-адресов из файла /etc/freeradius/authorized_macs выполнялась, нужно в файл /etc/freeradius/sites-available/default в секцию authorize <> после объявления rewrite.calling_station_id вставить прокомментированные строки:

Советы и замечания

При изменениях в конфиге radiusd.conf лучше демон перезагрузить:

Чтобы проверить конфигурацию следует запускать демон в режиме отладки:

При таком запуске можно увидеть как freeradius распарсил конфиг и увидеть как он обрабатывает запросы. Очень помогает при отыскании различных проблем или при объяснении неожиданного поведения.

В комплекте идет полезная утилитка radtest – простой RADIUS-клиент. С ней можно проводить некоторые простые тесты для проверки конфигурации. Возможный пример использования (тестирование внутритуннельной аутентификации по порту 18120):

Источник