WiFi Enterprise. FreeRadius + FreeIPA + Ubiquiti

Вече бяха описани някои примери за организация на корпоративен 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 версия 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. Последната може да се изтегли от https://freeradius.org/

След това 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 = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "CA FreeRadius"

Записваме същите стойности в файла server.cnf. Променяме само
commonName:

server.cnf

...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "Server Certificate FreeRadius"

Създаваме:

направи

Готово. Получените 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 — клиент
domain — домейн, на който е издаден сертификатът

Android

non-Samsung

От версия 7 при свързване с WiFi може да се използват системни сертификати, като се посочи само домейн:

domain — домейн, на който е издаден сертификатът
anonymous — клиент

Samsung

Както написах по-горе, устройствата на Samsung не могат да използват системни сертификати при свързване с WiFi и нямат възможност да се свържат по домейн. Затова е необходимо ръчно да добавим кореновия сертификат на удостоверяващия център (ca.pem, взимаме го на Radius сървъра). Тук ще се използва самооподписан.

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

Инсталиране на сертификата







При това, ще трябва да бъде зададено изображение за отключване на екрана, пин код или парола, ако все още не е зададена:

Показах сложния вариант за инсталиране на сертификата. На повечето устройства е достатъчно просто да кликнете на сваления сертификат.

Когато сертификатът е инсталиран, можем да преминем към свързването:

сертификат — посочваме този, който сме инсталирали
анонимен потребител — guest

macOS

Устройствата на Apple по подразбиране могат да се свързват само към EAP-TLS, но все пак е необходимо да им бъдат предоставяни сертификати. За да укажете друг метод на свързване, трябва да използвате Apple Configurator 2. Съответно, е необходимо предварително да го изтеглите на Mac, да създадете нов профил и да добавите всички необходими настройки на WiFi.

Apple Configurator



Тук посочваме името на нашата мрежа
Тип за сигурност — WPA2 Enterprise
Приети EAP типове — TTLS
Потребителско име и парола — оставяме празни
Вътрешна автентикация — PAP
Външна идентичност — client

Вкладка Trust. Тук посочваме нашия домейн

Всичко. Профилът може да бъде запазен, подписан и разпределен на устройства

След като профилът е готов, трябва да се изтегли на Mac и да се инсталира. По време на инсталацията ще трябва да се посочат usernmae_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-сървър и точка за достъп с име, съвпадащо с нашето, той може лесно да прихване потребителските данни (не забравяйте, че те се предават в нешифрован вид). А когато се използва сертификат, врагът ще види в логовете само нашите измислени потребителски имена — guest или client и грешка от типа — Unknown CA Certificate

още малко за macOSОбикновено на macOS преинсталирането на системата се прави чрез интернет. В режима на възстановяване макът трябва да бъде свързан към WiFi, и тук нито нашият корпоративен WiFi, нито гостоприемната мрежа ще сработят. Лично аз създадох още една мрежа, обикновена по WPA2-PSK, скрита, само за технически операции. Друг вариант е предварително да се направи загрузъчна USB флашка със системата. Но ако макът е след 2015 година, ще трябва да се намери адаптер за тази флашка).

Източник: habr.com