Ужо былі апісаны некаторыя прыклады арганізацыі карпаратыўнага 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, 29/30, Fedora XNUMX, XNUMX.
Для пачатку, спампоўваем сабе сертыфікат. Я не знайшоў у 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, канфігуратар
Тут паказваем імя сваёй сеткі
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