ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth una interfaccia per il Captive Portal

      Cosa è?
      Screenshots
      Licenza
      Annunci
      Mailing List
      Forum
      English Forum
      Documentazione
      FAQ
      Hardware
      Download
      Update On-line
      Kerberos Tutorial  
      Note Legali
      Contattami


  Più in dettaglio:
      Hotspot Router
      Accounting
      Shibboleth SP
      Grafici e Prestazioni
      Net Balancer
      Router UMTS
      Proxy con Antivirus
      Filtri Web
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS e LDAP
      Certificati X.509
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional




Hotspot router per l'accesso alla rete

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.

Rete in un Hotspot con Router Captive Portal
Fig.1 Rete in un Hotspot con Router Captive Portal



Il contenuto di questo documento è suddiviso nelle seguenti sezioni:

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à:
  1. Autenticazione
  2. Registrazione degli accessi nei log;
  3. 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
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
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
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
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:
  1. 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);
  2. 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 piu' interfacce di rete
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
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.

Hotspot distribuiti con server RADIUS di autenticazione/accounting centralizzato
Fig.3 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
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
Gestione accounting RADIUS




Dettagli di connessione di un utente
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
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
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
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.



    Copyright (C) 2005-2013 by Fulvio Ricciardi