Sono già stati descritti alcuni esempi di organizzazione del WiFi aziendale. Qui spiegherò come ho implementato una soluzione simile e quali problemi ho incontrato nel collegamento con dispositivi diversi. Utilizzeremo l'LDAP esistente con gli utenti registrati, installeremo FreeRadius e configureremo WPA2-Enterprise sul controller Ubnt. Sembra tutto semplice. Vediamo...
Un po' sui metodi EAP
Prima di iniziare a svolgere il compito, dobbiamo decidere quale metodo di autenticazione utilizzeremo nella nostra soluzione.
Dalla Wikipedia:
EAP è un framework di autenticazione, spesso utilizzato in reti wireless e connessioni punto a punto. Il formato è stato descritto per la prima volta nell'RFC 3748 e aggiornato nell'RFC 5247.
EAP viene utilizzato per selezionare il metodo di autenticazione, trasmettere le chiavi e gestire queste chiavi tramite moduli connessi chiamati metodi EAP. Esistono numerosi metodi EAP, sia definiti insieme all'EAP stesso che rilasciati da singoli produttori. 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.
Metodi stessi:
- LEAP — protocollo proprietario sviluppato da CISCO. Sono state trovate vulnerabilità. Attualmente non è consigliato l'uso.
- EAP-TLS — ampiamente supportato dai fornitori di connessioni wireless. È un protocollo sicuro, in quanto è il successore degli standard SSL. La configurazione del client è piuttosto complessa. Richiede un certificato del client oltre alla password. Supportato in molti sistemi.
- EAP-TTLS — ampiamente supportato in molti sistemi, offre una buona sicurezza utilizzando certificati PKI solo sul server di autenticazione.
- EAP-MD5 — un altro standard aperto. Offre sicurezza minima. È vulnerabile, non supporta l'autenticazione reciproca e la generazione di chiavi.
- EAP-IKEv2 — basato sul protocollo Internet Key Exchange versione 2. Garantisce l'autenticazione reciproca e l'installazione di una chiave di sessione tra client e server.
- PEAP — soluzione congiunta di CISCO, Microsoft e RSA Security come standard aperto. Ampiamente disponibile nei prodotti, offre una sicurezza molto buona. Simile a EAP-TTLS, richiedendo solo un certificato sul lato server.
- PEAPv0/EAP-MSCHAPv2 — dopo EAP-TLS, è il secondo standard più utilizzato al mondo. Utilizza una connessione client-server in Microsoft, Cisco, Apple e Linux.
- PEAPv1/EAP-GTC — creato da Cisco come alternativa a PEAPv0/EAP-MSCHAPv2. Non protegge i dati di autenticazione in alcun modo. Non è supportato in Windows OS.
- EAP-FAST — metodo sviluppato da Cisco per correggere le carenze di LEAP. Utilizza le Credenziali di Accesso Protette (PAC). Non è completamente sviluppato.
Tra tutta questa varietà, la scelta non è poi così ampia. Dal metodo di autenticazione era richiesta: buona sicurezza, supporto su tutti i dispositivi (Windows 10, macOS, Linux, Android, iOS) e, sostanzialmente, più è semplice, meglio è. Pertanto, la scelta è ricaduta su EAP-TTLS in combinazione con il protocollo PAP.
Potrebbe sorgere la domanda — perché usare PAP? Dato che invia le password in chiaro?
Sì, è corretto. La comunicazione tra FreeRadius e FreeIPA avverrà proprio in questo modo. In modalità debug, si può tracciare come vengono inviati username e password. E non importa che vengano inviati, solo che hai accesso al server FreeRadius.
Puoi leggere ulteriormente sul funzionamento di EAP-TTLS.
FreeRADIUS
Installeremo FreeRadius su CentOS 7.6. Non c'è niente di complicato, lo installiamo nel modo consueto.
yum install freeradius freeradius-utils freeradius-ldap -yDai pacchetti si installa la versione 3.0.13. L'ultima versione è disponibile su
Dopo questo, FreeRadius è già operativo. È possibile decommentare la riga in /etc/raddb/users
steve Cleartext-Password := "testing"Avviare il server in modalità debug
freeradius -XE facciamo un test di connessione con localhost
radtest steve testing 127.0.0.1 1812 testing123Ricevuto una risposta Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, tutto bene. Andiamo avanti.
Colleghiamo il modulo ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapE subito lo modifichiamo. Dobbiamo assicurarci 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 di eap. Si differenzieranno solo per i certificati e le chiavi. Spiegherò più avanti il perché.
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"
}
}Continua a modificare site-enabled/default. Vorrei sapere delle 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 di cui non abbiamo bisogno. 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 il dominio. Abbiamo un certificato e una chiave da un centro di certificazione fidato. Personalmente, ritengo che questa procedura di connessione sia più semplice rispetto a dover caricare un certificato autofirmato su ogni dispositivo. Tuttavia, non siamo riusciti a evitare completamente i certificati autofirmati. I dispositivi Samsung e Android < 6 non sono in grado di utilizzare i certificati di sistema. Pertanto, creiamo un'istanza separata di eap-guest con certificati autofirmati per loro. Per tutti gli altri dispositivi utilizzeremo eap-client con certificato fidato. Il nome utente è determinato dal campo Anonymous durante la connessione del dispositivo. Sono consentiti solo 3 valori: Guest, Client e un campo vuoto. Tutti gli altri valori vengono scartati. Questo è configurato nelle politiche. Fornirò un esempio tra poco.
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
}Successivamente, è necessario specificare nelle politiche quali nomi possono essere utilizzati per l'accesso anonimo. Modifichiamo policy.d/filter.
Dobbiamo trovare righe simili a questa:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name non è anonimizzato"
}
reject
}E sotto in elsif aggiungere 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 da un'autorità di certificazione fidata che abbiamo già, e generare certificati autofirmati per eap-guest.
Modifichiamo i parametri nel file ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = IT
stateOrProvinceNmae = Stato
localityNmae = Città
organizationName = NONAME
emailAddress = admin@admin.it
commonName = "CA FreeRadius"Scriviamo gli stessi valori nel file server.cnf. Cambiamo solo
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = IT
stateOrProvinceNmae = Stato
localityNmae = Città
organizationName = NONAME
emailAddress = admin@admin.it
commonName = "Server Certificate FreeRadius"Creiamo:
makeFatto. I risultati server.crt e server.key sono già stati specificati 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, indichiamo 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
Sul controller creiamo una rete separata. Sarà 192.168.2.0/24
Andiamo alle impostazioni -> profilo. Creiamo un nuovo:
Indichiamo l'indirizzo e la porta del server radius e la password che abbiamo registrato 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 proseguiamo.
Configurazione dei client
Iniziamo con la parte più difficile!
Windows 10
La difficoltà sta nel fatto che Windows ancora non riesce a connettersi al WiFi aziendale per dominio. Pertanto, è necessario caricare manualmente il nostro certificato nel deposito dei certificati fidati. Qui si può utilizzare sia un certificato autofirmato che uno emesso da un centro di certificazione. Utilizzerò il secondo.
Dobbiamo quindi creare una nuova connessione. Per farlo, andiamo su impostazioni di rete e Internet -> Centro gestione reti e condivisione -> Creazione e configurazione di una nuova connessione o rete:
Inseriamo manualmente il nome della rete e cambiamo il tipo di sicurezza. Poi clicchiamo su modifica le impostazioni di connessione e nella scheda Sicurezza selezioniamo l'autenticazione della rete — EAP-TTLS.
Accediamo alle impostazioni, impostiamo la riservatezza dell'autenticazione — client. Come autorità di certificazione attendibile selezioniamo il certificato che abbiamo aggiunto, segniamo l'opzione «Non chiedere all'utente di autenticarsi se la connessione al server non riesce» e scegliamo il metodo di autenticazione — password non crittografata (PAP).
Poi entriamo nelle impostazioni avanzate, spuntiamo l'opzione «Specifica il metodo di autenticazione». Selezioniamo l'opzione «Autenticazione dell'utente» e clicchiamo su salva le credenziali. Qui dobbiamo inserire username_ldap e password_ldap
Salviamo, applichiamo e chiudiamo. Possiamo connetterci alla nuova rete.
Linux
Ho testato su Ubuntu 18.04, 18.10, Fedora 29, 30.
Per iniziare, scarichiamo il certificato. Non ho trovato in Linux se c'è la possibilità di utilizzare certificati di sistema e se c'è anche un archivio di questo tipo.
Ci connetteremo tramite il dominio. Pertanto, è necessario un certificato della certificazione, da cui è stato acquistato il nostro certificato.
Tutta la connessione avviene in un'unica finestra. Scegliamo la nostra rete:
anonymous — client
domain — dominio a cui è stato emesso il certificato
Android
non-Samsung
Dalla versione C 7, è possibile utilizzare i certificati di sistema durante la connessione WiFi, specificando solo il dominio:
domain — dominio a cui è stato emesso il certificato
anonymous — client
Samsung
Come già accennato in precedenza, 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 quello autofirmato.
Scarichiamo il certificato sul nostro dispositivo e lo installiamo.
Installazione del certificato
A questo punto, sarà necessario impostare un'immagine di sblocco dello schermo, un PIN o una password, se non è già stata impostata:
Ho mostrato una procedura complessa per l'installazione del certificato. Su la maggior parte dei dispositivi, è sufficiente semplicemente fare clic sul certificato scaricato.
Quando il certificato è installato, si può procedere alla connessione:
certificato — indichiamo quello che abbiamo installato
utente anonimo — guest
macOS
I dispositivi Apple out-of-the-box possono connettersi solo a EAP-TLS, ma è comunque necessario caricare un certificato. Per specificare un altro metodo di connessione, è necessario utilizzare Apple Configurator 2. Pertanto, è necessario scaricarlo in anticipo su Mac, creare un nuovo profilo e aggiungere tutte le impostazioni WiFi necessarie.
Apple Configurator
Qui inseriamo il nome della nostra rete
Tipo di sicurezza — WPA2 Enterprise
Tipi EAP accettati — TTLS
Nome utente e password — lasciarli vuoti
Autenticazione interna — PAP
Identità esterna — client
Scheda Trust. Qui inseriamo il nostro dominio
Tutto. Il profilo può essere salvato, firmato e distribuito sui dispositivi
Dopo aver preparato il profilo, è necessario scaricarlo su Mac e installarlo. Durante il processo di installazione, sarà necessario fornire username_ldap e password_ldap dell'utente:
iOS
Il processo è simile a macOS. È necessario utilizzare un profilo (può essere lo stesso di quello per macOS. Per informazioni su 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, sincronizzato con FreeIPA e indicato ai punti di accesso Ubiquiti di utilizzare WPA2-EAP.
Domande possibili
D: come trasferire il profilo/certificato a un dipendente?
R: Conservo tutti i certificati/profili su FTP con accesso tramite web. Ho attivato la rete ospite con limitazione di velocità e accesso solo a Internet, fatta eccezione per FTP.
L'autenticazione dura 2 giorni, dopodiché viene ripristinata e il cliente resta senza Internet. Così, quando un dipendente vuole connettersi al WiFi, prima si collega alla rete ospite, accede all'FTP, scarica il certificato o profilo necessario, li installa e poi può connettersi alla rete aziendale.
D: Perché non utilizzare lo schema 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. Non è consigliabile fare ulteriori configurazioni, poiché ciò potrebbe portare a vari problemi di sincronizzazione degli utenti. In secondo luogo, l'hash è costituito da MD4, quindi non migliora molto la sicurezza.
D: È possibile autorizzare i dispositivi in base agli indirizzi MAC?
R: NO, non è sicuro; un malintenzionato può falsificare gli indirizzi MAC e, inoltre, l'autenticazione per indirizzi MAC non è supportata su molti dispositivi.
D: Perché utilizzare tutti questi certificati? Si può anche connettersi senza di essi.
R: I certificati vengono utilizzati per autenticare il server. Cioè, il dispositivo verifica se si tratta del server fidato. Se è fidato, l'autenticazione continua; se no, la connessione viene chiusa. Si può connettersi anche senza certificati, ma se un malintenzionato o un vicino configura un server RADIUS e un punto di accesso a casa con lo stesso nome, può facilmente intercettare le credenziali dell'utente (ricordiamo che vengono trasmesse in chiaro). Quando viene utilizzato un certificato, il nemico vedrà solo i nostri nomi utente fittizi nei log — 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 connesso al WiFi, e qui non funzionerà né il nostro WiFi aziendale né la rete ospite. Personalmente, ho creato un'altra rete, normale con WPA2-PSK, nascosta, solo per operazioni tecniche. In alternativa, si può anche preparare in anticipo una chiavetta USB avviabile con il sistema. Ma se il Mac è stato prodotto dopo il 2015, sarà necessario trovare un adattatore per questa chiavetta.)
Fonte: habr.com
