Sommario. Scopo del progetto

Transcript

1 AUTENTICAZIONE WiFi CON 802.1X Marco Anafi 18 Maggio 2006 Diario delle revisioni Revisione Maggio 2006 Prima versione del documento + appendice Sommario Introduzione teorica al protocollo 802.1x. Implementazione di un servizio di accesso ad una rete Wi-Fi che supporti il protocollo di autenticazione 802.1x utilizzando un access point "Cisco 1100", un server Radius e un database LDAP. Scopo del progetto Introduzione all autenticazione su reti Wireless con 802.1x Studio teorico del progetto X Lo standard di autenticazione l i EAP Certificati X Radius LDAP Progetto operativo Configurazione del server FreeRADIUS Configurazione dall AP (Cisco 1100) Configurazione del Supplicant Risultati ottenuti e conclusioni Risultati Conclusioni Possibili sviluppi futuri del progetto Bibliografia Appendice Integrabilità con il progetto TRIP TRIP (The Roaming INFN Physicist) Integrabilità Sviluppi futiri Scopo del progetto Lo scopo del progetto è quello d implementare una struttura che permetta agli utenti del dipartimento di Fisica di connettersi facilmente alla rete wireless dell edificio mantenendo comunque un buon grado si sicurezza. L autenticazione deve avvenire attraverso l utilizzo del protocollo 802.1x e non implicare l utilizzo di certificati da parte degli utenti. I dati riguardati le autorizzazioni sono già contenute nel server LDAP centrale dell università. 1

2 Schema di autenticazione Introduzione all autenticazione su reti Wireless con 802.1x Le reti WiFi soffrono del problema dell accesso non autorizzato molto più delle reti cablate. Ciò è ovvio se si tiene conto che se nelle ultime per potervi accedere è necessario un punto di accesso fisico (il socket RJ45), in quelle wireless basta trovarsi nel raggio di copertura della rete per potersi associare. Una prima soluzione al problema è stato il WEP (Wired Equivalent Privacy). Tuttavia, questo metodo, legato alla presenza di chiavi di crittografia simmetrica tanto sugli Access Point quanto su tutti i client autorizzati all accesso, scaricava sugli amministratori di rete l incombenza di cambiare periodicamente tali chiavi e di comunicare il cambiamento a tutti gli utenti. Il risultato di ciò era che le chiavi WEP rimanevano invariate per lunghi periodi rendendo insicura la rete. Con il protocollo 802.1x si è introdotta l autenticazione e il supporto alla gestione dinamica della chiavi WEP. In questo modo, una volta che il client si sia autenticato le chiavi con cui criptare il traffico wireless gli verranno fornite automaticamente e cambiate anche più volte durante la sessione di lavoro. Il periodo di validità delle chiavi è abbastanza breve tanto da renderle difficilmente determinabili da parte di un intruso che tenti un attacco. Dal punto di vista pratico, il protocollo 802.1x non è altro che il frame di autenticazione EAP (Extensible Authentication Protocol) che si utilizza per l autenticazione dei collegamenti point to point adattato per viaggiare in trame Ethernet invece che nei pacchetti PPP. In virtù di ciò il protocollo 802.1x è anche noto come EAPoL (EAP over LAN). Nella terminologia EAP le entità che entrano in gioco durante il processo di autenticazione sono: il supplicant, cioè il client che chiede di potersi associare alla rete fornendo le sue credenziali all authenticator; l authenticator che nel caso delle reti wireless coincide con l Access Point cioè colui che si occupa di applicare le security pocilies, prima di lasciar accedere ai servizi un supplicant; l authentication server che controlla se l utente è autorizzato ad accedere al servizio attraverso l authenticator. L authentication server coincide spesso con un server RADIUS, mentre l authenticator è quello che nel protocollo RADIUS viene definito NAS (Network Access Server). 2

3 Come detto in precedenza EAP è solo un frame di autenticazione che lascia al supplicant e all authentication server il compito di concordare il metodo di autenticazione da utilizzare effettivamente. Si noti che l Access Point è trasparente da questo punto di vista, poiché il suo unico compito è di trasmettere i pacchetti provenienti dal supplicant mediante EAPoL al server RADIUS incapsulandoli in IP (il server RADIUS è raggiungibile dalla parte wired dell AP) e viceversa. I metodi di autenticazione descritti di seguito sono tra quelli che danno maggiore garanzia di sicurezza e sono supportati da buona parte dei supplicant: EAP-TLS che usa TLS per la mutua autenticazione tra supplicant e Access Point. Sia il server RADIUS che il supplicant devono disporre di una chiave privata e del relativo certificato X.509. A parte l incombenza di dover dotare ogni utente del suo certificato, questo è sicuramente il metodo di autenticazione più sicuro e comodo poiché non è richiesto l inserimento di una password da parte dell utente; 3

4 PEAP (Protected EAP) che invece usa TLS per autenticare l Access Point e stabilire un tunnel crittografato in cui utilizzare MS-CHAPv2 per autenticare il supplicant con username e password. Il vantaggio di questo metodo è che solo il server RADIUS deve disporre di un certificato server e della chiave privata mentre l utente usa la stessa password utilizzata per autenticarsi con Kerberos 5 sugli altri servizi di rete. Apparentemente, tanto con EAP-TLS quanto con PEAP gli Access Point non dimostrano la loro identità nei confronti dei supplicant poiché non sono dotati di un certificato e di una chiave privata. In realtà non è così poiché gli Access Point condividono con RADIUS un segreto che li rende fidati nei confronti di quest ultimo. Tale fiducia permette a un supplicant che si fida di RADIUS (grazie al TLS) di fidarsi anche degli Access Point. Studio teorico del progetto 802.1X Schema dei protocolli Definizione dello standard 802.1X Un estratto dalla prima pagina dello documento che dichiara lo standard 802.1X rilasciato dalla IEEE nel Aprile del 2001 recita: 4

5 Funzionamento "Port-based network access control makes use of the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases which the authentication and authorization fails. A port in this context is a single point of attachment to the LAN infrastructure." X-2001, page 1. In pratica lo standard definisce un meccanismo per il controllo di accesso alla rete "Port-based" che faccia uso delle caratteristiche dell accesso fisico delle infrastrutture LAN IEEE 802 per poter ottenere un mezzo di autenticazione e un dispositivo di autorizzazione collegati a una porta LAN che abbia le stesse caratteristiche di una connessione point-to-point, inoltre deve poter bloccare l accesso alla porta nel caso in cui i processi di autenticazione o autorizzazione falliscano. Un nodo wireless deve autenticarsi prima di per poter ottenere un accesso alle risorse LAN. L autenticazione avviene seguendo questi tre principali passaggi: i. Quando un nodo wireless (WN) richiede l accesso ad una risorsa LAN, l access point (AP) esegue una richiesta d identità al WN. Prima che il WN sia autenticato non è permesso nessun altro traffico se non quello EAP (la "porta" è chiusa). ii. Dopo esser stata inviata l identità inizia il processo d autenticazione. Il protocollo usato tra il Supplicant e l Authenticator è EAP, o più precisamente EAPoL (EAP encapsulation over LAN). L Authenticator reincapsula il messaggio EAP in formato RADIUS e lo passa al Server Authenticator. iii. Se l autenticazione ha successo al Supplicant è assicurato un accesso alle altre risorse LAN/Internet. Il nodo wireless che richiede l autenticazione è spesso chiamato Supplicant (supplicante), benché sarebbe più corretto dire che il nodo wireless contenga un Supplicant. Il Supplicant è responsabile delle risposte che contengono le credenziali dell utente fornite all Authenticator. Lo stesso accade per l access point: l Authenticator non è l access point ma più propriamente l access point contiene un Authenticator. Comunque l Authenticator non deve necessariamente trovarsi nell access point, esso può trovarsi in un componente esterno. 5

6 Figura ruoli Authenticator, Supplicant, Authenticator Server EAP, che è il protocollo usato per l autenticazione, era originariamente utilizzato per la connessione PPP. Finché l identità dell utente viaggia in chiaro (non criptata), uno sniffer malintenzionato potrebbe scoprirla perciò si usa un metodo di "Identity hiding". Durante l autenticazione l Authenticator ritrasmette solamente i pacchetti tra il Supplicant e il Server Authenticator. Quando il processo di autenticazione finisce il Server Authenticator invia un messaggio si succedo (o di fallimento se l autenticazione non è andata a buon fine). Solo allora l Authenticator apre la "porta" per il Supplicant. 6

7 Figura 802.1X: un nodo wireless deve essere autenticato prima di poter ottenere l accesso alle altre risorse LAN L Authenticator lavora con porte controlled e uncontrolled. Entrambe le porte sono ingressi logici (porte virtuali) ma usano la stesse connessione fisica alla LAN (stesso punto d attacco). 7

8 Figura port: stati di autorizzazione della porta controlled Prima dell autenticazione solo la porta uncontrolled è "aperta". Il solo traffico permesso è EAPoL. (Figura: port - Authenticator System 1) Quando il Supplicant è autenticato la porta controllata è aperta e l accesso alle altre risorse LAN è concesso. (Figura: port - Authenticator System 2) Lo standard di autenticazione l i WEP WEP (Wired Equivalent Privacy) è parte dello standard originale e dovrebbe fornire la riservatezza. Sfortunatamente WEP è stato progettato male ed è risultato facilmente crackabile. Esso non è un metodo di autenticazione ma solo una debole forma di accesso controllato (deve essere comunicata la chiave condivisa). Come risposta alla violazione della sicurezza di WEP, l IEEE ha ideato uno nuovo standard per la sicurezza del wireless chiomato i. L 802.1X ha un ruolo fondamentale in questo nuovo standard. 8

9 802.11i Il nuovo standard per la sicurezza, l i, ratificato nel Giugno 2004, fissa tutte le debolezze del WEP. Esso è diviso in tre categorie principali: i. TKIP (Temporary Key Integrity Protocol)(Temporary Key Integrity Protocol) è una soluzione a breve termine per fissare le debolezze del WEP. TKIP può essere utilizzato con le vecchie apparecchiature dell (dopo un aggiornamento del driver/firmware) e fornisce integrità e confidenzialità. ii. CCMP (Counter Mode with CBC-MAC Protocol)(Counter Mode with CBC-MAC Protocol) è un protocollo nuovo, riprogettato delle fondamenta. Esso utilizza AES come algoritmo di crittografia e poiché richiede un carico maggiore per la CPU rispetto a RC4 (usato per WEP e TKIP) è necessario un nuovo hardware Alcuni driver possono implementare CCMP nel software. CCMP fornisce integrità e confidenzialità. iii X Port-Based Network Access Control: l autenticazione si utilizza l 802.1X. possono essere usati sia TKIP che CCMP, per Inoltre, al posto di CCMP, può essere utilizzato un metodo di crittografia opzionale chiamato WRAP (Wireless Robust Authentication Protocol)(Wireless Robust Authentication Protocol). WRAP era la proposta originale per i basato su AES, ma è stato sostituito da CCMP quando ha cominciato ad essere coperto da diritti di proprietà. In i il supporto per WRAP è opzionale ma è obbligatorio per CCMP i ha anche un estesa derivazione/gestione delle chiavi Gestione delle chiavi in i Scambio e gestione delle chiavi dinamiche Per rafforzare una politica di sicurezza che utilizzi algoritmi di criptaggio e integrità si devono poter ottenere delle chiavi. Fortunatamente i implementa un sistema per la distribuzione/gestione delle chiavi. 9

10 Figura KM: gestione e distribuzione delle chiavi in i. i. Quando il Supplicant (WN) e il Server di Autenticazione (AS) si autenticano, uno degli ultimi messaggi spediti dall AS, se l autenticazione ha avuto successo, è un Master Key (MK). Dopo esser stato spedito il MK è conosciuto solo dal WN e dall AS. Il MK è legato ad una particolare sessione tra il WN e l AS. ii. Sia il WN che l AS derivano una nuova chiave chiamata Pairwise Master Key (PMK) partendo dal MK. iii. La PMK è quindi trasferita dall AS all Authenticator (AP). Solo il WN e l AS possono derivare il PKM, altrimenti potrebbe essere l AP a prendere decisioni riguardi i permessi d accesso al posto dell AS. Il PMK è una nuova chiave simmetrica legata alla sessione tra il WN e l AS. 10

11 iv. Per derivare, fissare e verificare una Pairwise Transient Key (PTK) tra il WS e l AP sono utilizzati il PMK e un handshake a 4 vie. PTK è una serie di chiavi operative: Key Confirmation Key (KCK) come suggerito dal nome è utilizzata per verificare il possesso del PMK e per legare il PMK all AP. Key Encryption Key (KEK) è utilizzata per distribuire il Group Transient Key (GTK), descritto più avanti. Temporal Key 1 & 2 (TK1/TK2) sono utilizzate per il criptaggio. L utilizzo di TK1 e TK2 è specifico della sequenza di crittografia. v. Il KEK e un gruppo di handshake a 4 vie sono poi utilizzati per inviare il GTK dall AP al WN. Il GTK è una chiave condivisa tra tutti i Supplicant connessi allo stesso Authenticator ed è utilizzata per il traffico multicast/broadcast sicuro. 11

12 Figura PHK: gerarchia delle coppie di chiavi. chiavi pre-condivise 12

13 Per SOHO (small office / home office), reti ad hoc o uso domestico, si possono utilizzare chiavi pre-condivise PSK (pre-shared key)(pre-shared key) e l intero processo di autenticazione 802.1X è evitato. Questo metodo è chiamato WPA-PSK (WPA Personal)(WPA Personal), mentre il WPA che utilizza EAP (e RADIUS) è detto WPA Enterprise o semplicemente WPA. Il PSK a 256 bit è generato utilizzando PBKDFv2 [RFC2898] partendo da una password convenuta ed è utilizzato come se fosse il MK nel sistema di gestione delle chiavi descritto in precedenza. Si può utilizzare un singolo PSK per l intera rete (insicuro) oppure un singolo PSK per ogni Supplicant (più sicuro). TSN (WPA) / RSN (WPA2) Le industrie non aveva tempo per aspettare che lo standard i fosse completato. Esse volevano che i problemi del WEP fossero superati subito.la Wi-Fi Alliance, avvertendo questa pressione, prese un istantanea dello standard (basato sulla bozza n 3) e la chiamò Wi-Fi Protected Access (WPA). Un requisito fu che esistendo la apparecchiature per potessero essere utilizzate con WPA, così WPA è sostanzialmente KTIP X. WPA non è la soluzione a lungo termine. Per avere una Robust Secure Network (RSN), l hardware deve supportare e utilizzare CCMP. RSN è essenzialmente CCMP X. L RSN che utilizza TKIP invece che CCMP è chiamata Transition Security Network (TSN). RSN può anche essere chiamata WPA2, in questo modo non si fa confusione. Riassumendo: EAP TSN = TKIP X = WPA(1) RSN = CCMP X = WPA2 In più si utilizza la gestione delle chiavi, come descritto in precedenza. Extensible Authentication Protocol (EAP) [RFC 3748] è solamente il protocollo di trasposto ottimizzato per l autenticazione e non il metodo di autenticazione. EAP è una struttura di autenticazione che supporta metodi di autenticazione multipli. Tipicamente EAP gira direttamente sopra lo strato dei data link come il Point-to-Point Protocol (PPP) o l IEEE 802, senza bisogno di IP. EAP provvede da solo all eliminazione dei pacchetti duplicati e alla loro ritrasmissione, ma si basa sullo strato sottostante per garantirne l ordinamento. La frammentazione non è supportata da EAP stesso ma comunque può essere supportata dai singoli metodi di autenticazione. " [EAP is] an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this." --- RFC 3748, page 3 Metodi di autenticazione EAP Poiché 802.1X non seleziona uno specifico metodo EAP si possono utilizzare molti metodi diversi per l autenticazione inclusi: smart card, Kerberos, chiavi pubbliche, password fisse e altri. Alcuni tra i meccanismi di autenticazione EAP più utilizzati sono elencati qui sotto. Mentre una lista completa dei tipi di autenticazione EAP è disponibile presso l IANA 13

14 EAP-MD5: MD5-Challenge richiede username/password e è equivalente al protocollo PPP CHAP [RFC1994]. Questo metodo non fornisce protezione dagli attacchi di tipo dictionary, mutual authentication o key derivation e per questo è poco utilizzato per l autenticazione wireless. Lightweight EAP (LEAP): Un combinazione username/password viene inviata all Authentication Server (RADIUS) per l autenticazione. LEAP è un protocollo proprietario sviluppato da Cisco e non è considerato sicuro. Cisco sta eliminando gradualmente LEAP in favore di PEAP. EAP-TLS: S instaura una sessione TLS tra il Supplicant e l Authentication Server all interno di EAP. Sia il server che il/i client necessitano di un certificato x509 valido e quindi di un PKI (Public Key Infrastructure). Questo metodo prevede un autenticazione a due vie. EAP-TLS è descritto nel [RFC2716]. EAP-TTLS: Si stabilisce un tunnel TLS criptato per il trasporto sicuro dei dati di autenticazione. All interno del tunnel TLS può essere utilizzato qualunque altro metodo. L utilizzo dei certificati da parte dei Supplicant è opzionale ma è obbligatorio per il server (AS). Protected EAP (PEAP): Utilizza come EAP-TTLS un tunnel TLS criptato. Come per EAP-TTLS I certificati sono opzionali per i Supplicant ma obbligatori per il server (AS). E stato sviluppato da Microsoft, Cisco e RSA Security. EAP-MSCHAPv2: Richiede username/password ed fondamentalmente è un incapsulamento di MS-CHAPv2 [RFC2759] in EAP. Solitamente è utilizzato all interno di un tunnel PEAP criptato. E sviluppato da Microsoft. Non tutti I metodi di autenticazione sono considerati sicuri!!non tutti I metodi di autenticazione sono considerati sicuri!! 14

15 Standard e protocolli utilizzati Certificati X509 La crescente richiesta di connessioni crittografate che garantiscano per i dati trasmessi in rete la confidenzialità (nessuno oltre il legittimo destinatario può conoscerne il contenuto), la veridicità (firma elettronica) e l integrità (non è possibile alterarne il contenuto ponendosi nel mezzo dei due end-point della comunicazione) ha portato alla diffusione di algoritmi crittografici asimmetrici meglio noti come "algoritmi a chiave pubblica". Contrariamente alla crittografia a chiave simmetrica, in quella a chiave pubblica viene utilizzata una coppia di chiavi duali: ciò che è criptato con una può essere decriptato solo e soltanto con l altra e viceversa. Una delle due chiavi prende il nome di chiave privata e l altra di chiave pubblica. Così come i nomi stessi suggeriscono, la chiave privata è segreta e pertanto va custodita gelosamente dal proprietario, quella pubblica invece va distribuita agli interlocutori. Se un utente A vuole mandare dei dati segreti a un utente B, allora A dovrà criptare i dati con la chiave pubblica di B che essendo l unico possessore della chiave privata corrispondente potrà decriptarli. è così risolto il problema della confidenzialità. 15

16 Radius Supponiamo ora che l utente A voglia essere sicuro che i dati ricevuti siano inequivocabilmente provenienti da B e che non siano stati manomessi durante il tragitto: B deve calcolare un hash dei dati da spedire e criptarlo con la sua chiave privata. Quando A riceve i dati e l hash criptato, decripta quest ultimo con la chiave pubblica di B e lo confronta con l hash che calcola lui stesso sui dati giunti. Se i due hash sono uguali allora A può essere sicuro dell identità di B e dell integrità dei dati. In particolare, se i dati spediti da B ad A sono un documento elettronico il suddetto procedimento prende il nome di "firma digitale". La crittografia asimmetrica è tanto più forte quanto maggiore è la certezza che la chiave pubblica che si possiede appartenga realmente all interlocutore a cui i messaggi sono destinati o di cui si vuole accertare la provenienza. La cosa migliore da fare sarebbe scambiarsi personalmente le chiavi pubbliche, ma in una grande organizzazione non sempre ciò è possibile. Nasce pertanto l esigenza di dotare tali strutture di una PKI (Public Key Infrastructure). Le PKI si basano sull uso dei certificati, cioè di attestati firmati digitalmente che contengono i dati di identificazione dell utente (o del server), la sua chiave pubblica e l identificazione dell autorità di certificazione che firma il certificato. Naturalmente la Certification Authority (più in breve CA) che firma i certificati deve essere fidata e la sua chiave pubblica distribuita in maniera sicura. Con l uso dei certificati X509 v3 e del protocollo SSL (Secure Socket Layer), sviluppato inizialmente da Netscape ma che nella versione 3.0 è stato standardizzato dalla IETF e ha preso il nome di TLS 1.0 (Transport Layer Security), è possibile creare dei tunnel end-to-end poggiati sul livello di trasporto TCP ed ottenere un livello di sessione sicuro. Esempi di protocolli di sessione incapsulati in tunnel SSL sono: https (secure http), imaps (secure IMAP), telnets (secure telnet), smtps (secure SMTP), ldaps (secure LDAP), pop3s (secure pop3) e nntps (secure USENET transport protocol). Il protocollo TLS non si limita a criptare i dati che passano nel tunnel, ma, quando richiesto, garantisce anche l autenticità del client e del server (mutua autenticazione). Si noti poi, che gli algoritmi asimmetrici hanno una complessità computazionale molto maggiore di quelli simmetrici. Per questo motivo nel protocollo SSL, grazie a un primo scambio di dati crittografati asimmetricamente, client e server si accordano su un algoritmo simmetrico e sulla relativa chiave di sessione con cui criptare simmetricamente il resto della conversazione. RADIUS (Remote Authentication Dial-In User ServiceRemote Authentication Dial-In User Service) è definito nel [RFC2865] ed in alcune altre seguenti; Originariamente era utilizzato dagli ISP che necessitavano di autenticare nome e password degli utenti prima di poterli autorizzare ad utilizzare i servizi di rete forniti.. Non sono disponibili molti protocolli AAA ma sia RADIUS sia DIAMETER [RFC3588] (incluse le loro varianti) soddisfano tutti i requisiti di un AAA. AAA sta per Authentication, Authorization, and Accounting X non specifica quale tipo di server di autenticazione back-end debba essere utilizzato, ma il RADIUS è il server di autenticazione back-end di fatto utilizzato da 802.1X. 16

17 Introduzione Schema di autenticazione RADIUS è un protocollo largamente utilizzato negli ambienti di rete. E comunemente utilizzato nei dispositivi di rete embedded come i router, server di modem, switch, etc. E utilizzato per diverse ragioni: I sistemi embedded generalmente non possono colloquiare con un gran numero di utenti con informazioni di autenticazione distinte. Questo richiederebbe una capacità d immagazzinamento d informazioni più grande di quella posseduta dalla maggior parte dei sistemi embedded RADIUS facilita l amministrazione centralizzata degli utenti, il che è importante per molte di queste applicazioni. Molti ISP hanno decine di migliaia, centinaia di migliaia o anche milioni di utenti. Gli utenti sono aggiunti o cancellati continuamente durante il giorno, e le informazioni di autenticazione degli utenti cambiano costantemente. L amministrazione centralizzata degli utenti in questi ambienti è un requisito fondamentale. RADIUS fornisce alcuni livelli di protezione completa contro uno sniffig, attaccante attivo. Altri protocolli di autenticazione remota forniscono invece una protezione intermittente, una protezione inadeguata o una protezione inesistente. Gli avversari principali di RADIUS per l autenticazione remota sono TACACS+ e LDAP. LDAP spontaneamente non fornisce protezione contro sniffig o attaccanti attivi. TACACS+ è stato ingegnosamente violato come descritto da Solar Designer nei suoi advisory. 17

18 Il protocollo Il supporto di RADIUS è quasi onnipresente. Altri protocolli di autenticazione remota non sono supportati completamente da parte dei venditori di hardware, mentre RADIUS è uniformemente supportato. Poiché le piatteforme su cui RADIUS è implementato sono spesso sistemi embedded, ci sono opportunità limitate per supportare protocolli addizionali. Ogni cambiamento nel protocollo RADIUS dovrebbe essere almeno minimamente compatibile con i client e server RADIUS pre-esistenti (non modificati). RADIUS è correntemente lo standard di fatto per l autenticazione remota. Esso è veramente prevalente sia nei sistemi nuovi che in quelli più vecchi. Qui sotto un sommario di un pacchetto RADIUS (dall RFC) Il code stabilisce il tipo di pacchetto RADIUS. I code sono: 18

19 tutti i pacchetti di tipo non riconosciuto vengono scartati automaticamente L Identifier è un valore di otto bit che permette al client RADIUS di collegare una risposta RADIUS con la richiesta corrispondente. Nella sezione Attributes vengono inseriti un numero arbitrario di campi attributo. I soli attributi trattati in questa analisi sono gli attributi User-Name e User-Password. Questa descrizione si concentrerà sui tipi più comuni di scambi RADIUS: un Access-Request consiste di uno username e una user password, seguita da un Access-Accept o un Access-Reject o un fallimento. Ci riferiremo ai due partecipanti in questo protocollo come il client e il server. Il client è l entità che possiede le informazioni di autenticazione che devono essere convalidate. Il server è l entità che ha accesso al database delle informazioni di autenticazione che utilizza per convalidare le richieste di autenticazione del client. 19

20 Schema di autenticazione Processo iniziale del client Il client crea un pacchetto RADIUS di Access-Request, includendo alla fine gli attributi User-Name e User- Password.. Il campo identifier del pacchetto Access-Request è generato dal client. Il processo per generare il campo identifier non è specificato nelle specifiche del protocollo RADIUS, ma è usualmente implementato come un semplice contatore che viene incrementato ad ogni richiesta. Il pacchetto Access-Request contiene nel campo Authenticator un Request Authenticator di 16 byte. Il Request Authenticator è una stringa di 16 byte scelta casualmente. Questo pacchetto è completamente non protetto eccetto per l attributo User-Password, che viene protetto in questo modo: Il client e il server condividono un segreto. Questo segreto condiviso seguito dal Request Authenticator è inserito in un hash MD5 per creare un valore di 16 byte che venga XORato con la password inserita dall utente. Se la password dell utente è più grande di 16 byte, viene eseguito un ulteriore calcolo MD5, utilizzando il precedente testo cifrato anziché il Request Authenticator. Più esplicitamente: c1 = p1 XOR MD5(S + RA) c2 = p2 XOR MD5(S + c1)... cn = pn XOR MD5(S + cn-1) Gli attributi del User-Password contengono c1+c2++cn, dove + significa concatenati. 20

21 Processo sul server Il serve riceve il pacchetto RADIUS Access-Request e verifica che il server possieda un segreto condiviso con il client. Se il server non possiede un segreto condiviso per il client, la richiesta viene scartata automaticamente e in silenzio. Poiché anche il server possiede il segreto condiviso, esso può esaminare, attraverso una versione leggermente modificata del processo di protezione del client, l attributo User-Password e ottenere la password senza protezione. Quindi utilizza il suo database di autenticazione per convalidare l utente e la password. Se la password è valida, il server crea un pacchetto Access-Accept da rispedire al client. Se la password non è valida, il server crea un pacchetto Access-Reject da inviare al client. Sia il pacchetto Access-Accept che il pacchetto Access- Reject utilizzano lo stesso valore d identifier di quello del pacchetto Access-Request del client, e inseriscono un Response Authenticator nel campo Authenticator. Il Response Authenticator è l hash MD5 del pacchetto di risposta con il Request Authenticator, del pacchetto di richiesta assocciato, nel campo Authenticator, concatenato con il segreto condiviso. Cioè ResponseAuth = MD5 (Codice+ID+Lunghezza+RequestAuth+Attributi+Segreto) dove la + significa concatenati. Processo successivo del client FreeRadius Quando il client riceve un pacchetto di riposta, cerca di collegarlo con una richiesta utilizzando il campo identifier. Se il client non riconosce un richiesta corrispondente che utilizzi lo stesso identifier, la risposta è scartata in silenzio. Il client quindi verifica la Response Anthenticator compiendo la stessa operazione fatta dal server sulla Response Authenticator, e quindi confronta il risultato con il campo Authenticator. Se la Response Authenticator non combacia il pacchetto viene scartato in silenzio. Se il cliente riceve un pacchetto Access-Accept verificato, l username e la password sono considerate corrette e l utente viene autenticato. Se il cliente riceve un messaggio Access-Reject verificato, l username e la password sono considerati non corretti e l utente non viene autenticato. E la versione libera di RADIUS ed è reperibile su I metodi di autenticazione finora supportati sono: EAP-MD5 EAP-TLS EAP-TTLS PEAP EAP-SIM EAP-GTC LEAP EAP-MSCHAPv2 21

22 Mentre i database più importanti che si possono utilizzare per l autenticazione e l accounting sono: Postgreesql mysql ldap iodbc LDAP Directory E un protocollo per far comunicare più computer con un directory server. Ldap è stato disegnato per permettere un accesso leggero ad alberi derivati da directory X.500 OSI Directory Access Protocol (DAP), permettendo di sviluppare programmi più leggeri di quelli basati su X.500. Viene definito nelle rfc 1777 e 2251 Una directory è una collezione gerarchica di oggetti e di diritti associati agli oggetti stessi, un po come le directory di un filesystem. Ldap non è una base di dati intesa come sql. In sql i dati sono organizzati in tabelle, in ldap i dati sono organizzati in una struttura ad albero. 22

23 Esempio di directory Nel corso degli anni ci sono state evoluzioni dell ldap e la radice può essere specificata in più modi: o=lugvi, c=it (X.500) dc=vicenza.linux.it dc=vicenza,dc=linux,dc=it (rfc 2247) 23

24 Gli schemi La terza formulazione riflette la struttura dei dns, con tutti i vantaggi che ne conseguono. Gli Organizational Unit sono i nodi interni dell albero ldap. Permettono una divisione in sottoparti dei dati raggruppandoli in gruppi logici. La divisione dei dati un ou permettere di restringere le ricerche a sottoporzioni dell albero, diminuendo quindi i tempi di ricerca. Tutti i dati e gli oggetti che compongono l albero ldap vengono descritti dagli schemi, in cui per ogni oggetto vengono definiti i campi che lo compongono e i tipi dei dati. Per aumentare gli oggetti salvabili all interno degli alberi ldap è necessario includere gli schemi necessari. esempi di schemi: Dichiarazione degli attributi attributetype ( NAME loginshell DESC The path to the login shell EQUALITY caseexactia5match SYNTAX SINGLE-VALUE ) Definizione degli oggetti objectclass ( NAME posixaccount SUP top AUXILIARY DESC Abstraction of an account with POSIX attributes MUST ( cn $ uid $ uidnumber $ gidnumber $ homedirectory ) MAY ( userpassword $ loginshell $ gecos $ description ) ) Differenze tra ldap e database relazionali Ldap è stato progettato per basi di dati che devono essere letti spesso e aggiornati meno frequentemente. E quindi ottimizzato per permettere letture veloci, anche a discapito della velocità di scrittura. I dati sono organizzati in una struttura gerarchica e non in tabelle. Supporto nativo della replicazione. Differenze tra ldap e X.500 I programmi basati su X.500 erano particolarmente pesanti e consumavano molte risorse ed erano quindi inadatti all esecuzione su macchine client. Ldap mantiene le stesse caratteristiche principali, si basa su tcp/ip invece che sullo stack osi, tutti i dati sono stringhe e non binari. IETF prevede per ldap in più rispetto ad X.500 la replicazione multimaster. 24

25 Schema di associazione Progetto operativo Lo scopo del progetto è quello di realizzare un prototipo di sistema che permetta agli utenti autorizzati di collegarsi alla rete del dipartimento tramite acceso Wi-Fi. L autenticazione dal lato utente deve poter risultare il più semplice e portabile possibile ma al tempo stesso garantire un buon grado di sicurezza. Poiché, come 25

26 detto in precedenza, il server RADIUS è lo standard de-facto utilizzato per le autenticazioni con 802.1X, è stato naturale decidere di utilizzarlo come Authenticator Server nel nostro progetto. Del server RAIUS server ne esiste anche una versione libera: FreeRadius la quale può essere scaricata gratuitamente dal sito [ questa versione supporta l utilizzo di Ladp come database per le informazioni di autenticazione degli utenti e fornisce una buona possibilità di scelta riguardo i metodi di autenticazione. L unica pecca è la documentazione un po carente, i file di configurazione sono molto ben commentati in alcuni punti mentre in altri è scarso o non molto comprensibile. Comunque a questa mancanza si può porre rimedio eseguendo qualche ricerca in rete. Tra i metodi di autenticazione supportati i due che più soddisfano la richiesta di "semplicità" e sicurezza erano TTLS e PEAP, il fatto che TTLS non sia un metodo proprietario come invece lo è PEAP ha fatto preferire il primo al secondo. Per semplificare le cose, come metodo di autenticazione all interno di TTLS si era inizialmente pensato di utilizzare MD5; in seguito ad alcune difficoltà riscontrate con il confronto dei dati su Ldap, all interno di TTLS, si è scelto d implementare anche l utilizzo di PAP. Configurazione del server FreeRADIUS radiusd.conf Come prima cosa è necessario installare il server FreeRadius. Questo lo si può fare scaricando il file.tar.gz dal sito [ dopo aver decompresso il file utilizzando il comando: tar -xzvf entrare nella cartella appena creata ed installate il server digitando i seguenti comandi:./configure make make install Verranno create alcune cartelle e file tra cui la più importante è la cartella etc/raddb contenete i file di configurazione come ad esempio: radiusd.conf configurazione generale del server clients.conf elenco degli access point che possono contrattare le autenticazioni users dichiara i metodi utilizzati dagli utenti per autenticarsi eap.conf configurazione dei metodi eap Inoltre all interno della cartella sbin viene inserito il file eseguibile radiusd utilizzato per avviare il server; mentre nella cartella bin si può trovare l eseguibile radtest che come si può intuire dal nome viene utilizzato per testare il server simulando una richiesta d accesso. E il file di configurazione principale. La parte iniziale è commentata molto bene e contiene la configurazione di alcune variabili come l indirizzo delle cartelle contenenti gli altri file di configurazione o di log oppure il nome utente e il gruppo a cui può appartenere il server quando viene lanciato o ancora alcuni valori che definiscono i tempi di attesa del server e così via. Le impostazioni di default sono già sufficienti per far funzionare correttamente RADIUS perciò il più delle volte non è necessario modificarle. La parte che a noi interessa e che dobbiamo modificare comincia quando s incontra la variabile modules {}. All interno di questa sessioni sono configurate le impostazioni dei vari moduli di autenticazione che verranno caricati man a mano che s incontreranno nelle altre sessioni del file di configurazione. I moduli che dovremo configurare saranno quelli dell autenticazione PAP e di quella EAP, inoltre sarà da configurare il modulo per LDAP. modules { pap { encryption_scheme = crypt } $INCLUDE ${confdir}/eap.conf ldap { 26

27 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)" 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" dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 # password_header = "{crypt}" # password_attribute = userpassword # groupname_attribute = cn # groupmembership_filter = "( (&(object- Class=GroupOfNames)(member=%{Ldap UserDn}))(&(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 } 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 } } Dovremo modificare le seguenti linee di testo: per il modulo pap la riga che indica il metodo di crittografia delle password sul database, i valori possibili sono clear, crypt, md5 e sha1: encryption_scheme = crypt 27

28 per il modulo eap l impostazione di defaul rimanda già al file eap.conf $INCLUDE ${confdir}/eap.conf per il modulo ladp bisogna innanzitutto inserire gli estremi per la ricerca e la connessione col database si deve indicare il nome del server del database tramite il nome completo o l indirizzo ip server = "ldap.your.domain" il punto dell albero da cui iniziare la ricerca dei dati basedn = "o=my Org,c=UA" e il filtro da utilizzare per la ricerca, cioè il nome utente filter = "(uid=%{stripped-user-name:-%{user-name}})" è possibile impostare un ulteriore tunnel tls tra il Radius e Ldap ma in questo caso non vogliamo implementare questa funzione start_tls = no se la password contenuta in Ldap è preceduta da una stringa, come ad esempio nel nostro caso dove sta ad indicare l algoritmo di crittografia utilizzato, è possibile eliminarla password_header = "{crypt}" infine si deve indicare il nome del campo Ldap che contiene la password password_attribute = userpassword il resto del testo serve per impostare configurazioni più avanzate ma al momento non occorre alcuna modifica allo scritto di default. Un ulteriore modulo da configurare, e che risulterà utile per impostare i metodi di autenticazione che si vorranno utilizzare, è quello files. In esso vengono specificati i percorsi di alcuni file contenenti informazioni riguardanti le modalità di autenticazione degli utenti. L unica riga che c interessa non sia commentata è quella di usersfile files { usersfile = ${confdir}/users } La sessione seguente da prendere in esame è authorize {} authorize{ # attribute list to the EAP type from the packet. eap # # Read the users file files # The ldap module will set Auth-Type to LDAP if it has not # already been set ldap 28

29 } All interno di questa sessione vengono elencati tutti e soli i moduli che dovranno essere inizializzati al momento del caricamento del server. Se il modulo non è presente in questo elenco non sarà utilizzabile. Le righe che c interessano sono quelle di eap, files e ldap, tutte le altre possono essere commentate tutti per evitare che vengano caricati dei moduli inutili. authorize{ eap files ldap } Non ci resta che impostare la sessione authenticate {}, infatti al suo interno sono definiti tutti i metodi ammessi per richiedere l autenticazione. authenticate { } # password can be clear-text, or encrypted. Auth-Type PAP { pap } #Allow EAP authentication. # eap Poiché si era deciso di testare l autenticazione tramite MD5, che è un metodo eap, questo deve essere uno dei metodi accettati; quando in seguito si è deciso di testare anche PAP anch esso è stato aggiunto tra i metodi accettati. Quindi l unico testo che dovrà rimanere decommentato sarà authenticate { Auth-Type PAP { pap } eap } Tutto il resto è preferibile commentarlo per evitare che gli utenti si possano autenticare con metodi non desiderati. Nel file radiusd.conf è anche possibile impostare un servizio di proxy per l autenticazione oppure alcuni azioni da eseguire prima o dopo l autenticazione come l aggiunta di suffissi o prefissi al nome utente ecc. ma poiché nel nostro caso sono tutte cose non necessarie, per migliorare la sicurezza del sistema, possiamo commentarle tutte. 29

30 clients.conf In questo file vengono dichiarati tutti gli Authenticator (Access Point) che possono eseguire richieste di autenticazione da parte dei Supplicant. Tutti le richieste effettuate da AP che non compaiono in questo elenco vengono automaticamente scartate. Ma come si è detto nella parte teorica del progetto l AP e il server RADIUS devono condividere un segreto per poter comunicare, quindi anche nel caso l AP compaia nell elenco ma non abbia a disposizione un segreto impostato per questo server oppure il segreto sia diverso, le richieste verranno comunque rifiutate. client { secret = testing123 shortname = localhost nastype = other #login =!root #password = someadminpas } users Un client RADIUS deve essere definito utilizzando la formula "client [hostname ip-address]" cioè si può indicare il nome completo dell AP tipo some.host.org oppure direttamente il suo indirizzo IP, è anche possibile indicare una sottorete di client con cui condividere il segreto come /24 o /16. Nella riga secret viene indicata qual è al segreto condiviso, mentre nella riga shortname viene dichiarato un alias per indicare l AP senza usare il nome completo o l IP. Le ultime tre righe sono opzionali ed addirittura le ultime due sono solo per utilizzi futuri, il valore di nastype serve per indicare il modello di AP che effettuerà la richiesta permettendo una miglior comunicazione con esso. All interno di questo file è possibile impostare una discriminazione tra i metodi di autenticazione accettati a seconda dell utente che esegue la richiesta. Il file è commentato molto bene e gli esempi inseriti rendono la comprensione abbastanza semplice. E possibile impostare un elenco di singoli utenti o gruppi di essi e per ognuno indicare quale metodo di autenticazione debba essere utilizzato, in più possono essere indicati alcuni requisiti che il particolare supplicant deve soddisfare per poter effettuare l autenticazione come ad esempio il possedere un particolare indirizzo ip. Inoltre vi è la possibilità di rifiutare direttamente la richiesta di autenticazione da parte di uno specifico utente o di un gruppo senza bisogno di verificare la veridicità delle credenziali. Infine è possibile indicare un metodo di autenticazione da utilizzare per tutti quegli utenti che non rientrano direttamente negli elenchi precedenti impostando "l utente" DEFAULT Poiché a noi non interessa attuare alcun tipo di discriminazione tra gli utenti ed il file radius.conf è già stato impostato per permettere l autenticazione tramite EAP-MD5, non sarebbe necessario modificare questo file se non per permettere l autenticazione anche tramite PAP. I moduli caricati nella sezione authorize sono sia eap che files e in questo modo è possibile indicare, all interno di users, un metodo di default che sia diverso da EAP permettendo così di eseguire l autenticazione potendo scegliere tra due metodi diversi. Basterà aggiungere la riga: DEFAULT Auth-Type = PAP e commentare tutto il resto. 30

31 eap.conf Per completare la configurazione di autenticazione con 802.1X è necessario configurare attentamente un ultimo file: eap.conf. All interno di questo file viene impostato il metodo di autenticazione eap che si desidera utilizzare di default nonché alcuni parametri per l accettazione della richiesta. eap { default_eap_type = md5 timer_expire = 60 ignore_unknown_eap_types = no # Supported EAP-types md5 { } ## EAP-TLS #tls { # private_key_password = whatever # private_key_file = ${raddbdir}/certs/cert-srv.pem # certificate_file = ${raddbdir}/certs/cert-srv.pem # CA_file = ${raddbdir}/certs/democa/cacert.pem # dh_file = ${raddbdir}/certs/dh # random_file = ${raddbdir}/certs/random # fragment_size = 1024 # include_length = yes # check_crl = yes # check_cert_cn = %{User-Name} #} #ttls { # default_eap_type = md5 # copy_request_to_tunnel = no # use_tunneled_reply = no #} } La prima riga: default_eap_type = indica il metodo di autenticazione eap che verrà utilizzato per l autenticazione; mentre nella sessione Supported EAP-types sono elencati i metodi attivi e impostati alcuni loro parametri. Nel nostro caso nella prima riga dovremo sostituire md5 con ttls default_eap_type = ttls Dato che l autenticazione con ttls utilizza un tunnel che deriva da tls è necessario impostare correttamente anche quest ultimo metodo. Inoltre ttls prevede che all interno del tunnel creato venga utilizzato un ulteriore metodo eap per l autenticazione e quindi andrà configurato anch esso. Nel nostro caso abbiamo deciso di utilizzare md5 come metodo si autenticazione all interno del tunnel, quindi dovremo impostare md5, tls e ttls. Il metodo md5 non necessita di alcun parametro e quindi basta decommentare, se necessario, le righe md5 { 31

32 } L autenticazione tramite tls avviene attraverso l utilizzo dei certificati e sebbene per ttls basti il solo certificato del server sarà comunque necessario specificare l ubicazione di tale certificato ed alcuni parametri per il suo utilizzo. Queste impostazioni si trovano nella sezione riguardante il tls che quindi andrà decommentata e modificata. Le prime sei righe specificano tutti i parametri per l utilizzo del certificato: private_key_password = è da decommentare solo quando il certificato è protetto da password private_key_file = indica in quale file è contenuta la chiave privata certificate_file = indica in quale file è contenuto il certificato e può essere lo stesso di quello della chiave privata CA_file = dove trovare il certificato della CA dh_file = dove trovare un file per il controllo dell integrità del certificato random_file = dove trovare il file casuale utilizzato per la creazione della chiave Inoltre per far funzionare correttamente il tunnel è necessario decommentare anche le due righe seguenti fragment_size = 1024 include_length = yes Le ultime due righe sono utilizzate per la revoca dei certificati ma nel nostro caso possiamo lasciarle commentate. A questo punto il tunnel e il metodo da utilizzare al suo interno sono impostati, non resta quindi che configurare ttls. La cosa è molto semplice poiché basta decommentare poche righe e specificare quale metodo utilizzare all interno del tunnel che, come detto sopra, sarà md5. ttls { default_eap_type = md5 copy_request_to_tunnel = no use_tunneled_reply = no } A questo punto il server Radius dovrebbe essere configurato correttamente e lo si può avviare in modalità debug utilizzando il comando: radiusd -X. Se tutto funziona correttamente esso invierà a video una serie di notifiche sullo stato di avvio e finirà mettendosi in attesa di richieste d accesso da parte di qualche utente. Listening on authentication *:1812 Listening on accounting *:

33 Listening on proxy *:1814 Ready to process requests. Configurazione dall AP (Cisco 1100) L access point, oltre a fornire un accesso alla rete, ha il compito di trasmettere i pacchetti di autenticazione dal supplicant all authenticator server e viceversa e bloccare tutto il traffico non autorizzato. L AP deve quindi essere configurato sia per un collegamento verso il server che per uno verso il supplicant. Innanzitutto occorre accede all AP in modo da poterlo configurare, l accesso può avvenire in due modi: attraverso la console si può stabilire una connessione telnet o ssh oppure tramite il browser Web ci si collega direttamente utilizzando come URL il suo indirizzo IP. Per semplificare le cose abbiamo utilizzato il browser e appena effettuato l accesso vengono richiesti username e password per accedere alla configurazione. Nella pagine home si trova un riepilogo dello stato e della configurazione dell AP. 33