Sviluppo di un sistema a supporto del WiFi-Sharing UNIVERSITÀ DEGLI STUDI DELLA CALABRIA FACOLTÀ DI INGEGNERIA DELLE TELECOMUNICAZIONI

Transcript

1 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 Ciano Maurizio Daniele Paolo Gaetano Domenico

2 Sommario Introduzione... 3 Architettura... 4 Linksys WRT54GL... 5 Analisi Firmware OpenSource... 6 DD-WRT... 6 OpenWrt... 8 X-Wrt... 8 CoovaAP... 8 Server AAA Formato Pacchetto Radius Scambio Messaggi con Radius Chillispot Database MySql Analisi del traffico Pricing Implementazione Soluzione: Hotspot con Chillispot Soluzione: AAA con EAP Generazione Certificati X Conclusioni Le due soluzioni a confronto Bibliografia Appendice A: HowTo

3 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

4 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

5 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 MHz 16 MB 4 MB MHz 16 MB 4 MB Modello rilasciato dopo la versione 5 del WRT54G. Modello rilasciato nel Giugno Il router utilizzato è quello con la versione firmware

6 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

7 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

8 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 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

9 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

10 Server AAA Come server di AAA è stata utilizzata una macchina con sistema operativo Ubuntu 7.10 equipaggiata 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 User Service) consente l autenticazione, l autorizzazione 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 to 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

11 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

12 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

13 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

14 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

15 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

16 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

17 Viene mostrato adesso un esempio della tabella di accounting e vengono analizzati in dettaglio i campi: 17

18 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

19 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 Nuove norme sui dati del traffico telefonico e telematico e Art. 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

20 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

21 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

22 In figura vengono mostrati alcuni screenshoot: 22

23 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

24 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

25 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