Il fine di questo documento è la descrizione della realizzazione di un gateway per Hotspot Wi-Fi mediante l’uso di Zeroshell. Ci si soffermerà in particolar modo sulle modalità di autenticazione degli utenti (RADIUS, Kerberos 5 e con certificati digitali X.509) e sull’accounting RADIUS del traffico e del tempo di connessione. Si darà uno sguardo anche alla possibilità di ottenere un router Multi-WAN con bilanciamento e failover dei collegamenti Internet con funzionalità di Captive Portal.
Fig. 1 Rete in un hotspot router con Captive Portal
Il contenuto di questo documento è suddiviso nelle seguenti sezioni:
- Introduzione
- I nemici del Captive Portal
- Falsificazione (Spoofing) di IP e MAC address
- Denial of Service (DoS)
- Router o Bridge?
- Autenticazione degli utenti
- RADIUS (PAP, EAP-TTLS e PEAP)
- Kerberos 5 (Active Directory)
- Certificati Digitali X.509 (Smart Card)
- Shibboleth (IdP SAML 2.0)
- Contabilizzazione del tempo, del traffico e del costo di connessione
- Limiti di accesso alla rete
- Registrazione degli accessi e delle connessioni TCP/UDP nei log
- Load Balancing e Fault Tolerance delle connessioni Internet
Introduzione
Negli Hotspot, ovvero nei luoghi pubblici in cui si dà accesso ad Internet a utenti occasionali, è necessario per il gestore disporre di almeno alcune delle seguenti funzionalità:
- Autenticazione
- Registrazione degli accessi nei log;
- Accounting del traffico, del tempo e dei costi di connessione.
L’autenticazione,
ovvero la capacità di poter identificare univocamente l’utente per poi
autorizzarlo all’accesso alla rete, può avvenire mediante username e
password o tramite certificato digitale X.509 eventualmente memorizzato
su Smart Card.
Il log degli accessi è talvolta richiesto
per legge, poiché permette di risalire agli autori di attività
illecite. Si badi bene che per logging degli accessi non si intende la
registrazione degli URL o peggio dei contenuti a cui l’utente ha avuto
accesso, ma semplicemente l’annotazione della data e l’orario di inizio e
di fine delle connessioni a Internet di ogni utente e dell’indirizzo IP
associato al client (generalmente un PC portatile) da cui avviene il
collegamento.
L’accounting invece, oltre a tenere
traccia dell’inizio e della fine del collegamento, contabilizza il tempo
e il traffico di connessione relativo ad un utente. Spesso il fine
dell’accounting è quello di permettere la tariffazione del traffico con
costi per Megabyte di traffico generato o per minuto di collegamento.
Inoltre, tramite l’accounting, si possono impostare dei limiti al
traffico e al tempo oltre i quali l’utente viene disconnesso dalla rete.
In particolare, l’accounting può permettere la gestione di connessioni
prepagate in cui l’utente per poter essere in linea deve disporre di un
credito.
Per ottenere tali funzionalità si utilizzano una o entrambi le seguenti modalità di accesso:
- Autenticazione e cifratura del traffico tramite WPA/WPA2 Enterprise
- Captive Portal
WPA/WPA2
Enterprise prevede che gli Access Point Wi-Fi associno un client solo se
l’utente ha delle credenziali valide verificate mediante un server
RADIUS con protocollo 802.1x. Oltre all’autenticazione, è garantita
anche la cifratura del traffico tra client ed Access Point.
Nel caso di accesso mediante Captive
Portal invece, gli Access Point vengono programmati in modalità aperta,
cioè senza alcuna autenticazione e cifratura. Il client si può associare
liberamente e riceve immediatamente un indirizzo IP dal server DHCP.
Tuttavia, il Gateway di Accesso a Internet blocca la comunicazione con
l’esterno e redirige qualsiasi richiesta Web (http e https) verso un
portale di autenticazione.
Appare subito evidente che WPA/WPA2 Enterprise è un sistema più robusto dal punto di vista della sicurezza rispetto al Captive Portal, ma d’altra parte, richiede che l’utente configuri il suo client (supplicant) per autenticarsi via 802.1x. Tale configurazione non è facile per gli utenti occasionali di un Hotspot ed per questo, che nella maggior parte dei casi, si preferisce dare accesso mediante Captive Portal che non richiede alcuna configurazione sul dispositivo portatile.
Configurazione del Captive Portal Gateway
Alcuni Access Point Wireless implementano internamente un Captive Portal, ma spesso questo è poco configurabile ed adattabile all’esigenze di un Hotspot. Risulta invece più flessibile e conveniente utilizzare degli Access Point economici, senza alcuna caratteristica avanzata e demandare la funzione di Captive Portal ad un router che funge da gateway verso Internet così come illustrato nella figura 1.
I nemici del Captive Portal
La semplicità nell’uso di un Captive Portal anche da parte di un utente inesperto è dovuta soprattutto al fatto che l’accesso al livello 2 della rete, sia che si tratti di wireless che di rete cablata, è aperto (cioè privo di autenticazione). Il client appena si associa alla rete ottiene subito un IP dal server DHCP e comunica in maniera non criptata. La contropartita di tale semplicità si traduce in un’intrinseca debolezza dal punto di vista della sicurezza. Vedremo nei due successivi paragrafi come Zeroshell tenti di mitigare tale debolezza.
Falsificazione (Spoofing) di IP e MAC address
Il
problema di sicurezza più sentito quando si parla di Captive Portal è lo
spoofing dell’indirizzo IP e del MAC address della scheda di rete.
Infatti, il firewall del Captive Portal sblocca i client autenticati
identificandoli tramite l’indirizzo IP e il MAC address (quest’ultimo
solo nel caso che il captive portal sia direttamente connesso a livello 2
alla rete da proteggere, cioè senza che ci siano router in mezzo).
Purtroppo questi 2 parametri possono essere impostati con estrema
facilità su qualsiasi Sistema Operativo e perciò, esiste il rischio che
qualcuno catturi il traffico con uno sniffer alla ricerca di un client
già autenticato e si imposti gli stessi IP e MAC address. Ciò
perturberebbe la comunicazione del client legittimamente autenticato
che, notando una bassa qualità della connessione, rinuncerebbe all’uso
della rete lasciando campo libero all’impostore.
Il problema è aggravato dal fatto che la
maggior parte delle implementazioni di Captive Portal, mantengono un
client autenticato e quindi connesso finché questo è visibile in rete
senza che il client partecipi attivamente al rinnovo
dell’autenticazione. Alcune implementazioni controllano l’ARP table per
vedere se il client ha effettuato traffico di recente oppure effettuano
un ARP Request per verificare la presenza in rete dell’IP. Altre
utilizzano la tabella dei leases del DHCP server, controllando se il
client ha richiesto il rinnovo di recente. Tali soluzioni sono
chiaramente insicure, poiché il client ha un ruolo passivo nel
riaccreditamento dell’autenticazione.
La soluzione adottata da Zeroshell è
invece quella di far si che sia il client stesso a richiedere al Captive
Portal gateway il rinnovo dell’autenticazione, presentandogli un
pacchetto criptato con AES256, denominato Authenticator.
Quest’ultimo è un segreto condiviso soltanto dal client e dal Captive
Portal (viaggia infatti in tunnel SSL e perciò non può essere catturato
con uno sniffer) e pertanto anche se qualcuno imposta l’IP e il MAC
address di un utente autenticato, non disporrà dell’Authenticator con
cui richiedere al Captive Portal il rinnovo dell’autenticazione.
L’Authenticator viene memorizzato dal client all’interno di una finestra
popup denominata Network Access che si occupa mediante Java Script di spedirlo al Captive Portal per il rinnovo.
Network Access Popup
La finestra di Popup svolge anche altre funzioni come quella di permettere all’utente di disconnetersi e di visualizzare utili informazioni di accounting come il tempo, il traffico e il costo di connessione. È da notare che tale finestra non viene bloccata dai sistemi anti-popup di cui quasi ogni browser web è dotato poiché viene aperta in maniera sincrona alla richiesta di autenticazione dell’utente. D’altra parte però, la finestra di Popup ha causato diversi problemi con l’avvento dei dispositivi Mobile quali gli IPhone, gli iPad e altri cellulari e palmari (Android e Windows Mobile inclusi) che non avendo un sistema multitasking effettivo dimenticavano di rinnovare l’autenticazione causando la chiusura della connessione. Per ovviare a tale problema, a partire dalla release 1.0.beta15 di Zeroshell i dispositivi Mobile vengono riconosciuti dal Captive Portal che non gli impone il rinnovo dell’autenticazione mediante l’invio dell’Authenticator, ma semplicemente verificandone la presenza in rete.
Configurazione di Smartphone e dispositivi Mobile
Denial of Service (DoS)
Alcuni
software, nel tentativo di comunicare con l’esterno a tutti i costi,
dopo aver tentato la comunicazione sulle porte TCP/UDP a loro assegnate,
provano la connessione sulle porte TCP 80 e 443 sapendo che
difficilmente un amministratore di rete le chiuderebbe in uscita
impedendo così la navigazione http/https e quindi l’accesso al web.
L’esempio più noto di tale categoria di programmi è il client VoIP di
Skype, ma molti altri sistemi P2P e worm fanno altro e tanto. Si
intuisce subito che quando un utente con il suo client si associa alla
rete, ma non si autentica subito tramite il Captive Portal, tali
richieste sulle porte 80 e 443 TCP vengono redirette verso il portale di
autenticazione che cercherebbe invano di servirle visto che il traffico
non è HTTP. È ovvio, che all’aumentare dei client non ancora
autenticati su cui girano i suddetti programmi, aumenta la probabilità
che si verifichi un DoS (Denial of Service) in cui il portale di
autenticazione è impegnato a servire richieste fasulle, non riuscendo a
gestire o a gestire con molta lentezza le richieste leggittime
provenienti dai browser web.
Zeroshell limita il verificarsi di
situazioni del genere implementando un sistema di DoS Protection che
usando il Netfilter di Linux limita il numero massimo di redirect per
minuto. Il livello di protezione può essere impostato su tre livelli
(Low, Medium e High).
Captive Portal Denial of Service Protection
Inoltre, i meccanismi di Auto-Update dei Sistemi Operativi e delle Signature degli Antivirus spesso utilizzano il protocollo http per comunicare con il repository di aggiornamento e perciò possono aggravare la situazione, facendo delle richieste che vanno ad aumentare il carico di lavoro del Captive Portal. Anche in questo caso Zeroshell cerca di arginare il problema intercettando le richieste verso i piu’ comuni repository di aggiornamento evitandone l’inutile redirect verso la pagina di autenticazione del Captive Portal.
Router o Bridge?
Nella figura 1 il Captive Portal lavora come router di livello 3 connesso direttamente ad un modem con cui si collega ad Internet. Esso agisce come default gateway per i client che si connettono alla rete. In questa configurazione, detta in Routed Mode, conviene far svolgere al router anche la funzione di DHCP e DNS server.
Il Captive Portal di Zeroshell può lavorare anche nella modalità detta in Bridge Mode, in cui la rete da proteggere con il Captive Portal condivide la stessa subnet IP del resto della LAN. Pertanto, un client prende lo stesso indirizzo IP sia se si connette da una parte che dall’altra ed ha il medesimo default gateway che è un router a monte del Captive Portal. In questo caso, anche DHCP e DNS da utilizzare per la parte Hotspot possono essere gli stessi che si usano per il resto della LAN.
Nelle precedenti versioni di Zeroshell si doveva dichiarare esplicitamente la modalità di funzionamento del Captive Portal. Dalla release 1.0.beta15, invece, ci sono 2 novità a riguardo:
- Viene gestita la modalità MULTI in cui si possono dichiarare più interfacce di rete su cui attivare il Captive Portal. Come si vede nella figura il Captive Portal può essere attivato anche sulle VLAN 802.1q (Tagged Virtual LAN);
- Zeroshell sceglie la modalità bridge o router automaticamente controllando se un’interfaccia fa parte o meno di un bridge.
Mettendo insieme le due novità, si deduce che il Captive Portal di Zeroshell può lavorare sullo stesso box hardware contemporaneamente come router per alcuni segmenti di LAN e come bridge per altri.
Captive Portal su più interfacce di rete
Autenticazione degli utenti
Il Captive
Portal di Zeroshell può utilizzare diverse fonti di autenticazione
anche contemporaneamente. Per default, autentica gli utenti utilizzando
il suo KDC Kerberos 5 interno che contiene i principal relativi agli
utenti archiviati nella Directory LDAP e gestiti mediante l’interfaccia
web. Tuttavia, possono essere utilizzate fonti esterne di autenticazione
quali REALM Kerberos 5, server RADIUS e Identity Provider SAML 2.
Inoltre, è disponibile anche il login mediante Certificati Digitali
X.509 che permetterebbe l’accesso tramite Smart Card o Token USB.
Nel caso di autenticazione RADIUS o
Kerberos 5 gli utenti possono provenire da domini diversi. In tal caso,
l’utente deve selezionare il dominio di autenticazione mediante la
casella di selezione presente nella pagina di accesso oppure
qualificando il suo username mediante il suffisso @dominio (per esempio
pluto@example.com).
Domini autorizzati nella configurazione dell’autenticazione del Captive Portal
RADIUS (PAP, EAP-TTLS e PEAP)
L’autenticazione RADIUS è tra i protocolli più utilizzati per il riconoscimento degli utenti su dispositivi di rete quali per esempio Access Point Wireless o Switch che permettano l’accesso al layer 2 solo dopo che l’autenticazione abbia avuto successo. Il Captive Portal di Zeroshell permette l’autenticazione RADIUS verso server esterni tramite richieste proxy. In altre parole, il captive portal richiede l’autenticazione al suo server FreeRADIUS interno che, se si accorge di non essere autoritario per il dominio a cui l’utente appartiene, inoltra la richiesta di autenticazione al RADIUS server competente. Chiaramente tale server RADIUS esterno deve essere configurato nella lista dei server proxy specificando lo Shared Secret. D’altra parte, anche sul RADIUS server esterno bisogna aggiungere una entry tra i client RADIUS per abilitare l’indirizzo IP del Captive Portal utilizzando lo stesso Shared Secret. Nella lista dei proxy radius è possibile aggiungere il server RADIUS di DEFAULT che viene utilizzato qualora nessuno degli altri server è autoritario per autenticare l’utente. Il proxy radius di default viene spesso utilizzato anche quando il captive portal deve autenticare verso una gerarchia di server RADIUS.
Fig.2 Hotspot distribuiti con server RADIUS di autenticazione/accounting centralizzato
Il captive portal può effettuare richieste di autenticazione PAP o 802.1x (EAP-TTLS con PAP e PEAP con MsCHAPv2). In quest’ultimo caso, il captive portal appare al server RADIUS come il supplicant di un dispositivo Wi-Fi che tenta l’accesso tramite WPA/WPA2 Enterprise. L’utilizzo di 802.1x è consigliato rispetto al semplice PAP qualora sia necessario un livello di sicurezza maggiore, garantito dal protocollo TLS di cui sia EAP-TTLS che PEAP (Protect EAP) si avvalgono.
Kerberos 5 (Active directory)
L’autenticazione Kerberos 5 permette di interfacciare il Captive Portal ad un dominio Windows Active Directory. Infatti, ogni Windows Server che sia un controller di dominio ha un KDC Kerberos 5 che autentica gli utenti appartenenti al dominio Active Directory di cui fa parte. Pertanto, basta aggiungere tra i domini autorizzati all’accesso al captive portal il nome del dominio Active Directory per permettere agli utenti Windows di accedere alla rete. Si noti che qualora non è attiva la funzionalità di discovery del REALM e dei KDC tramite i record SRV del DNS è necessario specificare manualmente gli indirizzi IP (o gli hostname FQDN) dei KDC autoritari per il REALM.
Configurazione dei Realm Kerberos 5 esterni
In alcune situazioni è opportuno autorizzare l’accesso tramite Captive Portal soltando ad un gruppo di utenti. Ciò non è possibile mediante Kerberos 5 poiché quest’ultimo gestisce solo l’autenticazione di Active Directory, mentre l’autorizzazione è demandata ad LDAP. Tuttavia, si può attivare sui controllori di dominio lo IAS (il Servizio RADIUS di Active Directory) e configurare il Captive Portal per autenticare verso RADIUS. In questo caso, si può configurare IAS per autorizzare solo gli utenti che appartengano ad un determinato gruppo.
Certificati Digitali X.509 (Smart Card)
L’autenticazione tramite certificati digitali X.509 permette il login senza dover digitare username e password. In altre parole, ogni utente che deve accedere alla rete deve possedere un certificato personale con la relativa chiave privata caricato nel browser web. Premendo il tasto [X.509] presente nel portale di autenticazione, se il certificato è firmato da una delle Autorità di Certificazione configurate all’interno del captive portal, l’utente ha accesso alla rete. L’utilizzo dei certificati digitali è spesso legato a quello delle Smart Card o dei Token USB. Questi dispositivi infatti, possono custodire il certificato digitale in maniera estremamente sicura poiché, la chiave privata non può essere estratta con un’operazione di lettura dall’esterno. Le Smart Card sono perciò dotate di un loro chip che effettua le operazioni di cifratura e decifratura richieste tramite API. Per sbloccare l’utilizzo della chiave privata da parte del browser la Smart Card richiede la digitazione di un PIN che contribuisce ad aumentarne la sicurezza qualora la carta sia smarrita.
Shibboleth (IdP SAML 2.0)
Tramite
Shibboleth Service Provider, il Captive Portal di Zeroshell permette
l’autenticazione degli utenti verso un Identity Provider SAML 2. Ciò è
spesso utilizzato nelle federazioni in cui ogni membro di una
federazione implementa un IdP per il riconoscimento degli utenti oltre a
diversi servizi web (Service Provider). Tra questi servizi si può
includere l’accesso alla rete Wi-Fi, in cui, l’utente viene rediretto
verso il WAYF/DS da cui seleziona l’Identity Provider che lo può
autenticare. Si potrebbe obiettare che anche legando il captive portal
ad una gerarchia di server RADIUS (tipo EDUROAM per quel che riguarda le
Università e gli Enti di Ricerca) si otterrebbe l’accesso federato alla
rete. Tuttavia, mentre nel caso di 802.1x si ha la cosiddetta
autenticazione End-to-End anche attraversando la gerarchia di server
RADIUS, con il captive portal ciò non è garantito. Per questo è
preferibile utilizzare SAML, in cui invece, le credenziali viaggiano,
partendo dal browser dell’utente fino al’IdP autoritario per la sua
autenticazione, sempre all’interno dello stesso tunnel cifrato con SSL,
garantendo perciò l’autenticazione End-to-End.
Per maggiori dettagli sull’uso del Captive Portal con Shibboleth è disponibile il documento Configurare il Captive Portal per autenticare gli utenti mediante Shibboleth.
Contabilizzazione del tempo, del traffico e del costo di connessione
L’accounting permette di conoscere, per ogni utente, il tempo, il traffico e il costo delle sue connessioni. Il Captive Portal di Zeroshell utilizza RADIUS per trasmettere tali informazioni ed è pertanto possibile utilizzare un server esterno che supporti l’accounting via RADIUS oppure Zeroshell stesso. Così come per l’autenticazione, anche per l’accounting si può centralizzarne la gestione su di unico server RADIUS che raccolga le informazioni provenienti da più Hotspot. Si noti peraltro, che il sistema di accounting di Zeroshell può, proprio perché rispetta lo standard RADIUS, raccogliere sia le informazione dai Captive Portal, sia direttamente dagli Access Point Wi-Fi che utilizzino WPA/WAP2 Enterprise mediante 802.1x.
Gestione accounting RADIUS
Dettagli di connessione di un utente
Limiti di accesso alla rete
Tramite l’accounting RADIUS è possibile anche impostare dei limiti di connessione per gli utenti. Per far ciò è sufficiente assegnare gli utenti ad una classe di accounting a cui si attribuiscono i seguenti parametri:
- Tipo di pagamento (Prepagato e postpagato)
- Costo per Megabyte di traffico
- Costo orario della connessione
- Limite massimo di traffico generato (in entrata e in uscita) in Megabyte
- Limite orario di connessione
Configurazione dei limiti di accesso alla rete
Registrazione degli accessi e delle connessioni TCP/UDP nei log
Benché già l’accounting mantiene traccia delle connessioni degli utenti alla rete è possibile avere maggiori dettagli sull’autenticazione degli utenti consultando i messaggi di log del Captive Portal.
Messaggi di log del Captive Portal
Peraltro,
soprattutto se i client del Captive Portal utilizzano indirizzi IP
privati, può essere utile tenere traccia delle connessioni TCP e UDP che
vengono stabilite con server esterni. Infatti, poiché il captive portal
per far comunicare con la WAN gli indirizzi privati deve eseguire il
NAT (Network Address Translation), tutte le connessioni risultano
generate dall’indirizzo IP pubblico del router.
Il Connection Tracking va abilitato
esplicitamente ed è raccomandato valutare, prima di abilitarlo, quanto
il suo utilizzo sia consentito dalle leggi sulla privacy, tenuto conto
del fatto che esso non permette di risalire ai contenuti delle
comunicazioni degli utenti, ma soltanto a determinare quali server sono
stati contattati.
Registrazione nei log delle connessioni TCP/UDP
Load Balancing e Fault Tolerance delle connessioni Internet
Allo scopo
di garantire una banda di accesso ad Internet adeguata e stabile è
possibile attivare il Load Balancing e il Fault Tolerance dei
collegamenti WAN. Zeroshell può lavorare in due modalità denominate Failover e Load Balancing and Failover.
Nel primo caso tutto il traffico viene instradato dal collegamento più
efficiente, mentre gli altri collegamenti sono di riserva e subentrano
solo in caso di guasto di quello attivo. Nella modalità Load Balancing and Failover,
invece, tutte le connessioni sono contemporaneamente attive e il
traffico viene smistato ciclicamente su di esse. Anche in quest’ultimo
caso viene garantita la tolleranza ai guasti, poiché, qualora un dei
collegamenti risulti inaccessibile viene automaticamente escluso dal
bilanciamento automatico finché non ritorna accessibile.
Inoltre, è possibile bilanciare il
traffico anche manualmente. Per esempio, si può decidere che il traffico
VoIP sia instradato tutto da un link, mentre quello generato dal
trasferimento di file da un altro. Così facendo si evita di saturare il
link VoIP che produrrebbe disturbi nella voce. Per maggiori dettagli è
possibile consultare il documento Incremento della banda di connessione a Internet con bilanciamento del traffico e gestione dei guasti.