Sviluppo di un sistema a supporto del WiFi-Sharing

UNIVERSITÀ DEGLI STUDI DELLA CALABRIA
FACOLTÀ DI INGEGNERIA DELLE TELECOMUNICAZIONI
ANNO ACCADEMICO 2007/2008
Docente: Prof. Emanuele Viterbo
Tutor: Prof. Gianluca Aloi
*****
Laboratorio di Reti di Telecomunicazioni
*****
Sviluppo di un sistema a
supporto del WiFi-Sharing
STUDENTE
Belcastro Cristian
113511
Ciano Maurizio
111932
Daniele Paolo
113475
Gaetano Domenico
110888
Sommario
Introduzione ...................................................................................................................................................... 3
Architettura ....................................................................................................................................................... 4
Linksys WRT54GL ............................................................................................................................................... 5
Analisi Firmware OpenSource ........................................................................................................................... 6
DD-WRT ......................................................................................................................................................... 6
OpenWrt ........................................................................................................................................................ 8
X-Wrt ............................................................................................................................................................. 8
CoovaAP......................................................................................................................................................... 8
Server AAA ....................................................................................................................................................... 10
Formato Pacchetto Radius .......................................................................................................................... 11
Scambio Messaggi con Radius ..................................................................................................................... 12
Chillispot .......................................................................................................................................................... 13
Database MySql ............................................................................................................................................... 15
Analisi del traffico ............................................................................................................................................ 19
Pricing .............................................................................................................................................................. 23
Implementazione ............................................................................................................................................. 25
Soluzione: Hotspot con Chillispot .................................................................................................................... 25
Soluzione: AAA con EAP................................................................................................................................... 26
Generazione Certificati X.509 ...................................................................................................................... 29
Conclusioni ...................................................................................................................................................... 31
Le due soluzioni a confronto ....................................................................................................................... 31
Bibliografia ....................................................................................................................................................... 32
Appendice A: HowTo ....................................................................................................................................... 33
2
Introduzione
L’obiettivo di questo progetto consiste nel realizzare e testare un sistema che fornisca la
possibilità di effettuare WiFI-Sharing tramite la realizzazione di un Hotspot e l’applicazione
di politiche di Pricing, il tutto in ottica OpenSource.
Si è inoltre prevista una variante del suddetto progetto dedicata allo sviluppo di
autenticazioni sicure, quindi andare ad autenticare non solo una macchina(tramite
indirizzo MAC), ma anche l’individuo(tramite certificato digitale X.509).
Sono state analizzate diverse tipologie di architetture, ognuna con i suoi pro e contro che
verranno descritte in seguito; questa analisi ha permesso di scegliere la soluzione più
adatta a quanto richiesto in fase di commissiona mento del lavoro.
Elemento chiave del progetto è proprio la parola OpenSource poiché si cerca di ottenere
risultati efficaci pur non utilizzando software commerciale: questo getta le basi per uno
sviluppo non solo dell’OpenSource, ma anche in ottica di sviluppo per paesi che non
hanno la possibilità di realizzare un’infrastruttura di rete fissa e quindi basarsi su
connessioni ad hoc tra vari computer indipendenti tra loro.
L’architettura si basa su due server, uno per l’AAA (Autenticazione, Autorizzazione ed
Accounting) ed uno per il monitoraggio del traffico di rete.
Per rendere possibile ciò si è reso necessario riscrivere il firmware di un router con uno di
tipo OpenSource per abilitare alcune funzioni altrimenti non accessibili: il router
considerato è un Linksys WRT54GL.
I sistemi operativi adottati per i due server necessari alla realizzazione dell’infrastruttura
sono di tipo Linux Ubuntu 7.10 Gutsy Gibbon; per il server di AAA è stato utilizzato
FreeRadius interfacciato con Database MySql, mentre per il server di monitoraggio del
traffico è stato utilizzato il software Ntop.
3
Architettura
L’architettura del sistema è mostrata nella seguente figura:
In realtà le architetture analizzate sono state molteplici, ma la scelta è ricaduta su questa
in quanto è la migliore in ottica di architettura distribuita: così facendo non si appesantisce
una sola macchina e la delegazione dei compiti a server diversi permette di gestire in
maniera ottima la sicurezza.
Inizialmente si era pensato di utilizzare il router solo come Access Point, delegando le
funzioni di Hotspot alla stessa macchina che effettuava l’AAA: questa scelta è stata
scartata in quanto così facendo si appesantiva notevolmente il lavoro di una sola
macchina.
Si è scelto di implementare l’Hotspot sul router e di lasciare al server solo il compito di
effettuare l’AAA degli utenti ed il billing. Il monitor del traffico di rete si è reso necessario
per garantire la compatibilità con il Decreto Pisanu del 16/08/05 in materia di “Misure di
preventiva acquisizione di dati anagrafici, dei soggetti che utilizzano postazioni pubbliche
non vigilate per comunicazioni telematiche: ovvero punti di accesso ad internet utilizzando
tecnologia senza fili”.
4
Linksys WRT54GL
Quasi tutti i firmware openSource (dd-wrt, OpenWrt, x-wrt) richiedono dei router con
almeno 4 MB di memoria flash e 16 MB di memoria RAM. La tendenza delle case
costruttrici è quella di diminuire la quantità di memoria flash e RAM nei loro dispositivi in
modo da impedire agli utenti di modificare il firmware proprietario.
Per questo motivo la scelta del router è caduta sul Linksys WRT54GL[1]. Il prodotto Linksys
è
basato
sul
sistema
operativo
Linux.
Per
minimizzare i costi la Linksys decise di realizzare il
firmware
dell'apparecchiatura
con
il
sistema
operativo Linux. I router di fascia SoHo vengono
realizzati implementando gran parte delle loro
funzioni a livello software mantenendo al minimo
l'hardware dedicato al fine di contenere i costi di
produzione.
Il Linksys WRT54GL è una release del 2005 nato
come evoluzione del WRT54G.
La seguente tabella mostra le caratteristiche delle
diverse versioni del router WRT54GL:
VERSION
CPU SPEED
RAM
FLASH
MEMORY
NOTE
1.0
200 MHz
16 MB
4 MB
Modello rilasciato dopo la
versione 5 del WRT54G.
1.1
200 MHz
16 MB
4 MB
Modello rilasciato nel
Giugno 2006.
Il router utilizzato è quello con la versione firmware 1.1.
5
Analisi Firmware OpenSource
DD-WRT
DD-WRT[2] è un firmware gratuito per alcuni router Wi-Fi, tra i cui la famiglia dei router
Linksys WRT54G, WRT54GL che funzionano su una versione minimalista di Linux. È
rilasciato sotto licenza GNU versione 2.
Le versioni di DD-WRT fino alla v22 sono basate sul firmware Alchemy della Sveasoft, che
a sua volta è basato sul firmware Linksys originale. Dalla versione v23 il firmware è stato
in gran parte riscritto. Le versioni più recenti di DD-WRT (attualmente è la v23)
rappresentano un progetto completamente nuovo.
Il firmware DD-WRT implementa diverse funzioni non gestite dalla versione originale
Linksys, tra queste ricordiamo: WDS, IPv6, QoS avanzato, RADIUS, controllo della
potenza radio, possibilità di overclocking.
Tra le altre funzionalità non presenti nel firmware originale Linksys, DD-WRT aggiunge il
Kai Daemon per Kai Console Gaming network, WDS wireless bridging/repeating protocol,
Autenticazione Radius per comunicazioni wireless più sicure, gestione avanzata del
Quality of Service per l'allocazione della banda, supporto software per l'utilizzo di SD-Card
(modifica hardware).
Le funzionalità principali di tale firmware sono:
•
Portale Hotspot (Chillispot)
•
Server PPTP VPN
•
2-way Bandwidth Management (incl. P2P, VoIP, IM)
•
SSH Client e Server (dropbear)
•
Telnet
•
Script di Startup, Firewall e Shutdown
•
Modalita` WDS Repeater
•
Client Mode (supporta client multipli)
•
Modalita` Adhoc
•
Routing OSPF
6
•
Routing RIP2
•
Funzione Power Boost (potenza max 251mW)
•
Selezione Antenna
•
Gestione DHCP statico
•
DDNS
•
Clonazione Wireless MAC Addresses
•
VLAN
•
WPA over WDS
•
WPA/TKIP con AES
•
WPA2
•
Client Mode WPA
•
Client Isolation Mode
•
Gestione della banda QoS
•
Port Triggering
•
Port Forwarding (max. 30 record)
•
Wake-On-Lan
•
Syslog remoto
•
Statistiche Ntop remote
•
Xbox Kaid
•
SNMP.
•
Supporto IPv6
•
Stato dei client wireless e WDS con uptime e utilizzazione processore
•
Site Survey
7
•
Server NTP Remoto
•
Style (GUI configurabile; v.23)
OpenWrt
OpenWrt[3] è un firmware basato su GNU/Linux specifico per dispositivi embedded basati
su chipset Broadcom come i router Wi-Fi prodotti, ad esempio, da Asus, Belkin, Dell,
Linksys, US Robotics e Viewsonic.
Ci sono due versioni di OpenWrt:
•
Whiterussian: più datata, ma più stabile. Il suo sviluppo si è fermato agli inizi del
2007.
•
Kamikaze: nuova versione. È basata su un differente design in modo da farla girare
su una grande gamma di dispositivi basati sui nuovi kernel. Kamikaze è stato
sviluppato dalla Whiterussian per provvedere a creare una piattaforma per codice
sperimentale. Infatti integra molti nuovi pacchetti, updates, bug fix e riscritture.
X-Wrt
X-Wrt[4] e’ un progetto finalizzato agli utenti meno esperti. Esso rappresenta una raccolta
di pacchetti e patches per invogliare gli utenti finali di OpenWrt. Esso non deriva da
OpenWrt, ma lavora in congiunzione con esso. X-Wrt è nato per estendere le funzionalità
di OpenWrt, come una console di web management(webif). Da tanto tempo si è
consolidata l’idea che OpenWrt è il firmware migliore nel proprio ambito. Infatti supera gli
altri firmware in performance, stabilità, estendibilità, robustezza e design. X-Wrt invece
assume una visione più pragmatica rispetto a OpenWrt, cioè si basa su un’idea più
concreta per la ricerca delle soluzioni, ed intende perfezionare il cuore del firmware.
CoovaAP
CoovaAP[5] è un progetto che ha come firmware di base OpenWrt aggiornato alla White
Russian versione 0.9c.
Anche questo, come il predecessore, è sviluppato per chipset Broadcom e quindi
pienamente compatibile con il router a nostra disposizione.
I vantaggi principali di questo firmware sono quelli attribuiti all’OpenWrt con l’aggiunta
della possibilità di interfacciamento con JRadius, in pratica la versione Java di FreeRadius.
Questa però rappresenta un’arma a doppio taglio in quanto il vantaggio di lavorare con
Java è sicuramente la semplicità di lettura del codice e quindi di configurazione dell’intero
sistema; lo svantaggio è dato dalla lentezza di Java, soprattutto in ottica di applicazioni
8
che richiedono una notevole velocità in termini di tempi di risposta, e dalle risorse che
vengono occupate sul sistema.
Un altro vantaggio del sistema è quello di vedere in tempo reale l’esecuzione
dell’applicazione selezionata (es. Chillispot, FreeRadius etc.) e di una gradevole
interfaccia grafica per gestire l’installazione dei plug-in del sistema.
Inoltre, questo tipo di firmware, una volta installato, prevede la possibilità di essere
rimpiazzato, ma solo con firmware di tipo OpenWrt con estensione .trx, difficili da reperire;
per poter sostituire questo firmware con un altro di prova è stato infatti necessario
utilizzare un client TFTP[6] e forzare quindi il flash della memoria (operazione più rischiosa
del semplice aggiornamento da browser).
Queste sono le versioni di firmware che sono state analizzate. Anche se tutte quante
derivano da OpenWrt, ognuna implementa delle caratteristiche differenti più o meno
vantaggiose e significative. La scelta finale è ricaduta su DD-WRT. OpenWrt non è
gestibile da interfaccia web e questo potrebbe creare problemi in ottica di management del
sistema; X-WRT è gestibile tramite interfaccia web, però si basa su una release di
OpenWrt datata e quindi i plug-in non sono recenti.
Complessivamente si è preferito puntare su DD-WRT in quanto rappresenta una soluzione
che appesantisce poco sia il router che le interazioni con i server di autenticazione e
monitoraggio.
DD-WRT invece presenta tutte le caratteristiche necessarie allo svolgimento del progetto,
compreso un supporto nativo per il sistema Ntop utilizzato per monitorare il traffico di rete.
Inoltre visto il ridotto spazio presente sul router si è preferito evitare di andare ad installare
altro software aggiuntivo che avrebbe appesantito.
9
Server AAA
Come server di AAA è stata utilizzata una macchina con sistema operativo Ubuntu 7.10
equipaggiata
aggiata inoltre di Apache, Php e MySql.
Questi software sono necessari per il corretto interfacciamento con il FreeRadius per la
gestione degli account utente.
Il servizio chiamato RADIUS (Remote Access Dial-In
Dial In User Service) consente
l’autenticazione, l’autorizzazione
torizzazione e l’accounting degli utenti.
•
Autenticazione:: è il processo che determina l’identità dell’utente che può avvenire o
mediante username e password o mediante altri mezzi quali Certificati Digitali o
Firme Digitali. Questo processo viene effettuato
effettuato mediante schemi quali :
o PAP (Password Authentication Protocol)
o CHAP (Challenge Handshake Autentication Protocol)
o EAP (Extensible Autentication Protocol)
•
Autorizzazione:: è il processo che determina a quali servizi può accedere un utente
e a quali gli è negato l’accesso. Questo processo viene fatto dopo l’autenticazione e
l’user ID dell’utente viene poi memorizzata in apposite strutture dati.
•
Accounting: è il processo che tiene traccia dell’uso della rete da parte dell’utente. Si
occupa di memorizzare la data, l’ora di inizio, la fine sessione ed il numero di byte
trasferiti.
10
Formato Pacchetto Radius
In figura viene mostrato e descritto il formato di un pacchetto Radius[7]
•
Code: un ottetto contenente le richieste/risposte di accesso
•
Identifier: un ottetto utilizzato per verificare la corrispondenza tra richieste e
risposte
•
Length: indica la lunghezza complessiva del pacchetto compresi tutti i campi
•
Authenticator: utilizzato per autenticare la risposta del server Radius
Nel pacchetto di richiesta di accesso il suo valore è un numero a caso di 16 ottetti detto
autenticatore di richiesta.
Questo numero, insieme a un valore segreto, viene elaborato con l’algoritmo MD5 per
creare un digest di 16 ottetti che viene poi mandato in XOR con la password immessa
dall’utente.
Il risultato è posizionato nell’attributo User-password all’interno del pacchetto di richiesta di
accesso.
11
Scambio Messaggi con Radius
Ecco un esempio di scambio di messaggi tra un Radius client ed un server[8].
La richiesta al server RADIUS da parte del client deve essere un segreto condiviso con il
server, in caso contrario la richiesta viene scartata. Una volta superato il controllo iniziale,
il server consulta un database che contiene informazioni necessarie per autenticare
l'utente. Se anche l'autenticazione è conforme a tutte le richieste, il server a quel punto
invia una risposta all'utente sotto forma di messaggio di risposta all'accesso. Il client a sua
volta può ritrasmettere la risposta all'utente sotto forma di un prompt e, in ogni caso deve
inviare di nuovo il messaggio di richiesta di accesso, con alcuni campi differenti, il
principale dei quale è una risposta crittografata alla risposta del server. In seguito
all'utente viene presentato un numero random e gli viene chiesto di crittografarlo e di
ritrasmettere il risultato della crittografia. Il server riceve ed esamina questo messaggio e,
se tutto quadra, invia un messaggio di accesso al client. Il protocollo RADIUS va
comunque molto al di là delle operazioni di supporto all'autenticazione, in quanto il
messaggio di accesso contiene informazioni di configurazione, quali PPP, lo user login
eccetera. Con il nodo RADIUS si vogliono fornire tutte le informazioni necessarie per
supportare la sessione in rete, per esempio un indirizzo IP per la sessione, servizi di
compressione, unità di trasmissione massima (MTU) eccetera. Il client NAS può
supportare i protocolli PAP e CHAP . In questo caso il client NAS invia ID e password PAP
nel messaggio di richiesta di accesso (precisamente nei campi user-name e password del
messaggio).
12
Chillispot
Chillispot[9] è un captive portal open source, o per meglio dire, un punto di controllo per gli
accessi ad una rete wireless LAN. Esso è usato per l’autenticazione degli utenti in una rete
wireless LAN.
Supporta login basata su web, che oggi rappresenta lo standard per
hotspot pubblici, autenticazione WISP “smart client” e, inoltre, accesso protetto Wi-Fi
(WPA e WPA2). Autenticazione, autorizzazione e accounting (AAA protocol) sono
controllati da un server radius (in remoto o in locale).
L’architettura riportata di seguito rappresenta un sistema Chillispot che comprende tutti gli
elementi caratteristici:
È possibile installare il radius ed il web server sulla stessa macchina di Chillispot oppure in
qualsiasi macchina esterna (wherever).
Chillispot supporta due metodi di autenticazione:
•
Universal Access Method (UAM)
•
Wireless Protected Access (WPA)
Tramite la UAM il client wireless richiede un indirizzo IP, ed esso è allocato da Chilli.
Quando gli utenti aprono un web browser, Chilli cattura la connessione TCP e reindirizza il
browser ad un web server di autenticazione. Quindi il web server analizza l’utente secondo
il suo username e password. La password è criptata e inviata indietro a Chilli.
L’autenticazione WPA è controllata dall’Access Point, e successivamente indirizzata
dall’Access Point a Chilli. Se si usa WPA la connessione tra Access Point e i client è
criptata. Per entrambe, UAM e WPA, Chilli instrada le richieste di autenticazione ad un
server radius. Il server radius invia un messaggio di access-accept indietro al Chilli se
l’autenticazione ha successo; altrimenti si invia un access-reject. Un autenticazione web
13
server è necessaria per poter autenticare gli utenti usando un metodo di accesso
universale. Per l’accesso a reti wireless protette questo web server non è necessario.
L’interfaccia di comunicazione al web server è implementata usando soltanto protocolli
http. Non servono chiamate all’indietro dal web server a Chilli per autenticare il client.
Questo significa che l’Hotspot può essere piazzato dietro un gateway NAT, un proxy o un
firewall, mentre il web server è localizzato nel dominio internet. È quindi necessario uno
script cgi per il web server capace di interrogare l’utente secondo username e password.
Una volta che questa informazione è inoltrata dall’utente la password criptata è mandata
dietro al Chilli che instrada la richiesta al server radius. Per garantire la sicurezza, la
connessione tra client e server viene cifrata tramite SSL.
I principali vantaggi ottenuti da Chillispot sono la stabilità, la portabilità
la scalabilità.
Chillispot è stato scritto in C per migliorare la portabilità alle altre piattaforme, la
concorrenza è implementata usando un singolo select () loop, per migliorare la portabilità
e, allo stesso tempo, aumentare il throughput. Un processo client è creato ogniqualvolta si
riceve una richiesta di autenticazione http da un client. Le applicazioni sono state
sviluppate solo in ambiente open source. Ciò garantisce portabilità a discapito delle
prestazioni, che possono essere migliorate implementando il piano utente nello spazio del
kernel.
14
Database MySql
In figura è mostrato il database MySql sul quale si appoggia il server Radius:
Le tabelle del Database sono descritte di seguito:
•
Nas: indica la presenza di eventuali server NAS (Network Authentication Server)
•
Pricing: indica la tariffa con la quale si collega l’utente
•
Radacct: è la tabella più importante insieme a radcheck in quanto in essa sono
memorizzati i dati di accounting di ogni utente (illustrati in seguito)
•
Radcheck: memorizza gli utenti del sistema
•
Radgroupcheck: effettua il check degli utenti in base al gruppo di appartenenza
(Admin, utenti semplici etc.)
•
Radgroupreply: indica i parametri che il server radius deve passare al gruppo
•
Radpostauth: indica eventuali parametri di post-autenticazione
•
Radreply: indica i parametri che vengono forniti agli utenti che si loggano al sistema
•
Usergroup: contiene i gruppi degli utenti
15
Di seguito è mostrata la struttura delle viste necessarie ad effettuare il billing:
Le viste, combinate con uno script in bash, permettono di effettuare periodicamente
l’aggiornamento del billing di ogni utente che si collega: lo script richiama in maniera
periodica (ogni 30 minuti) l’aggiornamento delle viste combinando alla perfezione il bash
con il MySql.
Le viste necessarie per effettuare queste operazioni di pricing sono:
•
UtentiTime: seleziona gli utenti connessi ed il relativo tempo di connessione;
•
UtentiByte: seleziona gli utenti connessi ed il traffico scambiato;
•
Billing: effettua il billing in base al tempo;
•
BillingByte: effettua il billing in base al traffico (generalmente Kbyte).
16
Viene mostrato adesso un esempio della tabella di accounting e vengono analizzati in
dettaglio i campi:
17
•
RadAcctId: identificatore univoco di ogni connessione;
•
AcctSessionId: identificatore univoco della sessione;
•
AcctUniqueId: identificatore univoco assegnato agli utenti che si collegano in una
sessione;
•
UserName: username dell’utente connesso;
•
NASIPAddress: eventuale indirizzo IP del NAS;
•
NASPortId: eventuale porta del NAS;
•
NASPortType: tipo di connessione che usa il client;
•
AcctStartTime: data ed ora di inizio accounting;
•
AcctStopTime: data ed ora di fine accounting;
•
AcctSessionTime: tempo complessivo della durata della connessione (in sec.);
•
AcctInputOctets: traffico in upload (bit);
•
AcctOutputOctets: traffico in download (bit);
•
CalledStationId: indirizzo MAC del server;
•
CallingStationId: indirizzo MAC del client;
•
AcctTerminateCause: causa della fine della sessione;
•
ServiceType: indica il tipo di servizio corrente;
•
FramedProtocol: indica se si usa un protocollo frammentato (es. PPP)
•
FramedIPAddress: IP del client richiedente;
•
AcctStartDealy: eventuale inizio ritardo accounting;
•
AcctStopDelay: eventuale fine ritardo accounting.
18
Analisi del traffico
Uno degli aspetti chiave per garantire l’affidabilità di un sistema informatico è il controllo
dell’infrastruttura di rete: attraverso il monitoraggio dei servizi e delle applicazioni è infatti
possibile prevenire anomalie e in caso di necessità minimizzare i tempi di intervento.
Inoltre per essere in regola con il decreto per la sicurezza vigente in Italia ovvero il Decreto
Legge del 27 Luglio 2005 n. 144 riguardante “Misure urgenti per il contrasto del terrorismo
internazionale” Art. 6 in materia di
telematico”
e Art.
“Nuove norme sui dati del traffico telefonico e
7 in materia di “Integrazione della disciplina amministrativa degli
esercizi pubblici di telefonia e internet” che regolamenta tra l’altro l’accesso ad Internet
tramite tecnologia senza fili, impone la necessità di tracciare tutto il traffico, in modo da
risalire ad eventuali abusi dell’utilizzo improprio e fraudolento della Rete[10].
Per affrontare questo problema esistono diversi tool proprietari che possono essere
acquistati, ma per rispettare la filosofia del progetto l’attenzione è stata focalizzata
principalmente su due programmi Open Source, che verrano valutati di seguito.
•
MRTG [11]
Molto probabilmente è il tool per l’analisi di rete più conosciuto e diffuso al mondo, il
suo lavoro consiste nel misurare il traffico e generare dei grafici relativi
all’occupazione della banda che possono essere analizzati comodamente tramite
un’interfaccia semplice ed intuitiva mediante un qualunque browser web (firefox,
opera, internet explorer), ma non offre la possibilità, senza l’utilizzo di un proxy, di
salvare i dati dei singoli siti visitati da ogni utente, e questo non rispetta le specifiche
di tracciabilità di si è parlato in precedenza.
•
Zabbix [12]
Questa soluzione nonostante sia molto giovane dispone di una buona comunità di
utenti ed è ben documentata, fornisce diversi tool grafici ed è molto semplice da
realizzare, purtroppo per un corretto funzionamento necessita un installazione di un
server SNMP su tutti i client e questo non va bene per i requisiti richiesti dal
progetto poiché tutti i client dovrebbero installare e configurare un software sulla
propria macchina.
19
•
Cacti [13]
raccoglie via SNMP i parametri in merito a diversi componenti del target e li
presenta sotto forma grafica, andamento attuale e andamento totale, ma non una
panoramica della rete, quindi è più indicato nel monitorare risorse precise come
host ed
ha inoltre bisogno del database e di una preconfigurazione prima di
utilizzarlo.
•
JFFNMS [14]
A differenza dei precedenti permette il salvare i dati anche su un server mySQL, ma
la gestione è risultata troppo onerosa e macchinosa poiché gli utenti vanno creati
singolarmente ed altri problemi simili, inoltre usa per trasferire i file il protocollo
TFTP, ma poiché TFTP utilizza UDP, è necessario creare un supporto per
trasporto e sessione. Anche in questo caso si richiede l’installazione di un
software su tutti i client.
•
Nagios
[15]
Il suo scopo è creare una mappa della rete e dei suoi servizi, tenendo sotto
controllo la disponibilità degli oggetti monitorati. La configurazione di nagios è
abbastanza lunga perche ha molti file di configurazione, bisogna configurare anche
il database e il cgi del proprio web server
•
NTOP [16]
NTOP è il software che ha focalizzato maggiormente su di se l’attenzione poiché
permette come alcuni dei precedenti di scrivere su di un database mySQL e di
consultare facilmente i report tramite interfaccia web, ma la sua peculiarità
maggiore è quella di essere un software poco invasivo, infatti, basta installare una
sonda-demone sul router wi-fi e impostare un server che riceve tutti i dati, in questo
modo gli utenti non percepiscono minimamente di essere monitorati, poiché sulla
propria macchina non avviene nessuna installazione, inoltre anche l’installazione
sul router è particolarmente semplice e ancora più semplice è l’installazione sui
firmware della famiglia WRT.
Si analizza di seguito, nel particolare le ulteriori funzionalità di NTOP, la possibilità di
riconoscere diversi protocolli (TCP,UDP,ICMP,IPX,NetBIOS, Appletalk), distribuzione del
traffico per servizio (broadcast, web, mail, FTP, P2P) o per sorgente / destinazione, la
percentuale di banda utilizzata, il traffico Voip (SIP, Cisco SCCP, IAX2), lo storico delle
sessioni tcp e molto altro.
20
Nel caso affrontato bisogna analizzare anche l’interfacciamento che avviene fra DD-WRT
e il sistema NTOP. Il procedimento è molto semplice : basta installare un probe (sonda)
nel router ed esportare i dati verso ntop il quale farà da collezionatore e analizzatore.
Sul router Linksys la procedura è la seguente
1. Menu DD-WRT nella sezione administration e abilitare Rflow
2. Inserire indirizzo IP della macchina ntop e specificare la porta.
Sul Server NTop, invece
1. Abilitare plug-in e aggiungere il device NetFlow
2. Specificare la porta per il collector (2055)
3. Nel menu admin alla voce ”Switch NIC” selezionare il device NetFlow
L’architettura del sistema utilizzato è molto semplice e riportata di seguito:
Gli elementi salienti dell’architettura sono:
•
RFlow: probe Netflow che colleziona pacchetti ed esporta i flussi verso una console
centrale, utilizzabile in tutte le reti con router NetFlow enable;
•
libpcap: consiste in un insieme di librerie realizzate per la cattura dei pacchetti che
transitano sulle reti;
•
NetFlow: importa flussi di traffico e li cataloga per tipologia;
•
RRD.plugin: registra i dati e crea i grafici a run-time.
21
In figura vengono mostrati alcuni screenshoot:
22
Pricing
Il Pricing è un problema complesso poiché, inizialmente, è necessario stabilire delle linee
guida che permettano di considerare adeguatamente le politiche di connessione degli
utenti; in secondo luogo bisogna andare ad implementare i meccanismi.
Nel nostro caso, il pricing può essere applicato sia alla soluzione basata su hotspot, sia
alla soluzione basata su autenticazione EAP; questo è possibile in quanto è stata
predisposta un’architettura di base con un database MySql a supporto della connessione.
FreeRadius, durante l’accounting degli utenti che si collegano, memorizza alcune
informazioni particolari che permettono di effettuare politiche di pricing: in particolare nella
tabella radacct. I campi sono i seguenti:
•
AcctSessionTime: tempo complessivo della durata della connessione (in secondi);
•
AcctInputOctets: traffico in upload (bit);
•
AcctOutputOctets: traffico in download (bit);
È quindi possibile definire degli script in sql che permettono di effettuare delle Viste su
questa tabella, interrogandola periodicamente per ottenere informazioni sul tempo di
connessione di un utente oppure sui Kb scambiati durante la sessione.
Lo script generato è il seguente:
#! /bin/bash
while [ true ]
do
echo "Script 1 in esecuzione..."
mysql -uroot -proot radius < /home/domenico/Scrivania/View1.sql
echo "Script 2 in esecuzione..."
mysql -uroot -proot radius < /home/domenico/Scrivania/View2.sql
echo "Pausa di 30 min"
sleep 1800
done
Lo scopo principale dello script è quello di aggiornare periodicamente (per semplicità
abbiamo impostato un timeout di 30 minuti) le Viste in maniera tale da avere
23
aggiornamenti frequenti per la tariffazione degli utenti.
Gli script MySql View1.sql e View2.sql sono quelli che effettivamente si occupano di
aggiornare le viste e sono i seguenti:
View1.sql
CREATE OR REPLACE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL
SECURITY
DEFINER
VIEW
`Utenti`
AS
select
`r`.`UserName`
AS
`UserName`,sum(`r`.`AcctSessionTime`) AS `time` from `radacct` `r` group
by `r`.`UserName`
View2.sql
CREATE OR REPLACE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL
SECURITY
DEFINER
VIEW
`user-price`
AS
select
`u`.`UserName`
AS
`UserName`,((`p`.`PriceToPay` * `u`.`time`) / 60) AS `Billing` from
(`Utenti` `u` join `pricing` `p`) where (`u`.`UserName` = `p`.`UserName`)
group by `u`.`UserName`
Avendo queste informazioni è quindi possibile scegliere tra policy di pricing differenti
sfruttando appieno combinazioni di informazioni diverse (es. Soglie, combinazioni di tempo
e Kb, etc).
24
Implementazione
Inizialmente si era pensato di sviluppare un’autenticazione basata su certificati digitali
X.509 quindi utilizzando un protocollo 802.1X di tipo EAP-TLS (Transport Layer Security).
L’utilizzo di 802.1X/EAP serve per rafforzare l’architettura di sicurezza della rete wireless,
inoltre permette di autenticare il soggetto e non solo la scheda ed infine risolve i problemi
relativi al WEP.
Utilizzare questo tipo di cifratura nel nostro caso non è stato possibile in quanto
nell’architettura classica il router ha solo la funzionalità di Access Point, mentre nel nostro
caso il router cattura le connessioni in ingresso ed assegna un indirizzo IP che permette
solo di interrogare il server radius tramite script in cgi.
Quindi si crea un fenomeno di mutua autenticazione dovuto al fatto che, per funzionare
con l’EAP, serve che la connessione sia cifrata almeno con WPA mentre con questo tipo
di architettura la connessione deve essere lasciata aperta, altrimenti il programma che si
occupa di catturare le richieste dei client non riesce a farlo.
Per questo, visto che la soluzione di hotspot e di autenticazione EAP non potevano
convivere, si è scelto di svilupparle come due applicazioni parallele, andando infine a
confrontarle.
Soluzione: Hotspot con Chillispot
Un client che vuole accedere alla rete effettua semplicemente la connessione tramite la
scheda WiFi del proprio pc; il demone di Chillispot presente sull’AP cattura la connessione
ed assegna all’utente un indirizzo IP privato che può essere usato solamente per
contattare il server Radius.
Questo accade la prima volta che l’utente apre una pagina web: il demone cattura il
tentativo di connessione e reindirizza l’utente, tramite connessione cifrata SSL, ad una
pagina contenuta sul server Radius. La pagina non è altro che uno script di login scritto in
linguaggio cgi che apre una maschera all’utente dove questi può inserire username e
password; i dati vengono inviati al server Radius, sempre tramite connessione cifrata,
dove viene effettuato il controllo dei dati utente.
Se l’utente non è presente nel database, o comunque non è registrato, viene restituito un
messaggio di Access-Reject al client che visualizzerà a sua volta una pagina di errore.
Eventualmente non sia registrato, è presente un link che rimanda ad una form di
registrazione dove ci si può registrare inserendo i propri dati anagrafici: questi verranno
25
inviati via mail al gestore che, effettuati gli opportuni controlli, provvederà ad abilitare
l’utente.
Se l’utente è registrato, dopo la maschera di login verrà reindirizzato alla propria home
page, mantenendo un pop-up contenente un promemoria sulla durata della connessione,
che permette di effettuare in ogni momento la disconnessione: il tutto in maniera
trasparente all’utente.
Nel database MySql vengono inserite in tempo reale le informazioni relative all’accounting
start o all’accounting stop.
Queste aggiorneranno le Viste sul database che permette di gestire il billing degli utenti; il
vantaggio in questo caso è che queste interrogazioni possono essere fatte da remoto, e
con qualsiasi sistema operativo, tramite i tool messi a disposizione dalla Sun.
Per gli utenti che invece utilizzano una connessione diretta all’AP è stato scelto di non
richiedere l’autenticazione con Chillispot in quanto si presuppongono utenti noti, che
eventualmente possono agire direttamente sull’AP per eventuali manutenzioni e
configurazioni.
Soluzione: AAA con EAP
In questa seconda soluzione, l’architettura del sistema rimane praticamente invariata;
l’unica differenza si nota sul router, dove viene disabilitata la funzione di Hotspot e viene
invece abilitata l’autenticazione WPA2 Radius Mixed.
Questa nuova soluzione permette di selezionare il server radius al quale inviare le
informazioni per l’autenticazione di utenti mediante certificati digitali.
I certificati vengono generati dal server tramite OpenSSL che genera sia le chiavi private
del server che la Certification Authority locale che i certificati dei client[17].
Al client verranno poi forniti due certificati che dovrà installare sul proprio pc: la
Certification Authority (CA) ed il certificato personale del client; una volta installati
dovranno essere inseriti nelle impostazioni della connessione alla rete wireless fornita
dall’AP.
26
In figura vengono mostrati gli screenshot di configurazione del sistema client:
27
Una volta che il client tenta di autenticarsi, l’AP riceve le informazioni di autenticazione e le
invia all’indirizzo IP del server radius precedentemente impostato.
Il server, ricevute le informazioni, analizza i diversi tipi di autenticazione che possiede in
memoria, associati all’utente (nel nostro caso solo EAP); si occupa di avviare la procedura
di autenticazione tramite TLS (Transport Layer Security) e, se l’handshake va a buon fine,
invia le informazioni di Access-Accept al client che riceverà dall’AP le necessarie
configurazioni per permettere la navigazione.
In figura viene mostrato un esempio della procedura suddetta:
28
Generazione Certificati X.509
Come è noto esistono due modalità di crittografia dei dati quella simmetrica e asimmetrica.
La prima, anche se molto più veloce della seconda, utilizza la stessa chiave sia per la
crittografia che per la decrittografia dei dati; mentre quella asimmetrica utilizza due chiavi
diverse una pubblica e l’altra privata.
È preferibile usare chiavi di tipo one-time e la distribuzione delle chiavi deve avvenire nel
modo più sicuro possibile. L’uso di chiavi della dimensione di 4096 bit (o superiore)
potrebbe creare problemi su alcuni tipi di router o versioni datate di alcuni software.
Per la distribuzione delle chiavi pubbliche lo standard più utilizzato è l’X.509 del quale
sono disponibili tre versioni; la più aggiornata è la versione 3 che si presenta nel seguente
modo:
Una PKI (Public Key Infrastructure), che ha come base l’uso del certificato, è sicura
quanto lo sono le procedure adottate per gestirla; le procedure sono regolate da:
•
Security Policy
•
Certificate Policy
•
Certificate Practice Statement (CPS)
Esse vengono definite da un team misto di persone di diversi dipartimenti (legale,
personale, IT, …).
La validazione dei certificati assicura che le informazioni siano valide, il certificato viene
adoperato solo per i servizi dichiarati e che sia fidato. Nel nostro caso la validazione non
sarà necessaria, visto l’utilizzo che ne vogliamo fare.
È possibile configurare le policy di un certificato editando (oppure creando) il file
CAPolicy.inf che permette inoltre di definire le CPS.
29
La generazione dei certificati, in generale, è molto semplice utilizzando OpenSSL che
funziona sia sotto Linux che sotto Windows.
In questo caso per generare i certificati X.509, si è ricorso ad un tool messo a disposizione
dal programma OpenSource OpenVpn; questo programma, che permette di creare tunnel
vpn tra macchine diverse, mette a disposizione degli strumenti di sviluppo per generare
certificati di questo tipo.
La procedura è la seguente: si genera in primo luogo la Certification Authority (CA) che
servirà ad autenticare tutti gli altri certificati generati; fatto ciò si genera la chiave privata
del server radius ed il suo relativo certificato (necessario per il corretto funzionamento
dell’EAP-TLS).
Eseguite queste operazioni, è possibile generare certificati utente, a loro volta autenticati
dalla CA creata in precedenza.
Dopo aver generato tutti i certificati necessari, vengono generati altri due files molto
importanti che sono rispettivamente il parametro di Diffie-Hellman, che genera una chiave
di cifratura da usare durante la connessione, ed un file random al quale si appoggia
FreeRadius per le operazioni temporanee.
Dopo aver eseguito queste procedure è necessario aggiornare il file di FreeRadius,
eap.conf, passando come parametri i percorsi dei file precedentemente creati, nel nostro
caso nella sezione tls:
tls {
private_key_password = root
private_key_file = ${raddbdir}/certs/server.key
#
If Private key & Certificate are located in
#
the same file, then private_key_file &
#
certificate_file must contain the same file
#
name.
certificate_file = ${raddbdir}/certs/server.crt
#
Trusted Root CA list
CA_file = ${raddbdir}/certs/ca.crt
dh_file = ${raddbdir}/certs/dh1024.pem
random_file = ${raddbdir}/certs/random
}
30
Conclusioni
Le due soluzioni a confronto
Andando a confrontare le due diverse soluzioni una prima differenza consiste proprio
nell’uso del Router; questi infatti è fondamentale per la soluzione hotspot basata su
ChilliSpot in quanto fornisce nativamente, grazie all’uso del firmware DD-WRT,
l’implementazione del programma e la possibilità di configurarlo facilmente agendo via
browser.
Nel secondo caso, ovvero con l’EAP-TLS, il router non necessita di nessun software
particolare per cui svolge semplicemente la funzione di Access Point quindi sarebbe
praticamente rimpiazzabile da una semplice scheda di rete aggiuntiva.
D’altronde anche le due soluzioni si basano su un’ottica leggermente diversa: la prima
presuppone di lasciare libera la connessione per “chiunque”, necessitando però di
username e password se si vuole navigare; nel secondo caso invece la connessione viene
protetta da crittografia WPA2 che si appoggia su un server radius per l’autenticazione
quindi la connessione rimane inaccessibile dall’esterno a meno di non avere le credenziali
necessarie.
Il vantaggio della soluzione con EAP-TLS è dato sicuramente dal fatto che si autentica non
solo la macchina, o meglio la scheda WiFi che effettua la connessione, ma anche l’utente
che effettivamente la usa; questo è un grande vantaggio in quanto username e password
di un utente possono essere sempre facilmente carpibili con svariati tipi di attacchi
(BruteForce Online, BruteForce Offline, Phishing, etc) anche se la connessione è di tipo
https e quindi protetta da SSL.
Si può dire quindi che le due soluzioni devono essere indirizzate sicuramente a servizi
diversi, la prima ad esempio per connessioni in luoghi pubblici quali aeroporti, stazioni,
centri commerciali etc., mentre la seconda per connessioni aziendali o dipartimentali dove
fondamentale è la sicurezza e la garanzia che l’utente che si collega sia chi effettivamente
dice di essere.
31
Bibliografia
[1] – Router Linksys WRT54GL Home Page : http://www.linksys.com/international
[2] – DD-WRT Home Page : http://www.dd-wrt.com
[3] – OpenWrt wiki Home Page : http://wiki.openwrt.org/OpenWrtDocs
[4] – X-Wrt Home Page : http://x-wrt.org/
[5] – CoovaAP Home Page : http://www.coova.org/wiki
[6] – Client TFTP 3cDaemon Home Page : http://www.3com.com/
[7],[8] – Paolo Daniele, Studio ed implementazione di un sistema Open Source a supporto
della sicurezza per reti IP, December 15th 2006
[9] – Chillispot Home Page : http://www.chillispot.info/
[10] – D.L. 27/07/2005 n° 144
[11] – MRTG Home Page : http://oss.oetiker.ch/mrtg/index.en.html
[12] – Zabbix Home Page : http://www.zabbix.com
[13] – Cacti Home Page : http://www.cacti.net
[14] – Jffnms Home Page : http://www.jffnms.org/
[15] – Nagios Home Page : www.nagios.org/
[16] – Ntop Home Page : http://ntop.org/
[17] – Building Debian FreeRadius package with support of EAP-TLS
http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peapsupport.html
32
Appendice A: HowTo
In conclusione viene inserito un piccolo HowTo per spiegare come si è proceduti nella
configurazione di FreeRadius per funzionare come Radius server sia in caso di
autenticazione da database, sia in caso di autenticazione con EAP-TLS.
Per l’autenticazione da database, bisogna modificare il file sql.conf che si trova nella
cartella radice di FreeRadius (la versione del programma utilizzata è la 1.6.3 per
autenticazione da Db e la 1.7.1 modificata aggiungendo il supporto EAP-TLS)[17].
Si è proceduti prima ad installare sia Ubuntu 7.10 che Kubuntu 7.10 su delle partizioni del
sistema operativo; poi sfruttando il gestore pacchetti di Debian, Adept Manager, si sono
installati i pacchetti richiesti ovvero FreeRadius(solo la versione 1.6.3 perché la 1.7.1 non
è ancora nei repository), Mysql client e server, Apache e Php ed infine OpenVpn per
ottenere i tool necessari alla generazione dei certificati digitali.
Le modifiche al file sql.conf sono le seguenti:
sql {
# Database type
# Current supported are: rlm_sql_mysql, rlm_sql_postgresql,
# rlm_sql_iodbc, rlm_sql_oracle, rlm_sql_unixodbc, rlm_sql_freetds
driver = "rlm_sql_mysql"
# Connect info
server = "localhost"
login = "root"
password = "root"
# Database table configuration
radius_db = "radius"
# If you want both stop and start records logged to the
# same SQL table, leave this as is. If you want them in
# different tables, put the start table in acct_table1
# and stop table in acct_table2
acct_table1 = "radacct"
acct_table2 = "radacct"
# Allow for storing data after authentication
postauth_table = "radpostauth"
authcheck_table = "radcheck"
authreply_table = "radreply"
groupcheck_table = "radgroupcheck"
groupreply_table = "radgroupreply"
usergroup_table = "usergroup"
# Table to keep radius client info
nas_table = "nas"
33
# Remove stale session if checkrad does not see a double login
deletestalesessions = yes
# Print all SQL statements when in debug mode (-x)
sqltrace = no
sqltracefile = ${logdir}/sqltrace.sql
# number of sql connections to make to server
num_sql_socks = 5
# number of seconds to dely retrying on a failed database
# connection (per_socket)
connect_failure_retry_delay = 60
# Safe characters list for sql queries. Everything else is replaced
# with their mime-encoded equivalents.
# The default list should be ok
#safe-characters =
"@abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.-_: /"
###################################################################
####
# Query config: Username
###################################################################
####
# This is the username that will get substituted, escaped, and
added
# as attribute 'SQL-User-Name'.
'%{SQL-User-Name}' should be used
below
# everywhere a username substitution is needed so you you can be
sure
# the username passed from the client is escaped properly.
#
# Uncomment the next line, if you want the sql_user_name to mean:
#
#
Use Stripped-User-Name, if it's there.
#
Else use User-Name, if it's there,
#
Else use hard-coded string "DEFAULT" as the user name.
#sql_user_name = "%{Stripped-User-Name:-%{User-Name:-DEFAULT}}"
#
sql_user_name = "%{User-Name}"
###################################################################
####
# Default profile
###################################################################
####
# This is the default profile. It is found in SQL by group
membership.
# That means that this profile must be a member of at least one
group
# which will contain the corresponding check and reply items.
# This profile will be queried in the authorize section for every
user.
# The point is to assign all users a default profile without having
to
34
# manually add each one to a group that will contain the profile.
# The SQL module will also honor the User-Profile attribute. This
# attribute can be set anywhere in the authorize section (ie the
users
# file). It is found exactly as the default profile is found.
# If it is set then it will *overwrite* the default profile
setting.
# The idea is to select profiles based on checks on the incoming
packets,
# not on user group membership. For example:
# -- users file -# DEFAULT Service-Type == Outbound-User, User-Profile :=
"outbound"
# DEFAULT Service-Type == Framed-User, User-Profile := "framed"
#
# By default the default_user_profile is not set
#
#default_user_profile = "DEFAULT"
#
# Determines if we will query the default_user_profile or the UserProfile
# if the user is not found. If the profile is found then we
consider the user
# found. By default this is set to 'no'.
#
#query_on_not_found = no
###################################################################
####
# Authorization Queries
###################################################################
####
# These queries compare the check items for the user
# in ${authcheck_table} and setup the reply items in
# ${authreply_table}. You can use any query/tables
# you want, but the return data for each row MUST
# be in the following order:
#
# 0. Row ID (currently unused)
# 1. UserName/GroupName
# 2. Item Attr Name
# 3. Item Attr Value
# 4. Item Attr Operation
###################################################################
####
#
\
#
#
#
#
\
#
#
#
# Use these for case sensitive usernames.
authorize_check_query = "SELECT id, UserName, Attribute, Value, op
FROM ${authcheck_table} \
WHERE Username = BINARY '%{SQL-User-Name}' \
ORDER BY id"
authorize_reply_query = "SELECT id, UserName, Attribute, Value, op
FROM ${authreply_table} \
WHERE Username = BINARY '%{SQL-User-Name}' \
ORDER BY id"
35
# The default queries are case insensitive. (for compatibility with
# older versions of FreeRADIUS)
authorize_check_query = "SELECT id, UserName, Attribute, Value, op
\
FROM ${authcheck_table} \
WHERE Username = '%{SQL-User-Name}' \
ORDER BY id"
authorize_reply_query = "SELECT id, UserName, Attribute, Value, op
\
FROM ${authreply_table} \
WHERE Username = '%{SQL-User-Name}' \
ORDER BY id"
# Use these for case sensitive usernames.
#
authorize_group_check_query = "SELECT
${groupcheck_table}.id,${groupcheck_table}.GroupName,${groupcheck_table}.
Attribute,${groupcheck_table}.Value,${groupcheck_table}.op FROM
${groupcheck_table},${usergroup_table} WHERE ${usergroup_table}.Username
= BINARY '%{SQL-User-Name}' AND ${usergroup_table}.GroupName =
${groupcheck_table}.GroupName ORDER BY ${groupcheck_table}.id"
#
authorize_group_reply_query = "SELECT
${groupreply_table}.id,${groupreply_table}.GroupName,${groupreply_table}.
Attribute,${groupreply_table}.Value,${groupreply_table}.op FROM
${groupreply_table},${usergroup_table} WHERE ${usergroup_table}.Username
= BINARY '%{SQL-User-Name}' AND ${usergroup_table}.GroupName =
${groupreply_table}.GroupName ORDER BY ${groupreply_table}.id"
authorize_group_check_query = "SELECT
${groupcheck_table}.id,${groupcheck_table}.GroupName,${groupcheck_table}.
Attribute,${groupcheck_table}.Value,${groupcheck_table}.op FROM
${groupcheck_table},${usergroup_table} WHERE ${usergroup_table}.Username
= '%{SQL-User-Name}' AND ${usergroup_table}.GroupName =
${groupcheck_table}.GroupName ORDER BY ${groupcheck_table}.id"
authorize_group_reply_query = "SELECT
${groupreply_table}.id,${groupreply_table}.GroupName,${groupreply_table}.
Attribute,${groupreply_table}.Value,${groupreply_table}.op FROM
${groupreply_table},${usergroup_table} WHERE ${usergroup_table}.Username
= '%{SQL-User-Name}' AND ${usergroup_table}.GroupName =
${groupreply_table}.GroupName ORDER BY ${groupreply_table}.id"
###################################################################
####
# Accounting Queries
###################################################################
####
# accounting_onoff_query
- query for Accounting On/Off packets
# accounting_update_query - query for Accounting update packets
# accounting_update_query_alt
- query for Accounting update
packets
#
(alternate in case first query
fails)
# accounting_start_query
- query for Accounting start packets
# accounting_start_query_alt
- query for Accounting start
packets
36
#
(alternate in case first query
fails)
# accounting_stop_query
- query for Accounting stop packets
# accounting_stop_query_alt
- query for Accounting start
packets
#
(alternate in case first query
doesn't
#
affect any existing rows in the
table)
###################################################################
####
accounting_onoff_query = "UPDATE ${acct_table1} SET
AcctStopTime='%S', AcctSessionTime=unix_timestamp('%S') unix_timestamp(AcctStartTime), AcctTerminateCause='%{Acct-TerminateCause}', AcctStopDelay = '%{Acct-Delay-Time}' WHERE AcctSessionTime=0 AND
AcctStopTime=0 AND NASIPAddress= '%{NAS-IP-Address}' AND AcctStartTime <=
'%S'"
accounting_update_query = " \
UPDATE ${acct_table1} \
SET \
FramedIPAddress = '%{Framed-IP-Address}', \
AcctSessionTime
= '%{Acct-Session-Time}', \
AcctInputOctets
= '%{Acct-Input-Gigawords:-0}'
<< 32 |
\
AcctOutputOctets
'%{Acct-Input-Octets:-0}', \
= '%{Acct-Output-Gigawords:-0}' << 32 |
\
'%{Acct-Output-Octets:-0}' \
WHERE AcctSessionId = '%{Acct-Session-Id}' \
AND UserName
= '%{SQL-User-Name}' \
AND NASIPAddress
= '%{NAS-IP-Address}'"
accounting_update_query_alt = " \
INSERT INTO ${acct_table1} \
(AcctSessionId,
AcctUniqueId,
UserName, \
Realm,
NASIPAddress,
NASPortId, \
NASPortType,
AcctStartTime,
AcctSessionTime, \
AcctAuthentic,
ConnectInfo_start, AcctInputOctets, \
AcctOutputOctets, CalledStationId,
CallingStationId, \
ServiceType,
FramedProtocol,
FramedIPAddress, \
AcctStartDelay,
XAscendSessionSvrKey) \
VALUES \
('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', \
'%{SQL-User-Name}', \
'%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', \
'%{NAS-Port-Type}', \
DATE_SUB('%S', \
INTERVAL (%{Acct-Session-Time:-0} + \
%{Acct-Delay-Time:-0}) SECOND), \
'%{Acct-Session-Time}', \
'%{Acct-Authentic}', '', \
'%{Acct-Input-Gigawords:-0}' << 32 | \
'%{Acct-Input-Octets:-0}', \
'%{Acct-Output-Gigawords:-0}' << 32 | \
37
'%{Acct-Output-Octets:-0}', \
'%{Called-Station-Id}', '%{Calling-Station-Id}', \
'%{Service-Type}', '%{Framed-Protocol}', \
'%{Framed-IP-Address}', \
'0', '%{X-Ascend-Session-Svr-Key}')"
accounting_start_query = " \
INSERT INTO ${acct_table1} \
(AcctSessionId,
AcctUniqueId,
UserName, \
Realm,
NASIPAddress,
NASPortId, \
NASPortType,
AcctStartTime,
AcctStopTime, \
AcctSessionTime, AcctAuthentic,
ConnectInfo_start, \
ConnectInfo_stop, AcctInputOctets, AcctOutputOctets, \
CalledStationId, CallingStationId, AcctTerminateCause, \
ServiceType,
FramedProtocol,
FramedIPAddress, \
AcctStartDelay,
AcctStopDelay,
XAscendSessionSvrKey) \
VALUES \
('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', \
'%{SQL-User-Name}', \
'%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', \
'%{NAS-Port-Type}', '%S', '0', \
'0', '%{Acct-Authentic}', '%{Connect-Info}', \
'', '0', '0', \
'%{Called-Station-Id}', '%{Calling-Station-Id}', '', \
'%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IPAddress}', \
'%{Acct-Delay-Time:-0}', '0', '%{X-Ascend-Session-SvrKey}')"
accounting_start_query_alt = "UPDATE ${acct_table1} SET
AcctStartTime = '%S', AcctStartDelay = '%{Acct-Delay-Time}',
ConnectInfo_start = '%{Connect-Info}' WHERE AcctSessionId = '%{AcctSession-Id}' AND UserName = '%{SQL-User-Name}' AND NASIPAddress = '%{NASIP-Address}'"
accounting_stop_query =
UPDATE ${acct_table2}
AcctStopTime
AcctSessionTime
AcctInputOctets
" \
SET \
= '%S', \
= '%{Acct-Session-Time}', \
= '%{Acct-Input-Gigawords:-0}' << 32 | \
'%{Acct-Input-Octets:-0}', \
AcctOutputOctets
= '%{Acct-Output-Gigawords:-0}' << 32 | \
'%{Acct-Output-Octets:-0}', \
AcctTerminateCause = '%{Acct-Terminate-Cause}', \
AcctStopDelay
= '%{Acct-Delay-Time:-0}', \
ConnectInfo_stop
= '%{Connect-Info}' \
WHERE AcctSessionId
= '%{Acct-Session-Id}' \
AND UserName
= '%{SQL-User-Name}' \
AND NASIPAddress
= '%{NAS-IP-Address}'"
accounting_stop_query_alt = " \
INSERT INTO ${acct_table2} \
(AcctSessionId, AcctUniqueId, UserName, \
38
Realm, NASIPAddress, NASPortId, \
NASPortType, AcctStartTime, AcctStopTime, \
AcctSessionTime, AcctAuthentic, ConnectInfo_start, \
ConnectInfo_stop, AcctInputOctets, AcctOutputOctets, \
CalledStationId, CallingStationId, AcctTerminateCause, \
ServiceType, FramedProtocol, FramedIPAddress, \
AcctStartDelay, AcctStopDelay) \
VALUES \
('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', \
'%{SQL-User-Name}', \
'%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', \
'%{NAS-Port-Type}', \
DATE_SUB('%S', \
INTERVAL (%{Acct-Session-Time:-0} + \
%{Acct-Delay-Time:-0}) SECOND), \
'%S', '%{Acct-Session-Time}', '%{Acct-Authentic}', '', \
'%{Connect-Info}', \
'%{Acct-Input-Gigawords:-0}' << 32 | \
'%{Acct-Input-Octets:-0}', \
'%{Acct-Output-Gigawords:-0}' << 32 | \
'%{Acct-Output-Octets:-0}', \
'%{Called-Station-Id}', '%{Calling-Station-Id}', \
'%{Acct-Terminate-Cause}', \
'%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IPAddress}', \
'0', '%{Acct-Delay-Time:-0}')"
###################################################################
####
# Simultaneous Use Checking Queries
###################################################################
####
# simul_count_query - query for the number of current connections
#
- If this is not defined, no simultaneouls use
checking
#
- will be performed by this module instance
# simul_verify_query - query to return details of current
connections for verification
#
- Leave blank or commented out to disable
verification step
#
- Note that the returned field order should not be
changed.
###################################################################
####
# Uncomment simul_count_query to enable simultaneous use checking
#simul_count_query = "SELECT COUNT(*) \
#FROM ${acct_table1} \
#WHERE UserName='%{SQL-User-Name}' \
#AND AcctStopTime = 0"
simul_verify_query
= "SELECT RadAcctId, AcctSessionId, UserName,
\
NASIPAddress, NASPortId, FramedIPAddress,
\
39
CallingStationId, FramedProtocol \
FROM ${acct_table1} \
WHERE UserName='%{SQL-User-Name}' \
AND AcctStopTime = 0"
###################################################################
####
# Group Membership Queries
###################################################################
####
# group_membership_query
- Check user group membership
###################################################################
####
group_membership_query = "SELECT GroupName FROM ${usergroup_table}
WHERE UserName='%{SQL-User-Name}'"
###################################################################
####
# Authentication Logging Queries
###################################################################
####
# postauth_query
- Insert some info after authentication
###################################################################
####
postauth_query = "INSERT into ${postauth_table} (user, pass, reply,
date) values ('%{User-Name}', '%{User-Password:-Chap-Password}',
'%{reply:Packet-Type}', NOW())"
#
# Set to 'yes' to read radius clients from the database ('nas'
table)
#readclients = yes
}
In rosso le parti modificate per essere adattate a quanto richiesto, a parte i parametri di
configurazione della connessione al db, si è agito sulla query di accounting per gestire
meglio l’account degli utenti.
Molto importante è il file radiusd.conf fondamentale per la corretta configurazione di
FreeRadius, in particolare andando ad agire sulle modalità di autenticazione ed
accounting per poter gestire nel caso del sistema pubblico l’autenticazione e l’accounting
su database, mentre nel sistema privato l’autenticazione con eap e l’accounting con
database.
40
Radiusd.conf
#
Authorization. First preprocess (hints and huntgroups files),
#
then realms, and finally look in the "users" file.
#
#
The order of the realm modules will determine the order that
#
we try to find a matching realm.
#
#
Make *sure* that 'preprocess' comes before any realm if you
#
need to setup hints for the remote radius server
authorize {
#
#
The preprocess module takes care of sanitizing some bizarre
#
attributes in the request, and turning them into attributes
#
which are more standard.
#
#
It takes care of processing the 'raddb/hints' and the
#
'raddb/huntgroups' files.
#
#
It also adds the %{Client-IP-Address} attribute to the request.
preprocess
#
#
#
If you want to have a log of authentication requests,
#
un-comment the following line, and the 'detail auth_log'
#
section, above.
auth_log
# read the users file
files
#
attr_filter
41
#
#
The chap module will set 'Auth-Type := CHAP' if we are
#
handling a CHAP request and Auth-Type has not already been set
chap
#
#
If the users are logging in with an MS-CHAP-Challenge
#
attribute for authentication, the mschap module will find
#
the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
#
to the request, which will cause the server to then use
#
the mschap module for authentication.
mschap
#
#
#
If you have a Cisco SIP server authenticating against
#
FreeRADIUS, uncomment the following line, and the 'digest'
#
line in the 'authenticate' section.
digest
#
#
#
Look for IPASS style 'realm/', and if not found, look for
#
'@realm', and decide whether or not to proxy, based on
#
that.
IPASS
#
#
If you are using multiple kinds of realms, you probably
#
want to set "ignore_null = yes" for all of them.
#
Otherwise, when the first style of realm doesn't match,
#
the other styles won't be checked.
#
42
suffix
#
ntdomain
#
#
This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
#
authentication.
#
#
It also sets the EAP-Type attribute in the request
#
attribute list to the EAP type from the packet.
eap
#
#
Look in an SQL database.
The schema of the database
#
is meant to mirror the "users" file.
#
#
#
See "Authorization Queries" in sql.conf
sql
#
#
#
If you are using /etc/smbpasswd, and are also doing
#
mschap authentication, the un-comment this line, and
#
configure the 'etc_smbpasswd' module, above.
etc_smbpasswd
#
#
#
The ldap module will set Auth-Type to LDAP if it has not
#
already been set
ldap
#
#
#
Enforce daily limits on time spent logged in.
daily
43
#
# Use the checkval module
#
checkval
#
# As of 1.1.4, you should list "pap" last in this section.
# See "man rlm_pap" for more information.
pap
}
#
Authentication.
#
#
#
This section lists which modules are available for authentication.
#
Note that it does NOT mean 'try each module in order'.
#
that a module from the 'authorize' section adds a configuration
#
attribute 'Auth-Type := FOO'.
#
used to pick the apropriate module from the list below.
It means
That authentication type is then
#
#
In general, you SHOULD NOT set the Auth-Type attribute.
The server
#
will figure it out on its own, and will do the right thing.
#
most common side effect of erroneously setting the Auth-Type
#
attribute is that one authentication method will work, but the
#
others will not.
The
#
#
The common reasons to set the Auth-Type attribute by hand
#
is to either forcibly reject the user, or forcibly accept him.
#
authenticate {
44
#
#
PAP authentication, when a back-end database listed
#
in the 'authorize' section supplies a password.
#
password can be clear-text, or encrypted.
The
Auth-Type PAP {
pap
}
#
#
Most people want CHAP authentication
#
A back-end database listed in the 'authorize' section
#
MUST supply a CLEAR TEXT password.
#
won't work.
Encrypted passwords
Auth-Type CHAP {
chap
}
#
#
MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
#
#
#
If you have a Cisco SIP server authenticating against
#
FreeRADIUS, uncomment the following line, and the 'digest'
#
line in the 'authorize' section.
digest
#
#
#
Pluggable Authentication Modules.
pam
45
#
#
See 'man getpwent' for information on how the 'unix'
#
module checks the users password.
#
containing CHAP-Password attributes CANNOT be authenticated
#
against /etc/passwd!
Note that packets
See the FAQ for details.
#
unix
# Uncomment it if you want to use ldap for authentication
#
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password.
#
Auth-Type LDAP {
#
#
ldap
}
#
#
Allow EAP authentication.
eap
}
#
#
Pre-accounting.
Decide which accounting type to use.
#
preacct {
preprocess
#
#
Ensure that we have a semi-unique identifier for every
46
#
request, and many NAS boxes are broken.
acct_unique
#
#
Look for IPASS-style 'realm/', and if not found, look for
#
'@realm', and decide whether or not to proxy, based on
#
that.
#
#
#
Accounting requests are generally proxied to the same
#
home server as authentication requests.
IPASS
suffix
#
ntdomain
#
#
Read the 'acct_users' file
files
}
#
#
Accounting.
Log the accounting data.
#
accounting {
#
#
Create a 'detail'ed log of the packets.
#
Note that accounting requests which are proxied
#
are also logged in the detail file.
detail
#
daily
#
Update the wtmp file
#
47
#
If you don't use "radlast", you can delete this line.
unix
#
#
For Simultaneous-Use tracking.
#
#
Due to packet losses in the network, the data here
#
may be incorrect.
There is little we can do about it.
radutmp
#
sradutmp
#
Return an address to the IP Pool when we see a stop record.
#
main_pool
#
sqlippool
#
#
Log traffic to an SQL database.
#
#
See "Accounting queries" in sql.conf
sql
#
#
Instead of sending the query to the SQL server,
#
write it into a log file.
#
#
sql_log
#
#
Cisco VoIP specific bulk accounting
pgsql-voip
}
48
#
Session database,
radutmp
used for checking
#
or rlm_sql module can handle this.
#
The rlm_sql module is *much* faster
Simultaneous-Use. Either
the
session {
radutmp
#
#
#
See "Simultaneous Use Checking Querie" in sql.conf
sql
}
#
Post-Authentication
#
Once we KNOW that the user has been authenticated, there are
#
additional steps we can take.
post-auth {
#
Get an address from the IP Pool.
#
main_pool
#
sqlippool
#
#
#
If you want to have a log of authentication replies,
#
un-comment the following line, and the 'detail reply_log'
#
section, above.
reply_log
#
#
After authenticating the user, do another SQL query.
#
#
See "Authentication Logging Queries" in sql.conf
49
#
sql
#
#
Instead of sending the query to the SQL server,
#
write it into a log file.
#
#
sql_log
#
#
Un-comment the following if you have set
#
'edir_account_policy_check = yes' in the ldap module sub-section
#
the 'modules' section.
of
#
#
ldap
#
#
Access-Reject packets are sent through the REJECT sub-section of
#
post-auth section.
the
#
Uncomment the following and set the module name to the ldap
instance
#
name if you have set 'edir_account_policy_check = yes' in the
ldap
#
module sub-section of the 'modules' section.
#
#
Post-Auth-Type REJECT {
#
#
insert-module-name-here
}
}
#
#
When the server decides to proxy a request to a home server,
50
#
the proxied request is first passed through the pre-proxy
#
stage.
#
cancel the proxy.
This stage can re-write the request, or decide to
#
#
Only a few modules currently have this method.
#
pre-proxy {
#
#
#
attr_rewrite
#
Uncomment the following line if you want to change attributes
#
as defined in the preproxy_users file.
files
#
If you want to have a log of packets proxied to a home
#
server, un-comment the following line, and the
#
'detail pre_proxy_log' section, above.
pre_proxy_log
}
#
#
When the server receives a reply to a request it proxied
#
to a home server, the request may be massaged here, in the
#
post-proxy stage.
#
post-proxy {
#
If you want to have a log of replies from a home server,
#
un-comment the following line, and the 'detail post_proxy_log'
#
section, above.
#
post_proxy_log
#
attr_rewrite
51
#
#
Uncomment the following line if you want to filter replies from
#
remote proxies based on the rules defined in the 'attrs' file.
attr_filter
#
#
If you are proxying LEAP, you MUST configure the EAP
#
module, and you MUST list it here, in the post-proxy
#
stage.
#
#
You MUST also use the 'nostrip' option in the 'realm'
#
configuration.
#
in the proxied request will not match the user name
#
hidden inside of the EAP packet, and the end server will
#
reject the EAP request.
Otherwise, the User-Name attribute
#
eap
}
Inoltre, per permettere la comunicazione sicura tra server e router, bisogna abilitare una
shared key configurando il file clients.conf con queste modifiche:
client 192.168.1.1 {
secret = root
shortname
= private-network-1
}
Per configurare Chillispot invece si possono usare due vie, o aprire una sessione telnet
con il router(dopo aver modificato il firmware) o utilizzare l’interfaccia web.
Per configurare il file chilli.conf a mano si usa il seguente modello:
net 192.168.2.0/24
dns1 ns1.dominio.org
dns2 ns2.dominio.org
domain dominio.org
52
radiusserver1 127.0.0.1
radiusserver2 127.0.0.1
radiussecret radiussecret
dhcpif1 eth1
uamserver https://192.168.2.1/cgi-bin/hotspotlogin.cgi
uamsecret uamsecret
uamlisten 192.168.2.1
uamallowed www.dominio1.tld,www.dominio2.tld,192.168.2.0/24
Dove:
•
Radiusserver1 e radiusserver2: sono gli ip del server radius primario e di un
eventuale server di backup;
•
Radiussecret: è la shared key tra server radius e hotspot;
•
dhcpif1: è la scheda sulla quale applicare il dhcp;
•
uamserver: è il server che contiene la pagina di login;
•
uamsecret: è la shared key tra server e hotspot;
•
uamlisten: è l’indirizzo che si occupa di catturare le connessioni;
•
uamallowed: sono indirizzi visitabili senza doversi loggare
Per permettere connessioni sicure, ed evitare intrusioni sul sistema, è stato necessario
installare un web server usando Apache: questo perché il file di login deve poter essere
accessibile dall’esterno.
Per questo è stato necessario definire un file di policy per permettere connessioni ssl sul
file di login e proibire tutti gli altri tentativi di acesso alle risorse del sistema; per fare
questo si è creato il file /etc/apache2/sites-available/hotspot, che nel nostro caso
fornisce la configurazione per il sito contenente sia lo script di login che l'interfaccia Web
per amministrare gli utenti. A seconda delle necessità dell'installazione specifica si può
preferire distinguere questi due servizi in due virtual host disting magari perevendo una
pagina di Benvenuto. Questa comunque è una configurazione di massima nel caso
abbiate bisogno di ispirarvi:
NameVirtualHost 192.168.2.1:443
<VirtualHost 192.168.2.1:443>
ServerAdmin [email protected]
DocumentRoot "/var/www/hotspot"
ServerName "192.168.2.1"
<Directory "/var/www/hotspot/">
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Alias "/dialupadmin/" "/usr/share/freeradius-dialupadmin/htdocs/"
<Directory "/usr/share/freeradius-dialupadmin/htdocs/">
53
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /var/www/hotspot/cgi-bin/
<Directory "/var/www/hotspot/cgi-bin/">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/hotspot-error.log
LogLevel warn
CustomLog /var/log/apache2/hotspot-access.log combined
ServerSignature On
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>
Infine per Ntop e HLBR la configurazione è abbastanza semplice una volta installati i
programmi, nel caso di HLBR bisogna definire i gruppi di indirizzi che possono effettuare
determinate azioni, come in un file di policy.
Per Ntop la configurazione avviene tutta tramite interfaccia Web user-friendly.
54