Sicurezza su Wi-Fi – Zeroshell

Domande sulla sicurezza delle reti Wireless Wi-Fi

Ho una rete Wi-Fi e vorrei proteggerla dagli accessi non autorizzati. È preferibile usare un server RADIUS che mi consenta di ottenere l’autenticazione 802.1x e la protezione con WPA o WPA2 oppure utilizzare un Captive Portal che mi autentichi gli accessi mediante web login?
Entrambi questi metodi hanno i loro pregi e difetti. Utilizzando RADIUS con 802.11i si ha una maggiore sicurezza dovuta al fatto che oltre all’autenticazione degli accessi, che avviene quando il client si associa all’accesspoint, il layer 2 della comunicazione wireless è cifrato con delle chiavi crittografiche che vengono cambiate ad intervalli regolari. Dal canto suo, invece, un gateway con Captive Portal, si limita semplicemente ad autorizzare gli accessi quando il client ha già ottenuto un indirizzo IP. In questo caso, se si pretende che i dati siano anche criptati si deve ricorrere ad altri espedienti come per esempio le VPN. Il captive portal ha però l’incontestabile vantaggio di non richiedere alcuna configurazione lato client e di poter funzionare con qualsiasi hardware Wi-Fi. In realtà, dato che lavora a livello IP, il Captive Portal può proteggere gli accessi anche sulla rete cablata. Il sistema con server RADIUS, invece, oltre ad essere più complicato da configurare per l’utente, necessita del supporto da parte dell’hardware (access point e schede di rete wireless) e del sistema operativo. Concludiamo pertanto, dicendo, che il Captive Portal si adatta meglio nelle realtà come gli HotSpot in cui l’unico obiettivo è proteggere dall’accesso indiscriminato a Internet. WPA e WPA2 con server RADIUS si adattano meglio in quelle situazioni in cui è indispensabile garantire la confidenzialità dei dati oltre all’autenticazione degli utenti.

RADIUS server, 802.1x, WPA, 802.11i (WPA2)

Nella terminologia RADIUS riferita alla protezione di reti WiFi, cosa si intende per supplicant, authenticator, NAS e authentication server?
Un client che cerca di associarsi in una rete autenticata con 802.1x è denominato supplicant. Spesso si fa riferimento con il termine supplicant ad un software presente sul client che si occupa del processo di autenticazione 802.1x: in Windows XP o Mac OS X il supplicant è già integrato nel sistema, mentre in Linux, per buona parte delle distribuzioni, si deve ricorrere all’installazione del pacchetto Xsupplicant del progetto open1x.
Con i termini authenticator o equivalentemente NAS (Network Access Server) ci si riferisce agli Access Point. Alcuni dei punti di accesso più economici potrebbero non essere in grado di svolgere la funzione di authenticator non riuscendo a gestire il protocollo 802.1x.
Infine, con il termine authentication server, si indica il server a cui è delegato il compito di stabilire se l’utente che vuole accedere alla rete è veramente chi dice di essere. Quasi sempre l’authentication server coincide con un RADIUS server.
Il RADIUS server di ZeroShell supporta i protocolli WPA e 802.11i (WPA2) per la protezione delle reti wireless?
Sia il WPA che il WPA2 utilizzano come sistema di autenticazione e di generazione delle chiavi crittografiche il frame 802.1x. Poiché il RADIUS server di ZeroShell (FreeRadius) supporta 802.1x con i metodi di autenticazione EAP-TLS, EAP-TTLS e PEAP con Ms-Chapv2, WPA e WPA2 sono automaticamente supportati. Si noti però, che poiché WPA2 richiede uno strato crittografico con il moderno algoritmo di cifratura AES, bisogna verificare che l’hardware a disposizione (Accesspoint e schede wi-fi) supporti tale cifratura. Per il WPA invece, che utilizza come cifratura il meccanismo RC4 (come il WEP ma senza i problemi di sicurezza dovuti all’uso di chiavi statiche), anche il vecchio hardware in genere funziona tranquillamente. Al più è necessario un aggiornamento del firmware e dei driver.
Quando configuro il supplicant del mio computer, devo scegliere il metodo di autenticazione tra EAP-TLS, EAP-TTLS e PEAP. Di cosa si tratta?
L’802.1x è un frame di autenticazione intendendo con ciò che il metodo effettivo con cui avviene la validazione dell’utente viene negoziato tra quelli disponibili contemporaneamente sia al supplicant che all’authentication server. Tra i metodi di autenticazione che vengono presi in considerazione quando si utilizzano reti Wireless si hanno l’EAP-TLS, il PEAP e l’EAP-TTLS perchè questi sono quelli che, tramite l’uso di tunnel cifrati con SSL/TLS, danno maggiori garanzie di sicurezza e supporto per la generazione e lo scambio di chiavi crittografiche utilizzate in WPA e 802.11i.
L’EAP-TLS necessita di un cerficato digitale X.509 con relativa chiave privata sia sul RADIUS server che sul supplicant. Spesso, data la difficoltà con cui si riesce a dotare un’organizzazione di una PKI X.509 in grado di fornire ad ogni utente un certificato, si rinuncia a utilizzare EAP-TLS, anche se questo metodo è sicuramente quello più sicuro poiché l’utente non deve digitare username e password.
Del resto EAP-TLS è ideale quando si vuole autenticare l’accesso in rete mediante smart card memorizzando la chiave privata e il certificato dell’utente direttamente su tale supporto.
Il PEAP (Protected EAP) così come l’EAP-TTLS necessitano di un certificato X509 e della relativa chiave privata solo dal lato del RADIUS server. Con tale certificato viene autenticato l’authentication server nei confronti del client e successivamente stabilito un tunnel SSL/TLS in cui far passare un altro protocollo con cui autenticare l’utente nei confronti di RADIUS. In genere tale protocollo è Ms-CHAPv2 in cui l’utente deve inserire username e password.
Tra il PEAP e l’EAP-TTLS il PEAP con MS-CHAPv2 è quello più utilizzato. Ciò, probabilmente, è dovuto al fatto che Windows XP dà supporto nativo per questo protocollo. Se invece si vuole utilizzare EAP-TTLS su Windows bisogna ricorrere ad un supplicant di terzi come per esempio il SecureW2 di Alfa & Ariss.
Per quanto riguarda Linux, invece, Xsupplicant supporta tutti e tre i metodi di autenticazione.
Possiedo un Access Point che dispone della funzionalità Multiple SSID nel senso che possono essere configurati diversi SSID mappati su diverse VLAN. Se utilizzo ZeroShell come RADIUS server, posso smistare i client Wi-Fi sulle diverse VLAN in base allo username utilizzato durante l’autenticazione 802.1x?
Sì è possibile. È sufficiente impostare, nella scheda che riguarda l’utente, il VLAN ID 802.1Q della VLAN su cui si vuole associare l’utente. Così facendo, il server RADIUS, dopo aver autenticato l’utente con 802.1x, manderà all’Access Point gli attributi Tunnel-Type (=VLAN), Tunnel-Medium-Type (=802) e Tunnel-Private-Group-ID (=VLAN ID impostato per l’utente). Se l’AP riconosce tali attributi (in genere gli AP di Cisco lo fanno) il client verrà automaticamente associato sul SSID a cui corrisponde il VLANID.
Se l’autenticazione avviene mediante EAP-TLS, e quindi con certificati X.509 invece che con le normali credenziali, lo username viene ricavato dal valore del campo CN del certificato utilizzato.
Durante la configurazione dell’accesspoint e del server RADIUS, mi viene richiesto di specificare lo Shared Secret. Di cosa si tratta?
Così come il nome stesso suggerisce, lo Shared Secret, è una sequenza alfanumerica condivisa soltanto tra accesspoint e server di autenticazione RADIUS. Tale segreto è a garanzia dell’autenticità dell’AP e del server che intervengono nell’autenticazione di un client: se lo shared secret non coincide, i messaggi del protocollo 802.1x non vengono scambiati e l’autenticazione fallisce subito. Si noti che mentre sull’access point deve essere configurato un unico segreto, sul server RADIUS ne viene configurato uno per ogni indirizzo IP di access point per il quale è autorevole nell’autenticazione.
Il server RADIUS di ZeroShell può funzionare anche in modalità proxy. Cosa significa esattamente?
Nel supplicant del client wireless che tenta di autenticarsi mediante 802.1x lo username può essere inserito nella forma username@dominio (es. pluto@EXAMPLE.COM). In base al dominio, il server RADIUS a cui arriva la richiesta di autenticazione, decide se è autorevole per gestirla oppure deve delegare un altro server che possa farlo. In questo caso, il primo server RADIUS si dice che è un proxy RADIUS e necessita di un segreto condiviso con il secondo, come se fosse un normale access point. Si può, inoltre, configurare un RADIUS di default a cui mandare le richieste proxy per i domini non esplicitamente configurati. Si noti infine, che il secondo server RADIUS, potrebbe a sua volta non essere in grado di gestire la richiesta e quindi fare da proxy verso un altro server e così continuando finché non si raggiunge un server autorevole nella gestione dell’autenticazione del dominio.
Zeroshell supporta il WEP e il WPA-PSK per la protezione delle reti Wi-Fi?
Tanto il WEP quanto il WPA-PSK sono sistemi di protezione di tipo preshared key, intendendo con ciò, che un supplicant, che cerca di associarsi ad un access-point, deve condividere una chiave preimpostata con quest’ultimo. Per quanto detto, non è necessaria la presenza di un server di autenticazione che convalidi ogni singolo utente e quindi, chiedersi se ZeroShell supporti WEP e WPA-PSK non ha alcun senso.
Si badi bene al fatto, che il WEP è ritenuto ormai insufficiente per proteggere anche una rete wireless domestica visto che l’algoritmo di cifratura RC4 su cui è basato, unito ad un vettore di inizializzazione di soli 24 bit da combinare con la chiave condivisa, può essere crackato in poco tempo se si sniffano una quantità sufficiente di pacchetti. Il WPA-PSK, che invece utilizza un vettore di inizializzazione di 48 bit, purché utilizzato con una PSK di almeno 20 caratteri, è ritenuto una soluzione accettabile in ambienti domestici o SOHO.

Captive Portal

Il Captive Portal di ZeroShell è composto da due moduli: il server di Web Login e il Captive Gateway. Qual è il vantaggio di questa modularità?
La funzionalità di Captive Gateway è quella di un gateway (router o bridge) che, per i client non ancora autenticati, sbarra l’accesso ad una zona protetta della LAN, forwardando soltanto le richieste sulle porte 80 (http) e 443 (https) verso un server di Web Login ( detto anche Authentication Server). Il compito di quest’ultimo è quello di presentare all’utente una pagina web di autenticazione in cui inserire username e password. Se l’autenticazione ha esito positivo, il captive gateway rimuove le barriere per il client autenticato che potrà quindi accedere alla zona protetta.
Separando queste due funzionalità in moduli distinti, si ottiene il vantaggio di poter creare strutture multigateway, in cui più captive gateway, messi a protezione di network diverse, anche geograficamente distanti, possono utilizzare il medesimo server di web login. Così facendo, la personalizzazione della pagina web di login e l’accounting, avvengono in un posto solo invece che su di ogni gateway.
Ho intenzione di realizzare una struttura multigateway con il Captive Portal di ZeroShell. Qual è il numero massimo di captive gateway che possono fare riferimento allo stesso server di web login?
Teoricamente non vi è alcun limite al numero di gateway che possono essere serviti dallo stesso web login server. In pratica però, il limite dipende da molti fattori, tra cui: le performance dell’hardware dell’authentication server (*); da quanti client mediamente vengono gestiti dai vari captive gateway e da considerazioni di fault tolerance.Nota (*): si potrebbe facilmente cadere nell’errore, di considerare il carico di lavoro del server di web login molto inferiore di quello di un gateway, visto che il primo, dovrebbe soltanto fornire una pagina web di autenticazione e, successivamente, convalidare l’accesso in rete dell’utente. Apparentemente è un lavoro da poco. Tuttavia, le cose non vanno proprio in questo modo. Molti software, soprattutto quelli utilizzanti tecniche p2p, fanno un uso non standard delle porte TCP 80 e 443 nel tentativo di superare ad ogni costo eventuali firewall. Quale amministratore di rete, infatti, potrebbe mai chiudere in uscita le porte, su cui per default, è incapsulato il traffico del WWW? quasi sicuramente nessuno. Un esempio di tali software è Skype, il ben noto e più diffuso sistema di fonia VoIP: dopo aver tentato la connessione utilizzando come destinazione diverse porte TCP nel range 1-65535, tenta usando la porta 443 (https) e, se anche su questa dovesse fallirvi, utilizza la porta 80 (http). La procedura viene poi reiterata se anche quest’ultima non dà esito positivo. Il captive gateway, che non sa a priori che a generare traffico su tali porte non è un normale web browser, ma bensì Skype, forwarda comunque le richieste all’authentication server, il quale, a sua volta, inizialmente ignaro del fatto che non si tratta del protocollo http, è costretto ad elaborarle. La soluzione a questo problema, potrebbe essere quella di adottare sui gateway un firewall in layer 5, ovvero dei filtri sul contenuto trasportato nei pacchetti TCP, in modo tale da forwardare solamente quelle richieste che utilizzino realmente il protocollo http. ZeroShell non implementa tale caratteristica.
Quali sono le fonti di autenticazione utilizzate dal web login server del Captive Portal di ZeroShell per convalidare gli utenti?
L’authetication server del Captive Portal di ZeroShell può utilizzare come fonti di autenticazione: il server Kerberos v5 integrato per convalidare gli utenti locali; un server Kerberos 5 esterno per autenticare gli utenti di un altro realm, come per esempio, un dominio Microsoft Active Directory; la cross autenticazione tra realm Kerberos v5 per autenticare gli utenti di un dominio esterno con il quale ci sia una relazione di fiducia con il realm locale.
Il Captive Portal di ZeroShell può utilizzare come fonte di autenticazione un server RADIUS?
Dalla versione 1.0.beta6 di ZeroShell, il Captive Portal può usare, oltre all’autenticazione Kerberos 5, anche l’autenticazione RADIUS utilizzando il server locale come proxy verso altri server RADIUS configurati.
Il Captive Portal di ZeroShell può utilizzare più fonti di autenticazione contemporaneamente?
Sì può farlo. L’utente dovrà scegliere, nella pagina di web login, il dominio a cui appartiene. In base a tale scelta, il web login server sarà in grado di contattare l’authentication provider corretto. La scelta del dominio può avvenire o mediante una casella di scelta o utilizzando uno username nella forma username@DOMINIO.
Temo che un impostore, effettuando uno spoofing di indirizzo IP, possa sostituire il web login server con uno fasullo ed ingannare i gateway facendogli autorizzare client che non dovrebbero esserlo. Con il Captive Portal di ZeroShell esiste questo pericolo?
No, non esiste questo pericolo poiché il web login server e i captive gateway, che fanno parte della stessa infrastruttura, condividono un segreto (lo Shared Secret da configurare a cura dell’amministratore). Dopo che il web login server autentica l’utente attraverso Kerberos 5 o RADIUS, risponde al gateway attraverso un pacchetto criptato con AES256 utilizzando come chiave lo shared secret. Tale pacchetto, denominato Authenticator, contiene lo username completo del dominio, l’indirizzo IP del client e il timestamp del server. Quando il captive gateway riceve la risposta, deve riuscire a decriptare l’authenticator in modo da potervi leggere lo username e l’IP per il quale aprire la connessione. Ma se l’authentication server fosse fasullo, la chiave non corrisponderebbe a quella usata per criptare l’authenticator e il gateway riterrebbe il server non autorevole. Si noti, che l’autheticator ha un tempo di vita molto breve per evitare che durante l’attraversamento della rete possa essere catturato da un impostore e riutilizzato, abusivamente, per aprire una connessione. Ciò implica, che affinché l’infrastruttura di Captive Portal funzioni correttamente, gli orologi di sistema del web login server e dei gateway devono essere sincronizzati entro una certa tolleranza. È vivamente perciò consigliato l’utilizzo del protocollo NTP (Network Time Protocol).
Quando mi autentico con il Captive Portal di ZeroShell, subito dopo aver inserito username e password e premuto il bottone di accesso alla rete, contemporaneamente al popup per il controllo della connessione, il browser mi avverte che i miei dati viaggeranno in chiaro sulla rete e ci potrebbero pertanto essere problemi di sicurezza. Mi devo preoccupare? davvero le mie credenziale passano in chiaro sulla rete?
Assolutamente non preoccuparti per un tale messaggio da parte del browser. Lo username e la password che hai digitato passano in un tunnel criptato con SSL grazie all’utilizzo di richieste https. Quando invece il web login server ti ha già autenticato la sessione ritorna in chiaro e i dati a cui il browser fa riferimento non sono altro che l’authenticator che, creato dall’authentication server, deve transitare verso il gateway. Ma l’authenticator è già cifrato con AES256, sarebbe pertanto inutile usare un’ulteriore cifratura tramite SSL.
Ma se un impostore catturasse l’authenticator sulla rete e, senza decriptarlo, lo spedisse così come è al captive gateway, otterrebbe illegittimamente accesso alla rete?
Non è così semplice come sembra. L’impostore, una volta sniffato l’authenticator, prima di poterlo utilizzare, dovrebbe aspettare che il client legittimo abbandoni la rete. Si cambierebbe poi l’IP e il MAC address facendoli coincidere con quelli del client che se ne andato e finalmente invierebbe l’authenticator al gateway aspettando che quest’ultimo gli accordi la connessione. In realtà aspetterà invano per due motivi: l’authenticator ha una durata limitata nel tempo e quasi sicuramente, al momento dell’utilizzo da parte dell’impostore, sarà già scaduto; il captive gateway è in grado di ricordare gli autenticatori già utilizzati per accordare una connessione e non concede l’accesso se si tratta di una replica.
Perchè affinché il Captive Portal mantenga attiva la connessione l’utente non deve chiudere la finestra popup di controllo?
Perché tale finestra, oltre a permettere la disconessione forzata da parte dell’utente, garantisce il continuo rinnovo dell’authenticator prima della sua scadenza. Se la finestra viene chiusa, il gateway, che non vedrà più giungere alcuna richiesta di rinnovo, deciderà di chiudere la connessione al client.
Come sarà probabilmente già evidente, affinché un gateway rinnovi un autenticatore, quest’ultimo deve essere ancora valido. Il rinnovo consiste perciò, nel prolungamento del tempo di vita di un authenticator non ancora scaduto.
I captive gateway possono funzionare in Routed Mode o in Bridged Mode. Cosa significa?
In Routed Mode il captive gateway deve funzionare da router IP ed essere configurato come default gateway su ogni client che si associa alla rete Wireless. Per questo motivo, la subnet IP per la parte di LAN WiFi è diversa da quella presente sul resto della rete.
In Bridged Mode invece, il gateway è un bridge in layer 2 che unisce il segmento di LAN protetta al resto della rete. Il vantaggio più evidente di questa modalità, consiste nel poter assegnare ai client gli stessi indirizzi IP indipendentemente se ci si trova sul WI-FI o sulla wired LAN. È ovvio poi, che non solo il protocollo IP può transitare da una parte all’altra, ma anche qualsiasi altro protocollo incapsulato nelle trame ethernet. In particolare, se si tiene conto che in bridged mode anche il broadcast di livello 2 è forwardato, si deduce che sulla rete Wi-Fi non bisogna attivare un dhcp server per l’assegnazione degli indirizzi, ma, si può eventualmente sfruttare quello presente sul resto della LAN.
Il Captive Portal di ZeroShell può autenticare mediante certificati digitali X.509?
A partire dalla release 1.0.beta6, sulla pagina di web login, compare un pulsante X.509 che permette, all’utente che ha una chiave privata ed il relativo certificato X.509 riconosciuto dalle Trusted CAs abilitate, di accedere alla rete senza digitare username e password. Ovviamente si possono utilizzare le Smart Card per registrare chiave privata e certificato.