Au fost deja descrise câteva exemple de organizare a WiFi-ului corporativ. Aici voi detalia cum am realizat o astfel de soluție și problemele întâmpinate la conectarea pe diferite dispozitive. Vom folosi LDAP-ul existent cu utilizatorii înregistrați, vom configura FreeRadius și vom seta WPA2-Enterprise pe controllerul Ubnt. Pare simplu. Să vedem...
Puțin despre metodele EAP
Înainte de a începe de la sarcină, trebuie să ne stabilim metoda de autentificare pe care o vom folosi în soluția noastră.
Din Wikipedia:
EAP este un cadru de autentificare care este adesea folosit în rețelele wireless și în conexiunile punct-la-punct. Formatul a fost descris pentru prima dată în RFC 3748 și actualizat în RFC 5247.
EAP este folosit pentru a selecta metoda de autentificare, pentru transferul cheilor și pentru procesarea acestor chei prin modulele conectabile numite metode EAP. Există multe metode EAP, atât definite împreună cu EAP-ul, cât și emise de diferiți producători. EAP nu definește nivelul canalului, ci doar formatul mesajelor. Fiecare protocol care utilizează EAP are propriul protocol de încapsulare a mesajelor EAP.
Metodele în sine:
- LEAP este un protocol proprietar, dezvoltat de CISCO. Au fost găsite vulnerabilități. Actualmente, nu se recomandă utilizarea lui.
- EAP-TLS este bine suportat de furnizorii de conexiuni wireless. Este un protocol sigur, întrucât este succesorul standardelor SSL. Configurarea clientului este destul de complicată. Este necesar un certificat de client pe lângă parolă. Este suportat în multe sisteme.
- EAP-TTLS este larg suportat de multe sisteme, oferind o bună securitate, utilizând certificate PKI doar pe serverul de autentificare.
- EAP-MD5 este un alt standard deschis. Oferă o securitate minimă. Este vulnerabil, nu suportă autentificarea reciprocă și generarea cheilor.
- EAP-IKEv2 se bazează pe Internet Key Exchange Protocol versiunea 2. Oferă autentificare reciprocă și stabilirea unei chei de sesiune între client și server.
- PEAP este o soluție comună dezvoltată de CISCO, Microsoft și RSA Security ca standard deschis. Este accesibil pe scară largă în produse și oferă o securitate foarte bună. Este similar cu EAP-TTLS, necesitând doar un certificat pe partea serverului.
- PEAPv0/EAP-MSCHAPv2 — după EAP-TLS, acesta este al doilea standard utilizat pe scară largă în lume. Se folosește relația client-server în Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC — creat de Cisco ca alternativă la PEAPv0/EAP-MSCHAPv2. Nu protejează datele de autentificare în niciun caz. Nu sunt suportate în Windows OS
- EAP-FAST — metodă dezvoltată de Cisco pentru a corecta deficiențele LEAP. Utilizează Credentiala de Acces Protejată (PAC). Nu este complet dezvoltată
Din toată această diversitate, alegerea nu este totuși foarte mare. De la metoda de autentificare se cerea: securitate bună, suport pe toate dispozitivele (Windows 10, macOS, Linux, Android, iOS) și, de fapt, cu cât mai simplu, cu atât mai bine. Așadar, alegerea a fost EAP-TTLS în combinație cu protocolul PAP.
Poate apărea întrebarea — De ce să folosești PAP? deoarece transmite parolele în clar?
Da, este corect. Comunicarea între FreeRadius și FreeIPA va avea loc exact așa. În modul de depanare poți urmări cum sunt trimise username și password. Și să fie trimise, doar că tu ai acces la serverul FreeRadius.
Mai multe despre funcționarea EAP-TTLS poți citi
FreeRADIUS
Vom instala FreeRadius pe CentOS 7.6. Aici nu este nimic complicat, îl instalăm în mod obișnuit.
yum install freeradius freeradius-utils freeradius-ldap -yDin pachete se instalează versiunea 3.0.13. Ultima poate fi găsită pe
După aceasta, FreeRadius este deja funcțional. Poți decommenta linia în /etc/raddb/users
steve Cleartext-Password := "testing"Pornește serverul în modul de depanare
freeradius -XȘi facem o conexiune de testare de pe localhost
radtest steve testing 127.0.0.1 1812 testing123Am primit răspunsul Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, deci totul este în regulă. Continuăm.
Conectăm modulul ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapȘi imediat îl modificăm. Trebuie să facem astfel încât FreeRadius să poată accesa 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}})"
}
...Repornim serverul radius și verificăm sincronizarea utilizatorilor LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Edităm eap în mods-enabled/eap
Aici vom adăuga două instanțe eap. Acestea vor diferi doar prin certificate și chei. Mai jos voi explica de ce exact așa
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"
}
}Apoi edităm site-enabled/default. Ne interesează sectoarele authorize și 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
}În secțiunea authorize eliminăm toate modulele de care nu avem nevoie. Lăsăm doar ldap. Adăugăm o verificare a clientului pe baza numelui de utilizator. Exact pentru aceasta am adăugat anterior două instanțe de eap.
Multi EAPProblema este că, conectând anumite dispozitive, vom folosi certificatele de sistem și vom indica domeniul. Avem un certificat și o cheie de la un centru de certificare de încredere. Personal, cred că această procedură de conectare este mai simplă decât să trimitem pe fiecare dispozitiv un certificat auto-semnat. Dar nu am reușit să scăpăm de certificatele auto-semante. Dispozitivele Samsung și Android < 6 versiuni nu știu să folosească certificatele de sistem. De aceea, creăm o instanță separată de eap-guest cu certificate auto-semante pentru acestea. Pentru toate celelalte dispozitive, vom folosi eap-client cu certificat de încredere. User-Name este determinat în funcție de câmpul Anonymous la conectarea dispozitivului. Se permit doar 3 valori: Guest, Client și câmpul gol. Restul sunt respinse. Acest lucru se configurează în politici. Voi oferi un exemplu mai târziu.
Vom edita secțiunile authorize și authenticate în 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
}Apoi trebuie să specificăm în politici ce nume pot fi folosite pentru conectarea anonimă. Edităm policy.d/filter.
Trebuie să găsim linii care arată așa:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name nu este anonimizat"
}
reject
}Și mai jos, în elsif, adăugăm valorile necesare:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name nu este anonimizat"
}
reject
}Acum trebuie să ne mutăm în directorul certs. Aici trebuie să plasăm cheia și certificatul de la centrul de certificare de încredere pe care îl avem și să generăm certificate auto-semante pentru eap-guest.
Modificăm parametrii în fișierul ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RO
stateOrProvinceNmae = Județ
localityNmae = Oraș
organizationName = NONAME
emailAddress = admin@admin.ro
commonName = "CA FreeRadius"Asemenea valori le introducem în fișierul server.cnf. Modificăm doar
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RO
stateOrProvinceNmae = Județ
localityNmae = Oraș
organizationName = NONAME
emailAddress = admin@admin.ro
commonName = "Server Certificate FreeRadius"Creăm:
makeGata. Am obținut server.crt și server.key pe care le-am menționat deja mai sus în eap-guest.
Și în final, să adăugăm punctele noastre de acces în fișierul client.conf. Am 7. Pentru a nu adăuga fiecare punct individual, vom scrie doar rețeaua în care se află (punctele mele de acces sunt într-un VLAN separat).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Controller Ubiquiti
Pe controller, creăm o rețea separată. Să fie 192.168.2.0/24
Mergem la setări -> profil. Creăm unul nou:
Introducem adresa și portul serverului radius și parola pe care am scris-o în fișierul clients.conf:
Creăm un nou nume pentru rețeaua wireless. Ca metodă de autentificare, alegem WPA-EAP (Enterprise) și indicăm profilul radius creat:
Salvăm tot, aplicăm și mergem mai departe.
Configurarea clienților
Să începem cu cea mai complicată parte!
Windows 10
Complicația provine din faptul că Windows încă nu poate să se conecteze la WiFi-ul corporativ prin domeniu. Prin urmare, trebuie să aducem manual certificatul nostru în magazinul de certificare de încredere. Se poate folosi atât un certificat auto-semnat, cât și de la o autoritate de certificare. Eu voi folosi cel de-al doilea.
Apoi, trebuie să creăm o nouă conexiune. Pentru aceasta mergem la setările rețelei și Internet -> Centrul de control al rețelelor și partajării -> Crearea și configurarea unei noi conexiuni sau rețele:
Introducem manual numele rețelei și schimbăm tipul de securitate. Apoi facem clic pe modifică setările de conexiune și în tab-ul Securitate alegem autentificarea rețelei — EAP-TTLS.
Intrăm în setări, introducem confidențialitatea autentificării — client. Ca certificat de autoritate de certificare de încredere, alegem certificatul pe care l-am adăugat, bifăm opțiunea „Nu solicita utilizatorului o invitație dacă nu se poate autoriza serverul” și metoda de autentificare aleasă este — parola necriptată (PAP).
Apoi, mergem la opțiunile suplimentare, bifăm „Specificați modul de autentificare”. Selectăm „Autentificarea utilizatorului” și apăsăm pe salvează acreditivele. Aici va trebui să introducem username_ldap și password_ldap
Totul se salvează, aplicăm, închidem. Putem să ne conectăm la noua rețea.
Linux
Am verificat pe Ubuntu 18.04, 18.10, Fedora 29, 30.
Mai întâi, descărcăm certificatul. Nu am găsit în Linux dacă există posibilitatea de a folosi certificatele sistemului și dacă există în general un astfel de depozit.
Ne vom conecta pe domeniu. Prin urmare, este necesar un certificat de la autoritatea de certificare care a emis certificatul nostru.
Întreaga conexiune se realizează într-o singură fereastră. Alegem rețeaua noastră:
anonymous — client
domain — domeniul pentru care a fost emis certificatul
Android
non-Samsung
Din versiunea 7, la conectarea WiFi se pot folosi certificatele sistemului, specificând doar domeniul:
domain — domeniul pentru care a fost emis certificatul
anonymous — client
Samsung
Așa cum am menționat mai sus, dispozitivele Samsung nu pot folosi certificatele sistemului la conectarea WiFi și nu au opțiunea de a se conecta pe domeniu. Prin urmare, este necesar să adăugăm manual certificatul rădăcină al autorității de certificare (ca.pem, obținut de pe serverul Radius). Aici se va folosi un certificat auto-semnat.
Descărcăm certificatul pe dispozitivul nostru și îl instalăm.
Instalarea certificatului
În acest proces, va fi necesar să setăm o imagine de deblocare a ecranului, un cod PIN sau o parolă, dacă nu a fost deja setată:
Am ilustrat varianta complexă de instalare a certificatului. Pe majoritatea dispozitivelor, este suficient să apăsați pe certificatul descărcat.
Când certificatul este instalat, putem trece la conectare:
certificatul — specificăm cel pe care l-am instalat
utilizator anonim — guest
macOS
Dispozitivele Apple din fabrică se pot conecta doar la EAP-TLS, dar trebuie totuși să le încărcăm certificatul. Pentru a specifica o altă metodă de conectare, trebuie să folosim Apple Configurator 2. Prin urmare, trebuie să-l descărcăm mai întâi pe Mac, să creăm un nou profil și să adăugăm toate setările necesare WiFi.
Apple Configurator
Aici specificăm numele rețelei noastre
Tip de securitate — WPA2 Enterprise
Tipuri EAP acceptate — TTLS
Nume utilizator și Parolă — lăsăm goale
Autentificare internă — PAP
Identitate externă — client
Tab-ul Încredere. Aici specificăm domeniul nostru
Totul. Profilul poate fi salvat, semnat și distribuit pe dispozitive
După ce profilul este gata, trebuie să-l descărcați pe Mac și să-l instalați. În timpul instalării, va trebui să introduceți username_ldap și password_ldap utilizatorului:
iOS
Procesul este similar cu cel de pe macOS. Trebuie să folosiți profilul (poate fi exact același ca pe macOS. Cum se creează un profil în Apple Configurator, consultați mai sus).
Descărcăm profilul, instalăm, introducem datele de autentificare, ne conectăm:
Asta e tot. Am configurat serverul Radius, l-am sincronizat cu FreeIPA și am indicat punctelor de acces Ubiquiti să folosească WPA2-EAP.
Posibile întrebări
M: cum se transmite profilul/certificatul angajatului?
R: Toate certificatul/profilii le păstrez pe FTP cu acces prin web. Am ridicat o rețea gazdă cu limitare la viteză și acces doar la internet, cu excepția FTP-ului.
Autentificarea se menține timp de 2 zile, după care se resetează și clientul rămâne fără internet. Astfel, când angajatul dorește să se conecteze la WiFi, mai întâi se conectează la rețeaua gazdă, accesează FTP-ul, descarcă certificatul sau profilul de care are nevoie, le instalează și apoi se poate conecta la rețeaua corporativă.
M: de ce să nu folosim schema cu MSCHAPv2? nu este mai sigură?
R: în primul rând, această schemă funcționează bine pe NPS (Windows Network Policy System), în implementarea noastră este necesară configurarea suplimentară a LDAP (FreeIPA) și stocarea hash-urilor parolelor pe server. Configurările suplimentare sunt de evitat, deoarece pot duce la diverse probleme de sincronizare a utilizatorilor. În al doilea rând, hash-ul este de tip MD4, așa că nu mărește semnificativ securitatea.
M: se pot autoriza dispozitivele după adresele MAC?
R: NU, nu este sigur, un atacator poate falsifica adresele MAC, și în plus, autorizarea pe baza adreselor MAC nu este acceptată pe multe dispozitive.
M: de ce să folosim toate aceste certificate? nu putem să ne conectăm și fără ele?
R: Certificatul este utilizat pentru a autoriza serverul. Adică, când un dispozitiv se conectează, verifică dacă acesta este serverul de încredere sau nu. Dacă este, autentificarea continuă; dacă nu, conexiunea se închide. Este posibil să te conectezi fără certificatul, dar dacă un atacator sau un vecin își configurează un server RADIUS și un punct de acces cu același nume ca al nostru, va putea intercepta cu ușurință acreditivele utilizatorului (să nu uităm că acestea sunt transmise în mod deschis). Când se utilizează certificatul, inamicul va vedea în logurile sale doar numele de utilizator fictiv - guest sau client și o eroare de tip - Certificat CA necunoscut.
încă puțin despre macOSDe obicei, pe macOS, reinstalarea sistemului se face prin internet. În modul de recuperare, Macul trebuie să fie conectat la WiFi, iar rețeaua noastră corporativă sau rețeaua de oaspeți nu va funcționa. Personal, am creat o altă rețea, obisnuită pe WPA2-PSK, ascunsă, doar pentru operațiuni tehnice. De asemenea, se poate crea din timp un stick USB bootabil cu sistemul. Dar, dacă Macul este din 2015 sau mai recent, va trebui să găsești un adaptor pentru acest stick).
Sursa: habr.com
