- Mirko Mariotti

Università degli Studi di Perugia
Facoltà 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
2
Indice
1 Introduzione
7
1.1 Enti coinvolti nel progetto . . . . . . . . . . . . . . . . . . . . . .
7
1.1.1 Dipartimento di Fisica dell’Università di Perugia . . . . .
7
1.1.2 Sezione di Perugia dell’Istituto 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à, estensioni, aggiornamenti e modifiche
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
14
15
18
19
3 Tecnologie
3.1 Virtual LAN . . . . . . . . . . . . . . . . . . . .
3.1.1 Storia . . . . . . . . . . . . . . . . . . . .
3.1.2 Funzionamento e terminologia . . . . . . .
3.1.3 Configurazione 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 Certificati digitali X.509: sicurezza garantita . .
3.4.1 Crittografia . . . . . . . . . . . . . . . . .
3.4.2 Public Key Infrastructure . . . . . . . . .
3.4.3 Certificato digitale . . . . . . . . . . . . .
3.4.4 Il formato X.509 per certificati digitali . .
3.5 Directory service con LDAP . . . . . . . . . . . .
3.5.1 Storia . . . . . . . . . . . . . . . . . . . .
3.5.2 Perché 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 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
3.6
3.5.6 Server LDAP slave . . . . . . . . . . . .
3.5.7 La nostra directory . . . . . . . . . . . .
Virtualizzazione per alta affidabilità . . . . . .
3.6.1 Virtualizzazione di piattaforma con Xen
3.6.2 EVMS: virtualizzazione dei dischi . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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 Configurazione VLAN con SSID multipli su AP
4.3 Implementazione del progetto TRIP . . . . . . . . . .
4.3.1 Configurazione Access point per 802.1x . . . .
4.3.2 Configurazione Captive portal . . . . . . . . . .
4.3.3 Configurazioni RADIUS . . . . . . . . . . . . .
4.4 Configurazione directory LDAP . . . . . . . . . . . . .
4.4.1 Configurazione servizio slapd . . . . . . . . . .
4.4.2 Inserimento entry per lo startup . . . . . . . .
4.5 Configurazione repliche LDAP . . . . . . . . . . . . .
4.6 Configurazione DNS e DHCP . . . . . . . . . . . . . .
4.6.1 Configurazione DHCP . . . . . . . . . . . . . .
4.6.2 Configurazione DNS . . . . . . . . . . . . . . .
4.7 Configurazione delle macchine virtuali . . . . . . . . .
4.7.1 Installazione di Xen . . . . . . . . . . . . . . .
4.7.2 Configurazione dei domU . . . . . . . . . . . .
4.8 Configurazione router e firewall . . . . . . . . . . . . .
4.9 Uso di interfacce grafiche per la gestione del sistema .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
54
55
55
58
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
wireless
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
60
60
60
60
62
64
66
66
67
72
76
76
80
80
81
82
84
90
90
92
93
96
5 Migrazione
103
6 Conclusioni
105
4
Elenco delle figure
1.1
Schema della rete del Dipartimento di Fisica/INFN . . . . . . . .
9
2.1
2.2
Modello di rete privata . . . . . . . . . . . . . . . . . . . . . . . .
Associazione di un server ad una o più reti VLAN . . . . . . . .
16
18
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
Trama Ethernet con IEEE 802.1q . . . . . . . . . . . . . . . .
Esempio di comunicazione in modalità Tagged . . . . . . . .
Esempio di comunicazione in modalità Untagged . . . . . . .
Interfacce virtuali per l’uso delle VLAN . . . . . . . . . . . .
Meccanismo di proxying del server RADIUS . . . . . . . . . .
Schema di una sessione di autenticazione 802.1x . . . . . . . .
Schema dell’autenticazione 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 semplificato dell’architettura di XEN . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
24
24
25
28
29
32
37
38
41
42
43
52
52
54
57
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
Schermata di aggiunta di una VLAN sullo switch 3Com 3300
Aggiunta di porte in modalità Tagged ad una VLAN . . . . .
Definizione della VLAN Untagged per una porta dello switch
Esempio di separazione dei domini VLAN . . . . . . . . . . .
Configurazione delle VLAN sugli Access Point Cisco . . . . .
Configurazione degli SSID sugli Access Point Cisco . . . . . .
Configurazione dell’autenticazione sugli Access Point Cisco .
Dettaglio della configurazione dei metodi di cifratura . . . . .
Meccanismo di replica in LDAP . . . . . . . . . . . . . . . . .
Gerarchia delle configurazioni del DHCP su LDAP . . . . . .
Domini della rete privata . . . . . . . . . . . . . . . . . . . .
Gerarchia delle configurazioni del DNS su LDAP . . . . . . .
Router di frontiera con le reti servite . . . . . . . . . . . . . .
Schermata principale di phpLDAPadmin . . . . . . . . . . . .
Gerarchia di una directory LDAP con phpLDAPadmin . . . .
Definizione degli attributi di una entry con phpLDAPadmin .
Strutturazione dei file del programma LDAPaccess . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 62
. 63
. 63
. 64
. 64
. 65
. 67
. 67
. 80
. 83
. 85
. 87
. 94
. 97
. 97
. 98
. 100
5
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
6
Capitolo 1
Introduzione
Questa tesi presenta il lavoro svolto dal candidato presso il Dipartimento di
Fisica dell’Università di Perugia, in collaborazione con l’Istituto Nazionale di
Fisica Nucleare, per la realizzazione del nuovo impianto di rete cablata e wireless
dell’edificio che ospita i due enti. Il lavoro è stato svolto principalmente nel
periodo da Marzo a Settembre 2007.
Perché realizzare questo tipo di rete
La realizzazione di una rete come descritta da questa tesi risponde ad alcune
necessità specifiche degli enti che la utilizzeranno, ma può benissimo rispondere
alle necessità di altre realtà simili.
In particolare deve prevedere la possibilità di condividere gli apparati di rete
tra gli enti in gioco, ma nel contempo dare la possibilità di creare reti separate.
1.1
1.1.1
Enti coinvolti nel progetto
Dipartimento di Fisica dell’Università di Perugia
Il Dipartimento di Fisica dell’Università di Perugia nasce il 30 ottobre 1982.
Ad oggi conta 31 professori, tra ordinari ed associati, ed 11 ricercatori.
Inoltre all’interno del dipartimento lavorano 24 dottorandi.
Il dipartimento opera in stretta collaborazione con l’Istituto Nazionale di
Fisica Nucleare, con l’Istituto 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 è coinvolto il personale sono l’astrofisica,
la fisica della materia, la fisica sperimentale delle particelle e astroparticelle e la
fisica teorica.
Il dipartimento di Fisica si inserisce nella Facoltà di Scienze Matematiche
Fisiche e Naturali dell’Università degli Studi di Perugia, che fu una tra le prime
libere università sorte in Italia, eretta a Studium Generale l’8 settembre 1308.
Ad oggi l’Università degli Studi di Perugia è suddivisa in 11 facoltà, con
circa 34.000 iscritti in totale, provenienti da tutta Italia.
7
1.1.2
Sezione di Perugia dell’Istituto Nazionale di Fisica
Nucleare
L’INFN è l’ente dedicato allo studio dei costituenti fondamentali della materia e svolge attività di ricerca, teorica e sperimentale, nei campi della fisica
subnucleare, nucleare e astroparticellare1 .
La ricerca fondamentale in questi settori richiede l’uso di tecnologie e strumenti di ricerca d’avanguardia, che l’INFN sviluppa nei propri laboratori e in
collaborazione con il mondo dell’industria.
L’Istituto promuove inoltre il trasferimento delle competenze, delle metodologie e delle tecniche strumentali sviluppate nell’ambito della propria attività verso
campi di ricerca diversi quali la medicina, i beni culturali e l’ambiente. Tutte
queste attività si svolgono in stretta collaborazione con il mondo universitario.
L’INFN venne istituito l’8 Agosto 1951 da gruppi delle Università di Roma,
Padova, Torino e Milano, al fine di proseguire e sviluppare la tradizione scientifica iniziata negli anni ’30 con le ricerche teoriche e sperimentali di fisica nucleare
di Enrico Fermi e della sua scuola.
L’attività dell’INFN 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 l’Istituto e le Università. I
quattro Laboratori, con sede a Catania, Frascati, Legnaro e Gran Sasso, ospitano grandi apparecchiature e infrastrutture messe a disposizione della comunità
scientifica nazionale ed internazionale.
Il personale dell’INFN conta circa 2000 dipendenti propri e quasi 2000 dipendenti universitari coinvolti nelle attività dell’Istituto e 1300 giovani tra laureandi, borsisti e dottorandi. Si chiamano associati coloro che definiscono una
collaborazione con l’ente 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 all’interno dell’edificio, anche se possono parlarsi
attraverso un gateway che le mette in comunicazione; per il resto le due reti
sono fisicamente separate, cioè ognuna ha i propri switch, i propri cavi e i propri
server.
Vediamo schematicamente la rete odierna dell’edificio del Dipartimento di
Fisica nella figura 1.1.
In verde è 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 edificio
Questa struttura porta ad avere, ad ogni piano dell’edificio, armadi con 2 o 3
switch, anche non completamente utilizzati, vista la necessità 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
1 queste
informazioni sono prese dal sito ufficiale di INFN[1]
resto della tesi verrà usato il nome Fisica, intendendo il Dipartimento di Fisica
dell’Università di Perugia
2 nel
8
Figura 1.1: Schema della rete del Dipartimento di Fisica/INFN
attaccare un certo cavo (nel periodo di stage ho imparato l’importanza 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 configurazioni necessarie.
9
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,
flessibile e condivisa tra i due enti che risiedono nell’edificio cioè il Dipartimento
di Fisica e la sezione di Perugia dell’Istituto Nazionale di Fisica Nucleare.
La rete dovrà permettere la navigazione dei computer su Internet, l’utilizzo
delle risorse interne, quali stampanti, server di posta, griglia di calcolo e degli
altri servizi fondamentali. Le necessità 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à realizzata con la tecnologia IEEE2 802.1q
detta anche VLAN, Virtual LAN.
Si prevede anche di creare un sistema di gestione centralizzata delle configurazione 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 configurazione, autenticazione
ed autorizzazione per i servizi. La gestione sarà implementata con un directory
server usando il protocollo LDAP. Per aumentare l’affidabilità e la disponibilità
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, configurazione e
controllo delle reti che sia il più possibile facile, flessibile, sicuro, affidabile 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à tra
1 nel resto della tesi il termine dominio verrà 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 flessibilità e l’aggiunta di nuovi dispositivi alla rete.
Facilità di configurazione di molti server con la centralizzazione
Ciascun servizio di rete, come l’assegnazione degli indirizzi IP (DHCP), le stampanti condivise, la risoluzione dei nomi a dominio (DNS), il controllo degli accessi, ha necessità di configurazione diverse: per ciascuno di questi, esistono
altrettanti software che li implementano e ciascuno di essi ha una propria configurazione. Per ogni configurazione, nello specifico per ogni file di configurazione,
esistono altrettante regole di sintassi, comandi e parole chiave da imparare, che
sovente obbligano l’amministratore a noiose ricerche su manuali e guide di riferimento. L’idea di questo progetto è quella di centralizzare tutte le configurazioni
dei servizi principali, nel nostro caso DHCP, DNS, autenticazione e PROXY,
in un unico servizio informativo che sia di facile accesso ed abbia un’interfaccia
standard al fine di poter creare applicazioni personalizzate per svolgere certi
compiti.
Questo servizio informativo sarà critico per tutta la struttura di rete, poichè
ciascun server andrà a leggere la sua configurazione facendo delle interrogazioni
su di esso; possiamo perciò immaginare la sua criticità sia in termini di sicurezza
che di affidabilità.
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à; non essendoci più file di configurazione lunghissimi, l’unica informazione da scrivere nel server sarà quella che lo indirizza al servizio
informativo.
Economia nell’acquisto degli apparati di rete con la separazione dei
domini
Un punto a favore di questa struttura è il lato economico. Come già accennato nei paragrafi 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
c’era necessità 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ò bilanciare
il numero dei PC tra gli switch già 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 ufficio ha bisogno di accedere sia alla
rete INFN che a quella del Dipartimento di Fisica non deve avere più due cavi
che portano ad altrettanti switch, ma su un singolo cavo può far coesistere comunicazioni per l’una e per l’altra rete, semplicemente configurando la propria
postazione in modo opportuno.
Economia nell’acquisto dei server tramite virtualizzazione
La virtualizzazione è ormai una realtà 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é a ciascun server virtuale corrisponde una macchina reale
sulla quale viene eseguito, ma ciascuna macchina reale può eseguire più server
virtuali con la virtualizzazione dei sistemi operativi.
Con questo sistema possiamo far eseguire anche diversi server virtuali su
un’unica macchina reale. La configurazione migliore che sembra garantire buone
prestazioni è quella che prevede di far girare 4 server virtuali (o macchine virtuali) su una sola macchina fisica. In questo modo ci siamo risparmiati l’acquisto
di 3 server... un bel risultato!
Altro vantaggio dell’uso delle macchine virtuali è 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 filesystem 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 l’interfaccia 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 nell’acquisto di software
Altro fattore, che incide pesantemente sul risparmio che questa struttura di rete
porta, è 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. L’uso di software libero, oltre ad abbattere,
nella maggior parte dei casi, i costi di acquisto, aumenta la configurabilità,
l’adesione agli standard dei software rilasciati sotto licenze libere e facilita la
personalizzazione del software.
Il software libero, checché ne dicano i suoi detrattori, ha raggiunto un livello
di stabilità, 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 l’autenticazione), abbiamo preferito usare sempre software libero.
Flessibilità nella definizione di nuove reti private
Un elemento non secondario, conseguenza dell’utilizzo della tecnologia VLAN
per la separazione delle reti, è la flessibilità nella creazione delle reti (il termine
rete, in questo contesto, denota un dominio di collisione Ethernet, cioè 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à 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à di acquisto di nuovi switch o di cablaggi ulteriori, che si renderebbero
3 inteso
come quel software che permette la libertà di eseguire il programma per qualunque
scopo, di studiarlo e modificarlo, di copiarlo e distribuirlo e di migliorarlo e rilasciare i propri
miglioramenti a tutti perché tutti ne traggano beneficio
4 International Standard Organization/Open System Infrastructure, modello di riferimento
per le reti informatiche composto da una pila a 7 livelli
13
necessari visto che la rete dovrebbe essere separata fisicamente dalle altre. La
separazione fisica è realizzata con i VLAN ID.
Il compito delle VLAN è quello di creare reti logiche indipendenti su una
stessa rete fisica; al contrario delle sottoreti che tendono a creare gerarchie di
reti.
Criticità, svantaggi e rischi
Le criticità introdotte da questa struttura sono diverse.
Prima di tutto la coesistenza di due reti, afferenti a due enti diversi, sulle
stesse apparecchiature, porta la necessità di condividere la responsabilità tra
i gestori delle due reti; inoltre, l’errore di uno degli amministratori, anche se
riguarda una configurazione della propria rete, potrebbe provocare un down
della rete dell’altro ente, con evidenti conseguenze sulla disponibilità di quella rete. Gli apparati, quali switch, cavi e router, diventano critici perché 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 configurazioni (oltre agli evidenti vantaggi già enunciati) comporta alcuni svantaggi: anche per le configurazioni dei servizi la responsabilità 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 configurazioni (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à
una maggiore disponibilità 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ù critiche dal punto di vista della sicurezza; le politiche dovranno
essere adeguate, sia per quanto riguarda il controllo degli accessi, che consentirà l’accesso solo agli amministratori, sia per quanto riguarda il traffico in
entrata e in uscita, permesso solo alle macchine che devono leggere le proprie
configurazioni.
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à 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 definire l’associazione di
ciascuna porta dello switch ad un dominio. Saranno necessari degli switch Managed cioè ai quali possa essere assegnato un indirizzo IP per la gestione di queste
configurazioni.
Anche gli Access Point Wireless devono supportare la tecnologia 802.1q e devono
poter annunciare più di una rete wireless5 .
5 per rete wireless si intende un SSID che identifica 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 fino a 1Gbit/sec). I dispositivi
già 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ò 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 l’hard disk dovrà avere una capacità tale da contenere tutti i filesystem delle
macchine virtuali ed il filesystem del sistema di monitoraggio di queste.
Per quanto riguarda i dispositivi di rete c’è bisogno che le interfacce di
rete delle macchine reali possano comunicare a velocità sostenuta, di almeno
100Mbit/sec, meglio se 1Gbit/sec, visto che una stessa interfaccia potrebbe
essere utilizzata da più macchine virtuali.
Il controllo sull’autenticazione dei portatili sulla rete wireless verrà fatto
tramite server RADIUS8 , quindi gli access point devono supportare questa
modalità. 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 specifico quello delle distribuzioni
Gentoo e Debian, supportano questa tecnologia. Nei computer degli utenti della
rete, non c’è necessità di alcun supporto delle VLAN, a meno che questi non
debbano, per particolari necessità, avere interfacce di rete su più di una rete.
Quindi dal lato utente non c’è bisogno di alcuna modifica o upgrade del software.
2.3
La rete nascosta
Una delle novità più evidenti della nuova rete è il fatto che gli indirizzi di rete
pubblici, sia del dipartimento di Fisica, che dell’INFN, non vengono più dati ai
singoli utenti su singole postazioni, ma vengono riservati solo ai servizi di rete
(che con l’adozione di nuove tecnologie aumentano). Per indirizzo IP 9 pubblico
si intende un indirizzo registrato presso un ISP10 che può essere contattato
direttamente da qualsiasi host su Internet.
La rete nascosta (o rete privata) è una struttura che permette di realizzare
proprio questa separazione tra il dominio locale della rete ed Internet, come
mostrato in figura 2.1.
Fino ad oggi, quindi, i computer della rete del Dipartimento erano accedibili
da qualunque computer connesso ad Internet: questo per varie necessità, 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à ai computer della rete
6 Unshielded
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
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ò contattare direttamente un computer
interno. Analizziamo più attentamente i vantaggi/svantaggi di questa soluzione.
Vantaggi:
• i computer della rete Interna sono più protetti dagli attacchi esterni perché
non sono direttamente raggiungibili dalla rete di Internet;
• vengono risparmiati indirizzi IP pubblici;
• è facilitato il controllo degli accessi, il tracciamento delle connessioni e la
registrazione dell’utilizzo della rete;
• abbiamo a disposizione molti più indirizzi, visto che possiamo scegliere arbitrariamente la classe di indirizzi IP da usare e quindi la dimensione massima della nostra rete, perciò allarghiamo il limite dei servizi che possiamo
offrire.
Svantaggi:
• i computer della rete interna non sono contattabili direttamente da Internet, anche se si possono definire delle associazioni sul router di frontiera
della rete per renderli visibili;
• l’installazione e la configurazione sono più complicate rispetto alla vecchia
struttura.
Impatto sugli utenti
Uno dei requisiti della migrazione è quello di diminuire il più possibile l’impatto
sugli utenti della modifica. Effettivamente, chi utilizza un computer fisso non
dovrà effettuare alcuna modifica, visto che sia in passato, che nella nuova rete,
viene utilizzato un server DHCP11 che distribuisce le configurazioni di accesso
11 Dynamic
Host Configuration Protocol, protocollo per la configurazione degli host su rete
16
alla rete ai computer. Quindi per l’utente finale non ci sarà alcuna modifica,
tranne il fatto che non si potrà più accedere direttamente al proprio computer
da Internet, con le caratteristiche appena evidenziate.
Per gli utenti che si collegano con un portatile l’unica modifica da fare sarà
il nome della rete wireless (l’ESSID 12 ) e, per gli ospiti, l’inserimento di nome
utente/password sulla schermata di autenticazione.
VLAN per rappresentare l’afferenza delle reti
Con rete nascosta intendiamo tutto l’insieme delle reti, nascoste appunto, che
vengono realizzate nell’edificio. 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ò 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ù bisogno di uno switch per ogni ente ad ogni
piano. Gli switch che useremo dovranno essere più intelligenti della semplice
commutazione: infatti devono poter controllare il codice della VLAN (TAG) al
quale il pacchetto appartiene ed eventualmente modificare tale codice.
Ciascuna rete singola rappresenta una rete a se stante a livello IP; cioè
le varie VLAN si comportano come se fossero varie reti separate (come d’altronde succedeva nella vecchia struttura del dipartimento), ma che condividono
le stesse attrezzature hardware e software per funzionare. L’amministratore,
configurando gli switch e impostando le politiche più appropriate, può spostare
un computer da una VLAN ad un’altra in modo trasparente. Questo grazie
al meccanismo del VLAN Tagging delle porte, che verrà spiegato nel paragrafo
3.1.2.
Grazie alle VLAN creiamo delle reti separate inserendo dei codici nel traffico,
che permettono di associare un pacchetto o una porta di uno switch ad una certa
rete.
Il meccanismo è flessibile, infatti possiamo associare un computer ad una o
più reti VLAN diverse, senza modificare le funzionalità di rete già esistenti e
con un overhead relativamente basso.
La complessità naturalmente si sposta sullo switch che deve essere configurato 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 diversificandoli secondo la propria tipologia.
Nello specifico 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 l’autenticazione14 . Questi
servizi sono condivisi tra tutte le reti create, perché indispensabili per l’accesso
alla rete e ad Internet. Esistono anche delle risorse che sono condivise solo da
alcune reti, come ad esempio le stampanti. La flessibilità della rete permette
di creare servizi che rispondano ad una o più reti. Infatti basta associare lo
specifico server alle VLAN alle quali è interessato, registrarlo opportunamente
sul DNS ed il gioco è fatto.
Figura 2.2: Associazione di un server ad una o più reti VLAN
Come mostra la figura 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 nell’immagine) per realizzare il collegamento.
La configurazione di questi servizi è stata centralizzata in un directory server
che garantisce:
• omogeneità delle configurazioni, che non sono distribuite su vari file e
server, ma controllate da un unico servizio;
• robustezza dei dati ed affidabilità, infatti se un server andasse in crash,
potremmo tirare su una sua copia e leggere le configurazioni dal directory
server, che consideriamo affidabile15 ;
13 Domain
Name Service, servizio di risoluzione dei nomi a dominio
riguarda il riconoscimento di un utente sulla rete
15 il directory server sarà replicato in diverse copie che si mantengono aggiornate da una
copia principale, il master, e rispondono alle richieste in modalità load balancing
14 che
18
• integrità dei dati, perché l’aggiunta di nuove configurazioni non viene fatta modificando un file, 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à, estensioni, aggiornamenti e modifiche
Uno dei maggiori punti di forza della struttura è la sua flessibilità: la separazione
forte tra la struttura fisica 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è creare, eliminare o modificare una qualunque
rete nella struttura semplicemente andando a lavorare sulle configurazioni delle
VLAN.
Possiamo anche creare delle reti distribuite sui vari piani dell’edificio ed
associare un computer ad una qualunque di queste. Ciò potrebbe sembrare controproducente, perché un utente potrebbe collegarsi ad una rete alla quale non è
autorizzato ad accedere, ma la configurazione degli switch decide, porta per porta, a quale rete possiamo accedere, e quindi limita l’accesso di un computer ad
una sola rete (la maggioranza dei casi). L’accesso a più reti dovrebbe riguardare
solo i computer di servizio, degli amministratori e altri server o postazioni che
abbiano realmente tale necessità: la maggior parte dei computer dovrà accedere
solo ad una rete, con la possibilità di entrare nelle altre attraverso il router;
quest’ultimo può permettere il passaggio di traffico fra varie reti VLAN senza
intaccare l’isolamento a livello 2 della pila ISO/OSI dei singoli domini.
La centralizzazione delle configurazioni nel directory server permette di modificare 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 all’interno del file di configurazione del
DHCP, poi aggiungerlo con un nome nel file di configurazione del DNS (avendo
cura di modificare il seriale della zona modificata) ed infine riavviare tali servizi.
Con la nuova struttura possiamo effettuare tutta questa configurazione in un
colpo solo sul directory server, aggiungendo le dovute entry tramite l’interfaccia
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ù recenti come lo standard IEEE 802.1q. Sono
state scelte quelle che garantiscono la maggiore interoperabilità e che forniscono
interfacce e metodi di accesso consolidati e standardizzati.
3.1
Virtual LAN
Una Virtual LAN o VLAN è un metodo di creazione di reti logiche indipendenti
all’interno della stessa rete fisica: permette di ridurre i broadcast domain1 e
facilita l’amministratore 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 traffico 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é le reti sono separate logicamente e non
fisicamente
4. Crea diversi switch logici all’interno dello stesso switch fisico
Il principale protocollo usato per configurare le VLAN è appunto l’IEEE
802.1q, che descrive come possa essere partizionato il traffico su un singolo
network fisico in più reti logiche, assegnando un TAG (cioè un’etichetta) ad
ogni frame con dei byte aggiuntivi che identifichino la rete virtuale alla quale il
pacchetto appartiene.
1 concetto delle reti Ethernet che identifica l’insieme 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 dell’introduzione dello standard IEEE 802.1q, esistevano diversi protocolli proprietari, come il Cisco ISL (Inter-Switch Link, una variante dell’IEEE
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 dell’architettura IEEE 802, su altri sistemi di comunicazione condivisi, ma anche su
reti point-to-point
• le VLAN facilitano l’amministrazione di gruppi logici di stazioni che comunicano come se fossero sulla stessa LAN. Facilitano anche la migrazione,
l’aggiunta e la modifica dei membri di un gruppo
• il traffico tra le VLAN è ristretto; gli switch spediscono traffico unicast,
multicast e broadcast solo sui segmenti di LAN appartenenti ad una certa
VLAN
• per quanto possibile verrà mantenuta la compatibilità con gli switch e le
stazioni già 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è al livello Data-Link. Nella terminologia delle VLAN,
il termine trunk denota una rete che trasporta diverse VLAN, identificate da
etichette inserite all’interno dei pacchetti.
Come nel nostro caso esiste una rete comune che ospita tutte le VLAN.
Questa rete è 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 specifico VLAN ID. Per definire quali porte all’interno di uno switch
appartengono ad un dominio si usa il meccanismo dei TAG.
Il TAG è un’etichetta che viene associata ad una porta dello switch e che
permette il passaggio di traffico per quel particolare dominio: il traffico 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 l’immagine 3.1, nella trama Ethernet esiste il campo VLAN
ID, all’interno del TAG, che contiene uno tra i possibili 4096 ID per dominio.
Possiamo creare fino a 4094 diversi domini sulla stessa rete e non 4096, perché il
2 si
veda il documento originale di standardizzazione dell’IEEE [2]
LAN IDentifier, l’identificatore della rete virtuale
3 Virtual
22
VLAN-ID 0 identifica che un pacchetto non appartiene ad alcuna VLAN, mentre il VLAN-ID 4095 è riservato dal protocollo per motivi implementativi.
I VLAN ID vengono decisi dall’amministratore di sistema: dopo aver scelto
un ID, questo deve essere configurato su tutti gli switch. Per aggiungere una
porta di uno switch ad una VLAN basta configurare sullo switch stesso il TAG
per quella particolare VLAN sulla porta. Una porta può far passare traffico per
più VLAN contemporaneamente.
Esistono 2 modalità di configurazione delle porte di uno switch per il passaggio delle VLAN:
a modalità TAGGED: con questa modalità possiamo assegnare un numero
arbitrario di TAG a ciascuna porta dello switch; lo switch controllerà il
traffico in arrivo sulla porta e farà passare solo quello etichettato con uno
dei TAG VLAN definiti per quella porta. In questo modo però i pacchetti
in arrivo devono già contenere sull’intestazione Ethernet, nel campo VLAN
ID, il codice della VLAN a cui appartengono
b modalità UNTAGGED: tutto il traffico in arrivo sulla porta, per il quale
non è definito il campo VLAN ID, viene taggato cioè ad ogni pacchetto
viene apposto il VLAN ID definito sulla porta in modalità UNTAGGED.
Questo sistema serve per assegnare un VLAN ID ad uno stream di traffico,
senza che i PC sappiano dell’esistenza delle VLAN
Le due modalità possono coesistere sulla stessa porta, definendo un VLAN
ID in modalità UNTAGGED ed 1 o più VLAN ID in modalità TAGGED.
Facciamo un breve esempio per esporre le due modalità.
Modalità Tagged
Come si vede in figura 3.2 una porta può essere configurata in modalità Tagged
per far passare il traffico di una o più reti (nel nostro caso la rete Blu, Verde e
Rossa); il client che è 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à Untagged
In figura 3.3 si vedeil comportamente della stessa porta vista nella figura precedente, definendo un VLAN ID in modalità Untagged (nello specifico il VLAN
ID relativo alla rete Blu). Il client può anche non conoscere il meccanismo delle
VLAN, nel qual caso tutti i pacchetti uscenti non avranno nessun TAG definito
(nella figura sono i pacchetti di colore bianco): a questi pacchetti senza un TAG
lo switch appone il codice della VLAN Untagged, cioè quello della rete Blu,
come mostra l’immagine.
Se il client conosce le VLAN può apporre esso stesso un VLAN ID ai pacchetti
(si noti il pacchetto verde nell’immagine) che sarà distribuito dallo switch a tutte
le porte appartenenti a quel segmento VLAN.
23
Figura 3.2: Esempio di comunicazione in modalità Tagged
Figura 3.3: Esempio di comunicazione in modalità Untagged
3.1.3
Configurazione di VLAN su un computer
Dopo aver configurato 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 configurata in modalità UNTAGGED, non abbiamo bisogno di operare ulteriori configurazioni di sorta sul PC, perché la definizione del VLAN ID
viene demandata allo switch: in questo modo il nostro computer può associarsi
ad una sola rete.
Per un server invece, che deve magari eseguire servizi per più di una rete,
abbiamo necessità di definire 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è delle astrazioni che
permettano di definire dei wrapper 4 per le interfacce fisiche, ciascuno associato
ad una VLAN diversa.
4 letteralmente rivestimento, in questo contesto identifica un pezzo di software che fornisce
un’interfaccia semplice all’utente, nascondendo le specifiche dell’applicazione che usa
24
Figura 3.4: Interfacce virtuali per l’uso delle VLAN
Come mostra la figura 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à 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 significa che dovremo avere un indirizzo IP per ognuna delle reti alle
quali ci associamo5 .
Per rappresentare questa situazione quindi si definiscono 3 interfacce virtuali,
ciascuna delle quali è associata ad una VLAN diversa.
Sui sistemi GNU/Linux possiamo usare il comando vconfig, 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
è:
vconfig <interfacciaReteReale> <VLAN-ID>
Eseguito il comando il sistema creerà una interfaccia virtuale con nome
interfacciaReteReale.VLAN-ID, per distinguere tra le interfacce create.
A questo punto si può 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 dell’interfaccia reale.
Completate le fasi di analisi dei dati e di controllo il traffico viene taggato, cioè
viene aggiunto il campo VLAN ID e viene passato all’interfaccia reale che non
fa altro che mandarlo sulla rete fisica. Sarà poi compito dello switch smistare
questo traffico 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 è 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 un’altra 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 fili, via etere principalmente.
L’etere ha permesso il cablaggio di aree dove finora era difficile 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 fiere o di capannoni industriali a
basso costo.
Lo sviluppo delle reti wireless ha portato alla creazione di nuove tipologie di
rete, vista la facilità di installazione e configurazione di un Access Point wireless,
nello specifico parliamo oggi di:
• PAN: Personal Area Network, reti personali del raggio di qualche metro,
che servono a collegare periferiche come macchine fotografiche digitali o
stampanti ad un computer, ma anche per creare piccole reti di computer
soprattutto per condividere file
• WLAN: Local Area Network wireless, sostitute senza fili delle reti locali,
spesso impiegate per condividere l’accesso 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 geografiche, dell’ordine anche di
vari chilometri, spesso costituite da un insieme di punti d’accesso sotto la
stessa gestione
Per ciascuna di queste tipologie di rete esistono tecnologie e standard di
riferimento che ottimizzano in un caso la velocità di connessione, in altri la
larghezza dell’area di connettività, in altri ancora l’affidabilità del servizio.
Nel nostro caso la rete wireless non sostituisce la LAN tradizionale che rimane attiva per le postazioni fisse degli uffici, ma consente una connettività
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 dell’edificio che devono annunciare tutti le stesse reti.
Al contrario del cavo, sul quale passa il segnale di una rete, o comunque
di reti conosciute, l’etere è libera ed aperta (anche se ci sono delle restrizioni
26
di legge sulle bande di frequenza utilizzabili per le trasmissioni). Nasce perciò
l’esigenza di definire uno standard per l’identificazione di una rete nell’etere.
3.2.1
Extended Service Set
Questo sistema è definito all’interno dello standard 802.11 (lo standard IEEE
per le reti wireless): identifica un insieme di Access Point wireless connessi alla
stessa rete fisica come un unico servizio. In pratica viene definito un nome per
la rete wireless, detto SSID (Service Set IDentifier) definito 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ı̀ definita può passare da una cella, cioè dal raggio
di azione di un Access Point, all’altra senza risentire di alcuna interruzione del
servizio in modo totalmente trasparente.
Riassumendo, l’SSID permette l’identificazione di una rete wireless nell’etere
e il roaming tra due access point che appartengono alla stessa rete. L’identificatore di una rete wireless si chiama ESSID, Extended Service Set Identifier, e permette l’identificazione della rete, solitamente è una stringa che, anche
semanticamente, rappresenta l’utilizzo o il proprietario della rete.
3.2.2
Il progetto INFN/TRIP
Il progetto INFN TRIP (The Roaming INFN Physicist) nasce all’interno del
Comitato Calcolo e Reti dell’Istituto Nazionale di Fisica Nucleare e tenta di
dare una risposta alla necessità dei dipendenti e dei ricercatori dell’istituto di
avere una connessione ad Internet anche quando questi si trovino in una sezione
dell’istituto diversa dalla propria, ad esempio per un convegno o una riunione.
Come si legge nel documento di presentazione del progetto6 , le necessità 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
all’istituto7 , qualora si trovasse in una sezione diversa dalla sua, avrebbe dovuto
contattare l’amministratore di rete di quella struttura e fare una richiesta di accesso (fornendo quindi i propri dati personali). Con questa nuova infrastruttura,
non ci sarà più bisogno di fare richieste, perché basterà 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à spiegato nel
paragrafo 3.3.4, qui riportato nella figura 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
veda la guida all’implementazione [3]
una descrizione della struttura e dell’organizzazione dell’INFN si veda il paragrafo
7 per
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 dell’utente;
2. trasmissione della richiesta alla Struttura di appartenenza per verificarne
la legittimità;
3. trasmissione dell’autorizzazione 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
l’autenticazione 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 è uno standard per il controllo degli accessi ad una
rete. Permette l’autenticazione di dispositivi collegati ad una porta LAN, stabilendo una connessione point-to-point8 con il client o impedendo l’accesso
qualora questi fallisca l’autenticazione. Viene utilizzata anche sugli access point
per reti wireless ed è basato su EAP9 .
Il protocollo può 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).
L’utilizzo in reti wireless permette di superare alcune vulnerabilità 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, definito
dallo standard IEEE 802.11i
28
L’autenticazione avviene tra il client (detto anche supplicant) e l’Access Point
(detto anche authenticator), ma il controllo delle credenziali, cioè l’autenticazione vera e propria, viene effettuata da una terza entità, come un server
RADIUS. Questo garantisce una autenticazione forte attraverso protocolli come
l’EAP-TLS.
Questa commistione di accesso wireless e autenticazione 802.1x (nata per reti
cablate) viene, impropriamente, definita come 802.11x (per alludere al protocollo
802.11 per l’accesso wireless).
Vediamo il processo di autenticazione in 802.1x (sintetizzato nella figura 3.6):
1. quando uno switch (o un access point per il wireless) riconosce che un
client (usiamo il termine supplicant, più appropriato) si è 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 traffico, a livello data link, ad esempio DHCP
o HTTP, ad eccezione del traffico 802.1x;
2. l’authenticator (lo switch o l’AP) manda una EAP-Request al client;
3. il supplicant risponde con una EAP-Response che l’authenticator inoltrerà
al server di autenticazione;
4. il server di autenticazione (nel nostro caso RADIUS) può accettare o
rigettare la richiesta;
5. se accetta, l’authenticator metterà la porta in stato authorized e quindi
farà passare il traffico normale; quando il supplicant si disconnetterà, manderà un messaggio di EAP-logoff all’authenticator che rimetterà la porta
in stato unauthorized;
6. se la richiesta è stata rigettata, la porta rimane in stato unauthorized e il
supplicant potrà tentare di nuovo l’autenticazione.
Figura 3.6: Schema di una sessione di autenticazione 802.1x
Il protocollo garantisce un alto livello di sicurezza ed è flessibile, perché
permette di usare vari algoritmi e meccanismi di autenticazione in EAP.
29
Il protocollo EAP
Il protocollo EAP, Extensible Authentication Protocol, è un framework di autenticazione utilizzato nelle connessioni wireless e point-to-point, ma anche su
LAN cablate. È definito nell’RFC11 3748.
Si noti che EAP non è 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 l’autenticazione
L’EAP-TLS (EAP Transport Layer Security), definito nell’RFC 2716 è
uno standard molto buono per l’autenticazione 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ù grande è il forte overhead necessario per mettere in sicurezza le
comunicazioni, è considerato infatti uno degli standard più sicuri ed è supportato dalle maggiori aziende del settore. La sua forza risiede principalmente nella
necessità, da parte dell’utente, di un certificato. Perciò non basta rubare una
password per autenticarsi, ma bisogna avere un certificato valido per entrare,
che quindi aumenta la sicurezza. Se infine i certificati fossero memorizzati su
un supporto fisico come una smart card o una penna USB, sarebbe molto difficile, per un attaccante, accedere alla rete senza rubare anche la smart card o la
penna USB.
Lo standard EAP-MD5, definito nell’RFC 3748, è 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 l’autenticazione con
smart card contenenti certificati X.509 che possono essere utilizzati anche per
l’accesso ad altre risorse oltre che alla connettività wireless.
TRIP supporta numerosi metodi di autenticazione, in particolare via certificato X.509.
Captive portal
Il Captive Portal è 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à (ad esempio Roma) prevedono reti wireless
ad ampio raggio con autenticazione su Captive Portal.
L’idea si basa sulla delega dell’autenticazione ad un server di autenticazione;
in questo contesto gli Access Point hanno una configurazione ed una conoscenza
11 Request For Comment, documenti di standardizzazione di formati e protocolli dell’IETF,
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
all’elencazione di tutti i MAC-address14 che hanno accesso alla rete.
L’autenticazione viene spostata dalla fase di associazione e assegnazione dell’indirizzo 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 figura 3.7):
1. il client si associa al SSID della rete che prevede autenticazione con Captive
Portal;
2. l’AP lo associa e lo connette alla rete; il server DHCP prontamente gli
fornisce un indirizzo IP, una maschera di rete, l’indirizzo del gateway e
tutte le altre informazioni necessarie alla navigazione (come server DNS
ecc..);
3. il client ora ha accesso alla rete, ma l’unica cosa visibile, appena connesso,
è il gateway della rete stessa, che gli impedisce di uscire sulla rete esterna;
4. a questo punto deve aprire una finestra 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 l’autenticazione;
5. le credenziali da inserire possono essere varie: di solito si richiede accesso
su nome utente/password; ma si può 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) l’accesso
tramite certificato digitale personale installato sul browser, che accetta la
richiesta se riconosce valido il certificato;
6. la richiesta può 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 l’utente inserisce le credenziali giuste, viene visualizzata una schermata
di successo e finalmente è consentita la navigazione sulla rete esterna.
Quello che succede nel gateway, se l’autenticazione riesce, è che viene aggiunta una regola per far passare il traffico proveniente da quel particolare indirizzo
IP.
3.2.3
La rete aperta per i convegni
La rete aperta (con ESSID Open) è utilizzata in caso di convegni, seminari ed
in generale eventi che prevedono l’accesso wireless ad Internet ad utenti che non
sono registrati.
14 MAC sta per Medium Access Control; il MAC address è un numero identificativo, composto da 6 coppie di cifre esadecimali che identifica un dispositivo sulla rete a livello Data
Link
15 stringa di autenticazione valida per un tempo limitato che può essere usata una volta sola
31
Figura 3.7: Schema dell’autenticazione via Captive Portal
Il meccanismo di accesso è uguale a quello visto nella precedente sezione con
Captive Portal. Perciò gli utenti che partecipano al meeting, dovranno associarsi
alla rete wireless OPEN e nel loro browser apparirà la finestra 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 indifferente;
creiamo invece un numero sufficiente 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 all’accesso, e non
dovremo creare ogni volta account che poi verrebbero subito cancellati.
Per implementare questa funzione basterà creare degli account statici che
verranno autenticati tramite server RADIUS; il RADIUS verrà contattato dal
Captive Portal della rete OPEN per l’autenticazione.
Il RADIUS, vista la staticità delle informazioni, potrebbe leggere i dati
degli utenti anonimi anche da file; si prevede comunque la possibilità di registrare questi account sulla directory LDAP per mantenere eventualmente traccia
dell’associazione persona/account.
3.3
Sicurezza, autenticazione e controllo: RADIUS
Dopo aver elogiato i numerosi vantaggi della connettività wireless, dobbiamo
considerare l’altro lato della medaglia, soprattutto analizziamo il tema della
sicurezza.
La tecnologia wireless introduce nelle reti dei problemi che finora potevano
essere trascurati: con i cavi, potevamo essere quasi sicuri che i computer con32
nessi alla rete erano quelli che conoscevamo, perché i cavi, gli switch e le altre apparecchiature possono essere messe sotto controllo, con armadi chiusi e
lucchetti.
Con l’avvento delle reti wireless, qualunque computer dotato di una scheda di rete wireless, che si trovi all’interno della cella del nostro Access Point
può potenzialmente accedere alla rete, senza chiedere autorizzazione a nessuno.
Certamente l’etere è meno controllabile di un cavo che noi stendiamo!
Per considerazioni di questo tipo, non possiamo più fidarci del fatto che chi
riesce ad accedere alla rete è anche autorizzato a farlo.
Dobbiamo dotare la rete, e nello specifico 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ò essere aggirato tramite MAC-spoofing,
cioè modificando l’indirizzo fisico della propria scheda di rete wireless con
uno abilitato all’accesso;
• chiave WEP: meccanismo buono di cifratura dei messaggi, che utilizza
chiavi da 40 bit, ma che può essere aggirato in pochi minuti;
• cifratura forte: nome sotto il quale possiamo far rientrare quei meccanismi
che prevedono l’autenticazione dell’utente su un tunnel cifrato di dati;
questo meccanismo è molto difficile da aggirare, perché intervengono molti
elementi nella fase di autenticazione, tra cui i dati dell’account (nome
utente e password) e i certificati digitali.
3.3.1
AAA e RADIUS
Quello che serve ad una rete wireless che deve servire centinaia di utenti è di
poter definire a livello centralizzato delle politiche e delle proprietà che possano
essere assegnate ai client wireless (o supplicant) da tutti gli Access Point che
costituiscono la rete.
Quello che ci serve è una infrastruttura di AAA, cioè di Autenticazione, Autorizzazione e Accounting.
Spieghiamo brevemente il significato di questi termini16 :
Autenticazione: si intende la conferma che un utente che richiede un servizio,
nel nostro caso l’accesso alla rete, sia un utente valido e conosciuto. Viene
realizzata con la presentazione di una identità o di credenziali, che ad esempio possono essere una password, l’indirizzo MAC della scheda wireless
di un portatile o un certificato digitale.
Autorizzazione: si intende l’accesso a specifici servizi ad un utente, basandoci
sulla sua autenticazione, su quale servizio ha richiesto e sullo stato corrente
del sistema. Può basarsi su politiche che tengano in considerazione l’orario
di richiesta del servizio, la collocazione fisica 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 sull’identità dell’utente, sulla natura del servizio fornito e sull’orario di inizio
e di fine 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, è un protocollo che implementa politiche di AAA per l’accesso 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à il server RADIUS verrà usato solo per controllare le
credenziali di accesso di un utente, a vari livelli.
Il protocollo RADIUS è definito negli standard:
• RFC 2865 Remote Authentication Dial In User Service (RADIUS)
• RFC 2866 RADIUS Accounting
3.3.2
Il protocollo RADIUS
Come si legge nell’RFC17 , le caratteristiche chiave del protocollo RADIUS sono:
Modello Client/Server Un Network Access Server (NAS) opera come client
per RADIUS. Il client è responsabile del passaggio delle informazioni dell’utente al server RADIUS opportuno e deve poi agire in accordo alla
risposta ricevuta. Il server RADIUS è responsabile della ricezione della
richiesta di connessione dell’utente, dell’autenticazione dell’utente e dell’invio di tutte le informazioni di configurazione necessarie perché l’utente
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 è 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 flessibili RADIUS supporta una vasta gamma di metodi per autenticare un utente. Quando un server riceve nome
utente e password, può eseguire un login PPP, PAP o CHAP o UNIX19 o
altri meccanismi di autenticazione.
17 si
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
34
è un protocollo estendibile Tutte le transazioni comprendono tuple di lunghezza variabile del tipo (Attributo, Lunghezza, Valore). Perciò possono essere
aggiunti nuovi attributi senza disturbare l’implementazione già esistente.
Un’altra cosa importante da evidenziare del protocollo RADIUS è che lavora
usando connessioni UDP20 , invece che TCP21 . UDP è 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ò interrogare il server di
backup;
• le particolari necessità riguardo i tempi di risposta non vanno d’accordo col
TCP. Da un lato RADIUS non ha bisogno di tecniche di rilevazione delle
perdite di dati immediate: l’utente può attendere alcuni secondi perché
l’autenticazione sia completata senza troppi problemi; in questo contesto
le ritrasmissioni aggressive del TCP e l’ondata di acknowledgement tipiche
di questo protocollo non sono necessari. Dall’altro lato l’utente non vuole
aspettare dei minuti perché l’autenticazione sia completata: non ci interessa che il TCP fornisca una connessione affidabile 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 è stateless: i client e i server vanno e vengono; UDP
garantisce semplicità 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 ...
finiti i giochi.
• UDP semplifica l’implementazione del server: le prime implementazioni di
RADIUS consistevano in un server single threaded, cioè 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 l’utente.
Vediamo quali sono le operazioni che vengono eseguite per l’autenticazione;
si veda anche lo schema nell’immagine 3.8.
Quando un client è configurato 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, l’ID del client e l’ID della porta alla quale accede
20 User
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è un punto di
accesso alla rete, come un Access Point wireless
35
l’utente. La password viene nascosta usando l’RSA 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 file clients.conf ) tramite il segreto condiviso
(anch’esso scritto nel file client.conf ); se non viene riconosciuto, la richiesta
viene subito scartata.
Se viene accettata, il server RADIUS consulta il database per cercare l’utente e per controllare anche altri parametri che possono essere presenti; se è
necessario, la richiesta può essere rigirata ad altri server (cioè 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 è stata rifiutata. Opzionalmente
può essere incluso un messaggio testuale di rifiuto. 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ò rispondere con un Access-Accept, un
Access-Reject o un altro Access-Challenge.
Se il client riceve un pacchetto di Access-Challenge, fornisce all’utente 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 dell’utente.
Il server può rispondere con un Access-Accept, Access-Reject o un altro AccessChallenge.
Se tutti i requisiti sono soddisfatti, allora i valori di configurazione per
l’accesso vengono inseriti nella risposta di Access-Request.
Nel nostro caso non verrà usato il meccanismo di challenge/response, ma
se i requisiti sono soddisfatti già alla prima richiesta, viene subito spedito un
pacchetto di Access-Accept.
3.3.3
Il nostro server RADIUS
Il nostro server RADIUS è 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ù sicuri. Quest’ultimo
sistema verrà utilizzato anche per il controllo delle credenziali di accesso per i
Captive Portal come vedremo più avanti.
Come già anticipato all’inizio sulla presentazione del progetto, uno dei punti forti della struttura è la sua centralizzazione. Quindi, come ci possiamo
aspettare, le credenziali di accesso, cioè sia i MAC address che gli account
(username & password) autorizzati, sono memorizzati sul servizio informativo
23 algoritmo
di hash molto usato in crittografia
36
Figura 3.8: Processo di autenticazione RADIUS standard
(LDAP) centrale della rete, come mostrato nella figura 3.9.
Con questo meccanismo il server RADIUS non contiene alcuna informazione
di sicurezza, tranne quelle che mantiene in cache per velocizzare l’evasione delle
richieste. Cosı̀ facendo possiamo realizzare anche più 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 specifico.
Le categorie di server RADIUS che abbiamo implementato nel progetto sono
principalmente 2:
• RADIUS per l’autenticazione dei MAC ADDRESS: questo sistema autorizza o meno il MAC address di una scheda wireless se questa è registrata nell’elenco delle schede autorizzate. Il meccanismo di autorizzazione
abusa del protocollo RADIUS perché per scambiare queste informazioni
(riguardanti gli indirizzi fisici) utilizza i campi Username e User-Password
del protocollo RADIUS (si notare che questo comportamente è quello
standard in tutti gli AP che supportano RADIUS)
• RADIUS per l’autenticazione 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 afferisce il server RADIUS. Infatti sul server
delle configurazioni (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 è deciso di creare un server RADIUS per
ognuna delle reti wireless e nello specifico 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à
riguarderanno informazioni di autenticazione sui MAC address. La query
verrà 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 filtrate 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 l’autenticazione su nome utente e password può essere usata anche
per altri servizi, come il login remoto su macchine dedicate, o l’accesso
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 afferenti 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
afferenti 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 è previsto per il futuro un meccanismo di proxying quando esisterà uno standard condiviso tra tutte le università per
l’autenticazione degli studenti e dei dipendenti.
• RADIUS per l’accesso ai convegni: questo RADIUS verrà utilizzato solo durante meeting, convegni o eventi che richiedano l’accesso wireless
di persone esterne al Dipartimento e ad INFN; l’accesso sarà basato su
Captive Portal, per tracciare le connessioni; si prevede di definire delle
utenze anonime, del tipo USER001, che verranno fornite ai partecipanti
all’evento e saranno cancellate alla fine dello stesso, sempre memorizzate
su back-end LDAP.
3.3.4
FreeRADIUS
Tra le varie possibili alternative è stato scelto FreeRADIUS per la gestione del
protocollo RADIUS, versione 1.1.3.
FreeRADIUS è il software libero per protocollo RADIUS più diffuso26 ; ci
sono più di 50000 installazioni documentate, tra cui piccoli siti con decine di
utenti, aziende su larga scala con decine di centinaia di utenti, fino 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à una stima della forte scalabilità dell’implementazione che passa
senza troppi problemi da sistemi embedded con poca memoria fino 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 è una suite di applicazioni per il protocollo RADIUS modulare,
ad alte prestazioni e ricca di funzionalità; 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è la possibilità di rispedire una richiesta ad
un server autoritario di più alto livello, secondo un meccanismo a PROXY
(lo stesso meccanismo impiegato nell’infrastruttura AAI di INFN)
• fail-over e load balancing delle richieste tra diversi server
• possibilità di utilizzare come back-end, cioè come deposito delle informazioni di autenticazione e autorizzazione vari tipi di database (nel nostro
caso usiamo LDAP, ma si possono utilizzare database su file, ad esempio possiamo utilizzare il file /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à detto non è stata utilizzata nel nostro progetto).
26 queste
notizie sono riprese dal sito ufficiale di FreeRADIUS [6]
39
Configurazione di un server RADIUS con backend LDAP
Questa configurazione merita di essere anticipata in questo capitolo dedicato
alle Tecnologie.
FreeRADIUS presenta un’architettura modulare, nella quale possiamo definire
da quali fonti devono essere lette le informazioni di autenticazione e autorizzazione per evadere le richieste.
Di solito, per le realtà piccole, viene usato il file di configurazione 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 configurazione è molto semplice: definiamo all’interno 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 è protetto solo
con password, sono ristetti anche gli host che possono accedervi)
• basedn = ou=radiusmac,dc=priv: come si vedrà più avanti il base DN è
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 filtro cerchiamo una entry LDAP che abbia come uid proprio il
MAC address o l’username 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 dall’utente.
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ù 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 modificando il pacchetto per riflettere le necessità del sito locale.
La scelta di quale server interrogare per evadere una richiesta viene fatto
attraverso il realm. Il realm può far parte del Network Access Identifier (l’identità dell’utente per la rete). L’idea del realm è quella di separare vari domini di
lavoro; un concetto simile al dominio DNS.
Un server RADIUS può funzionare sia come forwarding server, cioè come
proxy per altri server, che come server remoto, cioè come server terminale per
una richiesta. Un singolo RADIUS può 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à la funzione di
proxying. Il server al quale demanderà le richieste sarà quello della sede centrale
nazionale di INFN, che può autenticare gli utenti di qualunque sezione italiana
(si veda l’immagine 3.5 per uno schema del proxying RADIUS).
Uno schema della gerarchia dei server INFN è riportato in figura 3.10.
Figura 3.10: Struttura gerarchica dei server RADIUS INFN
41
Il meccanismo di gestione e configurazione dei REALM verrà analizzato più
avanti nel paragrafo 4.3.3.
3.4
Certificati digitali X.509: sicurezza garantita
X.509 è uno standard ITU-T27 per l’infrastruttura a chiave pubblica (PKI).
3.4.1
Crittografia
La crittografia è quella scienza che studia i meccanismi per nascondere il contenuto di un messaggio a chi non è 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 dell’alfabeto, o
magari in un numero che permettesse l’interpretazione del messaggio; il segreto era protetto e non doveva essere rivelato ad altri. Questo meccanismo
della chiave condivisa va sotto il nome di crittografia 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è cifrarlo.
Per riottenere il messaggio originale il ricevente, che conosce la chiave con cui
il messaggio è stato cifrato, applica un procedimento analogo ma contrario che
permette di riottenere il messaggio originale, detto anche messaggio in chiaro
(come mostrato in figura 3.11).
Figura 3.11: Meccanismo di cifratura simmetrica
La crittografia a chiave pubblica, o asimmetrica, è una forma di crittografia nella quale un utente possiede, invece di una singola chiave condivisa
con l’altro utente, una coppia di chiavi, pubblica e privata.
La chiave privata viene tenuta segreta, mentre quella pubblica può essere diffusa
liberamente. Le chiave vengono generate attraverso dei procedimenti matematici che garantiscono una buona sicurezza verso eventuali attaccanti - la loro
forza si basa sulla difficoltà di fattorizzare numeri molto grandi.
27 Internation Telecommunication Union - Telecommunication Standardization Sector,
ovvero il Dipartimento di standardizzazione delle telecomunicazioni dell’Unione Internazionale
delle Telecomunicazioni
42
Sebbene le chiavi siano in una certa relazione matematica, è praticamente impossibile derivare la chiave privata da quella pubblica.
La crittografia a chiave pubblica nasce come soluzione ai molti problemi della
crittografia a chiave privata.
Figura 3.12: Meccanismo di cifratura asimmetrica
La crittografia a chiave pubblica permette di eseguire due importanti operazioni sui messaggi:
Cifratura messaggi cifriamo il messaggio con la chiave pubblica dell’utente
al quale lo vogliamo spedire; il destinatario potrà leggere il messaggio
originale, decifrandolo con la sua chiave privata ed è l’unico che può farlo
perché nessuno possiede la sua chiave privata (si veda la figura 3.12);
Firma digitale per assicurare il destinatario sull’identità del mittente, questi
firma il messaggio con la sua chiave privata: in questo modo chiunque può
verificare l’identità del mittente attraverso la sua chiave pubblica (che
viene diffusa liberamente, in elenchi disponibili sul web); inoltre il destinatario può anche controllare, attraverso la firma, che il messaggio non sia
stato alterato durante la trasmissione.
Il problema centrale di questo meccanismo è avere la certezza che una certa
chiave pubblica sia autentica, cioè che corrisponde all’utente che l’ha creata.
Una soluzione a questo problema viene data dalla Public Key Infrastructure:
ci si appoggia su una terza parte, la Certification Authority, che garantisce
l’autenticità delle chiavi. Un’altro approccio è quello del web of trust, che delega
il controllo dell’autenticità di una chiave alla comunità, basando la fiducia di una
chiave sul numero di persone che hanno avuto fiducia su di essa in precedenza
- questo meccanismo è poco usato dalle aziende perché non può dare garanzie
documentate.
Sebbene questo meccanismo sia più 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 approfittare dei lati positivi di entrambi i
sistemi, la velocità del simmetrico e la sicurezza dell’asimmetrico, si è 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 crittografia, l’infrastruttura a chiave pubblica è un sistema
che collega le chiavi pubbliche di cifratura all’identità dei rispettivi proprietari,
attraverso un’autorità di certificazione (Certification Authority). In questo contesto quindi si delega la fiducia sull’identità associata ad una chiave, ad una terza
parte, la CA28 , della quale gli appartenenti al sistema si fidano, che garantisce
con la sua firma digitale l’identità 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à sono:
1. ottenere il certificato digitale dell’utente, attraverso il suo sito Internet
oppure richiedendolo direttamente all’interessato tramite una email;
2. controllare la firma della CA che ha rilasciato il certificato: questo lo posso fare controllando, con il certificato dell’autorità, la firma sul certificato
dell’utente; qualora questa procedura fallisse, dovrei richiedere il certificato o trovare una fonte diversa dalla quale scaricare il certificato (il sito
della CA potrebbe mettere a disposizione i certificati che ha firmato);
3. controllata la validità del certificato posso estrarre da esso la chiave pubblica e spedire messaggi cifrati all’utente 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 l’identità
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 l’INFN si è organizzato con una Certification Authority propria a livello nazionale. Per snellire il lavoro, come prevede
la PKI, sono state create delle Registration Authority, cioè dei punti di fiducia
distribuiti che si pongono come intermediari tra i richiedenti del certificato e
la CA. Il loro compito principale è il controllo delle identità dei richiedenti per
il rilascio di un nuovo certificato. Altro compito molto importante è quello di
comunicare tempestivamente alla CA lo smarrimento o il furto della chiave privata di un utente, che quindi mette a rischio la validità della sua chiave pubblica
firmata dalla CA: la RA provvede a comunicare l’evento alla CA che prenderà
le opportune contromisure.
Queste contromisure prevedono l’inserimento del certificato manomesso all’interno delle liste di revoca dei certificati (CRL29 ) che vengono pubblicate
dalla CA per informare tutti gli utenti dei certificati ritenuti non più validi e
che quindi non devono essere usati.
3.4.3
Certificato digitale
Un certificato digitale può essere visto come una carta di identità elettronica che
definisce le credenziali del proprietario e può essere utilizzata per lavoro o ad
28 Certification
29 Certificate
Authority, autorità di certificazione
Revocation List, appunto la Lista dei certificati revocati
44
esempio per effettuare transazioni sul web. In generale è usata per riconoscere
ed autenticare un utente. Viene rilasciato, come già detto, da una autorità
di certificazione che garantisce sulla coppia chiave pubblica/identità dell’utente.
Contiene nome dell’utente, numero seriale del certificato, data di scadenza, copia
della chiave pubblica del possessore del certificato e firma digitale dell’autorità
di certificazione che in questo modo garantisce il documento.
3.4.4
Il formato X.509 per certificati digitali
Lo standard X.509, come ci suggerisce il nome, nasce insieme allo standard
X.500 e prevede un sistema fortemente gerarchico di autorità di certificazione
per il rilascio di un certificato. Nasce nel 1988 e si propone come meccanismo
completo per l’implementazione della PKI. Una CA rilascia un certificato 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 è, come dice la parola stessa, un nome distintivo che permette di individuare una persona, un host o qualunque cosa all’interno di un ente o di un paese,
in modo gerachico, similmente ai nomi a dominio.
I certificati 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 certificato digitale, che può essere firmato da
un’altra CA (per creare cosı̀ una gerarchia di fiducia).
Altro elemento dello standard X.509 sono le liste di revoca dei certificati
(CRL), che permettono ad una CA di far conoscere, a tutti, i certificati che non
sono più validi, ad esempio perché un utente ha perso la chiave privata, oppure
perché questa gli è stata rubata.
Struttura di un certificato X.509
Vediamo i valori contenuti all’interno di un certificato X.509:
• Version: versione di X.509 utilizzata (attualmente siamo alla 3.0)
• Serial Number : numero seriale che identifica il certificato all’interno della
CA
• Algorithm ID: identificativo dell’algoritmo di cifratura utilizzato;
• Issuer : nome distintivo della CA che ha rilasciato il certificato;
• Validity: periodo di validità del certificato, come data di inizio (campo
Not Before) e data di fine (campo Not After);
• Subject: nome distintivo della persona o dell’identità da associare al certificato;
• Subject Public Key Info: informazioni sulla chiave pubblica del soggetto,
composto da Public Key Algorithm, cioè l’algoritmo per l’utilizzo della chiave pubblica, e Subject Public Key, la chiave pubblica associata
all’identità;
45
• Issuer Unique Identifier : codice identificativo univoco dell’emittente (facoltativo);
• Subject Unique Identifier : codice identificativo univoco del soggetto (facoltativo);
• Extensions: facoltativo, può contenere varie informazioni come il nome
alternativo (di solito l’email), l’URL della lista dei certificati revocati ecc.;
• Certificate Signature Algorithm: l’algoritmo di firma del certificato;
• Certificate Signature: la firma digitale vera e propria del certificato, fatta
con la chiave privata della CA.
Vediamo ad esempio il file di certificato 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:[email protected]
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 certificato digitale
I certificati digitali vengono utilizzati largamente su Internet e su intranet aziendali
per svariati servizi:
• Autenticazione per sito web: molte aziende per l’accesso ad alcune sezioni del
proprio sito (magari quelle dedicate ai fornitori o ai dipendenti) richiedono che
venga riconosciuto valido il certificato digitale installato nel browser dell’utente:
in questo modo viene eliminata la necessità di ricordarsi username/password;
• Autenticazione per accesso wireless: nel progetto diamo la possibilità a tutti i
possessori di certificato digitale valido emesso dalla Certification Authority di
INFN30 di accedere ad Internet dalla rete della Sezione di Perugia, senza bisogno
di registrazione;
• Firma digitale: firmando le proprie email si dà sicurezza al ricevente che non ci
sono state alterazioni durante la trasmissione e sappiamo che l’utente ha ricevuto
proprio il messaggio che intendevamo spedire;
• Cifratura della posta elettronica: è buona pratica allegare a tutti i messaggi
di posta elettronica che si spediscono il proprio certificato digitale, cosı̀ che
se qualcuno vuole spedirci dei messaggi sicuri, può farlo attraverso la chiave
pubblica contenuta nel certificato.
3.5
Directory service con LDAP
Il protocollo Lightweight Directory Access Protocol o LDAP è un protocollo applicativo
(livello 7 della pila ISO/OSI) che permette di interrogare e modificare le informazioni
contenute in un directory service31 . Una directory è un insieme di oggetti con attributi simili, organizzati in modo logico e gerarchico. L’esempio più comune è quello
dell’elenco telefonico, che consiste in una serie di nomi in ordine alfabetico, con indirizzo e numero di telefono associati. Di solito le gerarchie LDAP riflettono situazioni
politiche, geografiche 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ù comuni dei directory service è quello della memorizzazione
di informazioni di autenticazione e contatti personali; basta notare come le ultime
versioni dei più 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ù diffuse applicazioni che richiedono autenticazione, che permettono di utilizzare l’autenticazione 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 è la LDAPv3 che viene definita in alcuni RFC,
come si legge nell’RFC 4510 (si legga [8]).
30 il
sui sito istituzionale è http://security.fi.infn.it/CA
descrizione è tratta da [7]
31 questa
48
3.5.1
Storia
La storia del protocollo LDAP ha radici lontane, già quando le prime compagnie
di telecomunicazioni avevano bisogno di directory service efficienti per mantenere le
informazioni di milioni di utenti.
Negli anni 80 l’International Telecommunication Union (ITU) definı̀ la specifica
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
un’alternativa 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. All’inizio il protocollo era conosciuto
anche come LDBP, ovvero Lightweight Directory Browsing Protocol; successivamente
venne corredato anche delle funzioni di modifica ed aggiornamento e quindi si preferı̀
access invece di browsing.
Altri protocolli e standard che riguardano i directory service sono il già citato X.500, l’XML 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é non usare un database relazionale?
Ci sono alcune differenze sostanziali tra una directory e un database relazionale.
Andiamo a vedere le differenze per poi fare alcune considerazioni:
• generalmente le informazioni sono lette più spesso di quanto sono scritte; per
questo motivo difficilmente troviamo implementate funzioni riguardanti transazioni
(come rollback o abort)
• i dati possono essere ridondati (ed è 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ù avanti di cosa
si tratta)
• uno schema, cioè la struttura di una entry della directory, è definito come attributi che un oggetto può 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à esistenti per
massimizzare la compatibilità e ridurre i problemi di aggiornamento legati a
nuove versioni del software del directory server
32 Internet Assigned Numbers Authority, l’ente che governa l’allocazione 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 dall’altra,
partendo dalla radice della gerarchia
• per individuare un’informazione, non devo conoscere la tabella nella quale è
memorizzata; mi basta conoscere il suo namespace
A differenza dei database, che permettono di modellizzare su computer una situazione reale, una directory costituisce un supporto per le informazioni di autenticazione
e autorizzazione; perciò sono pensate per svolgere un compito diverso da quello dei
database relazionali. La differenza più evidente quindi è che i database relazionali
sono usati per automatizzare un sistema con un modello di dati dedicato, mentre una
directory è usata per mantenere oggetti identificabili che possono essere usati da diverse applicazioni nei modi più 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é le informazioni contenute sono schematizzate in
un formato consolidato, che permette di modificarle e di arricchirle, aggiungendo nuove
classi di oggetto, senza necessità di drastiche modifiche alla struttura dei dati.
Ultimo vantaggio è la scalabilità: 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 definizione e la strutturazione delle directory è rimasto quello di
X.500 del 1993 e cioè:
• una directory è un albero di entry
• una entry è un insieme di attributi
• un attributo ha una nome e uno o più valori; gli attributi sono definiti negli
schema
LDAP non definisce alcun ordinamento, perciò 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 identificatore univoco, detto Distinguished Name
(DN). Il DN è costituito da due parti:
• il Relative Distinguished Name, costruito tramite alcuni attributi dell’entry, che
possiamo vedere come il nome proprio dell’entry
• il Distinguished Name dell’entry padre dell’entry corrente
In questo modo il nome dell’entry rappresenta oltre che il suo nome, anche il
percorso per trovarla all’interno dell’albero LDAP.
Vediamo l’esempio di definizione di una entry LDAP:
dn: cn=Simone Pascarosa,ou=people,dc=fisica,dc=unipg,dc=it
givenName: Simone
sn: Pascarosa
cn: Simone Pascarosa
mail: [email protected]
telephoneNumber: 0755852777
objectClass: inetOrgPerson
objectClass: top
50
La definizione di una entry consiste nell’assegnare ad ogni attributo un valore;
solo alcuni di questi sono obbligatori, molti sono stati omessi (la inetOrgPerson è
una classe molto diffusa per la memorizzazione dei dati personali); si noti la sintassi
dell’esempio 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 è:
nome attributo: valore
L’attributo dn è il nome dell’entry: non è né un attributo, né parte dell’entry
stessa, ma il suo identificatore:
cn=Simone Pascarosa è il Relative Distinguished Name
ou=people,dc=fisica,dc=unipg,dc=it si riferisce all’entry padre
cn significa Common Name, mentre dc sta per Domain Component, invece ou sta
per Organizational Unit.
Le righe successive definiscono i restanti attributi dell’entry, come nome e cognome
del contatto, l’indirizzo email, il numero di telefono ecc.
Un server contiene un sottoalbero che parte da una specifica entry: il server
del Dipartimento di Fisica potrebbe contenere ad esempio tutto il sottoalbero con
radice in dc=fisica,dc=unipg,dc=it e sotto di questo avere informazioni sui dipendenti nel sottoalbero ou=people,dc=fisica,dc=unipg,dc=it, sugli account degli utenti in
ou=account,dc=fisica,dc=unipg,dc=it e via dicendo.
In questo caso, il nome della radice rispetta il nome a dominio dell’ente, 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 è la possibilità di delegare alcuni sottoalberi ad altri server. Se ad esempio il nostro server gestisce l’albero dc=fisica,dc=unipg,dc=it, ma abbiamo creato un
server che gestisce autonomamente il sottoalbero ou=people,dc=fisica,dc=unipg,dc=it,
allora il server principale può rimandare le interrogazioni a questo server.
Esistono due meccanismi per implementare questa feature in LDAP (si vedano
rispettivamente gli schemi nelle figure 3.13 e 3.14):
Referrals: un server A viene interrogato per un sottoalbero di cui non contiene informazioni (punto 1 nell’immagine), 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 l’indirizzo del server B che può 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
nell’immagine), quando ha ottenuto la risposta (punto 3), la rispedisce al client
(punto 4)
Entrambi i metodi presentano delle caratteristiche peculiari che fanno preferire
l’uno rispetto all’altro in certi casi:
• il meccanismo del Chaining sposta l’onere 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 è 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 l’onere di replicare la richiesta al server autoritativo, cosi che il primo server viene alleggerito; questa soluzione è 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 è la definizione formale del contenuto delle entry in un sottoalbero.
Lo schema definisce 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 definisce le classi di oggetto generate attraverso
composizioni degli attributi definiti. Per gli attributi, lo schema definisce:
• se l’attributo è multivalore o a valore singolo
• le modalità di ricerca consentite (case sensitive o meno, ricerca su sottostringhe
ecc.)
• le modalità di confronto consentite
• la descrizione dell’attributo
Per le classi di oggetti, lo schema definisce:
• il codice
52
• il nome e la descrizione
• l’object 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à 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 specifica della sintassi della definizione degli schemi LDAP,
possiamo vedere come viene definito un attributo e come questo viene usato subito
all’interno della definizione di una nuova classe di oggetti (appunto objectClass).
È importante notare come le classi siano strutturate in una gerarchia attraverso
l’ereditarietà: in modo simile ai linguaggi di programmazione ad oggetti, si ha la possibilità di ereditare gli attributi di una classe già definita. La radice di questa gerarchia
è la classe top che definisce come unico attributo obbligatorio proprio l’attributo objectClass, cioè quello attraverso il quale si definisce la classe di appartenenza di una
entry.
Per completezza ecco la definizione della classe top:
objectclass ( 2.5.6.0 NAME ’top’
DESC ’RFC2256: top of the superclass chain’
ABSTRACT
MUST objectClass )
Siccome non è specificato altrimenti, si deduce che l’attributo objectClass è multivalore, quindi una entry può appartenere a più object class contemporaneamente, definendo almeno tutti gli attributi obbligatori delle classi usate. Bisogna fare attenzione
alle collisioni tra nomi di attributi uguali all’interno di due differenti classi.
53
Gli elementi di uno schema vengono identificati, oltre che dal loro nome, anche da
un identificatore globale detto Object Identifier (OID), che attraverso una notazione
numerica puntata, identifica 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 definizioni.
Oltre agli schema standard ogni amministratore può definire i propri personalizzati, anche partendo da quelli già fatti, per rappresentare meglio la propria realtà
aggiungendo gli attributi e le classi di oggetto che ritiene necessari.
3.5.6
Server LDAP slave
Vista la criticità dei dati contenuti nelle directory LDAP e la necessità 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à 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ù copie dello stesso server, in modo da
ottimizzare l’utilizzo 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 modifiche che vengono effettuate alla directory verso ciascuna copia, per mantenere
omogeneità nei dati tra master e slave, come vediamo nella figura 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à informazioni di diversa
natura, dettate principalmente dalla necessità di centralizzare le configurazioni dei
servizi di rete e di riconoscere l’utente associato a ciascun host della rete. In particolare
verranno memorizzate sulla directory:
• le configurazioni 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 flessibile per la trasmissione e la
codifica di dati
54
• le identità 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 l’indirizzo
email di un utente
• le configurazioni del server RADIUS (in particolare gli indirizzi MAC dei portatili che accedono senza ulteriore autenticazione)
3.6
Virtualizzazione per alta affidabilità
Per virtualizzazione si intende l’astrazione delle risorse dei computer. Potremmo
definire la virtualizzazione come una tecnica per nascondere le caratteristiche fisiche
di una risorsa (informatica) al sistema operativo, alle applicazioni e all’utente finale.
Ad esempio, potremmo far sembrare che una singola risorsa fisica (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ù risorse logiche come se fossero una sola risorsa.
Il concetto di virtualizzazione è molto ampio, e nel passato ha assunto varie declinazioni nei vari ambiti dell’informatica: il concetto di stampante virtuale, per esempio,
nasconde lo stato della stampante all’utente facendola sembrare sempre disponibile,
oppure il concetto di disco virtuale, che permette di creare dispositivi virtuali a partire da partizioni, insiemi di partizioni, file o aree disco. Il fattore comune è quello del
mascheramento dei dettagli fisici di una risorsa, a favore della flessibilità di utilizzo e
d’interfacciamento verso l’utente.
Puntualizziamo anche la differenza 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 è visibile, che percepiamo, ma che
non esiste nella forma in cui lo percepiamo (perché frammentato o combinato),
ad esempio un disco virtuale.
Seguendo una classificazione 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 è 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 è un ambiente virtuale che si pone come interfaccia tra
l’hardware del computer e il sistema operativo cosı̀ che l’utente abbia la sensazione di
usare un ambiente a lui dedicato. Come sistemi operativi host possiamo usare versioni
modificate 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è l’hypervisor non deve necessariamente simulare l’hardware, ma mette a disposizione delle speciali API34 che possono essere usate
dai sistemi operativi ospite, opportunamente modificati. Queste chiamate di sistema
all’hypervisor vengono appunto chiamate hypercall in Xen e offrono la possibilità di
controllare l’allocazione delle risorse harware alle macchine virtuali tramite il monitor.
34 Application
Program Interface
55
Xen nasce come progetto di ricerca all’Università 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é permette di creare macchine virtuali in modo
veloce ed efficiente, garantisce un basso overhead di calcolo (dovuto al monitoraggio e
al controllo delle macchine virtuali) e alla disponibilità di documentazione e supporto
su Internet.
Vediamo alcuni esempi dei benefici della creazione di macchine virtuali:
• creazione di server virtuali dedicati da parte degli Internet Hosting Service, per
fornire all’utente un ambiente di lavoro indipendente e personalizzato
• frammentazione dei servizi su server ad alte prestazioni, per aumentarne l’efficienza 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à, lo sfruttamento delle risorse e dà la capacità 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 fisico in modo da mantenere attivo il servizio anche in caso di
malfunzionamenti fisici 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 confinare il down di una macchina al singolo servizio che ospita; moltiplicheremo quindi il numero di server a disposizione che, anche se virtuali,
mantengono funzionalità soddisfacienti. Con lo stesso meccanismo possiamo creare
delle repliche dei server più critici, in modo tale da mantenere alti livelli di affidabilità
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 dell’architettura di Xen:
• Hypervisor: è il monitor delle macchine virtuali, che gira come servizio sul
sistema operativo host;
• Sistema operativo host con supporto per l’Hypervisor;
• Kernel dei sistemi operativi client con supporto per le chiamate Xen;
• Immagine dei filesystem dei sistemi client;
• Strumenti di amministrazione;
• File di configurazione delle macchine virtuali.
Introduciamo alcuni termini dell’architettura Xen:
Domain 0 (o Dom0) è il primo dominio 35 avviato dall’hypervisor all’avvio. Ha dei
privilegi speciali, ad esempio può avviare nuovi domini guest e può accedere
direttamente all’hardware. È responsabile di eseguire i driver per tutti i dispositivi presenti e, per l’hardware condiviso con gli altri domini, ad esempio schede
di rete e dischi, carica i backend driver che multiplexano e instradano all’hardware le richieste provenienti dai driver frontend di ciascun DomU. Solo Linux e
NetBSD possono essere eseguiti come Dom0, perché 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) è la controparte del Dom0; è un dominio ospite che non ha
accesso diretto all’hardware. Deve eseguire dei driver frontend per l’hardware
che vuole usare, che è condiviso con gli altri DomU. Il DomU è avviato dal
demone xend sul Dom0, tramite il comando xm. Il kernel del DomU da avviare
è memorizzato nel Dom0, non nel filesystem esportato al DomU.
Xen Hypervisor è il cuore di Xen: si situa tra l’hardware e il sistema operativo
dei vari domini. È responsabile del controllo dell’allocazione delle risorse, dello
scheduling e di altre operazioni a basso livello. Presenta al sistema operativo
una macchina virtuale, del tutto simile all’architettura reale sottostante. I domini comunicano con l’hypervisor attraverso delle hypercall (chiamate hardware
opportunamente modificare per usare le API di Xen); dal canto suo l’hypervisor
risponde con un evento, che simula il funzionamento degli IRQ 36 dell’hardware
reale.
Xend è il demone che si occupa del controllo delle macchine virtuali; viene eseguito
all’avvio, all’interno del Dom0.
Si veda lo schema in figura 3.16 che riassume la struttura dell’architettura di Xen.
Figura 3.16: Schema semplificato dell’architettura 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é
permettono di creare dei server molto snelli e veloci, che contengono solo il software
strettamente necessario.
Avendo delle macchine virtuali, sarà facile replicare un server se questo andasse
in crash: infatti basta copiare il filesystem della macchina virtuale difettosa su una
macchina funzionante, copiarne la configurazione e mandarla in esecuzione. Le due
macchine devono avere delle configurazioni simili. Si prevede perciò 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
L’Enterprise Volume Management System (EVMS) è un software di gestione di volumi
logici molto potente e flessibile, che permette di configurare sistemi complessi di storage
sotto Linux.
Volumi logici
I volumi logici sono un’astrazione delle partizioni disco create da un gestore di volumi.
Un volume logico può 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 flessibile le partizioni del disco, modificare la dimensione di un volume, aggiungendo nuove risorse, eliminando cosı̀ il problema dei limiti fisici 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ò incrementare di continuo lo spazio del volume logico associato.
La flessibilità di EVMS, come gestore di volumi logici, permette di creare volumi
che fisicamente corrispondono a file su una partizione fisica. Si possono creare delle
macchine virtuali su un computer ed usare come filesystem per queste macchine dei
file su disco che EVMS mostra come partizioni.
37 un’architettura
che prevede di collegare unità di memorizzazione (come dischi o supporti
ottici) in remoto ad un server, in modo tale che il sistema operativo veda quell’unità come
se fosse collegata localmente, rendendo trasparente la rete; si contrappone ai NAS (Networkattached storage) che usano un protocollo basato su file, come NFS o SMB, per collegare in
remoto delle unità disco, che vengono riconosciute come collegate via rete.
58
Capitolo 4
Realizzazione
Le fasi di ideazione del progetto, definizione 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 è stata installata e configurata ed è correntemente in uso presso il dipartimento, anche se ancora in fase di completamento.
Il lavoro è stato svolto su una infrastruttura già esistente, che non può essere
fermata per un certo periodo per l’aggiornamento, quindi la fase di migrazione degli
utenti ancora non è stata completata. A questo proposito si sta procedendo al passaggio graduale degli utenti, delle aule e dei laboratori a questa nuova infrastruttura,
modificando, in modo progressivo, i metodi di accesso alla rete.
Ecco, in breve, le fasi necessarie a completare l’installazione della nuova rete:
• progettazione: questa fase riguarda lo studio delle necessità degli utenti e l’individuazione delle tecnologie migliori per realizzare gli obiettivi della nuova rete;
soprattutto si è dovuto tenere conto della coesistenza dei due enti, Dipartimento
di Fisica ed INFN, all’interno dello stesso edificio
• definizione delle reti: in questa fase si è dovuto decidere quante e quali reti1
dovessero essere previste per la fase iniziale dell’implementazione (alcune di esse
servono solo per la fase di migrazione)
• configurazione dei dispositivi: prese le decisioni più importanti, è stato necessario configurare gli switch per riconoscere e distribuire in modo corretto il
traffico delle nuove reti; inoltre è stato necessario configurare il router di frontiera tra le reti, che richiede particolari attenzioni. Lo stesso lavoro è stato svolto
per gli access point wireless
• configurazione dei servizi: questa fase, avvenuta in concomitanza alla precedente, ha permesso di configurare 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, fissi o portatili, degli utenti, tutti gli account e le
configurazioni dei servizi principali. Questa fase richiede sicuramente il tempo
maggiore, poiché necessita di ripetute interazioni con gli utenti per l’inserimento
dei dati nella directory LDAP
• smantellamento delle vecchie strutture: questa fase consisterà nella rimozione
delle vecchie reti wireless e dei vecchi account degli utenti, e la definitiva 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à composta di varie reti che coesistono all’interno della
stessa infrastruttura di rete (cavi, switch, router). Verranno create 16 reti separate
che saranno utilizzate sia per modalità di accesso diverse, che per servizi diversi, come
vediamo nella tabella 4.1.
La struttura è flessibile ed estendibile: questo permetterà in futuro di aggiungere
nuovi domini, senza troppa difficoltà. 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 dell’edificio, opportunamente configurati, 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 sull’indirizzamento IP di tali reti.
4.1.1
Indirizzamento IP
La scelta fatta per l’indirizzamento delle varie reti tiene in considerazione alcuni fattori:
• non stravolgimento, nei limiti del possibile, degli indirizzamenti già esistenti
• possibilità di vedere le varie reti come un’unica rete ad un certo livello di
astrazione
Per rispondere alla prima necessità, è 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 l’indirizzamento 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à si è scelto di utilizzare una classe con capacità di indirizzamento molto grande e possibilità di suddividere la rete in porzioni
con la stessa cardinalità, di dimensioni ragionevoli (con almeno 200-300 indirizzi IP
disponibili). Abbiamo quindi la rete di classe A 10.0.0.0 che è 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ò contenere fino ad un massimo di 2562 = 65536 indirizzi IP, che
possono sicuramente soddisfare tutte le necessità presenti e future del dipartimento.
Per completezza, viene riportato l’assegnamento degli indirizzi alle reti, la VLAN
ad esse associate e il loro utilizzo nella tabella 4.2.
4.2
Implementazione VLAN
Dopo aver definito le reti di cui abbiamo bisogno, si devono far conoscere tali reti
agli switch del dipartimento. Verranno usati switch managed, cioè switch ai quali si
può assegnare un indirizzo IP e che forniscono una interfaccia per configurare le porte
e altri parametri di commutazione. Altro requisito degli switch è, naturalmente, il
supporto alle VLAN. Gli switch utilizzati sono quelli della serie 3Com 3300Tm e HP
Procurve 2848. Entrambi forniscono sia un’interfaccia web, che un piccolo interprete
a linea di comando per impostare le configurazioni dello switch.
4.2.1
Aggiunta dei VLAN ID
Per realizzare una Virtual LAN c’è bisogno che tutti gli switch conoscano il suo
identificatore (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à la rete cablata sia del Dipartimento di Fisica, che
dell’INFN: ad essa saranno collegate tutte le postazioni fisse
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 certificato 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 certificato 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à
rete wireless dedicata agli studenti dei Corsi Triennali e Specialistici di Fisica, che verrà gestita dal Dipartimento di Fisica per implementare politiche restrittive che permettano di
garantire l’accesso a certe porzioni della rete, in base, ad
esempio, all’anno di iscrizione di uno studente
rete wireless dedicata a tutti gli utenti sia del dipartimento di fisica che della sezione dell’INFN; 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 affluenza di persone, che non afferiscono né al dipartimento di
Fisica, né a INFN
rete dedicata a distribuire il tronco pubblico della rete del
Dipartimento di Fisica; conterrà 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 dell’edificio alla griglia di calcolo, aumentando
la sua capacità 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 è quindi quello di memorizzare in ogni switch (quelli di dorsale
almeno) il codice delle VLAN usate (si veda la figura 4.1); i dati da fornire in configurazione sono:
VLAN ID : il codice della VLAN (compreso tra 1 e 4094);
VLAN Name : il nome della VLAN, opzionale, utilizzato solo per facilitare l’utente;
Local ID : codice usato internamente su vecchi switch che permettono di configurare fino
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 definire quali porte appartengono a ciascuna VLAN:
ciascuna VLAN può essere annunciata su zero o più porte e ciascuna porta può
appartenere ad una o più VLAN.
L’appartenenza di una porta ad una VLAN può 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; nell’immagine 4.2 aggiungiamo porte Tagged alla lista della
VLAN 2 (WIRED).
62
Figura 4.2: Aggiunta di porte in modalità 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è viene inserita l’intestazione 802.1q con quel VLAN ID e sono quindi inoltrati verso altre
porte di quella VLAN; nell’immagine 4.3 si noti la parte evidenziata nella quale
specifichiamo la rete 2 (WIRED) come Untagged VLAN per la porta 1 dello
switch.
Figura 4.3: Definizione della VLAN Untagged per una porta dello switch
Da ciò consegue che ogni porta può appartenere a molte VLAN in modalità Tagged,
ma ad una sola in modalità Untagged, che quindi inserisce nella VLAN Untagged tutto
il traffico non 802.1q proveniente da quella porta.
63
Figura 4.4: Esempio di separazione dei domini VLAN
Si possono creare delle configurazioni complesse che distribuiscono le varie VLAN
per tutti gli switch presenti nella rete, come mostra la figura 4.4.
4.2.3
Configurazione VLAN con SSID multipli su AP wireless
Gli access point usati nella nostra struttura sono i Cisco Aironet 1100 e 1200.
Come si è visto nel progetto della rete nel paragrafo 2.3, ad ogni rete wireless
corrisponde una particolare VLAN.
Per configurare 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 identificatori delle VLAN associate
2. creare degli SSID per ciascuna rete
3. impostare le politiche di sicurezza per ciascuna rete
Configurazione delle VLAN negli access point
Per aggiungere una VLAN negli access point, basta selezionare la voce VLAN nella
sezione Service dell’interfaccia web di configurazione.
Figura 4.5: Configurazione delle VLAN sugli Access Point Cisco
Come si vede nell’immagine 4.5, per aggiungere una VLAN basta inserire il suo
VLAN ID e un nome, opzionale, per riconoscere la rete più facilmente. Si può scegliere
quale VLAN deve essere nativa, cioè alla quale associare i pacchetti che non hanno un
VLAN ID definito.
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é un
computer si possa connettere alla rete senza fili è definire gli SSID, o meglio gli ESSID2 .
Come mostra l’immagine 4.6, per definire un SSID, cioè una nuova rete3 wireless,
basta digitare il suo nome, la VLAN associata a questa rete e l’interfaccia di rete
wireless da usare (se ve ne fosse più di una).
Figura 4.6: Configurazione degli SSID sugli Access Point Cisco
In questo momento si possono definire le politiche di sicurezza della rete: per esempio, per la rete WL-common verrà impostato l’accesso con autenticazione su indirizzo
MAC che sarà controllato sul server RADIUS.
Un’altra impostazione riguarda l’annuncio 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 l’SSID della
rete alla quale associarsi e tentare la connessione: questa impostazione è consigliata
per reti nascoste alle quali deve accedere un ristretto numero di persone che conoscono
il nome della rete.
Definire le politiche di accesso
Dopo aver creato gli SSID, si può fare un riepilogo delle reti create e, soprattuto,
definire con esattezza le restrizioni di accesso e le impostazioni di autenticazione per
ciascuna rete.
Prima di tutto si devono fornire all’access point gli indirizzi dei server RADIUS
per le varie reti. Ad esempio per la rete WL-common la politica di autenticazione
è Open with MAC authentication, cioè 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 fisici delle schede wireless registrate.
La rete wireless INFN-web ha un’autenticazione Open che non richiede altri controlli: l’autenticazione degli utenti per questa rete avviene tramite Captive Portal;
quindi il problema dell’autenticazione viene demandato dall’access 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 è radius.pg.infn.it.
2 si
legga il paragrafo 3.2.1 per maggiori informazioni
termine è usato impropriamente, perché si dovrebbe parlare non di rete, ma di
identificatore per un insieme di servizi, che consistono nell’accesso alla VLAN associata
4 un pacchetto spedito dagli Access Point per far conoscere ai client gli SSID che forniscono
3 questo
65
Terminata la fase di configurazione dei dispositivi, occorre configurare i servizi
della rete.
4.3
Implementazione del progetto TRIP
Per realizzare in concreto il progetto TRIP bisogna installare e configurare alcuni
servizi:
1. Accesso wireless con autenticazione 802.1x
2. server RADIUS con proxying
3. Captive Portal con autenticazione su username/password o certificato digitale
X.509
L’installazione del progetto TRIP deve avvenire dopo aver configurato 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 l’accesso dei dipendenti/associati INFN:
• INFN-web: per l’accesso tramite Captive Portal con certificato digitale o username/password
• INFN-dot1x: per l’accesso cifrato con certificato 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 l’esperienza
dei progettisti e dei sistemisti INFN con tali tecnologie. Il meccanismo delle VPN non
è stato sviluppato nel progetto.
In tutti i casi il server di autorizzazione sarà un server RADIUS, che attualmente
lo standard di fatto nel settore.
4.3.1
Configurazione Access point per 802.1x
La configurazione degli access point per la rete INFN-dot1x è abbastanza laboriosa,
perché garantisce un buon livello di sicurezza mettendo in gioco vari elementi come
l’autenticazione e i certificati digitali.
Come visto nei paragrafi precendeti, abbiamo degli access point configurati per
lavorare con le VLAN, ma non sono state definite ancora le politiche di accesso per la
rete INFN-dot1x che richiede una particolare configurazione.
Configurazione della procedura di autenticazione
Per configurare l’autenticazione con 802.1x per l’SSID 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 nell’immagine 4.7. Senza dimenticarsi
di specificare il server RADIUS al quale delegare l’autenticazione.
Ora bisogna andare nella sezione relativa all’Encryption Manager, che permette di impostare il metodo di cifratura, cioè AES-CCMP+TKIP7 , come mostrato
nell’immagine 4.8.
5 Virtual Private Network, meccanismo di tunnelling di una comunicazione da una rete
verso un’altra
6 per una descrizione del protocollo EAP si veda la sezione relativa nel paragrafo 3.2.2
7 un meccanismo di cifratura che usa l’algoritmo 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: Configurazione dell’autenticazione sugli Access Point Cisco
Figura 4.8: Dettaglio della configurazione dei metodi di cifratura
Configurate queste opzioni basta abilitare la rotazione delle chiavi WPA8 con
l’opzione Broadcast Key Rotation Interval.
Ora è finalmente conclusa la configurazione della procedura di autenticazione
802.1x per la rete INFN-dot1x.
4.3.2
Configurazione Captive portal
In questa fase si deve creare il Captive Portal per l’autenticazione degli utenti della
rete wireless.
Si noti che questa procedura è comune alle reti INFN-web, OPEN e FISICA-web.
Configurazione server web
Il computer sul quale è installato il server web che fa girare i Captive Portal è
privgw.priv che svolge anche il compito di router tra le reti. Il server ha un’interfaccia di rete per ogni VLAN, visto che deve gestire il routing. Per questo motivo si
può configurare il server web per rispondere in modo diverso in base alla rete dalla
quale riceve richieste di accesso.
Tramite il DNS vengono definiti vari alias per il server, uno per ogni rete: quindi
avremo privgw.infnweb.priv, privgw.fisicaweb.priv e privgw.open.priv. Queste scelta è
guidata dal fatto che al primo accesso di un utente, vogliamo che la sua connessione
sia bloccata dal Captive Portal; dopo aver effettuato l’accesso, le connessioni da quel
client saranno fatte passare verso Internet, attraverso il firewall.
Come server web verrà usato Apache 2, versione 2.0.58; questo software permette
di definire varie istanze del server web, detti Virtual Host9 , diversificandoli in base al
nome DNS o all’indirizzo IP. Vengono definiti 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ù di
un sito o servizio
67
portal per le suddette reti.
Per configurare un virtual host basta includere la sua configurazione all’interno del
file di configurazione di Apache /etc/apache2/httpd.conf. Ecco la configurazione del
virtual host per il Captive Portal della rete INFN-web:
<VirtualHost 10.5.0.254:443>
ServerName
tino.infnweb.priv
ServerAdmin
[email protected]
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 soffermarsi troppo sulla sintassi, si può notare subito come venga definito
un virtual host che sta in ascolto sull’interfaccia 10.5.0.254, sulla rete INFN-web, sulla porta 443, cioè quella di http su tunnel cifrato (https10 ). Viene definito il nome
del server, tino.infnweb.priv che sarà un alias sul DNS per privgw.infnweb.priv, l’indirizzo dell’amministratore, e viene attivata la cifratura. Come si vedrà nel paragrafo
successivo, il software per il Captive Portal che è stato scelto è TINO NoCat, ed è
implementato tramite uno script CGI11 in linguaggio Perl.
La cartella di partenza del server web è quella di TINO, in modo che appaia proprio
il Captive Portal come prima pagina a chi accede al server.
A questo punto vanno configurate alcune opzioni che riguardano il controllo del
certificato dell’utente: queste funzioni servono per realizzare l’autenticazione tramite
10 porta speciale che fa passare il solito traffico 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
certificato INFN installato sul browser del client. Il server web chiederà al browser
dell’utente se possiede un certificato digitale: se la risposta è affermativa, il certificato viene trasmesso al server web che lo passerà al Captive Portal perché ne verifichi
la validità (le direttive coinvolte sono SSLVerifyClient, SSLOptions e SSLVerifyDepth).
Dopo aver configurato i file di log del virtual host, va completata la configurazione
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 certificato digitale del server che viene usato per la cifratura del
tunnel;
• SSLCACertificateFile /etc/apache2/ssl/infnca.crt: imposta il certificato
della Certification Authority INFN ed è usato per identificare la CA che ha
firmato il certificato del server.
Con questo la configurazione è quasi terminata; rimane da impostare un’ultima
opzione, che è anche la più importante per un Captive Portal e cioè la Rewrite Rule.
Sotto questo nome va quel meccanismo implementato nei server web che permette
la modifica dell’URL13 inserito dall’utente: nel nostro caso si deve fare in modo che
l’utente, 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, specificare l’indirizzo che va a sostituire quello digitato dall’utente,
con:
RewriteRule ^(.*) https://tino.infnweb.priv/tino.cgi [R=301,QSA,L]
È bene analizzare più a fondo le parti di quest’ultima direttiva:
• RewriteRule: è il nome della direttiva;
^
• (.*):
questa è un’espressione regolare che corrisponde a tutte le stringhe possibili, cioè quelle che iniziano con zero o più caratteri;
• https://tino.infnweb.priv/tino.cgi: questo è l’URL che viene sostituito a
quello digitato dall’utente 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 dell’URL digitato dall’utente.
Al termine della configurazione di Apache abbiamo il server web funzionante,
che visualizza la pagina di login di TINO al primo accesso dell’utente. Agli accessi
successivi la connessione dell’utente non sarà più bloccata dal Captive Portal.
Configurazione Tino
TINO NoCat è stato sviluppato come componente di accesso e autenticazione per la
rete wireless del Campus universitario di Palosaari, Finlandia. È scritto come CGI in
Perl.
Ecco, in alcuni passi, il suo funzionamento:
1. le connessioni vengono redirette alla pagina di login di Tino;
12 Secure
Socket Layer, un protocollo di crittografia che fornisce comunicazioni sicure per i
trasferimenti dati di qualunque tipo su Internet
13 Uniform Resource Locator, un identificatore glovale che permette di riconoscere e recuperare un documento all’interno di Internet; è uno dei concetti chiave del World Wide
Web
69
2. il MAC address dell’utente che accede alla pagina viene ricercato all’interno dei
lease del server DHCP;
3. all’utente viene richiesto il nome utente e la password, oppure, se lo possiede, il
suo certificato digitale;
4. se il login è andato a buon fine, l’indirizzo IP, il MAC address, la data di login e
il nome dell’utente (eventualmente estratto dal certificato) vengono memorizzati
in un file all’interno della directory di spool di Tino;
5. Tino invoca uno script di shell esterno per aprire il firewall alle connessioni
entranti da quell’indirizzo 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 firewall.
La configurazione del software avviene impostando alcune variabili nel file tino.pm
che contiene le funzioni principali dello script CGI. Vediamo alcuni frammenti della
configurazione:
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à i file con le specifiche degli utenti che hanno
effettuato il login
2. il file di log
3. lo script che modifica il firewall per far passare il traffico del client che si è
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à riconoscere come valida per autenticare gli utenti tramite certificati digitali. In questo caso si specifica il Distinguished
Name della CA di INFN. Le stringhe sono due, perché la CA di INFN ha di recente
cambiato nome, perciò va garantito il funzionamento anche dei certificati 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 l’accesso. Prima di tutti va impostato il percorso del file di
lease del DHCP, che contiene le informazioni dell’assegnamento degli indirizzi del
DHCP che vengono dati agli utenti, con l’indicazione dell’indirizzo IP assegnato. Poi
va detto a Tino dove si trova il server di autenticazione e come interagire con esso:
perciò viene indicato il nome del server RADIUS, radius.pg.infn.it, la password di
accesso e il realm di default che sarà appeso al nome utente inserito se non viene
specificato alcun realm (se per esempio tenta l’accesso l’utente [email protected],
non verrà appesa questa stringa, ma se tentasse l’accesso l’utente simone.pascarosa,
allora, prima di essere autenticato dal server RADIUS, la stringa sarebbe trasformata
in [email protected]).
70
Configurazione firewall iptables per NAT e redirezione connessioni
Per effettuare il controllo delle connessioni è stato usato lo strumento iptables 14 .
Non sarà commentata tutta la configurazione del firewall del server, ma solo la
parte relativa al Captive Portal, e in particolare sarà analizzata solo quella della rete
INFN-web, visto che quella delle altre reti con Captive Portal è simile. Il firewall segue
la politica di specificare quali sono le connessioni accettate e di negare tutte le altre
nella maggioranza dei casi.
Quello che verrà configurate sul firewall riguarda:
• accettazione del traffico in ingresso dalla rete INFN-web;
• accettazione del forward del traffico tra le interfacce interne e quelle su rete
pubblica;
• mascheramento con NAT15 degli IP interni.
Per organizzare i filtri, è 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 filter 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 firewall di accettare in ingresso tutte le nuove connessioni verso
il server web, sia in chiaro (porta 80) che cifrate (porta 443). L’ultima 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 traffico che passa attraverso il server, dalla rete
INFN-web verso un’altra rete, quindi anche Internet, nella catena filter 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
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
14 uno
strumento molto potente sotto GNU/Linux per intercettare e manipolare i pacchetti
di rete
15 Network Address Translation, tecnica che permette di riscrivere l’indirizzo IP sorgente e
di destinazione di un pacchetto che attraversa un router per la sua trasmissione su un’altra
rete
71
Impostate le regole di passaggio del traffico, viene definita la traduzione degli
indirizzi della rete INFN-web per andare su Internet. Infatti tutti i portatili di questa
rete usciranno su Internet con l’indirizzo 193.205.222.52. Le due istruzioni creano
la catena nat tino infnweb e la puliscono. La terza istruzione inserisce il traffico 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è quando ancora non è stata presa la decisione di routing sul pacchetto: quello che si vuole
fare infatti è bloccare la prima volta tutte le connessioni in uscita verso Internet,
per obbligarle a passare dall’autenticazione del Captive Portal. Il filtro intercetta i
pacchetti provenienti dalla rete INFN-web (10.5.0.0/16), destinati ad un’altra rete (!
10.5.0.0/16) ed effettua un DNAT, cioè un Destination NAT: in pratica viene cambiato
nell’intestazione IP l’indirizzo dell’host di destinazione, impostando come destinatario
il Captive Portal, che risponde all’indirizzo 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 specificare quale sarà l’indirizzo col quale i portatili verranno identificati su Internet ed usiamo perciò l’indirizzo dell’interfaccia pubblica sulla rete INFN del server (193.205.222.52). La regola infatti effettua il SNAT,
Source NAT, che, dopo che è stata decisa la destinazione del pacchetto e prima che
questo venga effettivamente trasmesso sull’interfaccia di rete giusta (la eth1), modifica l’indirizzo del mittente inserendo quello del server. In questo modo le risposte
ai messaggi trasmessi verranno rispedite al nostro server, che saprà come rispedire il
messaggio al giusto computer della rete interna.
4.3.3
Configurazioni RADIUS
Il server RADIUS utilizzato è FreeRADIUS, erede del più vecchio Cistron RADIUS
server. La configurazione del server RADIUS è molto lunga, perché prevede decine
e decine di moduli, plugin, driver per diversi back-end dai quali leggere i dati di
autenticazione.
I file di configurazione si trovano, di default, sotto la directory /etc/raddb (retaggio del vecchio Cistron): alcuni dei file contenuti in questa cartella sono inutili, ma
vengono mantenuti per retrocompatibilità.
I file più importanti, che verranno commentati sono:
• radiusd.conf: configurazione generale del server, imposta le opzioni di logging,
di sicurezza, il numero di processi da avviare, i driver backend da utilizzare e
i filtri; infine vengono decisi i moduli da utilizzare nelle fasi di Autenticazione,
Autorizzazione e Accounting;
• clients.conf: definisce 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: configurazione delle opzioni EAP, definisce i tipi di autenticazione
ammessi e le loro opzioni;
• proxy.conf: definisce i server che dovranno essere interrogati per i possibili
REALM (domini) che ci aspettiamo di gestire (ad esempio infn.it)
72
• users: definisce le autenticazioni da usare per i vari tipi di utenti e le risposte
da fornire; questo file può essere usato anche per contenere i dati di autenticazione (username/password) in mancanza di un backend più organizzato come
MySQL16 o LDAP.
radiusd.conf
Una prima sezione del file imposta le cartelle dove trovare gli eseguibili e le altre configurazioni, il file 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ù importante è 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 configurazione, per un metodo di autenticazione (come ad esempio
EAP) e per altre funzioni.
Ecco la configurazione 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à 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 filtrare i dati che ci riguardano. L’accesso al backend è protetto da password ed avviene
con le credenziali di amministratore. Il filtro (&(uid=%Stripped-User-Name:-%User-Name)
(PerugiaGroups=radius-infn)) fa selezionare solo l’entry riguardante l’utente che sta
richiedendo l’accesso; l’attributo PerugiaGroups fa parte dello schema personalizzato
che è stato creato e definisce a quale gruppo di utenti appartiene l’utenza: 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 specificare il loro nome utente con una stringa del tipo
[email protected]. La parte di dominio, quella che segue il simbolo @, viene
usata per delegare l’autenticazione ad un server autoritativo per quel dominio.
Per i nostri utenti locali non c’è bisogno del dominio, quindi questa clausola ci
permette di eliminarlo quando si va a cercare l’account all’interno della directory
LDAP.
16 famoso
gestore di database, snello e disponibile con una licenza di software libero
73
clients.conf
In questo file 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è i NAS (nel nostro caso gli Access Point) che vogliono autenticare
i supplicant (i portatili) che tentano l’accesso.
Ecco un estratto del file, 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 definito un nome e il segreto che dovrà 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 è 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 file imposta le opzioni EAP: configura i metodi di cifratura ammessi (nel nostro
caso TTLS) e il tunnelling (EAP-TTLS). In questo file vanno inseriti i percorsi del
certificato digitale del server e del certificato della CA (Certification 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 file vengono impostate le opzioni per la comunicazione con il server RADIUS
proxy e si fanno conoscere al server tutti i realm, cioè 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 specificano la parte di dominio, e DEFAULT, in cui ricadono
tutti gli altri utenti.
In questo modo il server riconosce gli utenti che non specificano parte di dominio
e quelli che specificano [email protected] come utenti propri e li autentica
usando le informazioni contenute nella directory LDAP. L’autenticazione 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 l’uso del server proxy.
75
users
Questo file contiene i profili 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 definiti i comportamenti di default del server per vari tipi
di autenticazione.
La seconda riga, in particolare, definisce il backend sul quale cercare le informazioni
effettive di autenticazione ed autorizzazione; demanda quindi alla directory LDAP la
memorizzazione dei dati
4.4
Configurazione directory LDAP
L’implementazione utilizzata per il server LDAP è OpenLDAP, versione 2.3.30. Configurare una directory LDAP non è un compito banale, perché bisogna avere bene in
testa l’uso che se ne vuole fare, la quantità di dati che dovrà essere contenuta nella
directory e la mole di traffico prevista.
OpenLDAP è stato installato con lo strumento emerge 17 con il comando:
emerge openldap
L’installazione dei binari non richiede quindi particolari opzioni.
4.4.1
Configurazione servizio slapd
A questo punto va configurata la directory: il server LDAP si chiama slapd e va
quindi modificato il file /etc/openldap/slapd.conf.
Verrà commentata ogni sezione del file di configurazione.
Inclusione schemi
La prima parte include gli schemi riconosciuti dal server. In questo modo slapd conosce
la struttura delle entry che conterrà la directory; se si tenta di inserire una entry che
appartiene ad una objectClass 18 sconosciuta, LDAP negherà l’inserimento.
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 definisce la classe di una entry, cioè gli attributi obbligatori e facoltativi
che può contenere
76
Oltre agli schemi standard largamente utilizzati per memorizzare informazioni personali, sono stati aggiunti anche degli schemi che serviranno a memorizzare le configurazioni per i servizi di rete e per rispecchiare meglio le necessità del dipartimento e
di INFN:
• dhcp.schema: contiene le classi per le entry riguardanti le configurazioni del
server DHCP, l’associazione MAC-address/IP-address, le configurazioni per le
varie reti servite ed altre opzioni;
• dlz.schema: contiene le classi per il driver DLZ19 del DNS, che riguarda la
configurazione del server DNS;
• perugia.schema: schema personalizzato realizzato per alcune funzionalità interne;
• authldap.schema: contiene le classi per le entry degli account degli utenti.
Schema PerugiaObject
Andiamo ad analizzare più in dettaglio lo schema personalizzato, per comprenderne
la necessità 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) )
L’attributo PerugiaGroups permette di impostare l’appartenenza di una entry ad
un certo gruppo. Con questo gruppo, ad esempio, si riesce a discriminare, all’interno
del sottoalbero dei contatti degli utenti, quelli appartenenti al Dipartimento di Fisica,
da quelli di INFN. L’attributo è multivalore, infatti spesso una entry appartiene ad uno
o più gruppi: può succedere, ad esempio, che un account debba poter essere utilizzato
sia per accedere al proxy web, sia per l’autenticazione wireless, sia per la posta; questo
attributo viene letto da ciascuno di questi servizi e permette di inserirlo o meno nelle
configurazioni di quel particolare servizio.
L’attributo PerugiaOwner permette di specificare la persona a cui è associata una
certa entry: ad esempio per una entry del DHCP si può specificare chi è il possessore
del computer con quell’indirizzo. Altro utilizzo è 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 configurazioni 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 l’indirizzo IP, con questo sistema si può facilmente
risalire al proprietario per avvertirlo.
Opzioni del server
Successivamente vanno configurate le opzioni del server che riguardano i certificati,
per stabilire sessioni cifrate (TLS, Transport Layer Security), il formato di Hash delle
password e altri parametri di sistema, come si vede sempre nel file 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
Configurazione della directory
In questa sezione viene configurata, finalmente, la directory, dicendo al server quale
albero conterrà e come dovrà 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
suffix dc=priv : questa opzione imposta la radice dell’albero contenuto nella directory; è stato scelto il DN dc=priv, proprio ad identificare la rete come un
dominio privato. Si noti che la radice è anch’essa una entry della directory e per
questo dovrà essere inserita nell’albero
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à read-only
Interfaccia Perl programmabile
Programma esterno (via Shell)
Interfaccia SQL programmabile
Tabella 4.3: Backend disponibili per LDAP
i dati modificati dalle transazioni in seguito ad un guasto); il primo valore indica il limite di dati in kilobyte modificati prima del quale eseguire il checkpoint,
mentre il secondo indica i minuti di ritardo. In questo modo il checkpoint verrà
effettuato 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 dell’utente root e
la sua password specificata tramite l’Hash SSHA20 ; questo utente potrà accedere
alla directory e modificare qualunque entry. Si noti che l’account dell’utente è
una entry della directory, che deve esistere nell’albero
directory /var/lib/openldap-data : questa opzione imposta il percorso nel quale
saranno memorizzati i file della directory, nel formato specifico 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 è scelto di inserire la ricerca sul
campo objectClass perché 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 specifica
che si creano indici per ricerche di uguaglianza e non di verosimiglianza o di
similitudine (verrà 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 )
replogfile /var/openldap/slapd.replog : questa opzione specifica il file di replication log utilizzato dal demone slurpd per comunicare ai server secondari le
modifiche avvenute sulla copia originale
replica uri=ldap://authserver2.fisica.unipg.it:389
binddn=cn=Manager,dc=priv
bindmethod=simple credentials=******* : questa opzione specifica un server
secondario sul quale eseguire la replica: questo server sarà una copia aggiornata
20 versione
potenziata del Secure Hash Algorithm
79
del server originale, ma verrà utilizzata solo per la lettura; le modifiche verranno
effettuate sempre sul master, che avrà cura, tramite questa direttiva, di avvertire
gli altri server, delle modifiche
4.4.2
Inserimento entry per lo startup
Dopo aver configurato la directory LDAP va avviato il servizio. Prima di farlo però
devono essere inserite le entry relative alla radice della directory, dc=priv, e all’utente
amministratore, cn=Manager,dc=priv. Per inserirle basta creare un file LDIF con la
specifica 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 file 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èssere utilizzata appieno la directory LDAP.
4.5
Configurazione repliche LDAP
I server di replica LDAP sono dei server slapd secondari il cui scopo è 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 modifiche avvenute su un database LDAP verso altri server. Se
slapd è configurato per tenere un log di replicazione, slurpd legge questo log e spedisce
le modifiche ai server slave sempre con il protocollo LDAP, come mostrato in figura
4.9.
Figura 4.9: Meccanismo di replica in LDAP
Il funzionamento è molto semplice:
80
• all’avvio slurpd controlla se esiste il file di replica e se ci sono state modifiche 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 file);
• se ci sono state modifiche, slurpd mette un lock sul file di replica, se ne fa una
copia privata, rilascia il lock sul file 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
modifiche.
Configurazione slapd secondari
Ecco una sezione del file di configurazione 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 configurazione è simile a quella del server centrale, visto che i dati che devono
essere memorizzati sono gli stessi. Si può comunque selezionare un backend diverso,
visto che la consistenza dei dati deve essere mantenuta solo a livello semantico, non
serve che i formati fisici di memorizzazione siano gli stessi tra i server.
La clausola updatedn specifica l’utente che può entrare dal server centrale per
effettuare gli aggiornamenti necessari a mantenere la copia locale coerente.
Nel server centrale si dovrà semplicemente avviare il demone slurpd, che leggerà
la configurazione dal file /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 specificati il file di replica nel quale leggere le modifiche alla directory
e l’elenco dei server secondari, in questo caso uno solo, che si aggiorneranno da questa
copia centrale.
4.6
Configurazione DNS e DHCP
Completato il server LDAP, dobbiamo configurare le macchine su cui sono in esecuzione i servizi base della rete per leggere le proprie configurazione dalla directory
LDAP. Si noti che alcuni degli strumenti usati sono molto nuovi e la documentazione
disponibile su Internet è scarna, eccetto alcuni sporadici esempi.
I servizi che vanno configurati con l’accesso 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à come dominio .priv, per
distinguerla dalle reti pubbliche; questo DNS servirà solo ai computer interni
alla rete privata e permetterà l’interrogazione dei DNS di Internet
RADIUS per l’autenticazione degli utenti della rete wireless su MAC-address (questa configurazione è stata analizzata nel paragrafo 4.3.3 per l’accesso su nome utente/password)
4.6.1
Configurazione DHCP
Il server DHCP che è stato utilizzato è il diffusissimo ISC21 DHCP versione 3.0.5.
Purtroppo la versione base del software non supporta la lettura delle configurazioni su
server LDAP, perciò è stato necessario applicare una patch e ricompilare il pacchetto.
La configurazione di un server DHCP è abbastanza semplice, poiché 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 configurazioni sono contenute nella directory LDAP, perciò il file
di configurazione è molto scarno, in quanto contiene solamente i parametri necessari
a collegarsi alla directory e a leggere le entry che interessano.
Andiamo ad analizzare il file di configurazione 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 significato è spiegato dalla sintassi stessa:
• prima di tutto viene specificato l’indirizzo del server LDAP e la porta sulla quale
sta in ascolta cioè la porta 636 del server authserver.fisica.unipg.it
• deve essere specificato poi l’utente col quale collegarsi alla directory, nel nostro
caso è l’amministratore con relativa password
• successivamente viene indicato il sottoalbero; sotto ou=dhcp,dc=priv si troveranno tutte le entry relative alla configurazione del DHCP
• la direttiva ldap-method ammette due valori:
static forza il server a leggere le configurazioni da LDAP all’avvio e in seguito il
server LDAP non verrà più contattato;
dinamic non vengono caricate le configurazioni all’inizio, il server contatta LDAP
per una certa entry solo quando ne ha bisogno (permette di modificare
le configurazioni del DHCP a runtime senza doverlo riavviare ad ogni
modifica);
• il file specificato nella direttiva ldap-debug-file permette di controllare la correttezza delle configurazioni lette da LDAP, infatti su questo file il server DHCP
scrive le configurazioni base che legge allo startup dopo il primo avvio, nello
stesso formato della configurazione stardard dhcpd.conf.
• l’ultima direttiva attiva il tunnel cifrato SSL, per proteggere le comunicazioni
tra server DHCP e LDAP.
21 Internet Systems Consortium, ente senza fini di lucro che sviluppa software e protocolli
fondamentali per il funzionamento della rete Internet
82
Formato configurazioni DHCP nella directory
Le configurazioni del DHCP vengono memorizzate nella directory nel sottoalbero ou=dhcp,dc=priv. La struttura è rappresentata in figura 4.10.
Figura 4.10: Gerarchia delle configurazioni del DHCP su LDAP
Come si vede nella figura, le configurazioni sono separate in due parti: la prima
contiene i dati delle reti servite, con gli indirizzi IP dei client registrati; l’altra contiene
le eventuali opzioni del server.
Le classi di oggetto delle entry che riguardano le configurazioni sono contenute nel
file 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 è autoritativo per le reti che
serve
dhcpSubnet contiene la specifica di una rete servita dal DHCP, il suo indirizzo, la
maschera di rete ecc.
dhcpOptions classe che permette di aggiungere espressività alle entry del DHCP: al
suo interno si possono inserire le stesse direttive che vengono usate dal formato
standard del file dhcpd.conf, come quelle per definire il router di default e i server
DNS
dhcpHost contiene i dati riguardanti un computer, che sono l’indirizzo Ethernet della
scheda di rete (il MAC-address) e l’indirizzo IP assegnato
dhcpServer crea istanze del server DHCP e permette di far condividere la stessa
configurazione a più server: nel nostro caso c’è un solo server DHCP, perciò una
sola entry per questa classe
Andiamo ad analizzare un frammento della directory riguardante le configurazioni
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à dei dati di configurazione, scaduto il quale il client dovrà 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 dell’ultima entry del listato, che
permette di specificare il proprietario del computer. Il valore contenuto corrisponde
al CN (common name) dell’utente, 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ò risalire in modo veloce al proprietario di un certo computer.
4.6.2
Configurazione DNS
Il server DNS utilizzato è ISC Bind, versione 9.4.1. Anche questo server, come per
il DHCP, ha bisogno di una patch per leggere le configurazioni 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ò l’installazione
può 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 configurazioni da un qualunque database allo stesse
modo già visto per DHCP su LDAP. Viene fornito come patch ai sorgenti di Bind.
DLZ permette di leggere le configurazioni da database MySQL, PostgreSQL, Berkeley DB, ODBC e naturalmente LDAP.
La configurazione usuale di un server DNS prevede la creazione di file di zona, che
contengano le configurazioni per i domini serviti dal DNS e al loro interno vengono
specificate le associazioni nome-a-dominio/indirizzo-IP ed altri nomi di servizio. La
struttura che verrà realizzata a livello di domini è riportata nella figura 4.11.
Figura 4.11: Domini della rete privata
Il file di configurazione principale del server dns è /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é cambiano raramente, cioè i root server di Internet)
• gli indirizzi sui quali il server sta in ascolto: va specificata una interfaccia per
ogni sottorete diversa (per ogni VLAN)
• le reti dalle quali accettare richieste
Successivamente viene fatto l’elenco 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 file /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.
Infine va detto a Bind di caricare le zone e le configurazioni 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 configurazione LDAP del DNS, sebbene gerarchica, similmente a quella del
DHCP, rispetta il vecchio meccanismo dei record delle configurazioni canoniche del
DNS. Si avrà sempre la suddivisione in zone e all’interno 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
significato delle righe contenute in questa sezione, notando che la specifica consiste
nella sola direttiva database, seguita da una lunga serie di opzioni:
• la prima riga contiene la specifica 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 configurazioni) e l’indirizzo IP del server LDAP;
• la seconda riga è la query LDAP che seleziona le entry delle zone DNS all’interno 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 è 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 è 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;
• l’ultima riga è di supporto alla precedente per l’utilizzo 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 l’entry cercata, viene restituito
tutto il sottoalbero ad essa associato, che contiene le configurazioni nel formato classico
dei record DNS, con indirizzo IP e nome a dominio.
Formato configurazioni DNS nella directory
Le configurazioni del DHCP vengono memorizzate nella directory nel sottoalbero ou=dns,dc=priv. La struttura è rappresentata in figura 4.12.
Figura 4.12: Gerarchia delle configurazioni del DNS su LDAP
Come si vede nella figura, le configurazioni sono fortemente gerarchiche e vi si
trovano:
• entry per la memorizzazione delle zone, che identificano 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: identificano un host e lo pongono come
radice del sottoalbero contenente i dati di quell’host (appartengono alla classe
dlzHost); anche il SOA, identificato con il carattere @, viene visto come un host;
• entry per la memorizzazione effettiva dei dati, relativi ai record della zona:
contengono l’indirizzo 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à 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 definire degli alias (CNAME) che non si inseriscono
bene in questa struttura.
24 record che specifica il server DNS che contiene le informazioni autoritative per un dominio, l’email dell’amministratore, il numero seriale della zona e alcune tempificazioni per gli
aggiornamenti delle zone
87
L’artificio introdotto da DLZ è di considerare ogni cosa come un host (anche il record
SOA e un nome CNAME) e al suo interno inserire l’entry con la configurazione 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 dell’host 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 dell’alias tino.infnweb.priv
#per l’host 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 l’ID del record, quello identificato dal campo dlzRecordID. Questo codice
rappresenta la sequenza del record come se ci trovassimo all’interno di un file 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 figura 4.12, mantenendo la sequenzialità con il campo ID.
Per assegnare gli ID abbiamo usato parte dell’indirizzo IP per ricavare un identificatore unico all’interno della zona: dato che le zone contengono indirizzi IP all’interno
della classe 10.X.0.0/16, utilizziamo gli ultimi due byte dell’indirizzo per calcolare l’ID.
Siano a3 e a4 gli ultimi due byte dell’indirizzo IP, allora
ID = a3 · 256 + a4
Quindi ad esempio il record che riguarda l’indirizzo IP 10.2.3.125 avrà come ID =
3 · 256 + 125 = 839.
Il record 1 di ogni zona è 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
Configurazione delle macchine virtuali
Xen, come già descritto nel paragrafo 3.6.1, è un monitor di macchine virtuali (o
hypervisor) che realizza paravirtualizzazione su architetture x86. Permette di eseguire
più macchine virtuali sullo stesso sistema fisico con performance molto buone. Ecco
alcune delle caratteristiche che contraddistinguono Xen dagli altri monitor di macchine
virtuali:
• performance molto simili a quelle dell’accesso diretto all’hardware;
• migrazione live delle macchine virtuali a run-time tra host fisici diversi;
• supporto fino a 32 CPU virtuali per sistema ospite;
• supporto per le piattaforme x86 a 32 e 64 bit;
4.7.1
Installazione di Xen
L’installazione di Xen su piattaforma Gentoo GNU/Linux 2007.0 è 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 dell’installazione:
• Compilazione dell’hypervisor (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
• Configurazione del bootloader per avviare Xen (l’hypervisor) che poi avvierà 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 è
ancora più specifico sulle configurazioni da impostare per la sua installazione.
Prima di tutto dobbiamo selezionare l’ultimo profilo 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ù 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 è implementata in un modo che va in conflitto 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 flag di compilazione -mno-tlsdirect-seg-refs al sistema in /etc/make.conf tra i flag di compilazione C:
25 Native POSIX Thread Library (NPTL) è una componente software che abilita il kernel
Linux a far girare in modo efficiente 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 flag -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 l’hypervisor e le applicazioni di gestione delle
macchine virtuali, con il comando:
emerge -av app-emulation/xen app-emulation/xen-tools
L’hypervisor consiste in un binario (/boot/xen.gz ) che verrà 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ò 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ù importanti da includere nel kernel, in modo statico e non come
moduli, sono:
• Enable Xen compatible kernel: abilita il kernel all’uso 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 configurato il bootloader26 perché 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 file di configurazione /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 è quello appena creato, ma è l’hypervisor
di Xen che si sostituisce al kernel del dom0 nelle fasi di inizializzazione dell’ambiente
per Xen. L’hypervisor procederà poi ad avviare il kernel del dom0 specificato nella
direttiva module.
Terminata questa fase, va soltanto riavviato il sistema.
4.7.2
Configurazione 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 filesystem
• configurare 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 l’hardware. Si può usare la stessa configurazione del dom0,
cambiando solo le opzioni specifiche di Xen e in particolare:
• Enable Xen compatible kernel: abilita il kernel all’uso 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 filesystem
Ora che abbiamo un kernel, va creata un’immagine per il filesystem del sistema operativo del domU. Fortunatamente esistono su Internet dei siti27 che mettono a disposizione dei file contenenti l’immagine di un filesystem con installata una distribuzione
GNU/Linux funzionante, nel nostro caso Debian GNU/Linux. Questo file verrà usato
come filesystem di riferimento per il domU che andiamo a creare.
Configurazione della macchina virtuale
La configurazione di un domU va scritta su un file che verrà usato dal comando xm.
Ecco il file di configurazione 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 è molto comprensibile. Le opzioni da configurare 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 identificativo;
• vif: l’interfaccia di rete da esportare al domU come eth0, in questo caso viene
usato un bridge 28 ;
• disk: la specifica dei filesystem esportati alla macchina virtual, nel formato
’percorso filesystem, nome filesystem nel domU, diritti di accesso’; si noti che
come percorso del filesystem si può specificare una partizione disco reale, una
partizione logica (come nel primo caso, con EVMS) o un file su disco (come nel
secondo caso come partizione di swap);
• root: il filesystem da avviare come root filesystem per il domU (uno di quelli
appena definiti).
Terminata la configurazione 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 file /xen/virtual1.conf,
che contiene la configurazione riportata in precedenza.
L’opzione -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 configurare
l’interfaccia di rete della nuova macchina ed installare il software necessario ai servizi
che deve ospitare.
4.8
Configurazione router e firewall
Il router di frontiera costituisce uno dei punti più critici della rete, perché deve
provvedere sia allo smistamento del traffico della rete interna verso Internet (tramite
due link separati del Dipartimento di Fisica e di INFN, come mostrato nella figura
1.1) che alla gestione dell’autenticazione degli utenti delle reti wireless con il Captive
Portal, nonché al filtraggio dei pacchetti (firewalling).
Il router è 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 fisica, configurata per
avere una interfaccia di rete logica per ogni rete VLAN definita nella struttura. In
questo modo si riesce a simulare un router professionale con diverse interfacce di rete.
Il computer in questione è privgw.priv. La struttura logica dei collegamenti è mostrata
in figura 4.13 (in verde sono rappresentate le reti di Fisica, in blu quelle di INFN).
Per implementare le politiche di firewalling e di routing verranno usati rispettivamente iptables e iproute2.
All’interno della configurazione del firewall 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 flag NEW dell’intestazione TCP) si decide se accettare o meno quel traffico. Successivamente tutti i
pacchetti relativi a quella connessione subiranno lo stesso destino del pacchetto iniziale;
in sostanza, se il firewall decide di far passare il pacchetto iniziale di una connessione,
tutto lo stream di dati appartenente a quella connessione viene fatto passare.
Ecco la configurazione:
28 un ponte virtuale, che mette in comunicazione l’interfaccia virtuale collegata al domU con
l’interfaccia 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 definiscono una catena, keep state, che accetta i pacchetti relativi
ad una connessione già iniziata. In questo modo, nelle altre regole del firewall dovremo
preoccuparci di far passare solo il pacchetto iniziale di una connessione.
Passaggio di traffico tra le reti
Come detto più volte, le reti VLAN della nostra struttura non hanno comunicazione
diretta tra loro. Il router ha delle regole che impediscono il passaggio del traffico 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à di contattare altri computer per avere
accesso alla rete.
I server RADIUS ed LDAP, che devono essere trasparenti agli utenti, hanno un’interfaccia di rete sulla rete VLAN di controllo, quella con VLAN ID 1, alla quale non
si può associare nessun client.
Questa rete permette agli amministratori di creare una sorta di limite invalicabile
al quale nessun computer può accedere: l’unico nodo che ha il permesso di interrogare
i servizi su questa rete, oltre alle postazioni degli amministratori, è proprio il router
privgw.priv che implementa i metodi di autenticazione verso gli utenti e che legge dal
server LDAP le configurazioni di DHCP e DNS.
All’interno di iptables quindi vanno specificate 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à riportata la configurazione del firewall riguardante il
Captive Portal, perché questa è stata già analizzata nel paragrafo 4.3.2.
Passaggio del traffico verso Internet
Il traffico 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 firewall di far passare il traffico 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
L’ultima istruzione memorizza nel log la registrazione del traffico in transito sulla
rete.
Network Address Translation
Prima di far passare il traffico dei nodi della rete nascosta su Internet, si deve provvedere
a modificare il loro indirizzo IP: non si può spedire sul Internet un pacchetto con un
indirizzo come 10.2.32.4, perché non si riceverà risposta, visto che la classe 10.0.0.0 è
riservata alle reti private.
Per questo vanno tradotti gli indirizzi dei client con l’indirizzo dell’interfaccia pubblica su Internet del router. In questo caso ci sono due interfacce di rete pubbliche su
Internet e vanno specificate 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à essere
modificato l’indirizzo del mittente in 141.250.2.11; ai pacchetti che devono essere per la
scheda eth1, quella sulla rete di INFN, dovrà essere modificato l’indirizzo del mittente
in 193.205.222.52.
Iproute per smistare il traffico
Grazie allo strumento iproute 29 , sempre incluso in GNU/Linux, si possono definire
delle tabelle di routing per smistare il traffico verso le due reti di Fisica e di INFN.
Prima di tutto vanno definite 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 traffico 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à dei due link: in questo modo si potrebbe decidere
di mandare alcuni flussi di traffico su entrambi i link per massimizzare la velocità di
comunicazione, evitando di intasare uno dei due collegamenti (questa funzione è stata
prevista per eventualità future).
Con queste tabelle, si può decidere, per ogni rete nascosta definita nella struttura,
verso quale delle due reti deve passare il traffico 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 definiscono la tabella di routing da usare per ogni rete, il che
definisce di conseguenza l’interfaccia di rete dalla quale il pacchetto sarà trasmesso
verso Internet (si veda l’immagine 4.13 per la struttura dei link).
4.9
Uso di interfacce grafiche per la gestione del
sistema
La centralizzazione delle configurazioni sulla directory LDAP permette di interagire in
modo veloce ed integrato con tutti i servizi critici della rete. La forza della struttura
risiede principalmente nell’integrazione dei servizi e nelle relazioni che si riescono a
stabilire all’interno della directory tra le varie entry.
Per manipolare questa mole di dati, si è resa necessaria la ricerca di strumenti,
anche grafici, che permettessero di inserire, cancellare e modificare i dati relativi a
tutti i servizi di rete.
phpLDAPadmin
La ricerca è approdata sul software phpLDAPadmin, un’interfaccia web scritta in
linguaggio PHP30 che interagisce con il server LDAP.
L’interfaccia di phpLDAPadmin facilita la manipolazione dei dati, grazie alla possibilità di visualizzare i dati in modo gerarchico e di poter modificare ogni singolo
valore con delle schermate intuitive ed immediate.
Il collegamento dell’interfaccia web alla directory LDAP è molto facile e richiede
la semplice modifica di un file di configurazione.
Vediamo alcune schermate per spiegare il funzionamento dell’interfaccia.
Nell’immagine 4.14 viene visualizzata l’interfaccia del programma phpLDAPadmin
all’interno 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 figura 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: Definizione degli attributi di una entry con phpLDAPadmin
Nell’immagine 4.16 si vede come si può modificare la homeDirectory dell’utente o
altre informazioni che lo riguardano semplicemente inserendo il nuovo valore all’interno
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à di integrazione dei dati presenti nella directory, abbiamo sviluppato
un tool, chiamato LDAPaccess, che permette di creare al volo le configurazioni per
un nuovo portatile o un nuovo desktop o per un nuovo account per la rete wireless.
Con questa stessa interfaccia si può anche avere immediatamente l’elenco delle configurazioni 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 un’inserimento massiccia dei dati),
l’aggiunta dei dati sulla directory LDAP non sarà molto frequente (possiamo
stimare di dover fare non più di una decina di operazioni al giorno); per questo
motivo non c’è bisogno di un meccanismo automatizzato che preveda, ad esempio, che gli utenti stessi sottomettano le modifiche alla directory e poi l’amministratore autorizzi quelle necessarie. Per questo motivo LDAPaccess permette di
aggiungere facilmente un nuovo account o un nuovo portatile alla rete in pochi
secondi, con un’interfaccia gradevole ed intuitiva.
• dall’altra parte non sarebbe stato pensabile modificare la directory direttamente con phpLDAPadmin, perché, come già 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é conosce già
la struttura della rete e quindi riempe automaticamente i campi necessari: se
dovessi inserire a mano le configurazioni 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 è scritto in linguaggio PHP ed è 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.
L’idea alla base del programma è quella di fornire uno strumento veloce e flessibile
per l’aggiunta di dati alla directory LDAP. Naturalmente, se si devono effettuare delle
modifiche 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 l’integrità delle relazioni che si creano
all’interno della directory, come quelle che riguardano il proprietario di un computer;
cosa che in phpLDAPadmin non appare evidente.
L’immagine 4.17 presenta la struttura del programma.
La cartella principale del programma contiene due sottocartelle: conf che contiene i file di configurazione del programma (riportati in verde nell’immagine) e pics
che contiene alcune immagini usate per l’interfaccia grafica. I file di configurazione
permettono di specificare le relazioni tra gli attributi inseriti nelle form HTML del
programma e gli attributi della directory LDAP.
Gli altri file del programma possono essere divisi in 3 categorie:
1. file di interfaccia (riportati in rosso nell’immagine): pagine che vengono richiamate direttamente dall’amministratore e che forniscono un’interfaccia grafica
per l’inserimento, la modifica e la visualizzazione dei dati;
99
Figura 4.17: Strutturazione dei file del programma LDAPaccess
2. file di libreria (riportati in blu nell’immagine): moduli PHP che forniscono le
funzioni di basso livello per l’accesso ai dati contenuti nella directory (in particolare il file read conf.php realizza il vero e proprio collegamento alla directory
e la creazione degli oggetti necessari per la lettura dei dati);
3. file di stile: il solo file general.css che definisce lo stile grafico di formattazione
delle pagine HTML con il linguaggio CSS32
Utilizzo di LDAPaccess
Come si vede nella figura 4.18, si possono creare tutte le configurazioni necessarie per
la registrazione di un portatile inserendo i valori di alcuni attributi, come il nome
del proprietario, l’indirizzo MAC della scheda di rete e l’indirizzo IP da assegnare al
portatile, presenti nella tabella di sinistra che riporta l’ultimo indirizzo disponibile per
ogni rete. Si può scegliere la rete a cui verrà collegato il computer tramite il menù a
tendina Sottorete.
Terminato l’inserimento dei valori, viene fornito il risultato delle entry LDAP necessarie per la registrazione di questi dati: le entry sono specificate in formato LDIF.
L’output è quindi una pagina HTML (come mostrata nella figura 4.19) contenente il
file LDIF che va inserito nella directory.
Questo passaggio dall’output 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ò essere copiato ed importato all’interno della directory
LDAP.
32 Cascading StyleSheet, linguaggio per la descrizione della presentazione di un documento
scritto in un linguaggio di marcatura come l’HTML
100
Figura 4.18: Aggiunta di un nuovo computer portatile con LDAPaccess
Figura 4.19: LDIF per la registrazione di un nuovo computer portatile
L’interfaccia permette di cercare il proprietario di un computer, ad esempio inserendo il MAC address di un suo portatile.
Si può inoltre visualizzare il dettaglio di tutti i dispositivi posseduti da un utente
con i dati più importanti selezionando l’utente da un menù a tendina o ricercandolo
all’interno della directory: il risultato che si ottiene è visualizzato in figura 4.20.
101
Figura 4.20: Dettaglio dei computer posseduti da un utente con LDAPAccess
102
Capitolo 5
Migrazione
La migrazione è una fase molto delicata per il completamento dell’installazione della
nuova struttura di rete del dipartimento. Sebbene si possa riuscire a non influenzare le
funzionalità delle postazioni degli utenti quando si lavora sulla struttura di dorsale e sui
servizi che entreranno in funzione, non si può 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 è preferito installare una rete separata,
con dispositivi propri, per mantenere la vecchia struttura fino al complementamento
dell’installazione: in questo modo si possono migrare gradualmente gli utenti sulla
nuova rete. È da ricordare che il dipartimento ospita più di 200 persone, afferenti
a diversi enti. Si deve tenere in considerazione che spesso i dipendenti si trovano a
lavorare fuori dall’edificio (spesso all’estero) 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 l’effettiva migrazione delle utenze ha riguardato il passaggio dei
portatili in rete wireless. La migrazione, ancora in fase di completamento, prevede
che l’amministratore di sistema mandi una comunicazione, preferibilmente per email,
all’interessato, specificando 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ù utilizzati o che sono stati dismessi.
Si è scelto di effettuare 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 è partiti dall’ultimo piano, a
scendere.
In media si può calcolare che per migrare tutti gli account della rete wireless di un
piano dell’edifico c’è bisogno di circa 2 settimane di tempo: questa attesa è giustificata
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é alcuni minuti.
Migrazione degli account della rete cablata
La migrazione degli account della rete cablata verrà effettuato nei prossimi mesi. Alcuni uffici sono stati già migrati alla nuova struttura e sono serviti da test per provare
l’efficacia della rete ed eventuali problemi non previsti in fase di progettazione.
I primi che sono stati passati sotto rete nascosta sono stati gli utenti dell’officina
meccanica del dipartimento (che ospita sia dipendenti del Dipartimento di Fisica,
che dell’INFN). Qui abbiamo uno switch configurato per la nuova rete, quindi con le
VLAN. Quello che va fatto per configurare una postazione fissa è conoscere la porta
dello switch alla quale è collegata e configurare 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 nell’edificio 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, è l’abitudine degli utenti del
dipartimento ad avere un indirizzo di rete pubblico su Intenrnet; questo ha portato
l’utente ad abituarsi a poter accedere al computer del proprio ufficio da qualunque
postazione connessa ad Internet. Come si è visto, la nuova rete impedisce questo
accesso diretto perché 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 d’ufficio da Internet, previa autenticazione.
104
Capitolo 6
Conclusioni
Questa tesi ha esposto, sinteticamente, il lavoro svolto durante quest’anno. Sicuramente la parte più impegnativa è stata lo studio delle varie tecnologie necessarie:
alcune di queste facevano già parte del mio bagaglio culturale universitario, ma molte
altre le ho dovute studiare ex-novo, con non poche difficoltà.
Oltre allo studio, anche la configurazione e l’implementazione dei servizi ha richiesto
molto impegno, vista la scarsa documentazione disponibile per alcuni strumenti. Per
centralizzare i servizi su LDAP è stato necessario uno sforzo non indifferente: la fase
di test ha preso un tempo considerevole sempre per la mancanza di documentazione.
Finalmente adesso il Dipartimento di Fisica e l’INFN hanno un’architettura di rete
flessibile ed unica. Flessibile perché, come si è visto, si possono creare nuove reti e
nuove servizi senza troppe difficolta, aiutati anche da una struttura di autenticazione
integrata. Unica perché non ci sono più due reti indipendenti, ma un’unica infrastruttura condivisa che può essere partizionata arbitrariamente per rispondere alle necessità
degli enti.
Questa flessibilità garantirà una lunga esistenza all’infrastruttura nel futuro. Se in
futuro si creeranno nuovi laboratori o si vorranno allargare quelli già esistenti, magari
spostandoli su piani diversi dell’edificio, l’infrastruttura potrà accogliere queste novità
con modifiche minime alle configurazioni odierne.
La centralizzazione delle configurazioni dà la libertà di creare copie multiple di
un server molto facilmente; questo permetterà sempre più l’innalzamento dei livelli di
disponibilità dei servizi.
L’infrastruttura di autenticazione, sempre basata sul servizio LDAP, faciliterà il
deployment di nuovi servizi e nuove tecnologie. Già oggi si potrebbe pensare di integrare l’autenticazione con i servizi di segreteria sia del dipartimento che dell’INFN,
per mantenere sempre aggiornati i dati sul personale.
In conclusione si può 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 l’opportunità 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à mi hanno fatto crescere molto; ringrazio tutti coloro che
ho conosciuto e con i quali ho condiviso quest’esperienza 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ù belli della Bibbia:
Vi esorto dunque, fratelli, per la misericordia di Dio, ad offrire i vostri corpi come
sacrificio vivente, santo e gradito a Dio; è questo il vostro culto spirituale. Non
conformatevi alla mentalità di questo secolo, ma trasformatevi rinnovando la vostra
mente, per poter discernere la volontà di Dio, ciò che è buono, a lui gradito e perfetto
Romani 12, 1-2
107
108
Bibliografia
[1] Sito ufficiale 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 l’8/12/1998, pagina 14
e 15
[3] Riccardo Veraldi, TRIP - Implementazione Tecnica, del 8/5/2006, sul sito:
http://security.fi.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 Ufficiale 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 Ufficiale di Bind DLZ: http://bind-dlz.sourceforge.net/
109