Proteggere la rete Wi-Fi con FreeRADIUS (EAP)
Da Wiki di NetBSD Italia.
Questa guida descrive la procedura per la messa a punto di un server RADIUS (Remote Authentication Dial In User Service) e del relativo software di autenticazione lato client (il supplicant). L'infrastruttura utilizzata per l'autenticazione e PEAP (Protected Extensible Authentication Protocol).
Dal momento che l'autenticazione, fornendo l'accesso alla rete Wi-Fi, non è in alcun modo correlata alla rete esterna e che il sistema di sicurezza per il trasferimento dei dati passanti per il punto d'accesso (WPA, WEP, etc.) non è in alcun modo correlato al servizio RADIUS, argomenti come la configurazione della connessione ad internet e la cifratura dei dati non verranno trattati.
Indice |
Requisiti
Per poter mettere a punto un server come quello di cui sopra bisogna disporre di:
- un punto di accesso Wi-Fi (con supporto 802.1x)
- una macchina con NetBSD installato.
NOTA: non è necessario disporre di una connessione alla rete esterna.
Installazione
I passi per l'installazione sono analoghi a quelli di uno qualsiasi dei pacchetti presenti all'interno dell'albero delle directory di pkgsrc. Questo installerà anche il modulo per le limitazioni del numero di connessioni simultanee concesse ai client (opzione freeradius-simul-use abilitata di default) chiamato Simultaneous-Use.
$ cd /usr/pkgsrc/net/freeradius # make install clean clean-depends
Come è possibile leggere dal messaggio informativo in fase di post-installazione, il demone FreeRADIUS è in grado di girare in modalità non privilegiata. Questo vuol dire che non è più richiesto l'accesso root per la sua messa a punto, per tanto le directory utilizzate dal servizio vanno modificate come segue:
chown -R radius:radius /var/run/radiusd /usr/pkg/etc/raddb
find /usr/pkg/etc/raddb -type d -exec chmod 0750 {} \;
find /usr/pkg/etc/raddb -type f -exec chmod 0640 {} \;
Adesso passare alla fase successiva: la configurazione.
Configurazione
La parte più divertente della messa a punto di FreeRADIUS è proprio quella relativa alla configurazione. Infatti, essendo un software tanto potente quanto flessibile e ricco di opzioni, consente di attraverso le sue molteplici sfaccettature di aderire alle più disparate esigenze degli amministratori. In questa sezione verranno descritti solamente i parametri fondamentali per ottenere un server funzionale lasciando i dettagli a letture più appropriate.
Innanzi tutto occorre abilitare l'autenticazione MS-CHAPv2 (in seguito utilizzata dal supplicant Wi-Fi) configurando il modulo mschap all'interno del file /usr/pkg/etc/raddb/radiusd.conf:
mschap {
use_mmpe = yes
require_encryption = yes
require_strong = yes
}
È necessario anche abilitare la cifratura basata sui certificati TLS (vedi sezione relativa) EAP-TLS decommentando le seguenti righe all'interno del file /usr/pkg/etc/raddb/eap.conf, facendo attenzione a non dimenticarsi la parentesi graffa chiusa alla fine:
tls {
private_key_password = whatever
private_key_file = ${raddbdir}/certs/cert-srv.pem
certificate_file = ${raddbdir}/certs/cert-srv.pem
CA_file = ${raddbdir}/certs/demoCA/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
include_length = yes
}
Terminata la fase relativa al server non resta che abilitare l'accesso ai client attraverso il file /usr/pkg/etc/raddb/client.conf inserendo una sezione del tipo:
client IP {
secret = parola_segreta
shortname = router
}
Dove IP corrisponde all'indirizzo IP del punto d'accesso su cui si è impostata l'autenticazione attraverso il server RADIUS. Il prossimo passo sarà aggiungere gli utenti abilitati ad effettuare l'accesso alla rete Wi-Fi configurando appositamente il file /usr/pkg/etc/raddb/users in questo modo:
nome_utente User-Password == "password"
Devo nome_utente e password sono auto-esplicativi e rispettivamente assegnati alle variabili identity e password del file di configurazione del supplicant.
Infine consentire all'utente radius di scrivere sul file di LOG:
# chown radius /var/log/radiusd/radius.log
Certificati
Per l'autenticazione EAP il server utilizza dei certificati al fine di garantire l'autenticità delle richieste in ingresso per mezzo della password di rete impostata nel punto d'accesso. Durante l'installazione del pacchetto alcuni script provvederanno a generare dei certificati standard per garantire l'avvio del server con la password di default (whatever). Tuttavia è bene creare i propri certificati personali grazie ai quali rendere più sicuro il processo di autenticazione impostando una password differente. I certificati possono essere generati come segue:
# cd /usr/pkg/etc/raddb # mv certs certs.orig # mkdir certs # cd certs # for arg in "-newca -newreq -sign" ; do /usr/pkg/share/examples/openssl/CA.pl $arg ; done
Al termine del processo verrà richiesta la chiave inserita in fase di generazione del certificato CA (cakey.pem). Ora basterà assecondare la configurazione standard unendo il certificato e la chiave in un unico file (cert-srv.pem), come segue:
NOTA: la parola segreta deve essere la stessa per entrambe i certificati.
# cat newcert.pem newkey.pem > cert-srv.pem
Per i più "puliti":
# rm -r new* demoCA/?[!a]*
Altri file essenziali
Fra i vari file contenuti nella directory certs/ originaria sono inclusi anche dh, contenente i parametri Diffie-Hellman e random contenente una certa quantità (1024 byte di default) di dati casuali. Questi file sono indispensabili per avviare il server, per tanto è necessario crearli eseguendo, all'interno della directory /usr/pkg/etc/raddb/, i seguenti comandi:
# openssl dhparam -out dh 1024 # dd if=/dev/urandom of=random bs=1024 count=1
Verifica del servizio
Se quanto descritto nelle precedenti sezioni è stato seguito correttamente, si dovrebbe a questo punto essere in grado di effettuare un primo avvio del server.
# radiusd -X
In questo modo il server verrà avviato (ma senza andare in background) mostrando diverse righe di output e terminando con delle righe simili a queste:
Listening on authentication *:1812 Listening on accounting *:1813 Ready to process requests.
In caso di errore controllare la configurazione e verificare che tutti i passaggi siano stati effettuati correttamente. Subito dopo aver avviato il server controllaro che esso sia effettivamente funzionante instaurando una connessione di prova eseguendo il comando:
# radtest nome_utente password 127.0.0.1 0 parola_segreta
Dove la coppia nome_utente e password corrisponde a una di quelle impostate nel file users e parola_segreta è il valore assegnato alla variabile secret del client 127.0.0.1 nel file clients.conf (default: testing123). L'output così ottenuto dovrebbe essere simile al seguente:
# radtest nome_utente password 127.0.0.1 0 testing123
Sending Access-Request of id 86 to 127.0.0.1 port 1812
User-Name = "nome_utente"
User-Password = "password"
NAS-IP-Address = 255.255.255.255
NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=86, length=20
L'ultima riga conferma che l'autenticazione è andata a buon fine per tanto il server funziona. Complimenti!
Automazione
Una volta certi che tutto funzioni correttamente è possibile fare in modo che il demone RADIUS parta all'avvio aggiungendo la seguente riga nel file /etc/rc.conf:
radiusd=YES
Per attivare subito il servizio senza dover riavviare il sistema basta eseguire il comando:
# /etc/rc.d/radiusd start
A questo punto il server è avviato.
Supplicant
Il supplicant si occupa di instaurare la connessione con la rete Wi-Fi trasferendo le informazioni tra il client su cui gira e il punto d'accesso. E' possibile che vengano trasmesse in chiaro informazioni sensibili, per questo motivo, sebbene la configurazione possa sembrare semplice e intuitiva, richiede particolare attenzione soprattutto se la sicurezza è un requisito indispensabile.
Parametri
I parametri relativi all'autenticazione sul server RADIUS sono essenzialmente il nome utente (identity) e la password:
identity="nome_utente" password="password"
Questo però fara in modo che il supplicant invii il nome utente in chiaro durante la prima fase dell'handshake abbassando il livello di sicurezza della rete. La soluzione consiste nel sostituire tale parametro con una maschera facendo in modo che un eventuale attaccante non possa risalire al nome utente reale:
phase1="identity=[hidden]"
Infine abilitare esplicitamente l'autenticazione Microsoft CHAP v.2 nella seconda fase:
phase2="auth=MSCHAPV2"
Per ulteriori dettagli è disponibile anche una trattazione generale sulla configurazione di wpa_supplicant.
Esempio
Quanto segue è un esempio di configurazione reale e funzionante. Diversi accorgimenti possono essere apportati al fine di rendere più flessibile la configurazione (ad esempio cambiando il valore della variabile proto che, se impostato su RSN non consente la trasmissione di dati con cifratura WPA, solo WPA2). Il file di configurazione è il seguente:
#
# WPA Supplicant configuration file
#
# allow frontend (e.g., wpa_cli) to be used by all users in ’root’ group
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=root
#
# home network (radius PEAP authentication)
#
network={
# Network name
ssid="ssid"
# Encrypition
key_mgmt=WPA-EAP
proto=RSN
eap=PEAP
# Authentication informations
identity="nome_utente"
password="password"
# First phase: don't send the real username (it's in clear)
phase1="identity=[hidden]"
# Second phase: enable Microsoft CHAP v.2 authentication
phase2="auth=MSCHAPV2"
}
I dati sono identici a quelli utilizzati negli esempi di questo documento. Per maggiori informazioni ed ulteriori esempi consultare l'articolo sulla configurazione di wpa_supplicant.
Conclusioni
In questa guida sono stati affrontati una parte degli elementi necessari a rendere la propria rete Wi-Fi un pò più sicura, anche in ambito aziendale. Tuttavia questo può non bastare e in ogni caso ulteriori accorgimenti e misure di sicurezza dovrebbero essere prese al fine di scoraggiare eventuali attacchi e tentativi di violazione. Spesso i punti d'accesso consentono di disabilitare la trasmissione del SSID o di abilitare i cosiddetti MAC filter, dei filtri basati sugli gli indirizzi MAC delle schede i quali dovrebbero essere univochi. Questo però non è sufficiente a garantire la sicurezza dei dati. Và considerato inoltre che sebbene risulti molto difficoltoso poter accedere all'interno della rete, è impossibile prevenire la cattura (sniffing) dei pacchetti in transito. Per questo motivo soluzioni come la cifratura dei dati sono alla base delle misure di sicurezza da adottare e connessioni in chiaro come trasferimenti ftp o accessi telnet sono da evitare. Per ulteriori informazioni consultare la numerosa documentazione disponibile sul web.
