WiFi Enterprise. FreeRadius FreeIPA Ubiquiti | Hi-Tech | Селдон Новости

Что дальше

Опи­са­ние настрой­ки WiFi не вхо­дит в рам­ки дан­ной инструк­ции. В двух сло­вах, выпол­ня­ем сле­ду­ю­щие шаги:

1. На WiFi кон­трол­ле­ре или точ­ке досту­па ука­зы­ва­ем тип про­вер­ки под­лин­но­сти с исполь­зо­ва­ни­ем RADIUS. В каче­стве послед­не­го ука­зы­ва­ем его IP-адрес, а так­же пароль­ную фра­зу, кото­рую пла­ни­ру­ем исполь­зо­вать для про­вер­ки подлинности.
2. На Freeradius в кон­фи­гу­ра­ци­он­ном фай­ле clients.conf созда­ем раз­дел с ука­за­ни­ем IP-адре­са устрой­ства, с кото­ро­го будет отправ­лять­ся запрос на про­вер­ку под­лин­но­сти, так­же ука­зы­ва­ем пароль­ную фразу.
3. Под­клю­ча­ем­ся к WiFi с исполь­зо­ва­ни­ем учет­ных дан­ных, хра­ни­мых во FreeIPA.

Edit EAP  from mods-available/eap  to include

default_eap_type = leap
...
 leap {
default_eap_type = mschapv2
copy_request_to_tunnel = no
use_tunneled_reply = no 
virtual_server = "inner-tunnel" 
}
...
peap {...
default_eap_type = mschapv2
...
}

6. edit  sites-available/default and sites-available/inner-tunnel to include (which seems to be default in Freeradius 3)

authorize{
...
      -ldap
...}

Edit client.conf to include the ip or network of your APs

client myNASS1 { ipaddr = 192.168.2.10 proto = * secret = foobar123 require_message_authenticator = yes nas_type = other limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } }

Eap_peap: error: tls alert write:fatal:protocol version

При под­клю­че­нии неко­то­рых устройств мы можем полу­чить ошибку:

При­чи­на: по умол­ча­нию, eap настро­ен на исполь­зо­ва­ние TLS вер­сии 1.2. Если устрой­ство, с кото­ро­го мы под­клю­ча­ем­ся исполь­зу­ет вер­сию про­то­ко­ла выше или ниже, то мы полу­чим ошибку.

Реше­ние: в настрой­ках RADIUS-сер­ве­ра есть воз­мож­ность ука­зать, какие вер­сии TLS долж­ны под­дер­жи­вать­ся. Откры­ва­ем кон­фи­гу­ра­ци­он­ный файл:

vi /etc/raddb/mods-available/eap

При­во­дим к сле­ду­ю­ще­му виду опции:

* в дан­ном при­ме­ре ука­за­ны не самые луч­шие пара­мет­ры с точ­ки зре­ния без­опас­но­сти. Луч­ше все­го отка­зать­ся от TLS 1.0 и 1.1. — для это­го, как пра­ви­ло, необ­хо­ди­мо уста­но­вить обнов­ле­ния на кли­ент­ском устройстве.

Пере­за­гру­жа­ем freeradius:

systemctl restart radiusd

Freeradius

FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.

yum install freeradius freeradius-utils freeradius-ldap -y

Linux

Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.

Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.

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

Все подключение делается в одном окне. Выбираем нашу сеть:

anonymous — clientdomain — домен, на который выпущен сертификат

Non-samsung

C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:

domain — домен, на который выпущен сертификатanonymous — client

Prepare freeipa for aaa authentication

[root@ipa /]#yum install freeipa-server-trust-adipa-adtrust-instal

confirm all including SID release. Rezults show like below

Samsung

Как уже писал выше, Samsung-устройства не умеют использовать системные сертификаты при подключении WiFi, и у них нет возможности подключаться по домену. Поэтому надо вручную добавить корневой сертификат центра сертификации (ca.pem, берем на Radius сервере). Вот здесь будет использовать самоподписанный.

Скачиваем сертификат себе на устройство и устанавливаем его.

Когда сертификат установлен, можно переходить к подключению:

сертификат — указываем тот, который устанавливалианонимный пользователь — guest

Возможные вопросы

В:

как передавать профиль/сертификат сотруднику?

О: Все сертификаты/профили я храню на фтп с доступом через веб. Поднял гостевую сеть с ограничением по скорости и доступом только в интернет, за исключением фтп. Аутентификация держится 2 дня, после чего сбрасывается и клиент остается без интернета. Т.о. когда сотрудник хочет подключиться к WiFi, сначало он подключается к гостевой сети, заходит на фтп, скачивает нужный ему сертификат или профиль, устанавливает их, и после может подключаться к корпоративной сети.

В: почему не использовать схему с MSCHAPv2? она же более безопасная!

О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность

В: можно ли авторизовывать устройтсва по mac-адресам?

О: НЕТ, это не безопасно, злоумышленник может подменить мак-адреса, и тем более авторизация по мак-адресам не поддерживается на многих устройствах

В: зачем вообще все эти сертификаты использовать? можно же и без них подключаться

Возможные проблемы

Для диа­гно­сти­ки про­блем, удоб­нее все­го запус­кать freeradius в режи­ме деба­га. Для это­го сна­ча­ла оста­но­вим его:

systemctl stop radiusd

После запус­ка­ем ради­ус командой:

radiusd -X

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

systemctl start radiusd

Рас­смот­рим про­бле­му, с кото­рой столк­нул­ся я.

Как будет выполняться настройка

Для выпол­не­ния зада­чи по настрой­ке авто­ри­за­ции на WiFi через RADIUS сер­вер может исполь­зо­вать­ся мно­же­ство реше­ний. Какие-то из них более удоб­ные в настрой­ке, какие-то в экс­плу­а­та­ции. В дан­ной инструк­ции сде­лан упор на мак­си­маль­ное удоб­ство со сто­ро­ны пользователя.

Фрейм­ворк аутен­ти­фи­ка­ции EAP вклю­ча­ет в себя мно­же­ство про­то­ко­лов. Одним из самых попу­ляр­ных явля­ет­ся PEAP (EAP-TLS) — его под­держ­ка реа­ли­зо­ва­на в боль­шин­стве устройств.

Для рабо­ты с FreeIPA нам подой­дет MSCHAP, но для его исполь­зо­ва­ния потре­бу­ет­ся неболь­шое рас­ши­ре­ние схе­мы и добав­ле­ние поля хра­не­ния хэша паро­ля. Сер­вер RADIUS (в нашем слу­чае, Freeradius) будет его вытас­ки­вать и срав­ни­вать с хэшем вве­ден­но­го пароля.

Перей­дем к реа­ли­за­ции задуманного.

Контроллер ubiquiti

На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24Идем в настройки -> профиль. Cоздаем новый:

Прописываем адрес и порт radius-сервера и пароль, который прописывали в файле clients.conf:

Создаем новое имя беспроводной сети. В качестве метода аутентификации выбираем WPA-EAP (Enterprise) и указываем созданный radius-профиль:

Все сохраняем, применяем и идем дальше.

Настройка freeipa

На сто­роне сер­ве­ра LDAP нам необходимо:

1. Доба­вить атри­бут ipaNTHash для хра­не­ния в нем хэша пароля
2. Создать роли и при­ви­ле­гии для воз­мож­но­сти читать дан­ный атрибут.
3. Создать сер­вис­ный акка­унт и предо­ста­вить ему пра­ва на чте­ние атри­бу­та ipaNTHash.

В нашем при­ме­ре будет исполь­зо­вать­ся домен test.local.

Настройка атрибута ipanthash

Нач­нем с уста­нов­ки пакета:

yum install freeipa-server-trust-ad

Дан­ный пакет необ­хо­дим для запус­ка ути­ли­ты ipa-adtrust-install, с помо­щью кото­рой мы созда­ем атри­бут ipaNTHash:

ipa-adtrust-install –add-sids

Настройка клиентов

Начнем с самого сложного!

Настройка сервера radius

Уста­нав­ли­ва­ем допол­не­ние к Freeradius для рабо­ты с ldap:

yum install freeradius-ldap

Акти­ви­ру­ем уста­нов­лен­ный модуль:

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

Откры­ва­ем на редак­ти­ро­ва­ние файл ldap:

vi /etc/raddb/mods-available/ldap

Вне­сем неко­то­рые изме­не­ния в настрой­ки конфигурации:

Немного о методах eap

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

Из википедии:

EAP — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.
EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями называемыми методами EAP. Существует множество методов EAP, как определенных вместе с самим EAP, так и выпущенных отдельными производителями. EAP не определяет канальный уровень, он только определяет формат сообщений. Каждый протокол использующий EAP имеет собственный протокол инкапсуляции сообщений EAP. Сами методы:

• LEAP — проприетарный протокол, разработан CISCO. Найдены уязвимости. В настоящее время не рекомендуется использовать
• EAP-TLS — хорошо поддерживаемый среди вендоров беспроводных соединений. Является безопасным протоколом, поскольку является преемником SSL стандартов. Настройка клиентской достаточно сложна. Нужен клиентский сертификат помимо пароля. Поддерживается во многих системах
• EAP-TTLS — широко поддерживается во многих системах, предлагает хорошую безопасность, используя PKI сертификаты только на сервере аутентификации
• EAP-MD5 — другой открытый стандарт. Предлагает минимальную безопасность. Уязвим, не поддерживает взаимную аутентификацию и генерацию ключей
• EAP-IKEv2 — основан на Internet Key Exchange Protocol version 2. Обеспечивает взаимную аутентификацию и установление сеансового ключа между клиентом и сервером
• PEAP — совместное решение CISCO, Microsoft и RSA Security как открытый стандарт. Широко доступен в продуктах, обеспечивает очень хорошую безопасность. Схож с EAP-TTLS, требуя только сертификат на серверной стороне
• PEAPv0/EAP-MSCHAPv2 — после EAP-TLS, это второй широко используемый стандарт в мире. Используется клиент-серверная взаимосвязь в Microsoft, Cisco, Apple, Linux
• PEAPv1/EAP-GTC — создан Cisco как альтернатива PEAPv0/EAP-MSCHAPv2. Не защищает аутентификационные данные в любом случае. Не поддерживаются в Windows OS
• EAP-FAST — метод, разработанный Cisco для исправления недостатков LEAP. Использует Protected Access Credential (PAC). Полностью не доработан

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

Windows 10

, macOS, Linux,

AndroidiOS

) и, собственно, чем проще, тем лучше. Поэтому выбор пал на EAP-TTLS в связке с протоколом PAP.

Возможно возникнет вопрос — Зачем же использовать PAP? ведь он передает пароли в открытом виде?

Создание и настройка сервисной учетной записи

Созда­дим поль­зо­ва­те­ля, с помо­щью кото­ро­го Freeradius будет под­клю­чать­ся к FreeIPA и полу­чать доступ к атри­бу­ту ipaNTHash.

Вво­дим:

ipa service-add ‘freeradius/ipa-server.test.local’

* где freeradius — имя сер­вис­но­го акка­ун­та; ipa-server.test.local — FQDN-имя сер­ве­ра IPA.

Созда­ем keytab-файл:

ipa-getkeytab -p ‘freeradius/ipa-server.test.local’ -s ipa-server.test.local -k /root/radiusd.keytab

* в дан­ном при­ме­ре файл будет сохра­нен по пути /root/radiusd.keytab.

Про­ве­рим файл:

kinit -t /root/radiusd.keytab -k freeradius/ipa-server.test.local

klist

Мы долж­ны уви­деть что-то на подобие:

Так­же выпол­ним who a mi в LDAP:

ldapwhoami -Y GSSAPI

Ответ дол­жен быть на подобие:

* freeradius/ipa-server.test.local@test.local,cn=services,cn=accounts,dc=test,dc=local — пол­ный путь учет­ной запи­си в LDAP. Он нам пона­до­бить­ся для даль­ней­шей настройки.

Теперь зада­дим пароль для сер­вис­но­го акка­ун­та. Для это­го созда­ем ldif файл:

Настра­и­ва­ем модуль EAP:

vi /etc/raddb/mods-available/eap

Доста­точ­но вне­сти изме­не­ние в одной строке:

default_eap_type = mschapv2

Пере­за­пус­ка­ем сервис:

systemctl restart radiusd

Для про­вер­ки уста­нав­ли­ва­ем ути­ли­ту freeradius-utils:

yum install freeradius-utils

И вво­дим команду:

radtest -t mschap test test12345 localhost:1812 0 testing123

Создание ролей и привилегий

Нам необ­хо­ди­мо создать настрой­ки без­опас­но­сти для воз­мож­но­сти предо­ста­вить доступ к атри­бу­ту ipaNTHash. Раз­бе­рем­ся с этим по шагам.

1. Созда­ем разрешение: