Sei sulla pagina 1di 109

Universit` a degli Studi di Perugia Facolt` a di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Informatica

Tesi di Laurea

Realizzazione di una soluzione integrata cablata/wireless per una infrastruttura di rete dipartimentale.
Candidato Simone Pascarosa

Relatore Prof. Leonello Servoli

Correlatore Mirko Mariotti

Anno Accademico 2006-2007

Indice
1 Introduzione 7 1.1 Enti coinvolti nel progetto . . . . . . . . . . . . . . . . . . . . . . 7 1.1.1 Dipartimento di Fisica dellUniversit` a di Perugia . . . . . 7 1.1.2 Sezione di Perugia dellIstituto Nazionale di Fisica Nucleare 8 1.2 Situazione attuale della rete . . . . . . . . . . . . . . . . . . . . . 8 2 Il progetto della rete 2.1 Funzioni da implementare . . . . . . . . . . . . . 2.2 Requisiti hardware e software . . . . . . . . . . . 2.3 La rete nascosta . . . . . . . . . . . . . . . . . . 2.4 I servizi condivisi . . . . . . . . . . . . . . . . . . 2.5 Flessibilit` a, estensioni, aggiornamenti e modiche 3 Tecnologie 3.1 Virtual LAN . . . . . . . . . . . . . . . . . . . . 3.1.1 Storia . . . . . . . . . . . . . . . . . . . . 3.1.2 Funzionamento e terminologia . . . . . . . 3.1.3 Congurazione di VLAN su un computer 3.2 Wireless . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Extended Service Set . . . . . . . . . . . . 3.2.2 Il progetto INFN/TRIP . . . . . . . . . . 3.2.3 La rete aperta per i convegni . . . . . . . 3.3 Sicurezza, autenticazione e controllo: RADIUS . 3.3.1 AAA e RADIUS . . . . . . . . . . . . . . 3.3.2 Il protocollo RADIUS . . . . . . . . . . . 3.3.3 Il nostro server RADIUS . . . . . . . . . . 3.3.4 FreeRADIUS . . . . . . . . . . . . . . . . 3.4 Certicati digitali X.509: sicurezza garantita . . 3.4.1 Crittograa . . . . . . . . . . . . . . . . . 3.4.2 Public Key Infrastructure . . . . . . . . . 3.4.3 Certicato digitale . . . . . . . . . . . . . 3.4.4 Il formato X.509 per certicati digitali . . 3.5 Directory service con LDAP . . . . . . . . . . . . 3.5.1 Storia . . . . . . . . . . . . . . . . . . . . 3.5.2 Perch e non usare un database relazionale? 3.5.3 Struttura directory e formato delle entry . 3.5.4 Referrals e chaining . . . . . . . . . . . . 3.5.5 Schema : attributi e classi di oggetto . . . 3 11 11 14 15 18 19 21 21 22 22 24 26 27 27 31 32 33 34 36 39 42 42 44 44 45 48 49 49 50 51 52

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . .

3.6

3.5.6 Server LDAP slave . . . . . . . . . . . . 3.5.7 La nostra directory . . . . . . . . . . . . Virtualizzazione per alta adabilit` a . . . . . . 3.6.1 Virtualizzazione di piattaforma con Xen 3.6.2 EVMS: virtualizzazione dei dischi . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

54 54 55 55 58 59 60 60 60 60 62 64 66 66 67 72 76 76 80 80 81 82 84 90 90 92 93 96 103 105

4 Realizzazione 4.1 Struttura generale della rete . . . . . . . . . . . . . . . 4.1.1 Indirizzamento IP . . . . . . . . . . . . . . . . 4.2 Implementazione VLAN . . . . . . . . . . . . . . . . . 4.2.1 Aggiunta dei VLAN ID . . . . . . . . . . . . . 4.2.2 Tagging delle porte . . . . . . . . . . . . . . . . 4.2.3 Congurazione VLAN con SSID multipli su AP 4.3 Implementazione del progetto TRIP . . . . . . . . . . 4.3.1 Congurazione Access point per 802.1x . . . . 4.3.2 Congurazione Captive portal . . . . . . . . . . 4.3.3 Congurazioni RADIUS . . . . . . . . . . . . . 4.4 Congurazione directory LDAP . . . . . . . . . . . . . 4.4.1 Congurazione servizio slapd . . . . . . . . . . 4.4.2 Inserimento entry per lo startup . . . . . . . . 4.5 Congurazione repliche LDAP . . . . . . . . . . . . . 4.6 Congurazione DNS e DHCP . . . . . . . . . . . . . . 4.6.1 Congurazione DHCP . . . . . . . . . . . . . . 4.6.2 Congurazione DNS . . . . . . . . . . . . . . . 4.7 Congurazione delle macchine virtuali . . . . . . . . . 4.7.1 Installazione di Xen . . . . . . . . . . . . . . . 4.7.2 Congurazione dei domU . . . . . . . . . . . . 4.8 Congurazione router e rewall . . . . . . . . . . . . . 4.9 Uso di interfacce grache per la gestione del sistema . 5 Migrazione 6 Conclusioni

. . . . . . . . . . . . . . . . . . . . . . . . . wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

Elenco delle gure


1.1 2.1 2.2 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 Schema della rete del Dipartimento di Fisica/INFN . . . . . . . . Modello di rete privata . . . . . . . . . . . . . . . . . . . . . . . . Associazione di un server ad una o pi` u reti VLAN . . . . . . . . Trama Ethernet con IEEE 802.1q . . . . . . . . . . . . . . . . Esempio di comunicazione in modalit` a Tagged . . . . . . . . Esempio di comunicazione in modalit` a Untagged . . . . . . . Interfacce virtuali per luso delle VLAN . . . . . . . . . . . . Meccanismo di proxying del server RADIUS . . . . . . . . . . Schema di una sessione di autenticazione 802.1x . . . . . . . . Schema dellautenticazione via Captive Portal . . . . . . . . . Processo di autenticazione RADIUS standard . . . . . . . . . Schematizzazione dei servizi RADIUS centralizzati su LDAP Struttura gerarchica dei server RADIUS INFN . . . . . . . . Meccanismo di cifratura simmetrica . . . . . . . . . . . . . . Meccanismo di cifratura asimmetrica . . . . . . . . . . . . . . Meccanismo di Referral di LDAP . . . . . . . . . . . . . . . . Meccanismo di Chaining di LDAP . . . . . . . . . . . . . . . Meccanismo di replica di LDAP . . . . . . . . . . . . . . . . . Schema semplicato dellarchitettura di XEN . . . . . . . . . Schermata di aggiunta di una VLAN sullo switch 3Com 3300 Aggiunta di porte in modalit` a Tagged ad una VLAN . . . . . Denizione della VLAN Untagged per una porta dello switch Esempio di separazione dei domini VLAN . . . . . . . . . . . Congurazione delle VLAN sugli Access Point Cisco . . . . . Congurazione degli SSID sugli Access Point Cisco . . . . . . Congurazione dellautenticazione sugli Access Point Cisco . Dettaglio della congurazione dei metodi di cifratura . . . . . Meccanismo di replica in LDAP . . . . . . . . . . . . . . . . . Gerarchia delle congurazioni del DHCP su LDAP . . . . . . Domini della rete privata . . . . . . . . . . . . . . . . . . . . Gerarchia delle congurazioni del DNS su LDAP . . . . . . . Router di frontiera con le reti servite . . . . . . . . . . . . . . Schermata principale di phpLDAPadmin . . . . . . . . . . . . Gerarchia di una directory LDAP con phpLDAPadmin . . . . Denizione degli attributi di una entry con phpLDAPadmin . Strutturazione dei le del programma LDAPaccess . . . . . . 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 16 18 22 24 24 25 28 29 32 37 38 41 42 43 52 52 54 57

. 62 . 63 . 63 . 64 . 64 . 65 . 67 . 67 . 80 . 83 . 85 . 87 . 94 . 97 . 97 . 98 . 100

4.18 Aggiunta di un nuovo computer portatile con LDAPaccess . . . . 101 4.19 LDIF per la registrazione di un nuovo computer portatile . . . . 101 4.20 Dettaglio dei computer posseduti da un utente con LDAPAccess 102

Capitolo 1

Introduzione
Questa tesi presenta il lavoro svolto dal candidato presso il Dipartimento di Fisica dellUniversit` a di Perugia, in collaborazione con lIstituto Nazionale di Fisica Nucleare, per la realizzazione del nuovo impianto di rete cablata e wireless delledicio che ospita i due enti. Il lavoro ` e stato svolto principalmente nel periodo da Marzo a Settembre 2007. Perch e realizzare questo tipo di rete La realizzazione di una rete come descritta da questa tesi risponde ad alcune necessit` a speciche degli enti che la utilizzeranno, ma pu` o benissimo rispondere alle necessit` a di altre realt` a simili. In particolare deve prevedere la possibilit` a di condividere gli apparati di rete tra gli enti in gioco, ma nel contempo dare la possibilit` a di creare reti separate.

1.1
1.1.1

Enti coinvolti nel progetto


Dipartimento di Fisica dellUniversit` a di Perugia

Il Dipartimento di Fisica dellUniversit` a di Perugia nasce il 30 ottobre 1982. Ad oggi conta 31 professori, tra ordinari ed associati, ed 11 ricercatori. Inoltre allinterno del dipartimento lavorano 24 dottorandi. Il dipartimento opera in stretta collaborazione con lIstituto Nazionale di Fisica Nucleare, con lIstituto Nazionale per la Fisica della Materia, con alcune Agenzie Spaziali ed Enti di Ricerca sparsi in tutto il mondo. I principali campi di ricerca in cui ` e coinvolto il personale sono lastrosica, la sica della materia, la sica sperimentale delle particelle e astroparticelle e la sica teorica. Il dipartimento di Fisica si inserisce nella Facolt` a di Scienze Matematiche Fisiche e Naturali dellUniversit` a degli Studi di Perugia, che fu una tra le prime libere universit` a sorte in Italia, eretta a Studium Generale l8 settembre 1308. Ad oggi lUniversit` a degli Studi di Perugia ` e suddivisa in 11 facolt` a, con circa 34.000 iscritti in totale, provenienti da tutta Italia. 7

1.1.2

Sezione di Perugia dellIstituto Nazionale di Fisica Nucleare

LINFN ` e lente dedicato allo studio dei costituenti fondamentali della materia e svolge attivit` a di ricerca, teorica e sperimentale, nei campi della sica subnucleare, nucleare e astroparticellare1 . La ricerca fondamentale in questi settori richiede luso di tecnologie e strumenti di ricerca davanguardia, che lINFN sviluppa nei propri laboratori e in collaborazione con il mondo dellindustria. LIstituto promuove inoltre il trasferimento delle competenze, delle metodologie e delle tecniche strumentali sviluppate nellambito della propria attivit` a verso campi di ricerca diversi quali la medicina, i beni culturali e lambiente. Tutte queste attivit` a si svolgono in stretta collaborazione con il mondo universitario. LINFN venne istituito l8 Agosto 1951 da gruppi delle Universit` a di Roma, Padova, Torino e Milano, al ne di proseguire e sviluppare la tradizione scientica iniziata negli anni 30 con le ricerche teoriche e sperimentali di sica nucleare di Enrico Fermi e della sua scuola. Lattivit` a dellINFN si basa su due tipi di strutture di ricerca complementari: le Sezioni e i Laboratori Nazionali. Le 19 Sezioni hanno sede in dipartimenti universitari e realizzano il collegamento diretto tra lIstituto e le Universit` a. I quattro Laboratori, con sede a Catania, Frascati, Legnaro e Gran Sasso, ospitano grandi apparecchiature e infrastrutture messe a disposizione della comunit` a scientica nazionale ed internazionale. Il personale dellINFN conta circa 2000 dipendenti propri e quasi 2000 dipendenti universitari coinvolti nelle attivit` a dellIstituto e 1300 giovani tra laureandi, borsisti e dottorandi. Si chiamano associati coloro che deniscono una collaborazione con lente per progetti di ricerca pur non essendo dipendenti.

1.2

Situazione attuale della rete

Finora le due reti, quella di INFN e quella del Dipartimento di Fisica, coesistono in modo indipendente allinterno delledicio, anche se possono parlarsi attraverso un gateway che le mette in comunicazione; per il resto le due reti sono sicamente separate, cio` e ognuna ha i propri switch, i propri cavi e i propri server. Vediamo schematicamente la rete odierna delledicio del Dipartimento di Fisica nella gura 1.1. In verde ` e riportato il dominio della rete di Fisica2 , mentre in blu quello di INFN. Si noti la presenza di almeno 2 switch per ogni piano, uno per dominio. Problemi della coesistenza di due reti nello stesso edicio Questa struttura porta ad avere, ad ogni piano delledicio, armadi con 2 o 3 switch, anche non completamente utilizzati, vista la necessit` a di avere la rete di Fisica su uno switch e quella INFN su un altro. Inoltre il cablaggio delle stanze deve essere tenuto sotto controllo e bisogna fare attenzione a quale switch
informazioni sono prese dal sito uciale di INFN[1] resto della tesi verr` a usato il nome Fisica, intendendo il Dipartimento di Fisica dellUniversit` a di Perugia
2 nel 1 queste

Figura 1.1: Schema della rete del Dipartimento di Fisica/INFN

attaccare un certo cavo (nel periodo di stage ho imparato limportanza delle etichette sui cavi!). Altro grande problema si presenta quando una persona passa da un ente ad un altro: se un ricercatore INFN diventa dipendente del Dipartimento di Fisica, si dovrebbe procedere a registrare nuovamente i suoi dati presso il nuovo ente e a ricreare tutte le congurazioni necessarie.

10

Capitolo 2

Il progetto della rete


Il progetto della nuova rete del Dipartimento di Fisica di Perugia vuole sfruttare gli apparati di rete esistenti per creare una infrastruttura di rete scalabile, essibile e condivisa tra i due enti che risiedono nelledicio cio` e il Dipartimento di Fisica e la sezione di Perugia dellIstituto Nazionale di Fisica Nucleare. La rete dovr` a permettere la navigazione dei computer su Internet, lutilizzo delle risorse interne, quali stampanti, server di posta, griglia di calcolo e degli altri servizi fondamentali. Le necessit` a di amministrazione e gestione della rete prevedono che i due domini1 siano separati, anche se gli apparati di rete, soprattutto quello di collegamento e commutazione, sono gestiti in collaborazione tra i due enti. Questa separazione verr` a realizzata con la tecnologia IEEE2 802.1q detta anche VLAN, Virtual LAN. Si prevede anche di creare un sistema di gestione centralizzata delle congurazione dei servizi di rete principali per facilitare la creazione di repliche ridondanti di tali server, per evitare replicazioni inutili di dati importanti e per centralizzare in un unico servizio le informazioni di congurazione, autenticazione ed autorizzazione per i servizi. La gestione sar` a implementata con un directory server usando il protocollo LDAP. Per aumentare ladabilit` a e la disponibilit` a dei servizi, si prevede di creare delle copie ridondanti di alcuni servizi critici tramite tecniche di virtualizzazione. Il progetto vuole creare un sistema di amministrazione, congurazione e controllo delle reti che sia il pi` u possibile facile, essibile, sicuro, adabile e mantenibile.

2.1

Funzioni da implementare

Separazione in apparati comuni e linee comuni Con la nuova struttura, le due reti saranno realizzate sulle stesse apparecchiature di comunicazione (switch e cavi), ma con la tecnologia IEEE 802.1q possiamo separare i domini delle due reti, riducendo il numero dei dispositivi e gli sforzi di gestione. Questo porta certamente ad una condivisione della responsabilit` a tra
1 nel resto della tesi il termine dominio verr` a usato in alternativa a rete; altri usi del termine saranno chiari dal contesto 2 Institute of Electrical and Electronics Engineers, uno dei principali enti di standardizzazione internazionali in informatica

11

gli amministratori delle due reti, ma sicuramente facilita il controllo, aumenta la essibilit` a e laggiunta di nuovi dispositivi alla rete. Facilit` a di congurazione di molti server con la centralizzazione Ciascun servizio di rete, come lassegnazione degli indirizzi IP (DHCP), le stampanti condivise, la risoluzione dei nomi a dominio (DNS), il controllo degli accessi, ha necessit` a di congurazione diverse: per ciascuno di questi, esistono altrettanti software che li implementano e ciascuno di essi ha una propria congurazione. Per ogni congurazione, nello specico per ogni le di congurazione, esistono altrettante regole di sintassi, comandi e parole chiave da imparare, che sovente obbligano lamministratore a noiose ricerche su manuali e guide di riferimento. Lidea di questo progetto ` e quella di centralizzare tutte le congurazioni dei servizi principali, nel nostro caso DHCP, DNS, autenticazione e PROXY, in un unico servizio informativo che sia di facile accesso ed abbia uninterfaccia standard al ne di poter creare applicazioni personalizzate per svolgere certi compiti. Questo servizio informativo sar` a critico per tutta la struttura di rete, poich` e ciascun server andr` a a leggere la sua congurazione facendo delle interrogazioni su di esso; possiamo perci` o immaginare la sua criticit` a sia in termini di sicurezza che di adabilit` a. Il servizio informativo messo in piedi permette quindi di replicare facilmente le macchine server, sia in caso di guasti della macchina stessa, sia in caso di indisponibilit` a; non essendoci pi` u le di congurazione lunghissimi, lunica informazione da scrivere nel server sar` a quella che lo indirizza al servizio informativo. Economia nellacquisto degli apparati di rete con la separazione dei domini Un punto a favore di questa struttura ` e il lato economico. Come gi` a accennato nei paragra precedenti, la condivisione degli apparati di rete e dei cavi diminuisce i costi sia di acquisto di nuovi apparati che di cablaggio. Con la struttura precedente della rete, quando uno switch di INFN esauriva le porte e cera necessit` a di una porta per un nuovo computer, si doveva acquistare un nuovo switch. Adesso che gli switch sono condivisi tra le due reti, si pu` o bilanciare il numero dei PC tra gli switch gi` a esistenti, visto che gli switch sono comuni tra le due reti. Con la tecnologia delle VLAN (o IEEE 802.1q) si diminuiscono anche i costi di cablaggio, visto che se un ucio ha bisogno di accedere sia alla rete INFN che a quella del Dipartimento di Fisica non deve avere pi` u due cavi che portano ad altrettanti switch, ma su un singolo cavo pu` o far coesistere comunicazioni per luna e per laltra rete, semplicemente congurando la propria postazione in modo opportuno.

Economia nellacquisto dei server tramite virtualizzazione La virtualizzazione ` e ormai una realt` a consolidata. Permette di creare versioni virtuali di una risorsa, nel nostro caso un sistema operativo, che agisce come se fosse la sua versione reale. I server che implementiamo in questo progetto 12

sono virtuali, perch e a ciascun server virtuale corrisponde una macchina reale sulla quale viene eseguito, ma ciascuna macchina reale pu` o eseguire pi` u server virtuali con la virtualizzazione dei sistemi operativi. Con questo sistema possiamo far eseguire anche diversi server virtuali su ununica macchina reale. La congurazione migliore che sembra garantire buone prestazioni ` e quella che prevede di far girare 4 server virtuali (o macchine virtuali) su una sola macchina sica. In questo modo ci siamo risparmiati lacquisto di 3 server... un bel risultato! Altro vantaggio delluso delle macchine virtuali ` e che al loro interno possiamo mettere solo lo stretto necessario, riducendo il rischio di crash del server e di errori di sistema causati da software non necessari, riducendo anche la dimensione su disco dei lesystem di queste macchine. In pratica creiamo dei piccoli server special purpose, virtuali, che condividono la stessa macchina reale sulla quale vengono eseguiti. Nella sezione 3.1.3 vedremo come riuscire a cablare queste macchine virtuali che naturalmente condividono linterfaccia di rete del server reale e come, attraverso il VLAN Tagging, riusciamo ad associare ciascun server alle reti che deve servire, risparmiando anche sulle interfacce di rete necessarie. Economia nellacquisto di software Altro fattore, che incide pesantemente sul risparmio che questa struttura di rete porta, ` e la scelta di usare software libero3 , vista anche la buona esperienza sia del candidato che dei suoi relatori con il software libero, e specialmente con il sistema operativo GNU/Linux. Luso di software libero, oltre ad abbattere, nella maggior parte dei casi, i costi di acquisto, aumenta la congurabilit` a, ladesione agli standard dei software rilasciati sotto licenze libere e facilita la personalizzazione del software. Il software libero, checch e ne dicano i suoi detrattori, ha raggiunto un livello di stabilit` a, di standardizzazione e di utilizzo tale da poter sostituire completamente quello proprietario, soprattutto nel campo dei server di rete. Tutte le tecnologie che abbiamo utilizzato sono standard consolidati; anche se esistono soluzioni proprietarie per alcune parti di questo progetto (ad esempio Active Directory per lautenticazione), abbiamo preferito usare sempre software libero. Flessibilit` a nella denizione di nuove reti private Un elemento non secondario, conseguenza dellutilizzo della tecnologia VLAN per la separazione delle reti, ` e la essibilit` a nella creazione delle reti (il termine rete, in questo contesto, denota un dominio di collisione Ethernet, cio` e una rete a livello Data Link ISO/OSI4 separata dalle altre). Allo stato attuale ci sono 14 domini diversi, ma nessuno ci vieta di crearne di nuovi. Se per esempio avessimo la necessit` a di creare una rete riservata alla quale agganciare PC di diversi piani, basterebbe creare un VLAN ID per la nuova rete, assegnando i TAG necessari alla porte dello switch con i PC interessati. Tutto questo senza necessit` a di acquisto di nuovi switch o di cablaggi ulteriori, che si renderebbero
come quel software che permette la libert` a di eseguire il programma per qualunque scopo, di studiarlo e modicarlo, di copiarlo e distribuirlo e di migliorarlo e rilasciare i propri miglioramenti a tutti perch e tutti ne traggano benecio 4 International Standard Organization/Open System Infrastructure, modello di riferimento per le reti informatiche composto da una pila a 7 livelli
3 inteso

13

necessari visto che la rete dovrebbe essere separata sicamente dalle altre. La separazione sica ` e realizzata con i VLAN ID. Il compito delle VLAN ` e quello di creare reti logiche indipendenti su una stessa rete sica; al contrario delle sottoreti che tendono a creare gerarchie di reti. Criticit` a, svantaggi e rischi Le criticit` a introdotte da questa struttura sono diverse. Prima di tutto la coesistenza di due reti, aerenti a due enti diversi, sulle stesse apparecchiature, porta la necessit` a di condividere la responsabilit` a tra i gestori delle due reti; inoltre, lerrore di uno degli amministratori, anche se riguarda una congurazione della propria rete, potrebbe provocare un down della rete dellaltro ente, con evidenti conseguenze sulla disponibilit` a di quella rete. Gli apparati, quali switch, cavi e router, diventano critici perch e un loro malfunzionamento compromette il funzionamento non solo della rete a cui appartengono ma di tutti i domini che passano attraverso questi. La centralizzazione delle congurazioni (oltre agli evidenti vantaggi gi` a enunciati) comporta alcuni svantaggi: anche per le congurazioni dei servizi la responsabilit` a deve essere condivisa tra gli amministratori delle reti interessate; inoltre le macchine che svolgono questo servizio informativo sono dei point of failure per le reti, infatti un down del servizio di centralizzazione delle congurazioni (LDAP) porterebbe al down di tutti i servizi interessati, come DHCP, DNS, autenticazione wireless ecc. Per aggirare questo problema, le macchine che implementano il servizio saranno replicate in una gerarchia che garantir` a una maggiore disponibilit` a del servizio anche nel caso in cui una delle macchine smettesse di funzionare. Il servizio informativo ed il router di frontiera tra i diversi domini sono le macchine pi` u critiche dal punto di vista della sicurezza; le politiche dovranno essere adeguate, sia per quanto riguarda il controllo degli accessi, che consentir` a laccesso solo agli amministratori, sia per quanto riguarda il traco in entrata e in uscita, permesso solo alle macchine che devono leggere le proprie congurazioni.

2.2

Requisiti hardware e software

I requisiti hardware per la realizzazione del progetto sono molto simili a quelli di una normale rete di computer. Per quanto riguarda il cablaggio, i requisiti sono la presenza di almeno 1 porta con connettivit` a Gigabit Ethernet per connettere tutti gli switch di dorsale al centro stella della rete ed uno switch che supporti Gigabit Ethernet; inoltre tali switch devono supportare lo standard 802.1q per denire lassociazione di ciascuna porta dello switch ad un dominio. Saranno necessari degli switch Managed cio` e ai quali possa essere assegnato un indirizzo IP per la gestione di queste congurazioni. Anche gli Access Point Wireless devono supportare la tecnologia 802.1q e devono poter annunciare pi` u di una rete wireless5 .
5 per rete wireless si intende un SSID che identica una rete wireless, come descritto nel paragrafo 3.2.1

14

Per il cablaggio abbiamo usato cavi UTP6 Cat.5 per le tratte dagli switch di piano ai computer e cavi STP7 Cat.7 per le tratte dagli switch di piano al centro stella (per supportare le trasmissioni a frequenze no a 1Gbit/sec). I dispositivi gi` a presenti sono switch 3com 3300 e HP Procurve 2848 ad ogni piano. Per il centro stella abbiamo scelto uno switch 3com 3300. Come Access Point usiamo Cisco Aironet 1100 e 1200. Come server per ospitare le macchine virtuali abbiamo utilizzato dei server SuperMicro o comunque possiamo utilizzare qualunque macchina di livello server pu` o andare bene. Per ospitare comodamente 4 macchine virtuali in funzione, le macchine reali dovranno avere un processore da almeno 2 GHz di clock, con almeno 1 GB di memoria RAM da condividere tra le macchine virtuali. Per quanto riguarda lo spazio disco, non ci sono particolari requisiti, tranne quello che lhard disk dovr` a avere una capacit` a tale da contenere tutti i lesystem delle macchine virtuali ed il lesystem del sistema di monitoraggio di queste. Per quanto riguarda i dispositivi di rete c` e bisogno che le interfacce di rete delle macchine reali possano comunicare a velocit` a sostenuta, di almeno 100Mbit/sec, meglio se 1Gbit/sec, visto che una stessa interfaccia potrebbe essere utilizzata da pi` u macchine virtuali. Il controllo sullautenticazione dei portatili sulla rete wireless verr` a fatto tramite server RADIUS8 , quindi gli access point devono supportare questa modalit` a. Il software di rete del sistema operativo sia delle macchine virtuali, che della macchina reale di monitor deve supportare le VLAN. Lo stack di rete del sistema operativo GNU/Linux, nello specico quello delle distribuzioni Gentoo e Debian, supportano questa tecnologia. Nei computer degli utenti della rete, non c` e necessit` a di alcun supporto delle VLAN, a meno che questi non debbano, per particolari necessit` a, avere interfacce di rete su pi` u di una rete. Quindi dal lato utente non c` e bisogno di alcuna modica o upgrade del software.

2.3

La rete nascosta

Una delle novit` a pi` u evidenti della nuova rete ` e il fatto che gli indirizzi di rete pubblici, sia del dipartimento di Fisica, che dellINFN, non vengono pi` u dati ai singoli utenti su singole postazioni, ma vengono riservati solo ai servizi di rete (che con ladozione di nuove tecnologie aumentano). Per indirizzo IP 9 pubblico si intende un indirizzo registrato presso un ISP10 che pu` o essere contattato direttamente da qualsiasi host su Internet. La rete nascosta (o rete privata) ` e una struttura che permette di realizzare proprio questa separazione tra il dominio locale della rete ed Internet, come mostrato in gura 2.1. Fino ad oggi, quindi, i computer della rete del Dipartimento erano accedibili da qualunque computer connesso ad Internet: questo per varie necessit` a, ad esempio per i docenti per mettere a disposizione materiale per gli studenti o ai ricercatori per poter scambiare facilmente dati e informazioni con altri ricercatori in giro per il mondo. La nuova struttura permetter` a ai computer della rete
Twisted Pair, coppia di cavi incrociati senza schermatura Twisted Pair, coppia di cavi incrociati con schermatura 8 una descrizione del sistema RADIUS viene data nel paragrafo 3.3.1 9 Internet Protocol, il protocollo di rete di Internet 10 Internet Service Provider, fornitore di accesso ad Internet
7 Shielded 6 Unshielded

15

Figura 2.1: Modello di rete privata

interna di navigare qualunque sito Web o di contattare qulunque host nella rete, viceversa, un utente di Internet non pu` o contattare direttamente un computer interno. Analizziamo pi` u attentamente i vantaggi/svantaggi di questa soluzione. Vantaggi: i computer della rete Interna sono pi` u protetti dagli attacchi esterni perch e non sono direttamente raggiungibili dalla rete di Internet; vengono risparmiati indirizzi IP pubblici; ` e facilitato il controllo degli accessi, il tracciamento delle connessioni e la registrazione dellutilizzo della rete; abbiamo a disposizione molti pi` u indirizzi, visto che possiamo scegliere arbitrariamente la classe di indirizzi IP da usare e quindi la dimensione massima della nostra rete, perci` o allarghiamo il limite dei servizi che possiamo orire. Svantaggi: i computer della rete interna non sono contattabili direttamente da Internet, anche se si possono denire delle associazioni sul router di frontiera della rete per renderli visibili; linstallazione e la congurazione sono pi` u complicate rispetto alla vecchia struttura. Impatto sugli utenti Uno dei requisiti della migrazione ` e quello di diminuire il pi` u possibile limpatto sugli utenti della modica. Eettivamente, chi utilizza un computer sso non dovr` a eettuare alcuna modica, visto che sia in passato, che nella nuova rete, viene utilizzato un server DHCP11 che distribuisce le congurazioni di accesso
11 Dynamic

Host Conguration Protocol, protocollo per la congurazione degli host su rete

16

alla rete ai computer. Quindi per lutente nale non ci sar` a alcuna modica, tranne il fatto che non si potr` a pi` u accedere direttamente al proprio computer da Internet, con le caratteristiche appena evidenziate. Per gli utenti che si collegano con un portatile lunica modica da fare sar` a il nome della rete wireless (lESSID 12 ) e, per gli ospiti, linserimento di nome utente/password sulla schermata di autenticazione. VLAN per rappresentare laerenza delle reti Con rete nascosta intendiamo tutto linsieme delle reti, nascoste appunto, che vengono realizzate nelledicio. Tecnicamente parlando infatti, non viene realizzata una singola rete (a livello IP), ma diverse reti, una per ogni ambito di lavoro (dipartimento, INFN, wireless, laboratori ecc.). Quando si parla di rete nascosta, si intende perci` o la struttura di queste varie reti. La suddivisione delle Virtual LAN permette di creare tante reti separate, senza moltiplicare il numero degli switch. Immaginiamo per esempio un palazzo di sei piani, come quello del Dipartimento di Fisica, con due reti separate: dovremmo avere un numero di switch pari alla reti possibili per ogni piano, quindi n = numero piani, r = numero reti numeroswitch = n r un numero esagerato! Con le VLAN non abbiamo pi` u bisogno di uno switch per ogni ente ad ogni piano. Gli switch che useremo dovranno essere pi` u intelligenti della semplice commutazione: infatti devono poter controllare il codice della VLAN (TAG) al quale il pacchetto appartiene ed eventualmente modicare tale codice. Ciascuna rete singola rappresenta una rete a se stante a livello IP; cio` e le varie VLAN si comportano come se fossero varie reti separate (come daltronde succedeva nella vecchia struttura del dipartimento), ma che condividono le stesse attrezzature hardware e software per funzionare. Lamministratore, congurando gli switch e impostando le politiche pi` u appropriate, pu` o spostare un computer da una VLAN ad unaltra in modo trasparente. Questo grazie al meccanismo del VLAN Tagging delle porte, che verr` a spiegato nel paragrafo 3.1.2. Grazie alle VLAN creiamo delle reti separate inserendo dei codici nel traco, che permettono di associare un pacchetto o una porta di uno switch ad una certa rete. Il meccanismo ` e essibile, infatti possiamo associare un computer ad una o pi` u reti VLAN diverse, senza modicare le funzionalit` a di rete gi` a esistenti e con un overhead relativamente basso. La complessit` a naturalmente si sposta sullo switch che deve essere congurato in modo adeguato per far passare i pacchetti per le VLAN previste nel modo giusto. Reti separate con servizi in comune Finora abbiamo parlato di suddivisione, separazione ed indipendenza. Si prevede di realizzare comunque dei servizi comuni a tutte le singole reti.
12 si

veda il paragrafo 3.2.1 per maggiori informazioni

17

In generale, la struttura permette, attraverso il router che connette le varie VLAN ad Internet, di fornire dei servizi agli utenti, anche diversicandoli secondo la propria tipologia. Nello specico possiamo realizzare sulla rete servizi di proxying, di accesso remoto alla propria postazione da Internet o accesso alle stampanti condivise.

2.4

I servizi condivisi

I servizi di rete principali sono il DHCP, il DNS13 e lautenticazione14 . Questi servizi sono condivisi tra tutte le reti create, perch e indispensabili per laccesso alla rete e ad Internet. Esistono anche delle risorse che sono condivise solo da alcune reti, come ad esempio le stampanti. La essibilit` a della rete permette di creare servizi che rispondano ad una o pi` u reti. Infatti basta associare lo specico server alle VLAN alle quali ` e interessato, registrarlo opportunamente sul DNS ed il gioco ` e fatto.

Figura 2.2: Associazione di un server ad una o pi` u reti VLAN

Come mostra la gura 2.2 possiamo associare un server alle reti VLAN che ci interessano semplicemente collegando la sua scheda di rete ad uno switch che sia connesso a tali reti; successivamente basta far conoscere al server i codici di queste reti (indicate con i colori nellimmagine) per realizzare il collegamento. La congurazione di questi servizi ` e stata centralizzata in un directory server che garantisce: omogeneit` a delle congurazioni, che non sono distribuite su vari le e server, ma controllate da un unico servizio; robustezza dei dati ed adabilit` a, infatti se un server andasse in crash, potremmo tirare su una sua copia e leggere le congurazioni dal directory server, che consideriamo adabile15 ;
Name Service, servizio di risoluzione dei nomi a dominio riguarda il riconoscimento di un utente sulla rete 15 il directory server sar` a replicato in diverse copie che si mantengono aggiornate da una copia principale, il master, e rispondono alle richieste in modalit` a load balancing
14 che 13 Domain

18

integrit` a dei dati, perch e laggiunta di nuove congurazioni non viene fatta modicando un le, ma tramite procedure personalizzate da noi create che garantiscono una certa protezione dagli errori umani e permettono di risalire facilmente alle informazioni relative ad un account, al suo possessore e, per esempio, ai computer registrati a suo nome.

2.5

Flessibilit` a, estensioni, aggiornamenti e modiche

Uno dei maggiori punti di forza della struttura ` e la sua essibilit` a: la separazione forte tra la struttura sica e la struttura logica della rete ci permette di giocare con le reti. Con il meccanismo delle VLAN disaccoppiamo completamente il concetto di dominio di collisione da quello di insieme di cavi, computer e switch collegati tra loro. Possiamo cio` e creare, eliminare o modicare una qualunque rete nella struttura semplicemente andando a lavorare sulle congurazioni delle VLAN. Possiamo anche creare delle reti distribuite sui vari piani delledicio ed associare un computer ad una qualunque di queste. Ci` o potrebbe sembrare controproducente, perch e un utente potrebbe collegarsi ad una rete alla quale non ` e autorizzato ad accedere, ma la congurazione degli switch decide, porta per porta, a quale rete possiamo accedere, e quindi limita laccesso di un computer ad una sola rete (la maggioranza dei casi). Laccesso a pi` u reti dovrebbe riguardare solo i computer di servizio, degli amministratori e altri server o postazioni che abbiano realmente tale necessit` a: la maggior parte dei computer dovr` a accedere solo ad una rete, con la possibilit` a di entrare nelle altre attraverso il router; questultimo pu` o permettere il passaggio di traco fra varie reti VLAN senza intaccare lisolamento a livello 2 della pila ISO/OSI dei singoli domini. La centralizzazione delle congurazioni nel directory server permette di modicare facilmente ed in modo veloce qualunque impostazione dei servizi. Con la vecchia struttura se, ad esempio, dovevamo aggiungere un nuovo desktop alla rete di INFN, avremmo dovuto inserirlo allinterno del le di congurazione del DHCP, poi aggiungerlo con un nome nel le di congurazione del DNS (avendo cura di modicare il seriale della zona modicata) ed inne riavviare tali servizi. Con la nuova struttura possiamo eettuare tutta questa congurazione in un colpo solo sul directory server, aggiungendo le dovute entry tramite linterfaccia da noi creata, come descritto nella sezione 4.9.

19

20

Capitolo 3

Tecnologie
Alcune delle tecnologie utilizzate in questo progetto sono datate e stabili, come il protocollo LDAP, altre pi` u recenti come lo standard IEEE 802.1q. Sono state scelte quelle che garantiscono la maggiore interoperabilit` a e che forniscono interfacce e metodi di accesso consolidati e standardizzati.

3.1

Virtual LAN

Una Virtual LAN o VLAN ` e un metodo di creazione di reti logiche indipendenti allinterno della stessa rete sica: permette di ridurre i broadcast domain1 e facilita lamministratore di rete separando logicamente i segmenti di una LAN esistente. In sostanza le VLAN sono un concetto astratto di separazione delle reti a livello logico. Vantaggi: 1. Aumenta il numero dei broadcast domain, riducendo la dimensione di ciascuno, che quindi riduce il traco di rete, aumentando la sicurezza della rete stessa 2. Riduce gli sforzi di gestione, soprattutto quelli connessi al mantenimento delle sottoreti 3. Riduce i requisiti hardware perch e le reti sono separate logicamente e non sicamente 4. Crea diversi switch logici allinterno dello stesso switch sico Il principale protocollo usato per congurare le VLAN ` e appunto lIEEE 802.1q, che descrive come possa essere partizionato il traco su un singolo network sico in pi` u reti logiche, assegnando un TAG (cio` e unetichetta) ad ogni frame con dei byte aggiuntivi che identichino la rete virtuale alla quale il pacchetto appartiene.
1 concetto delle reti Ethernet che identica linsieme dei dispositivi che ricevono il segnale trasmesso da uno qualunque dei nodi della rete, con una trasmissione detta appunto broadcast

21

3.1.1

Storia

Prima dellintroduzione dello standard IEEE 802.1q, esistevano diversi protocolli proprietari, come il Cisco ISL (Inter-Switch Link, una variante dellIEEE 802.10) e il VLT (Virtual LAN Trunk) di 3Com. Lo standard 802.1q nasce storicamente con questi obiettivi2 : le VLAN saranno implementabili su tutti i protocolli MAC dellarchitettura IEEE 802, su altri sistemi di comunicazione condivisi, ma anche su reti point-to-point le VLAN facilitano lamministrazione di gruppi logici di stazioni che comunicano come se fossero sulla stessa LAN. Facilitano anche la migrazione, laggiunta e la modica dei membri di un gruppo il traco tra le VLAN ` e ristretto; gli switch spediscono traco unicast, multicast e broadcast solo sui segmenti di LAN appartenenti ad una certa VLAN per quanto possibile verr` a mantenuta la compatibilit` a con gli switch e le stazioni gi` a esistenti

3.1.2

Funzionamento e terminologia

La separazione dei domini di collisione (o broadcast domain) lavora a livello 2 del modello ISO/OSI, cio` e al livello Data-Link. Nella terminologia delle VLAN, il termine trunk denota una rete che trasporta diverse VLAN, identicate da etichette inserite allinterno dei pacchetti. Come nel nostro caso esiste una rete comune che ospita tutte le VLAN. Questa rete ` e costituita da tutti gli switch di piano, dallo switch al centrostella e dal router di frontiera. Per motivi amministrativi il dominio principale ha come VLAN ID3 il valore 1, che indica la rete che noi chiamiamo rete di controllo. Sopra questa vengono creati dei domini separati, ciascuno dei quali ha uno specico VLAN ID. Per denire quali porte allinterno di uno switch appartengono ad un dominio si usa il meccanismo dei TAG. Il TAG ` e unetichetta che viene associata ad una porta dello switch e che permette il passaggio di traco per quel particolare dominio: il traco per un dominio viene discriminato controllando il campo VLAN ID della trama Ethernet in arrivo.

Figura 3.1: Trama Ethernet con IEEE 802.1q

Come mostra limmagine 3.1, nella trama Ethernet esiste il campo VLAN ID, allinterno del TAG, che contiene uno tra i possibili 4096 ID per dominio. Possiamo creare no a 4094 diversi domini sulla stessa rete e non 4096, perch e il
2 si 3 Virtual

veda il documento originale di standardizzazione dellIEEE [2] LAN IDentier, lidenticatore della rete virtuale

22

VLAN-ID 0 identica che un pacchetto non appartiene ad alcuna VLAN, mentre il VLAN-ID 4095 ` e riservato dal protocollo per motivi implementativi. I VLAN ID vengono decisi dallamministratore di sistema: dopo aver scelto un ID, questo deve essere congurato su tutti gli switch. Per aggiungere una porta di uno switch ad una VLAN basta congurare sullo switch stesso il TAG per quella particolare VLAN sulla porta. Una porta pu` o far passare traco per pi` u VLAN contemporaneamente. Esistono 2 modalit` a di congurazione delle porte di uno switch per il passaggio delle VLAN: a modalit` a TAGGED: con questa modalit` a possiamo assegnare un numero arbitrario di TAG a ciascuna porta dello switch; lo switch controller` a il traco in arrivo sulla porta e far` a passare solo quello etichettato con uno dei TAG VLAN deniti per quella porta. In questo modo per` o i pacchetti in arrivo devono gi` a contenere sullintestazione Ethernet, nel campo VLAN ID, il codice della VLAN a cui appartengono b modalit` a UNTAGGED: tutto il traco in arrivo sulla porta, per il quale non ` e denito il campo VLAN ID, viene taggato cio` e ad ogni pacchetto viene apposto il VLAN ID denito sulla porta in modalit` a UNTAGGED. Questo sistema serve per assegnare un VLAN ID ad uno stream di traco, senza che i PC sappiano dellesistenza delle VLAN Le due modalit` a possono coesistere sulla stessa porta, denendo un VLAN ID in modalit` a UNTAGGED ed 1 o pi` u VLAN ID in modalit` a TAGGED. Facciamo un breve esempio per esporre le due modalit` a. Modalit` a Tagged Come si vede in gura 3.2 una porta pu` o essere congurata in modalit` a Tagged per far passare il traco di una o pi` u reti (nel nostro caso la rete Blu, Verde e Rossa); il client che ` e connesso a quella porta deve prendersi carico di apporre il giusto VLAN ID ai pacchetti in uscita, in modo tale che lo switch possa commutare il pacchetto verso le porte della VLAN di appartenenza. Modalit` a Untagged In gura 3.3 si vedeil comportamente della stessa porta vista nella gura precedente, denendo un VLAN ID in modalit` a Untagged (nello specico il VLAN ID relativo alla rete Blu). Il client pu` o anche non conoscere il meccanismo delle VLAN, nel qual caso tutti i pacchetti uscenti non avranno nessun TAG denito (nella gura sono i pacchetti di colore bianco): a questi pacchetti senza un TAG lo switch appone il codice della VLAN Untagged, cio` e quello della rete Blu, come mostra limmagine. Se il client conosce le VLAN pu` o apporre esso stesso un VLAN ID ai pacchetti (si noti il pacchetto verde nellimmagine) che sar` a distribuito dallo switch a tutte le porte appartenenti a quel segmento VLAN. 23

Figura 3.2: Esempio di comunicazione in modalit` a Tagged

Figura 3.3: Esempio di comunicazione in modalit` a Untagged

3.1.3

Congurazione di VLAN su un computer

Dopo aver congurato le VLAN sugli switch, ci si chiede come associare un computer ad una Virtual LAN. Se colleghiamo il nostro computer ad una porta dello switch congurata in modalit` a UNTAGGED, non abbiamo bisogno di operare ulteriori congurazioni di sorta sul PC, perch e la denizione del VLAN ID viene demandata allo switch: in questo modo il nostro computer pu` o associarsi ad una sola rete. Per un server invece, che deve magari eseguire servizi per pi` u di una rete, abbiamo necessit` a di denire a livello di interfacce di rete i VLAN ID. Per fare questo i sistemi operativi moderni, come ad esempio GNU/Linux, prevedono un meccanismo di interfacce di rete virtuali cio` e delle astrazioni che permettano di denire dei wrapper 4 per le interfacce siche, ciascuno associato ad una VLAN diversa.
4 letteralmente rivestimento, in questo contesto identica un pezzo di software che fornisce uninterfaccia semplice allutente, nascondendo le speciche dellapplicazione che usa

24

Figura 3.4: Interfacce virtuali per luso delle VLAN

Come mostra la gura 3.4, in questo esempio abbiamo un computer con una sola interfaccia di rete reale, collegata ad una porta dello switch che fa passare in modalit` a TAGGED le VLAN 2 e 100. Ricordando che il meccanismo delle VLAN lavora a livello 2 della pila ISO/OSI, ci rendiamo velocemente conto che questo signica che dovremo avere un indirizzo IP per ognuna delle reti alle quali ci associamo5 . Per rappresentare questa situazione quindi si deniscono 3 interfacce virtuali, ciascuna delle quali ` e associata ad una VLAN diversa. Sui sistemi GNU/Linux possiamo usare il comando vcong, che ci permette di creare una nuova interfaccia di rete virtuale associata ad un certo VLAN ID. La sintassi per la creazione di una interfaccia di rete virtuale per una VLAN ` e: vconfig <interfacciaReteReale> <VLAN-ID> Eseguito il comando il sistema creer` a una interfaccia virtuale con nome interfacciaReteReale.VLAN-ID, per distinguere tra le interfacce create. A questo punto si pu` o usare il nuovo dispositivo virtuale come se fosse una vera e propria scheda di rete indipendente dalle altre, con un suo indirizzo IP e un suo stack di rete separato. A basso livello succede che viene creato uno stack IPV4/IPV6 separato al quale associamo un indirizzo e dei dati diversi da quello dellinterfaccia reale. Completate le fasi di analisi dei dati e di controllo il traco viene taggato, cio` e viene aggiunto il campo VLAN ID e viene passato allinterfaccia reale che non fa altro che mandarlo sulla rete sica. Sar` a poi compito dello switch smistare questo traco verso il resto della VLAN.
5 la rete descritta in questo progetto usa Ethernet come protocollo di basso livello e TCP/IP come protocolli di trasporto e di rete

25

Il meccanismo ` e simile a quello che sta alla base del networking per macchine virtuali. Infatti a ciascuna macchina virtuale possiamo far vedere solo le interfacce relative alle VLAN che la riguardano, cos` da aumentare la sicurezza per evitare che un intruso di una rete vada a bucare il server di unaltra rete (altro vantaggio della separazione dei domini di collisione).

3.2

Wireless

La tecnologia di connessione wireless ha cambiato il modo di pensare e di realizzare le reti di computer negli ultimi anni. Si parla oggi di Wireless Local Area Network, o WLAN, intendendo una rete locale realizzata con collegamenti senza li, via etere principalmente. Letere ha permesso il cablaggio di aree dove nora era dicile realizzare cablaggi con cavi metallici o con altre tecnologie, pensiamo ai palazzi storici magari con mura in pietra. Questo mezzo permette soprattutto la copertura di vaste aree aperte, come quelle delle grandi ere o di capannoni industriali a basso costo. Lo sviluppo delle reti wireless ha portato alla creazione di nuove tipologie di rete, vista la facilit` a di installazione e congurazione di un Access Point wireless, nello specico parliamo oggi di: PAN: Personal Area Network, reti personali del raggio di qualche metro, che servono a collegare periferiche come macchine fotograche digitali o stampanti ad un computer, ma anche per creare piccole reti di computer soprattutto per condividere le WLAN: Local Area Network wireless, sostitute senza li delle reti locali, spesso impiegate per condividere laccesso alla rete Internet a portatili posizionati in un raggio di qualche decina di metri dal punto di accesso WAN: Wide Area Network, reti ad ampio raggio che servono a collegare computer dislocati su vaste aree geograche, dellordine anche di vari chilometri, spesso costituite da un insieme di punti daccesso sotto la stessa gestione Per ciascuna di queste tipologie di rete esistono tecnologie e standard di riferimento che ottimizzano in un caso la velocit` a di connessione, in altri la larghezza dellarea di connettivit` a, in altri ancora ladabilit` a del servizio. Nel nostro caso la rete wireless non sostituisce la LAN tradizionale che rimane attiva per le postazioni sse degli uci, ma consente una connettivit` a alternativa per i portatili, soprattutto per gli utenti ospiti, che partecipano ad un meeting e che vogliono potersi connettere ad Internet con il loro laptop. Le frequenze a cui lavorano questi strumenti (access point wireless, schede di rete wireless, ripetitori) sono solitamente 2.4GHz e 5GHz: questi valori vengono decisi a livello governativo e le due frequenze appena citate sono riservate appunto per trasmissioni di questo tipo. Nel nostro caso, diversamente da una rete composta da un singolo punto di accesso wireless (o Access Point) connesso ad Internet, abbiamo diversi Access Point dislocati sui piani delledicio che devono annunciare tutti le stesse reti. Al contrario del cavo, sul quale passa il segnale di una rete, o comunque di reti conosciute, letere ` e libera ed aperta (anche se ci sono delle restrizioni 26

di legge sulle bande di frequenza utilizzabili per le trasmissioni). Nasce perci` o lesigenza di denire uno standard per lidenticazione di una rete nelletere.

3.2.1

Extended Service Set

Questo sistema ` e denito allinterno dello standard 802.11 (lo standard IEEE per le reti wireless): identica un insieme di Access Point wireless connessi alla stessa rete sica come un unico servizio. In pratica viene denito un nome per la rete wireless, detto SSID (Service Set IDentier) denito su tutti i punti di accesso del palazzo. Grazie alla funzione del roaming, prevista dallo standard IEEE 802.11, un utente della LAN wireless cos` denita pu` o passare da una cella, cio` e dal raggio di azione di un Access Point, allaltra senza risentire di alcuna interruzione del servizio in modo totalmente trasparente. Riassumendo, lSSID permette lidenticazione di una rete wireless nelletere e il roaming tra due access point che appartengono alla stessa rete. Lidenticatore di una rete wireless si chiama ESSID, Extended Service Set Identier, e permette lidenticazione della rete, solitamente ` e una stringa che, anche semanticamente, rappresenta lutilizzo o il proprietario della rete.

3.2.2

Il progetto INFN/TRIP

Il progetto INFN TRIP (The Roaming INFN Physicist) nasce allinterno del Comitato Calcolo e Reti dellIstituto Nazionale di Fisica Nucleare e tenta di dare una risposta alla necessit` a dei dipendenti e dei ricercatori dellistituto di avere una connessione ad Internet anche quando questi si trovino in una sezione dellistituto diversa dalla propria, ad esempio per un convegno o una riunione. Come si legge nel documento di presentazione del progetto6 , le necessit` a alle quali tenta di rispondere sono: collegarsi alla rete locale e utilizzare da remoto i servizi della Struttura di appartenenza; utilizzare i servizi della Struttura ospitante (ad es. le stampanti) mettere le basi per una infrastruttura di Autenticazione ed Autorizzazione che possa essere sfruttata anche per altri servizi Fino a oggi, un ospite di una sezione INFN, anche se dipendente o associato allistituto7 , qualora si trovasse in una sezione diversa dalla sua, avrebbe dovuto contattare lamministratore di rete di quella struttura e fare una richiesta di accesso (fornendo quindi i propri dati personali). Con questa nuova infrastruttura, non ci sar` a pi` u bisogno di fare richieste, perch e baster` a autenticarsi sul server della sezione di provenienza, per essere autenticati anche sui server delle altre sezioni italiane, con il meccanismo del RADIUS proxying, che verr` a spiegato nel paragrafo 3.3.4, qui riportato nella gura 3.5. In questo modo si snellisce sia il lavoro degli amministratori di sistema, che la burocrazia necessaria. Questa struttura potrebbe benissimo essere esportata
6 si 7 per

veda la guida allimplementazione [3] una descrizione della struttura e dellorganizzazione dellINFN si veda il paragrafo

1.1.2

27

Figura 3.5: Meccanismo di proxying del server RADIUS

in qualunque ente organizzato in modo simile a INFN. I passaggi necessari per autenticarsi nella struttura ospitante sono: 1. richiesta dellutente; 2. trasmissione della richiesta alla Struttura di appartenenza per vericarne la legittimit` a; 3. trasmissione dellautorizzazione dalla Struttura di appartenenza a quella ospitante. Il progetto prevede 2 meccanismi principali di accesso che si basano entrambi sulla presenza di un servizio di autenticazione (il proxy RADIUS) che permette lautenticazione di un utente di qualsiasi sezione INFN. I meccanismi previsti da TRIP sono: IEEE 802.1x Captive Portal Il protocollo IEEE 802.1x Il protocollo IEEE 802.1x ` e uno standard per il controllo degli accessi ad una rete. Permette lautenticazione di dispositivi collegati ad una porta LAN, stabilendo una connessione point-to-point8 con il client o impedendo laccesso qualora questi fallisca lautenticazione. Viene utilizzata anche sugli access point per reti wireless ed ` e basato su EAP9 . Il protocollo pu` o essere localizzato a livello data-link della pila ISO/OSI; va ricordato che nasce come protocollo per reti cablate (infatti appartiene alla famiglia 802.1). Lutilizzo in reti wireless permette di superare alcune vulnerabilit` a di WEP10 .
8 connessione 9 Extensible

diretta fra due postazioni Authentication Protocol, protocollo di autenticazione spiegato nel prossimo

paragrafo 10 Wired Equivant Privacy, protocolo di protezione delle comunicazioni wireless, denito dallo standard IEEE 802.11i

28

Lautenticazione avviene tra il client (detto anche supplicant) e lAccess Point (detto anche authenticator), ma il controllo delle credenziali, cio` e lautenticazione vera e propria, viene eettuata da una terza entit` a, come un server RADIUS. Questo garantisce una autenticazione forte attraverso protocolli come lEAP-TLS. Questa commistione di accesso wireless e autenticazione 802.1x (nata per reti cablate) viene, impropriamente, denita come 802.11x (per alludere al protocollo 802.11 per laccesso wireless). Vediamo il processo di autenticazione in 802.1x (sintetizzato nella gura 3.6): 1. quando uno switch (o un access point per il wireless) riconosce che un client (usiamo il termine supplicant, pi` u appropriato) si ` e collegato ad una porta, o comunque sta tentando di accedere, lo switch abilita la porta e la mette in stato unauthorized (non autorizzato); in questo stato viene bloccato qualunque tipo di traco, a livello data link, ad esempio DHCP o HTTP, ad eccezione del traco 802.1x; 2. lauthenticator (lo switch o lAP) manda una EAP-Request al client; 3. il supplicant risponde con una EAP-Response che lauthenticator inoltrer` a al server di autenticazione; 4. il server di autenticazione (nel nostro caso RADIUS) pu` o accettare o rigettare la richiesta; 5. se accetta, lauthenticator metter` a la porta in stato authorized e quindi far` a passare il traco normale; quando il supplicant si disconnetter` a, mander` a un messaggio di EAP-logo allauthenticator che rimetter` a la porta in stato unauthorized; 6. se la richiesta ` e stata rigettata, la porta rimane in stato unauthorized e il supplicant potr` a tentare di nuovo lautenticazione.

Figura 3.6: Schema di una sessione di autenticazione 802.1x

Il protocollo garantisce un alto livello di sicurezza ed ` e essibile, perch e permette di usare vari algoritmi e meccanismi di autenticazione in EAP. 29

Il protocollo EAP Il protocollo EAP, Extensible Authentication Protocol, ` e un framework di autenticazione utilizzato nelle connessioni wireless e point-to-point, ma anche su ` denito nellRFC11 3748. LAN cablate. E Si noti che EAP non ` e un meccanismo di autenticazione, ma un framework, che fornisce supporto per vari meccanismi di autenticazione (detti metodi EAP). Alcuni metodi come EAP-MD5, EAP-TLS ed EAP-TTLS utilizzano tecniche comuni, mentre si possono sviluppare meccanismi di autenticazione personalizzati sopra EAP. Quando viene avviata una sessione EAP, da un Access Point wireless ad esempio, vengono avviate le procedure necessarie alla creazione del tunnel di comunicazione per lautenticazione LEAP-TLS (EAP Transport Layer Security), denito nellRFC 2716 ` e uno standard molto buono per lautenticazione sicura; utilizza TLS che viene considerato il successore del famoso standard SSL12 . Usa la PKI13 per instaurare comunicazioni sicure tra authenticator e server di autenticazione. Il suo svantaggio pi` u grande ` e il forte overhead necessario per mettere in sicurezza le comunicazioni, ` e considerato infatti uno degli standard pi` u sicuri ed ` e supportato dalle maggiori aziende del settore. La sua forza risiede principalmente nella necessit` a, da parte dellutente, di un certicato. Perci` o non basta rubare una password per autenticarsi, ma bisogna avere un certicato valido per entrare, che quindi aumenta la sicurezza. Se inne i certicati fossero memorizzati su un supporto sico come una smart card o una penna USB, sarebbe molto dicile, per un attaccante, accedere alla rete senza rubare anche la smart card o la penna USB. Lo standard EAP-MD5, denito nellRFC 3748, ` e un altro standard, aperto, ma che garantisce una sicurezza relativamente bassa; si basa infatti sulle funzioni hash MD5 che sono vulnerabili ad attacchi basati su dizionari e non garantiscono quindi una protezione ragionevole. Il progetto TRIP consiglia di utilizzare il protocollo EAP-TLS che garantisce una sicurezza molto alta; in futuro potrebbe essere prevista lautenticazione con smart card contenenti certicati X.509 che possono essere utilizzati anche per laccesso ad altre risorse oltre che alla connettivit` a wireless. TRIP supporta numerosi metodi di autenticazione, in particolare via certicato X.509. Captive portal Il Captive Portal ` e un meccanismo molto user-friendly per controllare gli accessi su una rete wireless. Molti punti di accesso wireless, alberghi, stazioni ferroviarie, aereoporti o grandi citt` a (ad esempio Roma) prevedono reti wireless ad ampio raggio con autenticazione su Captive Portal. Lidea si basa sulla delega dellautenticazione ad un server di autenticazione; in questo contesto gli Access Point hanno una congurazione ed una conoscenza
11 Request For Comment, documenti di standardizzazione di formati e protocolli dellIETF, Internet Engineering Task Force 12 Secure Socket Layer, implementazione di un socket di comunicazione cifrato 13 Public Key Infrastructure, descritta nel paragrafo 3.4.2

30

delle informazioni di autenticazione molto ridotta (il che ne facilita il deployment); basti pensare a quanto man-power si guadagna in questo modo rispetto allelencazione di tutti i MAC-address14 che hanno accesso alla rete. Lautenticazione viene spostata dalla fase di associazione e assegnazione dellindirizzo IP alla fase di accesso alla rete pubblica. Vediamo in dettaglio la procedura che un client deve eseguire per accedere ad una rete di questo tipo (schematizzata in gura 3.7): 1. il client si associa al SSID della rete che prevede autenticazione con Captive Portal; 2. lAP lo associa e lo connette alla rete; il server DHCP prontamente gli fornisce un indirizzo IP, una maschera di rete, lindirizzo del gateway e tutte le altre informazioni necessarie alla navigazione (come server DNS ecc..); 3. il client ora ha accesso alla rete, ma lunica cosa visibile, appena connesso, ` e il gateway della rete stessa, che gli impedisce di uscire sulla rete esterna; 4. a questo punto deve aprire una nestra del suo web browser e connettersi al sito che preferisce (proprio qualunque sito): invece della solita pagina, la richiesta viene intercettata dal gateway della rete che propone una schermata di login per lautenticazione; 5. le credenziali da inserire possono essere varie: di solito si richiede accesso su nome utente/password; ma si pu` o anche pensare di richiedere una onetime password15 ad esempio per un convegno che dura un giorno; possiamo anche prevedere (come per la rete che stiamo implementando) laccesso tramite certicato digitale personale installato sul browser, che accetta la richiesta se riconosce valido il certicato; 6. la richiesta pu` o essere gestita in svariati modi: tramite uno script CGI, uno script PERL, PHP e usare come server di autenticazione RADIUS, LDAP, Linux PAM ecc.; 7. se lutente inserisce le credenziali giuste, viene visualizzata una schermata di successo e nalmente ` e consentita la navigazione sulla rete esterna. Quello che succede nel gateway, se lautenticazione riesce, ` e che viene aggiunta una regola per far passare il traco proveniente da quel particolare indirizzo IP.

3.2.3

La rete aperta per i convegni

La rete aperta (con ESSID Open) ` e utilizzata in caso di convegni, seminari ed in generale eventi che prevedono laccesso wireless ad Internet ad utenti che non sono registrati.
14 MAC sta per Medium Access Control; il MAC address ` e un numero identicativo, composto da 6 coppie di cifre esadecimali che identica un dispositivo sulla rete a livello Data Link 15 stringa di autenticazione valida per un tempo limitato che pu` o essere usata una volta sola

31

Figura 3.7: Schema dellautenticazione via Captive Portal

Il meccanismo di accesso ` e uguale a quello visto nella precedente sezione con Captive Portal. Perci` o gli utenti che partecipano al meeting, dovranno associarsi alla rete wireless OPEN e nel loro browser apparir` a la nestra di login. Per questa rete abbiamo scelto di non creare un nuovo account per ogni utente, cosa che comporterebbe un impegno di tempo e lavoro non indierente; creiamo invece un numero suciente di account anonimi, del tipo USER001, ed assegniamo questi account ai partecipanti dopo una registrazione. In questo modo non dovremo registrare i dati personali di ogni partecipante, se non per quanto concerne le pratiche burocratiche necessarie allaccesso, e non dovremo creare ogni volta account che poi verrebbero subito cancellati. Per implementare questa funzione baster` a creare degli account statici che verranno autenticati tramite server RADIUS; il RADIUS verr` a contattato dal Captive Portal della rete OPEN per lautenticazione. Il RADIUS, vista la staticit` a delle informazioni, potrebbe leggere i dati degli utenti anonimi anche da le; si prevede comunque la possibilit` a di registrare questi account sulla directory LDAP per mantenere eventualmente traccia dellassociazione persona/account.

3.3

Sicurezza, autenticazione e controllo: RADIUS

Dopo aver elogiato i numerosi vantaggi della connettivit` a wireless, dobbiamo considerare laltro lato della medaglia, soprattutto analizziamo il tema della sicurezza. La tecnologia wireless introduce nelle reti dei problemi che nora potevano essere trascurati: con i cavi, potevamo essere quasi sicuri che i computer con32

nessi alla rete erano quelli che conoscevamo, perch e i cavi, gli switch e le altre apparecchiature possono essere messe sotto controllo, con armadi chiusi e lucchetti. Con lavvento delle reti wireless, qualunque computer dotato di una scheda di rete wireless, che si trovi allinterno della cella del nostro Access Point pu` o potenzialmente accedere alla rete, senza chiedere autorizzazione a nessuno. Certamente letere ` e meno controllabile di un cavo che noi stendiamo! Per considerazioni di questo tipo, non possiamo pi` u darci del fatto che chi riesce ad accedere alla rete ` e anche autorizzato a farlo. Dobbiamo dotare la rete, e nello specico gli Access Point, di meccanismi di controllo e di autenticazione. Vediamo alcuni meccanismi di protezione e limitazione degli accessi: limitare i MAC address che possono accedere: meccanismo veloce, facilmente implementabile, ma che pu` o essere aggirato tramite MAC-spoong, cio` e modicando lindirizzo sico della propria scheda di rete wireless con uno abilitato allaccesso; chiave WEP: meccanismo buono di cifratura dei messaggi, che utilizza chiavi da 40 bit, ma che pu` o essere aggirato in pochi minuti; cifratura forte: nome sotto il quale possiamo far rientrare quei meccanismi che prevedono lautenticazione dellutente su un tunnel cifrato di dati; questo meccanismo ` e molto dicile da aggirare, perch e intervengono molti elementi nella fase di autenticazione, tra cui i dati dellaccount (nome utente e password) e i certicati digitali.

3.3.1

AAA e RADIUS

Quello che serve ad una rete wireless che deve servire centinaia di utenti ` e di poter denire a livello centralizzato delle politiche e delle propriet` a che possano essere assegnate ai client wireless (o supplicant) da tutti gli Access Point che costituiscono la rete. Quello che ci serve ` e una infrastruttura di AAA, cio` e di Autenticazione, Autorizzazione e Accounting. Spieghiamo brevemente il signicato di questi termini16 : Autenticazione: si intende la conferma che un utente che richiede un servizio, nel nostro caso laccesso alla rete, sia un utente valido e conosciuto. Viene realizzata con la presentazione di una identit` a o di credenziali, che ad esempio possono essere una password, lindirizzo MAC della scheda wireless di un portatile o un certicato digitale. Autorizzazione: si intende laccesso a specici servizi ad un utente, basandoci sulla sua autenticazione, su quale servizio ha richiesto e sullo stato corrente del sistema. Pu` o basarsi su politiche che tengano in considerazione lorario di richiesta del servizio, la collocazione sica del richiedente e informazioni simili.
16 dal

sito di Wikipedia - The Free Encyclopedia [4]

33

Accounting: si intende il tracciamento del consumo delle risorse di rete di un utente. Queste informazioni possono essere utilizzate per la gestione futura, per motivi statistici, o magari per redigere un conto mensile (come viene fatto negli ISP). Vengono solitamente memorizzate informazioni sullidentit` a dellutente, sulla natura del servizio fornito e sullorario di inizio e di ne della fruizione. Di queste tre A, noi utilizzeremo solo le prime due, visto che non dovendo far pagare la connessione agli utenti della rete non abbiamo bisogno di conteggiare i tempi di connessione. Per implementare queste politiche utilizziamo un server RADIUS. RADIUS sta per Remote Authentication Dial In User Service, ` e un protocollo che implementa politiche di AAA per laccesso alla rete. Il protocollo RADIUS prevede il controllo delle credenziali di un utente e la fornitura dei parametri di accesso e di altri valori necessari alla connessione. Per le nostre necessit` a il server RADIUS verr` a usato solo per controllare le credenziali di accesso di un utente, a vari livelli. Il protocollo RADIUS ` e denito negli standard: RFC 2865 Remote Authentication Dial In User Service (RADIUS) RFC 2866 RADIUS Accounting

3.3.2

Il protocollo RADIUS

Come si legge nellRFC17 , le caratteristiche chiave del protocollo RADIUS sono: Modello Client/Server Un Network Access Server (NAS) opera come client per RADIUS. Il client ` e responsabile del passaggio delle informazioni dellutente al server RADIUS opportuno e deve poi agire in accordo alla risposta ricevuta. Il server RADIUS ` e responsabile della ricezione della richiesta di connessione dellutente, dellautenticazione dellutente e dellinvio di tutte le informazioni di congurazione necessarie perch e lutente possa usufruire del servizio tramite il client. Sicurezza di rete Le transazioni tra client e server RADIUS sono autenticate tramite un segreto18 condiviso che non ` e mai trasmesso in rete. Inoltre, tutte le password utente vengono criptate tra i due attori per proteggere tali informazioni da intrusi che potrebbero attaccare la rete per trovare la password. Meccanismi di autenticazione essibili RADIUS supporta una vasta gamma di metodi per autenticare un utente. Quando un server riceve nome utente e password, pu` o eseguire un login PPP, PAP o CHAP o UNIX19 o altri meccanismi di autenticazione.
veda il documento originale [5] segreta condivisa tra il client e il server RADIUS per proteggere le comunicazioni 19 queste sigle rappresentano vari sistemi di autenticazione che non verranno approfonditi in questa sede e che non sono utilizzati in questo progetto
18 stringa 17 si

34

` e un protocollo estendibile Tutte le transazioni comprendono tuple di lunghezza variabile del tipo (Attributo, Lunghezza, Valore). Perci` o possono essere aggiunti nuovi attributi senza disturbare limplementazione gi` a esistente. Unaltra cosa importante da evidenziare del protocollo RADIUS ` e che lavora usando connessioni UDP20 , invece che TCP21 . UDP ` e stato scelto per ragioni prettamente tecniche: un server RADIUS intrattiene delle conversazioni di tipo transazionale, con caratteristiche particolari, tra cui: se una richiesta al server primario fallisce, si pu` o interrogare il server di backup; le particolari necessit` a riguardo i tempi di risposta non vanno daccordo col TCP. Da un lato RADIUS non ha bisogno di tecniche di rilevazione delle perdite di dati immediate: lutente pu` o attendere alcuni secondi perch e lautenticazione sia completata senza troppi problemi; in questo contesto le ritrasmissioni aggressive del TCP e londata di acknowledgement tipiche di questo protocollo non sono necessari. Dallaltro lato lutente non vuole aspettare dei minuti perch e lautenticazione sia completata: non ci interessa che il TCP fornisca una connessione adabile 2 minuti dopo aver fatto la richiesta... con UDP possiamo semplicemente provare a ri-autenticarci sul server di backup senza troppi problemi. il protocollo RADIUS ` e stateless: i client e i server vanno e vengono; UDP garantisce semplicit` a delle comunicazioni eliminando qualunque controllo ulteriore sullo stato delle connessioni e dei server. Infatti una sessione di autenticazione con UDP consiste nello scambio di alcuni pacchetti e ... niti i giochi. UDP semplica limplementazione del server: le prime implementazioni di RADIUS consistevano in un server single threaded, cio` e una sola richiesta alla volta era ricevuta ed evasa e le altre rimanevano in coda (con evidenti ritardi). Oggi tutte le implementazioni prevedono un thread separato per ogni nuova richiesta e il protocollo UDP facilita la spedizione di un messaggio di risposta ad un client con il suo formato snello e veloce e con evidenti vantaggi per il sistema e per lutente. Vediamo quali sono le operazioni che vengono eseguite per lautenticazione; si veda anche lo schema nellimmagine 3.8. Quando un client ` e congurato per usare RADIUS, ogni utente del client22 presenta delle informazioni di autenticazione, ad esempio con una schermata di login o con un protocollo come PPP che possiede pacchetti di autenticazione. Dopo aver ottenuto tali informazioni, il client sceglie di autenticare tramite RADIUS: prima di tutto crea una Access-Request che contiene tra gli altri, il nome utente e la password, lID del client e lID della porta alla quale accede
Datagram Protocol, protocollo che permette di spedire messaggi detti datagram su una rete di computer 21 Trasmission Control Protocol, protocollo di trasporto dei dati a livello 4 della pila ISO/OSI 22 nel protocollo RADIUS quando si parla di client, si intende un NAS, cio` e un punto di accesso alla rete, come un Access Point wireless
20 User

35

lutente. La password viene nascosta usando lRSA Message Digest Algorithm MD523 . Il pacchetto di Access-Request viene inviato al server RADIUS, se non si riceve risposta dopo un certo tempo, la richiesta viene riinviata per un numero determinato di volte; possiamo anche scegliere di mandarla ad un server secondario. Ricevuta la richiesta dal server, viene validato il client (che deve essere tra quelli riconosciuti ed elencati nel le clients.conf ) tramite il segreto condiviso (anchesso scritto nel le client.conf ); se non viene riconosciuto, la richiesta viene subito scartata. Se viene accettata, il server RADIUS consulta il database per cercare lutente e per controllare anche altri parametri che possono essere presenti; se ` e necessario, la richiesta pu` o essere rigirata ad altri server (cio` e il primo server agisce come client per un altro). Se uno di questi test non viene superato, allora viene restituito un pacchetto di Access-Request che indica che la richiesta ` e stata riutata. Opzionalmente pu` o essere incluso un messaggio testuale di riuto. Se sono soddisfatte le condizioni suddette allora il server RADIUS restituisce un pacchetto di AccessChallenge; successivamente il client che riceve un Access-Challenge risponde rispedendo il messaggio di Access-Request originale con un nuovo request-ID. Il server che riceve questo messaggio pu` o rispondere con un Access-Accept, un Access-Reject o un altro Access-Challenge. Se il client riceve un pacchetto di Access-Challenge, fornisce allutente un prompt per fornire una risposta. Il client quindi rispedisce la domanda con un nuovo request ID con, al posto del campo User-Password, la risposta dellutente. Il server pu` o rispondere con un Access-Accept, Access-Reject o un altro AccessChallenge. Se tutti i requisiti sono soddisfatti, allora i valori di congurazione per laccesso vengono inseriti nella risposta di Access-Request. Nel nostro caso non verr` a usato il meccanismo di challenge/response, ma se i requisiti sono soddisfatti gi` a alla prima richiesta, viene subito spedito un pacchetto di Access-Accept.

3.3.3

Il nostro server RADIUS

Il nostro server RADIUS ` e sostanzialmente un deposito di dati di autenticazione che possono essere interrogati dagli access point per controllare le credenziali di accesso di un computer. I dati che memorizziamo comprendono gli indirizzi MAC delle schede di rete registrate che useranno la rete wireless e lo username e password per i portatili che intendono usare sistemi di autenticazione wireless pi` u sicuri. Questultimo sistema verr` a utilizzato anche per il controllo delle credenziali di accesso per i Captive Portal come vedremo pi` u avanti. Come gi` a anticipato allinizio sulla presentazione del progetto, uno dei punti forti della struttura ` e la sua centralizzazione. Quindi, come ci possiamo aspettare, le credenziali di accesso, cio` e sia i MAC address che gli account (username & password) autorizzati, sono memorizzati sul servizio informativo
23 algoritmo

di hash molto usato in crittograa

36

Figura 3.8: Processo di autenticazione RADIUS standard

(LDAP) centrale della rete, come mostrato nella gura 3.9. Con questo meccanismo il server RADIUS non contiene alcuna informazione di sicurezza, tranne quelle che mantiene in cache per velocizzare levasione delle richieste. Cos` facendo possiamo realizzare anche pi` u server RADIUS special purpose, ciascuno specializzato per servire una particolare rete e per assolvere ad un compito, installandoli su macchine virtuali separate. Ciascuno di questi server, come infatti prevede il progetto, ha un compito ben specico. Le categorie di server RADIUS che abbiamo implementato nel progetto sono principalmente 2: RADIUS per lautenticazione dei MAC ADDRESS: questo sistema autorizza o meno il MAC address di una scheda wireless se questa ` e registrata nellelenco delle schede autorizzate. Il meccanismo di autorizzazione abusa del protocollo RADIUS perch e per scambiare queste informazioni (riguardanti gli indirizzi sici) utilizza i campi Username e User-Password del protocollo RADIUS (si notare che questo comportamente ` e quello standard in tutti gli AP che supportano RADIUS) RADIUS per lautenticazione su nome utente e password: questo sistema autorizza o meno un account se le credenziali di accesso sono corrette e se si appartiene al gruppo a cui aerisce il server RADIUS. Infatti sul server delle congurazioni (LDAP) risiedono le informazioni di accesso per la rete wireless. Per bilanciare meglio il carico tra i server RADIUS, e per separare bene i punti di accesso delle varie reti si ` e deciso di creare un server RADIUS per ognuna delle reti wireless e nello specico esistono i server: RADIUS per WL-common (sia Fisica che INFN): questo server evade tutte le richieste dalla VLAN che comprende gli host della rete WL-common 37

Figura 3.9: Schematizzazione dei servizi RADIUS centralizzati su LDAP

(la rete wireless con controllo sui MAC address); le richieste che ricever` a riguarderanno informazioni di autenticazione sui MAC address. La query verr` a fatta al server LDAP sulla cartella dei MAC address. RADIUS per STUD: similmente alla prima, autentica gli studenti del dipartimento di Fisica, che si connettono sulla rete STUD, sempre con il proprio MAC address registrato su LDAP. Inoltre, la politica di routing di questa rete prevede che tutte le connessioni vengano ltrate da un server PROXY ad accesso con nome utente e password sempre registrate su LDAP. RADIUS per le credeziali INFN (sia per Captive Portal, INFN-web, che per INFN-dot1x): questo server, che come gli altri risponde con le informazioni memorizzate su server LDAP, autentica gli utenti delle reti INFN; inoltre lautenticazione su nome utente e password pu` o essere usata anche per altri servizi, come il login remoto su macchine dedicate, o laccesso a pagine web riservate ai dipendenti o agli associati INFN. Questo server RADIUS, diversamente dagli altri, entra a far parte di una gerarchia di server AAA24 , che tramite il meccanismo del proxying 25 permette di autenticare anche utenti aerenti alle altre sezioni italiane di INFN. RADIUS per le credeziali del Dipartimento di Fisica (sia per Captive portal, FISICA-web, che per FISICA-priv): come il precedente autentica gli aerenti al Dipartimento di Fisica sempre con utente e password; anche
24 si 25 si

parla si AAA nel paragrafo 3.3.1 parla del proxying nel paragrafo 3.3.4

38

per questa autenticazione ` e previsto per il futuro un meccanismo di proxying quando esister` a uno standard condiviso tra tutte le universit` a per lautenticazione degli studenti e dei dipendenti. RADIUS per laccesso ai convegni: questo RADIUS verr` a utilizzato solo durante meeting, convegni o eventi che richiedano laccesso wireless di persone esterne al Dipartimento e ad INFN; laccesso sar` a basato su Captive Portal, per tracciare le connessioni; si prevede di denire delle utenze anonime, del tipo USER001, che verranno fornite ai partecipanti allevento e saranno cancellate alla ne dello stesso, sempre memorizzate su back-end LDAP.

3.3.4

FreeRADIUS

Tra le varie possibili alternative ` e stato scelto FreeRADIUS per la gestione del protocollo RADIUS, versione 1.1.3. FreeRADIUS ` e il software libero per protocollo RADIUS pi` u diuso26 ; ci sono pi` u di 50000 installazioni documentate, tra cui piccoli siti con decine di utenti, aziende su larga scala con decine di centinaia di utenti, no a installazioni di grandi Carrier internazionali con decine di milioni di utenti. I dati che leggiamo nel sito del progetto ci parlano di 100 milioni di utenti serviti attraverso il software FreeRADIUS. Questo ci d` a una stima della forte scalabilit` a dellimplementazione che passa senza troppi problemi da sistemi embedded con poca memoria no a sistemi con milioni di utenti. Supporta i protocolli di autenticazione PAP, CHAP, MSCHAP, EAP-MD5, EAP-GTC, EAP-TLS, EAP-TTLS, PEAPv0, LEAP, EAPSIM e Digest. FreeRADIUS ` e una suite di applicazioni per il protocollo RADIUS modulare, ad alte prestazioni e ricca di funzionalit` a; comprende un RADIUS server, un client (utilizzato soprattutto per i test), delle librerie di sviluppo (per utilizzare le chiamate RADIUS nelle proprie applicazione e/o per creare moduli aggiuntivi) e numerose utilities. Tra le varie caratteristiche che hanno decretato il successo e il largo impiego di FreeRADIUS citiamo: supporto al request proxying, cio` e la possibilit` a di rispedire una richiesta ad un server autoritario di pi` u alto livello, secondo un meccanismo a PROXY (lo stesso meccanismo impiegato nellinfrastruttura AAI di INFN) fail-over e load balancing delle richieste tra diversi server possibilit` a di utilizzare come back-end, cio` e come deposito delle informazioni di autenticazione e autorizzazione vari tipi di database (nel nostro caso usiamo LDAP, ma si possono utilizzare database su le, ad esempio possiamo utilizzare il le /etc/passwd di GNU/Linux, database SQL, password da domini SMB ecc.) anche le informazioni di accounting possono essere memorizzate su vari backend tra cui appunto LDAP e database SQL (ma questa caratteristica come gi` a detto non ` e stata utilizzata nel nostro progetto).
26 queste

notizie sono riprese dal sito uciale di FreeRADIUS [6]

39

Congurazione di un server RADIUS con backend LDAP Questa congurazione merita di essere anticipata in questo capitolo dedicato alle Tecnologie. FreeRADIUS presenta unarchitettura modulare, nella quale possiamo denire da quali fonti devono essere lette le informazioni di autenticazione e autorizzazione per evadere le richieste. Di solito, per le realt` a piccole, viene usato il le di congurazione users, nel quale sono memorizzati staticamente i parametri di accesso. Nel nostro caso dobbiamo dire al server RADIUS di recuperare le informazioni dalla directory LDAP centrale. La congurazione ` e molto semplice: deniamo allinterno del modulo ldap gli attributi necessari; in particolare troviamo: server = authserver.fisica.unipg.it: il server LDAP dal quale leggere gli attributi (si noti che il nome punta ad un alias nel DNS che opera load balancing sulle varie repliche del server centrale) identity = cn=Manager,dc=priv e password = ********: le credenziali di accesso al server LDAP (naturalmente il server non ` e protetto solo con password, sono ristetti anche gli host che possono accedervi) basedn = ou=radiusmac,dc=priv: come si vedr` a pi` u avanti il base DN ` e la cartella della directory LDAP alla quale vogliamo accedere; nel nostro caso si vuole accedere alla cartella contenente i MAC address autorizzati; filter = (&(uid=%User-Name)(PerugiaGroups=radius-wlcommon)): con questo ltro cerchiamo una entry LDAP che abbia come uid proprio il MAC address o lusername che si sta cercando; il resto del confronto viene fatto sul campo standard userPassword, sempre usando come valore o il MAC address, se il server prevede accesso con MAC address, oppure la password inserita dallutente. ldap { server = "authserver.fisica.unipg.it" identity = "cn=Manager,dc=priv" password = ******** basedn = "ou=radiusmac,dc=priv" filter = "(&(uid=%{User-Name})(PerugiaGroups=radius-wlcommon))" start_tls = no dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 } Gli altri campi hanno poco interesse a questo livello di analisi. Molte delle cose lasciate in sospeso saranno analizzate pi` u approfonditamente nel paragrafo dedicato ad LDAP.

40

RADIUS proxying Con il meccanismo dei proxy RADIUS, un server che riceve una richiesta di autenticazione, rispedisce la richiesta ad un server RADIUS remoto; riceve la risposta da questo server remoto e rispedisce la risposta indietro al client, possibilmente modicando il pacchetto per riettere le necessit` a del sito locale. La scelta di quale server interrogare per evadere una richiesta viene fatto attraverso il realm. Il realm pu` o far parte del Network Access Identier (lidentit` a dellutente per la rete). Lidea del realm ` e quella di separare vari domini di lavoro; un concetto simile al dominio DNS. Un server RADIUS pu` o funzionare sia come forwarding server, cio` e come proxy per altri server, che come server remoto, cio` e come server terminale per una richiesta. Un singolo RADIUS pu` o avere un numero arbitrario di server a cui spedire richieste. Possono essere create anche delle catene di proxy, ad esempio per rispecchiare le suddivisioni amministrative di una azienda (evitando di creare dei loop). Nel nostro caso il server RADIUS di INFN implementer` a la funzione di proxying. Il server al quale demander` a le richieste sar` a quello della sede centrale nazionale di INFN, che pu` o autenticare gli utenti di qualunque sezione italiana (si veda limmagine 3.5 per uno schema del proxying RADIUS). Uno schema della gerarchia dei server INFN ` e riportato in gura 3.10.

Figura 3.10: Struttura gerarchica dei server RADIUS INFN

41

Il meccanismo di gestione e congurazione dei REALM verr` a analizzato pi` u avanti nel paragrafo 4.3.3.

3.4

Certicati digitali X.509: sicurezza garantita

X.509 ` e uno standard ITU-T27 per linfrastruttura a chiave pubblica (PKI).

3.4.1

Crittograa

La crittograa ` e quella scienza che studia i meccanismi per nascondere il contenuto di un messaggio a chi non ` e autorizzato a leggerlo. Storicamente le tecniche usate si basavano sulla conoscenza di un segreto da parte di tutti gli interlocutori della comunicazione privata: il segreto poteva consistere in una tabella di corrispondenze di simboli a lettere dellalfabeto, o magari in un numero che permettesse linterpretazione del messaggio; il segreto era protetto e non doveva essere rivelato ad altri. Questo meccanismo della chiave condivisa va sotto il nome di crittograa a chiave privata o simmetrica. In informatica, questo meccanismo viene implementato utilizzando la chiave di cifratura, solitamente un numero o un insieme di numeri: il messaggio viene sottoposto ad alcuni passaggi matematici che utilizzano la chiave come valore di riferimento per perturbare il messaggio e renderlo incomprensibile, cio` e cifrarlo. Per riottenere il messaggio originale il ricevente, che conosce la chiave con cui il messaggio ` e stato cifrato, applica un procedimento analogo ma contrario che permette di riottenere il messaggio originale, detto anche messaggio in chiaro (come mostrato in gura 3.11).

Figura 3.11: Meccanismo di cifratura simmetrica

La crittograa a chiave pubblica, o asimmetrica, ` e una forma di crittograa nella quale un utente possiede, invece di una singola chiave condivisa con laltro utente, una coppia di chiavi, pubblica e privata. La chiave privata viene tenuta segreta, mentre quella pubblica pu` o essere diusa liberamente. Le chiave vengono generate attraverso dei procedimenti matematici che garantiscono una buona sicurezza verso eventuali attaccanti - la loro forza si basa sulla dicolt` a di fattorizzare numeri molto grandi.
27 Internation Telecommunication Union - Telecommunication Standardization Sector, ovvero il Dipartimento di standardizzazione delle telecomunicazioni dellUnione Internazionale delle Telecomunicazioni

42

Sebbene le chiavi siano in una certa relazione matematica, ` e praticamente impossibile derivare la chiave privata da quella pubblica. La crittograa a chiave pubblica nasce come soluzione ai molti problemi della crittograa a chiave privata.

Figura 3.12: Meccanismo di cifratura asimmetrica

La crittograa a chiave pubblica permette di eseguire due importanti operazioni sui messaggi: Cifratura messaggi cifriamo il messaggio con la chiave pubblica dellutente al quale lo vogliamo spedire; il destinatario potr` a leggere il messaggio originale, decifrandolo con la sua chiave privata ed ` e lunico che pu` o farlo perch e nessuno possiede la sua chiave privata (si veda la gura 3.12); Firma digitale per assicurare il destinatario sullidentit` a del mittente, questi rma il messaggio con la sua chiave privata: in questo modo chiunque pu` o vericare lidentit` a del mittente attraverso la sua chiave pubblica (che viene diusa liberamente, in elenchi disponibili sul web); inoltre il destinatario pu` o anche controllare, attraverso la rma, che il messaggio non sia stato alterato durante la trasmissione. Il problema centrale di questo meccanismo ` e avere la certezza che una certa chiave pubblica sia autentica, cio` e che corrisponde allutente che lha creata. Una soluzione a questo problema viene data dalla Public Key Infrastructure: ci si appoggia su una terza parte, la Certication Authority, che garantisce lautenticit` a delle chiavi. Unaltro approccio ` e quello del web of trust, che delega il controllo dellautenticit` a di una chiave alla comunit` a, basando la ducia di una chiave sul numero di persone che hanno avuto ducia su di essa in precedenza - questo meccanismo ` e poco usato dalle aziende perch e non pu` o dare garanzie documentate. Sebbene questo meccanismo sia pi` u complesso computazionalmente ed organizzativamente rispetto alla cifratura a chiave simmetrica, in cui le due parti della comunicazione condividono una chiave singola per cifrare i messaggi, garantisce una sicurezza molto forte. Per approttare dei lati positivi di entrambi i sistemi, la velocit` a del simmetrico e la sicurezza dellasimmetrico, si ` e soliti proteggere le comunicazioni usando la cifratura asimmetrica per scambiarsi in modo protetto una chiave simmetrica e poi solo questa viene usata per cifrare i messaggi di una stessa sessione. 43

3.4.2

Public Key Infrastructure

Nel campo della crittograa, linfrastruttura a chiave pubblica ` e un sistema che collega le chiavi pubbliche di cifratura allidentit` a dei rispettivi proprietari, attraverso unautorit` a di certicazione (Certication Authority). In questo contesto quindi si delega la ducia sullidentit` a associata ad una chiave, ad una terza parte, la CA28 , della quale gli appartenenti al sistema si dano, che garantisce con la sua rma digitale lidentit` a degli utenti. Quando voglio comunicare in modo sicuro con una persona devo quindi ottenere la sua chiave pubblica, ad esempio per spedire un messaggio cifrato. I passaggi che devo eseguire per essere sicuro della sua identit` a sono: 1. ottenere il certicato digitale dellutente, attraverso il suo sito Internet oppure richiedendolo direttamente allinteressato tramite una email; 2. controllare la rma della CA che ha rilasciato il certicato: questo lo posso fare controllando, con il certicato dellautorit` a, la rma sul certicato dellutente; qualora questa procedura fallisse, dovrei richiedere il certicato o trovare una fonte diversa dalla quale scaricare il certicato (il sito della CA potrebbe mettere a disposizione i certicati che ha rmato); 3. controllata la validit` a del certicato posso estrarre da esso la chiave pubblica e spedire messaggi cifrati allutente associato con la sicurezza che la CA garantisce per lui. Le CA sono quindi il perno su cui si basa tutta la struttura. Queste devono garantire delle procedure di riconoscimento adeguate ad assicurare lidentit` a della persona che richiede i servizi della CA. Visto il grande lavoro necessario a gestire una CA, solo grandi enti o aziende possono possederne una. Ad esempio lINFN si ` e organizzato con una Certication Authority propria a livello nazionale. Per snellire il lavoro, come prevede la PKI, sono state create delle Registration Authority, cio` e dei punti di ducia distribuiti che si pongono come intermediari tra i richiedenti del certicato e la CA. Il loro compito principale ` e il controllo delle identit` a dei richiedenti per il rilascio di un nuovo certicato. Altro compito molto importante ` e quello di comunicare tempestivamente alla CA lo smarrimento o il furto della chiave privata di un utente, che quindi mette a rischio la validit` a della sua chiave pubblica rmata dalla CA: la RA provvede a comunicare levento alla CA che prender` a le opportune contromisure. Queste contromisure prevedono linserimento del certicato manomesso allinterno delle liste di revoca dei certicati (CRL29 ) che vengono pubblicate dalla CA per informare tutti gli utenti dei certicati ritenuti non pi` u validi e che quindi non devono essere usati.

3.4.3

Certicato digitale

Un certicato digitale pu` o essere visto come una carta di identit` a elettronica che denisce le credenziali del proprietario e pu` o essere utilizzata per lavoro o ad
28 Certication 29 Certicate

Authority, autorit` a di certicazione Revocation List, appunto la Lista dei certicati revocati

44

esempio per eettuare transazioni sul web. In generale ` e usata per riconoscere ed autenticare un utente. Viene rilasciato, come gi` a detto, da una autorit` a di certicazione che garantisce sulla coppia chiave pubblica/identit` a dellutente. Contiene nome dellutente, numero seriale del certicato, data di scadenza, copia della chiave pubblica del possessore del certicato e rma digitale dellautorit` a di certicazione che in questo modo garantisce il documento.

3.4.4

Il formato X.509 per certicati digitali

Lo standard X.509, come ci suggerisce il nome, nasce insieme allo standard X.500 e prevede un sistema fortemente gerarchico di autorit` a di certicazione per il rilascio di un certicato. Nasce nel 1988 e si propone come meccanismo completo per limplementazione della PKI. Una CA rilascia un certicato che collega una chiave pubblica ad un particolare Distinguished Name (concetto che ritroveremo anche in LDAP, retaggio dello standard X.500) o ad un nome alternativo come ad esempio un indirizzo email o un nome DNS. Il Distinguished Name ` e, come dice la parola stessa, un nome distintivo che permette di individuare una persona, un host o qualunque cosa allinterno di un ente o di un paese, in modo gerachico, similmente ai nomi a dominio. I certicati rilasciati dalle CA possono essere usati su browser come Microsoft Internet Explorer, Mozilla Firefox o Safari, per farsi riconoscere sul web, ad esempio per aprire una sessione SSL. Ogni CA ha anche il proprio certicato digitale, che pu` o essere rmato da unaltra CA (per creare cos` una gerarchia di ducia). Altro elemento dello standard X.509 sono le liste di revoca dei certicati (CRL), che permettono ad una CA di far conoscere, a tutti, i certicati che non sono pi` u validi, ad esempio perch e un utente ha perso la chiave privata, oppure perch e questa gli ` e stata rubata. Struttura di un certicato X.509 Vediamo i valori contenuti allinterno di un certicato X.509: Version : versione di X.509 utilizzata (attualmente siamo alla 3.0) Serial Number : numero seriale che identica il certicato allinterno della CA Algorithm ID : identicativo dellalgoritmo di cifratura utilizzato; Issuer : nome distintivo della CA che ha rilasciato il certicato; Validity : periodo di validit` a del certicato, come data di inizio (campo Not Before) e data di ne (campo Not After); Subject : nome distintivo della persona o dellidentit` a da associare al certicato; Subject Public Key Info : informazioni sulla chiave pubblica del soggetto, composto da Public Key Algorithm, cio` e lalgoritmo per lutilizzo della chiave pubblica, e Subject Public Key, la chiave pubblica associata allidentit` a; 45

Issuer Unique Identier : codice identicativo univoco dellemittente (facoltativo); Subject Unique Identier : codice identicativo univoco del soggetto (facoltativo); Extensions : facoltativo, pu` o contenere varie informazioni come il nome alternativo (di solito lemail), lURL della lista dei certicati revocati ecc.; Certicate Signature Algorithm : lalgoritmo di rma del certicato; Certicate Signature : la rma digitale vera e propria del certicato, fatta con la chiave privata della CA. Vediamo ad esempio il le di certicato del candidato:
Certificate: Data: Version: 3 (0x2) Serial Number: 6967 (0x1b37) Signature Algorithm: sha1WithRSAEncryption Issuer: C=IT, O=INFN, CN=INFN CA Validity Not Before: May 23 10:33:23 2007 GMT Not After : May 22 10:33:23 2008 GMT Subject: C=IT, O=INFN, OU=Personal Certificate, L=Perugia, CN=Simone Pascarosa Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:bf:38:6a:06:94:06:b3:8a:30:d0:3a:f0:28:b7: f4:6b:70:af:22:1b:58:09:68:0e:55:19:33:ec:8f: 94:35:62:be:0e:bb:ab:bf:25:21:0a:65:53:cf:f2: 94:ba:85:1e:09:44:f6:7f:10:f2:b2:46:3f:f8:fe: da:64:55:8f:f8:c6:6d:e1:bb:a1:c0:f4:4f:9b:29: cf:30:3a:1b:4c:ec:77:2c:ae:c7:1b:85:d0:1c:a5: b2:d9:b8:f8:1b:7d:b3:21:c5:75:3a:1a:7e:2d:84: 32:10:29:82:2a:77:f4:3f:e3:9b:bb:2b:19:c1:aa: 6e:85:ef:5a:4a:01:95:6c:8c:f7:ea:ef:45:c8:58: ef:dc:db:6a:87:6e:9a:31:71:76:c6:2a:c8:b5:91: 08:07:a6:36:e7:e6:36:56:64:c9:c3:88:fa:53:6c: 11:3b:68:a2:56:94:f7:1c:5c:73:86:51:81:9d:0a: 3f:d0:4f:f7:9a:db:f1:49:02:d6:25:e3:1f:de:38: d0:e5:65:6e:03:cb:d0:60:79:e5:f0:50:39:40:44: e9:f9:f8:51:84:e9:30:ae:43:90:fc:a9:26:4d:f8: ae:30:22:61:b6:ca:8b:6f:a3:d0:85:be:0c:61:8f: 0c:3d:4f:67:d6:29:99:55:85:e9:b8:ff:e5:55:5e: 2b:cb Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment, Data Encipherment X509v3 Extended Key Usage:

46

TLS Web Client Authentication, E-mail Protection X509v3 CRL Distribution Points: URI:http://security.fi.infn.it/CA/INFNCA_crl.der X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.10403.10.1.5 X509v3 Subject Key Identifier: 77:B4:32:9D:FB:E1:3F:CB:2B:BE:E4:60:37:C5:AD:1C:50:2D:72:86 X509v3 Authority Key Identifier: keyid:D1:62:F3:B3:77:72:C8:2E:FB:F2:79:1A:6F:37:4E:27:9F:13:D5:20 DirName:/C=IT/O=INFN/CN=INFN CA serial:00 X509v3 Subject Alternative Name: email:Simone.Pascarosa@pg.infn.it Signature Algorithm: sha1WithRSAEncryption 1d:e7:00:a4:0a:06:a2:21:2f:72:6d:b5:05:f7:85:6e:30:77: 7e:65:32:c1:4d:fc:41:60:00:c3:89:c8:27:91:5d:a0:65:e0: 9a:2a:89:72:2a:d5:68:b7:15:46:ce:61:41:3e:33:33:58:f1: e9:9f:54:a2:06:bf:23:a5:06:54:3d:e3:e8:28:9f:6e:05:f6: 80:e3:b7:56:63:d0:f1:bb:27:c6:db:c1:95:01:fb:a6:b5:01: 31:7d:7b:43:de:a3:f4:b5:b4:5e:24:f4:38:d3:fd:16:66:7a: 60:4c:b3:7e:03:e3:a6:ff:29:11:ab:ab:2f:90:b0:aa:14:2e: 88:0b:35:e6:fb:80:3d:12:f7:8b:a4:13:41:fc:64:09:e3:6a: 27:8e:2a:75:81:52:0a:4c:6a:25:83:2d:3f:f0:a0:17:6c:e6: 3a:1a:fd:c5:1a:b0:6a:31:8f:2c:90:9f:9e:7d:8c:32:bc:5d: 18:fd:6c:b1:b4:16:fa:f4:e1:f3:94:5c:07:1d:3e:b7:ad:70: 47:1a:35:ed:54:1f:1a:9f:82:60:6a:b3:a9:3e:db:a8:cf:11: 2d:0c:42:67:4a:ee:58:c4:01:3c:f1:b7:6d:79:72:f2:4a:ed: 1d:35:b4:ff:a8:68:26:19:ef:a3:44:5c:10:e5:22:c2:82:07: 72:27:3e:65 -----BEGIN CERTIFICATE----MIIETDCCAzSgAwIBAgICGzcwDQYJKoZIhvcNAQEFBQAwLjELMAkGA1UEBhMCSVQx DTALBgNVBAoTBElORk4xEDAOBgNVBAMTB0lORk4gQ0EwHhcNMDcwNTIzMTAzMzIz WhcNMDgwNTIyMTAzMzIzWjBoMQswCQYDVQQGEwJJVDENMAsGA1UEChMESU5GTjEd MBsGA1UECxMUUGVyc29uYWwgQ2VydGlmaWNhdGUxEDAOBgNVBAcTB1BlcnVnaWEx GTAXBgNVBAMTEFNpbW9uZSBQYXNjYXJvc2EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQC/OGoGlAazijDQOvAot/RrcK8iG1gJaA5VGTPsj5Q1Yr4Ou6u/ JSEKZVPP8pS6hR4JRPZ/EPKyRj/4/tpkVY/4xm3hu6HA9E+bKc8wOhtM7Hcsrscb hdAcpbLZuPgbfbMhxXU6Gn4thDIQKYIqd/Q/45u7KxnBqm6F71pKAZVsjPfq70XI WO/c22qHbpoxcXbGKsi1kQgHpjbn5jZWZMnDiPpTbBE7aKJWlPccXHOGUYGdCj/Q T/ea2/FJAtYl4x/eONDlZW4Dy9BgeeXwUDlAROn5+FGE6TCuQ5D8qSZN+K4wImG2 yotvo9CFvgxhjww9T2fWKZlVhem4/+VVXivLAgMBAAGjggE4MIIBNDAMBgNVHRMB Af8EAjAAMA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYB BQUHAwQwPQYDVR0fBDYwNDAyoDCgLoYsaHR0cDovL3NlY3VyaXR5LmZpLmluZm4u aXQvQ0EvSU5GTkNBX2NybC5kZXIwFwYDVR0gBBAwDjAMBgorBgEEAdEjCgEFMB0G A1UdDgQWBBR3tDKd++E/yyu+5GA3xa0cUC1yhjBWBgNVHSMETzBNgBTRYvOzd3LI LvvyeRpvN04nnxPVIKEypDAwLjELMAkGA1UEBhMCSVQxDTALBgNVBAoTBElORk4x EDAOBgNVBAMTB0lORk4gQ0GCAQAwJgYDVR0RBB8wHYEbU2ltb25lLlBhc2Nhcm9z YUBwZy5pbmZuLml0MA0GCSqGSIb3DQEBBQUAA4IBAQAd5wCkCgaiIS9ybbUF94Vu MHd+ZTLBTfxBYADDicgnkV2gZeCaKolyKtVotxVGzmFBPjMzWPHpn1SiBr8jpQZU PePoKJ9uBfaA47dWY9DxuyfG28GVAfumtQExfXtD3qP0tbReJPQ40/0WZnpgTLN+ A+Om/ykRq6svkLCqFC6ICzXm+4A9EveLpBNB/GQJ42onjip1gVIKTGolgy0/8KAX

47

bOY6Gv3FGrBqMY8skJ+efYwyvF0Y/WyxtBb69OHzlFwHHT63rXBHGjXtVB8an4Jg arOpPtuozxEtDEJnSu5YxAE88bdteXLySu0dNbT/qGgmGe+jRFwQ5SLCggdyJz5l -----END CERTIFICATE-----

Ambienti di utilizzo del certicato digitale


I certicati digitali vengono utilizzati largamente su Internet e su intranet aziendali per svariati servizi: Autenticazione per sito web: molte aziende per laccesso ad alcune sezioni del proprio sito (magari quelle dedicate ai fornitori o ai dipendenti) richiedono che venga riconosciuto valido il certicato digitale installato nel browser dellutente: in questo modo viene eliminata la necessit` a di ricordarsi username/password; Autenticazione per accesso wireless: nel progetto diamo la possibilit` a a tutti i possessori di certicato digitale valido emesso dalla Certication Authority di INFN30 di accedere ad Internet dalla rete della Sezione di Perugia, senza bisogno di registrazione; Firma digitale: rmando le proprie email si d` a sicurezza al ricevente che non ci sono state alterazioni durante la trasmissione e sappiamo che lutente ha ricevuto proprio il messaggio che intendevamo spedire; Cifratura della posta elettronica: ` e buona pratica allegare a tutti i messaggi di posta elettronica che si spediscono il proprio certicato digitale, cos` che se qualcuno vuole spedirci dei messaggi sicuri, pu` o farlo attraverso la chiave pubblica contenuta nel certicato.

3.5

Directory service con LDAP

Il protocollo Lightweight Directory Access Protocol o LDAP ` e un protocollo applicativo (livello 7 della pila ISO/OSI) che permette di interrogare e modicare le informazioni contenute in un directory service31 . Una directory ` e un insieme di oggetti con attributi simili, organizzati in modo logico e gerarchico. Lesempio pi` u comune ` e quello dellelenco telefonico, che consiste in una serie di nomi in ordine alfabetico, con indirizzo e numero di telefono associati. Di solito le gerarchie LDAP riettono situazioni politiche, geograche o organizzative: per questo motivo sovente si utilizzano i nomi a dominio per la strutturazione delle gerarchie. Quindi possiamo immaginare che una ipotetica directory che contenga le informazioni per gli utenti della Sezione di Perugia di INFN sia contraddistinta da un nome simile utenti.pg.infn.it. Uno degli impieghi pi` u comuni dei directory service ` e quello della memorizzazione di informazioni di autenticazione e contatti personali; basta notare come le ultime versioni dei pi` u popolari client di posta permettano di esportare i contatti della propria rubrica in un formato pronto per un server LDAP. Esistono diversi moduli per le pi` u diuse applicazioni che richiedono autenticazione, che permettono di utilizzare lautenticazione con LDAP: tra queste possiamo citare il sistema PAM (Pluggable Authentication Module) di autenticazione per sistemi GNU/Linux, il server web Apache e il server FreeRADIUS. La versione corrente del protocollo ` e la LDAPv3 che viene denita in alcuni RFC, come si legge nellRFC 4510 (si legga [8]).

30 il

31 questa

sui sito istituzionale ` e http://security..infn.it/CA descrizione ` e tratta da [7]

48

3.5.1

Storia

La storia del protocollo LDAP ha radici lontane, gi` a quando le prime compagnie di telecomunicazioni avevano bisogno di directory service ecienti per mantenere le informazioni di milioni di utenti. Negli anni 80 lInternational Telecommunication Union (ITU) den` la specica X.500. Le directory X.500 venivano interrogate con il protocollo DAP (Directory Access Protocol), pensato per lavorare con lo stack di protocolli ISO/OSI. Quando poi la suite TCP/IP prese il sopravvento, nacque il protocollo LDAP che si proponeva come unalternativa snella di accesso a directory service per reti TCP/IP. Pian piano quindi tutti i directory service supportarono LDAP. Oggi il protocollo X.500 e DAP possono essere utilizzati anche su TCP/IP. Il protocollo LDAP fu progettato da Tim Howes (University of Michigan), Steve Kille (ISODE) e Wengyik Yeong (Performance Systems International) nel 1993. Ulteriori aggiornamenti vennero decisi dagli RFC. Allinizio il protocollo era conosciuto anche come LDBP, ovvero Lightweight Directory Browsing Protocol; successivamente venne corredato anche delle funzioni di modica ed aggiornamento e quindi si prefer` access invece di browsing. Altri protocolli e standard che riguardano i directory service sono il gi` a citato X.500, lXML Enabled Directory (XED), il Directory Service Markup Language (DSML), il Service Provisioning Markup Language (SPML) e il Service Location Protocol (SLP).

3.5.2

Perch e non usare un database relazionale?

Ci sono alcune dierenze sostanziali tra una directory e un database relazionale. Andiamo a vedere le dierenze per poi fare alcune considerazioni: generalmente le informazioni sono lette pi` u spesso di quanto sono scritte; per questo motivo dicilmente troviamo implementate funzioni riguardanti transazioni (come rollback o abort) i dati possono essere ridondati (ed ` e bene farlo) anche se di solito solo per ridurre i tempi di ricerca i dati sono organizzati in modo gerarchico non esistono relazioni (come nei database) molti-a-molti, anche se possono essere implementate attraverso liste di distinguished name (vedremo pi` u avanti di cosa si tratta) uno schema, cio` e la struttura di una entry della directory, ` e denito come attributi che un oggetto pu` o avere; questi si dividono in attributi obbligatori (che ogni istanza deve avere) ed opzionali (che possono essere omessi quando un oggetto viene creato), cosa che nei database comuni troviamo implementata con il valore NULL gli attributi di una entry sono spesso multivalore, al contrario di quanto avviene nei database convenzionali (ricordiamo la Prima Forma Normale dei database relazionali) gli attributi e le objectClass sono standardizzate e registrate dallo IANA32 attraverso un Object ID; si cerca quindi di riutilizzare le classi gi` a esistenti per massimizzare la compatibilit` a e ridurre i problemi di aggiornamento legati a nuove versioni del software del directory server
32 Internet Assigned Numbers Authority, lente che governa lallocazione globale degli indirizzi IP, la gestione delle zone DNS e di altre funzioni fondamentali di Internet

49

le classi di oggetti sono inserite in una gerarchia in cui una eredita dallaltra, partendo dalla radice della gerarchia per individuare uninformazione, non devo conoscere la tabella nella quale ` e memorizzata; mi basta conoscere il suo namespace A dierenza dei database, che permettono di modellizzare su computer una situazione reale, una directory costituisce un supporto per le informazioni di autenticazione e autorizzazione; perci` o sono pensate per svolgere un compito diverso da quello dei database relazionali. La dierenza pi` u evidente quindi ` e che i database relazionali sono usati per automatizzare un sistema con un modello di dati dedicato, mentre una directory ` e usata per mantenere oggetti identicabili che possono essere usati da diverse applicazioni nei modi pi` u svariati. Le directory sono molto apprezzate in contesti in cui ci sono varie organizzazioni e varie applicazioni che devono accedere alle stesse informazioni per utenti e oggetti diversi. In un contesto di integrazione dei servizi agli utenti, le directory danno un valore aggiunto rispetto ai database perch e le informazioni contenute sono schematizzate in un formato consolidato, che permette di modicarle e di arricchirle, aggiungendo nuove classi di oggetto, senza necessit` a di drastiche modiche alla struttura dei dati. Ultimo vantaggio ` e la scalabilit` a: visto che le directory nascono per memorizzare le informazioni degli utenti telefonici, possiamo immaginare facilmente che non abbiamo problemi ad inserire milioni di entry nella directory, strutturate in centinaia di livelli diversi senza troppi problemi.

3.5.3

Struttura directory e formato delle entry

Lo standard per la denizione e la strutturazione delle directory ` e rimasto quello di X.500 del 1993 e cio` e: una directory ` e un albero di entry una entry ` e un insieme di attributi un attributo ha una nome e uno o pi` u valori; gli attributi sono deniti negli schema LDAP non denisce alcun ordinamento, perci` o sia i valori degli attributi, che gli attributi di una entry, che i risultati di una interrogazione, possono essere restituiti in qualunque ordine. Ogni entry della directory ha un identicatore univoco, detto Distinguished Name (DN). Il DN ` e costituito da due parti: il Relative Distinguished Name, costruito tramite alcuni attributi dellentry, che possiamo vedere come il nome proprio dellentry il Distinguished Name dellentry padre dellentry corrente In questo modo il nome dellentry rappresenta oltre che il suo nome, anche il percorso per trovarla allinterno dellalbero LDAP. Vediamo lesempio di denizione di una entry LDAP: dn: cn=Simone Pascarosa,ou=people,dc=fisica,dc=unipg,dc=it givenName: Simone sn: Pascarosa cn: Simone Pascarosa mail: simone.pascarosa@gmail.com telephoneNumber: 0755852777 objectClass: inetOrgPerson objectClass: top

50

La denizione di una entry consiste nellassegnare ad ogni attributo un valore; solo alcuni di questi sono obbligatori, molti sono stati omessi (la inetOrgPerson ` e una classe molto diusa per la memorizzazione dei dati personali); si noti la sintassi dellesempio visualizzato, descritta dal formato LDIF (LDAP Data Interchange Format), che descrive una entry elencando prima di tutto il suo DN (nome distintivo) e successivamente tutti i suoi attributi. La sintassi per ogni attributo ` e: nome attributo: valore Lattributo dn ` e il nome dellentry: non ` e n e un attributo, n e parte dellentry stessa, ma il suo identicatore: cn=Simone Pascarosa ` e il Relative Distinguished Name ou=people,dc=sica,dc=unipg,dc=it si riferisce allentry padre cn signica Common Name, mentre dc sta per Domain Component, invece ou sta per Organizational Unit. Le righe successive deniscono i restanti attributi dellentry, come nome e cognome del contatto, lindirizzo email, il numero di telefono ecc. Un server contiene un sottoalbero che parte da una specica entry: il server del Dipartimento di Fisica potrebbe contenere ad esempio tutto il sottoalbero con radice in dc=sica,dc=unipg,dc=it e sotto di questo avere informazioni sui dipendenti nel sottoalbero ou=people,dc=sica,dc=unipg,dc=it, sugli account degli utenti in ou=account,dc=sica,dc=unipg,dc=it e via dicendo. In questo caso, il nome della radice rispetta il nome a dominio dellente, ma siamo liberi di usare qualunque nome si voglia.

3.5.4

Referrals e chaining

Altra caratteristica fondamentale, naturale conseguenza della forte strutturazione delle directory X.500 ` e la possibilit` a di delegare alcuni sottoalberi ad altri server. Se ad esempio il nostro server gestisce lalbero dc=sica,dc=unipg,dc=it, ma abbiamo creato un server che gestisce autonomamente il sottoalbero ou=people,dc=sica,dc=unipg,dc=it, allora il server principale pu` o rimandare le interrogazioni a questo server. Esistono due meccanismi per implementare questa feature in LDAP (si vedano rispettivamente gli schemi nelle gure 3.13 e 3.14): Referrals: un server A viene interrogato per un sottoalbero di cui non contiene informazioni (punto 1 nellimmagine), ma sa che sono memorizzate nel server B; allora manda al client che ha fatto la richiesta un referral o continuation reference (punto 2) che contenga lindirizzo del server B che pu` o evadere quella richiesta Chaining un server A viene interrogato per un sottoalbero di cui non contiene informazioni, ma sa che sono memorizzate nel server B; in modo trasparente il server A interroga il server B con le informazioni richieste al client (punto 2 nellimmagine), quando ha ottenuto la risposta (punto 3), la rispedisce al client (punto 4) Entrambi i metodi presentano delle caratteristiche peculiari che fanno preferire luno rispetto allaltro in certi casi: il meccanismo del Chaining sposta lonere della richiesta al server autoritativo per una certa sottodirectory dal client al server a cui questo fa richiesta, viene quindi snellito il lavoro del client; questa soluzione ` e da preferire se vogliamo fornire un servizio completo e trasparente al client

51

Figura 3.13: Meccanismo di Referral di LDAP

Figura 3.14: Meccanismo di Chaining di LDAP

il Referral invece lascia al client lonere di replicare la richiesta al server autoritativo, cosi che il primo server viene alleggerito; questa soluzione ` e da preferire se vogliamo alleggerire il carico dei server e distribuire i compiti in modo stretto

3.5.5

Schema : attributi e classi di oggetto

Uno schema ` e la denizione formale del contenuto delle entry in un sottoalbero. Lo schema denisce i tipi di attributi che le entry possono contenere. Gli attributi possono avere come valori una stringa UTF-8 (ad esempio per un indirizzo email), una stringa binaria in formato JPEG (per memorizzare la foto di una persona) oppure il DN di altre entry della directory (ad esempio per memorizzare il direttore di un dipartimento). Oltre a questo lo schema denisce le classi di oggetto generate attraverso composizioni degli attributi deniti. Per gli attributi, lo schema denisce: se lattributo ` e multivalore o a valore singolo le modalit` a di ricerca consentite (case sensitive o meno, ricerca su sottostringhe ecc.) le modalit` a di confronto consentite la descrizione dellattributo Per le classi di oggetti, lo schema denisce: il codice

52

il nome e la descrizione lobject class dalla quale eredita il tipo gli attributi obbligatori e quelli opzionali Vediamo un esempio di schema che ci permette di descrivere meglio le caratteristiche e le potenzialit` a di questo strumento. # Estratto dello schema inetorgperson.schema # attributetype ( 2.16.840.1.113730.3.1.39 NAME preferredLanguage DESC RFC2798: preferred written or spoken language for a person EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # [...] Altre definizioni di attributi objectclass ( 2.16.840.1.113730.3.2.2 NAME inetOrgPerson DESC RFC2798: Internet Organizational Person SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) Senza dilungarci sulla specica della sintassi della denizione degli schemi LDAP, possiamo vedere come viene denito un attributo e come questo viene usato subito allinterno della denizione di una nuova classe di oggetti (appunto objectClass ). ` importante notare come le classi siano strutturate in una gerarchia attraverso E lereditariet` a: in modo simile ai linguaggi di programmazione ad oggetti, si ha la possibilit` a di ereditare gli attributi di una classe gi` a denita. La radice di questa gerarchia ` e la classe top che denisce come unico attributo obbligatorio proprio lattributo objectClass, cio` e quello attraverso il quale si denisce la classe di appartenenza di una entry. Per completezza ecco la denizione della classe top : objectclass ( 2.5.6.0 NAME top DESC RFC2256: top of the superclass chain ABSTRACT MUST objectClass ) Siccome non ` e specicato altrimenti, si deduce che lattributo objectClass ` e multivalore, quindi una entry pu` o appartenere a pi` u object class contemporaneamente, denendo almeno tutti gli attributi obbligatori delle classi usate. Bisogna fare attenzione alle collisioni tra nomi di attributi uguali allinterno di due dierenti classi.

53

Gli elementi di uno schema vengono identicati, oltre che dal loro nome, anche da un identicatore globale detto Object Identier (OID), che attraverso una notazione numerica puntata, identica gerarchicamente un oggetto. Gli OID vengono largamente usati in molte altre applicazioni e sono standardizzati a livello internazione dallo ASN.133 di ITU-T per evitare collisioni e per avere un database aggiornato e centralizzato con tutte le denizioni. Oltre agli schema standard ogni amministratore pu` o denire i propri personalizzati, anche partendo da quelli gi` a fatti, per rappresentare meglio la propria realt` a aggiungendo gli attributi e le classi di oggetto che ritiene necessari.

3.5.6

Server LDAP slave

Vista la criticit` a dei dati contenuti nelle directory LDAP e la necessit` a di avere questi dati sempre disponibili, si possono creare delle repliche (server slave ) della directory (server master) contente i dati. Queste repliche hanno due principali funzioni: garantire la disponibilit` a di una copia sempre funzionante della directory, anche nel caso in cui il server principale smettesse di funzionare; bilanciare il carico delle richieste su pi` u copie dello stesso server, in modo da ottimizzare lutilizzo delle risorse e velocizzare i tempi di risposta. La replica di una directory LDAP prevede che il server con la copia principale (master) sia a conoscenza di tutti i server secondari presenti nella rete e che propaghi tutte le modiche che vengono eettuate alla directory verso ciascuna copia, per mantenere omogeneit` a nei dati tra master e slave, come vediamo nella gura 3.15.

Figura 3.15: Meccanismo di replica di LDAP

3.5.7

La nostra directory

La directory LDAP che utilizzeremo in questo progetto conterr` a informazioni di diversa natura, dettate principalmente dalla necessit` a di centralizzare le congurazioni dei servizi di rete e di riconoscere lutente associato a ciascun host della rete. In particolare verranno memorizzate sulla directory: le congurazioni dei servizi DHCP e DNS le informazioni di autenticazione degli utenti, sia per INFN/TRIP, che per il proxy del Dipartimento di Fisica, che per usi futuri
33 Abstract Syntax Notation One, notazione standard e essibile per la trasmissione e la codica di dati

54

le identit` a dei dipendenti degli enti coinvolti (informazioni molto utili per creare liste di utenti divise per enti, gruppi di ricerca, tipologie ecc.); possiamo usare queste informazioni direttamente da un client di posta per trovare lindirizzo email di un utente le congurazioni del server RADIUS (in particolare gli indirizzi MAC dei portatili che accedono senza ulteriore autenticazione)

3.6

Virtualizzazione per alta adabilit` a

Per virtualizzazione si intende lastrazione delle risorse dei computer. Potremmo denire la virtualizzazione come una tecnica per nascondere le caratteristiche siche di una risorsa (informatica) al sistema operativo, alle applicazioni e allutente nale. Ad esempio, potremmo far sembrare che una singola risorsa sica (come un server, un sistema operativo o un disco) funzioni come se fosse un insieme di varie risorse logiche, oppure, al contrario, far vedere pi` u risorse logiche come se fossero una sola risorsa. Il concetto di virtualizzazione ` e molto ampio, e nel passato ha assunto varie declinazioni nei vari ambiti dellinformatica: il concetto di stampante virtuale, per esempio, nasconde lo stato della stampante allutente facendola sembrare sempre disponibile, oppure il concetto di disco virtuale, che permette di creare dispositivi virtuali a partire da partizioni, insiemi di partizioni, le o aree disco. Il fattore comune ` e quello del mascheramento dei dettagli sici di una risorsa, a favore della essibilit` a di utilizzo e dinterfacciamento verso lutente. Puntualizziamo anche la dierenza tra trasparenza e virtualizzazione: per trasparenza di intende una risorsa che esiste nel mondo reale, ma non viene vista al lavoro; per virtualizzazione si intende qualcosa che ` e visibile, che percepiamo, ma che non esiste nella forma in cui lo percepiamo (perch e frammentato o combinato), ad esempio un disco virtuale. Seguendo una classicazione consolidata possiamo suddividere la virtualizzazione in due ambiti di applicazione diversi: virtualizzazione di piattaforme, che riguarda la simulazione di computer; virtualizzazione di risorse.

3.6.1

Virtualizzazione di piattaforma con Xen

Xen ` e un monitor di macchine virtuali (o Hypervisor) per architetture IA-32, x86-64, IA-64 e PowerPC. Permette di far girare un sistema operativo host e sopra di esso eseguire diversi sistemi operativi ospiti che utilizzano lo stesso hardware contemporaneamente. Una macchina virtuale ` e un ambiente virtuale che si pone come interfaccia tra lhardware del computer e il sistema operativo cos` che lutente abbia la sensazione di usare un ambiente a lui dedicato. Come sistemi operativi host possiamo usare versioni modicate di GNU/Linux e NetBSD. Come sistemi ospiti possiamo usare diversi sistemi Unix-like e, su certi hardware, anche versioni originali di Microsoft Windows. Xen opera una paravirtualizzazione, cio` e lhypervisor non deve necessariamente simulare lhardware, ma mette a disposizione delle speciali API34 che possono essere usate dai sistemi operativi ospite, opportunamente modicati. Queste chiamate di sistema allhypervisor vengono appunto chiamate hypercall in Xen e orono la possibilit` a di controllare lallocazione delle risorse harware alle macchine virtuali tramite il monitor.
34 Application

Program Interface

55

Xen nasce come progetto di ricerca allUniversit` a di Cambridge, diretto da Ian Pratt, fondatore della XenSource Inc. La prima versione pubblica di Xen risale al 2003. ` stato scelto il software Xen perch E e permette di creare macchine virtuali in modo veloce ed eciente, garantisce un basso overhead di calcolo (dovuto al monitoraggio e al controllo delle macchine virtuali) e alla disponibilit` a di documentazione e supporto su Internet. Vediamo alcuni esempi dei beneci della creazione di macchine virtuali: creazione di server virtuali dedicati da parte degli Internet Hosting Service, per fornire allutente un ambiente di lavoro indipendente e personalizzato frammentazione dei servizi su server ad alte prestazioni, per aumentarne lecienza e la sicurezza Le macchine virtuali vengono usate ad esempio dagli Internet Hosting Service per fornire ai clienti server virtuali a loro dedicati. Su grandi mainframe o server ad alte prestazioni, la virtualizzazione dei server aumenta la solidit` a, lo sfruttamento delle risorse e d` a la capacit` a di creare velocemente una nuova macchina virtuale, ad esempio per rispondere dinamicamente ad un crash di sistema; in caso di problemi hardware si potrebbe trasferire la macchina virtuale su un nuovo server sico in modo da mantenere attivo il servizio anche in caso di malfunzionamenti sici senza tempi di down del servizio (Xen permette il trasferimento di una macchina virtuale a run-time, tramite la virtual machine live migration ). Per quanto ci riguarda, useremo Xen per realizzare delle piccole macchine virtuali dedicate a particolari servizi, in modo da suddividere i problemi di ogni server nel proprio ambiente e per connare il down di una macchina al singolo servizio che ospita; moltiplicheremo quindi il numero di server a disposizione che, anche se virtuali, mantengono funzionalit` a soddisfacienti. Con lo stesso meccanismo possiamo creare delle repliche dei server pi` u critici, in modo tale da mantenere alti livelli di adabilit` a dei servizi, sia attraverso un bilanciamento continuo del carico, sia mantenendo una macchina secondaria silente che prenda il posto della copia originale quando questa si ferma. Ecco gli elementi chiave dellarchitettura di Xen: Hypervisor: ` e il monitor delle macchine virtuali, che gira come servizio sul sistema operativo host; Sistema operativo host con supporto per lHypervisor; Kernel dei sistemi operativi client con supporto per le chiamate Xen; Immagine dei lesystem dei sistemi client; Strumenti di amministrazione; File di congurazione delle macchine virtuali. Introduciamo alcuni termini dellarchitettura Xen: Domain 0 (o Dom0) ` e il primo dominio 35 avviato dallhypervisor allavvio. Ha dei privilegi speciali, ad esempio pu` o avviare nuovi domini guest e pu` o accedere ` responsabile di eseguire i driver per tutti i disposdirettamente allhardware. E itivi presenti e, per lhardware condiviso con gli altri domini, ad esempio schede di rete e dischi, carica i backend driver che multiplexano e instradano allhardware le richieste provenienti dai driver frontend di ciascun DomU. Solo Linux e NetBSD possono essere eseguiti come Dom0, perch e Xen prevede patch per il kernel e strumenti per il Dom0 solo per questi kernel.
35 in questo contesto il termine dominio sta ad indicare un ambiente operativo creato da Xen che simula una piattaforma, sulla quale eseguire un sistema operativo

56

Domain U (o DomU) ` e la controparte del Dom0; ` e un dominio ospite che non ha accesso diretto allhardware. Deve eseguire dei driver frontend per lhardware che vuole usare, che ` e condiviso con gli altri DomU. Il DomU ` e avviato dal demone xend sul Dom0, tramite il comando xm. Il kernel del DomU da avviare ` e memorizzato nel Dom0, non nel lesystem esportato al DomU. Xen Hypervisor ` e il cuore di Xen: si situa tra lhardware e il sistema operativo ` responsabile del controllo dellallocazione delle risorse, dello dei vari domini. E scheduling e di altre operazioni a basso livello. Presenta al sistema operativo una macchina virtuale, del tutto simile allarchitettura reale sottostante. I domini comunicano con lhypervisor attraverso delle hypercall (chiamate hardware opportunamente modicare per usare le API di Xen); dal canto suo lhypervisor risponde con un evento, che simula il funzionamento degli IRQ 36 dellhardware reale. Xend ` e il demone che si occupa del controllo delle macchine virtuali; viene eseguito allavvio, allinterno del Dom0. Si veda lo schema in gura 3.16 che riassume la struttura dellarchitettura di Xen.

Figura 3.16: Schema semplicato dellarchitettura di XEN

Nella nostra struttura le macchine virtuali Xen verranno usate per ospitare i server RADIUS e le repliche del master server LDAP; usiamo macchine virtuali perch e permettono di creare dei server molto snelli e veloci, che contengono solo il software strettamente necessario. Avendo delle macchine virtuali, sar` a facile replicare un server se questo andasse in crash: infatti basta copiare il lesystem della macchina virtuale difettosa su una macchina funzionante, copiarne la congurazione e mandarla in esecuzione. Le due macchine devono avere delle congurazioni simili. Si prevede perci` o di riservare alcuni server per ospitare macchine virtuali, proprio per assolvere a questo compito.
36 Interrupt

ReQuest

57

3.6.2

EVMS: virtualizzazione dei dischi

LEnterprise Volume Management System (EVMS) ` e un software di gestione di volumi logici molto potente e essibile, che permette di congurare sistemi complessi di storage sotto Linux.

Volumi logici
I volumi logici sono unastrazione delle partizioni disco create da un gestore di volumi. Un volume logico pu` o nascere da un insieme di partizioni, spazio libero su partizioni ed altre risorse, e viene mostrato al sistema come se fosse un normale dispositivo a blocchi. In questo modo possiamo gestire in modo essibile le partizioni del disco, modicare la dimensione di un volume, aggiungendo nuove risorse, eliminando cos` il problema dei limiti sici di un disco: potremmo ad esempio creare un volume logico che contenga spazio preso da una Storage Area Network37 e, aggiungendo ad essa nuovo spazio disco, si pu` o incrementare di continuo lo spazio del volume logico associato. La essibilit` a di EVMS, come gestore di volumi logici, permette di creare volumi che sicamente corrispondono a le su una partizione sica. Si possono creare delle macchine virtuali su un computer ed usare come lesystem per queste macchine dei le su disco che EVMS mostra come partizioni.

che prevede di collegare unit` a di memorizzazione (come dischi o supporti ottici) in remoto ad un server, in modo tale che il sistema operativo veda quellunit` a come se fosse collegata localmente, rendendo trasparente la rete; si contrappone ai NAS (Networkattached storage) che usano un protocollo basato su le, come NFS o SMB, per collegare in remoto delle unit` a disco, che vengono riconosciute come collegate via rete.

37 unarchitettura

58

Capitolo 4

Realizzazione
Le fasi di ideazione del progetto, denizione dei requisiti e analisi delle tecnologie sono avvenute fra primavera e autunno 2007, periodo in cui il candidato ha lavorato al progetto nel periodo di stage La rete ` e stata installata e congurata ed ` e correntemente in uso presso il dipartimento, anche se ancora in fase di completamento. Il lavoro ` e stato svolto su una infrastruttura gi` a esistente, che non pu` o essere fermata per un certo periodo per laggiornamento, quindi la fase di migrazione degli utenti ancora non ` e stata completata. A questo proposito si sta procedendo al passaggio graduale degli utenti, delle aule e dei laboratori a questa nuova infrastruttura, modicando, in modo progressivo, i metodi di accesso alla rete. Ecco, in breve, le fasi necessarie a completare linstallazione della nuova rete: progettazione: questa fase riguarda lo studio delle necessit` a degli utenti e lindividuazione delle tecnologie migliori per realizzare gli obiettivi della nuova rete; soprattutto si ` e dovuto tenere conto della coesistenza dei due enti, Dipartimento di Fisica ed INFN, allinterno dello stesso edicio denizione delle reti: in questa fase si ` e dovuto decidere quante e quali reti1 dovessero essere previste per la fase iniziale dellimplementazione (alcune di esse servono solo per la fase di migrazione) congurazione dei dispositivi: prese le decisioni pi` u importanti, ` e stato necessario congurare gli switch per riconoscere e distribuire in modo corretto il traco delle nuove reti; inoltre ` e stato necessario congurare il router di frontiera tra le reti, che richiede particolari attenzioni. Lo stesso lavoro ` e stato svolto per gli access point wireless congurazione dei servizi: questa fase, avvenuta in concomitanza alla precedente, ha permesso di congurare i servizi critici della rete, quali LDAP e RADIUS e, solo successivamente, DHCP e DNS migrazione degli utenti: fase ancora in esecuzione, che prevede di passare sulla nuova rete tutti i computer, ssi o portatili, degli utenti, tutti gli account e le congurazioni dei servizi principali. Questa fase richiede sicuramente il tempo maggiore, poich e necessita di ripetute interazioni con gli utenti per linserimento dei dati nella directory LDAP smantellamento delle vecchie strutture: questa fase consister` a nella rimozione delle vecchie reti wireless e dei vecchi account degli utenti, e la denitiva messa in produzione della nuova struttura
1 in

questo contesto il termine rete sta ad indicare ciascuna rete VLAN

59

4.1

Struttura generale della rete

La rete del dipartimento sar` a composta di varie reti che coesistono allinterno della stessa infrastruttura di rete (cavi, switch, router). Verranno create 16 reti separate che saranno utilizzate sia per modalit` a di accesso diverse, che per servizi diversi, come vediamo nella tabella 4.1. La struttura ` e essibile ed estendibile: questo permetter` a in futuro di aggiungere nuovi domini, senza troppa dicolt` a. Interventi come lo spostamento di un laboratorio o la distribuzione di una rete privata tra i vari piani non saranno un problema visto che gli switch della dorsale delledicio, opportunamente congurati, conoscono tutte le reti. Le reti appena elencate saranno divise logicamente, formando ciascuna un dominio di collisione Ethernet separato. Questo concetto di separazione dei domini che interviene a livello Data Link (il secondo della pila ISO/OSI), ci porta alle seguenti considerazioni sullindirizzamento IP di tali reti.

4.1.1

Indirizzamento IP

La scelta fatta per lindirizzamento delle varie reti tiene in considerazione alcuni fattori: non stravolgimento, nei limiti del possibile, degli indirizzamenti gi` a esistenti possibilit` a di vedere le varie reti come ununica rete ad un certo livello di astrazione Per rispondere alla prima necessit` a, ` e stata fatta la scelta di mantenere gli indirizzamenti IP originale per le reti del laboratorio di Informatica, del laboratorio di Acquisizione e della Farm di calcolo. Soprattutto per la Farm di calcolo, non era pensabile stravolgere lindirizzamento visto anche il recente upgrade della rete e il fatto che alcuni indirizzi sono hard-coded nel codice distribuito tra i vari nodi di calcolo. Per rispondere alla seconda necessit` a si ` e scelto di utilizzare una classe con capacit` a di indirizzamento molto grande e possibilit` a di suddividere la rete in porzioni con la stessa cardinalit` a, di dimensioni ragionevoli (con almeno 200-300 indirizzi IP disponibili). Abbiamo quindi la rete di classe A 10.0.0.0 che ` e stata suddivisa nelle sue componenti di classe B, reti 10.1.0.0, 10.2.0.0 ... Le Virtual LAN avranno quindi un indirizzamento del tipo 10.2.0.0 con maschera di rete 255.255.0.0. In questo modo ciascuna rete pu` o contenere no ad un massimo di 2562 = 65536 indirizzi IP, che possono sicuramente soddisfare tutte le necessit` a presenti e future del dipartimento. Per completezza, viene riportato lassegnamento degli indirizzi alle reti, la VLAN ad esse associate e il loro utilizzo nella tabella 4.2.

4.2

Implementazione VLAN

Dopo aver denito le reti di cui abbiamo bisogno, si devono far conoscere tali reti agli switch del dipartimento. Verranno usati switch managed, cio` e switch ai quali si pu` o assegnare un indirizzo IP e che forniscono una interfaccia per congurare le porte e altri parametri di commutazione. Altro requisito degli switch ` e, naturalmente, il supporto alle VLAN. Gli switch utilizzati sono quelli della serie 3Com 3300Tm e HP Procurve 2848. Entrambi forniscono sia uninterfaccia web, che un piccolo interprete a linea di comando per impostare le congurazioni dello switch.

4.2.1

Aggiunta dei VLAN ID

Per realizzare una Virtual LAN c` e bisogno che tutti gli switch conoscano il suo identicatore (il VLAN ID).

60

Rete di controllo

Wired

INFN-dot1x

FISICA-priv

INFN-web

FISICA-web

STUD

WL-common

OPEN

FISICA

INFN

INFOLAB ACQLAB FARM

rete utilizzata dagli amministratori: ad essa saranno collegati tutti gli switch (per il controllo remoto), gli access point (per lo stesso motivo), i dom0 per le macchine virtuali e le postazioni degli amministratori per accedere ai suddetti dispositivi sostituir` a la rete cablata sia del Dipartimento di Fisica, che dellINFN: ad essa saranno collegate tutte le postazioni sse degli utenti e le interfacce di rete cablata dei portatili; rete wireless protetta, con autenticazione 802.1x, dedicata agli utenti INFN in possesso del proprio certicato personale e delle credenziali di accesso wireless del progetto INFN/TRIP; rete wireless protetta, con autenticazione 802.1x, dedicata agli utenti universitari, per permettere un accesso sicuro agli utenti del dipartimento; rete wireless protetta da Captive Portal, dedicata agli utenti INFN in possesso o del proprio certicato personale o delle credenziali di accesso wireless del progetto INFN/TRIP; rete wireless protetta da Captive Portal dedicata agli utenti universitari, per permettere un accesso sicuro agli utenti del dipartimento, per supportare eventuali meccanismi futuri di autenticazione a livello internazionale tra Universit` a rete wireless dedicata agli studenti dei Corsi Triennali e Specialistici di Fisica, che verr` a gestita dal Dipartimento di Fisica per implementare politiche restrittive che permettano di garantire laccesso a certe porzioni della rete, in base, ad esempio, allanno di iscrizione di uno studente rete wireless dedicata a tutti gli utenti sia del dipartimento di sica che della sezione dellINFN; sostituisce la rete INFN-web per gli utenti locali che non devono inserire username/password per accedere alla rete, ma vengono riconosciuti in seguito alla registrazione del loro portatile sul database di autenticazione rete wireless dedicata ai convegni; viene attivata solo per convegni, seminari, workshop nei quali si prevede una grande afuenza di persone, che non aeriscono n e al dipartimento di Fisica, n e a INFN rete dedicata a distribuire il tronco pubblico della rete del Dipartimento di Fisica; conterr` a tutti i server pubblici del Dipartimento (web, posta ecc.) come la precedente, distribuisce il tronco pubblico della rete INFN, nella quale vengono inseriti tutti i servizi pubblici della sezione INFN di Perugia rete del laboratorio di informatica come la precedente ma riguarda il laboratorio di Acquisizione Dati situato al piano terra rete della farm di calcolo del dipartimento; ospita sia i calcolatori della griglia di calcolo INFN (INFN Grid), sia quelli di singoli esperimenti, che sono stati integrati nella stessa struttura: con le VLAN possiamo ad esempio associare un qualsiasi computer delledicio alla griglia di calcolo, aumentando la sua capacit` a elaborativa 61 Tabella 4.1: Reti nascoste del progetti

Rete di controllo Wired INFN-dot1x FISICA-priv INFN-web FISICA-web STUD WL-common OPEN FISICA INFN INFOLAB ACQLAB FARM

10.0.0.0/255.255.0.0 Fisica: 10.2.0.0/255.255.128.0, INFN: 10.2.128.0/255.255.128.0 10.3.0.0/255.255.0.0 10.4.0.0/255.255.0.0 10.5.0.0/255.255.0.0 10.6.0.0/255.255.0.0 10.7.0.0/255.255.0.0 Fisica: 10.8.0.0/255.255.128.0, INFN: 10.8.128.0.0/255.255.128.0 10.9.0.0/255.255.0.0 141.250.2.0/255.255.255.0 (pubblica) 193.205.222.0/255.255.255.0 (pubblica) 192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0 192.168.254.0/255.255.255.0 Tabella 4.2: Indirizzamento delle reti

Il primo passo ` e quindi quello di memorizzare in ogni switch (quelli di dorsale almeno) il codice delle VLAN usate (si veda la gura 4.1); i dati da fornire in congurazione sono: VLAN ID : il codice della VLAN (compreso tra 1 e 4094); VLAN Name : il nome della VLAN, opzionale, utilizzato solo per facilitare lutente; Local ID : codice usato internamente su vecchi switch che permettono di congurare no ad un massimo di 16 VLAN;

Figura 4.1: Schermata di aggiunta di una VLAN sullo switch 3Com 3300

4.2.2

Tagging delle porte

La fase successiva consiste nel denire quali porte appartengono a ciascuna VLAN: ciascuna VLAN pu` o essere annunciata su zero o pi` u porte e ciascuna porta pu` o appartenere ad una o pi` u VLAN. Lappartenenza di una porta ad una VLAN pu` o avvenire in due modi: Tagged : i pacchetti Ethernet che contengono al loro interno quel particolare VLAN ID (che si dicono quindi tagged) vengono fatti passare e possono essere inoltrati solo su porte che appartengono alla stessa VLAN eseguendo quindi una segmentazione dello switch; nellimmagine 4.2 aggiungiamo porte Tagged alla lista della VLAN 2 (WIRED).

62

Figura 4.2: Aggiunta di porte in modalit` a Tagged ad una VLAN

Untagged : i pacchetti Ethernet che passano per quella porta e non contengono un VLAN ID vengono colorati (o meglio Taggati) per quella VLAN, cio` e viene inserita lintestazione 802.1q con quel VLAN ID e sono quindi inoltrati verso altre porte di quella VLAN; nellimmagine 4.3 si noti la parte evidenziata nella quale specichiamo la rete 2 (WIRED) come Untagged VLAN per la porta 1 dello switch.

Figura 4.3: Denizione della VLAN Untagged per una porta dello switch

Da ci` o consegue che ogni porta pu` o appartenere a molte VLAN in modalit` a Tagged, ma ad una sola in modalit` a Untagged, che quindi inserisce nella VLAN Untagged tutto il traco non 802.1q proveniente da quella porta.

63

Figura 4.4: Esempio di separazione dei domini VLAN

Si possono creare delle congurazioni complesse che distribuiscono le varie VLAN per tutti gli switch presenti nella rete, come mostra la gura 4.4.

4.2.3

Congurazione VLAN con SSID multipli su AP wireless

Gli access point usati nella nostra struttura sono i Cisco Aironet 1100 e 1200. Come si ` e visto nel progetto della rete nel paragrafo 2.3, ad ogni rete wireless corrisponde una particolare VLAN. Per congurare gli access point (AP) wireless ad operare in questa struttura si deve procedere in questo modo: 1. far conoscere agli AP la presenza e gli identicatori delle VLAN associate 2. creare degli SSID per ciascuna rete 3. impostare le politiche di sicurezza per ciascuna rete

Congurazione delle VLAN negli access point


Per aggiungere una VLAN negli access point, basta selezionare la voce VLAN nella sezione Service dellinterfaccia web di congurazione.

Figura 4.5: Congurazione delle VLAN sugli Access Point Cisco


Come si vede nellimmagine 4.5, per aggiungere una VLAN basta inserire il suo VLAN ID e un nome, opzionale, per riconoscere la rete pi` u facilmente. Si pu` o scegliere quale VLAN deve essere nativa, cio` e alla quale associare i pacchetti che non hanno un VLAN ID denito.

64

Creazione degli SSID per ogni rete


A questo punto gli access point conoscono la struttura della rete, e quindi possono comunicare con le VLAN inserite nella fase precedente. Quello che manca perch e un computer si possa connettere alla rete senza li ` e denire gli SSID, o meglio gli ESSID2 . Come mostra limmagine 4.6, per denire un SSID, cio` e una nuova rete3 wireless, basta digitare il suo nome, la VLAN associata a questa rete e linterfaccia di rete wireless da usare (se ve ne fosse pi` u di una).

Figura 4.6: Congurazione degli SSID sugli Access Point Cisco


In questo momento si possono denire le politiche di sicurezza della rete: per esempio, per la rete WL-common verr` a impostato laccesso con autenticazione su indirizzo MAC che sar` a controllato sul server RADIUS. Unaltra impostazione riguarda lannuncio della rete ai client: spesso questa opzione, che va sotto il nome di Broadcast SSID in Beacon4 , viene attivata per fare in modo che un client veda la rete wireless alla quale associarsi e la selezioni. Se invece la rete non venisse annunciata con il Beacon, un client dovrebbe conoscere a priori lSSID della rete alla quale associarsi e tentare la connessione: questa impostazione ` e consigliata per reti nascoste alle quali deve accedere un ristretto numero di persone che conoscono il nome della rete.

Denire le politiche di accesso


Dopo aver creato gli SSID, si pu` o fare un riepilogo delle reti create e, soprattuto, denire con esattezza le restrizioni di accesso e le impostazioni di autenticazione per ciascuna rete. Prima di tutto si devono fornire allaccess point gli indirizzi dei server RADIUS per le varie reti. Ad esempio per la rete WL-common la politica di autenticazione ` e Open with MAC authentication, cio` e con controllo del MAC address; questi MAC address saranno controllati sul server radius-wlcommon.priv, creato appositamente su una macchina virtuale, per autenticare gli indirizzi sici delle schede wireless registrate. La rete wireless INFN-web ha unautenticazione Open che non richiede altri controlli: lautenticazione degli utenti per questa rete avviene tramite Captive Portal; quindi il problema dellautenticazione viene demandato dallaccess point al Captive Portal. Al contrario delle precedenti, la rete INFN-dot1x prevede autenticazione EAP, con il meccanismo di cifratura AES CCMP con TKIP. Il server RADIUS che autentica gli utenti di questa rete ` e radius.pg.infn.it.
legga il paragrafo 3.2.1 per maggiori informazioni termine ` e usato impropriamente, perch e si dovrebbe parlare non di rete, ma di identicatore per un insieme di servizi, che consistono nellaccesso alla VLAN associata 4 un pacchetto spedito dagli Access Point per far conoscere ai client gli SSID che forniscono
3 questo 2 si

65

Terminata la fase di congurazione dei dispositivi, occorre congurare i servizi della rete.

4.3

Implementazione del progetto TRIP

Per realizzare in concreto il progetto TRIP bisogna installare e congurare alcuni servizi: 1. Accesso wireless con autenticazione 802.1x 2. server RADIUS con proxying 3. Captive Portal con autenticazione su username/password o certicato digitale X.509 Linstallazione del progetto TRIP deve avvenire dopo aver congurato sia gli switch della rete cablata che gli Access Point della rete wireless con la struttura a VLAN. INFN/TRIP presuppone una infrastruttura wireless preesistente che riservi almeno due VLAN per laccesso dei dipendenti/associati INFN: INFN-web: per laccesso tramite Captive Portal con certicato digitale o username/password INFN-dot1x: per laccesso cifrato con certicato digitale e username/password (per una maggiore sicurezza con 802.1x) Il progetto TRIP prevedeva inizialmente 3 metodi di autenticazione, aggiungendo a quelli appena descritti le VPN5 . Questi 3 metodi sono stati scelti vista lesperienza dei progettisti e dei sistemisti INFN con tali tecnologie. Il meccanismo delle VPN non ` e stato sviluppato nel progetto. In tutti i casi il server di autorizzazione sar` a un server RADIUS, che attualmente lo standard di fatto nel settore.

4.3.1

Congurazione Access point per 802.1x

La congurazione degli access point per la rete INFN-dot1x ` e abbastanza laboriosa, perch e garantisce un buon livello di sicurezza mettendo in gioco vari elementi come lautenticazione e i certicati digitali. Come visto nei paragra precendeti, abbiamo degli access point congurati per lavorare con le VLAN, ma non sono state denite ancora le politiche di accesso per la rete INFN-dot1x che richiede una particolare congurazione.

Congurazione della procedura di autenticazione


Per congurare lautenticazione con 802.1x per lSSID INFN-dot1x si deve scegliere tra i metodi di autenticazione possibili nel Cisco 1100, quello che va sotto il nome di Open Authentication with EAP6 , come si vede nellimmagine 4.7. Senza dimenticarsi di specicare il server RADIUS al quale delegare lautenticazione. Ora bisogna andare nella sezione relativa allEncryption Manager, che permette di impostare il metodo di cifratura, cio` e AES-CCMP+TKIP7 , come mostrato nellimmagine 4.8.
5 Virtual Private Network, meccanismo di tunnelling di una comunicazione da una rete verso unaltra 6 per una descrizione del protocollo EAP si veda la sezione relativa nel paragrafo 3.2.2 7 un meccanismo di cifratura che usa lalgoritmo AES, Advanced Encryption Standard, insieme ai protocolli CCMP, Counter Mode with Cipher Block Chaining Message Authentication Code, e TKIP, Temporal Key Integrity Protocol, che si ripropongono insieme di sostituire il vecchio metodo WEP, Wired Equivalent Privacy.

66

Figura 4.7: Congurazione dellautenticazione sugli Access Point Cisco

Figura 4.8: Dettaglio della congurazione dei metodi di cifratura

Congurate queste opzioni basta abilitare la rotazione delle chiavi WPA8 con lopzione Broadcast Key Rotation Interval. Ora ` e nalmente conclusa la congurazione della procedura di autenticazione 802.1x per la rete INFN-dot1x.

4.3.2

Congurazione Captive portal

In questa fase si deve creare il Captive Portal per lautenticazione degli utenti della rete wireless. Si noti che questa procedura ` e comune alle reti INFN-web, OPEN e FISICA-web.

Congurazione server web


Il computer sul quale ` e installato il server web che fa girare i Captive Portal ` e privgw.priv che svolge anche il compito di router tra le reti. Il server ha uninterfaccia di rete per ogni VLAN, visto che deve gestire il routing. Per questo motivo si pu` o congurare il server web per rispondere in modo diverso in base alla rete dalla quale riceve richieste di accesso. Tramite il DNS vengono deniti vari alias per il server, uno per ogni rete: quindi avremo privgw.infnweb.priv, privgw.sicaweb.priv e privgw.open.priv. Queste scelta ` e guidata dal fatto che al primo accesso di un utente, vogliamo che la sua connessione sia bloccata dal Captive Portal; dopo aver eettuato laccesso, le connessioni da quel client saranno fatte passare verso Internet, attraverso il rewall. Come server web verr` a usato Apache 2, versione 2.0.58; questo software permette di denire varie istanze del server web, detti Virtual Host9 , diversicandoli in base al nome DNS o allindirizzo IP. Vengono deniti quindi 3 virtual host, relativi ai Captive
8 Wi-Fi Protected Access, un insieme di metodi di sicurezza per le reti wireless nato per risolvere alcune mancanze di WEP, Wired Equivalent Privacy 9 sistema implementato nei webserver, che permette di ospitare su uno stesso server pi` u di un sito o servizio

67

portal per le suddette reti. Per congurare un virtual host basta includere la sua congurazione allinterno del le di congurazione di Apache /etc/apache2/httpd.conf. Ecco la congurazione del virtual host per il Captive Portal della rete INFN-web: <VirtualHost 10.5.0.254:443> ServerName tino.infnweb.priv ServerAdmin simone.pascarosa@pg.infn.it ServerSignature On # General setup for the virtual host, inherited from global configuration DocumentRoot "/opt/tino/infnweb/tino-www" # tino config ScriptAlias /tino.cgi "/opt/tino/infnweb/tino/tino.cgi" <Location /tino.cgi> SSLVerifyClient optional SSLOptions +StdEnvVars SSLOptions +ExportCertData SSLVerifyDepth 2 </Location> CustomLog /var/log/apache2/tino-infnweb.ssl combined ErrorLog /var/log/apache2/tino-infnweb.ssl.error-log LogLevel warn SSLEngine On SSLCertificateFile /opt/tino/infnweb/self-signedCertificate/infnweb.crt SSLCertificateKeyFile /opt/tino/infnweb/self-signedCertificate/infnweb.key SSLCACertificateFile /etc/apache2/ssl/infnca.crt RewriteEngine on RewriteCond %{HTTP_HOST} !^tino\.infnweb\.priv [NC] RewriteCond %{HTTP_HOST} !^$ RewriteRule ^(.*) https://tino.infnweb.priv/tino.cgi [R=301,QSA,L] </VirtualHost> Senza soermarsi troppo sulla sintassi, si pu` o notare subito come venga denito un virtual host che sta in ascolto sullinterfaccia 10.5.0.254, sulla rete INFN-web, sulla porta 443, cio` e quella di http su tunnel cifrato (https10 ). Viene denito il nome del server, tino.infnweb.priv che sar` a un alias sul DNS per privgw.infnweb.priv, lindirizzo dellamministratore, e viene attivata la cifratura. Come si vedr` a nel paragrafo successivo, il software per il Captive Portal che ` e stato scelto ` e TINO NoCat, ed ` e implementato tramite uno script CGI11 in linguaggio Perl. La cartella di partenza del server web ` e quella di TINO, in modo che appaia proprio il Captive Portal come prima pagina a chi accede al server. A questo punto vanno congurate alcune opzioni che riguardano il controllo del certicato dellutente: queste funzioni servono per realizzare lautenticazione tramite
10 porta speciale che fa passare il solito traco HTTP su un livello di autenticazione e cifratura che si interpone tra HTTP e TCP 11 Common Gateway Interface, un protocollo standard per interfacciare applicazioni esterne con un webserver

68

certicato INFN installato sul browser del client. Il server web chieder` a al browser dellutente se possiede un certicato digitale: se la risposta ` e aermativa, il certicato viene trasmesso al server web che lo passer` a al Captive Portal perch e ne verichi la validit` a (le direttive coinvolte sono SSLVerifyClient, SSLOptions e SSLVerifyDepth ). Dopo aver congurato i le di log del virtual host, va completata la congurazione di SSL12 per la cifratura della connessione dal client al server: SLEngine On: attiva la cifratura sulla connessione; SSLCertificateFile /opt/tino/infnweb/self-signedCertificate/infnweb.crt: imposta il certicato digitale del server che viene usato per la cifratura del tunnel; SSLCACertificateFile /etc/apache2/ssl/infnca.crt: imposta il certicato della Certication Authority INFN ed ` e usato per identicare la CA che ha rmato il certicato del server. Con questo la congurazione ` e quasi terminata; rimane da impostare unultima opzione, che ` e anche la pi` u importante per un Captive Portal e cio` e la Rewrite Rule. Sotto questo nome va quel meccanismo implementato nei server web che permette la modica dellURL13 inserito dallutente: nel nostro caso si deve fare in modo che lutente, qualsiasi indirizzo digiti sul suo browser, venga rediretto sulla pagina di login del Captive Portal. Per fare questo deve essere attivato il motore di riscrittura, RewriteEngine on, e, dopo aver imposto alcuni casi in cui non deve essere eseguita alcuna riscrittura con la direttiva RewriteCond, specicare lindirizzo che va a sostituire quello digitato dallutente, con: RewriteRule ^(.*) https://tino.infnweb.priv/tino.cgi [R=301,QSA,L] ` bene analizzare pi` E u a fondo le parti di questultima direttiva: RewriteRule: ` e il nome della direttiva; ^ (.*) : questa ` e unespressione regolare che corrisponde a tutte le stringhe possibili, cio` e quelle che iniziano con zero o pi` u caratteri; https://tino.infnweb.priv/tino.cgi: questo ` e lURL che viene sostituito a quello digitato dallutente e corrisponde alla pagina di login del Captive Portal; [R=301,QSA,L]: queste ultime istruzioni permettono di passare delle opzioni allo script CGI per ricordarsi dellURL digitato dallutente. Al termine della congurazione di Apache abbiamo il server web funzionante, che visualizza la pagina di login di TINO al primo accesso dellutente. Agli accessi successivi la connessione dellutente non sar` a pi` u bloccata dal Captive Portal.

Congurazione Tino
TINO NoCat ` e stato sviluppato come componente di accesso e autenticazione per la ` scritto come CGI in rete wireless del Campus universitario di Palosaari, Finlandia. E Perl. Ecco, in alcuni passi, il suo funzionamento: 1. le connessioni vengono redirette alla pagina di login di Tino;
Socket Layer, un protocollo di crittograa che fornisce comunicazioni sicure per i trasferimenti dati di qualunque tipo su Internet 13 Uniform Resource Locator, un identicatore glovale che permette di riconoscere e recuperare un documento allinterno di Internet; ` e uno dei concetti chiave del World Wide Web
12 Secure

69

2. il MAC address dellutente che accede alla pagina viene ricercato allinterno dei lease del server DHCP; 3. allutente viene richiesto il nome utente e la password, oppure, se lo possiede, il suo certicato digitale; 4. se il login ` e andato a buon ne, lindirizzo IP, il MAC address, la data di login e il nome dellutente (eventualmente estratto dal certicato) vengono memorizzati in un le allinterno della directory di spool di Tino; 5. Tino invoca uno script di shell esterno per aprire il rewall alle connessioni entranti da quellindirizzo IP e MAC address. Come parte del pacchetto di Tino viene fornito anche un programma da linea di comando che controlla la scadenza dei lease DHCP degli utenti connessi ed eventualmente li cancella dalla directory di spool e dal rewall. La congurazione del software avviene impostando alcune variabili nel le tino.pm che contiene le funzioni principali dello script CGI. Vediamo alcuni frammenti della congurazione: our $spooldir = "/opt/tino/infnweb/spool"; our $logfile = "/opt/tino/infnweb/log"; my $fw_script = "sudo /opt/tino/infnweb/tino/firewall.sh"; Queste variabili impostano: 1. la directory di spool che conterr` a i le con le speciche degli utenti che hanno eettuato il login 2. il le di log 3. lo script che modica il rewall per far passare il traco del client che si ` e autenticato our $ca_match = "/C=IT/O=INFN/CN=INFN Certification Authority"; our $new_ca_match = "/C=IT/O=INFN/CN=INFN CA"; Successivamente va detto a Tino quale CA dovr` a riconoscere come valida per autenticare gli utenti tramite certicati digitali. In questo caso si specica il Distinguished Name della CA di INFN. Le stringhe sono due, perch e la CA di INFN ha di recente cambiato nome, perci` o va garantito il funzionamento anche dei certicati emessi dalla vecchia CA. my $dhcpd_leases = "/var/lib/dhcp/dhcpd.leases"; my $radius_host = "radius.pg.infn.it"; my $radius_secret = "********************"; our $default_realm = "\@pg.infn.it"; In questo frammento viene detto a Tino dove trovare le informazioni per autenticare i client che chiedono laccesso. Prima di tutti va impostato il percorso del le di lease del DHCP, che contiene le informazioni dellassegnamento degli indirizzi del DHCP che vengono dati agli utenti, con lindicazione dellindirizzo IP assegnato. Poi va detto a Tino dove si trova il server di autenticazione e come interagire con esso: perci` o viene indicato il nome del server RADIUS, radius.pg.infn.it, la password di accesso e il realm di default che sar` a appeso al nome utente inserito se non viene specicato alcun realm (se per esempio tenta laccesso lutente mario.rossi@mi.infn.it, non verr` a appesa questa stringa, ma se tentasse laccesso lutente simone.pascarosa, allora, prima di essere autenticato dal server RADIUS, la stringa sarebbe trasformata in simone.pascarosa@pg.infn.it ).

70

Congurazione rewall iptables per NAT e redirezione connessioni


Per eettuare il controllo delle connessioni ` e stato usato lo strumento iptables 14 . Non sar` a commentata tutta la congurazione del rewall del server, ma solo la parte relativa al Captive Portal, e in particolare sar` a analizzata solo quella della rete INFN-web, visto che quella delle altre reti con Captive Portal ` e simile. Il rewall segue la politica di specicare quali sono le connessioni accettate e di negare tutte le altre nella maggioranza dei casi. Quello che verr` a congurate sul rewall riguarda: accettazione del traco in ingresso dalla rete INFN-web; accettazione del forward del traco tra le interfacce interne e quelle su rete pubblica; mascheramento con NAT15 degli IP interni. Per organizzare i ltri, ` e stata creata una catena (Iptables Chain) che permette di raggruppare varie connessioni sotto lo stesso nome, per applicare regole a ciascuna di queste. /sbin/iptables -t filter -N filter_tino_infnweb /sbin/iptables -t filter -F filter_tino_infnweb Con queste istruzioni viene creata la catena lter tino infnweb. /sbin/iptables -t filter -A INPUT -p tcp -m state \ --state NEW -d 10.5.0.254 --dport 443 -j ACCEPT /sbin/iptables -t filter -A INPUT -p tcp -m state \ --state NEW -d 10.5.0.254 --dport 80 -j ACCEPT /sbin/iptables -t filter -A INPUT -j DROP Qui viene detto al rewall di accettare in ingresso tutte le nuove connessioni verso il server web, sia in chiaro (porta 80) che cifrate (porta 443). Lultima istruzione nega tutte le altre connessioni in ingresso. /sbin/iptables -t filter -A FORWARD -s 10.5.0.0/16 \ -d ! 10.5.0.0/16 -j filter_tino_infnweb Questa istruzione inserisce tutto il traco che passa attraverso il server, dalla rete INFN-web verso unaltra rete, quindi anche Internet, nella catena lter tino infnweb. /sbin/iptables -t nat -N nat_tino_infnweb /sbin/iptables -t nat -F nat_tino_infnweb /sbin/iptables -t -d ! 10.5.0.0/16 /sbin/iptables -t -d ! 10.5.0.0/16
14 uno

nat -A PREROUTING -s 10.5.0.0/16 \ -j nat_tino_infnweb nat -A PREROUTING -p tcp -s 10.5.0.0/16 \ --dport 80 -j DNAT --to-destination 10.5.0.254

strumento molto potente sotto GNU/Linux per intercettare e manipolare i pacchetti di rete 15 Network Address Translation, tecnica che permette di riscrivere lindirizzo IP sorgente e di destinazione di un pacchetto che attraversa un router per la sua trasmissione su unaltra rete

71

Impostate le regole di passaggio del traco, viene denita la traduzione degli indirizzi della rete INFN-web per andare su Internet. Infatti tutti i portatili di questa rete usciranno su Internet con lindirizzo 193.205.222.52. Le due istruzioni creano la catena nat tino infnweb e la puliscono. La terza istruzione inserisce il traco in passaggio nel server nella catena appena creata. La quarta istruzione merita un approfondimento: /sbin/iptables -t nat -A PREROUTING -p tcp -s 10.5.0.0/16 \ -d ! 10.5.0.0/16 --dport 80 -j DNAT --to-destination 10.5.0.254 Questa regola viene applicata ai pacchetti nella fase di PREROUTING, cio` e quando ancora non ` e stata presa la decisione di routing sul pacchetto: quello che si vuole fare infatti ` e bloccare la prima volta tutte le connessioni in uscita verso Internet, per obbligarle a passare dallautenticazione del Captive Portal. Il ltro intercetta i pacchetti provenienti dalla rete INFN-web (10.5.0.0/16), destinati ad unaltra rete (! 10.5.0.0/16) ed eettua un DNAT, cio` e un Destination NAT: in pratica viene cambiato nellintestazione IP lindirizzo dellhost di destinazione, impostando come destinatario il Captive Portal, che risponde allindirizzo 10.5.0.254 sulla porta 80 (http). /sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/8 \ -d ! 10.0.0.0/8 -o eth1 -j SNAT --to-source 193.205.222.52 Sistemata la rete interna, si deve specicare quale sar` a lindirizzo col quale i portatili verranno identicati su Internet ed usiamo perci` o lindirizzo dellinterfaccia pubblica sulla rete INFN del server (193.205.222.52). La regola infatti eettua il SNAT, Source NAT, che, dopo che ` e stata decisa la destinazione del pacchetto e prima che questo venga eettivamente trasmesso sullinterfaccia di rete giusta (la eth1), modica lindirizzo del mittente inserendo quello del server. In questo modo le risposte ai messaggi trasmessi verranno rispedite al nostro server, che sapr` a come rispedire il messaggio al giusto computer della rete interna.

4.3.3

Congurazioni RADIUS

Il server RADIUS utilizzato ` e FreeRADIUS, erede del pi` u vecchio Cistron RADIUS server. La congurazione del server RADIUS ` e molto lunga, perch e prevede decine e decine di moduli, plugin, driver per diversi back-end dai quali leggere i dati di autenticazione. I le di congurazione si trovano, di default, sotto la directory /etc/raddb (retaggio del vecchio Cistron): alcuni dei le contenuti in questa cartella sono inutili, ma vengono mantenuti per retrocompatibilit` a. I le pi` u importanti, che verranno commentati sono: radiusd.conf: congurazione generale del server, imposta le opzioni di logging, di sicurezza, il numero di processi da avviare, i driver backend da utilizzare e i ltri; inne vengono decisi i moduli da utilizzare nelle fasi di Autenticazione, Autorizzazione e Accounting; clients.conf: denisce i client (authenticator) che possono fare richiesta di autenticazione al RADIUS server; viene associato ad ogni client un nome e un segreto per evitare che un attaccante si spacci per un client autorizzato; eap.conf: congurazione delle opzioni EAP, denisce i tipi di autenticazione ammessi e le loro opzioni; proxy.conf: denisce i server che dovranno essere interrogati per i possibili REALM (domini) che ci aspettiamo di gestire (ad esempio infn.it)

72

users: denisce le autenticazioni da usare per i vari tipi di utenti e le risposte da fornire; questo le pu` o essere usato anche per contenere i dati di autenticazione (username/password) in mancanza di un backend pi` u organizzato come MySQL16 o LDAP.

radiusd.conf
Una prima sezione del le imposta le cartelle dove trovare gli eseguibili e le altre congurazioni, il le e le opzioni di logging. Tra le altre ci sono le opzioni di sicurezza e quelle riguardanti il numero di processi da avviare per servire le richieste. La parte pi` u importante ` e quella dei modules : i moduli sono delle parti di server che possono essere caricate o meno e che forniscono supporto per un certo backend dal quale leggere le congurazione, per un metodo di autenticazione (come ad esempio EAP) e per altre funzioni. Ecco la congurazione del modulo LDAP: ldap { server = "authserver.fisica.unipg.it" identity = "cn=Manager,dc=priv" password = ************ basedn = "ou=users,dc=priv" filter = "(&(uid=%{Stripped-User-Name:-%{User-Name}})(PerugiaGroups=radius-infn))" start_tls = no dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 } Come gi` a visto precedentemente, viene detto a RADIUS dove si trova il sever LDAP con i dati di autenticazione, quale parte della directory LDAP considerare e come ltrare i dati che ci riguardano. Laccesso al backend ` e protetto da password ed avviene con le credenziali di amministratore. Il ltro (&(uid=%Stripped-User-Name:-%User-Name) (PerugiaGroups=radius-infn)) fa selezionare solo lentry riguardante lutente che sta richiedendo laccesso; lattributo PerugiaGroups fa parte dello schema personalizzato che ` e stato creato e denisce a quale gruppo di utenti appartiene lutenza: in questo caso il server RADIUS risponde per gli utenti di INFN. Nella stessa directory ci sono anche gli utenti del Dipartimento di Fisica e gli studenti. Notare la clausola %Stripped-User-Name:... che permette di eliminare dal nome utente eventuali parti relative al dominio: gli utenti che si vogliono connettere alla rete tramite TRIP, possono specicare il loro nome utente con una stringa del tipo nome.cognome@pg.infn.it. La parte di dominio, quella che segue il simbolo @, viene usata per delegare lautenticazione ad un server autoritativo per quel dominio. Per i nostri utenti locali non c` e bisogno del dominio, quindi questa clausola ci permette di eliminarlo quando si va a cercare laccount allinterno della directory LDAP.
16 famoso

gestore di database, snello e disponibile con una licenza di software libero

73

clients.conf
In questo le vengono elencati tutti i client che possono interrogare il server RADIUS: in questo contesto per client si intende quello che nel protocollo 802.1x viene chiamato authenticator e cio` e i NAS (nel nostro caso gli Access Point) che vogliono autenticare i supplicant (i portatili) che tentano laccesso. Ecco un estratto del le, con una sintassi facilmente comprensibile: client 193.205.222.52 { secret = ********** shortname = privgw nastype = other } client 192.84.145.15 { secret = ************* shortname = radiushub } Per ogni client viene denito un nome e il segreto che dovr` a essere fornito per essere riconosciuti e per poter sottomettere richieste al server RADIUS. In questo caso gli unici computer ai quali viene dato accesso sono il router di frontiera, nel quale ` e ospitato il Captive Portal (193.205.222.52), e il server proxy RADIUS centrale di INFN dal quale si riceveranno le riguardanti utenti della Sezione di Perugia che tentano di autenticarsi su reti wireless di altre sezioni INFN.

eap.conf
Questo le imposta le opzioni EAP: congura i metodi di cifratura ammessi (nel nostro caso TTLS) e il tunnelling (EAP-TTLS). In questo le vanno inseriti i percorsi del certicato digitale del server e del certicato della CA (Certication Authority) per instaurare il tunnel cifrato EAP. eap { default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no # Tipi EAP supportati ## EAP-TLS tls { private_key_password = *************** private_key_file = ${raddbdir}/certs/RADIUSPG/key.pem certificate_file = ${raddbdir}/certs/RADIUSPG/radius.crt # Lista delle CA di cui ci fidiamo CA_file = ${raddbdir}/certs/INFNCA.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1024 check_cert_cn = %{User-Name} } ttls {

74

# default_eap_type = md5 copy_request_to_tunnel = no use_tunneled_reply = no } } Semplicemente viene impostato il metodo TTLS come tipo di cifratura di default per EAP che crea un tunnel cifrato nel quale eseguire le operazioni di autenticazione.

proxy.conf
In questo le vengono impostate le opzioni per la comunicazione con il server RADIUS proxy e si fanno conoscere al server tutti i realm, cio` e i domini conosciuti. proxy server { synchronous = no retry_delay = 5 retry_count = 3 dead_time = 120 default_fallback = yes post_proxy_authorize = no } realm LOCAL { type = radius authhost = LOCAL accthost = LOCAL } realm pg.infn.it { type = radius authhost = LOCAL accthost = LOCAL } realm DEFAULT { type = radius authhost = radius.garr.net:1812 accthost = radius.garr.net:1813 secret = ************** nostrip } Oltre al dominio pg.infn.it vengono impostati i domini LOCAL, in cui ricadono tutti gli utenti che non specicano la parte di dominio, e DEFAULT, in cui ricadono tutti gli altri utenti. In questo modo il server riconosce gli utenti che non specicano parte di dominio e quelli che specicano nome.cognome@pg.infn.it come utenti propri e li autentica usando le informazioni contenute nella directory LDAP. Lautenticazione degli altri viene delegata al server proxy radius.garr.net. Possiamo anche autenticare utenti che non appartengono ad INFN, ma che sono da esso riconosciuti e autorizzati ad entrare, con luso del server proxy.

75

users
Questo le contiene i proli degli utenti, che consistono nelle informazioni di autenticazione ed autorizzazione. DEFAULT EAP-Type == EAP-TLS, Auth-Type := Reject DEFAULT Auth-Type := LDAP DEFAULT Auth-Type = System Fall-Through = 1 Nel nostro caso vengono deniti i comportamenti di default del server per vari tipi di autenticazione. La seconda riga, in particolare, denisce il backend sul quale cercare le informazioni eettive di autenticazione ed autorizzazione; demanda quindi alla directory LDAP la memorizzazione dei dati

4.4

Congurazione directory LDAP

Limplementazione utilizzata per il server LDAP ` e OpenLDAP, versione 2.3.30. Congurare una directory LDAP non ` e un compito banale, perch e bisogna avere bene in testa luso che se ne vuole fare, la quantit` a di dati che dovr` a essere contenuta nella directory e la mole di traco prevista. OpenLDAP ` e stato installato con lo strumento emerge 17 con il comando: emerge openldap Linstallazione dei binari non richiede quindi particolari opzioni.

4.4.1

Congurazione servizio slapd

A questo punto va congurata la directory: il server LDAP si chiama slapd e va quindi modicato il le /etc/openldap/slapd.conf. Verr` a commentata ogni sezione del le di congurazione.

Inclusione schemi
La prima parte include gli schemi riconosciuti dal server. In questo modo slapd conosce la struttura delle entry che conterr` a la directory; se si tenta di inserire una entry che appartiene ad una objectClass 18 sconosciuta, LDAP negher` a linserimento. include include include include include include include include /etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema /etc/openldap/schema/dhcp.schema /etc/openldap/schema/authldap.schema /etc/openldap/schema/perugia.schema /etc/openldap/schema/dlz.schema

17 comando che permette di interagire con Portage, il sistema di gestione di pacchetti della distribuzione GNU/Linux Gentoo 18 una objectClass denisce la classe di una entry, cio` e gli attributi obbligatori e facoltativi che pu` o contenere

76

Oltre agli schemi standard largamente utilizzati per memorizzare informazioni personali, sono stati aggiunti anche degli schemi che serviranno a memorizzare le congurazioni per i servizi di rete e per rispecchiare meglio le necessit` a del dipartimento e di INFN: dhcp.schema: contiene le classi per le entry riguardanti le congurazioni del server DHCP, lassociazione MAC-address/IP-address, le congurazioni per le varie reti servite ed altre opzioni; dlz.schema: contiene le classi per il driver DLZ19 del DNS, che riguarda la congurazione del server DNS; perugia.schema: schema personalizzato realizzato per alcune funzionalit` a interne; authldap.schema: contiene le classi per le entry degli account degli utenti.

Schema PerugiaObject
Andiamo ad analizzare pi` u in dettaglio lo schema personalizzato, per comprenderne la necessit` a e i vantaggi: attributetype ( 1.1.2.1.1.201 NAME PerugiaGroups EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) attributetype ( 1.1.2.1.1.202 NAME PerugiaOwner EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) objectClass ( 1.1.2.2.1.200 NAME PerugiaObject SUP top AUXILIARY MUST ( cn $ PerugiaGroups $ PerugiaOwner) ) Lattributo PerugiaGroups permette di impostare lappartenenza di una entry ad un certo gruppo. Con questo gruppo, ad esempio, si riesce a discriminare, allinterno del sottoalbero dei contatti degli utenti, quelli appartenenti al Dipartimento di Fisica, da quelli di INFN. Lattributo ` e multivalore, infatti spesso una entry appartiene ad uno o pi` u gruppi: pu` o succedere, ad esempio, che un account debba poter essere utilizzato sia per accedere al proxy web, sia per lautenticazione wireless, sia per la posta; questo attributo viene letto da ciascuno di questi servizi e permette di inserirlo o meno nelle congurazioni di quel particolare servizio. Lattributo PerugiaOwner permette di specicare la persona a cui ` e associata una certa entry: ad esempio per una entry del DHCP si pu` o specicare chi ` e il possessore del computer con quellindirizzo. Altro utilizzo ` e quello di memorizzare il responsabile di una persona, ad esempio un ospite o un laureando. Questo attributo ci permette anche di fare delle ricerche, per sapere quali computer, quali account e in generale quali congurazioni riguardano una certa persona.
19 Dynamic

Loadable Zones, si legga il paragrafo 4.6.2 per maggiori informazioni

77

Se ad esempio vediamo sui log di un servizio un problema di un computer del quale conosciamo il MAC-address o lindirizzo IP, con questo sistema si pu` o facilmente risalire al proprietario per avvertirlo.

Opzioni del server


Successivamente vanno congurate le opzioni del server che riguardano i certicati, per stabilire sessioni cifrate (TLS, Transport Layer Security), il formato di Hash delle password e altri parametri di sistema, come si vede sempre nel le slapd.conf : allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel 1 password-hash {md5} TLSCertificateFile /etc/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/ssl/ldap.pem

Congurazione della directory


In questa sezione viene congurata, nalmente, la directory, dicendo al server quale albero conterr` a e come dovr` a essere gestito. database bdb suffix "dc=priv" checkpoint 32 30 rootdn "cn=Manager,dc=priv" rootpw {SSHA}******************* directory /var/lib/openldap-data index objectClass eq index dhcpHWAddress eq index dhcpClassData eq replogfile /var/openldap/slapd.replog replica uri=ldap://authserver2.fisica.unipg.it:389 binddn="cn=Manager,dc=priv" bindmethod=simple credentials="***********!" Andiamo ad analizzare le direttive una ad una: database bdb : questa opzione imposta il database di backend da utilizzare per memorizzare su disco le informazioni: OpenLDAP permette di usare come backend molti tipi di database, alcuni di questi sono riportati nella tabella 4.3 sux dc=priv : questa opzione imposta la radice dellalbero contenuto nella directory; ` e stato scelto il DN dc=priv, proprio ad identicare la rete come un dominio privato. Si noti che la radice ` e anchessa una entry della directory e per questo dovr` a essere inserita nellalbero checkpoint 32 30 : questa opzione permette di impostare le scadenze per il salvataggio del checkpoint del database (usato dai DB transazionali per recuperare

78

Tipi bdb dnssrv hdb ldap ldbm meta monitor passwd perl shell sql

Descrizione Database transazionale Berkeley Record SRV del sistema DNS Variante gerarchica di bdb Proxy LDAP Versione leggera di DBM Meta Directory Monitor Usa il passwd in modalit` a read-only Interfaccia Perl programmabile Programma esterno (via Shell) Interfaccia SQL programmabile

Tabella 4.3: Backend disponibili per LDAP


i dati modicati dalle transazioni in seguito ad un guasto); il primo valore indica il limite di dati in kilobyte modicati prima del quale eseguire il checkpoint, mentre il secondo indica i minuti di ritardo. In questo modo il checkpoint verr` a eettuato ogni 32Kb inseriti nel database e comunque almeno una volta ogni 30 minuti (per avere una buona tolleranza) rootdn cn=Manager,dc=priv rootpw SSHA************** : queste opzioni impostano il DN dellutente root e la sua password specicata tramite lHash SSHA20 ; questo utente potr` a accedere alla directory e modicare qualunque entry. Si noti che laccount dellutente ` e una entry della directory, che deve esistere nellalbero directory /var/lib/openldap-data : questa opzione imposta il percorso nel quale saranno memorizzati i le della directory, nel formato specico del backend database scelto. index objectClass eq index dhcpHWAddress eq index dhcpClassData eq : queste opzioni creano degli indici per velocizzare la ricerca dei dati secondo alcuni attributi; si ` e scelto di inserire la ricerca sul campo objectClass perch e spesso questo viene inserito tra i parametri; inoltre i campi dhcpHWAddress e dhcpClassData permettono di velocizzare la ricerca dei dati di un computer in base al suo MAC-address. La clausola eq specica che si creano indici per ricerche di uguaglianza e non di verosimiglianza o di similitudine (verr` a velocizzata quindi la ricerca di un particolare MAC-address ma non, ad esempio, la ricerca dei MAC-address che contengono al loro interno la stringa c5 ) replogle /var/openldap/slapd.replog : questa opzione specica il le di replication log utilizzato dal demone slurpd per comunicare ai server secondari le modiche avvenute sulla copia originale replica uri=ldap://authserver2.sica.unipg.it:389 binddn=cn=Manager,dc=priv bindmethod=simple credentials=******* : questa opzione specica un server secondario sul quale eseguire la replica: questo server sar` a una copia aggiornata
20 versione

potenziata del Secure Hash Algorithm

79

del server originale, ma verr` a utilizzata solo per la lettura; le modiche verranno eettuate sempre sul master, che avr` a cura, tramite questa direttiva, di avvertire gli altri server, delle modiche

4.4.2

Inserimento entry per lo startup

Dopo aver congurato la directory LDAP va avviato il servizio. Prima di farlo per` o devono essere inserite le entry relative alla radice della directory, dc=priv, e allutente amministratore, cn=Manager,dc=priv. Per inserirle basta creare un le LDIF con la specica delle due entry (ad esempio in /home/simone/primo.ldif ): dn: dc=priv objectClass: dcObject objectClass: organization dc: priv o: Department of Physics - University of Perugia - INFN dn: cn=Manager,dc=priv objectClass: organizationalRole cn: Manager Creato il le con queste righe, va inserito nella directory con il comando: ldapadd -h localhost -D "cn=Manager,dc=priv" -W -f /home/simone/primo.ldif Da questo momento pu` essere utilizzata appieno la directory LDAP.

4.5

Congurazione repliche LDAP

I server di replica LDAP sono dei server slapd secondari il cui scopo ` e quello di replicare le informazioni del server centrale e di rispondere alle sole operazioni di interrogazione in sua vece. La replicazione della directory avviene tramite il server slurpd, che gira sul server centrale. Slurpd propaga le modiche avvenute su un database LDAP verso altri server. Se slapd ` e congurato per tenere un log di replicazione, slurpd legge questo log e spedisce le modiche ai server slave sempre con il protocollo LDAP, come mostrato in gura 4.9.

Figura 4.9: Meccanismo di replica in LDAP

Il funzionamento ` e molto semplice:

80

allavvio slurpd controlla se esiste il le di replica e se ci sono state modiche che devono essere propagate ai server secondari (se non ci fossero, slurpd si mette in riposo e si riattiva ad intervalli regolari per controllare il le); se ci sono state modiche, slurpd mette un lock sul le di replica, se ne fa una copia privata, rilascia il lock sul le originale e crea tante copie del suo processo, quanti sono i server slave su cui replicare; ogni processo creato si collega e si autentica sul server secondario e spedisce le modiche.

Congurazione slapd secondari


Ecco una sezione del le di congurazione di slapd per un qualunque server secondario: database bdb suffix "dc=priv" checkpoint 32 30 rootdn "cn=Manager,dc=priv" rootpw {SSHA}******************** directory /var/lib/openldap-data index objectClass eq index dhcpHWAddress eq index dhcpClassData eq updatedn "cn=Manager,dc=priv" La congurazione ` e simile a quella del server centrale, visto che i dati che devono essere memorizzati sono gli stessi. Si pu` o comunque selezionare un backend diverso, visto che la consistenza dei dati deve essere mantenuta solo a livello semantico, non serve che i formati sici di memorizzazione siano gli stessi tra i server. La clausola updatedn specica lutente che pu` o entrare dal server centrale per eettuare gli aggiornamenti necessari a mantenere la copia locale coerente. Nel server centrale si dovr` a semplicemente avviare il demone slurpd, che legger` a la congurazione dal le /etc/openldap/slapd.conf, soprattutto la sezione riguardante le repliche: replogfile /var/openldap/slapd.replog replica uri=ldap://authserver2.fisica.unipg.it:389 binddn="cn=Manager,dc=priv" bindmethod=simple credentials="**********" Qui vengono specicati il le di replica nel quale leggere le modiche alla directory e lelenco dei server secondari, in questo caso uno solo, che si aggiorneranno da questa copia centrale.

4.6

Congurazione DNS e DHCP

Completato il server LDAP, dobbiamo congurare le macchine su cui sono in esecuzione i servizi base della rete per leggere le proprie congurazione dalla directory LDAP. Si noti che alcuni degli strumenti usati sono molto nuovi e la documentazione disponibile su Internet ` e scarna, eccetto alcuni sporadici esempi. I servizi che vanno congurati con laccesso alla directory LDAP sono:

81

DHCP per la distribuzione dei parametri di accesso alla rete (indirizzo IP, maschera di rete, router IP, server DNS) DNS per la risoluzione dei nomi degli host sulla rete, che avr` a come dominio .priv, per distinguerla dalle reti pubbliche; questo DNS servir` a solo ai computer interni alla rete privata e permetter` a linterrogazione dei DNS di Internet RADIUS per lautenticazione degli utenti della rete wireless su MAC-address (questa congurazione ` e stata analizzata nel paragrafo 4.3.3 per laccesso su nome utente/password)

4.6.1

Congurazione DHCP

Il server DHCP che ` e stato utilizzato ` e il diusissimo ISC21 DHCP versione 3.0.5. Purtroppo la versione base del software non supporta la lettura delle congurazioni su server LDAP, perci` o` e stato necessario applicare una patch e ricompilare il pacchetto. La congurazione di un server DHCP ` e abbastanza semplice, poich e basta elencare le reti disponibili e le associazioni MAC-address / indirizzo IP per ogni client che deve essere servito, assieme ad altri parametri che vanno passati ai client come maschera di rete, router IP, server DNS ecc. Nel nostro caso le congurazioni sono contenute nella directory LDAP, perci` o il le di congurazione ` e molto scarno, in quanto contiene solamente i parametri necessari a collegarsi alla directory e a leggere le entry che interessano. Andiamo ad analizzare il le di congurazione dhcpd.conf : ldap-server "authserver.fisica.unipg.it"; ldap-port 636; ldap-username "cn=Manager,dc=priv"; ldap-password "***********"; ldap-base-dn "ou=dhcp,dc=priv"; ldap-method dynamic; ldap-debug-file "/var/log/dhcp-ldap-startup.log"; ldap-ssl on; Il signicato ` e spiegato dalla sintassi stessa: prima di tutto viene specicato lindirizzo del server LDAP e la porta sulla quale sta in ascolta cio` e la porta 636 del server authserver.sica.unipg.it deve essere specicato poi lutente col quale collegarsi alla directory, nel nostro caso ` e lamministratore con relativa password successivamente viene indicato il sottoalbero; sotto ou=dhcp,dc=priv si troveranno tutte le entry relative alla congurazione del DHCP la direttiva ldap-method ammette due valori: static forza il server a leggere le congurazioni da LDAP allavvio e in seguito il server LDAP non verr` a pi` u contattato; dinamic non vengono caricate le congurazioni allinizio, il server contatta LDAP per una certa entry solo quando ne ha bisogno (permette di modicare le congurazioni del DHCP a runtime senza doverlo riavviare ad ogni modica); il le specicato nella direttiva ldap-debug-le permette di controllare la correttezza delle congurazioni lette da LDAP, infatti su questo le il server DHCP scrive le congurazioni base che legge allo startup dopo il primo avvio, nello stesso formato della congurazione stardard dhcpd.conf. lultima direttiva attiva il tunnel cifrato SSL, per proteggere le comunicazioni tra server DHCP e LDAP.
21 Internet Systems Consortium, ente senza ni di lucro che sviluppa software e protocolli fondamentali per il funzionamento della rete Internet

82

Formato congurazioni DHCP nella directory


Le congurazioni del DHCP vengono memorizzate nella directory nel sottoalbero ou=dhcp,dc=priv. La struttura ` e rappresentata in gura 4.10.

Figura 4.10: Gerarchia delle congurazioni del DHCP su LDAP


Come si vede nella gura, le congurazioni sono separate in due parti: la prima contiene i dati delle reti servite, con gli indirizzi IP dei client registrati; laltra contiene le eventuali opzioni del server. Le classi di oggetto delle entry che riguardano le congurazioni sono contenute nel le dhcp.schema : dhcpService contiene le opzioni generali del servizio, come ad esempio la durata del lease time 22 , il nome del server DHCP e se il server ` e autoritativo per le reti che serve dhcpSubnet contiene la specica di una rete servita dal DHCP, il suo indirizzo, la maschera di rete ecc. dhcpOptions classe che permette di aggiungere espressivit` a alle entry del DHCP: al suo interno si possono inserire le stesse direttive che vengono usate dal formato standard del le dhcpd.conf, come quelle per denire il router di default e i server DNS dhcpHost contiene i dati riguardanti un computer, che sono lindirizzo Ethernet della scheda di rete (il MAC-address) e lindirizzo IP assegnato dhcpServer crea istanze del server DHCP e permette di far condividere la stessa congurazione a pi` u server: nel nostro caso c` e un solo server DHCP, perci` o una sola entry per questa classe Andiamo ad analizzare un frammento della directory riguardante le congurazioni del DHCP: #Entry radice del sottoalbero del DHCP dn: ou=dhcp,dc=priv ou: dhcp objectClass: organizationalUnit objectClass: top #Opzioni di default del servizio dn: cn=DHCP Config,ou=dhcp,dc=priv cn: DHCP Config objectClass: top objectClass: dhcpService
22 il periodo di validit` a dei dati di congurazione, scaduto il quale il client dovr` a rinnovare la richiesta al DHCP

83

dhcpPrimaryDN: cn=privgw,ou=dhcp,dc=priv dhcpStatements: ddns-update-style interim dhcpStatements: authoritative dhcpStatements: default-lease-time 3600 dhcpStatements: max-lease-time 86400 #Server che utilizzeranno queste configurazioni dn: cn=privgw,ou=dhcp,dc=priv cn: privgw objectClass: top objectClass: dhcpServer dhcpServiceDN: cn=DHCP Config,ou=dhcp,dc=priv #Opzioni di default per la sottorete 10.2.0.0/16 dn: cn=10.2.0.0,cn=DHCP Config,ou=dhcp,dc=priv cn: 10.2.0.0 objectClass: top objectClass: dhcpSubnet objectClass: dhcpOptions dhcpNetMask: 16 dhcpOption: domain-name-servers 10.2.0.254, 141.250.2.7, 193.205.222.2, 141.250.1.6, 131.154.1.3 dhcpOption: routers 10.2.0.254 #Computer della rete 10.2.0.0/16 dn: cn=pascarosa-pc0,cn=10.2.0.0,cn=DHCP Config,ou=dhcp,dc=priv objectClass: dhcpHost objectClass: top objectClass: PerugiaObject dhcpHWAddress: ethernet AA:BB:CC:DD:EE:FF dhcpStatements: fixed-address 10.2.0.12 PerugiaGroups: dhcp PerugiaOwner: Simone Pascarosa cn: pascarosa-pc0

Da rilevare il valore del campo PerugiaOwner dellultima entry del listato, che permette di specicare il proprietario del computer. Il valore contenuto corrisponde al CN (common name) dellutente, come registrato nella sezione dedicata agli utenti della directory LDAP; esiste infatti una entry con distinguished name cn=Simone Pascarosa,ou=people,dc=priv. In questo modo si pu` o risalire in modo veloce al proprietario di un certo computer.

4.6.2

Congurazione DNS

Il server DNS utilizzato ` e ISC Bind, versione 9.4.1. Anche questo server, come per il DHCP, ha bisogno di una patch per leggere le congurazioni da directory LDAP. Fortunatamente la distribuzione GNU/Linux Gentoo permette di selezionare, tra le varie opzioni di installazione, il supporto per gli schemi LDAP, perci` o linstallazione pu` o essere eseguita con il solo comando:

USE="dlz" emerge bind

84

Il progetto DLZ23 (Dynamically Loadable Zones) ha creato dei moduli per il server Bind, che permettono di leggere le congurazioni da un qualunque database allo stesse modo gi` a visto per DHCP su LDAP. Viene fornito come patch ai sorgenti di Bind. DLZ permette di leggere le congurazioni da database MySQL, PostgreSQL, Berkeley DB, ODBC e naturalmente LDAP. La congurazione usuale di un server DNS prevede la creazione di le di zona, che contengano le congurazioni per i domini serviti dal DNS e al loro interno vengono specicate le associazioni nome-a-dominio/indirizzo-IP ed altri nomi di servizio. La struttura che verr` a realizzata a livello di domini ` e riportata nella gura 4.11.

Figura 4.11: Domini della rete privata


Il le di congurazione principale del server dns ` e /etc/bind/named.conf : options { directory "/var/bind"; listen-on-v6 { none; }; listen-on { 127.0.0.1; 10.0.0.254; 10.2.0.254; 10.3.0.254; 10.4.0.254; 10.5.0.254; 10.6.0.254; 10.7.0.254; 10.8.0.254; 10.9.0.254; }; allow-transfer { none; }; // to allow only specific hosts to use the DNS server: allow-query { 127.0.0.1; 10.0.0.0/8; }; pid-file "/var/run/named/named.pid"; }; Questa sezione imposta alcune opzioni generali del server: la directory dove sono contenute le zone statiche (quelle che non sono inserite in LDAP perch e cambiano raramente, cio` e i root server di Internet) gli indirizzi sui quali il server sta in ascolto: va specicata una interfaccia per ogni sottorete diversa (per ogni VLAN) le reti dalle quali accettare richieste Successivamente viene fatto lelenco delle zone statiche del DNS: zone "." IN { type hint;
23 si

veda il sito di riferimento del software [9]

85

file "named.ca"; }; zone "localhost" IN { type master; file "pri/localhost.zone"; allow-update { none; }; notify no; }; zone "127.in-addr.arpa" IN { type master; file "pri/127.zone"; allow-update { none; }; notify no; }; Queste riguardano i root server di Internet, elencati appunto nel le /var/bind/named.ca, la zona locale e la zona locale inversa, quella che risolve i nomi per gli indirizzi del tipo 127.X.Y.Z. Inne va detto a Bind di caricare le zone e le congurazioni dei vari host da LDAP: dlz "ldap zone" { database "ldap 1 v3 simple {cn=Manager,dc=priv} {*********} {X.Y.Z.K} ldap:///dlzZoneName=%zone%,ou=dns,dc=priv???objectClass=dlzZone ldap:///dlzHostName=%record%,dlzZoneName=%zone%,ou=dns,dc=priv? dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr? sub?(&(objectClass=dlzAbstractRecord)(!(dlzType=soa))) ldap:///dlzHostName=@,dlzZoneName=%zone%,ou=dns,o=bind-dlz? dlzTTL,dlzType,dlzData,dlzPrimaryNS,dlzAdminEmail,dlzSerial, dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub? (&(objectclass=dlzAbstractRecord)(dlzType=soa)) ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType, dlzHostName,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS, dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire, dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa))) "; }; La congurazione LDAP del DNS, sebbene gerarchica, similmente a quella del DHCP, rispetta il vecchio meccanismo dei record delle congurazioni canoniche del DNS. Si avr` a sempre la suddivisione in zone e allinterno delle zone i record che descrivono i dati dei nomi registrati (per maggiori dettagli si rimanda al prossimo paragrafo). La parola chiave dlz apre la dichiarazione delle zone LDAP. Andiamo a vedere il signicato delle righe contenute in questa sezione, notando che la specica consiste nella sola direttiva database, seguita da una lunga serie di opzioni: la prima riga contiene la specica del database utilizzato (LDAP), il numero di connessioni parallele che il driver mantiene con il server LDAP (1), la versione del protocollo LDAP (versione 3), le credenziali di accesso alla directory (le stesse incontrate anche nelle altre congurazioni) e lindirizzo IP del server LDAP; la seconda riga ` e la query LDAP che seleziona le entry delle zone DNS allinterno della directory (infatti le zone si trovano sul sottoalbero con radice in ou=dns,dc=priv) che appartengono appunto alla classe dlzZone;

86

la riga successiva ` e la query che seleziona le entry che contengono le informazioni sui nomi a dominio: si noti che vengono scartate le entry riguardanti il record SOA24 (Start Of Authority) in quanto questa query viene invocata proprio per fornire una risposta ad una interrogazione, mentre il record SOA ` e utilizzato per descrivere le impostazioni generali della zona; la quarta riga risponde alla richieste del record SOA e permette al server DNS di leggere le opzioni necessarie alla sincronizzazione delle zone; lultima riga ` e di supporto alla precedente per lutilizzo del record SOA. Il server DNS quando riceve la richiesta per la risoluzione di un nome a dominio, inserisce il nome richiesto nel campo %record%, la parte di dominio nel campo %zone% e manda una interrogazione al server LDAP; se esiste lentry cercata, viene restituito tutto il sottoalbero ad essa associato, che contiene le congurazioni nel formato classico dei record DNS, con indirizzo IP e nome a dominio.

Formato congurazioni DNS nella directory


Le congurazioni del DHCP vengono memorizzate nella directory nel sottoalbero ou=dns,dc=priv. La struttura ` e rappresentata in gura 4.12.

Figura 4.12: Gerarchia delle congurazioni del DNS su LDAP

Come si vede nella gura, le congurazioni sono fortemente gerarchiche e vi si trovano: entry per la memorizzazione delle zone, che identicano la zona e si pongono come radice del sottoalbero contenente i dati di quella zona DNS (appartengono alla classe dlzZone) entry per la memorizzazione degli host: identicano un host e lo pongono come radice del sottoalbero contenente i dati di quellhost (appartengono alla classe dlzHost); anche il SOA, identicato con il carattere @, viene visto come un host; entry per la memorizzazione eettiva dei dati, relativi ai record della zona: contengono lindirizzo IP del computer e il suo nome a dominio, ma possono contenere in generale tutti i record tipici del DNS, quali il record A, CNAME e SOA, che corrispondono rispettivamente alle classi dlzARecord, dlzSOARecord e dlzCNameRecord. Come si vedr` a nel listato successivo, la gerarchia proposta da DLZ permette di strutturare la directory in zone, host e record relativi agli host; ma un DNS contiene anche altri record, come quelli per denire degli alias (CNAME) che non si inseriscono bene in questa struttura.
24 record che specica il server DNS che contiene le informazioni autoritative per un dominio, lemail dellamministratore, il numero seriale della zona e alcune tempicazioni per gli aggiornamenti delle zone

87

Larticio introdotto da DLZ ` e di considerare ogni cosa come un host (anche il record SOA e un nome CNAME) e al suo interno inserire lentry con la congurazione corretta. Vediamo appunto un estratto del sottoalbero del DNS nella directory LDAP: #Radice del sottoalbero del DNS dn: ou=dns,dc=priv ou: dns objectClass: organizationalUnit objectClass: top #Radice della zona relativa al dominio wired.priv dn: dlzZoneName=wired.priv,ou=dns,dc=priv dlzZoneName: wired.priv objectClass: dlzZone #Radice della configurazione del SOA della zona wired.priv dn: dlzHostName=@,dlzZoneName=wired.priv,ou=dns,dc=priv dlzHostName: @ objectClass: dlzHost #Configurazione del SOA della zona wired.priv dn: dlzRecordID=1,dlzHostName=@,dlzZoneName=wired.priv,ou=dns,dc=priv dlzAdminEmail: root.fisica.unipg.it. dlzExpire: 604800 dlzHostName: @ dlzMinimum: 86400 dlzPrimaryNS: privgw.priv. dlzRecordID: 1 dlzRefresh: 2800 dlzRetry: 7200 dlzSerial: 2007052302 dlzTTL: 10 dlzType: soa objectClass: dlzSOARecord #Host della zona wired.priv dn: dlzHostName=pascarosa-pc0,dlzZoneName=wired.priv,ou=dns,dc=priv objectClass: dlzHost objectClass: PerugiaObject PerugiaGroups: dns dlzHostName: pascarosa-pc0 PerugiaOwner: Simone Pascarosa cn: pascarosa-pc0 #Configurazione dellhost pascarosa-pc0.wired.priv dn: dlzRecordID=12,dlzHostName=pascarosa-pc0, dlzZoneName=wired.priv,ou=dns,dc=priv objectClass: dlzARecord objectClass: PerugiaObject PerugiaGroups: dns PerugiaOwner: Simone Pascarosa dlzHostName: pascarosa-pc0 dlzType: a dlzIPAddr: 10.2.0.12 dlzTTL: 10

88

dlzRecordID: 12 cn: pascarosa-pc0 # [...] #Configurazione della zona infnweb.priv dn: dlzHostName=tino,dlzZoneName=infnweb.priv,ou=dns,dc=priv PerugiaGroups: dns PerugiaOwner: Simone Pascarosa cn: privgw dlzHostName: tino objectClass: dlzHost objectClass: PerugiaObject #Host fittizio per il CNAME tino.infnweb.priv dn: dlzHostName=tino,dlzZoneName=infnweb.priv,ou=dns,dc=priv PerugiaGroups: dns PerugiaOwner: Simone Pascarosa cn: privgw dlzHostName: tino objectClass: dlzHost objectClass: PerugiaObject #Configurazione dellalias tino.infnweb.priv #per lhost privgw.infnweb.priv dn: dlzRecordID=66890,dlzHostName=tino, dlzZoneName=infnweb.priv,ou=dns,dc=priv dlzData: privgw dlzHostName: tino dlzRecordID: 66890 dlzTTL: 10 dlzType: CNAME objectClass: dlzCNameRecord Si noti lID del record, quello identicato dal campo dlzRecordID. Questo codice rappresenta la sequenza del record come se ci trovassimo allinterno di un le sequenziale: tale concetto stride con quello delle directory in cui si predilige la gerarchia rispetto alla sequenza. Ebbene DLZ concilia i due concetti creando una gerarchia come mostrato nella gura 4.12, mantenendo la sequenzialit` a con il campo ID. Per assegnare gli ID abbiamo usato parte dellindirizzo IP per ricavare un identicatore unico allinterno della zona: dato che le zone contengono indirizzi IP allinterno della classe 10.X.0.0/16, utilizziamo gli ultimi due byte dellindirizzo per calcolare lID. Siano a3 e a4 gli ultimi due byte dellindirizzo IP, allora ID = a3 256 + a4 Quindi ad esempio il record che riguarda lindirizzo IP 10.2.3.125 avr` a come ID = 3 256 + 125 = 839. Il record 1 di ogni zona ` e riservato al SOA. I record di CNAME che quindi non hanno associato direttamente un indirizzo IP, avranno come ID un numero maggiore di 65536, limite massimo degli ID per record A (quelli che associano un nome ad un indirizzo IP).

89

4.7

Congurazione delle macchine virtuali

Xen, come gi` a descritto nel paragrafo 3.6.1, ` e un monitor di macchine virtuali (o hypervisor) che realizza paravirtualizzazione su architetture x86. Permette di eseguire pi` u macchine virtuali sullo stesso sistema sico con performance molto buone. Ecco alcune delle caratteristiche che contraddistinguono Xen dagli altri monitor di macchine virtuali: performance molto simili a quelle dellaccesso diretto allhardware; migrazione live delle macchine virtuali a run-time tra host sici diversi; supporto no a 32 CPU virtuali per sistema ospite; supporto per le piattaforme x86 a 32 e 64 bit;

4.7.1

Installazione di Xen

Linstallazione di Xen su piattaforma Gentoo GNU/Linux 2007.0 ` e abbastanza lunga, soprattuto la fase di ricompilazione del kernel richiede spesso il riavvio del sistema se non si ha esperienza. Ecco in breve le fasi dellinstallazione: Compilazione dellhypervisor (Xen) Installazione delle patch di Xen per il kernel del dom0 Installazione degli strumenti di controllo (xm, xend ...) Compilazione del kernel del dom0 per Xen Congurazione del bootloader per avviare Xen (lhypervisor) che poi avvier` a il dom0 Preparazione del sistema Questa fase prepara il sistema alla compilazione dei sorgenti di Xen e delle librerie di sistema. Gentoo propone la ricompilazione di tutti i pacchetti che si vogliono installare, per personalizzare al massimo le caratteristiche di ogni applicazione. Questo comporta naturalmente una fase di tuning del proprio sistema e Xen ` e ancora pi` u specico sulle congurazioni da impostare per la sua installazione. Prima di tutto dobbiamo selezionare lultimo prolo di sistema disponibile per Portage, il sistema di pacchettizzazione e compilazione di Gentoo, tramite il comando: eselect profile list Questo ci garantisce che nel sistema siano presenti le versioni pi` u recenti della libreria C standard (glibc) con NPTL 25 . In seguito dobbiamo correggere un problema riguardante la libreria glibc: infatti la libreria TLS di glibc ` e implementata in un modo che va in conitto con il meccanismo con cui Xen usa i registri di segmento per superare un limite delle piattaforme x86 a 32 bit, che causa una perdita di performance su certe operazioni di Xen, stimabile intorno al 50% in meno su applicazioni multi-threaded. Naturalmente il problema non si presenta su architetture a 64 bit, sulle quali possiamo saltare questo passaggio. Per risolvere il problema dobbiamo aggiungere il ag di compilazione -mno-tlsdirect-seg-refs al sistema in /etc/make.conf tra i ag di compilazione C:
25 Native POSIX Thread Library (NPTL) ` e una componente software che abilita il kernel Linux a far girare in modo eciente programmi scritti usando la libreria per thread POSIX.

90

CFLAGS="-O2 -march=i686 -pipe -mno-tls-direct-seg-refs" CXXFLAGS="${CFLAGS}" CHOST="i686-pc-linux-gnu" GENTOO_MIRRORS="http://mirror.ing.unibo.it/gentoo/ ftp://mirror.ing.unibo.it/gentoo" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" MAKEOPTS="-j3" FEATURES="parallel-fetch ccache" USE="nptlonly screen ncurses" A questo punto sarebbe necessaria la ricompilazione di tutti i pacchetti di sistema per compilarli con il ag -mno-tls-direct-seg-refs; su Gentoo possiamo eseguire il comando: emerge -evat world

Compilazione Hypervisor e strumenti di gestione


In questa fase dobbiamo installare lhypervisor e le applicazioni di gestione delle macchine virtuali, con il comando: emerge -av app-emulation/xen app-emulation/xen-tools Lhypervisor consiste in un binario (/boot/xen.gz ) che verr` a avviato dal boot loader prima del kernel del dom0.

Compilazione del kernel del dom0


In questa fase dobbiamo scaricare un kernel per il dom0 con le patch necessarie per Xen; si pu` o installare il pacchetto relativo con il comando: emerge sys-kernel/xen-sources Installate queste patches vanno mantenute inalterate le opzioni del il kernel in funzione, ma devono essere aggiunte alcune caratteristiche che impostino, ad esempio, il funzionamento dei driver come backend driver. Le opzioni pi` u importanti da includere nel kernel, in modo statico e non come moduli, sono: Enable Xen compatible kernel: abilita il kernel alluso delle API Xen Privileged Guest (domain 0): dice al kernel di funzionare come dom0 Block-device backend driver: fa funzionare i driver dei dispositivi a blocchi come backend driver per i domU Network-device backend driver: come il precedente ma per i dispositivi di rete

Avvio del nuovo kernel


A questo punto va congurato il bootloader26 perch e faccia partire il sistema con il nuovo kernel del dom0. Il nostro sistema usa Grub come bootloader. Per farlo partire con il kernel appena creato basta aggiungere queste righe al le di congurazione /boot/grub/grub.conf :
26 il software che si occupa di inizializzare il sistema ed avviare il sistema operativo, dopo il BIOS

91

title root kernel module

Xen 3.0 / Linux 2.6.16.52 (hd0,0) /xen.gz dom0_mem=98M /vmlinuz-2.6.16.52-xen0 root=/dev/sda1

Il kernel che deve essere avviato non ` e quello appena creato, ma ` e lhypervisor di Xen che si sostituisce al kernel del dom0 nelle fasi di inizializzazione dellambiente per Xen. Lhypervisor proceder` a poi ad avviare il kernel del dom0 specicato nella direttiva module. Terminata questa fase, va soltanto riavviato il sistema.

4.7.2

Congurazione dei domU

Dopo il riavvio del sistema, bisogna entrare nel dom0 di Xen, dal quale si possono gestire tutte le macchine virtuali. Per creare una macchina virtuale bisogna: compilare il suo kernel preparare il lesystem congurare la macchina virtuale

Compilazione del kernel dei domU


I kernel dei domU devono contenere i frontend driver di Xen, visto che non interagiscono direttamente con lhardware. Si pu` o usare la stessa congurazione del dom0, cambiando solo le opzioni speciche di Xen e in particolare: Enable Xen compatible kernel: abilita il kernel alluso delle API Xen Block-device frontend driver: fa funzionare i driver dei dispositivi a blocchi come frontend driver, attraverso le API di Xen Network-device frontend driver: come il precedente ma per i dispositivi di rete

Preparazione del lesystem


Ora che abbiamo un kernel, va creata unimmagine per il lesystem del sistema operativo del domU. Fortunatamente esistono su Internet dei siti27 che mettono a disposizione dei le contenenti limmagine di un lesystem con installata una distribuzione GNU/Linux funzionante, nel nostro caso Debian GNU/Linux. Questo le verr` a usato come lesystem di riferimento per il domU che andiamo a creare.

Congurazione della macchina virtuale


La congurazione di un domU va scritta su un le che verr` a usato dal comando xm. Ecco il le di congurazione della macchina virtuale: kernel = "/boot/vmlinuz-2.6.16.52-xenU" memory = 128 name = "log" vif = [ bridge=xenbr0 ] disk = [phy:/dev/evms/log,sda1,w, file:/xen/debian.swap,sda2,w] root = "/dev/sda1 ro" La sintassi ` e molto comprensibile. Le opzioni da congurare sono: kernel: il percorso del kernel da usare per questo domU;
27 noi

abbiamo scelto http://jailtime.org/

92

memory: il quantitativo di memoria RAM da riservare per la macchina virtuale; name: il nome identicativo; vif: linterfaccia di rete da esportare al domU come eth0, in questo caso viene usato un bridge 28 ; disk: la specica dei lesystem esportati alla macchina virtual, nel formato percorso lesystem, nome lesystem nel domU, diritti di accesso; si noti che come percorso del lesystem si pu` o specicare una partizione disco reale, una partizione logica (come nel primo caso, con EVMS) o un le su disco (come nel secondo caso come partizione di swap); root: il lesystem da avviare come root lesystem per il domU (uno di quelli appena deniti). Terminata la congurazione della macchina virtuale, non resta che avviarla con il comando: xm create /xen/virtual1.conf -c Questo comando manda in esecuzione la macchina virtuale descritta nel le /xen/virtual1.conf, che contiene la congurazione riportata in precedenza. Lopzione -c attiva una console sulla macchina virtuale e permette di seguire le fasi di boot, di fare login e di eseguire comandi su di essa. A questo punto basta congurare linterfaccia di rete della nuova macchina ed installare il software necessario ai servizi che deve ospitare.

4.8

Congurazione router e rewall

Il router di frontiera costituisce uno dei punti pi` u critici della rete, perch e deve provvedere sia allo smistamento del traco della rete interna verso Internet (tramite due link separati del Dipartimento di Fisica e di INFN, come mostrato nella gura 1.1) che alla gestione dellautenticazione degli utenti delle reti wireless con il Captive Portal, nonch e al ltraggio dei pacchetti (rewalling ). Il router ` e stato messo in forte sicurezza per evitare intrusioni di malintenzionati che potrebbero manometterlo e compromettere di conseguenza tutto il funzionamento della rete. ` stato utilizzato un server con una sola interfaccia di rete sica, congurata per E avere una interfaccia di rete logica per ogni rete VLAN denita nella struttura. In questo modo si riesce a simulare un router professionale con diverse interfacce di rete. Il computer in questione ` e privgw.priv. La struttura logica dei collegamenti ` e mostrata in gura 4.13 (in verde sono rappresentate le reti di Fisica, in blu quelle di INFN). Per implementare le politiche di rewalling e di routing verranno usati rispettivamente iptables e iproute2. Allinterno della congurazione del rewall viene usato il supporto di iptables al tracciamento dei pacchetti appartenenti ad una stessa connessione: quando arriva il pacchetto iniziale di inizio di una nuova connessione (indicato dal ag NEW dellintestazione TCP) si decide se accettare o meno quel traco. Successivamente tutti i pacchetti relativi a quella connessione subiranno lo stesso destino del pacchetto iniziale; in sostanza, se il rewall decide di far passare il pacchetto iniziale di una connessione, tutto lo stream di dati appartenente a quella connessione viene fatto passare. Ecco la congurazione:
28 un ponte virtuale, che mette in comunicazione linterfaccia virtuale collegata al domU con linterfaccia di rete reale sul dom0

93

Figura 4.13: Router di frontiera con le reti servite

/sbin/iptables /sbin/iptables /sbin/iptables /sbin/iptables

-t -t -t -t

filter filter filter filter

-N -F -A -A

keep_state keep_state keep_state -m state --state INVALID -j DROP keep_state -m state --state ESTABLISHED,RELATED -j ACCEPT

Queste istruzioni deniscono una catena, keep state, che accetta i pacchetti relativi ad una connessione gi` a iniziata. In questo modo, nelle altre regole del rewall dovremo preoccuparci di far passare solo il pacchetto iniziale di una connessione.

Passaggio di traco tra le reti


Come detto pi` u volte, le reti VLAN della nostra struttura non hanno comunicazione diretta tra loro. Il router ha delle regole che impediscono il passaggio del traco tra reti diverse, ma accetta quello che deve transitare verso Internet. Il DHCP e il DNS sono implementati su questo stesso server: per questo motivo i nodi delle reti nascoste non hanno necessit` a di contattare altri computer per avere accesso alla rete. I server RADIUS ed LDAP, che devono essere trasparenti agli utenti, hanno uninterfaccia di rete sulla rete VLAN di controllo, quella con VLAN ID 1, alla quale non si pu` o associare nessun client. Questa rete permette agli amministratori di creare una sorta di limite invalicabile al quale nessun computer pu` o accedere: lunico nodo che ha il permesso di interrogare i servizi su questa rete, oltre alle postazioni degli amministratori, ` e proprio il router privgw.priv che implementa i metodi di autenticazione verso gli utenti e che legge dal server LDAP le congurazioni di DHCP e DNS. Allinterno di iptables quindi vanno specicate alcune regole: Accetta le connessioni DNS in ingresso: /sbin/iptables -t filter -A INPUT -p udp -m state \ --state NEW -d 10.0.0.254 --dport 53 -j ACCEPT Accetta le connessioni DHCP in ingresso: /sbin/iptables -t filter -A INPUT -p udp -m state \ --state NEW -s 10.0.0.0/8 --dport 67 -j ACCEPT /sbin/iptables -t filter -A INPUT -p udp -m state \ --state NEW -s 10.0.0.0/8 --dport 68 -j ACCEPT

94

In questa sezione non verr` a riportata la congurazione del rewall riguardante il Captive Portal, perch e questa ` e stata gi` a analizzata nel paragrafo 4.3.2.

Passaggio del traco verso Internet


Il traco verso Internet ha la caratteristica di avere come indirizzo IP di destinazione un indirizzo non appartente alla rete 10.0.0.0. Prima di tutto va aggiunta la catena keep state per il tracciamento delle connessioni alla tabella di forward di iptables, quella che riguarda i pacchetti in trasito nel computer, dicendo al rewall di far passare il traco in transito: /sbin/iptables -t filter -P FORWARD ACCEPT /sbin/iptables -t filter -F FORWARD /sbin/iptables -t filter -A FORWARD -j keep_state /sbin/iptables -A FORWARD -j LOG Lultima istruzione memorizza nel log la registrazione del traco in transito sulla rete.

Network Address Translation


Prima di far passare il traco dei nodi della rete nascosta su Internet, si deve provvedere a modicare il loro indirizzo IP: non si pu` o spedire sul Internet un pacchetto con un indirizzo come 10.2.32.4, perch e non si ricever` a risposta, visto che la classe 10.0.0.0 ` e riservata alle reti private. Per questo vanno tradotti gli indirizzi dei client con lindirizzo dellinterfaccia pubblica su Internet del router. In questo caso ci sono due interfacce di rete pubbliche su Internet e vanno specicate le traduzioni degli indirizzi per entrambe: /sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/8 \ -d ! 10.0.0.0/8 -o eth0 -j SNAT --to-source 141.250.2.11 /sbin/iptables -t nat -A POSTROUTING -s 10.0.0.0/8 \ -d ! 10.0.0.0/8 -o eth1 -j SNAT --to-source 193.205.222.52 Queste due regole ci dicono che a tutti i pacchetti che devono essere trasmessi dalla scheda di rete eth0, quella relativa alla rete del Dipartimento di Fisica, dovr` a essere modicato lindirizzo del mittente in 141.250.2.11; ai pacchetti che devono essere per la scheda eth1, quella sulla rete di INFN, dovr` a essere modicato lindirizzo del mittente in 193.205.222.52.

Iproute per smistare il traco


Grazie allo strumento iproute 29 , sempre incluso in GNU/Linux, si possono denire delle tabelle di routing per smistare il traco verso le due reti di Fisica e di INFN. Prima di tutto vanno denite le tabelle di routing: ip route add table ip route add table ip route add table weight 1 nexthop 3 default via 193.205.222.101 4 default via 141.250.2.3 5 default nexthop via 193.205.222.101 dev eth1 \ via 141.250.2.3 dev eth0 weight 1

29 una collezione di strumenti molto potenti per il controllo del traco delle reti TCP/IP per il kernel Linux

95

La tabella contraddistinta dal numero 3 riguarda la rete di INFN, che ha come router di default 193.205.222.101, mentre la tabella 4 riguarda la rete del Dipartimento di Fisica con router 141.250.2.3. La tabella 5 permette di bilanciare il carico tra le due reti e sommare quindi le velocit` a dei due link: in questo modo si potrebbe decidere di mandare alcuni ussi di traco su entrambi i link per massimizzare la velocit` a di comunicazione, evitando di intasare uno dei due collegamenti (questa funzione ` e stata prevista per eventualit` a future). Con queste tabelle, si pu` o decidere, per ogni rete nascosta denita nella struttura, verso quale delle due reti deve passare il traco per andare su Internet. ip ip ip ip ip ip ip ip ip ip rule rule rule rule rule rule rule rule rule rule add add add add add add add add add add from from from from from from from from from from 10.2.0.0/17 table 4 10.2.128.0/17 table 3 10.3.0.0/16 table 3 10.4.0.0/16 table 4 10.5.0.0/16 table 3 10.6.0.0/16 table 4 10.7.0.0/16 table 4 10.8.0.0/17 table 4 10.8.128.0/17 table 3 10.9.0.0/16 table 4

Questi comandi deniscono la tabella di routing da usare per ogni rete, il che denisce di conseguenza linterfaccia di rete dalla quale il pacchetto sar` a trasmesso verso Internet (si veda limmagine 4.13 per la struttura dei link).

4.9

Uso di interfacce grache per la gestione del sistema

La centralizzazione delle congurazioni sulla directory LDAP permette di interagire in modo veloce ed integrato con tutti i servizi critici della rete. La forza della struttura risiede principalmente nellintegrazione dei servizi e nelle relazioni che si riescono a stabilire allinterno della directory tra le varie entry. Per manipolare questa mole di dati, si ` e resa necessaria la ricerca di strumenti, anche graci, che permettessero di inserire, cancellare e modicare i dati relativi a tutti i servizi di rete.

phpLDAPadmin
La ricerca ` e approdata sul software phpLDAPadmin, uninterfaccia web scritta in linguaggio PHP30 che interagisce con il server LDAP. Linterfaccia di phpLDAPadmin facilita la manipolazione dei dati, grazie alla possibilit` a di visualizzare i dati in modo gerarchico e di poter modicare ogni singolo valore con delle schermate intuitive ed immediate. Il collegamento dellinterfaccia web alla directory LDAP ` e molto facile e richiede la semplice modica di un le di congurazione. Vediamo alcune schermate per spiegare il funzionamento dellinterfaccia. Nellimmagine 4.14 viene visualizzata linterfaccia del programma phpLDAPadmin allinterno del browser, dopo il login.
30 PHP Hypertext Preprocessor, un linguaggio di scripting per il web molto versatile, simile come sintassi al linguaggio Java

96

Figura 4.14: Schermata principale di phpLDAPadmin

Figura 4.15: Gerarchia di una directory LDAP con phpLDAPadmin

In dettaglio, nella gura 4.15 si vede la strutturazione della directory in sottoalberi: si possono riconoscere le sezioni relative al DNS, al DHCP, alle informazioni sui MAC address registrati (ou=radiusmac ) e via di seguito.

97

Figura 4.16: Denizione degli attributi di una entry con phpLDAPadmin

Nellimmagine 4.16 si vede come si pu` o modicare la homeDirectory dellutente o altre informazioni che lo riguardano semplicemente inserendo il nuovo valore allinterno dei campi della pagina HTML31 . Con questa interfaccia si possono quindi gestire tutte le entry della directory, creare nuovi sottoalberi e gestire i backup.

31 HyperText Markup Language, linguaggio di marcatura per ipertesti largamente usato nel World Wide Web

98

LDAPaccess
Per le necessit` a di integrazione dei dati presenti nella directory, abbiamo sviluppato un tool, chiamato LDAPaccess, che permette di creare al volo le congurazioni per un nuovo portatile o un nuovo desktop o per un nuovo account per la rete wireless. Con questa stessa interfaccia si pu` o anche avere immediatamente lelenco delle congurazioni relative ad un utente. LDAPaccess facilita le operazione quotidiane di gestione della rete. Alcune considerazioni sono necessarie per capire meglio le scelte fatte: terminata la fase di migrazione (che prevede uninserimento massiccia dei dati), laggiunta dei dati sulla directory LDAP non sar` a molto frequente (possiamo stimare di dover fare non pi` u di una decina di operazioni al giorno); per questo motivo non c` e bisogno di un meccanismo automatizzato che preveda, ad esempio, che gli utenti stessi sottomettano le modiche alla directory e poi lamministratore autorizzi quelle necessarie. Per questo motivo LDAPaccess permette di aggiungere facilmente un nuovo account o un nuovo portatile alla rete in pochi secondi, con uninterfaccia gradevole ed intuitiva. dallaltra parte non sarebbe stato pensabile modicare la directory direttamente con phpLDAPadmin, perch e, come gi` a spiegato, ogni nuova registrazione prevede la produzione di varie entry: si sarebbe impiegato troppo tempo a creare ogni volta tutte le entry necessarie e a riempire i vari campi a mano (con evidenti ricadute sul numero di errori e sul tempo impiegato per svolgere queste operazioni). LDAPaccess facilita la creazione di entry LDAP perch e conosce gi` a la struttura della rete e quindi riempe automaticamente i campi necessari: se dovessi inserire a mano le congurazioni per un nuovo portatile, dovrei creare almeno 3 entry diverse, con alcuni dati ripetuti. LDAPaccess richiede solo la compilazione di un form HTML e provvede a produrre le entry necessarie visto che ci sono 2 amministratori (uno per la rete del Dipartimento di Fisica e uno per la rete di INFN), la soluzione con interfaccia web permette di far accedere entrambi in modo facile ed immediato, senza dover acquistare costosi tool di amministrazione e di condivisione delle risorse Il programma LDAPaccess ` e scritto in linguaggio PHP ed ` e costituito da una serie di moduli che permettono la creazione di entry LDAP per la registrazione dei dati per DNS, DHCP, RADIUS ed altri servizi. Lidea alla base del programma ` e quella di fornire uno strumento veloce e essibile per laggiunta di dati alla directory LDAP. Naturalmente, se si devono eettuare delle modiche ai singoli attributi di una entry, conviene usare phpLDAPadmin che con la sua interfaccia molto intuitiva facilita le cose. Il programma serve soprattutto a mantenere lintegrit` a delle relazioni che si creano allinterno della directory, come quelle che riguardano il proprietario di un computer; cosa che in phpLDAPadmin non appare evidente. Limmagine 4.17 presenta la struttura del programma. La cartella principale del programma contiene due sottocartelle: conf che contiene i le di congurazione del programma (riportati in verde nellimmagine) e pics che contiene alcune immagini usate per linterfaccia graca. I le di congurazione permettono di specicare le relazioni tra gli attributi inseriti nelle form HTML del programma e gli attributi della directory LDAP. Gli altri le del programma possono essere divisi in 3 categorie: 1. le di interfaccia (riportati in rosso nellimmagine): pagine che vengono richiamate direttamente dallamministratore e che forniscono uninterfaccia graca per linserimento, la modica e la visualizzazione dei dati;

99

Figura 4.17: Strutturazione dei le del programma LDAPaccess

2. le di libreria (riportati in blu nellimmagine): moduli PHP che forniscono le funzioni di basso livello per laccesso ai dati contenuti nella directory (in particolare il le read conf.php realizza il vero e proprio collegamento alla directory e la creazione degli oggetti necessari per la lettura dei dati); 3. le di stile: il solo le general.css che denisce lo stile graco di formattazione delle pagine HTML con il linguaggio CSS32

Utilizzo di LDAPaccess
Come si vede nella gura 4.18, si possono creare tutte le congurazioni necessarie per la registrazione di un portatile inserendo i valori di alcuni attributi, come il nome del proprietario, lindirizzo MAC della scheda di rete e lindirizzo IP da assegnare al portatile, presenti nella tabella di sinistra che riporta lultimo indirizzo disponibile per ogni rete. Si pu` o scegliere la rete a cui verr` a collegato il computer tramite il men` ua tendina Sottorete. Terminato linserimento dei valori, viene fornito il risultato delle entry LDAP necessarie per la registrazione di questi dati: le entry sono specicate in formato LDIF. Loutput ` e quindi una pagina HTML (come mostrata nella gura 4.19) contenente il le LDIF che va inserito nella directory. Questo passaggio dalloutput in formato LDIF permette di dare un ultimo controllo ai dati che andranno inseriti nella directory, per evitare di fare errori. Il contenuto quindi pu` o essere copiato ed importato allinterno della directory LDAP.
32 Cascading StyleSheet, linguaggio per la descrizione della presentazione di un documento scritto in un linguaggio di marcatura come lHTML

100

Figura 4.18: Aggiunta di un nuovo computer portatile con LDAPaccess

Figura 4.19: LDIF per la registrazione di un nuovo computer portatile

Linterfaccia permette di cercare il proprietario di un computer, ad esempio inserendo il MAC address di un suo portatile. Si pu` o inoltre visualizzare il dettaglio di tutti i dispositivi posseduti da un utente con i dati pi` u importanti selezionando lutente da un men` u a tendina o ricercandolo allinterno della directory: il risultato che si ottiene ` e visualizzato in gura 4.20.

101

Figura 4.20: Dettaglio dei computer posseduti da un utente con LDAPAccess

102

Capitolo 5

Migrazione
La migrazione ` e una fase molto delicata per il completamento dellinstallazione della nuova struttura di rete del dipartimento. Sebbene si possa riuscire a non inuenzare le funzionalit` a delle postazioni degli utenti quando si lavora sulla struttura di dorsale e sui servizi che entreranno in funzione, non si pu` o evitare di farlo quando vanno registrati i dati delle postazioni sulla nuova struttura ed avvertiti gli utenti della migrazione. Fasi della migrazione: operazioni preliminari registrazione dei nuovi account migrazione degli account della rete wireless migrazione degli account della rete cablata

Operazioni preliminari
Prima di iniziare la migrazione sono stati preparati tutti i dispositivi di infrastruttura (switch ed access point) per la nuova rete. Si ` e preferito installare una rete separata, con dispositivi propri, per mantenere la vecchia struttura no al complementamento dellinstallazione: in questo modo si possono migrare gradualmente gli utenti sulla ` da ricordare che il dipartimento ospita pi` nuova rete. E u di 200 persone, aerenti a diversi enti. Si deve tenere in considerazione che spesso i dipendenti si trovano a lavorare fuori dalledicio (spesso allestero) e quindi le comunicazioni riguardanti la migrazione hanno un ritardo di risposta molto alto.

Registrazione dei nuovi account


La politica per la registrazione dei nuovi account prevede di registrare tutte le nuove utenze, sia wireless che cablate, direttamente sulla nuova rete. Chi oggi, ad esempio, registra il proprio portatile per la rete wireless, viene inserito direttamente nella nuova struttura. In questo modo, anche il naturale ricambio dei computer e dei portatili aiuta, con la dismissione dei vecchi, nella migrazione

Migrazione degli account della rete wireless


Il primo passo per leettiva migrazione delle utenze ha riguardato il passaggio dei portatili in rete wireless. La migrazione, ancora in fase di completamento, prevede che lamministratore di sistema mandi una comunicazione, preferibilmente per email, allinteressato, specicando i portatili in rete wireless che risultano registrati al momento e che verranno passati nella nuova rete. Con questa comunicazione si riescono

103

ad individuare, dalle risposte degli utenti, anche tutti i portatili che sono registrati ma che non vengono pi` u utilizzati o che sono stati dismessi. Si ` e scelto di eettuare la migrazione degli utenti wireless per piani. I primi a passare sotto la nuova rete sono stati quelli del secondo piano (dove si trovano le sale dei dottorandi o dei ricercatori). Successivamente si ` e partiti dallultimo piano, a scendere. In media si pu` o calcolare che per migrare tutti gli account della rete wireless di un piano delledico c` e bisogno di circa 2 settimane di tempo: questa attesa ` e giusticata dal fatto che si deve aspettare la conferma degli utenti della loro connessione alla nuova rete e per sapere se ci sono stati problemi (ad esempio di ricezione del segnale). La semplice registrazione dei dati dei portatili di un piano richiede di per s e alcuni minuti.

Migrazione degli account della rete cablata


La migrazione degli account della rete cablata verr` a eettuato nei prossimi mesi. Alcuni uci sono stati gi` a migrati alla nuova struttura e sono serviti da test per provare lecacia della rete ed eventuali problemi non previsti in fase di progettazione. I primi che sono stati passati sotto rete nascosta sono stati gli utenti dellocina meccanica del dipartimento (che ospita sia dipendenti del Dipartimento di Fisica, che dellINFN). Qui abbiamo uno switch congurato per la nuova rete, quindi con le VLAN. Quello che va fatto per congurare una postazione ssa ` e conoscere la porta dello switch alla quale ` e collegata e congurare la VLAN relativa su quella porta. Prima della migrazione sono state fatte delle riunioni con i responsabili di tutti i gruppi di ricerca e dei vari servizi ospitati nelledicio per far conoscere la nuova infrastruttura e per permettere di sollevare dubbi e richieste. In queste riunione sono state decise anche le procedure necessarie alla richiesta di un accesso diretto alla rete pubblica solo per i servizi indispensabili. Il problema principale, riscontrato in queste riunioni, ` e labitudine degli utenti del dipartimento ad avere un indirizzo di rete pubblico su Intenrnet; questo ha portato lutente ad abituarsi a poter accedere al computer del proprio ucio da qualunque postazione connessa ad Internet. Come si ` e visto, la nuova rete impedisce questo accesso diretto perch e i computer sono su rete privata. In futuro si prevede di individuare ed installare dei sistemi di accesso remoto che permettano di accedere alla propria postazione ducio da Internet, previa autenticazione.

104

Capitolo 6

Conclusioni
Questa tesi ha esposto, sinteticamente, il lavoro svolto durante questanno. Sicuramente la parte pi` u impegnativa ` e stata lo studio delle varie tecnologie necessarie: alcune di queste facevano gi` a parte del mio bagaglio culturale universitario, ma molte altre le ho dovute studiare ex-novo, con non poche dicolt` a. Oltre allo studio, anche la congurazione e limplementazione dei servizi ha richiesto molto impegno, vista la scarsa documentazione disponibile per alcuni strumenti. Per centralizzare i servizi su LDAP ` e stato necessario uno sforzo non indierente: la fase di test ha preso un tempo considerevole sempre per la mancanza di documentazione. Finalmente adesso il Dipartimento di Fisica e lINFN hanno unarchitettura di rete essibile ed unica. Flessibile perch e, come si ` e visto, si possono creare nuove reti e nuove servizi senza troppe dicolta, aiutati anche da una struttura di autenticazione integrata. Unica perch e non ci sono pi` u due reti indipendenti, ma ununica infrastruttura condivisa che pu` o essere partizionata arbitrariamente per rispondere alle necessit` a degli enti. Questa essibilit` a garantir` a una lunga esistenza allinfrastruttura nel futuro. Se in futuro si creeranno nuovi laboratori o si vorranno allargare quelli gi` a esistenti, magari spostandoli su piani diversi delledicio, linfrastruttura potr` a accogliere queste novit` a con modiche minime alle congurazioni odierne. La centralizzazione delle congurazioni d` a la libert` a di creare copie multiple di un server molto facilmente; questo permetter` a sempre pi` u linnalzamento dei livelli di disponibilit` a dei servizi. Linfrastruttura di autenticazione, sempre basata sul servizio LDAP, faciliter` a il deployment di nuovi servizi e nuove tecnologie. Gi` a oggi si potrebbe pensare di integrare lautenticazione con i servizi di segreteria sia del dipartimento che dellINFN, per mantenere sempre aggiornati i dati sul personale. In conclusione si pu` o dire che la nuova rete costituisce una soluzione tecnologica integrata, moderna e pronta per accogliere le tecnologie del futuro.

105

106

Ringraziamenti
Voglio ringraziare il prof. Leonello Servoli per lopportunit` a che mi ha dato di partecipare a questo progetto e per aver creduto in me. Un profondissimo ringraziamento va a Mirko Mariotti che mi ha guidato nella realizzazione del progetto e col quale ho condiviso molto del mio tempo negli ultimi mesi... grazie. Ringrazio anche Fabrizio Gentile per avermi accolto a lavorare con lui. Questi anni di universit` a mi hanno fatto crescere molto; ringrazio tutti coloro che ho conosciuto e con i quali ho condiviso questesperienza forte, soprattutto a Davide che mi ha sempre sostenuto e nel quale ho trovato un vero amico. Un ringraziamento va a tutti i miei amici, che hanno sempre creduto in me, e ai quali non posso che augurare una vita splendida. Voglio concludere ringraziando il Signore per tutte le cose belle che ha messo nella mia vita, per la mia famiglia, per la Chiesa, per le persone che incontro ogni giorno e per il suo insegnamento, ricordando uno dei brani pi` u belli della Bibbia: Vi esorto dunque, fratelli, per la misericordia di Dio, ad orire i vostri corpi come sacricio vivente, santo e gradito a Dio; ` e questo il vostro culto spirituale. Non conformatevi alla mentalit` a di questo secolo, ma trasformatevi rinnovando la vostra mente, per poter discernere la volont` a di Dio, ci` o che ` e buono, a lui gradito e perfetto Romani 12, 1-2

107

108

Bibliograa
[1] Sito uciale di INFN: http://www.infn.it [2] IEEE Std 802.1Q-1998, IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks, pubblicato l8/12/1998, pagina 14 e 15 [3] Riccardo Veraldi, TRIP - Implementazione Tecnica, del 8/5/2006, sul sito: http://security..infn.it/TRIP/TRIP.pdf [4] da Wikipedia - The Free Encyclopedia, http://en.wikipedia.org/wiki/AAA protocol AAA protocol, dal sito:

[5] The Internet Society - Network Working Group, C. Rigney et al., Request For Comment n. 2865, Giugno 2000 [6] Sito Uciale di FreeRADIUS: http://www.freeradius.org/ [7] da Wikipedia - The Free Encyclopedia, Lightweight Directory Access Protocol, dal sito: http://en.wikipedia.org/wiki/Lightweight Directory Access Protocol [8] The Internet Society - Network Working Group, K. Zeilenga e OpenLDAP Foundation, Request For Comment n. 4510, Giugno 2006 [9] Sito Uciale di Bind DLZ: http://bind-dlz.sourceforge.net/

109