Вече бяха описани някои примери за организация на корпоративен 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 — базиран на протокола за обмен на ключове в интернет версия 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 ще става именно така. В режим на отстраняване на грешки можете да проследите как се изпращат потребителското име и паролата. И нека се изпращат, стига да имате достъп до сървъра 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 from 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
}Сега трябва да се преместим в директорията certs. Тук трябва да сложим ключа и сертификата от доверения сертификационен център, който вече имаме и трябва да генерираме самоподписани сертификати за eap-guest.
Променяме параметрите във файла ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = BG
stateOrProvinceNmae = Област
localityNmae = Град
organizationName = NONAME
emailAddress = admin@admin.bg
commonName = "CA FreeRadius"Същите стойности вписваме във файла server.cnf. Променяме само
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = BG
stateOrProvinceNmae = Област
localityNmae = Град
organizationName = NONAME
emailAddress = admin@admin.bg
commonName = "Сертификат на сървъра FreeRadius"Създаваме:
, затова потребителите на Windows трябва да инсталират Cygwin или да се справят сами с Visual Studio и библиотеките.Готово. Получените 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.
Влизаме в параметрите, записваме конфиденциалността на аутентификацията — client. Като доверен сертификационен център избираме добавения от нас сертификат, поставяме отметка „Не изисквай от потребителя покана, ако не може да се удостоверява сървъра“ и метода за проверка на автентичността избираме — нешифрован пароль (PAP).
Следва да отидем в допълнителните параметри и да поставим галочка на „Укажете режима на удостоверяване“. Избираме опцията „Удостоверяване на потребителя“ и натискаме на запазване на данните за идентификация. Тук трябва да въведем username_ldap и password_ldap
Всичко запазваме, прилагаме и затваряме. Можем да се свържем с новата мрежа.
Linux
Тествах на Ubuntu 18.04, 18.10, Fedora 29, 30.
Първо, сваляме сертификата. Не намерих в Linux, дали има възможност да се използват системните сертификати и дали изобщо съществува такова хранилище.
Ще се свързваме по домейна. Затова е нужен сертификат от удостоверяващия център, от който е закупен нашият сертификат.
Цялото свързване се извършва в един прозорец. Избираме нашата мрежа:
anonymous — client
domain — домейн, на който е издаден сертификатът
Android
non-Samsung
От версия 7 нататък, при свързването с WiFi може да се използват системните сертификати, като просто посочите домейна:
domain — домейн, на който е издаден сертификатът
anonymous — client
Samsung
Както казах по-горе, устройствата на Samsung не могат да използват системни сертификати при свързване с WiFi и нямат възможност да се свързват по домейна. Затова трябва ръчно да добавим кореновия сертификат на удостоверяващия център (ca.pem, вземаме от Radius сървъра). Тук ще използваме самоподписания.
Сваляме сертификата на устройството си и го инсталираме.
Инсталация на сертификата
При това трябва да бъде установлен рисунък за отключване на екрана, ПИН код или парола, ако вече не е установен:
Показах сложен вариант за инсталация на сертификата. На повечето устройства е необходимо просто да натиснете на сваления сертификат.
След като сертификатът е инсталиран, можем да преминем към свързването:
сертификат — посочваме този, който инсталирахме
анонимен потребител — guest
macOS
Устройствата на Apple от фабриката могат да се свързват само към EAP-TLS, но все пак е необходимо да им се предостави сертификат. За да зададете друг метод на свързване, трябва да използвате Apple Configurator 2. Съответно, преди това трябва да го свалите на Mac, да създадете нов профил и да добавите всичките необходими настройки за WiFi.
Apple Configurator
Тук посочваме името на нашата мрежа
Security Type — WPA2 Enterprise
Accepted EAP Types — TTLS
User Name и Password — оставяме празни
Inner Authentication — PAP
Outer Identity — client
В раздела Trust. Тук посочваме нашия домейн
Всичко. Профилът може да бъде запазен, подписан и разпространен на устройствата.
След като профилът е готов, трябва да се изтегли на Mac и да се инсталира. По време на инсталацията ще трябва да се въведе username_ldap и password_ldap на потребителя:
iOS
Процесът е аналогичен на macOS. Трябва да се използва профил (може да бъде същият като за macOS. Как да се създаде профил в Apple Configurator, вижте по-горе).
Изтегляме профила, инсталираме, въвеждаме данните за вход, свързваме се:
С това приключваме. Конфигурирахме Radius сървър, синхронизирахме го с FreeIPA и указахме на достъпните точки Ubiquiti да използват WPA2-EAP.
Възможни въпроси
В: как да предам профил/сертификат на служителя?
О: Всички сертификати/профили съхранявам на FTP с достъп през уеб. Създадох гостна мрежа с ограничение на скоростта и достъп само до интернет, с изключение на FTP.
Аутентификацията трае 2 дни, след което се нулира и клиентът остава без интернет. Тоест, когато служителят иска да се свърже с WiFi, първо се свързва с гостната мрежа, влиза в FTP, изтегля нужния сертификат или профил, инсталира ги и след това може да се свърже с корпоративната мрежа.
В: защо да не използваме схемата с MSCHAPv2? тя е по-безопасна!
О: На първо място, същата схема работи добре на NPS (Windows Network Policy System), в нашата реализация е необходимо допълнително конфигуриране на LDAP (FreeIpa) и съхраняване на хешове на паролите на сървъра. Допълнителните настройки не са желателни, тъй като могат да доведат до различни проблеми със синхронизацията. На второ място, хешът представлява MD4, така че това не увеличава особено безопасността.
В: може ли да се удостоверяват устройства по MAC адреси?
О: НЕ, това не е безопасно, злоумышленик може да подмени MAC адресите, и освен това удостоверяването по MAC адреси не се поддържа на много устройства.
В: защо изобщо да се използват всички тези сертификати? може и без тях да се свързва.
О: Сертификатите се използват, за да удостоверят сървъра. Т.е. устройството при свързване проверява дали това е сървър, на който може да се доверява. Ако е, удостоверяването продължава, ако не, връзката се затваря. Може да се свързвате и без сертификати, но ако злонамерен човек или съсед настрои у дома си radius-сървър и точка за достъп с име, съвпадащо с нашето, той лесно може да прихване потребителските данни (не забравяйте, че те се предават в открит вид). А когато се използва сертификат, врагът ще види в логовете си само нашите измислени User-Name — guest или client и грешка от типа — Unknown CA Certificate.
още малко за macOSОбикновено на macOS преинсталацията на системата се прави чрез интернет. В режим на възстановяване, макът трябва да бъде свързан към WiFi, и тук няма да заработи нито нашият корпоративен WiFi, нито гостовата мрежа. Лично аз създадох още една мрежа, обикновена по WPA2-PSK, скрита, само за технически операции. Или може предварително да се направи зареждаща флашка със системата. Но ако макът е след 2015 година, ще трябва да се намери и адаптер за тази флашка).
Източник: habr.com
