Вже описано деякі приклади організації корпоративного WiFi. Тут я розпишу як реалізував подібне рішення та проблеми з якими довелося зіткнутися при підключенні на різних пристроях. Будемо використовувати вже наявну LDAP із заведеними користувачами, піднімемо FreeRadius і налаштуємо WPA2-Enterprise на контролері Ubnt. Начебто все просто. Подивимося…
Небагато про методи 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, Android, iOS) і, власне, що простіше, то краще. Тому вибір ліг на EAP-TTLS у зв'язці з протоколом PAP.
Можливо виникне питання - Навіщо використовувати PAP? адже він передає паролі у відкритому вигляді?
Так все вірно. Спілкування між FreeRadius та FreeIPA буде проходити саме так. У режимі дебагу можна відстежити як надсилаються username і password. Та й нехай відправляються, тільки у вас є доступ до сервера FreeRadius.
Докладніше про роботу EAP-TTLS можна прочитати
FreeRADIUS
FreeRadius підніматимемо на CentOS 7.6. Тут нічого складного, ставимо звичайним способом.
yum install freeradius freeradius-utils freeradius-ldap -yІз пакетів ставиться версія 3.0.13. Останню можна взяти на
Після цього FreeRadius працює. Можна в /etc/raddb/users розкоментувати рядок
steve Cleartext-Password := "testing"Запустити на сервер у режимі дебагу
freeradius -XІ робимо тестове підключення із localhost
radtest steve testing 127.0.0.1 1812 testing123Отримали відповідь Received Access-Accept Id 115 від 127.0.0.1:1812 to 127.0.0.1:56081 length 20, значить все добре. Йдемо далі.
Підключаємо модуль ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapІ одразу його змінимо. Нам потрібно, щоб FreeRadius міг звертатися до FreeIPA
mods-enabled/ldap
ldap {
server="ldap://ldap.server.com"
port=636
start_tls=yes
identity="uid=admin,cn=users,dc=server,dc=com"
password=**********
base_dn="cn=users,dc=server,dc=com"
set_auth_type=yes
...
user {
base_dn="${..base_dn}"
filter="(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
}
...Перезапускаємо radius-сервер і перевіряємо синхронізацію користувачів LDAP:
radtest user_ldap password_ldap localhost 1812 testing123
Редагуємо eap в mods-enabled/eap
Тут додамо два екземпляри eap. Вони відрізнятимуться лише сертифікатами та ключами. Трохи нижче поясню, чому саме так
mods-enabled/eap
eap eap-client { default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_file = ${certdir}/fisrt.key
certificate_file = ${certdir}/first.crt
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}
eap eap-guest {
default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_passwotd=blablabla
private_key_file = ${certdir}/server.key
certificate_file = ${certdir}/server.crt
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}Далі редагуємо site-enabled/default. Цікавлять розділи authorize та authenticate.
site-enabled/default
authorize {
filter_username
preprocess
if (&User-Name == "guest") {
eap-guest {
ok = return
}
}
elsif (&User-Name == "client") {
eap-client {
ok = return
}
}
else {
eap-guest {
ok = return
}
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
logintime
pap
}
authenticate {
Auth-Type LDAP {
ldap
}
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
pap
}У секції authorize прибираємо всі модулі, які нам не потрібні. Залишаємо тільки ldap. Додаємо перевірку клієнта за username. Саме для цього ми додавали вище два екземпляри eap.
Multi EAPСправа в тому, що підключаючи деякі пристрої, ми будемо використовувати системні сертифікати і вказувати домен. У нас є сертифікат та ключ від довіреного центру сертифікації. Особисто на мою думку така процедура підключення простіша, ніж кидати на кожен пристрій самопідписаний сертифікат. Але й без самопідписаних сертифікатів все ж таки не вдалося піти. Samsung девайси та Android =< 6 версії не вміють використовувати системні сертифікати. Тому для них створюємо окремий екземпляр eap-guest із самопідписаними сертифікатами. Для інших пристроїв будемо використовувати eap-client з довіреним сертифікатом. User-Name визначається за полем Anonymous при підключенні пристрою. Дозволено використовувати лише 3 значення: Guest, Client та порожнє поле. Решта все відкидається. Це налаштовується у політиках. Приклад наведу трохи згодом
Відредагуємо секції authorize та authenticate у site-enabled/inner-tunnel
site-enabled/inner-tunnel
authorize {
filter_username
filter_inner_identity
update control {
&Proxy-To-Realm := LOCAL
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
digest
logintime
pap
}
authenticate {
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
Auth-Type PAP {
pap
}
ldap
}Далі слід прописати в політиках, які імена можна використовувати для анонімного входу. Редагуємо policy.d/filter.
Потрібно знайти рядки схожі на це:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}І нижче в elsif додати потрібні значення:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Тепер нам потрібно переміститися до директорії сертифікати. Сюди потрібно покласти ключ та сертифікат від довіреного центру сертифікації, який ми вже маємо і потрібно згенерувати самопідписані сертифікати для eap-guest.
Змінюємо параметри у файлі ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "CA FreeRadius"Такі ж значення прописуємо у файлі server.cnf. Змінюємо тільки
звичайне ім'я:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "Server Certificate FreeRadius"Створюємо:
makeГотово. Отримані server.crt и server.key у нас вже написано вище в eap-guest.
І останнє, додамо наші точки доступу до файлу client.conf. У мене їх 7. Щоб не додавати кожну точку окремо, пропишемо тільки мережу в яку вони знаходяться (у мене точки доступу знаходяться в окремому VLAN).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Контролер Ubiquiti
На контролері піднімаємо окрему мережу. Нехай буде 192.168.2.0/24
Йдемо в налаштування -> профіль. Створюємо новий:
Прописуємо адресу та порт radius-сервера та пароль, який прописували у файлі clients.conf:
Створюємо нове ім'я бездротової мережі. Як метод аутентифікації вибираємо WPA-EAP (Enterprise) і вказуємо створений radius-профіль:
Все зберігаємо, застосовуємо та йдемо далі.
Налаштування клієнтів
Почнемо із найскладнішого!
Windows 10
Складність зводиться до того, що Windows ще не вміє підключатися до корпоративного WiFi по домену. Тому доводиться вручну закидати наш сертифікат у сховище довірених сертифікатів. Тут можна використовувати як самопідписаний, так і від центру сертифікації. Я використовуватиму другий.
Далі слід створити нове підключення. Для цього йдемо в параметри мережі та Інтернет -> Центр управління мережами та загальним доступом -> Створення та налаштування нового підключення або мережі:
Вручну прописуємо ім'я мережі та змінюємо тип безпеки. Після натискаємо на змінити параметри підключення і у володінні Безпека вибираємо автентифікацію мережі - EAP-TTLS.
Заходимо до параметрів, прописуємо конфіденційність аутентифікації. клієнт. Як довірений центр сертифікації вибираємо доданий нами сертифікат, ставимо галочку "Не видавати користувачеві запрошення, якщо не вдається авторизувати сервер" і метод автентифікації вибираємо - незашифрований пароль (PAP).
Далі заходимо у додаткові параметри, ставимо галочку на "Вкажіть режим автентифікації". Вибираємо пункт «Перевірка справжності користувача» та натискаємо на зберегти облікові дані. Тут потрібно буде ввести username_ldap та password_ldap
Все зберігаємо, застосовуємо, закриваємо. Можна підключатися до нової мережі.
Linux
Я перевіряв на Ubuntu 18.04, 18.10, Fedora 29, 30.
Для початку скачуємо собі сертифікат. Я не знайшов у Linux, чи є можливість використовувати системні сертифікати і чи є там взагалі таке сховище.
Підключатимемося по домену. Тому потрібен сертифікат центру, що посвідчує, у якого був придбаний наш сертифікат.
Все підключення робиться в одному вікні. Вибираємо нашу мережу:
anonymous - client
domain — домен, на який випущено сертифікат
Android
non-Samsung
C 7 версії при підключенні WiFi можна використовувати системні сертифікати, вказавши лише домен:
domain — домен, на який випущено сертифікат
anonymous - client
Samsung
Як уже писав вище, Samsung-пристрої не вміють використовувати системні сертифікати при підключенні WiFi, і вони не мають можливості підключатися по домену. Тому треба вручну додати кореневий сертифікат центру сертифікації (ca.pem, беремо на сервері Radius). Ось тут використовуватиме самопідписаний.
Завантажуємо сертифікат собі на пристрій та встановлюємо його.
Встановлення сертифіката
При цьому потрібно буде встановити малюнок розблокування екрану, пін-код або пароль, якщо він ще не встановлений:
Я показав складний варіант встановлення сертифіката. На більшості пристроїв досить просто натиснути на сертифікат.
Коли сертифікат встановлено, можна перейти до підключення:
сертифікат - вказуємо той, який встановлювали
анонімний користувач - guest
MacOS
Яблучні пристрої з коробки можуть підключатися тільки до EAP-TLS, але все одно потрібно закидати сертифікат. Щоб вказати інший метод підключення, потрібно скористатися Apple Configurator 2. Відповідно потрібно заздалегідь завантажити його на мак, створити новий профіль та додати всі необхідні налаштування WiFi.
Apple Configurator
Тут вказуємо ім'я своєї мережі
Security Type - WPA2 Enterprise
Accepted EAP Types - TTLS
User Name і Password - залишаємо порожніми
Inner Authentication - PAP
Outer Identity - client
Вкладка Trust. Тут вказуємо наш домен
Всі. Профіль можна зберігати, підписувати та розповсюджувати на пристрої
Після того, як профіль готовий, його потрібно завантажити на мак та встановити. У процесі встановлення потрібно буде вказати usernmae_ldap та password_ldap користувача:
iOS
Процес аналогічний до macOS. Потрібно використовувати профіль (можна прямий такий як для macOS. Як створювати профіль у Apple Configurator, дивитися вище).
Завантажуємо профіль, встановлюємо, вводимо облікові дані, підключаємось:
На цьому все. Ми налаштували сервер Radius, синхронізували його з FreeIPA і вказали точкам доступу Ubiquiti використовувати WPA2-EAP.
Можливі питання
В: як передавати профіль/сертифікат співробітнику?
Про: Усі сертифікати/профілі я зберігаю на фтп з доступом через Інтернет. Підняв гостьову мережу з обмеженням за швидкістю та доступом тільки в інтернет, за винятком фтп.
Аутентифікація триває 2 дні, після чого скидається і клієнт залишається без інтернету. Т.о. коли співробітник хоче підключитися до WiFi, спочатку він підключається до гостьової мережі, заходить на фтп, завантажує потрібний сертифікат або профіль, встановлює їх, і потім може підключатися до корпоративної мережі.
В: чому не використовувати схему з MSCHAPv2? вона ж безпечніша!
Про: по-перше, така схема добре працює на NPS (Windows Network Policy System), у нашій реалізації необхідно додатково налаштовувати LDAP (FreeIpa) та зберігати хеші паролів на сервері. Дод. налаштування робити не бажано, т.к. це може призвести до різних проблем сихронізації УЗ. По-друге, хеш є MD4, так що це не особливо підвищує безпеку
В: Чи можна авторизувати пристрої за mac-адресами?
Про: НІ, це не безпечно, зловмисник може підмінити мак-адреси, і тим більше авторизація за мак-адресами не підтримується на багатьох пристроях
В: навіщо взагалі всі ці сертифікати використати? можна ж і без них підключатися
Про: Сертифікати використовуються для авторизації сервера. Тобто. пристрій при підключенні перевіряє той сервер, якому можна довіряти чи ні. Якщо той, то аутентифікація відбувається далі, якщо ні, з'єднання закривається. Можна підключатися без сертифікатів, але якщо зловмисник або сусід підніме у себе вдома radius-сервер і точку доступу з таким самим ім'ям, як у нас, він зможе легко перехопити облікові дані користувача (не забуваємо, що вони передаються у відкритому вигляді). А коли використовується сертифікат, ворог побачить у себе в логах тільки наші вигадані User-Name – guest або client та помилку типу – Unknown CA Certificate
ще трохи про macOSЗазвичай на macOS перевстановлення системи здійснюється через Інтернет. У режимі відновлення мак треба підключити до WiFi, і тут не спрацює наш корпоративний WiFi, ні гостьова мережа. Особисто я підняв ще одну мережу, звичайну WPA2-PSK, приховану, тільки для технічних операцій. Або ще можна заздалегідь зробити завантажувальну флешку із системою. Але якщо мак після 2015 року, треба буде ще знайде адаптер для цієї флешки)
Джерело: habr.com