Captive Portal per l'autorizzazione negli HotSpot

In alcune circostanze, l'uso di tecniche di protezione del Layer 2, come WPA e WPA2 sono inapplicabili a causa della loro non semplice configurabilità per l'utente finale. D'altra parte, la loro applicabilità è subordinata all'utilizzo di hardware (accesspoint e schede di rete) e di sistemi operativi che supportino tali protocolli. Spesso poi, è necessario un sistema di protezione degli accessi indipendente dal mezzo trasmissivo sia esso wireless che cablato. La soluzione a questi problemi può essere quella di spostare il controllo degli accessi dal Layer 2 al Layer 3, cioè a livello di protocollo IP.

Premesso ciò, nell'ipotesi che non sia necessario criptare il traffico di rete, ma sia sufficiente garantire accesso autenticato, si può usare la tecnica del Captive Portal, che consiste nell'autenticare gli utenti mediante l'immissione delle credenziali (username e password o certificati digitali) nel loro web browser. I luoghi dove più spesso si fa uso di questa modalità di accesso sono gli Hotel, gli Hotspot e più in generale i luoghi dove si deve dare accesso a Internet in maniera non indiscriminata o si abbiano esigenze di contabilizzazione del traffico o del tempo di accesso.

La realizzazione di un Captive Portal avviene mediante l'utilizzo di un gateway che funge da default router per la zona da proteggere. Tale gateway blocca il traffico IP diretto verso l'esterno mentre "cattura" qualsiasi richiesta http o https diretta alle porte TCP 80 e 443 e la redirige verso un web server (in seguito lo chiameremo Authentication Server) che presenta all'utente una pagina di autenticazione in cui inserire le credenziali. Se l'utente ha le credenziali corrette, l'Autentication Server comunica al gateway che l'host è autorizzato e vengono rimossi i filtri per il traffico di quel client.

Si noti che l'Authentication Server puo' coincidere o meno con il gateway. Più in generale, si può realizzare uno scenario in cui un Authentication Server autentica le richieste provenienti da più captive gateway posti a protezione di diverse reti.

ZeroShell implementa sia le funzionalità di Authentication Server che di captive gateway in maniera nativa, senza fare uso di altri software per Captive Portal come per esempio NoCatAuth, NoCatSplash o Chillispot.

Di seguito sono elencate le caratteristiche del captive portal di ZeroShell:

• Permette di realizzare una struttura multigateway in cui un unico Authentication Server può fornire il weblogin per più gateway. Authentication Server e gateway possono eventualmente coesistere sulla stessa macchina;
• I Captive Gateway possono funzionare sia in routed mode che in bridged mode (o transparent mode):
  • In routed mode il gateway deve necessariamente essere il default router per la subnet da proteggere con Captive Portal. In questo modo solo il traffico IP può transitare da una rete all'altra se avviene l'autenticazione, mentre gli altri protocolli che poggiano direttamente sul layer 2 come IPX, Appletalk, Netbeui così come i messaggi in broadcast di livello 2 rimangono isolati;
  • In bridged mode invece, il Captive Gateway funziona da bridge su 2 o più interfacce di rete (anche VPN site-to-site) di cui una protetta da weblogin. In questa modalità qualsiasi tipo di protocollo e il broadcast possono transitare, se l'autenticazione ha esito positivo, attraverso il gateway. In bridged mode (o transparent mode) la rete protetta può condividere con il resto della rete la subnet IP, il default router e il server DHCP consentendo ad un client di ottenere sempre lo stesso indirizzo IP indipendentemente dal posto in cui accede;
• il Captive Portal può essere attivato anche su di una particolare VLAN 802.1Q invece che direttamente su di un'interfaccia;
• tutte le interazioni tra il web browser del client e l'Authentication Server avvengono criptate in https in maniera da evitare che le credenziali possano essere catturate sulla rete;
• i client vengono identificati dalla coppia IP e MAC address. Tuttavia, tenuto conto che questi due parametri possono facilmente essere falsificati, il Captive Gateway richiede che il client possieda nel suo browser un authenticator, cioè un pacchetto criptato, generato dall'Authentication Server e che periodicamente deve essere rinnovato prima che scada e inviato al gateway affinché questo lasci la connessione con l'esterno attiva. Tale authenticator, che viaggia in HTTPS ed è ulteriormente criptato con AES256 non potrà essere facilmente falsificato da un impostore prima che scada. La validità dell'autenticatore può essere configurata dall'amministratore e varia da un minuto fino alla non scadenza. E' ovvio che la gestione dell'authenticator e trasparente all'utente finale del Captive Portal che può tranquillamente ignorarne l'esistenza.
• l'Authentication Server convalida le credenziali dell'utente basandosi sul database Kerberos 5 locale, su un server Kerberos 5 esterno o mediante cross autenticazione tra realm Kerberos. In particolare le ultime 2 possibilità permettono al captive portal di autenticare gli utenti di un dominio Windows Active Directory.
  Si noti poi che l'utente può inserire uno username del tipo Username@Dominio permettendo al Captive Portal di scegliere il server Kerberos da utilizzare basandosi sul Dominio di appartenenza dell'utente.
  Dalla versione 1.0.beta6 di ZeroShell è possibile autenticare gli utenti anche mediante server RADIUS esterni o tramite certificati digitali X.509. Quest'ultima caratteristica permette l'utilizzo di Smart Card per autenticarsi sulla LAN tramite web login.
• è possibile impostare un elenco di host che abbiano accesso all'esterno senza la necessità di autenticarsi; si pensi per esempio alle stampanti di rete, alle webcam o altri apparecchi che non hanno un web browser o comunque un utente che immetta le credenziali;
• è possibile definire una serie di servizi forniti da server all'esterno della rete protetta a cui i client possono accedere senza autenticazione;
• oltre alla possibilità di configurare l'aspetto della pagina di weblogin, è presente anche il supporto multilingua per l'inglese, l'italiano o una lingua custom in cui verrano visualizzati i messaggi all'utente che si vuole autenticare;
• dopo l'autenticazione viene visualizzata una finestra popup da cui l'utente controlla lo stato della connessione e da cui tramite un pulsante è possibile disconnettersi. Tale popup ha anche il compito di rinnovare periodicamente l'autenticatore e di spedirlo al gateway che altrimenti chiuderebbe automaticamente la connessione. Vista l'importanza di questa finestra, ZeroShell applica speciali tecniche per evitare che il sistema anti-popup, di cui buona parte dei moderni browser ne è dotata, possa bloccarne la comparsa causando la prematura interruzione della connessione;