Sono già stati descritti alcuni esempi di organizzazione del WiFi aziendale. Qui spiegherò come ho implementato una soluzione simile e i problemi che ho dovuto affrontare durante la connessione a dispositivi diversi. Utilizzeremo l'LDAP esistente con gli utenti registrati, attiveremo FreeRadius e configureremo WPA2-Enterprise sul controller Ubnt. Sembra tutto semplice. Vediamo...
Un po' sui metodi EAP
Prima di iniziare a svolgere il compito, è necessario decidere quale metodo di autenticazione utilizzeremo nella nostra soluzione.
Dalla Wikipedia:
EAP è un framework di autenticazione utilizzato comunemente nelle reti wireless e nelle connessioni point-to-point. Il formato è stato descritto per la prima volta in RFC 3748 ed è stato aggiornato in RFC 5247.
EAP viene utilizzato per selezionare il metodo di autenticazione, trasferire le chiavi e gestire queste chiavi tramite i moduli collegabili noti come metodi EAP. Ci sono molti metodi EAP, alcuni definiti insieme all'EAP stesso e altri rilasciati da produttori separati. EAP non definisce il livello di collegamento; definisce solo il formato dei messaggi. Ogni protocollo che utilizza EAP ha il proprio protocollo di incapsulamento dei messaggi EAP.
I metodi stessi:
- LEAP è un protocollo proprietario sviluppato da CISCO. Sono state trovate vulnerabilità. Attualmente non è consigliato utilizzare.
- EAP-TLS è ben supportato tra i fornitori di connessioni wireless. È un protocollo sicuro poiché rappresenta l'erede degli standard SSL. La configurazione del client è piuttosto complessa. È necessario un certificato client oltre alla password. È supportato in molti sistemi.
- EAP-TTLS è ampiamente supportato in molti sistemi e offre una buona sicurezza, utilizzando certificati PKI solo sul server di autenticazione.
- EAP-MD5 è un altro standard aperto. Offre una sicurezza minima. È vulnerabile, non supporta l'autenticazione reciproca e la generazione di chiavi.
- EAP-IKEv2 è basato su Internet Key Exchange Protocol versione 2. Fornisce autenticazione reciproca e stabilisce una chiave di sessione tra client e server.
- PEAP è una soluzione congiunta di CISCO, Microsoft e RSA Security come standard aperto. È ampiamente disponibile nei prodotti e offre una sicurezza molto buona. È simile a EAP-TTLS, richiedendo solo un certificato sul lato del server.
- PEAPv0/EAP-MSCHAPv2 — dopo EAP-TLS, è il secondo standard più ampiamente utilizzato al mondo. Viene utilizzata una connessione client-server in Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC — creato da Cisco come alternativa a PEAPv0/EAP-MSCHAPv2. Non protegge i dati di autenticazione in nessun caso. Non è supportato in Windows OS
- EAP-FAST — metodo sviluppato da Cisco per risolvere le carenze di LEAP. Utilizza Protected Access Credential (PAC). Non è completamente finito
Tra tutta questa varietà, la scelta non è poi così vasta. Dal metodo di autenticazione ci si aspettava: buona sicurezza, supporto su tutti i dispositivi (Windows 10, macOS, Linux, Android, iOS) e, naturalmente, più è semplice, meglio è. Perciò la scelta è ricaduta su EAP-TTLS in combinazione con il protocollo PAP.
Potrebbe sorgere la domanda — Perché usare PAP? per il fatto che trasmette le password in chiaro?
Sì, è vero. La comunicazione tra FreeRadius e FreeIPA avverrà in questo modo. In modalità debug, è possibile seguire come vengono inviati username e password. E lasciateli inviare, purché abbiate accesso al server FreeRadius.
Maggiore informazione sul funzionamento di EAP-TTLS può essere letta
FreeRADIUS
Installeremo FreeRadius su CentOS 7.6. Non c'è nulla di complicato, si installa in modo tradizionale.
yum install freeradius freeradius-utils freeradius-ldap -yViene installata la versione 3.0.13 dai pacchetti. L'ultima può essere trovata su
Dopo questo, FreeRadius è già funzionante. Si può decommentare la riga in /etc/raddb/users
steve Cleartext-Password := "testing"Avviare il server in modalità debug
freeradius -XE facciamo una connessione di prova da localhost
radtest steve testing 127.0.0.1 1812 testing123Ricevuto risposta Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, significa che tutto va bene. Andiamo avanti.
Colleghiamo il modulo ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapE subito lo modifichiamo. Dobbiamo fare in modo che FreeRadius possa accedere a 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}})"
}
...Riavviamo il server radius e verifichiamo la sincronizzazione degli utenti LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Modifichiamo eap in mods-enabled/eap
Qui aggiungeremo due istanze eap. Differiranno solo per i certificati e le chiavi. Spiegherò più avanti perché in questo modo.
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"
}
}Modifica successiva site-enabled/default. Ci interessano le sezioni authorize e 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
}Nella sezione authorize rimuoviamo tutti i moduli che non ci servono. Lasciamo solo ldap. Aggiungiamo un controllo del cliente tramite username. È proprio per questo che abbiamo aggiunto sopra due istanze di eap.
Multi EAPIl fatto è che collegando alcuni dispositivi utilizzeremo certificati di sistema e indicheremo un dominio. Abbiamo un certificato e una chiave da un ente di certificazione fidato. Personalmente, credo che questa procedura di collegamento sia più semplice che inviare a ciascun dispositivo un certificato autofirmato. Ma senza certificati autofirmati non siamo riusciti a scappare del tutto. I dispositivi Samsung e Android <= 6 non riescono a utilizzare certificati di sistema. Quindi per loro creiamo un'istanza separata di eap-guest con certificati autofirmati. Per tutti gli altri dispositivi utilizzeremo eap-client con certificato fidato. User-Name è determinato dal campo Anonymous durante la connessione del dispositivo. Sono consentiti solo 3 valori: Guest, Client e campo vuoto. Tutto il resto viene scartato. Questo è configurabile nelle politiche. Darò un esempio un po' più tardi
Modificheremo le sezioni authorize e authenticate in 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
}Ora dobbiamo specificare nelle politiche quali nomi possono essere utilizzati per l'accesso anonimo. Modifichiamo policy.d/filter.
Devi trovare righe simili a questa:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name non è anonimizzato"
}
reject
}E qui sotto in elsif aggiungi i valori necessari:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name non è anonimizzato"
}
reject
}Ora dobbiamo spostarci nella directory certs. Qui dobbiamo mettere la chiave e il certificato dall'ente di certificazione fidato che abbiamo già e dobbiamo generare certificati autofirmati per eap-guest.
Modifichiamo i parametri nel file ca.cnf.
ca.cnf
...
days_default = 3650
days_md_default = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = IT
stateOrProvinceName = Stato
localityName = Città
organizationName = NONAME
emailAddress = admin@admin.it
commonName = "CA FreeRadius"Scriviamo gli stessi valori nel file server.cnf. Cambiamo solamente
commonName:
server.cnf
...
days_default = 3650
days_md_default = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = IT
stateOrProvinceName = Stato
localityName = Città
organizationName = NONAME
emailAddress = admin@admin.it
commonName = "Certificato Server FreeRadius"Creiamo:
makeFatto. Ottenuto server.crt e server.key sono già stati scritti sopra in eap-guest.
E infine, aggiungiamo i nostri punti di accesso nel file client.conf. Ne ho 7. Per non aggiungere ogni punto singolarmente, scriveremo solo la rete in cui si trovano (i miei punti di accesso sono in un VLAN separato).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Controller Ubiquiti
Nel controller creiamo una rete separata. Può essere 192.168.2.0/24
Andiamo nelle impostazioni -> profilo. Creiamo nuovo:
Scriviamo l'indirizzo e la porta del server radius e la password che abbiamo scritto nel file clients.conf:
Creiamo un nuovo nome per la rete wireless. Come metodo di autenticazione scegliamo WPA-EAP (Enterprise) e indichiamo il profilo radius creato:
Salviamo tutto, applichiamo e andiamo avanti.
Configurazione dei client
Iniziamo con la parte più difficile!
Windows 10
La difficoltà è che Windows non è ancora in grado di connettersi al WiFi aziendale tramite dominio. Quindi, dobbiamo caricare manualmente il nostro certificato nel deposito dei certificati di fiducia. Qui possiamo utilizzare sia un certificato autofirmato che uno del centro di certificazione. Userò il secondo.
Dobbiamo quindi creare una nuova connessione. Per farlo, andiamo su Impostazioni rete e Internet -> Centro di gestione rete e condivisione -> Creazione e configurazione di una nuova connessione o rete:
Scriviamo manualmente il nome della rete e cambiamo il tipo di sicurezza. Dopo clicchiamo su modifica le impostazioni della connessione e nella scheda Sicurezza scegliamo l'autenticazione della rete — EAP-TTLS.
Accediamo alle impostazioni, scriviamo la privacy dell'autenticazione — client. Come ente di certificazione fidato scegliamo il certificato che abbiamo aggiunto, mettiamo il segno di spunta su "Non chiedere all'utente per invitare se non riesce ad autorizzare il server" e selezioniamo come metodo di autenticazione — password non criptata (PAP).
Successivamente, accediamo alle impostazioni avanzate, selezioniamo la casella "Specifica il modo di verifica dell'autenticità". Scegliamo l'opzione "Verifica dell'autenticità dell'utente" e facciamo clic su salva le credenziali. Qui sarà necessario inserire username_ldap e password_ldap.
Salviamo tutto, applichiamo e chiudiamo. Possiamo connetterci a una nuova rete.
Linux
Ho verificato su Ubuntu 18.04, 18.10, Fedora 29, 30.
Per iniziare, scarichiamo il certificato. Non ho trovato in Linux se sia possibile utilizzare i certificati di sistema e se ci sia effettivamente un archivio di questo tipo.
Ci collegheremo tramite dominio. Pertanto, è necessario avere il certificato dell'autorità di certificazione da cui abbiamo acquistato il nostro certificato.
Tutta la connessione viene effettuata in una sola finestra. Selezioniamo la nostra rete:
anonymous — client
domain — dominio per il quale è stato emesso il certificato
Android
non-Samsung
A partire dalla versione 7, quando ci si connette a WiFi, si possono usare i certificati di sistema, specificando solo il dominio:
domain — dominio per il quale è stato emesso il certificato
anonymous — client
Samsung
Come già accennato, i dispositivi Samsung non possono utilizzare i certificati di sistema durante la connessione WiFi e non hanno la possibilità di connettersi tramite dominio. Pertanto, è necessario aggiungere manualmente il certificato radice dell'autorità di certificazione (ca.pem, disponibile sul server Radius). Qui verrà utilizzato un certificato autofirmato.
Scarichiamo il certificato sul nostro dispositivo e lo installiamo.
Installazione del certificato
In questo caso, sarà necessario impostare un'immagine di sblocco dello schermo, un codice PIN o una password, se non è già stato fatto:
Ho mostrato la versione complessa per installare il certificato. Su molti dispositivi è sufficiente semplicemente fare clic sul certificato scaricato.
Quando il certificato è installato, possiamo procedere con la connessione:
certificato — specifichiamo quello che abbiamo installato
utente anonimo — guest
macOS
I dispositivi Apple possono connettersi solo a EAP-TLS di default, ma è comunque necessario fornire loro il certificato. Per specificare un altro metodo di connessione, è necessario utilizzare Apple Configurator 2. Di conseguenza, è necessario scaricarlo in anticipo sul Mac, creare un nuovo profilo e aggiungere tutte le impostazioni WiFi necessarie.
Apple Configurator
Qui specifichiamo il nome della nostra rete
Tipo di sicurezza — WPA2 Enterprise
Tipi di EAP accettati — TTLS
Nome utente e Password — lasciamo vuoti
Autenticazione interna — PAP
Identità esterna — client
Scheda Fiducia. Qui specifichiamo il nostro dominio
Tutto. Il profilo può essere salvato, firmato e distribuito sui dispositivi
Dopo che il profilo è pronto, deve essere scaricato su Mac e installato. Durante il processo di installazione sarà necessario fornire il username_ldap e la password_ldap dell'utente:
iOS
Il processo è simile a macOS. È necessario utilizzare un profilo (può essere esattamente lo stesso utilizzato per macOS. Come creare un profilo in Apple Configurator, vedere sopra).
Scarichiamo il profilo, lo installiamo, inseriamo le credenziali, ci connettiamo:
Questo è tutto. Abbiamo configurato il server Radius, l'abbiamo sincronizzato con FreeIPA e abbiamo indicato ai punti di accesso Ubiquiti di utilizzare WPA2-EAP.
Domande possibili
D: come trasferire il profilo/certificato a un dipendente?
R: Tutti i certificati/profili che conservo su FTP con accesso tramite web. Ho attivato una rete guest con limitazione di velocità e accesso solo a internet, eccezion fatta per l'FTP.
L'autenticazione dura 2 giorni, dopodiché viene ripristinata e il cliente rimane senza internet. Così, quando il dipendente desidera connettersi al WiFi, prima si connette alla rete guest, accede all'FTP, scarica il certificato o il profilo di cui ha bisogno, li installa e poi può connettersi alla rete aziendale.
D: perché non utilizzare lo schema con MSCHAPv2? è più sicuro!
R: In primo luogo, tale schema funziona bene su NPS (Windows Network Policy System), nella nostra implementazione è necessario configurare ulteriormente LDAP (FreeIPA) e memorizzare gli hash delle password sul server. È sconsigliabile fare ulteriori configurazioni, in quanto potrebbero portare a vari problemi di sincronizzazione degli utenti. In secondo luogo, l'hash è MD4, quindi non aumenta molto la sicurezza.
D: è possibile autorizzare i dispositivi tramite indirizzi mac?
R: NO, non è sicuro, un aggressore può falsificare gli indirizzi mac, e in più l'autenticazione tramite indirizzi mac non è supportata su molti dispositivi.
D: perché utilizzare tutti questi certificati? è possibile connettersi anche senza di essi.
R: I certificati vengono utilizzati per autorizzare il server. Ossia, il dispositivo al momento della connessione verifica se si tratta del server di cui ci si può fidare o meno. Se lo è, l'autenticazione prosegue, se no, la connessione viene chiusa. È possibile connettersi senza certificati, ma se un malintenzionato o un vicino avvia un server Radius e un punto di accesso con lo stesso nome del nostro, potrà facilmente intercettare le credenziali dell'utente (ricordiamo che vengono trasmesse in chiaro). E quando viene utilizzato un certificato, il nemico vedrà solo nei suoi log i nostri nomi utente inventati — guest o client e un errore del tipo — Certificato CA sconosciuto.
Ancora un po' su macOSDi solito, su macOS la reinstallazione del sistema avviene tramite internet. In modalità di recupero, il Mac deve essere collegato a WiFi, e qui non funzionerà né il nostro WiFi aziendale, né la rete ospite. Personalmente ho attivato un'altra rete, normale con WPA2-PSK, nascosta, solo per operazioni tecniche. In alternativa, è possibile creare in anticipo una chiavetta USB avviabile con il sistema. Ma se il Mac è post 2015, sarà necessario trovare un adattatore per questa chiavetta).
Fonte: habr.com
