INDICE - Linux.it

Transcript

INDICE - Linux.it

INDICE
Introduzione
3
1. Reti wireless
5
1.1 Generalità sulle reti wireless
5
1.2 Il mezzo trasmissvo
6
1.3 La tecnologia Wireless Lan
6
1.4 Protocollo d’accesso al mezzo
8
2. Sicurezza nella comunicazione
11
2.1 Tipologia d’attacchi
11
2.2 Segretezza, autenticazione ed integrità
12
2.3 La crittografia
12
2.4 Sistema a chiave simmetrica
13
2.5 Sistema a chiave pubblica
14
2.6 Firma digitale
15
2.7 Digest del messaggio
16
2.8 Certificazione
16
3. WEP
19
3.1 Crittografia WEP
19
3.2 Protezione base della rete wireless
20
3.3 Auditing
23
4. IEEE 802.1X
25
4.1 Lostandard 802.1x
25
4.2 Protocollo EAP
26
4.3 Funzionamento EAP-TLS
28
1
2
5.WPA
31
5.1Funzionamento del WPA
31
5.2 Crittografia nel WPA
34
5.3Problemi del WPA
35
6.Progetto TLS
37
6.1Utilizzo del Radius server
37
6.2Configurazione del progetto TLS
39
6.3Configurazione Access Piont
47
6.4Configurazione supplicant per TLS
50
7. Progetto TTLS
55
7.1Configurazione del TTLS
55
7.2Configurazione supplicant per TTLS
62
8. Supplicant per Linux
69
8.1Wpa_supplicant
69
8.2Configurazione wpa_supplicant
72
Conclusioni
77
Bibliografia
79
Appendice
81
INTRODUZIONE
Questo testo s’impegna a descrivere la tecnologia e la struttura che
caratterizza la rete wireless, partendo inizialmente dalle generalità più
comuni, sino ad arrivare a toccare le peculiarità più importanti che
costituiscono questo tipo di rete.
Il wireless, che oggi ha raggiunto un grand successo, possiede molti
vantaggi ma anche un grosso problema: la vulnerabilità; a questo
proposito nel secondo capitolo ci si occuperà appunto della sicurezza
nella comunicazione.
Inoltre nel trezo capitolo viene trattata una tecnica di crittografia
chiamata WEP, oggi ritenuta abbastanza obsoleta in quanto molto
debole e facilmente aggirabile da un eventuale aggressore.
Successivamente sono elencati alcuni tra i più comuni metodi di base
per consentire una semplice protezione della propria rete wireless
senza utilizzare sistemi particolari.
Ovviamente la sicurezza raggiunta con questi semplici metodi, non è
sicuramente l’ideale per aziende in cui la protezione dei propri dati è
un’esigenza basilare; per sopperire a questa mancanza sono stati creati
vari protocolli come l’802.1x ed il WPA.
Lo standard 802.1x è stato sviluppato per permettere l’autenticazione
e l’autorizzazione nella rete wireless; esso si appoggia ad un altro
protocollo chiamato EAP che si suddivide in diversi metodi
d’autenticazione, tra cui l’EAP-TLS ed EAP-TTLS, entrambi
implementati nel progetto.
Nel capitolo cinque è descritto il WPA; un protocollo creato per
colmare le lacune dovute dal WEP ed inoltre richiede che un utente si
autentichi prima di accedere alla rete.
Tale operazione è consentita in quanto il WPA è integrato in maniera
ottimale con lo standard 802.1x.
3
In seguito, nel capitolo sesto, viene introdotto un componente molto
importante per questa struttura, il Radius server, una sorta di
magazzino
centrale
contenente
tutte
le
informazione
per
l’autenticazione e l’autorizzazione degli utenti che possono accedere
alla rete.
Continuando viene poi descritta la configurazione dell’EAP-TLS
effettuata nel progetto; il metodo d’autenticazione TLS è basato
principalmente su una “mutual authentication”, cioè sia il server che
l’utente (detto supplicant), devono reciprocamente autenticarsi tramite
i propri certificati x.509.
Il metodo EAP-TLS assicura una sicurezza ottimale, l’unico problema
legato a quest’implementazione è la necessità da parte d’ogni utente
d’avere in possesso un certificato x.509; per ovviare a questo
inconveniente ho deciso di trasformare il progetto in un EAP-TTLS.
A differenza della tecnica precedente, il TTLS consente un
autenticazione basata sul certificato solo da parte del server, il
supplicant invece s’identificherà tramite un altro metodo sempre
appartenente alla famiglia EAP; nel mio caso mi sono servito
dell’EAP-MD5, che consente l’autenticazione tramite lo username e
la password.
Sino a questa parte di progetto ho configurato solo macchine utente
con sistema operativo Windows, ma per poter ampliare il progetto ho
deciso d’implementare un supplicant anche in un sistema operativo
Linux, per questo nel capitolo otto è rappresentata la configurazione
di un software Open Source chiamato wpa_supplicant.
4
1. RETI WIRELESS
1.1 Generalità sulle reti wireless
L’implementazione di una rete senza fili è detta rete wireless, se la
struttura è locale allora è detta “wlan” (Wireless Lan).
La necessità di copertura in ambienti difficili da raggiungere tramite
cavi ha favorito lo sviluppo della tecnologia wireless; esistono diverse
tecniche per la trasmissione via etere come il GPRS, il Bluetooth e
802.11, detta anche Wireless Ethernet o Wi-Fi (Wireless Fidelty).
Le prime implementazione delle reti wireless risalgono a circa 20 anni
or sono ma fino a qualche anno fa le Lan Wireless effettivamente
implementate erano veramente poche.
I motivi di questa carenza erano: la scarsa velocità di trasmissione,
che risultava inferiore alle reti standard, il costo che era di molto
superiore a quello delle reti cablate, la scarsa o quasi assente
protezione offerta e per ultimo la mancanza d’interoperabilità dei
dispositivi wireless con quelli della rete cablata.
Oggi la diffusione di queste reti è notevolmente aumentata all’interno
d’aziende e utenze private grazie a costi ridotti, velocità di
trasmissione di 11 Mbps o 54Mbps, maggiore flessibilità, protezione e
semplicità nel cablaggio poiché non c’è bisogno di tirare cavi,
montare canaline e armadi di cablaggio.
Cambiando poi la posizione di una postazione di lavoro non è
necessario
effettuare
alcuna
modifica
sui
dispositivi
d’interconnessione ed ovviamente esiste la possibilità di realizzare
una rete mista aggiungendo ad una rete cablate una wlan.
5
1.2 Il mezzo trasmissivo
Le reti wireless per trasmettere i dati possono usare onde
elettromagnetiche di vario tipo:
• onde radio
• raggi infrarossi
• microonde a 2,4 GHz, usate anche da telefoni cellulari
• microonde a 5 GHz, frequenza con cui trasmettono i satelliti.
La frequenza è la caratteristica principale di un’onda elettromagnetica,
se la frequenza è bassa l’onda è lunga, viceversa se la frequenza è alta
l’onda è corta.[11]
1.3 La tecnologia Wireless Lan
La tecnologia wireless più diffusa è lo standard 802.11, la cui
specifica 802.11b (conosciuta anche come 802.11 High Rate, Wireless
Ethernet o Wi-Fi) ha permesso il gran successo di queste reti, inoltre
grazie a tale rettifica al protocollo originale, la wireless Lan è vista
come una rete Ethernet tradizionale.
Lo standard 802.11 definisce lo strato fisico e lo strato d’accesso al
mezzo (media access control, MAC) per una rete d’area locale senza
fili.
Sono definiti diversi strati fisici per Lan 802.11 che differiscono tra
loro per frequenza (2.4GHz e 5GHz) e velocità di trasmissione
(11Mb/s per 802.11b e 54 Mb/s per 802.11a e 802.11g).
La velocità di trasmissione effettiva della singola connessione è
funzione della potenza del segnale wireless ricevuto e del numero di
utenti che utilizzano contemporaneamente la stessa rete.
La copertura del segnale WLAN varia da poche decine di metri fino
ad alcuni chilometri a seconda della tipologia d’ambiente (ostacoli,
altezza, angolo di trasmissione, ecc.) e dal protocollo utilizzato.[10]
6
Lo standard IEEE 802.11 prevede due possibilità: reti strutturate e reti
ad-hoc.
Il principale blocco della rete strutturata è la cella o conosciuta come
set di servizio di base (Basic Service Set, BSS), quest’ultimo
al suo interno contiene una o più stazioni di lavoro senza cavi e una
stazione di base centrale detto punto d’accesso (access point, AP).
Più AP possono essere collegati tra loro grazie ad un’Ethernet cablata
o tramite un canale senza fili per formare così un sistema di
distribuzione (distribution system, DS).
Una caratteristica importante è che il DS è visto dal protocollo dello
strato superiore, come per esempio dal protocollo IP, come una
singola rete 802.
Quando un dispositivo wireless 802.11 vuole accedere in una BSS,
deve ottenere delle informazioni di sincronizzazione da un punto
d’accesso (o da un'altra stazione se operante in una rete ad-hoc) per
assicurarsi che tutte le stazioni operino con gli stessi parametri.
Queste informazioni possono essere ricavate in due modi:
• Scansione passiva: la stazione attende che arrivi dal punto
d’accesso il pacchetto di sincronizzazione (Beacon Frame,
inviati a intervalli regolari).
• Scansione attiva: la stazione tenta di localizzare un punto
d’accesso e invia dei pacchetti sonda (probe packets) nell’attesa
di una risposta dall’AP.
Il pacchetto di sincronizzazione contiene informazioni per il livello
fisico, come la sequenza per il salto di frequenza, il clock del punto
d’accesso e l’identificativo della BSS (SSID), che viene trasmesso
solitamente in broadcast e in chiaro.
7
Se il sistema è aperto il punto d’accesso accetterà la connessione da
qualsiasi nodo con una SSID vuota o impostata su any, nel caso
invece che il sistema sia chiuso, il punto d’accesso rifiuterà ogni
connessione da nodi con il SSID impostato non corretto.
Una variante importante è che le stazioni possono anche raggrupparsi
e formare una rete ad hoc, vale a dire una rete senza controllo centrale
e senza connessione con il mondo esterno.
Questa rete viene creata spontaneamente soltanto per il motivo che
diverse stazioni si sono trovate in prossimità tra loro con il comune
bisogno di comunicare, un esempio più pratico potrebbe essere
quando un gruppo di persone s’incontrano e vogliono scambiarsi dati
senza un AP centralizzato.[11]
1.4 Protocollo d’accesso al mezzo
Le stazioni senza fili fisse o mobili e la stazione centrale comunicano
tra loro grazie al protocollo d’accesso al mezzo MAC, che serve anche
a coordinare il loro accesso e uso del mezzo di comunicazione
condiviso, che in questo caso è la radiofrequenza.
Il protocollo MAC è un protocollo d’accesso multiplo con rivelazione
del portante e annullamento delle collisioni (CSMA/CA).
Il protocollo CSMA prima di trasmettere dei pacchetti, sonda il canale
per determinare se altre stazioni stanno trasmettendo oppure il canale
è libero, in quest’ultimo caso la trasmissione del pacchetto da parte
del sender viene effettuata.
Dall’altra parte se la stazione desiderata ha ricevuto correttamente e
completamente il pacchetto spedito, allora a sua volta spedirà un
pacchetto esplicito di riscontro al sender, in modo tale che la stazione
che ha inviato i dati sia sicura che la trasmissione sia andata a buon
fine.
8
Sino ad ora abbiamo descritto il caso in cui il canale fosse libero, nel
caso in cui invece il canale venisse rilevato occupato, allora il sender
rimanda il suo accesso sino a quando il canale è libero.
Per ottenere questo il sender sceglie un tempo casuale di attesa per
ritentare la trasmissione e visto che la probabilità che due stazioni
scelgano lo stesso fattore di tempo è molto bassa, allora le possibili
collisioni tra pacchetti sono ridotte al minimo.
Esistono però situazioni in una rete wireless in cui non è possibile il
rivelamento di una collisione: queste situazioni sono sostanzialmente
di due tipi e sono conosciute come il problema del terminale nascosto
e l’attenuazione della forza di un segnale.
Il problema del terminale nascosto consiste in due stazioni che
trasmettono contemporaneamente ad uno stesso nodo: l’impossibilità
nel rilevare la collisione sta nel fatto che a causa di ostacoli fisici
nell’ambiente, i due nodi sender non siano in grado di ascoltare la
trasmissione dell’altro.
Il secondo scenario è dovuto a due nodi trasmettitori situati in modo
che le loro rispettive forze del segnale non siano sufficientemente
potenti per essere rilevate.[2]
9
10
2. SICUREZZA NELLA COMUNICAZIONE
2.1 Tipologia d’attacchi
La rete wireless può essere vulnerabile a diverse tipologie di attacchi
da parte di intrusi.
Questi attacchi sono:
• Attacchi agli apparati radio: un intruso potrebbe analizzare il
traffico wireless eludendo la crittografia dei dati trasmessi, così
da poter ottenere il loro contenuto, come il login e la password.
Inoltre è possibile un attacco più specifico, come la modifica
dei dati in transito o l’inserimento di un finto access point con
un segnale più potente, dirottando così la connessione dei nodi
wireless verso la rete pirata.
In questa maniera l’utente che tenta di connettersi non farà altro
che fornire dati riservati all’intruso.
• Attacchi alla rete aziendale o interna: se la rete wireless non ha
nessuna tecnica per autenticare un utente, allora qualsiasi
intruso potrebbe facilmente entrare nella rete e inoltre non
avendo nessun controllo per l’accesso alle risorse interne,
l’utente non desiderato potrebbe effettuare qualsiasi operazione
senza problema.
• Attacchi ai client wireless: i client wireless sono visti da molte
architetture come risorse interne ed un possibile aggressore
potrebbe compromettere un client per ottenere informazioni o
per usarlo come ponte per entrare nella rete aziendale.
11
2.2 Segretezza, autenticazione ed integrità
La sicurezza nella comunicazione in una rete è una caratteristica
molto importante e le principali proprietà che essa deve avere sono la
segretezza, l’autenticazione e l’integrità del messaggio.
La segretezza consiste nel garantire che solo il sender e il receiver
desiderati possano capire il contenuto del messaggio trasmesso e
poiché un intruso, come spiegato precedentemente, potrebbe
intercettare il messaggio, allora per assicurare la segretezza è
necessario che il dato trasmesso sia cifrato in modo che un aggressore
non possa decifrarlo.
Inoltre sia il sender che il receiver hanno la necessità di conferma
dell’identità dall’altra parte della comunicazione in modo da esser
sicuri che l’altro partecipante sia davvero chi dice di essere,
quest’operazione è detta autenticazione.
L’integrità del messaggio permette d’avere la certezza che il
contenuto del messaggio non sia stato alterato da incidenti durante il
percorso o volontariamente da un intruso.[1]
2.3 La crittografia
Le tecniche di crittografia permettono di cifrare i dati trasmessi in
modo tale che un intruso che ha intercettato un messaggio non sia in
grado di decifrarlo, ma allo stesso tempo che il destinatario desiderato
possa, una volta ricevuto il pacchetto, recuperare il dato originale da
quello camuffato.
Il testo non modificato è detto testo semplice o testo in chiaro, in
seguito usando un particolare algoritmo di cifratura esso sarà
trasformato in testo cifrato.
Tutti gli algoritmi usati sono standardizzati e resi pubblici a tutto il
mondo, per questo, per garantire la sicurezza si ha bisogno di qualche
12
elemento segreto per cifrare il messaggio, quest’informazione segreta
è la così detta chiave.
La chiave viene data usata come input, insieme al testo in chiaro
all’algoritmo di cifratura e così si ottiene come output il testo cifrato.
Dall’altra parte il receiver userà una propria chiave e un algoritmo di
decifratura per ottenere il testo originale.
Esistono due principali tipologie di utilizzo delle chiavi: il sistema a
chiave simmetrica e il sistema a chiave pubblica.
2.4 Sistema a chiave simmetrica
Un sistema a chiave simmetrica è costruito in modo che entrambi gli
interlocutori abbiano la stessa identica chiave segreta.
Questa proprietà implica il fatto che le due parti comunicanti debbano
condividere un segreto, cioè la chiave usata per cifrare e decifrare il
testo desiderato.
La difficoltà principale è che le due parti devono in qualche modo
accordarsi sulla chiave condivisa e quindi occorre una comunicazione
presumibilmente sicura tra loro.
I due comunicanti potrebbero incontrarsi di persona e cosi accordarsi
sulla chiave, ma nel mondo dell’informatica questa soluzione è al
quanto improbabile perché entrambi potrebbero solo comunicare
tramite la rete.
Una soluzione al problema è usare un intermediario di fiducia che nel
caso del sistema a chiave simmetrica è detto centro di distribuzione
delle chiavi KDC (Key Distribution Center), cioè una singola entità di
fiducia della rete con cui viene stabilita una chiave condivisa.
13
2.5 Sistema a chiave pubblica
Questo sistema ha un approccio completamente differente e
soprattutto permette a due entità di comunicare tra loro senza essersi
accordati precedentemente per una chiave condivisa.
Nel caso del sistema a chiave pubblica un’entità possiede due chiavi:
una chiave pubblica disponibile a chiunque nel mondo e una privata
conosciuta solo da lei.
L’altro comunicante che vuole interagire deve: prima richiedere la
chiave pubblica da chi la possiede, poi cifra il proprio messaggio con
la chiave appena ricavata e spedisce il messaggio.
Dall’altra parte l’entità che riceverà il messaggio cifrato con la propria
chiave pubblica decifrerà il testo con la sua privata.
In questo modo si può inviare messaggi segreti senza che alcuni dei
partecipanti sia costretto a distribuire chiavi segrete.
Un problema abbastanza evidente potrebbe essere un intruso che
entrato in possesso di un messaggio cifrato.
Infatti dopo aver ricavato la chiave pubblica, che tra l’altro è
disponibile al mondo, l’intruso potrebbe anche capire quale algoritmo
di cifratura è stato usato e così inviare qualsiasi tipo di testo cifrato o
spacciarsi per qualcun altro.
Chiaramente la selezione della chiave pubblica e la codifica di un
messaggio deve essere fatta in modo tale che sia praticamente
impossibile per un intruso ricavare qualsiasi informazione.
La crittografia a chiave pubblica trova spazio per l’utilizzo di tecniche
come la firma digitale e il digest del messaggio.
14
2.6 Firma digitale
Per indicare il proprietario o il creatore di un documento o per
garantire d’esser d’accordo con il suo contenuto, nel mondo
dell’informatica viene utilizzata la tecnica della firma digitale, cioè
una tecnica crittografica che consente di raggiungere questi obbiettivi.
Come la firma tradizionale, la firma digitale deve essere: verificabile,
non falsificabile e non rifiutabile.
Un’entità per firmare digitalmente un documento, non deve far altro
che usare la propria chiave privata e l’algoritmo di decifratura sul
documento stesso.
Può sembrare strano utilizzare un algoritmo di decifratura su un testo
non cifrato, ma è bene ricordare che un algoritmo non è nient’altro
che una funzione matematica e che l’obbiettivo non è quello di cifrare
e confondere il testo, ma quello di apporgli la propria firma.
Dall’altra parte l’entità che riceverà il documento applicherà la chiave
pubblica di chi dice di aver firmato e il proprio algoritmo di cifratura
alla firma digitale e così si otterrà un testo identico a quello originale.
In questo modo si ha la certezza del reale proprietario della firma,
poichè chiunque ha firmato il documento doveva essere a conoscenza
della chiave di cifratura privata.
E’ importante notare che la firma digitale è utilizzata anche per
garantire l’integrità di un messaggio, infatti, se il testo viene
danneggiato o cambiato volontariamente, allora l’output che si ottiene
applicando la chiave pubblica e l’algoritmo di cifratura sulla firma
digitale sarà differente da quello originale.
15
2.7 Digest del messaggio
Abbiamo affermato che la tecnologia di crittografia a chiave pubblica
è utilizzata per creare una firma digitale, un problema relativo a
quest’operazione è dovuta alla costosa cifratura e decifratura di un
intero testo e quindi da un alta computazione dei dati che ne segue.
La soluzione si può ottenere con una tecnica detta digest del
messaggio utilizzata sia per l’integrità che per firmare un documento.
L’algoritmo di digest prende un messaggio di lunghezza arbitraria e
calcola una “impronta digitale” di lunghezza fissa dei dati, conosciuta
come digest del messaggio.
In verità il digest non è nient’altro che una funzione hash, funzione
che prende in input un messaggio e calcola una stringa di lunghezza
fissa.
La tecnica appena vista garantisce l’integrità del messaggio, poichè se
un testo viene modificato, allora il digest che si ottiene sarà differente
da quello ricavato dal testo originale.
Inoltre è possibile utilizzare la tecnica della firma digitale al solo
digest e non all’intero documento, così da poter risolvere il problema
della costosa e alta computazione dei dati.
2.8 Certificazione
Un problema invece legato al sistema di chiavi pubbliche è proprio
nella sicurezza dell’ottenimento delle chiave pubblica da parte di
un'altra entità.
Un utente può rendere disponibile la propria chiave in molti modi:
per esempio mettendola in una pagina Web personale o in un server di
chiavi pubbliche o inviandola per e-mail.
Il problema è che l’utente che riceve la chiave pubblica deve essere
certo di possedere la chiave dell’entità con cui sta comunicando.
16
Quindi come per il sistema a chiavi simmetriche, anche per questo
tipo di crittografia si ha bisogno di un intermediario di fiducia detto
autorità di certificazione CA (Certification Authority).
Il compito della CA è di certificare che una chiave pubblica
appartenga ad una particolare entità: in sostanza essa verifica che un
entità sia chi dice di essere e fatto questo crea un certificato che lega
la chiave pubblica all’identità stessa.
Il certificato contiene al suo interno oltre alla chiave, anche le
informazioni di identificazione del proprietario ed infine viene firmato
dalla CA stessa.
Negli anni sono stati sviluppati e creati degli standard per le autorità
di certificazione, uno di questi è il x509 che specifica la sintassi per i
certificati.[2]
I campi più importanti contenuti in un certificato sono:
• Versione: numero della versione della specifica x.509
• Numero di serie: identificatore unico per il certificato rilasciato
dalla CA
• Firma: specifica l’algoritmo usato dalla CA per la firma
• Nome rilasciante: identità della CA che rilascia questo
certificato, nel formato detto DN (distinguished name)
• Periodo di validità: inizio e fine del periodo di validità del
certificato
• Nome del soggetto: identità dell’entità legata alla chiave, in
formato DN
• Chiave pubblica del soggetto: la chiave pubblica del soggetto
con un indicazione dell’algoritmo di chiave pubblica
17
18
3. WEP
3.1 Crittografia WEP
Lo standard 802.11 definisce anche una cifratura dei dati trasmessi
detta WEP (Wired Equivalent Privacy), studiato e creato per dare
all’utente una protezione adeguata.
La chiave fissa WEP da 40 o 104 bit (shared key) viene concatenata
inizialmente ad un vettore di inizializzazione (IV) di 24 bit casuali in
modo da formare una stringa di 64 o 128 bit.
Questa stringa sarà poi data in input all’algoritmo RC4 per formare la
chiave di cifratura dei dati.
Lo standard non definisce come generare il vettore d’inizializzazione
(IV) e viene trasmesso in chiaro.
Parallelamente all’operazione precedente, il testo da criptare viene
scomposto in blocchi e concatenato con i bit di checksum (ICV) per
formare una stringa della stessa lunghezza della chiave RC4.
Infine viene effettuata un’operazione di XOR tra la chiave e i blocchi
di dati, ottenendo così il testo cifrato a cui poi verrà aggiunto il vettore
di inizializzazione.
Nel 2001 alcuni ricercatori hanno però dimostrato la debolezza
dell’algoritmo RC4, nonché altre fragilità intrinseche del meccanismo
WEP dovute all’uso del vettore d’inizializzazione.
Infatti vari studi hanno dimostrato che si può ricavare la chiave di
cifratura dall’osservazione del traffico di rete e inoltre l’algoritmo
RC4 risulta essere vulnerabile se vengono utilizzate le chiavi più di
una volta.[10]
Il vettore di inizializzazione è lungo soltanto 24 bit, perciò permette
solo 2^24 tipi di combinazioni ed il protocollo prevede la
19
reinizializzazione dell’IV ogni qual volta si riscontra una collisione tra
i pacchetti inviati.
Tutto questo implica che in una rete di medie dimensioni e con un
traffico discreto sono sufficienti pochi minuti perché vengano
riutilizzate le stesse chiavi di cifratura.
Per questo, tramite appositi meccanismi di criptoanalisi si è in grado
di recuperare la chiave WEP e così decifrare tutto il traffico
trasmesso.
Oltre alla vulnerabilità del WEP stesso notiamo che lo standard
802.11 non fornisce nessun meccanismo per la custodia e la
protezione delle chiavi, infatti, nei casi peggiori si è optato per
conservare le chiavi in chiaro nei registri del sistemi Windows o in un
file di testo di Linux e solo in pochi casi alcuni produttori hanno
deciso di depositare le chiavi WEP nel firmware della scheda di rete.
La configurazione della chiave WEP è inoltre il più delle volte un
operazione manuale e questo implica un notevole sforzo per gli
amministratori di rete, che devono impostare la chiave su ogni singola
stazione wireless e punto di accesso.
Tutto questo porta ad una scarsa variazione nel tempo della chiave e
quindi un’evidente causa degli inconvenienti sopra descritti.
3.2 Protezione base della rete wireless
Con un’approfondita e una corretta analisi della propria rete e una
buona configurazione degli apparati, si può garantire una protezione
di base all’intero sistema.
Alcune regole di base per un’iniziale protezione sono:
• Cambiare gli SSID di default: il SSID identifica univocamente
ogni punto d’accesso all’interno della rete, in modo tale che
solo i dispositivi che usano il corretto SSID, possono
20
comunicare con i punti d’accesso. Se il punto d’accesso rimane
configurato con il SSID di default allora un eventuale intruso,
potrebbe usare questo nome per cercare di accedervi.
• Utilizzare SSID non descrittivi: usare SSID descrittivi relativi a
luoghi o aziende, può aiutare un intruso ad indovinare il SSID.
• Disabilitare il Broadcast SSID: gli access point mandano ad
intervalli regolari dei messaggi per la sincronizzazione ai client
e che contengono tra l’altro il SSID.
Questi pacchetti servono al client per configurarsi
automaticamente con la rete, ma possono anche servire ad un
intruso per la ricerca della rete, per questo motivo è utile
disabilitare quest’opzione e configurare il client manualmente.
• Cambiare le password: è importante cambiare la password di
default degli access point, che sia almeno lunga otto caratteri e
che includa caratteri speciali e numeri.
• Aggiornare il firmware: quando si sceglie un access point è
importante che esso abbia la possibilità di aggiornare il proprio
firmware o che almeno esso abbia l’ultima versione.
• Chiavi WEP: un intruso ha bisogno di catturare dai 100 Mb a
1Gb di traffico per provare a scovare la chiave WEP, quindi
cambiare spesso le chiavi di crittografia agli access point è un
buon deterrente al tentativo d’aggressione.
Alcuni access point supportano la dynamic WEP-Key, in grado
di automatizzare la generazione e la distribuzione delle chiavi,
sfortunatamente è una tecnica non standard e quindi esistono
diversi tipi d’implementazione a riguardo.
In altri AP invece quest’opzione non esiste, ma è possibile però
specificare fino a quattro differenti chiavi per il periodico
cambio di chiavi.
21
• Abilitare il MAC filtering: in molti access point esiste la
possibilità di abilitare solo alcune schede di rete usando il loro
MAC address, ma poiché quest’indirizzo può essere cambiato
allora possiamo considerare questo tipo di protezione non
sufficientemente sicura.
• Spegnere l’access point quando non serve: solitamente un
aggressore agisce durante la notte o al fine settimana perché la
rete non è controllata, perciò è utile spegnere l’AP quando non
è utilizzato.
• Minimizzare l’intensità del segnale: le onde radio non si
possono limitare a luoghi ben definiti, ma riescono ad
espandersi anche al di fuori del perimetro desiderato, per questo
motivo sarebbe buona cosa scegliere un apposita locazione
dell’access point, in modo che possa diffondere il proprio
segnale solo all’interno del luogo desiderato.
È possibile tramite sistemi radio o d’audit verificare che il
segnale radio non si diffonda al di fuori del luogo interessato ed
inoltre, è possibile diminuire l’intensità del segnale
posizionando l’AP non vicino a finestre o usare antenne
direzionali con basso guadagno in decibel.
Inoltre alcuni AP hanno la possibilità di definire l’intensità di
segnale via software.
• Protezione del client: come abbiamo visto in precedenza alcuni
attacchi sono mirati ai client, poiché essi possono essere usati
come ponte per entrare nella rete o per avere informazioni
importanti.
Per questo motivo è utile usare nel client dei personali firewall
per ridurre rischi di questo genere.
22
• Non utilizzare il DHCP: è consigliabile non utilizzare il DHCP
per l’assegnazione dinamica d’indirizzi IP, ma utilizzarne IP
statici e in questo caso è pure consigliabile di non usare
indirizzi di default facilmente intuibili.
Questa
è
ovviamente
una
tecnica
impegnativa
per
l’amministratore ma è utile per evitare che siano dati indirizzi
IP validi a chiunque tenti di connettersi.
Detto questo è bene notare che questi piccoli accorgmenti, in piccole
aziende o comunque in ambienti in cui la protezione non è
un’esigenza basilare, sono comunque sufficienti.
In altri ambienti invece, dove la sicurezza e la confidenzialità dei dati
è molto importante si necessita d’apparecchiature e operazioni
differenti che spiegheremo più avanti in questo testo.[11]
3.3 Auditing
Abbiamo accennato precedentemente all’audit, esso è infatti uno dei
principali meccanismi per conoscere lo stato del proprio livello di
sicurezza.
Questa è un’operazione che viene ripetuta non una sola volta ma a
cicli periodici.
Per esser più precisi l’auditing per le reti wireless Lan è molto
importante per verificare che i parametri di configurazione siano
corretti e che il segnale radio sia veramente limitato all’area che si
vuole coprire ed è anche in grado di rilevare la presenza d’access
point collegati alla rete non autorizzati.
Esistono software d’auditing per le wireless Lan che richiedono l’uso
di PC portatili o di palmari dotati di scheda wireless compatibili con
lo standard 802.11.
23
I più usati sono Kismet e Airsnort per il sistema Linux e Netstumbler
per Windows.
Questi software sono in grado di effettuare le seguenti funzionalità:
• Esaminare tutti i pacchetti di sincronizzazione per trovare i
punti d’accesso
• Determinare gli SSID e il nome degli access point
• Esaminare i pacchetti dei dati
• Determinare la presenza di meccanismi di cifratura
• Esaminare i pacchetti d’autenticazione ed il relativo metodo
• Esaminare il numero di client nella rete
• Determinare la versione del firmware presente sui singoli
punti d’accesso
• Determinare la quantità dei dati trasmessi per eventuali
attacchi al WEP
24
4. IEEE 802.1X
4.1 Lo standard 802.1x
Per ovviare a molti dei problemi visti in precedenza e garantire una
maggior sicurezza è stato creato lo standard IEEE 802.1x.
Questo standard permette di identificare in maniera sicura gli utenti
collegati ad una porta ethernet o ad un access point, esso infatti è nato
per l’autenticazione e l’autorizzazione dell’utente in una rete wireless
o ethernet.
Non
bisogna
confondere
le
due
principali
proprietà,
cioè
l’autenticazione e l’autorizzazione: la prima è un’operazione che
permette di garantire che colui con cui si sta comunicando sia
realmente chi dice di essere, la seconda controlla se ad un utente è
consentito accedere o no alla rete.
Il protocollo 802.1x è basato su l’EAPOL (Extensive Authentication
Protocol Over Lan) che consiste in diverse tipologie d’autenticazione.
E’molto utile per autenticare un utente e permettergli l’accesso alla
rete ma in ogni modo possiede alcune problematiche da tener conto:
per primo, questo standard non definisce nessun metodo di crittografia
anche se può integrarsi con il WEP ed il WPA, il secondo eventuale
problema è che molti access point non dispongono del supporto
802.1x.
Inoltre soltanto alcuni sistemi operativi come Windows 2000 e XP
supportano nativamente questo standard; altri sistemi invece che non
hanno questa caratteristica devono acquistare ed installare dei client
appositi.
Oggi molte aziende in possesso di una PKI (Public Key Infrastructure)
e di un access point compatibile con il 802.1x stanno sempre più
25
adottando questo tipo di tecnologia, poichè sicura e utile per
scoraggiare eventuali aggressori.
4.2 Il protocollo EAP
Lo standard 802.1x è nato principalmente per sopperire alla mancanza
d’autenticazione nelle reti wireless ma è stato anche esteso a reti
tradizionali.
E’ un sistema detto “Port-Based access control mechanism” cioè in
grado di autenticare un utente collegato ad una determinata porta
ethernet.
Per autenticare e autorizzare un utente la IEEE ha utilizzato un
protocollo EAP (Extensible Autentication Protocol) che supporta
differenti schemi d’autenticazione.
Esso non specifica solo un metodo per quest’operazione, ma permette
di negoziare la tecnica da usare tra l’utente e il server d’autenticazione
(solitamente un Radius server).
Gli schemi d'autenticazione di EAP sono: MD5, TLS ,TTLS , LEAP,
PEAP, SecureID, SIM e AKA.
EAP-MD5: è uno schema di autenticazione in cui un algoritmo di
hash viene usato con una shared secret e un challenge.
Questa è una tecnica non consigliata poiché gli hash delle password
possono essere vittime di attacchi e se un intruso riesce a ricavare il
challenge e l’hash di risposta, allora con appositi programmi potrebbe
arrivare anche alla password.
Inoltre non è ottimale, in quanto è un sistema che autentica solo il
client e non controlla invece anche la rete a cui ci si sta autenticando.
26
EAP-TLS: Transport Layer Security è un ottimo schema di
autenticazione, esso sostituisce la password con l’uso di certificati
digitali x.509, supporta la “mutual authentication”, cioè sia il client
che il server si autenticano così da evitare attacchi causati da access
point pirati.
In 802.1x questo metodo è molto usato ed è tra i più sicuri, a patto che
sia già stata adottata una PKI, ma ha anche uno svantaggio dovuto alla
gestione dei certificati per ogni client che vuole accedere alla rete.
EAP-LEAP: Light EAP o anche chiamato Cisco EAP, è una
implementazione proprietaria di Cisco che permette la “mutual
authentication” e permette di usare username e password come
meccanismo di autenticazione.
EAP-TTLS: Tunneled Transport Layer Security è una estensione di
EAP-TLS creata per evitare l’oneroso compito di dare certificati ad
ogni client e come tutti i sistemi di autenticazione “tunneling” è
basato su due fasi.
La prima fase consiste in un algoritmo asimetrico basato sulla chiave
del server che permette di autenticarlo e creare un tunnel sicuro.
Nella seconda fase il client viene identificato tramite un secondo
metodo d’autenticazione che attraversa il tunnel sicuro creato
precedentemente.
Il metodo di autenticazione usato nella seconda fase potrebbe essere
uno qualsiasi tra quelli gia elencati.
EAP-PEAP: Il Protected EAP è un Internet Draft di Cisco, Microsoft
e RSA, è simile al TLS poiché sono gli unici protocolli EAP di tipo
27
“tunneling” ed infatti anch’esso crea un tunnel sicuro in cui poi verrà
eseguita l’autenticazione del client.
Lo standard 802.1x tramite un frame detto EAPOL-Key del protocollo
EAP invia una o più chiavi WEP al client, è possibile inoltre usare su
alcuni access point chiavi WEP differenti per ogni sessione e così
risolvere il problema del cambio delle chiavi WEP, tuttavia questo
tipo di crittografia rimane una tecnica debole.
4.3 Funzionamento di EAP-TLS
Prima di parlare del sistema di autenticazione EAP-TLS, è utile
discutere brevemente di uno schema di sicurezza detto SSL (Secure
Sockets Layer) che sta alla base del TLS stesso.
SSL è un protocollo progettato per permettere la cifratura e
l’autenticazione per mezzo di certificati digitali tra un client e un
server.
L’operazione da esso svolta comincia con una fase di handshake in
cui ci si accorda su un algoritmo di cifratura e sulle chiavi da
utilizzare ed autentica il server al client e viceversa.
Terminata questa fase tutti i dati trasmessi saranno cifrati con la
chiave di sessione concordata precedentemente.
SSL è ampiamente utilizzato nel commercio Internet ed implementato
in molti browser e server Web, inoltre come detto sopra costituisce la
base del protocollo di sicurezza del livello di trasporto TLS.[2]
Come detto sopra EAP-TLS è oggi lo schema di autenticazione più
diffuso e sicuro per lo standard 802.1x/EAP.
I componenti essenziali per questo schema sono il supplicant, cioè il
computer dell’utente, l’authenticator che non è altro che l’access
point e l’authentication server che è tipicamente il Radius server.
28
E’bene ricordare che sia il Radius che il supplicant devono supportare
EAP-TLS, mentre l’access point deve supportare solamente il
802.1x/EAP e non è a conoscenza del tipo di schema EAP utilizzato.
Fig. 4-1 Schema di comunicazione
Durante la conversazione EAP, il Radius server manda i proprio
certificato al client e richiede il certificato del client, l’utente valida il
certificato del server e risponde con un messaggio EAP contenente il
suo certificato.
Il client inizia poi la negoziazione per la crittografia come l’algoritmo
di cifratura.
Dopo che il certificato del client è stato validato, il server risponde
con le specifiche crittografiche della sessione.
La derivazione di chiavi WEP nello schema EAP-TLS avviene in
questo modo: durante l’handshake TLS tra client e server, il client
genera un pre-master secret che viene crittografato con la chiave
pubblica del server e inviato a quest’ultimo.
In seguito il pre-master secret insieme a dei valori casuali del client e
del server vengono dati in input alla funzione PRF (pseudo-random
function) per creare una chiave detta master secret.
Quest’ultima insieme a valori casuali del client e del server vengono
dati in input di nuovo alla PRF per così generare una chiave di
sessione e il vettore d’inizializzazione (IV).
29
Infine la lunghezza della chiave di sessione è determinata dall’access
point ed è inviata attraverso un messaggio di tipo EAPOL-Key ai
client.
30
5. WPA
5.1 Funzionamento del WPA
Per colmare i problemi e le lacune derivanti dall’utilizzo del WEP, un
gruppo di lavoro chiamato “Task Group i” ha cercato di definire un
nuovo standard di sicurezza: l’IEEE 802.11i.
Nel frattempo per sostituire immediatamente il WEP e attendere che il
802.11i (oggi chiamato WPA2) giungesse a maturazione, è stato
creato un nuovo meccanismo detto WPA (Wi-Fi Protected Access)
concepito sin dall’inizio come soluzione temporanea.[11]
Alcuni produttori di hardware hanno concepito dei sistemi che
permettono il “mixed mode”, cioè la possibilità di supportare sia il
WEP che il WPA.
Inoltre la distribuzione di quest’ultimo è consentita e facilitata con
pochi aggiornamenti software in prodotti come access point e schede
di rete.
Il WPA richiede che un client si autentichi per avere accesso alla rete
e questo è consentito per il WPA attraverso il Pre-Shared Key o lo
standard 802.1x/EAP.
Permette anche un sistema di crittografia che usa un protocollo TKIP
(Temporary Key Integrity Protocol) e AES (Advanced Encryption
Standard).
Il protocollo WPA usa di default il TKIP (Temporary Key Integrity
Protocol) per crittografare i dati ed aumenta le chiavi da 104 bit del
WEP a 128 bit.
Contrariamente al WEP, dove le chiavi venivano impostate
staticamente, nel WPA vengono generate dinamicamente e distribuite
attraverso il protocollo 802.1x/EAP.
31
Il TKIP include anche un MIC (Message Integrity Check) che
permette di evitare le alterazioni dei pacchetti trasmessi, viene
calcolato separatamente dal client e dall’access point e se risultasse
differente il pacchetto in discussione verrebbe scartato.
Le differenze sostanziali tra il WEP e il WPA sono: il WEP ha una
crittografia debole, chiavi a 40 bit o 104 bit statiche, cioè tutti i client
hanno la stessa chiave e la loro distribuzione è manuale; il WPA
invece ha una crittografia più sicura e difficile da decifrare con chiavi
a 128 bit dinamiche, ciò significa che ogni utente, ogni sessione e
addirittura ogni pacchetto ha una chiave differente e quest’ultime
vengono distribuite automaticamente.
In dettaglio oltre alla forte integrazione con il 802.1x e la crittografia
più sicura, il WPA ha anche altre funzionalità suddividibili in cinque
categorie.
Network Capability Determination.
Comunica, tramite pacchetti di sincronizazione, le informazioni ai
client sul WPA, ovvero il metodo di autenticazione ( 802.1x o PreShared Key) e il tipo di cifratura (TKIP e AES).
Authentication.
Le tipologie d’autenticazioni sono la Pre-Shared Key, nel caso non si
disponga di un Radius server e il 802.1x che è la metodologia
preferita dal WPA poiché è in grado di distribuire chiavi differenti
attraverso messaggi EAPOL-Key.
Key Management.
Il Wpa ha un sistema di generazione e manutenzione di chiavi, esse
sono generate dopo che il client è stato autenticato e dopo un 4-way
handshake tra il client e l’access point.
32
Data Privacy (o crittografia).
Come parlato precedentemente il WPA usa il TKIP per incapsulare il
WEP e grazie a diverse tecniche si è in grado di evitare alcuni dei suoi
problemi.
Data Integrity.
TkIP include un MIC alla fine d’ogni messaggio per rilevare eventuali
modifiche dei pacchetti da parte di un aggressore.
Com’enunciato in precedenza i possibili metodi d’autenticazione sono
il Pre-Shared Key e 802.1x, il primo metodo usa una chiave statica
impostata manualmente sia sul client sia sull’access point ed è ideale
per esempio per utenze domestiche o piccoli ambienti che non hanno
un Radius server.
Il client equipaggiato dell’apposito software (supplicant), usa le
informazioni sulla rete trasmessi per mezzo della funzionalità
Network
Capability
Determination,
per
decidere
il
metodo
d’autenticazione e di cifratura da utilizzare.
Se per esempio l’access point usa il metodo PSK, allora il supplicant
non userà l’802.1x, ma sarà sufficiente provare all’access point di
essere in possesso del PSK comune.
Se invece il supplicant si accorge che non è in grado di supportare le
tecniche offerte, allora dovrà usare l’autenticazione 802.1x senza
WPA, quest’ultimo processo è detto Pre-WPA authentication.
La tecnica d’autenticazione 802.1x è la preferita dal WPA perché si
ottiene la migliore autenticazione e cifratura possibile.
Durante l’operazione d’autenticazione il PMK (Pairwise Master Key)
viene generato sul Radius server che poi lo invierà in maniera sicura
all’access point.
33
Questo PMK non sarà utilizzato dalla funzione di cifratura, ma viene
usato per generare chiavi temporanee che poi saranno usate nelle
funzioni di cifratura.
Le chiavi temporanee sono molto importanti perché utili al fine di
evitare attacchi alla chiave principale.
5.2 Crittografia nel WPA
Il TKIP cioè la cifratura preferita dal WPA usa l’algoritmo RC4 che è
lo stesso del WEP, ma con tecniche di protezione aggiuntive per
evitare problemi come nel caso del WEP.
Sono state aggiunte funzioni di cambio di chiavi per ogni pacchetto,
vettore di inizializzazione più lungo e un MIC (Message Integrità
Code): la funzione di cambio di chiavi per ogni pacchetto viene usata
dal TKIP per evitare attacchi su chiavi deboli, durante la generazione
del testo cifrato la chiave di crittografia non è mai usata nella funzione
RC4, ma viene usata una chiave temporanea per ogni pacchetto
spedito.
Per risolvere il problema dell’osservazione dei pacchetti con IV
identico allora il TKIP aumenta la sua grandezza da 24 a 48 bit.
Infine la funzione di hash utilizzata per controllare l’integrità del
messaggio è detta MIC e la sua funzione è di controllare che un
pacchetto non sia stato alterato da un intruso.
WPA supporta come algoritmo di cifratura anche l’AES che è
nettamente migliore del TKIP, ma che necessita anche di un nuovo
hardware che lo supporti.
TKIP invece offre una buona portabilità e una maggior sicurezza nei
confronti del WEP.[11]
34
5.3 Problemi del WPA
Il WPA non è esente da problemi, infatti, è soggetto ad un attacco di
tipo DoS (Denial of Service): se un access point riceve due pacchetti
che falliscono la verifica del MIC entro 60 secondi, allora esso
presume che è in corso un attacco e così impiega delle contromisure di
difesa, come la disconnessione di tutti i client dell’access point.
Questo è un buon metodo di difesa, ma perde anche una connettività
di 60 secondi che in termini informatici non sono certamente pochi.
Perciò possiamo dedurre che il WPA è un ottimo protocollo sicuro ed
affidabile
ma
in
possesso
anch’esso
di
qualche
problema,
inconvenienti però pur sempre molto piccoli rispetto ai vantaggi che
propone.
35
36
6. PROGETTO TLS
6.1 Utilizzo del Radius server
In un’azienda le operazioni di sicurezza sono molto impegnative, ma
ciò non esclude il problema che tutte le operazioni relative alla
protezione devono essere fatte in accordo con le politiche di sicurezza
aziendale.
Possiamo dedurre che per garantire un’adeguata sicurezza in una
struttura si ha la necessita di introdurre un elemento molto importante
e già elencato nel capitolo precedente, cioè il Radius server (Remote
Authentification Dial-In User Service) che è in grado di autenticare e
autorizzare ogni utente che tenta d’avere accesso alla rete.
Inoltre tra le tante funzioni che questo server possiede è anche in
grado di comunicare con altri server che usano o no lo stesso
protocollo.
L’utente interessato all’accesso comunica con l’access point,
quest’ultimo attraverso la rete fa lo stesso con il Radius in modo da
poter autenticare e autorizzare il client.
Infatti l’idea principale è proprio quella d’avere un magazzino
centrale contenente tutte le informazioni sull’autenticazione e
l’autorizzazione degli utenti.
Al client verrà richiesto di fornire le informazioni per l’autenticazione,
che verranno poi spedite all’access point e da qui inviate al Radius
server: il messaggio inviato conterrà le informazioni necessarie
all’utente per essere identificato, tutte le informazioni sono dette
attributi e sono definiti dal system manager del Radius.
La richiesta al server Radius da parte del client deve essere un segreto
condivisi con il server, in caso contrario la richiesta viene scartata.
Una volta superato il controllo iniziale il server consulta i propri file
37
interni che contengono tutte le informazioni necessarie per autenticare
l’utente, se anche questa operazione è conforme alla richiesta, allora a
questo punto il Radius invia una risposta all’utente sotto forma di
messaggio di risposta all’accesso.
Il pacchetto del Radius è solitamente incapsulato in UDP ed è formato
da diversi campi.
Code: identifica il tipo di pacchetto secondo il suo utilizzo.
• 1 richiesta d’accesso
• 2 consenso all’accesso
• 3 rifiuto dell’accesso
• 4 richiesta d’account
• 5 risposta dell’account
• 11 risposta dell’accesso
• 12 stato del server
• 13 stato del client
Identifier: verifica la corrispondenza tra richiesta e risposta.
Lenght: lunghezza del pacchetto compresi tutti i campi.[14]
Il protocollo che utilizza il Radius server è un protocollo del livello di
trasposto chiamato UDP, non orientato alla connessione ed
inaffidabile, la porta utilizzata è solitamente la numero 1812.
La scelta del protocollo UDP rispetto al TCP, che è orientato alla
connessione ed affidabile, è dovuta da diversi motivi: un utente non
vuole aspettare troppo tempo per essere autenticato dal server e l’UDP
che non è orientato alla connessione è molto più veloce del TCP e
quindi sembra essere la scelta migliore.
38
Inoltre il Radius è installato in macchine apposite che possono essere
spente, accese e riavviate e in questi casi la connessione TCP diventa
più difficile da gestire.
Infine l’UDP semplifica l’uso del multi-threading (il client genera
diversi processi per ridurre il ritardo dell’autenticazione).[2]
Un server Radius molto utilizzato in diverse strutture è il Freeradius,
che è il primo Open Source Radius server: è veloce, flessibile,
facilmente configurabile e supporta molti tra i protocolli di
autenticazione più commercializzati.
Più in dettaglio il Freeradius supporta la comunicazione con database
come
LDAP,
MySQL,
PosgreSQL
e
Oracle,
permette
l’implementazione di protocolli d’autenticazione della famiglia EAP,
come EAP-MD5, EAP-SIM, EAP-TLS, EAP-TTLS, EAP-PEAP e
Cisco LEAP.
Un’altra caratteristica molto importante è la possibilità d’eseguire
operazioni di proxing, cioè la capacità di utilizzare diversi Radius
server in comunicazione tra loro per distribuire l’autenticazione degli
utenti e bilanciare il carico di lavoro.[3] [4] [5] [7]
6.2 Configurazione del progetto TLS
La struttura che ho implementato per la creazione di una rete wireless
con il protocollo standard 802.1x è costituita da tre componenti: il
computer di un utente o meglio detto supplicant, l’authenticator cioè
l’access point ed infine l’authentication server ovvero il server
Radius.
La macchina su cui ho installato il server ha come nome rad1.fe.infn.it
ed ha le seguenti caratteristiche:
• sistema operativo Scientific Linux
• versione del Kernel 2.4.21-20.EL
39
• processore AMD athlon XP 1800+
1533 MHz
• memoria RAM 256 MB
• memoria fissa 8 GB
• indirizzo IP 193.206.188.38 maschera 255.255.255.0
In rad1 ho montato due schede di rete, una con indirizzo IP descritto
sopra per un utilizzo normale della rete, l’altra scheda di rete invece è
stata configurata con un indirizzo IP di rete privata 10.5.2.5 con
maschera 255.255.0.0, in modo da poter comunicare con l’access
point configurato con l’IP 10.5.1.4 e maschera 255.255.0.0.
Fig. 6.1 Nome ed indirizzo IP delle macchine utilizzate
Sono stati utilizzati indirizzi IP di rete privata di classe B per una sorta
di protezione, o meglio in modo tale che solo la macchina rad1,
avendo lo stesso numero di rete dell’access point e conoscendo il suo
IP possa avere accesso all’AP stesso.
Il software Radius installato nella macchina è un Freeradius: esistono
pacchetti in formato tar.gz ed rpm per questo tipo di programma.
La mia scelta è caduta sul Freeradius-1.0.1-1.RHEL3.i386.rpm.
La scelta del server da utilizzare è molto importante, anzi basilare,
bisogna innanzitutto accertarsi che tra i pacchetti che verranno
installati siano compresi quelli necessari per il tipo di utilizzo che si
vuole ottenere.
40
Come primo passo nel progetto, ho cercato di garantire una sicurezza
in una rete wireless utilizzando il protocollo d’autenticazione EAPTLS.
Ho installato il server con questo comando:
rpm –i Freeradius-1.0.1-1.RHEL3.i386.rpm
Saranno così installati una gran numero di pacchetti, ma è importante
notare tra questi la presenza di librerie, riportate qui di seguito, che
per sono utilissime per la configurazione del TLS e inseguito del
TTLS:
/usr/lib/rlm_eap_tls-1.0.1.so
/usr/lib/rlm_eap_tls.so
/usr/lib/rlm_eap_ttls-1.0.1.so
/usr/lib/rlm_eap_ttls.so
Tutti i file per la configurazione del server sono installati nella
directory /etc/raddb/, sono creati inizialmente per una configurazione
di base e parte del testo è completamente commentata, inoltre in
alcuni di loro sono inclusi riferimenti ad altri file situati altrove.[6]
Per un’appropriata configurazione del progetto ho dovuto leggere
ovviamente la documentazione allegata al Freeradius, dopodiché
togliere il commento alla parte del testo dei file che m’interessava ed
inserire alcuni parametri necessari.
Il file principale di configurazione del server è il radiusd.conf, che è
interamente riportato senza modifiche in appendice A1, gli altri file
utili per il progetto e da me modificati sono: client.conf riportato
senza modifiche in appendice A2, file user in appendice A3 ed
eap.conf in appendice A4.
Il file client.conf è utilizzato per contenere al suo interno le proprietà
dei client che sono visti dal freeradius, questi client sono
comunemente gli access point.
41
Il formato per l’identificazione dei client sopra citati sono:
“client [hostname | ip-address]”
seguito poi da un secret, che è un segreto condiviso tra il server e lo
stesso access point, da il nome, il tipo ed il login e la password, tutto
questo inserito all’interno di una parentesi graffa.
Nel mio caso le modifiche apportate a questo file sono le seguenti:
client 10.5.1.4/16 {
secret
= 12345
shortname
= ap
nastype
= other
login
= admin
password
= Michele
}
Il file user contiene l’autenticazione e la configurazione d’ogni utente
autorizzato ad aver accesso alla rete, è indicato il nome dell’utente con
una lunghezza massima di 253 caratteri, l’autenticazione con la quale
s’identificherà, una password se è necessaria, il nome del server, il
numero di porta con cui comunica il server e il tipo di protocollo.
Quando il server riceve una richiesta d’autenticazione, allora questo
file viene testato dall’alto verso il basso bloccandosi solo se è trovata
una corrispondenza con le informazioni dell’utente.
Nel caso invece in cui sia stata abilitata la proprietà “Fall-Through”,
allora la ricerca continua fino alla fine del file anche se è stata
intercettata una corrispondenza.
Le modifiche da noi inserite nel file user sono le seguenti:
“fabio” Auth-Type := EAP
42
Nel file eap.conf è necessario abilitare il tipo d’autenticazione usata e
inseguito configurare la sezione appropriata, nel mio caso ho
abilitato il TLS in questo modo:
eap {
# Invoke the default supported EAP type when
# EAP-Identity response is received.
#
# The incoming EAP messages DO NOT specify which EAP
# type they will be using, so it MUST be set here.
#
# For now, only one default EAP type may be used at a time.
#
# If the EAP-Type attribute is set by another module,
# then that EAP type takes precedence over the
# default type configured here.
#
default_eap_type = tls
E’ importante ricordare che con l’utilizzo di un protocollo come EAPTLS sia il server che l’utente necessitano entrambi di un certificato
x.509 per autenticarsi.
Per ottenere un certificato per la macchina rad1 ho usato dei comandi
OpenSSL per la creazione di una chiave privata e una richiesta di
certificazione.
OpenSSL è una realizzazione in forma di software libero dei
protocolli SSL/TLS per la certificazione e la comunicazione cifrata, si
compone di librerie che permettono d’incorporare le funzionalità dei
protocolli sopra enunciati e di una serie di programmi di utilità per la
gestione dei certificati e delle chiavi, arrivando eventualmente anche
alla gestione di un’autorità di certificazione.
La prima cosa che ho fatto è stata la creazione di una file con dati
casuali, ottenibile in due possibili modi:
cat file_a file_b file_c > file_casuale
dd if=/dev/random of=file_casuale bs=1b count=1k
43
Una volta ottenuto il file casuale ho creato una chiave privata in
questo comando:
openssl genrsa -rand file_casuale -out key.pem 1024
Per avere un certificato da un’autorità di certificazione, nel nostro
caso la INFN CA, ho creato una richiesta di certificazione che
necessita di un inserimento di dati in maniera interattiva:
openssl req -new -key key.pem -out req.pem
Dopo aver realizzato la richiesta, questa è stata inviata dal delegato
autorizzato all’INFN CA che inseguito la certificherà firmandola
digitalmente e rispedendo il documento al mittente.
Una volta in possesso dei certificati, è necessario prelevare il
certificato della CA e creare un collegamento simbolico che esprima il
codice di controllo del file stesso, più l’estensione .0:
ln –s infn.pem ‘openssl x509 –hash –noout –in infn.pem’.0
Il collegamento appena creato deve essere posto nella directory
/usr/share/ssl/certs in modo che SSL, che sta alla base del TLS, possa
controllare e riconoscere il certificato usato. [22]
A questo punto essendo in possesso di tutto il materiale necessario,
bisogna entrare nella sezione TLS del file eap.conf e inserire tutti i file
necessari per l’autenticazione, in altre parole la password della chiave,
se è stata utilizzata, la chiave e la sua locazione, il certificato del
server, l’autorità di certificazione fidata e i file dh e random.
## EAP-TLS
#
#
#
#
#
#
#
#
#
44
To generate ctest certificates, run the script
../scripts/certs.sh
The documents on http://www.freeradius.org/doc
are old, but may be helpful.
See also:
#
# http://www.dslreports.com/forum/remark,9286052~mode=flat
#
tls {
private_key_password =
private_key_file = /etc/raddb/infncert/key.pem
# If Private key & Certificate are located in
# the same file, then private_key_file &
# certificate_file must contain the same file
# name.
certificate_file = /etc/raddb/infncert/rad1.pem
# Trusted Root CA list
CA_file = /etc/raddb/infncert/infn.pem
dh_file = /etc/mycerts/dh
random_file = /etc/raddb/mycert/demoCA/private/file_casuale
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accomodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
fragment_size = 1024
# include_length is a flag which is
# by default set to yes If set to
# yes, Total Length of the message is
# included in EVERY packet we send.
# If set to no, Total Length of the
# message is included ONLY in the
# First packet of a fragment series.
#
include_length = yes
# Check the Certificate Revocation List
#
# 1) Copy CA certificates and CRLs to same directory.
# 2) Execute 'c_rehash <CA certs&CRLs Directory>'.
#
'c_rehash' is OpenSSL's command.
# 3) Add 'CA_path=<CA certs&CRLs directory>'
#
to radiusd.conf's tls section.
# 4) uncomment the line below.
# 5) Restart radiusd
check_crl = yes
#
#
#
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
# in the client certificate. If the values
# do not match, the certificate verification
# will fail rejecting the user.
#
check_cert_cn = %{User-Name}
}
45
Come detto in precedenza il file radiusd.conf è il principale per la
configurazione e l’utilizzo del server, al suo interno infatti sono
riportati tutti i riferimenti ai file sopra descritti.
Una volta modificato il file user, client.conf ed eap.conf bisogna
inserire l’EAP tra i moduli d’autorizzazione e autenticazione del
radiusd.conf come segue:
authorize {
#
# This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP
# authentication.
#
# It also sets the EAP-Type attribute in the request
# attribute list to the EAP type from the packet.
eap
authenticate {
# Allow EAP authentication.
eap
}
A questo punto è possibile avviare il server Radius e controllare se
sono stati commessi errori o se il server è pronto a ricevere richieste
d’accesso alla rete. [9]
Ho avviato il Freeradius eseguendo questo comando:
[root@rad1 root] # radiusd -X -A
Sono possibili diverse opzioni per il comando radiusd e sono riportate
qui di seguito:
Usage: radiusd [-a acct_dir] [-d db_dir] [-l log_dir] [-i address] [-p port] [AcfnsSvXxyz]
Options:
-a
-A
-d
-f
-h
-i
-l
46
acct_dir
db_dir
address
log_dir
use accounting directory 'acct_dir'.
Log auth detail.
Use database directory 'db_dir'.
Run as a foreground process, not a daemon.
Print this help message.
Listen only in the given IP address.
Log messages to 'log_dir'. Special values are:
stdout == log all messages to standard output.
-p port
-s
-S
-v
-X
-x
-y
-z
syslog == log all messages to the system logger.
Bind to 'port', and not to the radius/udp, or 1646/udp.
Do not spawn child processes to handle requests.
Log stripped names.
Print server version information.
Turn on full debugging. (Means: -sfxxyz -l stdout)
Turn on partial debugging. (-xx gives more debugging).
Log authentication failures, with password.
Log authentication successes, with password.
6.3 Configuazione Access Point
L’access point utilizzato nel progetto deve essere un apparecchio che
deve poter supportare la 802.1x, la tecnologia crittografica WPA e
quindi poter comunicare con un server Radius: la nostra scelta è
caduta su un hp J8131A wireless access point 420.
Per accedere direttamente all’access point mi sono collegato a lui con
un computer tramite la porta console, utilizzando poi un programma
d’emulazione come HyperTerminal sono riuscito ad avere accesso
all’AP usando il suo username e la password di default.
Una volta all’interno ho applicato una configurazione di base,
inserendo il nostro username e la password, disabilitando il suo DHCP
interno ed assegnandogli un indirizzo IP statico, che nel nostro caso è
il 10.5.1.4 con maschera 255.255.0.0
Fatta quest’operazione è poi possibile con la macchina rad1 accedere
all’access point direttamente con un browser Web, indicando come
URL l’indirizzo http://10.5.1.4/ , dopodiché comparirà la
schermata dell’access point in cui sarà richiesto username e password,
come mostra la figura sottostante.[16] [17]
47
Fig. 6.2 Interfaccia dell’access point per l’inserimento del username e password
Il secondo passo che ho fatto per la configurazione dell’access point è
stata l’assegnazione del SSID.
Fig. 6-3 Interfaccia dell’access point per l’assegnazione del SSID
48
Inseguito ho configurato il WPA per la crittografia e inserito le proprietà del Radius
server: l’indirizzo IP, la porta di comunicazione e il secret condiviso.
Fig. 6-4 Interfaccia dell’access point per l’abilitazione del WPA
Fig. 6-5 Interfaccia dll’access point per l’inserimento del Radius server
49
6.4 Configurazione supplicant per TLS
Sistemi operativi come Windows 2000 e Windows XP supportano
nativamente la IEEE 802.1x e il protocollo d’autenticazione
EAP-TLS.
Per testare il nostro progetto ho usato una macchina con il sistema
operativo Windows XP, il primo passo compiuto è stato quello di
permettere al sistema operativo e non alla scheda wireless di gestire la
configurazione e la rilevazione della rete senza fili.
Innanzi tutto ho abilitato il WPA nella macchina: per far questo sono
entrato nella finestra delle “connessioni di rete” e da qui nelle
proprietà della “connessione di rete senza fili”, in questa finestra sono
riportate tutte le reti senza fili disponibili.
Fig. 6-6 Connessioni di rete senza fili
50
Una volta scelta la rete senza fili a cui devo collegarmi, nel mio caso è
la 420, bisogna entrare nella finestra delle proprietà e da qui
selezionare il WPA ed il TKIP.
Fig. 6-7 Abilitazione WPA
E’importante notare che prima di configurare il TLS nella macchina
dell’utente, è necessario installare il suo certificato personale e
l’autorità di certificazione fidata (INFN CA).[8]
Per abilitare invece il TLS sono entrato nella “connessione di rete” e
da qui nella proprietà della “connessione alla rete locale (LAN) ”, si
sceglie la voce autenticazione e si abilita la 802.1x e il tipo di EAP
utilizzato, che in questo caso è “Smart Card o altro certificato”.
Dopodiché si seleziona il pulsante proprietà e si abilita l’utilizzo del
certificato sul computer e la convalida del certificato del server.
51
Fig. 6-8 Abilitazione 802.1x ed EAP
Fig. 6-9 Abilitazione dell’utilizzo del certificato
52
Una volta configurato anche il supplicant ho tentato di connettermi
alla rete protetta appena creata e dopo uno scambio reciproco di
certificati tra la macchina supplicant ed il server Radius è stato
consentito l’accesso alla rete.
53
54
7. PROGETTO TTLS
7.1 Configurazione del TTLS
La seconda parte del progetto consiste nel configurare la rete wireless
protetta con il protocollo d’autenticazione EAP-TTLS.
Tutto questo per evitare che ogni utente che vuole accedere alla rete
debba essere in possesso di un certificato: infatti come descritto in
precedenza, il TTLS permette che solo il server si autentichi con un
certificato, mentre l’utente usi un altro metodo per identificarsi, che
nel nostro progetto è l’EAP-MD5.
Per poter configurare il TTLS è stato necessario modificare alcuni file
di configurazione nella macchina Radius, file che abbiamo già visto
precedentemente per il TLS.
Il file clients.conf rimarrà identico a quello già modificato per il TLS,
poiché l’access point utilizzato sarà sempre lo stesso e anche la sua
configurazione non sarà cambiata:
client 10.5.1.4/16 {
secret
= 12345
shortname
= ap
nastype
= other
login
= admin
password
= Michele
}
Nel file user sono stati inseriti gli utenti che sono autorizzati ad
accedere alla rete protetta, in questo caso però il formato utilizzato è
differente da quello visto per il TLS, in altre parole ho immesso lo
username dell’utente, seguito dal tipo di autenticazione e dalla sua
password:
"fabio"
Auth-Type := EAP, User-Password == "centro"
"Mic" Auth-Type := EAP, User-Password == "test"
55
"Alberto Gianoli" Auth-Type := EAP, User-Password == "prova"
Nel file eap.conf ho settato il TTLS come tipo di autenticazione della
famiglia EAP, come riportato qui di seguito:
eap {
# Invoke the default supported EAP type when
# EAP-Identity response is received.
#
# The incoming EAP messages DO NOT specify which EAP
# type they will be using, so it MUST be set here.
#
# For now, only one default EAP type may be used at a time.
#
# If the EAP-Type attribute is set by another module,
#
default_eap_type = ttls
# A list is maintained to correlate EAP-Response
# packets with EAP-Request packets. After a
# configurable length of time, entries in the list
# expire, and are deleted.
#
timer_expire
= 60
# There are many EAP types, but the server has support
# for only a limited subset. If the server receives
# a request for an EAP type it does not support, then
# it normally rejects the request. By setting this
# configuration to "yes", you can tell the server to
# instead keep processing the request. Another module
# MUST then be configured to proxy the request to
# another RADIUS server which supports that EAP type.
#
# If another module is NOT configured to handle the
# request, then the request will still end up being
# rejected.
ignore_unknown_eap_types = no
# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given
# a User-Name attribute in an Access-Accept, it copies one
# more byte than it should.
#
# We can work around it by configurably adding an extra
# zero byte.
cisco_accounting_username_bug = no
Sempre nel file eap.conf ho lasciato la sezione del TLS esattamente
come era stata configurata precedentemente, poiché il certificato che
utilizzerà il server per identificarsi sarà sempre lo stesso, mentre nella
sezione del TTLS è necessario inserire il tipo d’autenticazione che
56
sarà utilizzato dall’utente per autenticarsi tramite il tunnel protetto, nel
mio caso sarà l’MD5:
## EAP-TLS
#
# To generate ctest certificates, run the script
#
#
../scripts/certs.sh
#
# The documents on http://www.freeradius.org/doc
# are old, but may be helpful.
#
# See also:
#
#
tls {
private_key_password =
private_key_file = /etc/raddb/infncert/key.pem
# name.
certificate_file = /etc/raddb/infncert/rad1.pem
CA_file = /etc/raddb/infncert/infn.pem
dh_file = /etc/mycerts/dh
random_file = /etc/raddb/mycert/demoCA/private/file_casuale
#
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accomodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
#
#
Check the Certificate Revocation List
57
#
#
#
check_crl = yes
#
#
#
#
}
# The TTLS module implements the EAP-TTLS protocol,
# which can be described as EAP inside of Diameter,
# inside of TLS, inside of EAP, inside of RADIUS...
#
# Surprisingly, it works quite well.
#
# The TTLS module needs the TLS module to be installed
# and configured, in order to use the TLS tunnel
# inside of the EAP packet. You will still need to
# configure the TLS module, even if you do not want
# to deploy EAP-TLS in your network. Users will not
# be able to request EAP-TLS, as it requires them to
# have a client certificate. EAP-TTLS does not
# require a client certificate.
#
ttls {
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# TTLS tunnel, we recommend using EAP-MD5.
# If the request does not contain an EAP
# conversation, then this configuration entry
# is ignored.
default_eap_type = md5
# The tunneled authentication request does
# not usually contain useful attributes
# like 'Calling-Station-Id', etc. These
# attributes are outside of the tunnel,
# and normally unavailable to the tunneled
# authentication request.
#
# By setting this configuration entry to
# 'yes', any attribute which NOT in the
# tunneled authentication request, but
# which IS available outside of the tunnel,
# is copied to the tunneled request.
#
# allowed values: {no, yes}
copy_request_to_tunnel = yes
#
58
The reply attributes sent to the NAS are
# usually based on the name of the user
# 'outside' of the tunnel (usually
# 'anonymous'). If you want to send the
# reply attributes based on the user name
# inside of the tunnel, then set this
# configuration entry to 'yes', and the reply
# to the NAS will be taken from the reply to
# the tunneled request.
#
use_tunneled_reply = yes
}
Il file radiusd.conf rimane invece esattamente come quello
configurato per il TLS, quindi con le inclusioni dei file sopra
modificati per il TTLS e l’inserimento dell’EAP tra i moduli
d’autorizzazione e d’autenticazione: [15] [13] [14]
authorize {
#
# authentication.
#
eap
authenticate {
eap
}
Infine una volta avviato il server Radius, esso si metterà in attesa di richieste
d’accesso da parte di qualche utente:
[root@rad1 root]# radiusd -X -A
Starting - reading configuration files ...
reread_config: reading radiusd.conf
Config:
including file: /etc/raddb/proxy.conf
Config:
including file: /etc/raddb/clients.conf
Config:
including file: /etc/raddb/snmp.conf
Config:
including file: /etc/raddb/eap.conf
Config:
including file: /etc/raddb/sql.conf
main: prefix = "/usr"
main: localstatedir = "/var"
main: logdir = "/var/log/radius"
main: libdir = "/usr/lib"
main: radacctdir = "/var/log/radius/radacct"
main: hostname_lookups = yes
main: max_request_time = 30
59
main: cleanup_delay = 5
main: max_requests = 1024
main: delete_blocked_requests = 0
main: port = 0
main: allow_core_dumps = no
main: log_stripped_names = yes
main: log_file = "/var/log/radius/radius.log"
main: log_auth = yes
main: log_auth_badpass = yes
main: log_auth_goodpass = yes
main: pidfile = "/var/run/radiusd/radiusd.pid"
main: user = "radiusd"
main: group = "radiusd"
main: usercollide = no
main: lower_user = "no"
main: lower_pass = "no"
main: nospace_user = "no"
main: nospace_pass = "no"
main: checkrad = "/usr/sbin/checkrad"
main: proxy_requests = yes
proxy: retry_delay = 5
proxy: retry_count = 3
proxy: synchronous = no
proxy: default_fallback = yes
proxy: dead_time = 120
proxy: post_proxy_authorize = yes
proxy: wake_all_if_all_dead = no
security: max_attributes = 200
security: reject_delay = 1
security: status_server = no
main: debug_level = 0
read_config_files: reading dictionary
read_config_files: reading naslist
Using deprecated naslist file. Support for this will go away soon.
read_config_files: reading clients
read_config_files: reading realms
radiusd: entering modules setup
Module: Library search path is /usr/lib
Module: Loaded exec
exec: wait = yes
exec: program = "(null)"
exec: input_pairs = "request"
exec: output_pairs = "(null)"
exec: packet_type = "(null)"
rlm_exec: Wait=yes but no output defined. Did you mean output=none?
Module: Instantiated exec (exec)
Module: Loaded expr
Module: Instantiated expr (expr)
Module: Loaded PAP
pap: encryption_scheme = "crypt"
Module: Instantiated pap (pap)
Module: Loaded CHAP
Module: Instantiated chap (chap)
Module: Loaded MS-CHAP
mschap: use_mppe = yes
mschap: require_encryption = no
mschap: require_strong = no
mschap: with_ntdomain_hack = no
mschap: passwd = "(null)"
mschap: authtype = "MS-CHAP"
mschap: ntlm_auth = "(null)"
Module: Instantiated mschap (mschap)
Module: Loaded System
60
unix: cache = no
unix: passwd = "(null)"
unix: shadow = "/etc/shadow"
unix: group = "(null)"
unix: radwtmp = "/var/log/radius/radwtmp"
unix: usegroup = no
unix: cache_reload = 600
Module: Instantiated unix (unix)
Module: Loaded eap
eap: default_eap_type = "ttls"
eap: timer_expire = 60
eap: ignore_unknown_eap_types = no
eap: cisco_accounting_username_bug = no
rlm_eap: Loaded and initialized type md5
rlm_eap: Loaded and initialized type leap
gtc: challenge = "Password: "
gtc: auth_type = "PAP"
rlm_eap: Loaded and initialized type gtc
tls: rsa_key_exchange = no
tls: dh_key_exchange = yes
tls: rsa_key_length = 512
tls: dh_key_length = 512
tls: verify_depth = 0
tls: CA_path = "(null)"
tls: pem_file_type = yes
tls: private_key_file = "/etc/raddb/infncert/key.pem"
tls: certificate_file = "/etc/raddb/infncert/rad1.pem"
tls: CA_file = "/etc/raddb/infncert/infn.pem"
tls: private_key_password = ""
tls: dh_file = "/etc/mycerts/dh"
tls: random_file = "/etc/raddb/mycert/demoCA/private/file_casuale"
tls: fragment_size = 1024
tls: include_length = yes
tls: check_crl = no
tls: check_cert_cn = "(null)"
rlm_eap: Loaded and initialized type tls
ttls: default_eap_type = "md5"
ttls: copy_request_to_tunnel = yes
ttls: use_tunneled_reply = yes
rlm_eap: Loaded and initialized type ttls
mschapv2: with_ntdomain_hack = no
rlm_eap: Loaded and initialized type mschapv2
Module: Instantiated eap (eap)
Module: Loaded preprocess
preprocess: huntgroups = "/etc/raddb/huntgroups"
preprocess: hints = "/etc/raddb/hints"
preprocess: with_ascend_hack = no
preprocess: ascend_channels_per_line = 23
preprocess: with_ntdomain_hack = no
preprocess: with_specialix_jetstream_hack = no
preprocess: with_cisco_vsa_hack = no
Module: Instantiated preprocess (preprocess)
Module: Loaded detail
detail: detailfile = "/var/log/radius/radacct/%{Client-IP-Address}/auth-detail%Y%m%d"
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (auth_log)
Module: Loaded realm
realm: format = "suffix"
realm: delimiter = "@"
realm: ignore_default = no
61
realm: ignore_null = no
Module: Instantiated realm (suffix)
Module: Loaded files
files: usersfile = "/etc/raddb/users"
files: acctusersfile = "/etc/raddb/acct_users"
files: preproxy_usersfile = "/etc/raddb/preproxy_users"
files: compat = "no"
Module: Instantiated files (files)
Module: Loaded Acct-Unique-Session-Id
acct_unique: key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IPAddress, NAS-Port"
Module: Instantiated acct_unique (acct_unique)
detail:
detailfile
=
"/var/log/radius/radacct/%{Client-IP-Address}/detail%Y%m%d"
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (detail)
Module: Loaded radutmp
radutmp: filename = "/var/log/radius/radutmp"
radutmp: username = "%{User-Name}"
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Listening on authentication *:1812
Listening on accounting *:1813
Listening on proxy *:1814
Ready to process requests.
7.2 Configurazione supplicant per TTLS
Abbiamo visto precedentemente che alcuni sistemi operativi come
Windows 2000 ed XP supportano la IEEE 802.1x e l’EAP-TLS.
Il problema in questo progetto è che questi stessi sistemi operativi non
supportano nativamente il TTLS: per questo motivo mi sono messo
alla ricerca di un software che potesse sopperire a questa mancanza.
La mia scelta è stato il software SecureW2_300_UniMore per
Windows 2000 ed XP.
E’un programma client EAP-TTLS di Windows scaricabile da
Internet, che supporta il TTLS e non è a pagamento.
Per poter funzionare questo programma ha bisogno del certificato
della CA fidata e del server, in modo tale da poter riconoscere il
server Radius quando tenta d’autenticarsi.
62
Per poter inserire all’interno del SecureW2 questi certificati ho
implementato un file di testo che lo stesso software utilizzerà per
l’installazione, all’interno ho elencato prima il certificato della
macchina Radius e poi quello dell’autorità di certificazione fidata.
È molto importante non sbagliare l’ordine dei certificati inseriti
all’interno del file di testo, altrimenti il SecureW2 confonderà i
certificati e non riconoscerà l’identificazione del server.
Un’ulteriore caratteristica da inserire nel file di testo, oltre ai
certificati, è anche il Fingerprint della CA fidata, cioè una stringa di
sedici numeri in notazione esadecimale che non è nient’altro che una
funzione hash per il controllo dell’integrità.
Il Fingerprint della CA si ottiene con un comando Openssl:
[root@rad1 infncert]# openssl x509 -noout -fingerprint -in infn.pem
MD5 Fingerprint=9C:3E:F4:3B:18:44:12:55:10:F3:89:C0:D5:D8:49:16
Inoltre i certificati rad1.pem e infn.pem, che devono essere copiati nel sistema
operativo Windows dell’utente e poi installati nel SecureW2, devono essere prima
convertiti in un formato “der” con una estensione “.cer” per essere riconosciuti da
Windows, per questo motivo ho usato un comando di conversione di Openssl:
openssl x509 –in rad1.pem –outform der –out rad1.cer
openssl x509 –in infn.pem –outform der –out infnCA.cer
L’implementazione del file di testo è riportata di seguito:
[Version]
Signature = "$Windows NT$"
Provider = "Alfa & Ariss"
Config = 5
[Certificates]
Certificate.0= rad1.cer
Certificate.1= infnCA.cer
[Profile.1]
; Connection
Name = 420
UseAlternateIdentity = FALSE
UseAnonymousIdentity = FALSE
AlternateOuterIdentity = [email protected]
63
EnableSessionResumption = FALSE
; Certificates
VerifyServerCertificates = TRUE
TrustedRootCA.0= 9c3ef43b1844125510f389c0d5d84916
; Authentication
AuthenticationMethod = md5
EAPType = 0
; User Account
PromptUserForCredentials = FALSE
; Advanced
ServerCertificateOnLocalComputer = TRUE
CheckForMicrosoftExtensions = FALSE
AllowNewConnections = TRUE
RenewIPAddress = FALSE
Una volta installato il SecureW2 è necessario entrare nella
“connessione di rete” di windows, da qui poi accedere alle proprietà
della “connessione alla rete locale (LAN)”, una volta qui è importante
notare che la voce SecureW2 è stata inserita come tipo di EAP.
A questo punto ho selezionato la voce SecureW2 e sono entrato nelle
sue proprietà per poterlo configurare a mia discrezione.
Fig. 7-1 Selezione del SecureW2 come tipo di EAP
64
Come prima cosa ho indicato un profilo di configurazione chiamato
420.
Fig.7-2 Creazione profilo 420
Inseguito ho configurato il profilo appena creato, controllando innanzi
tutto che i certificati del server e della CA siano stati installati e poi
inserendo il nome della macchina del server.
Fig. 7-3 Abilitazione per la verifica del certificato del server
65
Una volta controllata la presenza dei certificati ho scelto il tipo di
protocollo d’autenticazione che sarà usato dal supplicant per
identificarsi, nel mio caso sarà l’EAP-MD5.
Fig. 7-4 Abilitazione dell’EAP-MD5
Infine ho scelto di poter inserire le credenziali dell’utente
manualmente prima della fase di connessione.
Fig. 7-5 Abilitazione dell’inserimento delle credenziali dell’utente
66
E’ bene ricordare che la macchina supplicant deve essere sempre
configurata per l’utilizzo del WPA: la configurazione per questa
tecnica rimane esattamente la stessa vista nel paragrafo
“6.4 Configurazione supplicant per TLS”, in cui veniva abilitato il
WPA ed il TKIP per la connessione all’access point 420.
Arrivati a questo punto non rimane altro che tentare di connetterci alla
rete protetta, una volta richiesta la connessione uscirà un messaggio
dalla barra delle applicazioni, in cui verrà chiesto di cliccare con il
mouse sopra questo messaggio per poter inserire le proprie credenziali
per la connessione alla rete 420.
Fig.7-6 Messaggio per l’inserimento delle credenziali dell’utente
Fatto questo comparirà nello schermo una nuova finestra in cui
potremmo inserire il nostro username e la nostra password.
Fig. 7-7 Interfaccia per l’inserimento delle credenziali
67
In seguito basterà attendere perché venga data l’autorizzazione
d’accesso alla rete e così essere connessi.
I messaggi scambiati tra il Radius server e l’access point prima di
consentire l’accesso alla rete sono veramente molti, qui di seguito è
riportata la parte finale dello scambio di questi messaggi: per la
precisione l’istante in cui viene accettato l’accesso all’utente.
Login OK: [fabio/<no User-Password attribute>] (from client localhost port 1 cli
00095b657627)
TTLS: Got tunneled reply RADIUS code 2
EAP-Message = 0x03010004
Message-Authenticator = 0x00000000000000000000000000000000
User-Name = "fabio"
TTLS: Got tunneled Access-Accept
rlm_eap: Freeing handler
TTLS: Freeing handler for user fabio
modcall[authenticate]: module "eap" returns ok for request 6
modcall: group authenticate returns ok for request 6
Login OK: [fabio/<no User-Password attribute>] (from client ap port 1 cli 00095b
657627)
Sending Access-Accept of id 79 to 10.5.1.4:1616
Message-Authenticator = 0x00000000000000000000000000000000
User-Name = "fabio"
MS-MPPE-Recv-Key = 0x3a647e328b0e7db43c6f750b2efb432584848ca567ab379907d
31e55499f5acf
MS-MPPE-Send-Key = 0xa7c150ca8c46d8fd4b8440b42297d835251b9e01cc61e0a6dd8
33316574ebbd4
EAP-Message = 0x03070004
Finished request 6
Going to the next request
68
8. SUPPLICANT PER LINUX
8.1 Wpa_supplicant
Un ulteriore passo per il progetto è quello di permettere a computer
con sistemi operativi Linux di poter accedere alla rete protetta da me
creata.
Per realizzare questa parte è necessario installare nella macchina
utente un supplicant in grado di supportare il protocollo EAP-TTLS.
Nel mio caso ho utilizzato un software libero: il wpa_supplicant.
Il software wpa_supplicant supporta perfettamente il protocollo EAP
(con server Radius) e diversi metodi d’autenticazione come:
• EAP-TLS
• EAP-PEAP/MSCHAPv2
• EAP-PEAP/TLS
• EAP-PEAP/GTC
• EAP-PEAP/OTP
• EAP-PEAP/MD5-Challenge
• EAP-TTLS/EAP-MD5-Challenge
• EAP-TTLS/EAP-GTC
• EAP-TTLS/EAP-OTP
• EAP-TTLS/EAP-MSCHAPv2
• EAP-TTLS/EAP-TLS
• EAP-TTLS/MSCHAPv2
• EAP-TTLS/MSCHAP
• EAP-TTLS/PAP
• EAP-TTLS/CHAP
• EAP/SIM
• EAP/AKA
69
• EAP/PSK
• LEAP (richiede speciali supporti driver per IEEE 802.11)
I seguenti metodi sono supportati dal wpa_supplicant ma non possono
essere usati con il WPA o con IEEE 802.1x con WEP:
• EAP-MD5-Challenge
• EAP-MSCHAPv2
• EAP-GTC
• EAP-OPT
Come alternativa a seconda del metodo che si vuole usare per
autenticare le parti comunicanti, si può utilizzare un altro supplicant
chiamato Xsupplicant.
I drivers della scheda wireless che supporta il wpa_supplicant sono
differenti:
• Host AP driver per Prism2/2.5/3
• Linuxant DriverLoader
• Agere System Inc. Linux Driver
• Madwifi driver
• Atmel AT76C5XXx driver
• Linux ndiswrapper
• Broadcom driver
• Intel ipw2100 driver
• Intel ipw2200 driver
• Wired ethernet driver
• BSD net80211 layer
• Windows NDIS
70
Questo software è stato creato per essere portabile, quindi adattabile a
diversi driver e ad altrettanti sistemi operativi, inoltre per supportare
autenticazioni come EAP-TLS ed EAP-TTLS è necessario avere la
libreria openssl installata sulla propria macchina.
Una
volta
recuperato
da
Internet
il
pacchetto
software
wpa_supplicant, per poterlo installare è necessario creare all’interno
dello stesso pacchetto un file .config, in cui bisognerà inserire dei
parametri per l’abilitazione del EAP e dei driver desiderati.
Il formato di questi parametri è: CONFIG_<option>=y e le stringhe
precedute dal carattere # sono commentate.
Di seguito è riportato un esempio di un possibile file .config, in cui
per altro sono stati inclusi tutti i tipi di driver ed EAP che può
supportare il wpa_suplicant:
CONFIG_DRIVER_HOSTAP=y
CONFIG_DRIVER_PRISM54=y
CONFIG_DRIVER_HERMES=y
CONFIG_DRIVER_MADWIFI=y
CONFIG_DRIVER_ATMEL=y
CONFIG_DRIVER_WEXT=y
CONFIG_DRIVER_NDISWRAPPER=y
CONFIG_DRIVER_BROADCOM=y
CONFIG_DRIVER_IPW=y
CONFIG_DRIVER_BSD=y
CONFIG_DRIVER_NDIS=y
CONFIG_WIRELESS_EXTENSION=y
CONFIG_IEEE8021X_EAPOL=y
CONFIG_EAP_MD5=y
CONFIG_EAP_MSCHAPV2=y
CONFIG_EAP_TLS=y
CONFIG_EAP_PEAP=y
CONFIG_EAP_TTLS=y
CONFIG_EAP_GTC=y
CONFIG_EAP_OTP=y
CONFIG_EAP_SIM=y
CONFIG_EAP_AKA=y
CONFIG_EAP_PSK=y
CONFIG_EAP_LEAP=y
CONFIG_PCSC=y
71
Dopo aver creato il file di configurazione, è necessario usare il
comando “make” per poter compilare il software, dopodiché bisogna
installare il pacchetto nella directory /usr/local/bin con il comando
seguente: cp wpa_cli wpa_supplicant /usr/local/bin.
Il wpa_cli è una interfaccia di testo inclusa nel wpa_supplicant, che
una volta avviata permette di visualizzare l’output del supplicant
durante il suo funzionamento. [28] [29] [20] [21]
8.2 Configurazione wpa_supplicant
Dopo aver installato il wpa_supplicant è necessario poterlo
configurare a seconda delle proprie esigenze: per poter far questo si
utilizza un file chiamato wpa_supplicant.conf che si trova solitamente
nella directory /etc.
In questo file è possibile inserire la propria configurazione indicando
le diverse caratteristiche della rete a cui ci si vuole connettere, come il
SSID dell’access point, il tipo di criptazione e autenticazione
utilizzata e tante altre opzioni a seconda del proprio caso.
Qui
di
seguito
sono
riportati
diversi
configurazioni:
# EAP-TLS con WPA
network={
ssid="work"
scan_ssid=1
key_mgmt=WPA-EAP
pairwise=CCMP TKIP
group=CCMP TKIP
eap=TLS
identity="[email protected]"
ca_cert="/etc/cert/ca.pem"
client_cert="/etc/cert/user.pem"
private_key="/etc/cert/user.prv"
private_key_passwd="password"
}
72
esempi
di
possibili
# WPA-RADIUS/EAP-PEAP/MSCHAPv2 con Radius server
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
ssid="example"
scan_ssid=1
key_mgmt=WPA-EAP
eap=PEAP
password="foobar"
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}
# EAP-TTLS/EAP-MD5-Challenge
network={
ssid="example"
scan_ssid=1
key_mgmt=WPA-EAP
eap=TTLS
anonymous_identity="[email protected]"
password="foobar"
phase2="auth=MD5"
}
# IEEE 802.1X(no WPA)con dynamic WEP keys ed EAP-TLS
network={
ssid="1x-test"
scan_ssid=1
key_mgmt=IEEE8021X
eap=TLS
client_cert="/etc/cert/user.pem"
private_key="/etc/cert/user.prv"
private_key_passwd="password"
eapol_flags=3
}
73
# Autenticazione per wired Ethernet (-Dwired nel comando di start)
ap_scan=0
network={
key_mgmt=IEEE8021X
eap=MD5
identity="user"
password="password"
eapol_flags=0
}
Nel mio progetto, per poter configurare il wpa_supplicant con
un’autenticazione
EAP-TTLS/EAP-MD5
ho
inserito
nel
file
wpa_supplicant.conf queste righe di testo:
# EAP-TTLS/EAP-MD5
network={
ssid=”420”
key_mgmt=WPA-EAP
eap=TTLS
identity=”fabio”
password=”centro”
ca_cert=”/root/fabio/cert/infn.pem”
phase2=”auth-MD5”
}
Una volta configurato il wpa_supplicant è possibile avviarlo dalla
linea di comando in questo modo: “wpa_supplicant” seguito
principalmente dall’identificativo della scheda di rete utilizzata, dal
file wpa_supplicant.conf con la sua locazione nel filesystem e da
un’opzione che abilita o no il debugging, come elencato nell’esempio
sottostante:
wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -d
wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -B
Inoltre è anche possibile elencare nella linea di comando, includendo
un formato tipo –D<driver name>, quale driver si utilizza per la
scheda wireless.
74
Infine, qui di seguito ho esposto l’intero comando con tutte le possibili
opzioni e le sigle da utilizzare per i diversi driver supportati:
usage:
wpa_supplicant [-BddehLqqvw] -i<ifname> -c<config file> [-D<driver>] \
[-N -i<ifname> -c<conf> [-D<driver>] ...]
options:
-B = run daemon in the background
-d = increase debugging verbosity (-dd even more)
-K = include keys (passwords, etc.) in debug output
-t = include timestamp in debug messages
-e = use external IEEE 802.1X Supplicant (e.g., xsupplicant)
(this disables the internal Supplicant)
-h = show this help text
-L = show license (GPL and BSD)
-q = decrease debugging verbosity (-qq even less)
-v = show version
-w = wait for interface to be added, if needed
-N = start describing new interface
drivers:
hostap = Host AP driver (Intersil Prism2/2.5/3) [default]
(this can also be used with Linuxant DriverLoader)
prism54 = Prism54.org driver (Intersil Prism GT/Duette/Indigo)
not yet fully implemented
hermes = Agere Systems Inc. driver (Hermes-I/Hermes-II)
madwifi = MADWIFI 802.11 support (Atheros, etc.)
atmel = ATMEL AT76C5XXx (USB, PCMCIA)
wext = Linux wireless extensions (generic)
ndiswrapper = Linux ndiswrapper
broadcom = Broadcom wl.o driver
ipw = Intel ipw2100/2200 driver
wired = wpa_supplicant wired Ethernet driver
bsd = BSD 802.11 support (Atheros, etc.)
ndis = Windows NDIS driver
In questa parte di progetto, nonostante vari tentativi d’accedere alla
rete, devo constatare che non ho avuto affatto successo.
Dopo varie ricerche ed aver letto vari articoli in Internet, ho dedotto
che la causa principale del mio insuccesso è che i driver delle schede
wireless utilizzate per le prove di progetto, vale a dire Intel ipw e
prism54, non sono ancora completamente progettate per supportare il
protocollo EAP-TTLS/EAP-MD5.
Per questo motivo ho deciso d’interrompere questo tipo di sviluppo
del progetto e attendendere che un domani vengano implementati i
driver adatti per la mia struttura, in modo da permettere anche ad
75
utenti con sistema operativo Linux d’accedere alla rete wireless
protetta da me creata.
76
CONCLUSIONI
Il progetto realizzato promette d’essere una buona garanzia di
sicurezza sulla nostra rete wireless; i maggiori problemi che ho
incontrato durante lo sviluppo di questa struttura sono stati causati dal
recupero di apparecchiature adatte alle nostre esigenze, in particolare
di access point e Radius server in grado di supportare il WPA e il
802.1x.
Non meno problematica è stata la gestione dei certificati x.509, la
scelta di un buon supplicant per Windows e Linux in grado di
supportare il TTLS ed infine la scelta dei driver per le schede
wireless, infatti come già spiegato nel capitolo otto alcuni di essi non
sono ancora stati completamente sviluppati per poter supportare alcuni
parametri che per il mio progetto sono necessari.
Per futuri scenari credo sia un’ottima idea poter integrare il nostro
Radius server con un database LDAP, in modo da poter inserire tutti
gli utenti a cui è permesso l’accesso alla rete all’interno del database
stesso, così da poter sfruttare tutti i vantaggi e le comodità che ne
derivano.
77
78
BIBLIOGRAFIA
[1] Tanenbaum A., “Reti di computer”, terza edizione, Omegna (Vb),
UTET, 2001
[2] Kurose J., Ross K., “Internet e Reti di Calcolatori”, Milano,
McGraw-Will, 2001
[3] “The FreeRADIUS Server Project”, http://www.freeradius.org
[4] “Installation”, http://www.freeradius.org/usage.html
[5] “README”, http://www.freeradius.org/radiusd/README
[6] “INSTALL”, http://www.freeradius.org/radiusd/INSTALL
[7] “doc/README”,
http://www.freeradius.org/radiusd/doc/README
[8] Ken R., “Setup for FreeRADIUS and Windows XP Supplicant,
2002,
http://www.freeradius.org/radiusd/doc/README
[9] “Authentication Server: Setting up FreeRADIUS”, 2004,
http://www.tldp.org/HOWTO/8021X-HOWTO/freeradius.html
[10] ”Wireless Lan”, http://equars.com/wireless_security.html
[11] Paternò G. “Sicurezza Nelle Wireless LAN”, 2003,
http://gpaterno.free.fr/publications/SicurezzaWLAN/GPaternoSicurezza_Nelle_Wireless_LAN.pdf
[12] D’Amato L., “Il protocollo di autenticazione RADIUS”, 2002,
http://www.securitywireless.info/article_read.asp?id=42
[13] “Setting up FreeRADIUS using EAP_TTLS”, 2004,
http://www.alphacore.net/spipen/article.php3?id_article=4
[14] ”Help with EAP-TTLS/EAP-MD5”, 2004,
http://lists.shmoo.com/pipermail/hostap/2004-July/007206.html
[15] Birri R.,”How to Freeradius + EAP-TTLS”,
http://rbirri.9online.fr/howto/Freeradius_+_TTLS.html
79
[16] “Management and configuration guide”,
www.hp.com/go/hpprocurve
[17] “Installation and getting started guide”,
www.hp.com/go/hpprocurve
[18] “Configurazione di Linux per l’accesso alla rete wireless di
Facoltà”, http://art.ing.unibs.it/linux+wifi.html
[19] Scano A.,“Collegarsi ad una rete wireless 802.11 con Linux”,
http://seminari.gulch.crs4.it/slides/wireless/seminario-wireless.pdf
[20] “WiFi + WPA tutorial”,
http://www.dsy.it/forum/showthread.php?s=72865d5c7f239f80dc710
1e6d0699fac&threadid=14164&display=&perpage=15&pagenumber
=6
[21] “Linux WPA/WPA2/IEEE 802.1x Supplicant”,
http://hostap.epitest.fi/wpa_supplicant/
[22] “Introduzione a OpenSSL”, http://a2.pluto.it/a2312.htm
APPENDICE
Appendice A1
##
## radiusd.conf
-- FreeRADIUS server configuration file.
##
##
http://www.freeradius.org/
##
$Id: radiusd.conf.in,v 1.188 2004/05/13 20:10:19 pnixon Exp $
##
#
#
#
#
#
80
The location of other config files and
logfiles are declared in this file
Also general configuration for modules can be done
in this file, it is exported through the API to
#
#
#
#
#
#
#
#
#
modules that ask for it.
The configuration variables defined here are of the form ${foo}
They are local to this file, and do not change from request to
request.
The per-request variables are of the form %{Attribute-Name}, and
are taken from the values of the attribute in the incoming
request. See 'doc/variables.txt' for more information.
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = /usr/sbin
logdir = ${localstatedir}/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct
# Location of config and logfiles.
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/radiusd
#
# The logging messages for the server are appended to the
# tail of this file.
#
log_file = ${logdir}/radius.log
#
# libdir: Where to find the rlm_* modules.
#
#
This should be automatically set at configuration time.
#
#
If the server builds and installs, but fails at execution time
#
with an 'undefined symbol' error, then you can use the libdir
#
directive to work around the problem.
#
#
The cause is usually that a library has been installed on your
#
system in a place where the dynamic linker CANNOT find it. When
#
executing as root (or another user), your personal environment MAY
#
be set up to allow the dynamic linker to find the library. When
#
executing as a daemon, FreeRADIUS MAY NOT have the same
#
personalized configuration.
#
#
To work around the problem, find out which library contains that symbol,
#
and add the directory containing that library to the end of 'libdir',
#
with a colon separating the directory names. NO spaces are allowed.
#
#
e.g. libdir = /usr/local/lib:/opt/package/lib
#
#
You can also try setting the LD_LIBRARY_PATH environment variable
#
in a script which starts the server.
#
#
If that does not work, then you can re-configure and re-build the
#
server to NOT use shared libraries, via:
#
#
./configure --disable-shared
#
make
#
make install
#
libdir = /usr/lib
81
# pidfile: Where to place the PID of the RADIUS server.
#
# The server may be signalled while it's running by using this
# file.
#
# This file is written when ONLY running in daemon mode.
#
# e.g.: kill -HUP `cat /var/run/radiusd/radiusd.pid`
#
pidfile = ${run_dir}/radiusd.pid
# user/group: The name (or #number) of the user/group to run radiusd as.
#
#
If these are commented out, the server will run as the user/group
#
that started it. In order to change to a different user/group, you
#
MUST be root ( or have root privleges ) to start the server.
#
#
We STRONGLY recommend that you run the server with as few permissions
#
as possible. That is, if you're not using shadow passwords, the
#
user and group items below should be set to 'nobody'.
#
#
On SCO (ODT 3) use "user = nouser" and "group = nogroup".
#
# NOTE that some kernels refuse to setgid(group) when the value of
# (unsigned)group is above 60000; don't use group nobody on these systems!
#
# On systems with shadow passwords, you might have to set 'group = shadow'
# for the server to be able to read the shadow password file. If you can
# authenticate users while in debug mode, but not in daemon mode, it may be
# that the debugging mode server is running as a user that can read the
# shadow info, and the user listed below can not.
#
user = radiusd
group = radiusd
# max_request_time: The maximum time (in seconds) to handle a request.
#
# Requests which take more time than this to process may be killed, and
# a REJECT message is returned.
#
# WARNING: If you notice that requests take a long time to be handled,
# then this MAY INDICATE a bug in the server, in one of the modules
# used to handle a request, OR in your local configuration.
#
# This problem is most often seen when using an SQL database. If it takes
# more than a second or two to receive an answer from the SQL database,
# then it probably means that you haven't indexed the database. See your
# SQL server documentation for more information.
#
# Useful range of values: 5 to 120
#
max_request_time = 30
# delete_blocked_requests: If the request takes MORE THAN 'max_request_time'
# to be handled, then maybe the server should delete it.
#
# If you're running in threaded, or thread pool mode, this setting
# should probably be 'no'. Setting it to 'yes' when using a threaded
# server MAY cause the server to crash!
#
delete_blocked_requests = no
82
# cleanup_delay: The time to wait (in seconds) before cleaning up
# a reply which was sent to the NAS.
#
# The RADIUS request is normally cached internally for a short period
# of time, after the reply is sent to the NAS. The reply packet may be
# lost in the network, and the NAS will not see it. The NAS will then
# re-send the request, and the server will respond quickly with the
# cached reply.
#
# If this value is set too low, then duplicate requests from the NAS
# MAY NOT be detected, and will instead be handled as seperate requests.
#
# If this value is set too high, then the server will cache too many
# requests, and some new requests may get blocked. (See 'max_requests'.)
#
# Useful range of values: 2 to 10
#
cleanup_delay = 5
# max_requests: The maximum number of requests which the server keeps
# track of. This should be 256 multiplied by the number of clients.
# e.g. With 4 clients, this number should be 1024.
#
# If this number is too low, then when the server becomes busy,
# it will not respond to any new requests, until the 'cleanup_delay'
# time has passed, and it has removed the old requests.
#
# If this number is set too high, then the server will use a bit more
# memory for no real benefit.
#
# If you aren't sure what it should be set to, it's better to set it
# too high than too low. Setting it to 1000 per client is probably
# the highest it should be.
#
# Useful range of values: 256 to infinity
#
max_requests = 1024
# bind_address: Make the server listen on a particular IP address, and
# send replies out from that address. This directive is most useful
# for machines with multiple IP addresses on one interface.
#
# It can either contain "*", or an IP address, or a fully qualified
# Internet domain name. The default is "*"
#
# As of 1.0, you can also use the "listen" directive. See below for
# more information.
#
bind_address = *
#
#
#
#
#
#
#
#
#
#
#
#
#
port: Allows you to bind FreeRADIUS to a specific port.
The default port that most NAS boxes use is 1645, which is historical.
RFC 2138 defines 1812 to be the new port. Many new servers and
NAS boxes use 1812, which can create interoperability problems.
The port is defined here to be 0 so that the server will pick up
the machine's local configuration for the radius port, as defined
in /etc/services.
If you want to use the default RADIUS port as defined on your server,
(usually through 'grep radius /etc/services') set this to 0 (zero).
83
# A port given on the command-line via '-p' over-rides this one.
#
# As of 1.0, you can also use the "listen" directive. See below for
# more information.
#
port = 0
#
# By default, the server uses "bind_address" to listen to all IP's
# on a machine, or just one IP. The "port" configuration is used
# to select the authentication port used when listening on those
# addresses.
#
# If you want the server to listen on additional addresses, you can
# use the "listen" section. A sample section (commented out) is included
# below. This "listen" section duplicates the functionality of the
# "bind_address" and "port" configuration entries, but it only listens
# for authentication packets.
#
# If you comment out the "bind_address" and "port" configuration entries,
# then it becomes possible to make the server accept only accounting,
# or authentication packets. Previously, it always listened for both
# types of packets, and it was impossible to make it listen for only
# one type of packet.
#
#listen {
# IP address on which to listen.
# Allowed values are:
#
dotted quad (1.2.3.4)
#
hostname
(radius.example.com)
#
wildcard
(*)
#
ipaddr = *
#
#
#}
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
84
# Port on which to listen.
#
integer port number (1812)
#
0 means "use /etc/services for the proper port"
port = 0
# Type of packets to listen for.
#
auth listen for authentication packets
#
acct listen for accounting packets
#
type = auth
hostname_lookups: Log the names of clients or just their IP addresses
e.g., www.freeradius.org (on) or 206.47.27.232 (off).
The default is 'off' because it would be overall better for the net
if people had to knowingly turn this feature on, since enabling it
means that each client request will result in AT LEAST one lookup
request to the nameserver.
Enabling hostname_lookups will also
mean that your server may stop randomly for 30 seconds from time
to time, if the DNS requests take too long.
Turning hostname lookups off also means that the server won't block
for 30 seconds, if it sees an IP address which has no name associated
with it.
allowed values: {no, yes}
#
hostname_lookups = yes
# Core dumps are a bad thing. This should only be set to 'yes'
# if you're debugging a problem with the server.
#
#
allow_core_dumps = no
# Regular expressions
#
# These items are set at configure time. If they're set to "yes",
# then setting them to "no" turns off regular expression support.
#
# If they're set to "no" at configure time, then setting them to "yes"
# WILL NOT WORK. It will give you an error.
#
regular_expressions
= yes
extended_expressions
= yes
# Log the full User-Name attribute, as it was found in the request.
#
#
log_stripped_names = yes
# Log authentication requests to the log file.
#
#
log_auth = yes
# Log passwords with the authentication requests.
# log_auth_badpass - logs password if it's rejected
# log_auth_goodpass - logs password if it's correct
#
#
log_auth_badpass = yes
log_auth_goodpass = yes
# usercollide: Turn "username collision" code on and off. See the
# "doc/duplicate-users" file
#
# WARNING
# !!!!!!! Setting this to "yes" may result in the server behaving
# !!!!!!! strangely. The "username collision" code will ONLY work
# !!!!!!! with clear-text passwords. Even then, it may not do what
# !!!!!!! you want, or what you expect.
# !!!!!!!
# !!!!!!! We STRONGLY RECOMMEND that you do not use this feature,
# !!!!!!! and that you find another way of acheiving the same goal.
# !!!!!!!
# !!!!!!! e,g. module fail-over. See 'doc/configurable_failover'
# WARNING
#
usercollide = no
# lower_user / lower_pass:
# Lower case the username/password "before" or "after"
# attempting to authenticate.
#
85
# If "before", the server will first modify the request and then try
# to auth the user. If "after", the server will first auth using the
# values provided by the user. If that fails it will reprocess the
# request after modifying it as you specify below.
#
# This is as close as we can get to case insensitivity. It is the
# admin's job to ensure that the username on the auth db side is
# *also* lowercase to make this work
#
# Default is 'no' (don't lowercase values)
# Valid values = "before" / "after" / "no"
#
lower_user = no
lower_pass = no
# nospace_user / nospace_pass:
#
# Some users like to enter spaces in their username or password
# incorrectly. To save yourself the tech support call, you can
# eliminate those spaces here:
#
# Default is 'no' (don't remove spaces)
# Valid values = "before" / "after" / "no" (explanation above)
#
nospace_user = no
nospace_pass = no
# The program to execute to do concurrency checks.
checkrad = ${sbindir}/checkrad
# SECURITY CONFIGURATION
#
# There may be multiple methods of attacking on the server. This
# section holds the configuration items which minimize the impact
# of those attacks
#
security {
#
# max_attributes: The maximum number of attributes
# permitted in a RADIUS packet. Packets which have MORE
# than this number of attributes in them will be dropped.
#
# If this number is set too low, then no RADIUS packets
# will be accepted.
#
# If this number is set too high, then an attacker may be
# able to send a small number of packets which will cause
# the server to use all available memory on the machine.
#
# Setting this number to 0 means "allow any number of attributes"
max_attributes = 200
#
#
#
#
#
#
#
#
#
#
#
86
delayed_reject: When sending an Access-Reject, it can be
delayed for a few seconds. This may help slow down a DoS
attack. It also helps to slow down people trying to brute-force
crack a users password.
Setting this number to 0 means "send rejects immediately"
If this number is set higher than 'cleanup_delay', then the
rejects will be sent at 'cleanup_delay' time, when the request
is deleted from the internal cache of requests.
#
# Useful ranges: 1 to 5
reject_delay = 1
#
# status_server: Whether or not the server will respond
# to Status-Server requests.
#
# Normally this should be set to "no", because they're useless.
# See: http://www.freeradius.org/rfc/rfc2865.html#Keep-Alives
#
# However, certain NAS boxes may require them.
#
# When sent a Status-Server message, the server responds with
# an Access-Accept packet, containing a Reply-Message attribute,
# which is a string describing how long the server has been
# running.
#
status_server = no
}
# PROXY CONFIGURATION
#
# proxy_requests: Turns proxying of RADIUS requests on or off.
#
# The server has proxying turned on by default. If your system is NOT
# set up to proxy requests to another server, then you can turn proxying
# off here. This will save a small amount of resources on the server.
#
# If you have proxying turned off, and your configuration files say
# to proxy a request, then an error message will be logged.
#
# To disable proxying, change the "yes" to "no", and comment the
# $INCLUDE line.
#
#
proxy_requests = yes
$INCLUDE ${confdir}/proxy.conf
# CLIENTS CONFIGURATION
#
# Client configuration is defined in "clients.conf".
#
# The 'clients.conf' file contains all of the information from the old
# 'clients' and 'naslist' configuration files. We recommend that you
# do NOT use 'client's or 'naslist', although they are still
# supported.
#
# Anything listed in 'clients.conf' will take precedence over the
# information from the old-style configuration files.
#
$INCLUDE ${confdir}/clients.conf
# SNMP CONFIGURATION
#
# Snmp configuration is only valid if SNMP support was enabled
# at compile time.
#
# To enable SNMP querying of the server, set the value of the
87
# 'snmp' attribute to 'yes'
#
snmp = no
$INCLUDE ${confdir}/snmp.conf
# THREAD POOL CONFIGURATION
#
# The thread pool is a long-lived group of threads which
# take turns (round-robin) handling any incoming requests.
#
# You probably want to have a few spare threads around,
# so that high-load situations can be handled immediately. If you
# don't have any spare threads, then the request handling will
# be delayed while a new thread is created, and added to the pool.
#
# You probably don't want too many spare threads around,
# otherwise they'll be sitting there taking up resources, and
# not doing anything productive.
#
# The numbers given below should be adequate for most situations.
#
thread pool {
# Number of servers to start initially --- should be a reasonable
# ballpark figure.
start_servers = 5
# Limit on the total number of servers running.
#
# If this limit is ever reached, clients will be LOCKED OUT, so it
# should NOT BE SET TOO LOW. It is intended mainly as a brake to
# keep a runaway server from taking the system with it as it spirals
# down...
#
# You may find that the server is regularly reaching the
# 'max_servers' number of threads, and that increasing
# 'max_servers' doesn't seem to make much difference.
#
# If this is the case, then the problem is MOST LIKELY that
# your back-end databases are taking too long to respond, and
# are preventing the server from responding in a timely manner.
#
# The solution is NOT do keep increasing the 'max_servers'
# value, but instead to fix the underlying cause of the
# problem: slow database, or 'hostname_lookups=yes'.
#
# For more information, see 'max_request_time', above.
#
max_servers = 32
# Server-pool size regulation. Rather than making you guess
# how many servers you need, FreeRADIUS dynamically adapts to
# the load it sees, that is, it tries to maintain enough
# servers to handle the current load, plus a few spare
# servers to handle transient load spikes.
#
# It does this by periodically checking how many servers are
# waiting for a request. If there are fewer than
# min_spare_servers, it creates a new spare. If there are
# more than max_spare_servers, some of the spares die off.
# The default values are probably OK for most sites.
#
min_spare_servers = 3
88
max_spare_servers = 10
# There may be memory leaks or resource allocation problems with
# the server. If so, set this value to 300 or so, so that the
# resources will be cleaned up periodically.
#
# This should only be necessary if there are serious bugs in the
# server which have not yet been fixed.
#
# '0' is a special value meaning 'infinity', or 'the servers never
# exit'
max_requests_per_server = 0
}
# MODULE CONFIGURATION
#
# The names and configuration of each module is located in this section.
#
# After the modules are defined here, they may be referred to by name,
# in other sections of this configuration file.
#
modules {
#
# Each module has a configuration as follows:
#
#
name [ instance ] {
#
config_item = value
#
...
#
}
#
# The 'name' is used to load the 'rlm_name' library
# which implements the functionality of the module.
#
# The 'instance' is optional. To have two different instances
# of a module, it first must be referred to by 'name'.
# The different copies of the module are then created by
# inventing two 'instance' names, e.g. 'instance1' and 'instance2'
#
# The instance names can then be used in later configuration
# INSTEAD of the original 'name'. See the 'radutmp' configuration
# below for an example.
#
# PAP module to authenticate users based on their stored password
#
# Supports multiple encryption schemes
# clear: Clear text
# crypt: Unix crypt
#
md5: MD5 ecnryption
#
sha1: SHA1 encryption.
# DEFAULT: crypt
pap {
encryption_scheme = crypt
}
# CHAP module
#
# To authenticate requests containing a CHAP-Password attribute.
#
chap {
authtype = CHAP
}
89
# Pluggable Authentication Modules
#
# For Linux, see:
#
http://www.kernel.org/pub/linux/libs/pam/index.html
#
# WARNING: On many systems, the system PAM libraries have
#
memory leaks! We STRONGLY SUGGEST that you do not
#
use PAM for authentication, due to those memory leaks.
#
pam {
#
# The name to use for PAM authentication.
# PAM looks in /etc/pam.d/${pam_auth_name}
# for it's configuration. See 'redhat/radiusd-pam'
# for a sample PAM configuration file.
#
# Note that any Pam-Auth attribute set in the 'authorize'
# section will over-ride this one.
#
pam_auth = radiusd
}
# Unix /etc/passwd style authentication
#
unix {
#
# Cache /etc/passwd, /etc/shadow, and /etc/group
#
# The default is to NOT cache them.
#
# For FreeBSD and NetBSD, you do NOT want to enable
# the cache, as it's password lookups are done via a
# database, so set this value to 'no'.
#
# Some systems (e.g. RedHat Linux with pam_pwbd) can
# take *seconds* to check a password, when th passwd
# file containing 1000's of entries. For those systems,
# you should set the cache value to 'yes', and set
# the locations of the 'passwd', 'shadow', and 'group'
# files, below.
#
cache = no
# Reload the cache every 600 seconds (10mins). 0 to disable.
cache_reload = 600
#
# Define the locations of the normal passwd, shadow, and
# group files.
#
# 'shadow' is commented out by default, because not all
# systems have shadow passwords.
#
# To force the module to use the system password functions,
# instead of reading the files, leave the following entries
# commented out.
#
# This is required for some systems, like FreeBSD,
# and Mac OSX.
#
#
passwd = /etc/passwd
shadow = /etc/shadow
90
#
group = /etc/group
#
# The location of the "wtmp" file.
# This should be moved to it's own module soon.
#
# The only use for 'radlast'. If you don't use
# 'radlast', then you can comment out this item.
#
radwtmp = ${logdir}/radwtmp
}
#
#
#
#
#
$INCLUDE
Extensible Authentication Protocol
For all EAP related authentications.
Now in another file, because it is very large.
${confdir}/eap.conf
# Microsoft CHAP authentication
#
# This module supports MS-CHAP and MS-CHAPv2 authentication.
# It also enforces the SMB-Account-Ctrl attribute.
#
mschap {
#
# As of 0.9, the mschap module does NOT support
# reading from /etc/smbpasswd.
#
# If you are using /etc/smbpasswd, see the 'passwd'
# module for an example of how to use /etc/smbpasswd
# authtype value, if present, will be used
# to overwrite (or add) Auth-Type during
# authorization. Normally should be MS-CHAP
authtype = MS-CHAP
# if use_mppe is not set to no mschap will
# add MS-CHAP-MPPE-Keys for MS-CHAPv1 and
# MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2
#
#use_mppe = no
# if mppe is enabled require_encryption makes
# encryption moderate
#
#require_encryption = yes
# require_strong always requires 128 bit key
# encryption
#
#require_strong = yes
# Windows sends us a username in the form of
# DOMAIN\user, but sends the challenge response
# based on only the user portion. This hack
# corrects for that incorrect behavior.
#
#with_ntdomain_hack = no
# The module can perform authentication itself, OR
# use a Windows Domain Controller. This configuration
# directive tells the module to call the ntlm_auth
91
# program, which will do the authentication, and return
# the NT-Key. Note that you MUST have "winbindd" and
# "nmbd" running on the local machine for ntlm_auth
# to work. See the ntlm_auth program documentation
# for details.
#
# Be VERY careful when editing the following line!
#
#ntlm_auth
=
"/path/to/ntlm_auth
--request-nt-key
username=%{Stripped-User-Name:-%{User-Name:-None}}
challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
}
# Lightweight Directory Access Protocol (LDAP)
#
# This module definition allows you to use LDAP for
# authorization and authentication (Auth-Type := LDAP)
#
# See doc/rlm_ldap for description of configuration options
# and sample authorize{} and authenticate{} blocks
ldap {
server = "ldap.your.domain"
# identity = "cn=admin,o=My Org,c=UA"
# password = mypass
basedn = "o=My Org,c=UA"
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
# base_filter = "(objectclass=radiusprofile)"
# set this to 'yes' to use TLS encrypted connections
# to the LDAP database by using the StartTLS extended
# operation.
# The StartTLS operation is supposed to be used with normal
# ldap connections instead of using ldaps (port 689) connections
start_tls = no
#
#
#
#
#
#
tls_cacertfile = /path/to/cacert.pem
tls_cacertdir
= /path/to/ca/dir/
tls_certfile
= /path/to/radius.crt
tls_keyfile
= /path/to/radius.key
tls_randfile
= /path/to/rnd
tls_require_cert
= "demand"
# default_profile = "cn=radprofile,ou=dialup,o=My Org,c=UA"
# profile_attribute = "radiusProfileDn"
access_attr = "dialupAccess"
# Mapping of RADIUS dictionary attributes to LDAP
# directory attributes.
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
#
# NOTICE: The password_header directive is NOT case insensitive
#
# password_header = "{clear}"
#
# The server can usually figure this out on its own, and pull
# the correct User-Password or NT-Password from the database.
#
# Note that NT-Passwords MUST be stored as a 32-digit hex
# string, and MUST start off with "0x", such as:
#
92
---
#
0x000102030405060708090a0b0c0d0e0f
#
# Without the leading "0x", NT-Passwords will not work.
# This goes for NT-Passwords stored in SQL, too.
#
# password_attribute = userPassword
# groupname_attribute = cn
#
groupmembership_filter
"(|(&(objectClass=GroupOfNames)(member=%{LdapUserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))"
# groupmembership_attribute = radiusGroupName
timeout = 4
timelimit = 3
net_timeout = 1
# compare_check_items = yes
# do_xlat = yes
# access_attr_used_for_allow = yes
}
=
# passwd module allows to do authorization via any passwd-like
# file and to extract any attributes from these modules
#
# parameters are:
#
filename - path to filename
#
format - format for filename record. This parameters
#
correlates record in the passwd file and RADIUS
#
attributes.
#
#
Field marked as '*' is key field. That is, the parameter
#
with this name from the request is used to search for
#
the record from passwd file
#
Attribute marked as '=' is added to reply_itmes instead
#
of default configure_itmes
#
Attribute marked as '~' is added to request_items
#
#
Field marked as ',' may contain a comma separated list
#
of attributes.
#
authtype - if record found this Auth-Type is used to authenticate
#
user
#
hashsize - hashtable size. If 0 or not specified records are not
#
stored in memory and file is red on every request.
#
allowmultiplekeys - if few records for every key are allowed
#
ignorenislike - ignore NIS-related records
#
delimiter - symbol to use as a field separator in passwd file,
#
for format ':' symbol is always used. '\0', '\n' are
#
not allowed
#
# An example configuration for using /etc/smbpasswd.
#
#passwd etc_smbpasswd {
#
filename = /etc/smbpasswd
#
format
=
"*User-Name::LM-Password:NT-Password:SMB-Account-CTRLTEXT::"
#
authtype = MS-CHAP
#
hashsize = 100
#
ignorenislike = no
#
allowmultiplekeys = no
#}
#
#
#
Similar configuration, for the /etc/group file. Adds a Group-Name
attribute for every group that the user is member of.
93
#passwd etc_group {
#
filename = /etc/group
#
format = "=Group-Name:::*,User-Name"
#
hashsize = 50
#
ignorenislike = yes
#
allowmultiplekeys = yes
#
delimiter = ":"
#}
# Realm module, for proxying.
#
# You can have multiple instances of the realm module to
# support multiple realm syntaxs at the same time. The
# search order is defined by the order in the authorize and
# preacct sections.
#
# Four config options:
#
format
- must be 'prefix' or 'suffix'
#
delimiter
- must be a single character
#
ignore_default - set to 'yes' or 'no'
#
ignore_null
- set to 'yes' or 'no'
#
# ignore_default and ignore_null can be set to 'yes' to prevent
# the module from matching against DEFAULT or NULL realms. This
# may be useful if you have have multiple instances of the
# realm module.
#
# They both default to 'no'.
#
# 'realm/username'
#
# Using this entry, IPASS users have their realm set to "IPASS".
realm IPASS {
format = prefix
delimiter = "/"
ignore_default = no
ignore_null = no
}
# 'username@realm'
#
realm suffix {
format = suffix
delimiter = "@"
ignore_default = no
ignore_null = no
}
# 'username%realm'
#
realm realmpercent {
format = suffix
delimiter = "%"
ignore_default = no
ignore_null = no
}
#
# 'domain\user'
#
realm ntdomain {
format = prefix
94
delimiter = "\\"
ignore_default = no
ignore_null = no
}
# A simple value checking module
#
# It can be used to check if an attribute value in the request
# matches a (possibly multi valued) attribute in the check
# items This can be used for example for caller-id
# authentication. For the module to run, both the request
# attribute and the check items attribute must exist
#
# i.e.
# A user has an ldap entry with 2 radiusCallingStationId
# attributes with values "12345678" and "12345679". If we
# enable rlm_checkval, then any request which contains a
# Calling-Station-Id with one of those two values will be
# accepted. Requests with other values for
# Calling-Station-Id will be rejected.
#
# Regular expressions in the check attribute value are allowed
# as long as the operator is '=~'
#
checkval {
# The attribute to look for in the request
item-name = Calling-Station-Id
# The attribute to look for in check items. Can be multi valued
check-name = Calling-Station-Id
# The data type. Can be
# string,integer,ipaddr,date,abinary,octets
data-type = string
# If set to yes and we dont find the item-name attribute in the
# request then we send back a reject
# DEFAULT is no
#notfound-reject = no
}
# rewrite arbitrary packets. Useful in accounting and authorization.
#
#
# The module can also use the Rewrite-Rule attribute. If it
# is set and matches the name of the module instance, then
# that module instance will be the only one which runs.
#
# Also if new_attribute is set to yes then a new attribute
# will be created containing the value replacewith and it
#
will be added to searchin (packet, reply, proxy, proxy_reply or
config).
# searchfor,ignore_case and max_matches will be ignored in that case.
#
# Backreferences are supported: %{0} will contain the string the whole
match
# and %{1} to %{8} will contain the contents of the 1st to the 8th
parentheses
#
# If max_matches is greater than one the backreferences will correspond to
the
# first match
95
#
#attr_rewrite sanecallerid {
#
attribute = Called-Station-Id
# may be "packet", "reply", "proxy", "proxy_reply" or "config"
#
searchin = packet
#
searchfor = "[+ ]"
#
replacewith = ""
#
ignore_case = no
#
new_attribute = no
#
max_matches = 10
#
## If set to yes then the replace string will be appended to the
original string
#
append = no
#}
# Preprocess the incoming RADIUS request, before handing it off
# to other modules.
#
# This module processes the 'huntgroups' and 'hints' files.
# In addition, it re-writes some weird attributes created
# by some NASes, and converts the attributes into a form which
# is a little more standard.
#
preprocess {
huntgroups = ${confdir}/huntgroups
hints = ${confdir}/hints
# This hack changes Ascend's wierd port numberings
# to standard 0-??? port numbers so that the "+" works
# for IP address assignments.
with_ascend_hack = no
ascend_channels_per_line = 23
# Windows NT machines often authenticate themselves as
# NT_DOMAIN\username
#
# If this is set to 'yes', then the NT_DOMAIN portion
# of the user-name is silently discarded.
#
# This configuration entry SHOULD NOT be used.
# See the "realms" module for a better way to handle
# NT domains.
with_ntdomain_hack = no
# Specialix Jetstream 8500 24 port access server.
#
# If the user name is 10 characters or longer, a "/"
# and the excess characters after the 10th are
# appended to the user name.
#
# If you're not running that NAS, you don't need
# this hack.
with_specialix_jetstream_hack = no
#
#
#
#
#
#
#
#
#
96
Cisco sends it's VSA attributes with the attribute
name *again* in the string, like:
H323-Attribute = "h323-attribute=value".
If this configuration item is set to 'yes', then
the redundant data in the the attribute text is stripped
out. The result is:
# H323-Attribute = "value"
#
# If you're not running a Cisco NAS, you don't need
# this hack.
with_cisco_vsa_hack = no
}
# Livingston-style 'users' file
#
files {
usersfile = ${confdir}/users
acctusersfile = ${confdir}/acct_users
# If you want to use the old Cistron 'users' file
# with FreeRADIUS, you should change the next line
# to 'compat = cistron'. You can the copy your 'users'
# file from Cistron.
compat = no
}
# Write a detailed log of all accounting records received.
#
detail {
# Note that we do NOT use NAS-IP-Address here, as
# that attribute MAY BE from the originating NAS, and
# NOT from the proxy which actually sent us the
# request. The Client-IP-Address attribute is ALWAYS
# the address of the client which sent us the
# request.
#
# The following line creates a new detail file for
# every radius client (by IP address or hostname).
# In addition, a new detail file is created every
# day, so that the detail file doesn't have to go
# through a 'log rotation'
#
# If your detail files are large, you may also want
# to add a ':%H' (see doc/variables.txt) to the end
# of it, to create a new detail file every hour, e.g.:
#
#
..../detail-%Y%m%d:%H
#
# This will create a new detail file for every hour.
#
detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d
#
# The Unix-style permissions on the 'detail' file.
#
# The detail file often contains secret or private
# information about users. So by keeping the file
# permissions restrictive, we can prevent unwanted
# people from seeing that information.
detailperm = 0600
}
#
#
#
#
#
#
#
Many people want to log authentication requests.
Rather than modifying the server core to print out more
messages, we can use a different instance of the 'detail'
module, to log the authentication requests to a file.
You will also need to un-comment the 'auth_log' line
97
# in the 'authorize' section, below.
#
detail auth_log {
detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail-%Y%m%d
#
# This MUST be 0600, otherwise anyone can read
# the users passwords!
detailperm = 0600
}
#
# This module logs authentication reply packets sent
# to a NAS. Both Access-Accept and Access-Reject packets
# are logged.
#
# You will also need to un-comment the 'reply_log' line
# in the 'post-auth' section, below.
#
# detail reply_log {
#
detailfile
=
${radacctdir}/%{Client-IP-Address}/reply-detail%Y%m%d
#
# detailperm = 0600
# }
#
# This module logs packets proxied to a home server.
#
# You will also need to un-comment the 'pre_proxy_log' line
# in the 'pre-proxy' section, below.
#
# detail pre_proxy_log {
# detailfile = ${radacctdir}/%{Client-IP-Address}/pre-proxy-detail%Y%m%d
#
# detailperm = 0600
# }
#
# This module logs response packets from a home server.
#
# You will also need to un-comment the 'post_proxy_log' line
# in the 'post-proxy' section, below.
#
# detail post_proxy_log {
# detailfile = ${radacctdir}/%{Client-IP-Address}/post-proxy-detail%Y%m%d
#
# detailperm = 0600
# }
# Create a unique accounting session Id. Many NASes re-use or
# repeat values for Acct-Session-Id, causing no end of
98
# confusion.
#
# This module will add a (probably) unique session id
# to an accounting packet based on the attributes listed
# below found in the packet. See doc/rlm_acct_unique for
# more information.
#
acct_unique {
key = "User-Name, Acct-Session-Id, NAS-IP-Address,
Address, NAS-Port"
}
Client-IP-
# Include another file that has the SQL-related configuration.
# This is another file only because it tends to be big.
#
# The following configuration file is for use with MySQL.
#
# For Postgresql, use:
${confdir}/postgresql.conf
# For MS-SQL, use:
${confdir}/mssql.conf
# For Oracle, use:
${confdir}/oraclesql.conf
#
$INCLUDE ${confdir}/sql.conf
#
#
#
#
#
#
#
For Cisco VoIP specific accounting with Postgresql,
use:
${confdir}/pgsql-voip.conf
You will also need the sql schema from:
src/billing/cisco_h323_db_schema-postgres.sql
Note: This config can be use AS WELL AS the standard sql
config if you need SQL based Auth
# Write a 'utmp' style file, of which users are currently
# logged in, and where they've logged in from.
#
# This file is used mainly for Simultaneous-Use checking,
# and also 'radwho', to see who's currently logged in.
#
radutmp {
# Where the file is stored. It's not a log file,
# so it doesn't need rotating.
#
filename = ${logdir}/radutmp
# The field in the packet to key on for the
# 'user' name, If you have other fields which you want
# to use to key on to control Simultaneous-Use,
# then you can use them here.
#
# Note, however, that the size of the field in the
# 'utmp' data structure is small, around 32
# characters, so that will limit the possible choices
# of keys.
#
# You may want instead: %{Stripped-User-Name:-%{User-Name}}
username = %{User-Name}
#
#
#
Whether or not we want to treat "user" the same
as "USER", or "User". Some systems have problems
with case sensitivity, so this should be set to
99
# 'no' to enable the comparisons of the key attribute
# to be case insensitive.
#
case_sensitive = yes
# Accounting information may be lost, so the user MAY
# have logged off of the NAS, but we haven't noticed.
# If so, we can verify this information with the NAS,
#
# If we want to believe the 'utmp' file, then this
# configuration entry can be set to 'no'.
#
check_with_nas = yes
# Set the file permissions, as the contents of this file
# are usually private.
perm = 0600
callerid = "yes"
}
# "Safe" radutmp - does not contain caller ID, so it can be
# world-readable, and radwho can work for normal users, without
# exposing any information that isn't already exposed by who(1).
#
# This is another 'instance' of the radutmp module, but it is given
# then name "sradutmp" to identify it later in the "accounting"
# section.
radutmp sradutmp {
filename = ${logdir}/sradutmp
perm = 0644
callerid = "no"
}
# attr_filter - filters the attributes received in replies from
# proxied servers, to make sure we send back to our RADIUS client
# only allowed attributes.
attr_filter {
attrsfile = ${confdir}/attrs
}
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
100
counter module:
This module takes an attribute (count-attribute).
It also takes a key, and creates a counter for each unique
key. The count is incremented when accounting packets are
received by the server. The value of the increment depends
on the attribute type.
If the attribute is Acct-Session-Time or of an integer type we add the
value of the attribute. If it is anything else we increase the
counter by one.
The 'reset' parameter defines when the counters are all reset to
zero. It can be hourly, daily, weekly, monthly or never.
hourly: Reset on 00:00 of every hour
daily: Reset on 00:00:00 every day
weekly: Reset on 00:00:00 on sunday
monthly: Reset on 00:00:00 of the first day of each month
It can also be user defined. It should be of the form:
num[hdwm] where:
h: hours, d: days, w: weeks, m: months
If the letter is ommited days will be assumed. In example:
# reset = 10h (reset every 10 hours)
# reset = 12 (reset every 12 days)
#
#
# The check-name attribute defines an attribute which will be
# registered by the counter module and can be used to set the
# maximum allowed value for the counter after which the user
# is rejected.
# Something like:
#
# DEFAULT Max-Daily-Session := 36000
#
Fall-Through = 1
#
# You should add the counter module in the instantiate
# section so that it registers check-name before the files
# module reads the users file.
#
# If check-name is set and the user is to be rejected then we
# send back a Reply-Message and we log a Failure-Message in
# the radius.log
# If the count attribute is Acct-Session-Time then on each login
# we send back the remaining online time as a Session-Timeout attribute
#
# The counter-name can also be used instead of using the check-name
# like below:
#
# DEFAULT Daily-Session-Time > 3600, Auth-Type = Reject
#
Reply-Message = "You've used up more than one hour today"
#
# The allowed-servicetype attribute can be used to only take
# into account specific sessions. For example if a user first
# logs in through a login menu and then selects ppp there will
# be two sessions. One for Login-User and one for Framed-User
# service type. We only need to take into account the second one.
#
# The module should be added in the instantiate, authorize and
# accounting sections. Make sure that in the authorize
# section it comes after any module which sets the
# 'check-name' attribute.
#
counter daily {
filename = ${raddbdir}/db.daily
key = User-Name
count-attribute = Acct-Session-Time
reset = daily
counter-name = Daily-Session-Time
check-name = Max-Daily-Session
allowed-servicetype = Framed-User
cache-size = 5000
}
# The "always" module is here for debugging purposes. Each
# instance simply returns the same result, always, without
# doing anything.
always fail {
rcode = fail
}
always reject {
rcode = reject
}
always ok {
rcode = ok
simulcount = 0
101
mpp = no
}
#
# The 'expression' module currently has no configuration.
#
# This module is useful only for 'xlat'. To use it,
# put 'exec' into the 'instantiate' section. You can then
# do dynamic translation of attributes like:
#
# Attribute-Name = `%{expr:2 + 3 + %{exec: uid -u}}`
#
# The value of the attribute will be replaced with the output
# of the program which is executed. Due to RADIUS protocol
# limitations, any output over 253 bytes will be ignored.
expr {
}
#
# The 'digest' module currently has no configuration.
#
# "Digest" authentication against a Cisco SIP server.
# See 'doc/rfc/draft-sterman-aaa-sip-00.txt' for details
# on performing digest authentication for Cisco SIP servers.
#
digest {
}
#
# Execute external programs
#
# This module is useful only for 'xlat'. To use it,
# put 'exec' into the 'instantiate' section. You can then
# do dynamic translation of attributes like:
#
# Attribute-Name = `%{exec:/path/to/program args}`
#
# The value of the attribute will be replaced with the output
# of the program which is executed. Due to RADIUS protocol
# limitations, any output over 253 bytes will be ignored.
#
# The RADIUS attributes from the user request will be placed
# into environment variables of the executed program, as
# described in 'doc/variables.txt'
#
exec {
wait = yes
input_pairs = request
}
#
# This is a more general example of the execute module.
#
# This one is called "echo".
#
# Attribute-Name = `%{echo:/path/to/program args}`
#
# If you wish to execute an external program in more than
# one section (e.g. 'authorize', 'pre_proxy', etc), then it
# is probably best to define a different instance of the
# 'exec' module for every section.
#
exec echo {
102
#
# Wait for the program to finish.
#
# If we do NOT wait, then the program is "fire and
# forget", and any output attributes from it are ignored.
#
# If we are looking for the program to output
# attributes, and want to add those attributes to the
# request, then we MUST wait for the program to
# finish, and therefore set 'wait=yes'
#
wait = yes
#
# The name of the program to execute, and it's
# arguments. Dynamic translation is done on this
# field, so things like the following example will
# work.
#
program = "/bin/echo %{User-Name}"
#
# The attributes which are placed into the
# environment variables for the program.
#
#
#
request
attributes from the request
#
config
attributes from the configuration items list
#
reply
attributes from the reply
#
proxy-request
attributes from the proxy request
#
proxy-reply attributes from the proxy reply
#
# Note that some attributes may not exist at some
# stages. e.g. There may be no proxy-reply
# attributes if this module is used in the
# 'authorize' section.
#
input_pairs = request
#
# Where to place the output attributes (if any) from
# the executed program. The values allowed, and the
# restrictions as to availability, are the same as
# for the input_pairs.
#
output_pairs = reply
#
#
#
#
#
#
#
#
#
#
#
#
#
#
When to execute the program. If the packet
type does NOT match what's listed here, then
the module does NOT execute the program.
For a list of allowed packet types, see
the 'dictionary' file, and look for VALUEs
of the Packet-Type attribute.
By default, the module executes on ANY packet.
Un-comment out the following line to tell the
module to execute only if an Access-Accept is
being sent to the NAS.
103
#packet_type = Access-Accept
}
# Do server side ip pool management. Should be added in post-auth and
# accounting sections.
#
# The module also requires the existance of the Pool-Name
# attribute. That way the administrator can add the Pool-Name
# attribute in the user profiles and use different pools
# for different users. The Pool-Name attribute is a *check* item not
# a reply item.
#
# Example:
# radiusd.conf: ippool students { [...] }
# users file : DEFAULT Group == students, Pool-Name := "students"
#
# ********* IF YOU CHANGE THE RANGE PARAMETERS YOU MUST *********
# ********* THEN ERASE THE DB FILES
*********
#
ippool main_pool {
# range-start,range-stop: The start and end ip
# addresses for the ip pool
range-start = 192.168.1.1
range-stop = 192.168.3.254
# netmask: The network mask used for the ip's
netmask = 255.255.255.0
# cache-size: The gdbm cache size for the db
# files. Should be equal to the number of ip's
# available in the ip pool
cache-size = 800
# session-db: The main db file used to allocate ip's to clients
session-db = ${raddbdir}/db.ippool
# ip-index: Helper db index file used in multilink
ip-index = ${raddbdir}/db.ipindex
# override: Will this ippool override a Framed-IP-Address already
set
override = no
# maximum-timeout: If not zero specifies the maximum time in seconds
an
# entry may be active. Default: 0
maximum-timeout = 0
}
# ANSI X9.9 token support. Not included by default.
# $INCLUDE ${confdir}/x99.conf
}
# Instantiation
#
# This section orders the loading of the modules. Modules
# listed here will get loaded BEFORE the later sections like
# authorize, authenticate, etc. get examined.
#
# This section is not strictly needed. When a section like
# authorize refers to a module, it's automatically loaded and
104
# initialized. However, some modules may not be listed in any
# of the following sections, so they can be listed here.
#
# Also, listing modules here ensures that you have control over
# the order in which they are initalized. If one module needs
# something defined by another module, you can list them in order
# here, and ensure that the configuration will be OK.
#
instantiate {
#
# Allows the execution of external scripts.
# The entire command line (and output) must fit into 253 bytes.
#
# e.g. Framed-Pool = `%{exec:/bin/echo foo}`
exec
#
# The expression module doesn't do authorization,
# authentication, or accounting. It only does dynamic
# translation, of the form:
#
#
Session-Timeout = `%{expr:2 + 3}`
#
# So the module needs to be instantiated, but CANNOT be
# listed in any other section. See 'doc/rlm_expr' for
# more information.
#
expr
#
}
#
# We add the counter module here so that it registers
# the check-name attribute before any module which sets
# it
daily
# Authorization. First preprocess (hints and huntgroups files),
# then realms, and finally look in the "users" file.
#
# The order of the realm modules will determine the order that
# we try to find a matching realm.
#
# Make *sure* that 'preprocess' comes before any realm if you
# need to setup hints for the remote radius server
authorize {
#
# The preprocess module takes care of sanitizing some bizarre
# attributes in the request, and turning them into attributes
# which are more standard.
#
# It takes care of processing the 'raddb/hints' and the
# 'raddb/huntgroups' files.
#
# It also adds the %{Client-IP-Address} attribute to the request.
preprocess
#
# If you want to have a log of authentication requests,
# un-comment the following line, and the 'detail auth_log'
# section, above.
auth_log
#
attr_filter
105
#
# The chap module will set 'Auth-Type := CHAP' if we are
# handling a CHAP request and Auth-Type has not already been set
chap
#
# If the users are logging in with an MS-CHAP-Challenge
# attribute for authentication, the mschap module will find
# the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP'
# to the request, which will cause the server to then use
# the mschap module for authentication.
mschap
#
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authenticate' section.
digest
#
#
# Look for IPASS style 'realm/', and if not found, look for
# '@realm', and decide whether or not to proxy, based on
# that.
IPASS
#
#
# If you are using multiple kinds of realms, you probably
# want to set "ignore_null = yes" for all of them.
# Otherwise, when the first style of realm doesn't match,
# the other styles won't be checked.
#
suffix
ntdomain
#
#
# authentication.
#
eap
#
# Read the 'users' file
files
#
#
# Look in an SQL database. The schema of the database
# is meant to mirror the "users" file.
#
# See "Authorization Queries" in sql.conf
sql
#
#
# If you are using /etc/smbpasswd, and are also doing
# mschap authentication, the un-comment this line, and
# configure the 'etc_smbpasswd' module, above.
etc_smbpasswd
#
#
#
106
The ldap module will set Auth-Type to LDAP if it has not
already been set
#
ldap
#
#
# Enforce daily limits on time spent logged in.
daily
#
}
#
#
#
#
#
#
#
#
#
#
# Use the checkval module
checkval
Authentication.
This section lists which modules are available for authentication.
Note that it does NOT mean 'try each module in order'. It means
that a module from the 'authorize' section adds a configuration
attribute 'Auth-Type := FOO'. That authentication type is then
used to pick the apropriate module from the list below.
# In general, you SHOULD NOT set the Auth-Type attribute. The server
# will figure it out on its own, and will do the right thing. The
# most common side effect of erroneously setting the Auth-Type
# attribute is that one authentication method will work, but the
# others will not.
#
# The common reasons to set the Auth-Type attribute by hand
# is to either forcibly reject the user, or forcibly accept him.
#
authenticate {
#
# PAP authentication, when a back-end database listed
# in the 'authorize' section supplies a password. The
# password can be clear-text, or encrypted.
Auth-Type PAP {
pap
}
#
# Most people want CHAP authentication
# A back-end database listed in the 'authorize' section
# MUST supply a CLEAR TEXT password. Encrypted passwords
# won't work.
Auth-Type CHAP {
chap
}
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
#
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authorize' section.
digest
#
#
Pluggable Authentication Modules.
107
#
pam
#
# See 'man getpwent' for information on how the 'unix'
# module checks the users password. Note that packets
# containing CHAP-Password attributes CANNOT be authenticated
# against /etc/passwd! See the FAQ for details.
#
unix
#
#
#
#
}
# Uncomment it if you want to use ldap for authentication
#
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password.
Auth-Type LDAP {
ldap
}
#
eap
#
# Pre-accounting.
#
preacct {
preprocess
Decide which accounting type to use.
#
# Ensure that we have a semi-unique identifier for every
# request, and many NAS boxes are broken.
acct_unique
#
#
#
# Look for IPASS-style 'realm/', and if not found, look for
# '@realm', and decide whether or not to proxy, based on
# that.
#
# Accounting requests are generally proxied to the same
# home server as authentication requests.
IPASS
suffix
ntdomain
#
# Read the 'acct_users' file
files
}
#
# Accounting. Log the accounting data.
#
accounting {
#
# Create a 'detail'ed log of the packets.
# Note that accounting requests which are proxied
# are also logged in the detail file.
detail
#
daily
108
# Update the wtmp file
#
# If you don't use "radlast", you can delete this line.
unix
#
#
# For Simultaneous-Use tracking.
#
# Due to packet losses in the network, the data here
# may be incorrect. There is little we can do about it.
radutmp
sradutmp
#
# Return an address to the IP Pool when we see a stop record.
main_pool
#
#
# Log traffic to an SQL database.
#
# See "Accounting queries" in sql.conf
sql
#
# Cisco VoIP specific bulk accounting
pgsql-voip
}
# Session database, used for checking Simultaneous-Use. Either the radutmp
# or rlm_sql module can handle this.
# The rlm_sql module is *much* faster
session {
radutmp
#
}
#
# See "Simultaneous Use Checking Querie" in sql.conf
sql
# Post-Authentication
# Once we KNOW that the user has been authenticated, there are
# additional steps we can take.
post-auth {
# Get an address from the IP Pool.
#
main_pool
#
#
# If you want to have a log of authentication replies,
# un-comment the following line, and the 'detail reply_log'
# section, above.
reply_log
#
#
# After authenticating the user, do another SQL qeury.
#
# See "Authentication Logging Queries" in sql.conf
sql
#
#
#
Access-Reject packets are sent through the REJECT sub-section
of the post-auth section.
109
#
#
#
#
Post-Auth-Type REJECT {
insert-module-name-here
}
}
#
# When the server decides to proxy a request to a home server,
# the proxied request is first passed through the pre-proxy
# stage. This stage can re-write the request, or decide to
# cancel the proxy.
#
# Only a few modules currently have this method.
#
pre-proxy {
#
attr_rewrite
#
}
# If you want to have a log of packets proxied to a home
# server, un-comment the following line, and the
# 'detail pre_proxy_log' section, above.
pre_proxy_log
#
# When the server receives a reply to a request it proxied
# to a home server, the request may be massaged here, in the
# post-proxy stage.
#
post-proxy {
#
#
# If you want to have a log of replies from a home server,
# un-comment the following line, and the 'detail post_proxy_log'
# section, above.
post_proxy_log
#
attr_rewrite
#
#
#
Uncomment the following line if you want to filter replies from
remote proxies based on the rules defined in the 'attrs' file.
attr_filter
#
# If you are proxying LEAP, you MUST configure the EAP
# module, and you MUST list it here, in the post-proxy
# stage.
#
# You MUST also use the 'nostrip' option in the 'realm'
# configuration. Otherwise, the User-Name attribute
# in the proxied request will not match the user name
# hidden inside of the EAP packet, and the end server will
# reject the EAP request.
#
eap
}
110
Appendice A2
#
# clients.conf - client configuration directives
#
#######################################################################
#######################################################################
#
# Definition of a RADIUS client (usually a NAS).
#
# The information given here over rides anything given in the
# 'clients' file, or in the 'naslist' file. The configuration here
# contains all of the information from those two files, and allows
# for more configuration items.
#
# The "shortname" is be used for logging. The "nastype", "login" and
# "password" fields are mainly used for checkrad and are optional.
#
111
#
# Defines a RADIUS client. The format is 'client [hostname|ip-address]'
#
# '127.0.0.1' is another name for 'localhost'. It is enabled by default,
# to allow testing of the server after an initial installation. If you
# are not going to be permitting RADIUS queries from localhost, we suggest
# that you delete, or comment out, this entry.
#
client 127.0.0.1 {
#
# The shared secret use to "encrypt" and "sign" packets between
# the NAS and FreeRADIUS. You MUST change this secret from the
# default, otherwise it's not a secret any more!
#
# The secret can be any string, up to 32 characters in length.
#
secret
= testing123
#
# The short name is used as an alias for the fully qualified
# domain name, or the IP address.
#
shortname
= localhost
#
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous use checks
#
#
# The nastype tells 'checkrad.pl' which NAS-specific method to
# use to query the NAS for simultaneous use.
#
# Permitted NAS types are:
#
#
cisco
#
computone
#
livingston
#
max40xx
#
multitech
#
netserver
#
pathras
#
patton
#
portslave
#
tc
#
usrhiper
#
other
# for all other types
#
nastype
#
#
}
= other
# localhost isn't usually a NAS...
#
# The following two configurations are for future use.
# The 'naspasswd' file is currently used to store the NAS
# login name and password, which is used by checkrad.pl
# when querying the NAS for simultaneous use.
#
login
= !root
password
= someadminpas
#client some.host.org {
#
secret
= testing123
112
#
#}
shortname
= localhost
#
# You can now specify one secret for a network of clients.
# When a client request comes in, the BEST match is chosen.
# i.e. The entry from the smallest possible network.
#
#client 192.168.0.0/24 {
#
secret
= testing123-1
#
shortname
= private-network-1
#}
#
#client 192.168.0.0/16 {
#
secret
= testing123-2
#
shortname
= private-network-2
#}
#client 10.10.10.10 {
#
# secret and password are mapped through the "secrets" file.
#
secret
= testing123
#
shortname
= liv1
#
# the following three fields are optional, but may be used by
#
# checkrad.pl for simultaneous usage checks
#
nastype
= livingston
#
login
= !root
#
password
= someadminpas
#}
Appendice A3
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
Please read the documentation file ../doc/processing_users_file,
or 'man 5 users' (after installing the server) for more information.
This file contains authentication security and configuration
information for each user. Accounting requests are NOT processed
through this file. Instead, see 'acct_users', in this directory.
The first field is the user's name and can be up to
253 characters in length. This is followed (on the same line) with
the list of authentication requirements for that user. This can
include password, comm server name, comm server port number, protocol
type (perhaps set by the "hints" file), and huntgroup name (set by
the "huntgroups" file).
If you are not sure why a particular reply is being sent by the
server, then run the server in debugging mode (radiusd -X), and
113
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
you will see which entries in this file are matched.
When an authentication request is received from the comm server,
these values are tested. Only the first match is used unless the
"Fall-Through" variable is set to "Yes".
A special user named "DEFAULT" matches on all usernames.
You can have several DEFAULT entries. All entries are processed
in the order they appear in this file. The first entry that
matches the login-request will stop processing unless you use
the Fall-Through variable.
If you use the database support to turn this file into a .db or .dbm
file, the DEFAULT entries _have_ to be at the end of this file and
you can't have multiple entries for one username.
You don't need to specify a password if you set Auth-Type += System
on the list of authentication requirements. The RADIUS server
will then check the system password file.
Indented (with the tab character) lines following the first
line indicate the configuration values to be passed back to
the comm server to allow the initiation of a user session.
This can include things like the PPP configuration values
or the host to log the user onto.
You can include another `users' file with `$INCLUDE users.other'
For a list of RADIUS attributes, and links to their definitions,
see:
http://www.freeradius.org/rfc/attributes.html
#
# Deny access for a specific user. Note that this entry MUST
# be before any other 'Auth-Type' attribute which results in the user
# being authenticated.
#
# Note that there is NO 'Fall-Through' attribute, so the user will not
# be given any additional resources.
#
#lameuser
Auth-Type := Reject
#
Reply-Message = "Your account has been disabled."
#
# Deny access for a group of users.
#
# Note that there is NO 'Fall-Through' attribute, so the user will not
# be given any additional resources.
#
#DEFAULT
Group == "disabled", Auth-Type := Reject
#
Reply-Message = "Your account has been disabled."
#
#
# This is a complete entry for "steve". Note that there is no Fall-Through
# entry so that no DEFAULT entry will be used, and the user will NOT
# get any attributes in addition to the ones listed here.
#
#steve
Auth-Type := Local, User-Password == "testing"
114
#
#
#
#
#
#
#
#
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 172.16.3.33,
Framed-IP-Netmask = 255.255.255.0,
Framed-Routing = Broadcast-Listen,
Framed-Filter-Id = "std.ppp",
Framed-MTU = 1500,
Framed-Compression = Van-Jacobsen-TCP-IP
#
# This is an entry for a user with a space in their name.
# Note the double quotes surrounding the name.
#
#"John Doe" Auth-Type := Local, User-Password == "hello"
#
Reply-Message = "Hello, %u"
#
# Dial user back and telnet to the default host for that port
#
#Deg Auth-Type := Local, User-Password == "ge55ged"
#
Service-Type = Callback-Login-User,
#
Login-IP-Host = 0.0.0.0,
#
Callback-Number = "9,5551212",
#
Login-Service = Telnet,
#
Login-TCP-Port = Telnet
#
# Another complete entry. After the user "dialbk" has logged in, the
# connection will be broken and the user will be dialed back after which
# he will get a connection to the host "timeshare1".
#
#dialbk
Auth-Type := Local, User-Password == "callme"
#
Service-Type = Callback-Login-User,
#
Login-IP-Host = timeshare1,
#
Login-Service = PortMaster,
#
Callback-Number = "9,1-800-555-1212"
#
# user "swilson" will only get a static IP number if he
# a framed protocol on a terminal server in Alphen (see
#
# Note that by setting "Fall-Through", other attributes
# the following DEFAULT entries
#
#swilson
Service-Type == Framed-User, Huntgroup-Name
#
#
Fall-Through = Yes
logs in with
the huntgroups file).
will be added from
== "alphen"
#
# If the user logs in as 'username.shell', then authenticate them
# against the system database, give them shell access, and stop processing
# the rest of the file.
#
#DEFAULT
Suffix == ".shell", Auth-Type := System
#
Service-Type = Login-User,
#
Login-Service = Telnet,
#
Login-IP-Host = your.shell.machine
#
# The rest of this file contains the several DEFAULT entries.
# DEFAULT entries match with all login names.
# Note that DEFAULT entries can also Fall-Through (see first entry).
115
# A name-value pair from a DEFAULT entry will _NEVER_ override
# an already existing name-value pair.
#
#
# First setup all accounts to be checked against the UNIX /etc/passwd.
# (Unless a password was already given earlier in this file).
#
DEFAULT
Auth-Type = System
Fall-Through = 1
#
# Set up different IP address pools for the terminal servers.
# Note that the "+" behind the IP address means that this is the "base"
# IP address. The Port-Id (S0, S1 etc) will be added to it.
#
#DEFAULT
Service-Type == Framed-User, Huntgroup-Name == "alphen"
#
Framed-IP-Address = 192.168.1.32+,
#
Fall-Through = Yes
#DEFAULT
#
#
Service-Type == Framed-User, Huntgroup-Name == "delft"
Framed-IP-Address = 192.168.2.32+,
Fall-Through = Yes
#
# Defaults for all framed connections.
#
DEFAULT
Service-Type == Framed-User
Framed-MTU = 576,
Service-Type = Framed-User,
Fall-Through = Yes
#
# Default for PPP: dynamic IP address, PPP mode, VJ-compression.
# NOTE: we do not use Hint = "PPP", since PPP might also be auto-detected
#
by the terminal server in which case there may not be a "P" suffix.
#
The terminal server sends "Framed-Protocol = PPP" for auto PPP.
#
DEFAULT
Framed-Protocol == PPP
Framed-Protocol = PPP,
Framed-Compression = Van-Jacobson-TCP-IP
#
# Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression.
#
DEFAULT
Hint == "CSLIP"
Framed-Protocol = SLIP,
Framed-Compression = Van-Jacobson-TCP-IP
#
# Default for SLIP: dynamic IP address, SLIP mode.
#
DEFAULT
Hint == "SLIP"
Framed-Protocol = SLIP
#
# Last default: rlogin to our main server.
#
#DEFAULT
#
Service-Type = Login-User,
#
Login-Service = Rlogin,
#
Login-IP-Host = shellbox.ispdomain.com
116
#
#
#
#
#
#
# Last default: shell on the local terminal server.
#
DEFAULT
Service-Type = Shell-User
# On no match, the user is denied access.
Appendice A4
#
#
#
#
#
#
#
#
Whatever you do, do NOT set 'Auth-Type := EAP'. The server
is smart enough to figure this out on its own. The most
common side effect of setting 'Auth-Type := EAP' is that the
users then cannot use ANY other authentication method.
$Id: eap.conf,v 1.4 2004/04/15 18:34:41 aland Exp $
eap {
#
#
#
#
#
#
#
#
#
Invoke the default supported EAP type when
EAP-Identity response is received.
The incoming EAP messages DO NOT specify which EAP
type they will be using, so it MUST be set here.
For now, only one default EAP type may be used at a time.
If the EAP-Type attribute is set by another module,
117
#
# A list is maintained to correlate EAP-Response
# packets with EAP-Request packets. After a
# configurable length of time, entries in the list
# expire, and are deleted.
#
timer_expire
= 60
# There are many EAP types, but the server has support
# for only a limited subset. If the server receives
# a request for an EAP type it does not support, then
# it normally rejects the request. By setting this
# configuration to "yes", you can tell the server to
# instead keep processing the request. Another module
# MUST then be configured to proxy the request to
# another RADIUS server which supports that EAP type.
#
# If another module is NOT configured to handle the
# request, then the request will still end up being
# rejected.
ignore_unknown_eap_types = no
# Cisco AP1230B firmware 12.2(13)JA1 has a bug. When given
# a User-Name attribute in an Access-Accept, it copies one
# more byte than it should.
#
# We can work around it by configurably adding an extra
# zero byte.
cisco_accounting_username_bug = no
# Supported EAP-types
#
# We do NOT recommend using EAP-MD5 authentication
# for wireless connections. It is insecure, and does
# not provide for dynamic WEP keys.
#
md5 {
}
# Cisco LEAP
#
# We do not recommend using LEAP in new deployments. See:
# http://www.securiteam.com/tools/5TP012ACKE.html
#
# Cisco LEAP uses the MS-CHAP algorithm (but not
# the MS-CHAP attributes) to perform it's authentication.
#
# As a result, LEAP *requires* access to the plain-text
# User-Password, or the NT-Password attributes.
# 'System' authentication is impossible with LEAP.
#
leap {
}
#
#
#
#
118
Generic Token Card.
Currently, this is only permitted inside of EAP-TTLS,
or EAP-PEAP. The module "challenges" the user with
# text, and the response from the user is taken to be
# the User-Password.
#
# Proxying the tunneled EAP-GTC session is a bad idea,
# the users password will go over the wire in plain-text,
# for anyone to see.
#
gtc {
# The default challenge, which many clients
# ignore..
#challenge = "Password: "
# The plain-text response which comes back
# is put into a User-Password attribute,
# and passed to another module for
# authentication. This allows the EAP-GTC
# response to be checked against plain-text,
# or crypt'd passwords.
#
# If you say "Local" instead of "PAP", then
# the module will look for a User-Password
# configured for the request, and do the
# authentication itself.
#
auth_type = PAP
}
## EAP-TLS
#
# To generate ctest certificates, run the script
#
#
../scripts/certs.sh
#
# The documents on http://www.freeradius.org/doc
# are old, but may be helpful.
#
# See also:
#
#
#tls {
#
private_key_password = whatever
#
private_key_file = ${raddbdir}/certs/cert-srv.pem
#
# name.
certificate_file = ${raddbdir}/certs/cert-srv.pem
#
CA_file = ${raddbdir}/certs/demoCA/cacert.pem
#
#
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
#
#
#
#
#
#
#
This can never exceed the size of a RADIUS
packet (4096 bytes), and is preferably half
that, to accomodate other attributes in
RADIUS packet. On most APs the MAX packet
length is configured between 1500 - 1600
In these cases, fragment size should be
119
#
# 1024 or less.
#
#
#
#
# Check the Certificate Revocation List
#
#
#
check_crl = yes
#
#
#
#}
# The TTLS module implements the EAP-TTLS protocol,
# which can be described as EAP inside of Diameter,
# inside of TLS, inside of EAP, inside of RADIUS...
#
# Surprisingly, it works quite well.
#
# The TTLS module needs the TLS module to be installed
# have a client certificate. EAP-TTLS does not
#
#ttls {
# TTLS tunnel, we recommend using EAP-MD5.
# If the request does not contain an EAP
# conversation, then this configuration entry
# is ignored.
#
#
#
#
120
The tunneled authentication request does
not usually contain useful attributes
like 'Calling-Station-Id', etc. These
#
# attributes are outside of the tunnel,
# and normally unavailable to the tunneled
# authentication request.
#
# By setting this configuration entry to
# 'yes', any attribute which NOT in the
# tunneled authentication request, but
# which IS available outside of the tunnel,
# is copied to the tunneled request.
#
copy_request_to_tunnel = no
#
#
The reply attributes sent to the NAS are
# usually based on the name of the user
'outside' of the tunnel (usually
'anonymous'). If you want to send the
reply attributes based on the user name
inside of the tunnel, then set this
configuration entry to 'yes', and the reply
to the NAS will be taken from the reply to
the tunneled request.
#
#
#
#
#
#
#
#
use_tunneled_reply = no
#}
#
# The tunneled EAP session needs a default EAP type
# which is separate from the one for the non-tunneled
# EAP module. Inside of the TLS/PEAP tunnel, we
# recommend using EAP-MS-CHAPv2.
#
# The PEAP module needs the TLS module to be installed
# have a client certificate. EAP-PEAP does not
#
# peap {
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
#
default_eap_type = mschapv2
#}
#
#
#
#
#
#
#
#
#
#
This takes no configuration.
Note that it is the EAP MS-CHAPv2 sub-module, not
the main 'mschap' module.
Note also that in order for this sub-module to work,
the main 'mschap' module MUST ALSO be configured.
This module is the *Microsoft* implementation of MS-CHAPv2
121
# in EAP. There is another (incompatible) implementation
# of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not
# currently support.
#
mschapv2 {
}
}
122

INDICE - Linux.it

Transcript

Documenti analoghi

Progetto TRIP 2ª parte: 802.1x

Rivahouse - Agenzia Immobiliare,Immobilien,Real Estate Riva del

lingua inglese - Istituto Statale d`Istruzione Superiore Mattei

Modulo Area Alarms - Integra Solutions

1 2 3 4 TCM02 - esco

PROGRAMMAZIONE ANNUALE INDIVIDUALE

descrizione della prova d`esame ielts - Didattica

OFFICINE DI ENERGIA CATALOGO /CATALOGue

1: Install Module into SMV Terminal Cover 2: Install SMV Terminal