VPN sicure con IPSEC

Transcript

1 Università degli Studi di Pisa Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Informatica VPN sicure con IPSEC Studio teorico e realizzazione pratica di una Virtual Private Network tramite l utilizzo dei protocolli IPSec Studenti: David Frassi, Luca Saba Anno Accademico

2 Pagina 2 di 85.Sì, io sono un criminale. Il mio crimine è quello della curiosità. Il mio crimine è quello di giudicare le persone per quello che dicono e pensano, non per quello che appaiono. Il mio crimine è quello di metterti nel sacco, qualcosa per cui non mi perdonerai mai. Io sono un hacker e questo è il mio manifesto. Forse potrai fermare me, ma non potrai mai fermarci tutti dopo tutto, siamo tutti uguali. (dal Manifesto dell Hacker Anonimo)

3 Pagina 3 di 85

4 Pagina 4 di 85 Indice INTRODUZIONE LA SICUREZZA DELLE RETI INFORMATICHE DEFINIZIONE UN APPROCCIO SISTEMATICO Attacchi Servizi Modelli per la Sicurezza CONCLUSIONI COS È UNA VPN E PERCHÉ UTILIZZARLA? INTRODUZIONE IL PERCHÉ DI UNA VPN UN PICCOLO ESEMPIO Accordo tra i gateways Invio del messaggio IPSEC: LA SOLUZIONE STANDARD ALLA SICUREZZA IP INTRODUZIONE SECURITY ASSOCIATION (RFC 2401) SA in transport mode SA in tunnel mode Funzionalità di una SA Combinazione di più SA DATABASES SPD: Security Policy Database Selectors SAD: Security Association Database Localizzazione di un Security Gateway AH (AUTHENTICATION HEADER) RFC Introduzione AH (Modalità Trasporto) AH (Modalità Tunnel) Invio dei Pacchetti e Authentication Algorithm Ricezione dei Pacchetti ESP (ENCAPSULATING SECURITY PAYLOAD) RFC Introduzione Formato del pacchetto ESP ESP (Modalità Trasporto) ESP (Modalità Tunnel) Invio dei Pacchetti Frammentazione Ricezione dei Pacchetti Confronto tra AH e ESP - Utilizzo di HMAC CONFRONTO TRA ESP IN MODALITÀ TRASPORTO E ESP IN MODALITÀ TUNNEL ISAKMP E IKE UNO SGUARDO GENERALE IKE E LO SCAMBIA DELLE SA Fase 1 dello scambio tra i servers ISAKMP/IKE STUDIO DI UN CASO REALE DESCRIZIONE REALIZZAZIONE DELLA SOLUZIONE Servizi ISAKMP e IKE Configurazione delle access lists Configurazione delle interfacce...63

5 Pagina 5 di Mappatura del traffico In pratica LISTATO DELLE CONFIGURAZIONI IPSEC Firenze Roma Montecatini SVANTAGGI DI IPSEC PRESTAZIONI DI IPSEC COMPATIBILITÀ TRA IMPLEMENTAZIONI VULNERABILITÀ DI IPSEC Sensibilità ai Denial of Service: Sensibilità all attacco con uomo in mezzo...71 CONCLUSIONI...74 APPENDICE A - ISAKMP E IKE: SCAMBIO DI MESSAGGI...76 A.1 IKE FASE A.1.1 Autenticazione tramite firma digitale...76 A.1.2 Autenticazione con crittografia a chiave pubblica...77 A.1.3 Autenticazione con crittografia asimmetrica e chiave di sessione...77 A.1.4 Autenticazioni tramite sistema di chiavi pre-distribuite...78 A.2 IKE FASE A.3 ISAKMP INFORMATIONAL EXCHANGE...80 APPENDICE B FRAMMENTAZIONE E PATH MTU...82 BIBLIOGRAFIA...84 RINGRAZIAMENTI...85

6 Pagina 6 di 85 Introduzione La diffusione dei personal computer, l introduzione delle reti locali, il proliferare dei servizi telematici, hanno segnato profondamente l aspetto di Internet, modificando progressivamente il profilo dell utente tipico. Tutto questo, se da un verso ha comportato una grande funzionalità nelle procedure del mondo del lavoro, ha anche costretto gli individui ad affrontare problematiche sconosciute, derivate dai nuovi rischi legati alla sicurezza delle informazioni, che hanno assunto via via sempre più valore. In realtà alla veloce evoluzione di questi mezzi elettronici non è seguita una coordinata modernizzazione della cultura socioistituzionale e degli strumenti di sicurezza; ciò ha notevolmente incrementato i rischi e le probabilità di attacco, dall introduzione di virus, alla manipolazione e/o furto dei dati, conducendo alla nascita di nuove forme criminali, fortemente connotate dalla tecnologia. Internet è nata in un momento e con obiettivi ben diversi da quelli che oggi destano così tanti interessi. Chi poteva accedere originariamente ad Internet era parte di una elite tecnocratica che non aveva nessun interesse a danneggiare il lavoro degli altri utenti, trattandosi molto spesso di colleghi con cui lavorare a stretto contatto. Le preoccupazioni di tutti gli operatori coinvolti, dagli utenti agli sviluppatori di protocolli Internet, erano concentrate perlopiù sulle performance e sull affidabilità della rete piuttosto che sulla sicurezza. Oggi lo scenario è cambiato. Nuovi utilizzi della rete sono alle porte, nuovi potenziali utenti premono per entrare a far parte della comunità, specialmente dopo l esplosione dell E-Business. Internet infatti, grazie alla sua diffusione, rappresenta il veicolo ideale per raggiungere milioni di consumatori i quali possono essere indotti a spendere i propri soldi nei servizi e nelle merci proposte attraverso il commercio elettronico. Così, i documenti che mostrano le fasi di avanzamento di un dato progetto, le previsioni di vendita di un prodotto di prossima introduzione sul mercato, sono solo alcuni tra i dati potenzialmente appetitosi per la concorrenza. Fatto ben noto agli hackers che possono mettersi al servizio del miglior offerente. Mai come oggi i bit scambiati su Internet possono essere convertiti in denaro, e questo non fa altro che ingrossare le fila di chi naviga la rete al solo scopo di predare gli utenti più incauti. D'altronde, grazie all enorme disponibilità e libertà di informazione insita nel Web e nella cosiddetta comunità globale, ogni aspirante hacker, per diventare tale, non deve essere un profondo conoscitore delle tecnologie e della teoria che sta dietro ad ogni sua intrusione, ma gli sarà sufficiente scaricarsi il software

7 Pagina 7 di 85 apposito (exploit), magari corredato dal relativo tutorial o manuale di utilizzo, da uno dei tanti siti underground che popolano il Web. Proprio a causa di questa riproducibilità degli attacchi, tutti coloro che hanno il compito di difendere un sistema si trovano particolarmente in svantaggio rispetto ai cosiddetti pirati informatici, il cui esercito non è composto dai soli geni, ideatori della tecnica d intrusione ma anche da tutti coloro (la maggior parte) che la riproducono. Tra le tante soluzioni utilizzate dalle aziende per garantire un flusso sicuro di informazioni, le VPN (Virtual Private Network, rete privata virtuale) rappresentano già da qualche anno un industria in veloce crescita, specie se implementate con il protocollo di scambio protetto di informazioni, denominato IPSec. Una VPN ha l aspetto e molti dei vantaggi della linea privata dedicata, ma attraversa la rete pubblica mediante diverse tecniche di codifica per garantire la segretezza e l integrità dei dati; questo processo è noto anche come tunneling. La popolarità delle VPN risiede in un fattore importantissimo, il costo. Con l esplosione di Internet, non subito si intuì che la madre di tutte le reti forniva la stessa funzionalità delle WAN (Wide Area Network): stessi routers, stessi tipi di dorsali e stesso protocollo, il TCP/IP. Riuscire quindi ad utilizzare Internet come metodo di trasporto per i dati segreti avrebbe portato ad un risparmio notevole, in termini di costi, rispetto ad un onerosa serie di connessioni WAN. Tra i vari protocolli ideati per implementare una VPN, è IPSec in questo momento a trionfare. Sviluppato dalla IETF (Internet Engineering Task Force), questo standard vanta un folto seguito, dato che i costruttori non risparmiano energie per cercare di realizzare apparecchiature ad esso conformi. Cisco e 3Com hanno diffuso di recente alcuni servers VPN con il supporto IPSec, ma altre società meno note possedevano i prodotti adeguati già dalla prima versione dello standard, il quale continua ad essere sviluppato per supportare funzioni aggiuntive. Nella presente relazione verrà introdotto il concetto di sicurezza delle reti informatiche, cercando di illustrarne le caratteristiche teoriche generali. Successivamente, dopo aver descritto la tecnologia che sta alla base delle VPN e di IPSec, concluderemo con lo studio di un caso reale attraverso cui sarà possibile capire meglio alcuni aspetti teorici.

8 Pagina 8 di La sicurezza delle Reti Informatiche Rendere un sistema sicuro non significa solo attuare un insieme di contromisure specifiche (di carattere tecnologico ed organizzativo) che neutralizzi tutti gli attacchi ipotizzabili per quel sistema; significa soprattutto collocare ciascuna contromisura in una politica organica di sicurezza che tenga conto dei vincoli (tecnici, logistici, amministrativi, politici) imposti dalla struttura in cui il sistema opera, e che giustifichi ciascuna contromisura in un quadro complessivo. 1.2 Definizione Con il termine Sicurezza si intende l insieme delle misure (di carattere organizzativo e tecnologico) tese ad assicurare a ciascun utente autorizzato tutti e soli i servizi necessari per svolgere un lavoro, nei tempi e nelle modalità previste. Secondo la definizione della Commissione delle comunità Europee in materia di Sicurezza ( Linee guida per un approccio strategico europeo ): La sicurezza delle reti e dell'informazione va intesa come la capacità di una rete o di un sistema d'informazione di resistere, ad un determinato livello di riservatezza, ad eventi imprevisti o atti dolosi che compromettono la disponibilità, l'autenticità, l'integrità e la riservatezza dei dati conservati o trasmessi e dei servizi forniti o accessibili tramite la suddetta rete o sistema. Vediamo di entrare maggiormente in dettaglio: Disponibilità: il sistema deve rendere disponibili a ciascun utente abilitato le informazioni alle quali ha diritto di accedere, nei tempi e nei modi previsti. Nei sistemi informatici, i requisiti di disponibilità sono legati a quelli di prestazione, di robustezza, di tolleranza ai guasti e di recupero dai guasti (garantire il rientro in funzione in tempo utile del sistema informatico, a seguito di eventi negativi anche gravi). La disponibilità di una informazione ad un utente, infatti, deve essere assicurata in modo ininterrotto durante tutto il periodo di tempo previsto (continuità del servizio). Integrità: il sistema deve impedire l alterazione diretta o indiretta delle informazioni, sia da parte di utenti e processi non autorizzati, che a seguito di eventi accidentali. Anche la perdita di dati, per esempio a seguito di cancellazione o danneggiamento, viene considerata come alterazione. Riservatezza: il sistema deve impedire a chiunque di ottenere o dedurre, direttamente o indirettamente, informazioni che non è autorizzato a conoscere. Vale la pena di osservare che, in

9 Pagina 9 di 85 determinati contesti, il fatto stesso che un informazione sia protetta, o che esista una comunicazione in atto fra due utenti o processi, può essere sufficiente per dedurre informazioni riservate. 1.2 Un approccio sistematico Un approccio sistematico alla Sicurezza di rete, prevede lo studio dei seguenti elementi fondamentali: Attacchi. Modelli per la sicurezza. Servizi che migliorano la sicurezza Attacchi Si può definire un attacco come ogni evento che comprometta la sicurezza di una rete. Tali eventi possono essere suddivisi in: Eventi indesiderati Attacchi deliberati Eventi indesiderati L esigenza della sicurezza nasce dal fatto che possono accadere eventi indesiderati che determinano un degrado nelle caratteristiche di integrità, disponibilità e riservatezza. Un buon punto di partenza per definire un evento indesiderato è costituito dal considerare come tale qualsiasi accesso (a servizio o informazione) che non sia esplicitamente permesso dalla politica di sicurezza del sistema. L insieme degli eventi indesiderati tuttavia, è ben più esteso, in quanto comprende eventi che non sono affatto degli attacchi deliberati, bensì dei semplici eventi accidentali. Stando alle statistiche, il fattore umano (per esempio cancellazione accidentale di file, installazione di componenti incompatibili o infettate che corrompono il software di base) resta la principale causa di perdita accidentale di dati. Per quanto riguarda gli eventi accidentali di altra origine, accanto ai guasti più frequenti (dischi, alimentatori, memoria, ecc.) occorre valutare anche i guasti a dispositivi di supporto come condizionatori d aria o trasformatori di potenza, ed eventi disastrosi come l incendio o l allagamento della sala in cui sono conservati gli elaboratori. Per questo motivo si fa riferimento al concetto più generale di evento indesiderato.

10 Pagina 10 di 85 Attacchi deliberati Non ritenendo opportuno, in questa sede, elencare in dettaglio tutti i possibili attacchi (migliaia) che possono essere sferrati ai più disparati sistemi informativi sparsi sul pianeta (per questo si rimanda al sito abbiamo provveduto alla classificazione degli stessi sulla base delle tipologie di danno che provocano ai sistemi. Alla luce di ciò sono possibili quattro tipi di attacco: - Interruzione Una parte del sistema viene distrutta o diventa non utilizzabile. Questo è un attacco alla disponibilità del sistema. - Intercettazione Un soggetto non autorizzato ottiene accesso ad una componente del sistema. Questo è un attacco alla riservatezza. - Modifica Un soggetto non autorizzato entra in possesso di una componente del sistema, la modifica e la introduce di nuovo nello stesso. Questo è un attacco all integrità. - Produzione Un soggetto non autorizzato produce componenti nuove e le immette nel sistema. Gli attacchi che fanno uso di queste tecniche non sono tesi ad accedere a servizi ed informazioni, ma semplicemente a degradare la operatività del sistema. Sono considerabili come atti di sabotaggio, e minacciano tipicamente l integrità e la disponibilità, più raramente (e indirettamente) la riservatezza. Nel considerare un attacco deliberato, è conveniente distinguere la componente attaccata e la tecnica utilizzata dall intrusore. Un approccio sistematico individua tutte le componenti del sistema, sia fisiche (calcolatori, router, cavi) che logiche (file, processi, ecc.) e, per ciascuna di esse, individua tutte le tecniche di attacco ad essa applicabili. Il risultato di questo approccio può essere convenientemente riassunto in una matrice avente le componenti su un asse e le tecniche di attacco sull altro. Una cella di tale matrice permetterebbe infatti di descrivere se e come una certa tecnica può essere utilizzata per attaccare una certa componente Servizi Si fa riferimento a tutti quei servizi che migliorano la sicurezza del sistema e delle informazioni in transito, quelli che fronteggiano gli attacchi e ne prevengono gli effetti disastrosi.

11 Pagina 11 di 85 Essi possono essere suddivisi in: Confidenzialità: è la proprietà per cui l informazione non è resa disponibile a soggetti non autorizzati. In sostanza garantisce che se un soggetto non autorizzato entra in possesso del messaggio che veicola l informazione, quest ultima è per lui non intelligibile. Integrità: è la proprietà di inalterabilità dell informazione (sia che essa venga scambiata sia che venga memorizzata e successivamente recuperata). Autenticazione: è la verifica dell identità dichiarata da un soggetto. Tramite l autenticazione il soggetto ricevente è sicuro sull identità del soggetto mittente (impedendo quindi che un impostore non si spacci per il mittente e trasmetta informazioni non vere) e viceversa il soggetto mittente è sicuro sull identità del soggetto destinatario (impedendo che un impostore non si spacci per il destinatario e riceva informazioni non destinate a lui). Autorizzazione: è la determinazione se autorizzare o meno un soggetto a richiedere l accesso ad una risorsa. In generale ad ogni soggetto sono concessi dei diritti, ad ogni risorsa sono associate delle liste di diritti (ACL Access Control List) e quindi il processo di autorizzazione consiste nel verificare la corrispondenza tra i diritti concessi al soggetto ed il tipo di richiesta che il soggetto sta eseguendo. Una ACL è una lista dei soggetti autorizzati, in cui per ognuno sono specificati i rispettivi diritti. Non ripudio: è la proprietà per cui il destinatario di una comunicazione può provare che il mittente effettivamente abbia effettuato la comunicazione, anche se quest ultimo successivamente volesse negare di averla mai effettuata. Auditing: è l azione di registrare, in modo permanente e non modificabile, tutte le richieste (e le rispettive risposte) effettuate dai soggetti al sistema o tra di loro Modelli per la Sicurezza L obiettivo di questi meccanismi è quello di rendere sicuri i sistemi implementando i Servizi di sicurezza appena descritti. Va notato come nessuno di questi, attualmente, sia in grado di offrire tutti i servizi richiesti, ovvero non sia capace di fronteggiare tutti i possibili attacchi, ed è per questo motivo che rendere un sistema sicuro richiede un approccio ingegneristico che, utilizzando il giusto mix di meccanismi, ottenga il

12 Pagina 12 di 85 desiderato livello di sicurezza. La maggior parte di questi meccanismi utilizza un comune meccanismo di base: la tecnica crittografica. Molti vendors si impegnano nel proporre soluzioni integrate per ottenere sicurezza. Si tratta molto spesso di soluzioni diverse da vendor a vendor ma tutte quante assimilabili per le caratteristiche e le funzionalità svolte dai moduli che ne fanno parte. Un esempio tipico è costituito dal seguente schema, secondo cui la sicurezza è composta da sei elementi essenziali, ognuno dei quali implementato da diversi prodotti Hardware o Software: 1. Policy aziendale per la sicurezza 2. Controllo dell identità 3. Sicurezza perimetrale 4. Connettività sicura 5. Monitoraggio della sicurezza 6. Gestione della sicurezza 1. Policy aziendale per la sicurezza Il processo di valutazione che è necessario effettuare per stabilire quali servizi adottare e quali protocolli utilizzare per la loro attuazione è un processo mai definitivo che deve portare alla stesura e alla revisione in tempo reale di una efficace politica di sicurezza. La politica di sicurezza stabilisce cosa può essere e cosa non può esser fatto, nonché le modalità che devono essere seguite per utilizzare i vari servizi. Essa deve esistere ogni qualvolta si prevede di utilizzare la rete ed i servizi che attraverso di essa sono ottenibili. Le direttive impartite dall azienda per svolgere la sicurezza dovrebbero basarsi sulle seguenti domande: - Qual è il mio network business plan? - Quali risorse devo proteggere? - Quali servizi prevedo di offrire? - Quali rischi portano per la sicurezza? - Quali strumenti o metodi sono disponibili per ridurli? - Qual è il mio livello di rischio accettabile? 2. Controllo dell identità Processo noto con la sigla AAA, ovvero:

13 Pagina 13 di 85 - Autenticazione, con la quale si verifica l identità dell utente del sistema, tipicamente tramite l uso dei certificati digitali e crittografia. - Autorizzazione, con la quale si costringe ogni utente ad avere tutti e soli i diritti a lui necessari e nessun altro. - Accounting, grazie alla quale è possibile svolgere attività di Audit delle attività degli utenti, ovvero la tenuta di appositi files di log per registrare e controllare le attività da essi svolte sul sistema. 3. Sicurezza Perimetrale Attraverso di essa si gestisce il traffico consentito verso l interno o verso l esterno dei segmenti di rete. Di solito vengono utilizzati a tale scopo, i seguenti strumenti: - Router con ACL (Access Control List) attraverso cui è possibile filtrare tutto il traffico consentito e non che entra nel sistema a livello di routing. - Firewall attraverso cui è possibile proteggersi da attacchi interni e/o esterni. - Filtraggio contenuti o Packet filtering, tecnica che impedisce l ingresso di pacchetti ritenuti portatori di contenuti proibiti. 4. Connettività Sicura (VPN Virtual Private Network) Questo modulo si occupa di creare un meccanismo di trasferimento sicuro dei dati dall una all altra estremità di una rete (internet). E questo l argomento della presente relazione e ne tratteremo approfonditamente nei prossimi capitoli. Qui sottolineiamo solamente gli obiettivi che questa tecnologia si prefigge: - Privacy dei dati/crittografia (protezione dei dati in ambienti non affidabili) - Ampliamento della portata e dei servizi della rete senza l ausilio di reti dedicate ma attraverso Internet. - Incremento dei risparmi in termini di costo per la realizzazione della tecnologia 5. Monitoraggio della sicurezza E lo strumento impiegato per il monitoraggio dei pacchetti entranti e uscenti da un certo segmento di rete (IDS Intrusion detection System). Può essere visto come l equivalente delle telecamere a circuito chiuso utilizzate dalle banche per monitorare il comportamento di possibili rapinatori. Questo tipo di strumenti permette il confronto tra i requisiti dei pacchetti entranti (morfologia e/o sequenza) con alcuni pattern

14 Pagina 14 di 85 inseriti nell IDS precedentemente. Nel caso di un riscontro positivo, l IDS provvederà a segnalare un allarme attacco (il loro comportamento è molto simile agli antivirus). 6. Gestione della sicurezza E l insieme degli strumenti Hardware e Software attraverso i quali è possibile, da un unica postazione, gestire tutto il resto dei moduli appena descritti, centrando lo sviluppo e la gestione della policy di sicurezza. 1.3 Conclusioni Concludiamo questo capitolo ricordando che la Sicurezza non è un prodotto ma un processo aziendale, e il cuore di questo processo è la Policy di Sicurezza. Per questo motivo essa deve essere continuamente aggiornata e in sincronia con la dinamica aziendale. La sicurezza non è un prodotto, è un processo. Non potete semplicemente aggiungerla ad un sistema dopo il fatto. E essenziale conoscere le reali minacce che incombono su un sistema, definire una politica di sicurezza commisurata a tali rischi e mettere in atto appropriate contromisure (Bruce Schneier Segreti e Bugie )

15 Pagina 15 di 85

16 Pagina 16 di Cos è una VPN e perché utilizzarla? 2.1 Introduzione Il concetto di Virtual Private Network (VPN) è spesso molto confuso. Lo stesso significato dei termini utilizzati per definirla può variare sensibilmente a seconda della situazione in cui li utilizziamo. Per meglio chiarire il concetto conviene analizzare singolarmente i termini dell acronimo. Per quanto riguarda il termine Network (rete), in questo caso la genericità è obbligatoria per via delle differenze che possono esistere tra diversi tipi di rete. Diciamo che, in generale, una rete è un insieme di apparecchiature in un qualche modo tra loro collegate e tra le quali può intercorrere uno scambio di dati. Una definizione più specifica sarebbe troppo limitante. Vediamo ora di definire il termine Private (privato). Che qualità deve avere un oggetto per essere definito privato? La prima tentazione è quella di far coincidere il termine privato col termine sicuro. Ma questo sarebbe un grosso errore Basti pensare che la maggior parte degli attacchi alle reti private sono messi in atto da personale interno alla ditta stessa. Proviamo a pensare a qualcosa di fisico come, ad esempio, la nostra casa. Indubbiamente la nostra casa è privata. Eppure tutti possono vederla, almeno dall esterno. Possono cercare di inviarci informazioni attraverso la buca delle lettere o attraverso il telefono. Ma quel che sicuramente non possono (o non dovrebbero poter) fare è fruirne con la stessa libertà con cui lo facciamo noi e questo in base al principio che noi solamente ne deteniamo la proprietà. Possiamo decidere quando entrarci, cosa farvi all interno e per quanto tempo. Non per questo però, la nostra privacy viene tutelata automaticamente. Se ad esempio fossimo molto orgogliosi del nostro arredamento, potremmo decidere di permetterne la visibilità all esterno facendo installare un ampia vetrata. Quindi privato non vuol dire neanche nascosto. Il temine Virtual (virtuale) deve essere preso in congiunzione con i termini Private e Network. Di per sè, una cosa virtuale svolge le funzioni di qualcos altro che non è fisicamente presente. Tiriamo le somme: una rete privata è una rete le cui parti sono di proprietà di un ente ben definito che ne regolamenta l utilizzo, la visibilità e la fruizione. Una Virtual Private Network è un qualcosa che svolge le stesse funzioni e offre le stesse caratteristiche di servizio di una rete privata. Con la VPN, la rete privata è realizzata costruendo sopra una risorsa pubblicamente condivisa, un insieme di infrastrutture che implementano le stesse funzionalità della rete privata e che quindi permettono un controllo sulla visibilità e sulla fruibilità delle informazioni scambiate da parte del detentore della VPN stessa.

17 Pagina 17 di 85 Una possibile definizione di VPN è quindi la seguente: Una VPN è una rete privata immersa all interno di una rete pubblica come, ad esempio, internet. Questa definizione è molto generica e forse non pienamente soddisfacente ma entrare più nello specifico non permetterebbe di apprezzare tutte le sfaccettature di questo tipo di organizzazione delle infrastrutture di rete. Esistono diverse tipologie di VPN: 1. Virtual Private Dial-up Network (VPDN) che si realizza tra un utente dial-up ed una LAN; 2. Site-to-Site quando è necessario, non solo fornire determinati servizi, ma realizzare anche una compenetrazione delle reti dislocate a distanza. Quest ultimo, a sua volta, può essere: a. Intranet-based, quando un'azienda o un ente ha una o più sedi remote da collegare tra loro per condividere le informazioni ed i servizi; b. Extranet-based, che si realizza quando una azienda o un ente ha uno stretto rapporto di collaborazione con partner esterni (come la relazione tra siti di commercio elettronico e le banche o le ditte di spedizione).

18 Pagina 18 di Il perché di una VPN Ci sono diversi motivi per cui un azienda potrebbe essere interessata alla realizzazione di una VPN. Sicuramente la motivazione di base è legata all economicità di questa soluzione rispetto a quelle che prevedono l acquisto o la realizzazione di collegamenti dedicati tra le diverse entità della rete aziendale. Inoltre, in riferimento alla figura precedente, le diverse realtà non solo richiedono differenti tipologie di collegamento ma anche una particolare adattabilità al mutamento della struttura e della topologia della rete. Anche la necessità della confidenzialità e dell integrità dei dati è una motivazione per scegliere una VPN. Quando un azienda si rivolge ad un provider di servizi di telecomunicazione per acquistare un collegamento dedicato tra le sue filiali, deve obbligatoriamente fidarsi dell onestà del provider stesso. Molto spesso però il collegamento acquistato non è totalmente dedicato (di norma, per ovvi motivi economici, i providers tendono a far utilizzare gli stessi collegamenti a più aziende), quindi l azienda non può fisicamente controllare un eventuale malintenzionato che si mette in ascolto sul cavo. Una VPN mette a disposizione una serie di metodi per garantire sia la riservatezza che l integrità dei dati, nonostante essi transitino su di una infrastruttura pubblica. La sicurezza è un aspetto critico per una VPN. Il fatto che certe informazioni, dall interno dell azienda, passino su canali pubblicamente condivisi, non sempre può essere un aspetto desiderabile. Per ovviare a questo problema vengono utilizzati diversi protocolli che realizzano un canale sicuro tra i punti di collegamento (che siano due gateways o due hosts) delle aziende. All interno di questo canale le informazioni possono fluire tranquillamente. Il canale fornisce una serie di servizi fondamentali: la riservatezza dei dati trasmessi, la loro integrità e l autenticazione del mittente e del destinatario. La realizzazione pratica di questi servizi dipende dal livello dello stack ISO/OSI sul quale si decide di lavorare e le modalità con cui le informazioni vengono imapacchettate prima di affrontare il viaggio attraverso l infrastruttura pubblica.. Generalmente la soluzione più adottata è quella di creare un tunnel lavorando al livello 3 dello stack TCP/IP (quello della rete), utilizzando un insieme di strumenti denominato IPSec. Per meglio chiarire tale concetto vediamo un esempio introduttivo: Nell immagine successiva vediamo come l host h1, nella LAN1, invii dati all host h2 in LAN2. I dati passano prima al Security Gateway SG1 il quale li impacchetta prima di spedirli a SG2. Una volta spacchettate le informazioni, SG2 potrà leggere l indirizzo di h2 e inviargli i dati di h1. Durante tutti questi passaggi h1 e h2 non si accorgono minimamente del fatto che i dati sono transitati su di una rete pubblica.

19 Pagina 19 di 85 Inoltre SG1 e SG2 si sono adoperati per fare in modo che tali dati fossero protetti da qualsiasi intromissione esterna al canale. Nello scenario precedente abbiamo visto come sia possibile realizzare un tunnel tra due gateway che permettono ad hosts delle LAN aziendali di comunicare tra loro su di una rete pubblica.. Un ulteriore possibilità è quella di fornire un servizio di VPN anche ad utenti di tipo dial-up. Questo tipo di soluzione si chiama Virtual Private Dial Network (VPDN). Il protocollo più diffuso è il Layer 2 Tunnel Protocol (L2TP). Questo protocollo si basa su due protocolli proprietari precedenti: il Layer 2 Forward (L2f), sviluppato dalla Cisco, ed il Point to Point Tunneling Protocol (PPTP), sviluppato dalla Microsoft. In pratica, con questo protocollo, un utente si collega, tramite un modem sulla linea telefonica, al suo usuale ISP. A questo punto, una volta che il server ISP effettua l autenticazione del client dial-up e riconosce che l utente appartiene ad una determinata VPDN, crea un tunnel L2TP con il server della VPDN dell ente di appartenenza dell utente e, al suo interno, farà passare il traffico PPP:

20 Pagina 20 di 85 Questi sono solo due esempi di come sia possibile realizzare una simile infrastruttura. Tutto ciò però, può aiutare ad avere un idea di un altra caratteristica molto importante delle VPN: la loro elasticità ed adattabilità. 2.3 Un piccolo esempio Abbiamo visto, in modo molto generale, come sia possibile realizzare collegamenti tra reti diverse e utenti diversi utilizzando livelli diversi dello stack TCP/IP (ma anche ISO/OSI). Realizzare tutto questo è quasi completamente indolore per chi amministra la rete e può rimane completamente invisibile agli utenti che utilizzano le infrastrutture. Prima di vedere come effettivamente può essere realizzata una VPN tramite IPSec, vediamo quali sono gli obiettivi e i modi per perseguirli. Il primo passo è sicuramente quello di stabilire una politica di sicurezza relativa alla circolazione delle informazioni. E fondamentale capire quali servizi offrire (crittografia, autenticazione, etc.) e con quale profondità (crittografia anche all interno delle LAN o solo sull infrastruttura pubblica?). Questo perché una sicurezza troppo lasca permetterebbe accesso ad informazioni che si vorrebbero tenere segrete, mentre una sicurezza eccessiva consumerebbe inutilmente l utilizzo di risorse (CPU, memoria, etc..). Ecco lo schema del nostro esempio: Ipotizziamo che H1 e H2 vogliano dialogare tra di loro. Per fare questo SG1 e SG2 devono aprire un tunnel attraverso il quale far passare i dati che H1 e H2 devono scambiarsi. Ipotizziamo che sia H1 a voler parlare con H2. Il messaggio da H1 a H2 avrà come indirizzo di destinazione un indirizzo appartenente alla rete /24, perciò percorrerà tutta la LAN1 sino a raggiungere il gateway SG1.

21 Pagina 21 di 85 SG1 deve controllare, in una base dati, che azione intraprendere per questo messaggio. Una entry possibile potrebbe essere del tipo: Indirizzo Origine / /24 Indirizzo Destinazione /24 * Politica VPN crittografia richiesta Nessuna azione Questa entry è molto limitata. Vedremo come, in realtà, le informazioni necessarie per attuare la politica di sicurezza siano decisamente più numerose Accordo tra i gateways A questo punto, SG1 controllerà se esiste già un accordo con SG2 per stabilire un tunnel con servizio di crittografia ed autenticazione. Nel caso non ci sia un tale accordo, sarà necessario che SG1 contatti SG2 per negoziare i servizi richiesti da questo particolare tipo di traffico. Per fare questo, si devono affrontare due fasi. Nella prima fase SG1 e SG2 si autenticano reciprocamente e si accordano su un insieme di algoritmi crittografici da utilizzare per cifrare il loro traffico. Nella seconda fase si

22 Pagina 22 di 85 scambieranno gli accordi per proteggere il traffico tra gli altri host delle LAN. Nell immagine seguente, ad esempio, durante la prima fase, SG1 propone due diverse suite crittografiche a SG2: la prima sarà <DES (per la cifratura simmetrica), MD5 (per il controllo dell integrità dei messaggi), RSA (per l autenticazione), gruppo 1 di scambio Diffie-Hellman (per lo scambio delle chiavi di sessione)>, mentre la seconda sarà <DES, MD5, autenticazione basata su chiavi pre-distribuite, DH1>. Ora sarà SG2 a comunicare la suite prescelta a SG1: Una volta fatto ciò, SG1 e SG2 si scambiano i dati richiesti dagli algoritmi crittografici scelti. Nella seconda fase invece, SG1 e SG2 negoziano i pacchetti crittografici da utilizzare per il traffico tra gli hosts delle due reti. Il meccanismo è lo stesso utilizzato per la negoziazione della suite tra SG1 e SG2. SG1 fa una serie di proposte ordinate per preferenza e SG2 segnala quella che meglio si avvicina alle sue politiche di sicurezza relative al tipo di traffico per il quale si sta negoziando.

23 Pagina 23 di 85 Opzionalmente SG1 e SG2 possono rinnovare le chiavi crittografiche che utilizzano per cifrare le loro comunicazioni. A questo punto, SG1 ha concordato con SG2 tutti i dati che serviranno per dare inizio alla comunicazione tra H1 e H Invio del messaggio Un messaggio tipo da H1 ad H2 sarà qualcosa come: Ora che SG1 ha stabilito un accordo con SG2, può iniziare a manipolare il messaggio secondo le regole prestabilite. Ecco come sarà il messaggio risultante: Come si può ben vedere questo messaggio non sembra avere niente a che vedere con quello precedente. I mittenti originali sono spariti e i dati del datagrams sono completamente cifrati.

24 Pagina 24 di 85 Una volta immesso nella rete pubblica, questo messaggio giungerà correttamente a SG2. Ricevuto il messaggio, SG2 utilizza gli algoritmi e le chiavi negoziate con SG1 per svelare il datagram originale e leggere l indirizzo dell effettivo destinatario. A questo punto il pacchetto viene finalmente inviato nella LAN2. E da notare come il datagram sia arrivato a destinazione senza che nessuno dei due hosts si sia accorto del suo passaggio dalla rete pubblica. Tutto il lavoro è stato svolto da SG1 e SG2 che, da questo momento e grazie agli accordi presi, faranno da ponte tra le due LANs offrendo tutti i servizi previsti per quella locale politica di sicurezza.

25 Pagina 25 di 85

26 Pagina 26 di IPSec: La soluzione standard alla sicurezza IP 3.1 Introduzione IPsec (IP Security) è una suite di protocolli che fornisce sicurezza allo strato della rete. E un oggetto piuttosto complesso, e diverse parti di esso sono descritte in oltre una dozzina di RFC. Prima di entrare nelle specifiche di IPSec, facciamo qualche passo indietro e consideriamo cosa significa fornire sicurezza allo strato della rete. Lo strato della rete riuscirebbe a garantire una certa sicurezza se tutti i dati trasportati da tutti i datagram IP fossero cifrati. Questo significa che ogni volta che un host vuole inviare un datagram, esso dovrebbe cifrare il campo dati del datagram prima di inviarlo nella rete. Ovviamente, riuscendo a cifrare l intero datagram oltre che il solo campo dati, si otterrebbe una sicurezza ancor maggiore nascondendo anche le informazioni riguardanti l origine e la destinazione del flusso. Il campo dati potrebbe essere un segmento UDP, un messaggio ICMP, e così via. Se questo servizio di rete fosse disponibile, tutti i dati inviati dagli host (comprese , pagine web, comandi e messaggi di gestione come SNMP) risulterebbero nascosti a qualsiasi terza parte interessata ad intercettarli dalla rete. Oltre alla segretezza, si potrebbe desiderare che lo strato della rete fornisca l autenticazione della sorgente. In tal caso, quando un host destinatario riceve un qualsiasi datagram IP, esso dovrebbe autenticare il mittente verificando l effettiva corrispondenza tra il pacchetto ricevuto e il mittente stesso Sulla base delle suddette considerazioni possiamo dire che lo standard IPSec permette di fornire i seguenti servizi: 1. confidenzialità dei dati (crittografia); 2. confidenzialità delle parti effettivamente coinvolte nel flusso del traffico; 3. integrità dei dati; 4. autenticazione del mittente; 5. protezione contro gli attacchi di replay. Per fare ciò IPSec si serve dei seguenti protocolli: l AH (Autentication Header) e l ESP (Encapsulating Security Payload). Il protocollo AH fornisce l autenticazione della sorgente e l integrità dei dati ma non la segretezza, l ESP fornisce l integrità dei dati, l autenticazione e la segretezza. Fornendo più servizi, il protocollo ESP è naturalmente più complicato e richiede più elaborazioni rispetto al protocollo AH. Sia nel

27 Pagina 27 di 85 caso dell AH che nel caso dell ESP, prima di inviare datagram sicuri sul canale, l host sorgente e quello destinazione si devono prima scambiare l handshake creando una connessione logica sullo strato della rete. Questo canale logico è detto Associazione di Sicurezza SA (Security Association). Quindi l IPSec trasforma il tradizionale strato della rete non orientata alla connessione di Internet, in uno strato con connessioni logiche. La connessione logica definita da un SA è una connessione simplex, cioè unidirezionale. Se entrambi gli host volessero scambiarsi datagram sicuri dovrebbero essere stabilite due connessioni SA, una in ciascuna direzione. Una SA è unicamente identificata da: Un identificatore del protocollo di sicurezza (AH o ESP); L indirizzo IP destinazione per una connessione simplex; Un identificatore a 32 bit della connessione, detto indice dei parametri di sicurezza (SPI, Security Parameter Index). Per una data SA ciascun datagram IPSec avrà un campo speciale per il SPI. In questo campo tutti i datagram di quella SA useranno lo stesso valore SPI. Per un buon funzionamento di IPSec, è necessario uno schema SA di scala e automatico per la gestione delle chiavi. Per fare questo ci sono due protocolli principalmente utilizzati: il protocollo Internet per la gestione delle associazioni per la sicurezza e delle chiavi ISAKMP (Internet Secutiy Association & Key Management Protocol) il quale definisce le procedure per stabilire e interrompere le SA [RFC 2407,RFC 2408]. ISAKMP prevede due fasi per contrattazione: una prima fase in cui gli end-points della comunicazione si autenticano e si accordano su un insieme di funzioni crittografiche per lo scambio dei dati (IKE SA); una seconda fase in cui avviene lo scambio vero e proprio delle SA (IPSec SA); il protocollo Internet per lo scambio delle chiavi IKE (Intenet Key Exchange) RFC Nei prossimi capitoli entreremo in dettaglio su ognuna delle suddette funzionalità cercando di analizzare come queste abbiano portato IPSec ad essere considerato lo standard di fatto per una connettività sicura. 3.2 Security Association (RFC 2401) IPSec può essere utilizzato in due modalità: trasporto e tunnel. Nella modalità trasporto, i dati relativi al protocollo IPSec sono inseriti nel datagram IP, tra l header IP e quello subito superiore (solitamente TCP o UDP). Questo tipo di soluzione può essere necessaria nel caso di comunicazioni end-to-

28 Pagina 28 di 85 end. In tutti gli altri casi è obbligatorio utilizzare la modalità tunnel. In questo caso il pacchetto IP viene inglobato in quello IPSec al quale, a sua volta, viene aggiunto un nuovo header IP con gli indirizzi dei security gateways che stanno ai due capi del tunnel. Da questa immagine si vede chiaramente come i campi dell header IP non siano assolutamente protetti nel caso di modalità trasporto. Per ottenere il servizio di cui al punto 2 visto sopra, è quindi necessario utilizzare la modalità tunnel. Nei prossimi paragrafi vedremo come una Security Association possa usufruire delle suddette modalità cercando di individuarne anche le possibili applicazioni reali SA in transport mode Si utilizza nel caso di connessione tra due hosts. In IPv4 l header del protocollo di sicurezza si trova subito dopo l header IP e le relative opzioni e prima dei protocolli di livello superiore (TCP o UDP). IPv4 in transport mode Nel caso in cui stia utilizzando ESP, una SA in transport mode fornirebbe sicurezza ai protocolli di livello superiore ma non all header IP o a tutto ciò che precede l header ESP. Nel caso di AH, la protezione è anche estesa a porzioni selezionate dell header IP e delle sue estensioni e/o opzioni.

29 Pagina 29 di SA in tunnel mode Si deve utilizzare sempre quando uno dei due estremi è un security gateway, per evitare (potenziali) problemi relativi alla frammentazione/riassemblaggio di pacchetti IPSec (vedi appendice B per un maggiore approfondimento), e in situazioni dove esistono percorsi multipli (dopo un gateway) per raggiungere la stessa destinazione. esempio di SA in tunnel mode - Posso inoltre utilizzarla in caso di connessione tra due hosts. Per una SA in tunnel mode, esiste un header IP esterno, che specifica dove il pacchetto dovrà essere processato da IPsec e un IP header interno, che specifica la destinazione finale (apparentemente) 1 del pacchetto. L header del protocollo di sicurezza utilizzato si trova tra i due. - IPv4 in tunnel mode Funzionalità di una SA L insieme dei servizi di sicurezza offerti da una SA dipende dal protocollo selezionato, dalla modalità dell SA, dai punti terminali dell SA e dalla scelta di servizi opzionali all interno del protocollo. Se è stata richiesta criptazione tra due security gateways, verrà creata una SA in tunnel mode che utilizzerà come protocollo l ESP. L uso della modalità tunnel permetterà agli header IP interni di essere criptati, nascondendo così l identità della sorgente e della destinazione finale. E questo, per esempio, il caso di una connessione 1 Questo perché sono possibili più livelli di annidamento. In tal caso la destinazione finale non coinciderebbe con tale indirizzo IP.

30 Pagina 30 di 85 telefonica tra un utente mobile e il firewall della società alla quale si sta collegando (che in questo caso opererebbe come un security gateway) Combinazione di più SA Quando una politica di sicurezza richiede la combinazione di più servizi, può non essere sufficiente l uso di una singola SA. Queste possono essere combinate tra loro (SA bundle) in due modi: transport adjacency mode e iterated tunneling mode. Transport adjacency mode: Applico più di un protocollo di sicurezza allo stesso pacchetto IP senza invocare tunneling. E possibile combinare AH ed ESP una sola volta; ulteriore annidamenti non porterebbero nessun beneficio. L esempio più frequente è costituito da un pacchetto che viene autenticato tramite AH, ma cifrato con ESP, in modo tale da godere dei vantaggi di entrambi i protocolli2. transport adjacency mode - Iterated tunneling mode: Applicando la tecnica del tunneling posso utilizzare più livelli di annidamento, in quanto ogni tunnel può avere origine o terminare su differenti siti lungo il percorso che implementano IPsec. 2 Vedremo infatti che AH autentica meglio di ESP poiché comprende nell Autenticazione anche l header IP del pacchetto originale. D altronde l uso di ESP è inevitabile perché è il solo protocollo che permette la segretezza.

31 Pagina 31 di 85 I casi principali sono tre: 1) entrambi i punti terminali della SA sono gli stessi; i tunnel possono utilizzare indifferentemente AH o ESP, anche se solitamente l host mittente specifica sempre lo stesso protocollo per tutti i tunnel. Per esempio si potrebbe volere un tunnel per trasportare AH ed un altro per trasportare ESP, diretti entrambi allo stesso host. In questo caso vengono incapsulati l uno dentro l altro e inviati sul canale. iterated tunneling mode - 2) Solo uno dei punti terminali è lo stesso (si usa indifferentemente sia AH che ESP). Siamo nel caso in cui un Host mittente, per accedere ad un Host situato dall altro lato del tunnel, deve prima conquistare l accesso al Firewall del Security Gateway anch esso posizionato dall altro lato. In questo caso il primo tunnel avrà funzioni di autenticazione e si fermerà al gateway, mentre quello incapsulato implementerà la segretezza e arriverà a destinazione. iterated tunneling mode - 3) Nessuno dei punti coincide. Anche in questo caso si utilizza indifferentemente AH o ESP. Nell esempio che segue i tunnel incapsulati potrebbero essere addirittura tre; uno per autenticare i due gateway tra

32 Pagina 32 di 85 loro, uno per autenticare i due host e l altro per l invio dei dati cifrati all host finale. iterated tunneling mode - L approccio Adjacent Transport e Iterated Tunneling possono essere combinati: per esempio potremmo avere una SA in tunnel mode e una o più SA in transport mode applicate in sequenza. Se si decide di utilizzare l adjacent transport mode, sarebbe buona norma applicare prima ESP e poi AH, in modo tale da proteggere anche parte dell header IP, dato che AH si applica ai protocolli di strato superiore ma anche ai campi non mutabili dell header IP Databases Molti dei processi associati all implementazione di IPsec sono gestiti in locale e non necessitano di standardizzazione; tuttavia per assicurare interoperabilità e facilitare la gestione, alcuni aspetti esterni devono essere standardizzati. Si è giunti ad un modello che fa uso di due databases: SPD (Security Policy Database) e SAD (Security Association Database). Il primo specifica le politiche che gestiscono il traffico IP in arrivo o in partenza da un host o da un security gateway. Il secondo contiene i parametri che sono associati ad ogni SA attiva. Ogni interfaccia, per la quale è abilitato Ipsec, richiede l uso di database separati per il traffico entrante o uscente, a causa della direzionalità di molti dei campi usati come selectors4. Solitamente per ogni host o security gateway esiste solo un interfaccia che implementa IPsec. 3 I campi immutabili sono quelli che non cambiano durante l attraversamento della rete (per esempio IP address sorgente e quello destinazione), a differenza dei campi mutabili come per esempio il TTL che decrementa ad ogni Hop. 4 insieme di valori relativi al protocollo IP e a quelli di livello superiore usati da SPD per mappare il traffico

33 Pagina 33 di SPD: Security Policy Database Specifica quali servizi una SA può offrire ad un pacchetto IP e in che modo. L SPD deve essere consultato durante il processamento di tutto il traffico (entrante o uscente), incluso quello non sottoposto ad IPsec. Per questo, sono richieste entries differenti per il traffico in entrata e uscita. Si può immaginare questo come due SPD separati. Per ogni pacchetto entrante o uscente sono possibili tre scelte: 1) scarto del pacchetto, che quindi non può lasciare l host, non può attraversare il security gateway o essere consegnato ad una applicazione. 2) bypass di IPsec (il pacchetto può transitare senza che gli venga fornita protezione da IPsec). 3) utilizzo di IPsec. Per ogni implementazione di IPsec, ci deve essere un interfaccia di amministrazione che permetta al system administrator di gestire il SPD. Questa interfaccia deve permettere la creazione di entries consistenti con i selectors e deve supportare l ordinamento delle stesse. L uso di wildcards ne permette una gestione più agile ed efficiente. L SPD contiene quindi una lista ordinata di policy entries, ognuna delle quali è identificata da uno o più selectors; questo meccanismo definisce la granularità delle politiche o delle SA. Ogni entry comprende un indicazione sul da farsi nel caso in cui il traffico coincida con la politica selezionata. Se IPsec deve essere applicato, l entry includerà le specifiche di una SA (o SA bundle); in particolare i protocolli, le modalità e gli algoritmi utilizzati, compresi tutti i requisiti per il nesting (nidificazione) Selectors Una SA può essere definita a vari livelli, che dipenderanno dai selectors utilizzati per definire l insieme del traffico. I seguenti selectors devono essere supportati per la gestione della SA, in modo tale da poterne controllare facilmente la granularità: Destination IP Address: può essere un indirizzo singolo, multicast, un intervallo di indirizzi, indirizzi più la maschera o indirizzi specificati da una wildcard. Gli ultimi tre sono utilizzati per supportare più di un destinatario che condivida la stessa SA. Questo è concettualmente differente dal campo Destination IP Address presente nella tripla che definisce una SA e proviene dall header IP incapsulato. Quando un pacchetto, inviato tramite tunneling, arriva ad uno degli estremi, si utilizzano i suoi campi SPI, Destination Address e Protocol per cercare nel SAD la SA relativa. Una volta che il pacchetto è stato decriptato, i suoi selectors sono cercati nell inbound SPD.

34 Pagina 34 di 85 Questo ha uno specifico selector chiamato destination address. Questo indirizzo IP è quello interno (incapsulato). Se il pacchetto fosse stato inviato in transport mode, sarebbe stato presente solo un header IP e non si sarebbero presentati problemi di ambiguità. Source IP Address: può essere un indirizzo singolo o multicast, un intervallo di indirizzi, indirizzi più la maschera o indirizzi specificati da una wildcard. Questi ultimi tre sono utilizzati per supportare più di una sorgente che condivida lo stesso SA. Name: può essere uno user ID (l IPSec Domain Of Interpretation prevede sia stringhe DNS come david_luca@micronix.net, sia X.500 distinguished names tipo C=IT, O=Micronix, OU=Network Management, CN=David&Luca ) o system names (che possono essere stringhe DNS, tipo micronix.net o X. 500 distiguished names oppure X.500 general names). Deve inoltre prevedersi che questo campo sia lasciato opaco 5. Data Sensitivity Level: questo campo permette una maggiore granularità6 nella realizzazione delle politiche di sicurezza. I valore assumibili sono definiti nella rfc Transport Layer Protocol: può essere il campo Protocol del datagram IPv4. In pratica, ogni implementazione di IPSec deve scandire il datagram, in profondità, fino a che non trova un codice di protocollo di trasporto che riconosca come tale, fino a che non incontra un codice di protocollo che non è nella lista dei protocolli riconosciuti oppure fino a che non sia possibile scandire oltre il datagram (ad esempio nel caso in cui il campo Protocol punti a ESP). In questi ultimi casi, deve prevedersi che il valore del Transport Layer Protocol sia lasciato opaco. Source e Destination Port: possono essere dei valori singoli o wildcard (TCP o UDP). Potrebbe essere opaca a causa di un header ESP. 5 Ovvero si deve prevedere la possibilità che il campo venga cifrato e quindi possa non essere visibile. E possibile costruire più tunnel realizzando livelli incrementali logici tra un mittente ed una destinazione. Questo al fine di assegnare tunnels diversi a servizi diversi. 6

35 Pagina 35 di SAD: Security Association Database Ogni entry definisce i parametri associati ad una SA; di conseguenza ogni SA deve avere una entry nel SAD. Per il processamento del traffico uscente, le entries sono puntate da quelle presenti nel SPD. Nel caso in cui una entry nel SPD non faccia riferimento a nessuna SA, IPSec dovrà creare una SA appropriata e collegare l entry dell SPD con quella del SAD. Per il processamento del traffico IPSec entrante invece, ogni entry nel SAD è sicuramente indicizzata dalla tripla <indirizzo IP di destinazione, protocollo IPsec, SPI>, altrimenti il pacchetto viene scartato. Nello schema seguente verrà illustrato un esempio di flusso in entrata nel caso di protocollo ESP in modalità tunnel. - Inbound - I seguenti campi del pacchetto invece, sono utilizzati per cercare l SA nel SAD. Outer header s destination IP address. IPsec protocol: AH o ESP. SPI (Security Parameter Index): il valore a 32 bit utilizzato per distinguere differenti SA che terminano sulla stessa destinazione e usano lo stesso protocollo IPsec.

36 Pagina 36 di 85 Destination IP Address: indirizzo dell altra estremità della connessione che, non necessariamente, corrisponde all host che richiede il servizio. Per ogni selector, l entry nel SAD relativa alla SA deve contenere i valori negoziati al momento della creazione della SA. Il mittente userà questi valori per decidere l SA appropriata per un pacchetto uscente. Il destinatario utilizza questi campi per verificare che i valori dei selectors per un pacchetto in entrata corrispondano a quelli della SA utilizzata (è una verifica sull integrità della spedizione). I seguenti campi del SAD sono utilizzati per l IPSec processing (ovvero per la cifratura e/o decifrazione e per l applicazione di eventuali algoritmi di autenticazione): Sequence number counter: intero a 32bit usato per generare il campo sequence number negli header AH o ESP. Richiesto per tutte le implementazioni ma utilizzato solo per il traffico in uscita; Sequence counter overflow: una flag che indica se l overflow del campo Sequence Number Counter (ovvero se il numero di sequenza è maggiore di 232) deve o meno generare un log di audit. In ogni caso la SA deve essere abbattuta e rinegoziata. Anti-Reply Window: un contatore a 32bit e una mappa dei bit, utilizzati per determinare se un pacchetto in entrata (AH o ESP) è un replay. Richiesto per tutte le implementazioni ma utilizzato solo per il traffico in entrata; Algoritmi e chiavi, per AH e ESP, e header ESP per l autenticazione; algoritmi aggiuntivi a quelli usati nella SA che costituiscono un ulteriore discriminante. Lifetime dell SA: un intervallo di tempo dopo il quale una SA deve essere sostituita da una nuova SA con un nuovo SPI o terminata (un periodo di tempo approssimativo potrebbe essere un valore minore di 22 ore che è il tempo

37 Pagina 37 di 85 attualmente necessario per la rottura del DES). In realtà potrei usare un contatore basato sul tempo, sui byte o su entrambi. IPsec protocol mode: tunnel, transport o wildcard. Indica quale modo di AH o ESP è applicato al traffico di una determinata SA. Se viene selezionato wildcard, sarà l applicazione a dover specificare all implementazione IPsec la modalità da utilizzare. In questo modo siamo in grado di utilizzare la stessa SA sia per il tunnel che per il transport mode. Il destinatario non necessita di conoscere la modalità di spedizione dei pacchetti per un corretto processamento dell header IPsec del pacchetto. Nel prospetto seguente viene illustrato un esempio di flusso in uscita sempre nel caso di protocollo ESP in modalità tunnel. - Outbound Localizzazione di un Security Gateway Una serie di problemi si presentano quando un host deve cercare di trovare un altro host o un altro security gateway con il quale negoziare le proprie SA. Attualmente non esistono campi DNS o simili appositamente studiati per questo scopo. Ne segue che l unico modo per risolvere questo tipo di problemi è un attenta configurazione delle macchine. Ovvero, dovendo installare una VPN su IPSec sarà necessario installare a mano la lista degli indirizzi dei security gateways a disposizione. Questo tipo di procedura è

38 Pagina 38 di 85 limitante per l elasticità degli apparati ma è una scelta obbligatoria fin tanto che le comunicazioni protette al livello della rete non diventeranno uno standard largamente utilizzato.

39 Pagina 39 di AH (Authentication Header) RFC Introduzione Come già detto, il protocollo AH fornisce l identificazione dell host sorgente e l integrità dei dati ma non la segretezza. Quando un determinato host sorgente vuole inviare uno o più datagram utilizzando IPSec, prima stabilisce una SA con la destinazione, dopo di che può iniziare a spedire effettivamente i datagram sicuri verso di essa. Come abbiamo visto nei paragrafi precedenti esistono due modalità con cui è possibile implementare i protocolli IPSec, la modalità Trasporto e la modalità Tunnel. Vediamo come utilizzare il protocollo AH a tal proposito AH (Modalità Trasporto) In questa modalità i datagram IPsec comprendono l intestazione AH, che è inserita fra i dati del datagram IP originale (per esempio un segmento TCP) e l intestazione IP, come mostrato in figura. L header del pacchetto originale subisce una modifica nel campo next protocol nel quale viene inserito il valore 51 per indicare che il datagram sta incapsulando un intestazione AH (sarà quest ultima ad ospitare il reale protocollo di livello superiore trasportato 7). Quando l host di destinazione riceve il datagram IP, esso si accorge del valore 51 presente nel campo protocollo ed elabora il datagram usando il protocollo AH. I router intermedi elaborano i datagram come hanno sempre fatto: esaminano l indirizzo IP di destinazione e instradano i datagram in funzione di questo indirizzo. 7 Ricordiamo che il campo protocollo nel datagram IP è usato per determinare il protocollo dello strato superiore, per esempio UDP, TCP, o ICMP, a cui dovrà essere passata la porzione di dati di un datagram IP

40 Pagina 40 di AH (Modalità Tunnel) La modalità Tunnel invece, prevede la creazione, da parte del mittente, di un pacchetto IP ausiliario utilizzato per ospitare l originario datagram IP. Quest ultimo viene messo in sicurezza mediante incapsulamento in un pacchetto AH. Come è possibile osservare dalla figura, grazie a questa modalità, l originario pacchetto IP viene interamente protetto (Header + Dati), mentre nella modalità Trasporto poteva esserlo solo in parte (l header IP restava fuori dalla protezione di AH). L intestazione di un pacchetto AH comprende i seguenti campi: Vediamone in dettaglio il significato: Campo intestazione successiva (next header): come abbiamo già accennato, se stiamo utilizzando la modalità trasporto, vi vengono copiati i dati contenuti del campo next protocol del datagram IP originale, indicando se il datagram sta trasportando segmenti TCP, UDP oppure ICMP. Se viene invece utilizzata la modalità Tunnel, esso

41 Pagina 41 di 85 contiene l intestazione del datagram IP originario. Comunque sia tutti i possibili valori da esso accettati sono specificati nella RFC Payload Length: campo da 8 bit che specifica la lunghezza di AH in parole da 32 bit. Reserved: campo da 16 bit riservato ad usi futuri; deve essere posto a ZERO. Indice dei parametri di sicurezza (SPI, Security Parameter Index): un valore arbitrario di 32 bit che, in combinazione con l indirizzo IP di destinazione e con il protocollo di sicurezza, identifica in modo univoco l SA per il datagram. In questo modo il mittente comunica al destinatario quale gruppo di protocolli di sicurezza sta utilizzando nella comunicazione in atto. I valori da 0 a 255 sono riservati. Questo campo non è altro che un identificatore usato per distinguere diverse SA che hanno stesso indirizzo IP di destinazione e stesso protocollo (cioè AH). Numero di sequenza (sequenze number): campo a 32 bit contenente un numero di sequenza per ciascun datagram. Inizialmente, quando si stabilisce una SA, è posto a 0. E sempre presente anche se il ricevente non ha abilitato il controllo dei duplicati. Quando vengono usate tutte le 232 possibili combinazioni la SA deve essere abbattuta e deve esserne creata una nuova. E un contatore che aumenta ogni qual volta un pacchetto è mandato allo stesso indirizzo utilizzando lo stesso SPI. Esso indica quale pacchetto è in viaggio e quanti pacchetti sono stati già spediti con lo stesso gruppo di parametri. Il sequence number fornisce protezione contro quei tipi di attacchi in cui un terzo si inserisce nella comunicazione, copia i pacchetti per poi rispedirli in futuro ottenendo conseguenze indesiderabili (interruzioni di servizi). Questo tipo di attacchi viene detto di replica o di replay. Dati di autenticazione (authentication data):

42 Pagina 42 di 85 campo di lunghezza variabile contenente un digest del messaggio firmato (cioè, una firma digitale) per questo datagram. Il digest che viene anche chiamato ICV (Integrity Check Value) è calcolato sul datagram IP originale, e fornisce così l autenticazione dell host e l integrità del datagram IP. La firma digitale è calcolata usando l algoritmo di autenticazione specificato dalla SA, tipo il DES, l MD5 o l SHA. E' prevista la presenza di un padding per raggiungere una lunghezza multipla di 32 bit (Ipv4) o di 64 bit (IPv6). AH garantisce l'autenticazione per tutto il pacchetto IP, tranne quei campi che non sono predicibili (ad esempio contatori relativi al numero di hop fatti da pacchetto) Invio dei Pacchetti e Authentication Algorithm L'algoritmo di autenticazione utilizzato per il calcolo di ICV è specificato attraverso la SA e viene applicato su: - Tutti i campi dell'header IP che sono immutabili o prevedibili nel punto di arrivo della Security Association. - L'header AH (Next Header, Payload Len, Reserved, SPI, Sequence Number, Authentication Data (posto a ZERO per questo calcolo), bytes di padding se presenti). - Pacchetto di livello superiore assunto immutabile nel transito. I campi mutabili per il calcolo di ICV vengono posti a zero per preservare l'allineamento del pacchetto; in questo modo anche se non coperti dall'icv la lunghezza di questi campi è comunque sotto controllo. I campi dell'header IPv4 sono classificati nel seguente modo: Immutabili Version Internet Header Length Total Length Identification Protocol Source Address Destination Address (senza source routing)

43 Pagina 43 di 85 Mutabili ma predicibili Destination Address (con source routing) Mutabili Type of Service Flag Fragment Offset Time to Live Header Checksum Se richiesta, la frammentazione di un pacchetto IP avviene dopo l'applicazione dell'header AH. In modalità trasporto AH è applicato solo all'intero pacchetto; durante il percorso il pacchetto potrebbe essere frammentato da qualche router; il destinatario deve ricostruire il pacchetto per poi gestire il protocollo AH. Nella modalità tunnel l'header AH è applicato a pacchetti IP, ma il payload può anche essere un frammento Ricezione dei Pacchetti In fase di ricezione di un pacchetto protetto con IPsec si deve procedere all'esame di ogni IPsec header indipendentemente da quelli applicati successivamente, per garantire una gestione indipendente di ogni protocollo applicato. All'arrivo di un pacchetto viene cercata la corrispondente SA con le indicazioni relative alla gestione del pacchetto stesso (chiavi, algoritmi,...); se non viene trovata il pacchetto viene scartato. La prima operazione che viene fatta dopo la verifica della SA corretta è il controllo (se abilitato) del numero di sequenza del pacchetto per velocizzare l'eventuale scarto del pacchetto. Il controllo dei duplicati viene effettuato attraverso l'uso di una finestra scorrevole di dimensione minima pari a 32 bit, anche se per default viene utilizzata una finestra di 64. Il margine destro della finestra rappresenta il numero di sequenza più alto ricevuto dalla SA; pacchetti con numero di sequenza minore del limite sinistro vengono scartati; i pacchetti all'interno della finestra vengono confrontati con i pacchetti già ricevuti per verificare la presenza di duplicati. Se un pacchetto cade dentro la finestra (oppure fuori ma a destra), ne viene prima verificato l'icv

44 Pagina 44 di 85 dopo di che si provvede ad aggiornare la finestra. Ulteriori dettagli sul protocollo AH si possono trovare nella RFC ESP (Encapsulating Security Payload) RFC Introduzione Il protocollo ESP fornisce la segretezza a livello dello strato della rete, ma può fornire anche autenticazione dell host così come AH. I servizi offerti da ESP sono mutuamente esclusivi e oltre a quelli già citati vi può essere anche il controllo dei duplicati (opzionale), il quale, se presente, deve essere accompagnato dall autenticazione della sorgente. Nel caso di modalità trasporto, così come avveniva per AH, è necessario indicare il valore 50 nel campo next header del datagram IP originario, per indicare che il datagram contiene un pacchetto ESP. Quando l host di destinazione, ricevuto il datagram IP, vede il valore 50, elabora il datagram usando tale protocollo. I dati del datagram IP originale insieme al campo trailer ESP sono cifrati. La segretezza è fornita con la cifratura DES-CBC (RFC 2405) Formato del pacchetto ESP L Header ESP consiste di un campo a 32 bit per l SPI e di un altro a 32 bit per il numero di sequenza ed hanno lo stesso ruolo dei corrispondenti campi di AH.

45 Pagina 45 di 85 Anche altri campi sono analoghi a quelli del fratello minore AH, ESP però presenta il campo Next Header nel trailer che essendo cifrato insieme ai dati originali impedisce ad un eventuale intruso di determinarne il protocollo di trasporto usato. Vediamo comunque i campi da esso utilizzati: Security Parameters Index (SPI): analogo a quello presente in AH Sequence Number: analogo a quello presente in AH Payload Data: campo di lunghezza variabile ma obbligatorio. In esso viene praticamente inserita tutta la pila di informazioni (il campo payload) che veniva trasportata dal datagram IP originario; d altra parte se venisse abilitata la cifratura in modalità tunnel, è qui che verrebbe inserito l intero datagram IP completamente crittografato. Infine, se l algoritmo usato per cifrare il payload richiedesse di esplicitare particolari parametri crittografici, come per esempio un Vettore di inizializzazione (Initialization Vector IV), si potrebbe usare questo campo anche per tale scopo. In questo caso ogni algoritmo di cifratura che richiedesse qualche uso crittografico specifico dovrebbe indicare la lunghezza dei dati relativi ai parametri trasportati all interno del Payload, specificando anche a quale RFC si deve fare riferimento per ottenere le informazioni necessarie al loro utilizzo. Padding (cifratura): diverse ragioni richiedono l'utilizzo di questo campo: o Se un algoritmo di cifratura richiede che il testo in chiaro sia un multiplo di un certo numero di bytes, questo campo è usato per allineare la lunghezza di tale testo (ovvero Payload Data, Pad Lenght, Next Header, così come Padding ), con quella richiesta dall algoritmo. o Indipendentemente dall uso di un eventuale algoritmo di cifratura, potrebbe essere richiesto per assicurare che il testo in chiaro finale sia confinato ad occupare multipli di 4 byte. Specificatamente i campi pad length e next header devono essere allineati a destra entro una parola di 4 byte. Tutto ciò assicura che il campo Authentication data se presente, sia costretto ad occupare al massimo 4 byte per volta.

46 Pagina 46 di 85 o Il padding, oltre che essere richiesto per ragioni di allineamento, può essere anche usato per celare la lunghezza del payload e realizzare così un parziale servizio di confidenzialità. Si noti però che l utilizzo del padding per tali scopi ha delle notevoli ripercussioni sulle prestazioni della connessione e si consiglia di utilizzarlo con cautela. Il campo padding è opzionale anche se tutte le implementazioni dovrebbero supportarlo. Pad Length: campo che indica il numero di bytes che costituiscono il campo Padding. L intervallo valido va da 0 a 255. Il campo è obbligatorio e quando viene utilizzato il valore 0 significa che non è presente padding. Next Header: campo obbligatorio di 1 byte che indica il tipo di dati contenuti nel campo Payload data, per esempio un header Ipv4 (nel caso di tunneling) oppure TCP, UDP ecc. (nel caso di transport). Il valore di questo campo è scelto tra i valori di protocollo elencati nella lista assigned numbers reperibile all IANA (Internet Assigned Numbers Authority - RFC 1700). Authentication Data: campo di lunghezza variabile contenente l'icv (Integrity Check Value) calcolato sul pacchetto (meno il campo Authentication Data stesso). La lunghezza di questo campo è specificata dalla funzione scelta per il calcolo dell'icv. Questo campo è opzionale ed è presente solo se è abilitato il controllo di autenticazione. In questo caso l algoritmo di autenticazione deve specificare la lunghezza dell ICV e le modalità con cui verrà calcolato ESP (Modalità Trasporto) ESP può essere usato in due modalità: tunnel e trasporto. Quest'ultimo si applica solo per comunicazioni host-to-host e vengono protetti solo i dati relativi ai protocolli superiori, non l'header IP del pacchetto stesso. In modalità di trasporto, ESP è inserito dopo l'header IP e prima dei protocolli di livello superiore (TCP, UDP, ICMP,...) e di qualsiasi altro header IPsec precedentemente inserito. La modalità tunnel può essere usata sia sugli host che nei security gateways; nel caso di gateway che implementa IPsec

47 Pagina 47 di 85 l'uso del tunneling è obbligatorio. Con l'uso del tunneling l'intero pacchetto interno è protetto da ESP (compreso l'header); si noti inoltre che gli indirizzi nel pacchetto interno possono ovviamente essere diversi dagli indirizzi del pacchetto "contenitore". Vediamo in dettaglio le caratteristiche della modalità trasporto. Come mostra la seguente figura, un datagram sicuro è creato circondando il campo dati del datagram IP originale con l intestazione e il trailer del pacchetto ESP, e quindi reinserendo il tutto sotto l header del datagram IP originale. Si ricorda che il campo Trailer comprende (Padding, Pad Length, Next Header) ESP (Modalità Tunnel) Nella modalità Tunnel invece, il datagram sicuro è creato circondando l intero datagram IP originale con i campi intestazioni e trailer del pacchetto ESP, e quindi inserendo il tutto, questa volta, in un nuovo pacchetto IP. Così come mostrato dalla seguente figura Invio dei Pacchetti ESP ha la possibilità sia di criptare una parte del pacchetto IP che di autenticare la sorgente; entrambe le funzionalità sono opzionali ma almeno una deve essere selezionata. Ovviamente quando il mittente ha un pacchetto da spedire applica l'esp solo dopo aver controllato che la SA associata al pacchetto necessita dell'uso di questo protocollo. Di seguito sono illustrati i passi che devono essere fatti per l'applicazione di ESP:

48 Pagina 48 di Incapsulamento (nel campo Payload di ESP): o modalità trasporto -- informazioni relative a protocolli superiori o modalità tunnel -- intero pacchetto IP originale 2. Aggiunta di eventuali bit di padding 3. Cifratura del risultato (Payload Data, Padding, Pad Length, e Next Header) usando chiave e algoritmo indicati nella SA. Se oltre alla cifratura è presente la funzione di autenticazione della sorgente, quest'ultima va applicata per seconda; la cifratura quindi non comprende l'icv nell'authentication Data. Quest ordine di applicazione permette di autenticare il pacchetto prima di perdere tempo decriptandolo; c'è anche la possibilità di far procedere le due operazioni in parallelo. Se il servizio di autenticazione è attivo il mittente calcola l'icv sul pacchetto ESP, meno il campo Authentication Data. Sono compresi quindi nel calcolo i campi: SPI, Sequence Number, Payload Data, Padding (se presente), Pad Length e Next Header. Si noti che gli ultimi 4 campi sono già stati criptati Frammentazione In modalità trasporto la frammentazione deve essere utilizzata solo dopo aver applicato ESP con l accortezza di riassemblare il pacchetto originale prima che il ricevente possa decodificare i dati. In modalità tunnel, ESP contiene un intero pacchetto IP ed il payload può anche essere un frammento. Si pensi alla situazione in cui ad un security gateway viene chiesto di far passare dei frammenti IP attraverso una linea "poco sicura"; questo gateway può applicare ESP in modalità tunnel ad ogni frammento, in modo da proteggerne il contenuto (si rimanda all appendice B per un ulteriore approfondimento) Ricezione dei Pacchetti Se il ricevente ha abilitato il controllo sui duplicati attraverso l'uso del campo Sequence Number dell'header ESP, deve avere una "sliding receive window" le cui caratteristiche dipendono dall'implementazione. La finestra funziona come nel caso precedente (AH). Quando arriva un pacchetto codificato si eseguono i seguenti passi: 1. Decodifica dei campi Payload Data, Padding, Pad Length, e Next Header usando le informazioni indicate attraverso la SA (chiave, algoritmi,...); 2. Gestione del Padding come specificato nell'algoritmo di decodifica;

49 Pagina 49 di Ricostruzione del pacchetto IP originale da: o modalità di trasporto -- header IP originale più il campo Payload; o modalità tunnel -- pacchetto IP contenuto nel campo Payload. Si noti che la decodifica di un pacchetto può fallire per diverse ragioni: La SA selezionata non è corretta ; Errore nella lunghezza o nel valore del campo Padding; Il pacchetto in esame è corrotto (questo è scoperto se è abilitata l'autenticazione). Confronto tra AH e ESP - Utilizzo di HMAC Quando l host di destinazione riceve un datagram IP con un intestazione AH oppure ESP, determina l SA per il datagram e autentica l integrità del datagram attraverso l elaborazione del campo dati di autenticazione. Lo schema di autenticazione IPSec (per entrambi i protocolli AH e ESP) usa un modello detto HMAC, che è un digest del messaggio cifrato descritto nella RFC Per l autenticazione dei messaggi, HMAC usa una chiave segreta condivisa fra due parti invece del metodo a chiave pubblica. Di seguito verranno proposti tre schemi secondo cui è possibile cogliere le principali differenze funzionali tra il protocollo AH e ESP: Le due seguenti slides descrivono rispettivamente la morfologia dei pacchetti nelle due modalità trasporto e tunnel, sia per quanto riguarda il protocollo AH, che per quanto riguarda il protocollo ESP.

50 Pagina 50 di 85 - Confronto tra AH in modalità trasporto e AH in modalità Tunnel - -Confronto tra ESP in modalità trasporto e ESP in modalità Tunnel

51 Pagina 51 di 85

52 Pagina 52 di ISAKMP e IKE 4.1 Uno sguardo generale Come recita la RFC 2408, L ISAKMP definisce le procedure ed il formato dei pacchetti per stabilire, negoziare, modificare ed eliminare le Security Associations. ISAKMP definisce due fasi perché possa avvenire lo scambio delle richieste sulle SA. In una prima fase due entità (i servers ISAKMP-IKE) si accordano sul metodo di protezione del traffico successivo che intercorrerà tra di esse (SA-ISAKMP). Nella seconda fase, vengono stabilite le SA per gli altri protocolli (SA-IPSec). Sia nella prima che nella seconda fase, l iniziatore (il server che da inizio alla negoziazione) fa una Proposal (proposta). Una Proposal è una lista, in ordine decrescente di preferenza, di suites di protezione ritenute dal sistema adeguate per una data situazione. Un server, ad esempio, può avere bisogno di utilizzare crittografia forte su una determinata comunicazione, perciò la sua Proposal potrebbe richiedere l uso di particolari algoritmi crittografici prima di altri. Ogni proposta può essere associata a più Transform le quali specificano le caratteristiche, ed eventualmente una serie di attributi, da associare alla proposta. Ad esempio, la proposta di utilizzare AH per il controllo di integrità può essere seguita dalla Transform che richiede l utilizzo di MD5 e da una seconda Transform che preveda l utilizzo di SHA1. Rispondendo al Proposal, un server indica quale sia la suite crittografica che predilige. Una volta accordatisi su questi aspetti, i servers si scambiano i pacchetti crittografici necessari per cifrare le loro comunicazioni e le informazioni che permetteranno l autenticazione tra i due. 4.2 IKE e lo scambia delle SA Nel prosieguo di questo paragrafo utilizzeremo come esempio standard la seguente configurazione:

53 Pagina 53 di 85 H1 e H2, collegati rispettivamente alla LAN 1 e alla LAN 2, devono potersi scambiare dati. SG1 e SG2 realizzano il tunnel IPSec ed eseguono tutte le operazioni necessarie per fornire i servizi richiesti per il traffico. Inoltre, supponiamo che sia H1 a dare inizio alla comunicazione. Una volta che il messaggio di H1 raggiunge SG1, la prima cosa che SG1 dovrà fare, se non esistono ancora SA-IPSEC da utilizzare per il traffico da H1 a H2, è accordarsi con SG2 sulle SA-IPSEC da utilizzare durante la comunicazione. Prima di negoziare le SA-IPSEC, SG1 e SG2 devono potersi autenticare e devono stabilire un insieme di regole sia per crittografare il traffico tra di loro sia per il processo di autenticazione (ovvero devono stabilire una SA-ISAKMP). Questa è la fase uno dello scambio così come definita nell RFC 2408 (ISAKMP). IKE definisce due metodi per portare a termine la fase uno: il Main Mode e l Aggressive Mode. Solo il Main Mode deve essere obbligatoriamente implementato in ogni realizzazione di IKE. Comunque è decisamente consigliabile implementare anche l Aggressive Mode poiché permette di portare a termine le operazioni di autenticazione e cifratura con un minor numero di messaggi e, conseguentemente, con un minore appesantimento del carico della rete. Il Main Mode prevede lo scambio di sei messaggi tra SG1 e SG2: i primi due messaggi servono per negoziare le politiche di sicurezza per i messaggi successivi (le SA per lo scambio IKE): in pratica, SG1 invierà una o più proposte di suite crittografiche a SG2 e SG2 risponderà indicando quale di queste preferisca (SG2 potrebbe comunque non accettare la proposta di SG1); Il terzo e il quarto messaggio servono per scambiare i valori pubblici per le chiavi Diffie-Hellman (DH, d ora in poi) e gli eventuali dati collegati (ad esempio il nonce); il quinto ed il sesto messaggio servono per autenticare lo scambio DH. L Aggressive Mode utilizza soltanto tre messaggi tra SG1 e SG2. In pratica col primo messaggio SG1 spedisce sia le sue proposte per la politica (SA per IKE) sia i valori pubblici per lo scambio delle chiavi DH sia, infine, i dati ulteriormente necessari per effettuare gli scambi successivi. Con il secondo messaggio, SG2 comunica a SG1 la politica di sicurezza scelta, comprensiva dei valori pubblici per lo scambio DH. Inoltre, con il secondo messaggio, SG1 è capace di autenticare SG2. Il terzo ed ultimo messaggio serve per autenticare SG1 e per dare una prova di partecipazione allo scambio. Sia con l Aggressive Mode che con il Main Mode, sono possibili quattro diversi metodi di autenticazione tra i servers: - autenticazione tramite firma; - autenticazione con crittografia a chiave pubblica; - autenticazione con crittografia asimmetrica e chiave di sessione;

54 Pagina 54 di 85 - autenticazione con pre-shared keys. Tutti questi metodi hanno come risultato la creazione di un gruppo di materiale crittografico (chiavi, fondamentalmente) per la comunicazione e la autenticazione dei due poli della comunicazione Fase 1 dello scambio tra i servers ISAKMP/IKE Vediamo ora nel dettaglio lo scambio che intercorre tra SG1 e SG2 nel momento in cui SG1 voglia stabilire nuove SA. Main Mode SG1 invierà a SG2 un messaggio che, schematicamente, possiamo riassumere così: Header del Messaggio ISAKMP. - Initiator Cookie; - Flag vari per richieste del tipo di servizio. Proposal 1. - Crittografia: DES; - Algoritmo di hash: SHA; - Autenticazione: Chiavi Pubbliche RSA; - Gruppo Diffie-Hellman: 1 Proposal 2. - Crittografia: DES; - Algoritmo di hash: MD5; - Autenticazione: Chiavi pre-distribuite; - Gruppo Diffie-Hellman: 1 Una volta ricevuto questo messaggio, SG2 sceglierà la proposta che meglio si avvicina alle sue politiche di sicurezza e alle sue capacità di calcolo ed invierà a SG1 un messaggio con le sue scelte. Tale messaggio ha la stessa forma del precedente salvo il fatto che vi sarà una sola proposta. Ciò che invece varierà sarà l header nel quale verrà inserito il Responder Cookie di SG2. Il secondo scambio di messaggi varia a seconda del tipo di autenticazione che viene utilizzato. Per meglio trattare l argomento, utilizzeremo, come esempio, l autenticazione tramite chiavi predistribuite. Un sistema del genere deve prevedere l esistenza di un sistema di distribuzione delle chiavi off-line.

55 Pagina 55 di 85 SG1 spedisce un messaggio contenente i valori per lo scambio delle chiavi Diffie - Hellman e un Nonce (ovvero un numero usa e getta che non si deve ripetere) che verrà utilizzato più avanti per l autenticazione dello scambio (controllo di integrità): Header del Messaggio ISAKMP. - Initiator Cookie; - Responder Cookie; - ID del messaggio; - Flag vari per richieste del tipo di servizio. Valori per lo scambio DH. - g^x Nonce di SG ecc.. SG2 risponderà con un messaggio del tutto simile. L unica differenza sarà il nonce. Scambiati i valori per creare le chiavi Diffie - Hellman, il resto della comunicazione, tra SG1 e SG2, verrà criptata. L ultimo scambio di messaggi tra SG1 e SG2, prima del completamento della fase 1, prevede l autenticazione dei due servers. Il messaggio che spedirà SG1 dovrà quindi portare con se: 1. materiale per l identificazione; 2. il materiale per l autenticazione dei messaggi e di SG1 stesso. E necessario aprire una parentesi relativamente al punto due. E necessario capire cosa permetta a SG1 e SG2 di autenticare sia la comunicazione (ovvero dimostrare che non ci sono state intrusioni di messaggi da terze parti) sia le rispettive controparti (ovvero dimostrare che SG1 è effettivamente SG1 e SG2 è effettivamente SG2). Per fare questo, la RFC 2409 richiede una funzione pseudo-random da applicare al corpo dei messaggi scambiati. Una tale funzione, prende in input i bits del messaggio e restituisce in output un insieme di bits a partire dai quali è impossibile ricostruire il messaggio che ha originato un tale output. Questa funzione che indicheremo con prf o è negoziata nei primi messaggi o è, di default, la KeyedHahsing for Message Authentication (HMAC, definita nella RFC 2104). HMAC prende in input sia una serie di bits che una chiave, in questo modo il suo output è legato sia alla chiave che al testo del messaggio.

56 Pagina 56 di 85 Torniamo allo scambio tra SG1 e SG2. SG1 spedirà un messaggio con la seguente forma (la parte con il bordo più grosso è cifrata con la chiave DH appena generata) a SG2: SG2, a sua volta, risponderà con un messaggio del tutto simile. Anch esso, infatti, conterrà sia il materiale necessario per l autenticazione che l output della prf applicata al corpo dei messaggi scambia con SG1 e alla chiave pre-distribuita. A questo punto SG1 e SG2 si sono autenticati e condividono una chiave con cui cifrare la loro sessione di lavoro. Possono quindi passare allo scambio delle SA-IPSec ovvero alla fase 2. Aggressive Mode A differenza del Main Mode, nell Aggressive Mode, il numero di messaggi scambiati è bassissimo. Perciò in ogni messaggio vi sono molte informazioni. Questo a discapito della segretezza delle stesse. Infatti tutta la fase 1 è affrontata in chiaro e solo la fase 2 sarà cifrata. SG1, in Aggressive Mode, invierà a SG2, in un unico messaggio, la proposta per la determinazione di un canale sicuro, il payload con il materiale per lo scambio delle chiavi DH, il nonce e, infine, il payload per l identificazione; il tutto completamente in chiaro:

57 Pagina 57 di 85 SG2, a sua volta, risponderà con la SA da lui scelta tra quelle proposte da SG1, il materiale per completare lo scambio delle chiavi DH, il suo nonce, il materiale per l identificazione e il risultato della funzione prf applicata al corpo del messaggio stesso e alla chiave pre-distribuita: In ultimo, SG1 risponderà con il materiale per l autenticazione della comunicazione, concludendo così la fase 1.

58 Pagina 58 di 85 Le differenze tra lo scambio di messaggi con il metodo di autenticazione tramite firma digitale e quello con altri metodi di autenticazione risiede nel tipo di informazione che sarà necessario spedire ogni volta. Per una trattazione completa degli scambi si rinvia alla appendice A.