WiFi предприятие. 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. Използва идентификационни данни за защитен достъп (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. Последното може да се вземе https://freeradius.org/

След това FreeRadius вече работи. Можете да разкоментирате реда в /etc/raddb/users

steve   Cleartext-Password := "testing"

Стартирайте в сървъра в режим на отстраняване на грешки

freeradius -X

И направете тестова връзка от localhost

radtest steve testing 127.0.0.1 1812 testing123

Имам отговор Получен идентификатор за достъп-приемане 115 от 127.0.0.1:1812 до 127.0.0.1:56081 дължина 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}})"
}
...

Рестартирайте радиус сървъра и проверете синхронизацията на 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"
           }
}

Допълнително редактиране активиран от сайта/по подразбиране. Секциите за оторизиране и удостоверяване представляват интерес.

активиран от сайта/по подразбиране

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
}

В раздела за оторизиране премахваме всички модули, които не са ни необходими. Оставяме само ldap. Добавяне на клиентска проверка чрез потребителско име. Ето защо добавихме два екземпляра на eap по-горе.

Мулти EAPФакт е, че когато свързваме някои устройства, ще използваме системни сертификати и ще посочим домейна. Имаме сертификат и ключ от доверен сертифициращ орган. Лично според мен подобна процедура за свързване е по-лесна от хвърлянето на самоподписан сертификат на всяко устройство. Но дори и без самоподписани сертификати, пак не се получи. Устройствата на Samsung и Android =< 6 версии не могат да използват системни сертификати. Затова създаваме отделен екземпляр на eap-guest за тях със самоподписани сертификати. За всички други устройства ще използваме eap-клиента с доверен сертификат. Потребителското име се определя от полето Anonymous, когато устройството е свързано. Разрешени са само 3 стойности: Гост, Клиент и празно поле. Всичко останало се изхвърля. Ще бъде конфигуриран в политици. Ще дам пример малко по-късно.

Нека редактираме секциите за оторизиране и удостоверяване в сайт-активиран/вътрешен тунел

сайт-активиран/вътрешен тунел

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
}

След това трябва да посочите в правилата кои имена могат да се използват за анонимно влизане. Редактиране политика.d/филтър.

Трябва да намерите редове, подобни на този:

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"

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

сървър.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

Готов. получено сървър.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
Отидете на настройки -> профил. Създаваме нов:

Пишем адреса и порта на радиус сървъра и паролата, която е записана във файла clients.conf:

Създайте ново име на безжична мрежа. Изберете WPA-EAP (Enterprise) като метод за удостоверяване и посочете създадения радиус профил:

Запазваме всичко, прилагаме и продължаваме напред.

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

Да започнем с най-трудното!

Windows 10

Трудността се свежда до факта, че Windows все още не знае как да се свърже с корпоративния WiFi чрез домейн. Следователно трябва ръчно да качим нашия сертификат в довереното хранилище за сертификати. Тук можете да използвате както собствено подписване, така и от сертифициращия орган. Ще използвам втория.

След това трябва да създадете нова връзка. За да направите това, отидете на настройките за мрежа и интернет -> Център за мрежи и споделяне -> Създайте и конфигурирайте нова връзка или мрежа:

Въведете ръчно името на мрежата и променете типа защита. След като щракнем върху променете настройките за връзка и в раздела Защита изберете удостоверяване на мрежата - EAP-TTLS.

Влизаме в параметрите, предписваме поверителността на удостоверяването - клиент. Като доверен сертифициращ орган изберете сертификата, който добавихме, поставете отметка в квадратчето „Не издавай покана на потребителя, ако сървърът не може да бъде упълномощен“ и изберете метода за удостоверяване – некриптирана парола (PAP).

След това отидете на разширените настройки, поставете отметка на „Посочете режима на удостоверяване“. Изберете „User Authentication“ и щракнете върху запишете идентификационни данни. Тук ще трябва да въведете username_ldap и password_ldap

Запазваме всичко, прилагаме, затваряме. Можете да се свържете с нова мрежа.

Linux

Тествах на Ubuntu 18.04, 18.10, Fedora 29, 30.

Първо, нека изтеглим нашия сертификат. Не открих в Линукс дали е възможно да се използват системни сертификати и дали изобщо има такъв магазин.

Нека се свържем с домейна. Затова се нуждаем от сертификат от сертифициращия орган, от който е закупен сертификатът ни.

Всички връзки се правят в един прозорец. Избор на нашата мрежа:

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

Android

не-Samsung

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

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

Samsung

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

Изтеглете сертификата на вашето устройство и го инсталирайте.

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







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

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

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

сертификат - посочете този, който е инсталиран
анонимен потребител - гост

macOS

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

Apple Configurator



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

Раздел Доверие. Тук посочваме нашия домейн

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

След като профилът е готов, трябва да го изтеглите в мака и да го инсталирате. По време на инсталационния процес ще трябва да посочите usernmae_ldap и password_ldap на потребителя:

IOS

Процесът е подобен на macOS. Трябва да използвате профил (можете да използвате същия като за macOS. Как да създадете профил в Apple Configurator, вижте по-горе).

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

Това е всичко. Настроихме Radius сървър, синхронизирахме го с FreeIPA и казахме на AP на Ubiquiti да използват WPA2-EAP.

Възможни въпроси

AT: как да прехвърля профил/сертификат на служител?

ОТНОСНО: Съхранявам всички сертификати/профили на ftp с уеб достъп. Вдигна мрежа за гости с ограничение на скоростта и достъп само до интернет, с изключение на ftp.
Автентификацията продължава 2 дни, след което се нулира и клиентът остава без интернет. Че. когато служител иска да се свърже с WiFi, той първо се свързва с мрежата за гости, осъществява достъп до FTP, изтегля необходимия сертификат или профил, инсталира го и след това може да се свърже с корпоративната мрежа.

AT: защо не използвате схема с MSCHAPv2? Тя е по-безопасна!

ОТНОСНО: Първо, такава схема работи добре на NPS (Windows Network Policy System), в нашата реализация е необходимо допълнително да конфигурирате LDAP (FreeIpa) и да съхранявате хешовете на паролите на сървъра. Добавете. не е препоръчително да правите настройки, т.к. това може да доведе до различни проблеми при синхронизирането на ултразвука. Второ, хешът е MD4, така че не добавя много сигурност.

AT: възможно ли е да се оторизират устройства чрез mac-адреси?

ОТНОСНО: НЕ, това не е безопасно, нападателят може да промени MAC адресите и още повече, че упълномощаването чрез MAC адреси не се поддържа на много устройства

AT: за какво изобщо всички тези сертификати да се използват? можеш ли да се включиш без тях?

ОТНОСНО: сертификатите се използват за оторизиране на сървъра. Тези. при свързване устройството проверява дали е сървър, на който може да се вярва или не. Ако е, тогава удостоверяването продължава, ако не, връзката се затваря. Можете да се свържете без сертификати, но ако нападател или съсед настрои радиус сървър и точка за достъп със същото име като нашето у дома, той може лесно да прихване идентификационните данни на потребителя (не забравяйте, че те се предават в чист текст). И когато се използва сертификат, врагът ще види в своите логове само нашето измислено потребителско име - гост или клиент и грешка при типа - Неизвестен CA сертификат

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

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