VPN sicure con IPSEC

Transcript

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 2001-2002
Pagina 2 di 85
“VPN sicure con Ipsec” – David Frassi e Luca Saba – 2002
“……….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)
Pagina 3 di 85
Pagina 4 di 85
Indice
INTRODUZIONE..............................................................................................................................................................6
1. LA SICUREZZA DELLE RETI INFORMATICHE..................................................................................................8
1.2 DEFINIZIONE...................................................................................................................................................................8
1.2 UN APPROCCIO SISTEMATICO.............................................................................................................................................9
1.2.1 Attacchi................................................................................................................................................................9
1.2.2 Servizi................................................................................................................................................................10
1.2.3 Modelli per la Sicurezza....................................................................................................................................11
1.3 CONCLUSIONI...............................................................................................................................................................14
2. COS’È UNA VPN E PERCHÉ UTILIZZARLA?.....................................................................................................16
2.1 INTRODUZIONE..............................................................................................................................................................16
2.2 IL PERCHÉ DI UNA VPN.................................................................................................................................................18
2.3 UN PICCOLO ESEMPIO.....................................................................................................................................................20
2.3.1 Accordo tra i gateways......................................................................................................................................21
2.3.2 Invio del messaggio...........................................................................................................................................23
3. IPSEC: LA SOLUZIONE STANDARD ALLA SICUREZZA IP...........................................................................26
3.1 INTRODUZIONE..............................................................................................................................................................26
3.2SECURITY ASSOCIATION (RFC 2401)..............................................................................................................................27
3.2.1 SA in transport mode.........................................................................................................................................28
3.2.2 SA in tunnel mode..............................................................................................................................................29
3.2.3 Funzionalità di una SA......................................................................................................................................29
3.2.4 Combinazione di più SA....................................................................................................................................30
3.3 DATABASES.................................................................................................................................................................32
3.3.1 SPD: Security Policy Database.........................................................................................................................33
3.3.2 Selectors............................................................................................................................................................33
3.3.3 SAD: Security Association Database................................................................................................................35
3.3.3 Localizzazione di un Security Gateway.............................................................................................................37
3.4 AH (AUTHENTICATION HEADER) RFC 2402 .................................................................................................................39
3.4.1 Introduzione
.............................................................................................................................................39
3.4.2 AH (Modalità Trasporto)..................................................................................................................................39
3.4.3 AH (Modalità Tunnel) .....................................................................................................................................40
3.4.4 Invio dei Pacchetti e Authentication Algorithm................................................................................................42
3.4.5 Ricezione dei Pacchetti ....................................................................................................................................43
3.6 ESP (ENCAPSULATING SECURITY PAYLOAD) RFC 2406.................................................................................................44
3.6.1 Introduzione.....................................................................................................................................................44
3.6.2 Formato del pacchetto ESP..............................................................................................................................44
3.6.3 ESP (Modalità Trasporto) ...............................................................................................................................46
3.6.4 ESP (Modalità Tunnel)......................................................................................................................................47
3.6.5 Invio dei Pacchetti............................................................................................................................................47
3.6.6 Frammentazione................................................................................................................................................48
3.6.7 Ricezione dei Pacchetti....................................................................................................................................48
3.6.8Confronto tra AH e ESP - Utilizzo di HMAC.....................................................................................................49
-CONFRONTO TRA ESP IN MODALITÀ TRASPORTO E ESP IN MODALITÀ TUNNEL –...........................50
4. ISAKMP E IKE...........................................................................................................................................................52
4.1 UNO SGUARDO GENERALE...............................................................................................................................................52
4.2 IKE E LO SCAMBIA DELLE SA........................................................................................................................................52
4.2.1 Fase 1 dello scambio tra i servers ISAKMP/IKE..............................................................................................54
5. STUDIO DI UN CASO REALE..................................................................................................................................59
5.1 DESCRIZIONE................................................................................................................................................................59
5.2 REALIZZAZIONE DELLA SOLUZIONE...................................................................................................................................61
5.2.1 Servizi ISAKMP e IKE.......................................................................................................................................62
5.2.2 Configurazione delle access lists......................................................................................................................63
5.2.3 Configurazione delle interfacce........................................................................................................................63
Pagina 5 di 85
5.2.4 Mappatura del traffico......................................................................................................................................64
5.2.4 In pratica...........................................................................................................................................................65
5.3 LISTATO DELLE CONFIGURAZIONI IPSEC. ..........................................................................................................................65
5.3.1 Firenze...............................................................................................................................................................66
5.3.2 Roma..................................................................................................................................................................67
5.3.3 Montecatini........................................................................................................................................................68
6.SVANTAGGI DI IPSEC...............................................................................................................................................70
6.1PRESTAZIONI DI IPSEC .....................................................................................................................................................70
6.2 COMPATIBILITÀ TRA IMPLEMENTAZIONI ............................................................................................................................70
6.3 VULNERABILITÀ DI IPSEC................................................................................................................................................71
6.3.1 Sensibilità ai Denial of Service:........................................................................................................................71
6.3.2 Sensibilità all’attacco con uomo in mezzo........................................................................................................71
CONCLUSIONI................................................................................................................................................................74
APPENDICE A - ISAKMP E IKE: SCAMBIO DI MESSAGGI...............................................................................76
A.1 IKE – FASE 1............................................................................................................................................................76
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 2............................................................................................................................................................79
A.3 ISAKMP INFORMATIONAL EXCHANGE..........................................................................................................................80
APPENDICE B – FRAMMENTAZIONE E PATH MTU..........................................................................................82
BIBLIOGRAFIA..............................................................................................................................................................84
RINGRAZIAMENTI.......................................................................................................................................................85
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
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.
Pagina 8 di 85
1. 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” – 6.6.2001):
“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
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
1.2.1 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”.
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
www.cert.org), 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.
1.2.2 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.
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.
1.2.3 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
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:
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
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”)
Pagina 15 di 85
Pagina 16 di 85
2. 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.
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).
Pagina 18 di 85
2.2 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.
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:
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 192.168.11.0/24, perciò percorrerà tutta la LAN1 sino a raggiungere il gateway SG1.
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
192.168.10.0/24
192.168.10.0/24
Indirizzo Destinazione
192.168.11.0/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.
2.3.1 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
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.
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 H2.
2.3.2 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.
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.
Pagina 25 di 85
Pagina 26 di 85
3. 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 e-mail, 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
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 2409.
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-
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.
3.2.1 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.
Pagina 29 di 85
3.2.2 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 -
3.2.3 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.
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).
3.2.4 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.
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.
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
Pagina 32 di 85
loro, uno per autenticare i due host e l’altro per l’invio dei dati cifrati all’host finale.
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 IP3.
3.3 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
Pagina 33 di 85
3.3.1 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).
3.3.2 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.
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
[email protected],
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 2401.
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
Pagina 35 di 85
3.3.3 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.
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
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 -
3.3.3 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 è
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.
Pagina 39 di 85
3.4 AH (Authentication Header) RFC 2402
3.4.1 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.
3.4.2 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
Pagina 40 di 85
3.4.3 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
Pagina 41 di 85
contiene l’intestazione del datagram IP originario. Comunque sia tutti i possibili valori da esso
accettati sono specificati nella RFC 1700.
•
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):
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).
3.4.4 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)
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.
3.4.5 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
Pagina 44 di 85
dopo di che si provvede ad aggiornare la finestra. Ulteriori dettagli sul protocollo AH si possono trovare nella
RFC 2402.
3.6 ESP (Encapsulating Security Payload) RFC 2406
3.6.1 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).
3.6.2 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.
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.
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.
3.6.3 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
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).
3.6.4 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.
3.6.5 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:
Pagina 48 di 85
1. 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.
3.6.6 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).
3.6.7 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;
Pagina 49 di 85
3. 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:
3.6.8
•
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 2104. 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.
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 –
Pagina 51 di 85
Pagina 52 di 85
4. 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:
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;
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.
4.2.1 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”.
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 SG1.
- 0010100010101010010101010010101010101010101 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.
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:
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.
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.
Pagina 59 di 85
5. Studio di un caso reale
5.1 Descrizione
Dopo lo studio svolto sulla teoria alla base dei protocolli della suite IPSec, cercheremo di applicare le
nozioni fin qui apprese ad un caso reale. L’azienda con la quale abbiamo a che fare ha tre sedi: una a
Firenze, una a Roma ed una a Montecatini. Nella pratica, lo scambio di dati tra le due reti avviene attraverso
un tunnel Generic Routing Encapsulation (GRE – RFC 2784), il quale a sua volta viene inserito in un tunnel
IPSec. Questa scelta nasce dall’esigenza di poter configurare in modo semplice e chiaro tutti i routers
coinvolti nello scambio. Infatti, l’utilizzo del tunnel GRE, rende il SPD più scalabile ed elastico poichè,
basandosi sul tunnel GRE e non sulla reale topologia della rete, non risente della creazione o modifica degli
indirizzi IP. Nella figura seguente, le frecce evidenziano le direzioni dei tunnels GRE.
Pagina 60 di 85
EMBED Visio.Drawing.6
Firenze
Interfaccia Seriale:
20.14.131.76
20.11.32.74
INTERNET
Interfaccia Logica:
10.0.0.1
PW R
10M100M 1 2 3 4 5 6 7 8 9 10 111 2
AC TAC T
CO LCO L
SWITCH
13 141 5161 7181920 2122 232 4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Roma
Interfaccia Logica:
10.0.0.4
U PLINK
PWR
10M1 00M 1 2 3 4 5 6 7 8 9 10 1112
A CT AC T
C OLC OL
SWITC H
13141516171819 202 122 2324
Indirizzi Privati:
192.168.1.0/24
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
UPLIN K
Indirizzi Privati:
192.168.3.0/24
Interfaccia Logica:
10.0.0.2
Interfaccia Logica:
10.0.0.3
20.52.151.82
Montecatini
PWR
10 M10 0M
ACT ACT
1 2 3 4 5 6 7 8 9 101 112
CO LCO L
S WITC H
131 4151 6171 81 9202 1222 324
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
U PLINK
Indirizzi Privati:
192.168.2.0/24
Quando Firenze deve dialogare con Roma, invia i dati sul tunnel GRE verso Montecatini il quale
provvederà ad inoltrarli verso Roma. Se da una parte questa soluzione potrebbe allungare i tempi di
consegna dei dati, dall’altra semplifica la gestione di tutta la rete diminuendo il numero di tunnel da creare.
Sarebbe possibile apprezzare maggiormente tale semplificazione se per ipotesi il numero delle sedi fosse
almeno quattro. In tal caso, per una rete completamente magliata, ci vorrebbero sei tunnels, il che vorrebbe
Pagina 61 di 85
dire configurare tre interfacce su ogni macchina di ogni città. Con la soluzione utilizzata in figura, si
aggiungerebbe un solo altro tunnel senza andare a modificare sensibilmente le configurazioni delle
macchine. Per concludere questa divagazione sul GRE, è comunque necessario notare che il payload dei
pacchetti risente dell’ulteriore utilizzo del GRE. Per questo motivo potrebbe essere necessario un ulteriore
sforzo per il calcolo della PMTU (vedi anche Appendice B)
Le richieste relative al controllo della sicurezza del traffico cadono sia sull’autenticazione che sulla
confidenzialità. Il fatto di utilizzare il tunnel GRE, semplifica questo compito. Vediamo, nelle immagini che
seguono, il perché:
Come si vede, è sufficiente utilizzare il protocollo ESP in modalità trasporto per effettuare
l’autenticazione del mittente e del destinatario effettivi della comunicazione (IP Header Originale). A questo
punto non ci rimane che vedere in pratica come venga realizzato tutto ciò.
5.2 Realizzazione della soluzione
Tutte e tre le sedi utilizzano come border gateway un router Cisco sul quale gira IOS con supporto
per IPSec. Per realizzare il tunnel GRE, sarà necessario costruire delle interfacce logiche all’interno delle quali
verrà mandato tutto il traffico che, dalla rete privata di una data sede, deve andare nella rete privata di
un’altra sede. Gli indirizzi che utilizzeremo per indicare nelle tabelle di routing le interfacce logiche sono già
stati riportati nell’immagine iniziale.
Pagina 62 di 85
5.2.1 Servizi ISAKMP e IKE
Cominciamo col vedere la configurazione del router della sede di Firenze. Innanzitutto dobbiamo
avvisare il nostro router che abbiamo intenzione di utilizzare ISAKMP per la negoziazione della crittografia.
Questo si ottiene inserendo il seguente comando, una volta entrati in modalità configurazione da terminale:
1) crypto isakmp enable
Il prossimo passo da compiere è quello di creare le politiche per lo scambio e la negoziazione delle Security
Associations.
2) crypto isakmp policy 1
3)
encryption 3des
4)
hash md5
5)
authentication pre-share
6)
group 2
7)
lifetime 86400
Nota: Il numero cardinale non è presente nella configurazione del router. E’ un espendiente di questa
relazione per poter,sucessivamente, meglio commentare il codice.
Analizziamo questi comandi. Con la riga 2) si comunica al router che quella che segue sarà una
politica per la negoziazione delle SA e lo scambio delle chiavi ISAKMP.
Successivamente sono definite le caratteristiche di questa Proposal:
•
Crittografia tramite 3DES;
•
Algoritmo di digest MD5;
•
Autenticazione con la modalità delle chiavi pre-distribuite;
•
Gruppo 2 per la generazioni delle chiavi Diffie-Hellman;
•
Durata della SA-IKE una volta stabilita 86400 secondi (un giorno).
Potremmo inserire anche altre politiche ISAKMP ma, in effetti, con un numero così limitato di routers, non
avrebbe senso. Anche l’utilizzo della modalità pre-shared per l’autenticazione discende direttamente dal fatto
che il numero di routers è limitato. In casi più complessi, l’utilizzo delle chiavi pubbliche è probabilmente più
adatto.
In conseguenza della scelta fatta per l’autenticazione sarà necessario inserire il seguente comando
nel file di configurazione:
Pagina 63 di 85
8) crypto isakmp key ****** address 20.52.151.82
(per l’autenticazione con Montecatini)
In questo modo abbiamo inserito le password che il router di Firenze dovrà utilizzare per autenticarsi con
quello di Montecatini.
5.2.2 Configurazione delle access lists
Passiamo, a questo punto, alla definizione delle access lists. Queste sono il cuore del SPD. Ecco la
prima access list necessaria per la nostra VPN IPSec:
9) access-list 100 permit gre host 20.11.32.74 host 20.52.151.82
La keyword “permit” indica al router che il traffico che corrisponde ai criteri dati, deve passare attraverso
IPSec. Nella fattispecie si specifica che tutto il traffico GRE che da Firenze va a Montecatini deve essere
passato a IPSec.
Per poter ricevere il traffico in entrata, sono necessarie alcune altre access list:
10) access-list 101 permit gre host 20.52.151.82 host 20.11.32.74
11) access-list 101 permit udp host 20.52.151.82 host 20.11.32.74 eq 500
12) access-list 101 permit esp host 20.52.151.82 host 20.11.32.74
Mentre la access list 100 avvisa il router su quale traffico in uscita debba essere trattato con IPSec, queste
access-lists speficano il traffico ammesso in ingresso. Nella fattispecie, il traffico interessante per il router
sarà:
•
Il traffico ESP: tunnel IPSec da Montecatini a Firenze;
•
Il traffico GRE: che altro non è che il traffico ESP decrittato e autenticato;
•
Il traffico UDP sulla porta 500: per la contrattazione delle SA-IPSec.
A tutto il traffico rimanente viene impedito l’accesso.
5.2.3 Configurazione delle interfacce
Dopo aver configurato le varie access lists, dobbiamo creare il nostro tunnel GRE. Per fare questo
utilizziamo i seguenti comandi:
13) interface Tunnel0
14)
ip address 10.0.0.1 255.255.255.0
15)
tunnel source 20.11.32.74
16)
tunnel destination 20.52.151.82
Pagina 64 di 85
17)
crypto map Mntc
Con queste righe abbiamo creato una sorta di nuova sottorete: la sottorete 10.0.0.1/24. Questa sottorete è
composta da i due tunnel: quello che va da Montecatini (10.0.0.2) a Firenze (10.0.0.1) e quello che va da
Montecatini (10.0.0.3) a Roma (10.0.0.4). Abbiamo inoltre richiesto che, al traffico che passa per questa
interfaccia, venga applicato il trattamento IPSec denominato Mntc (che vedremo più avanti).
Per fare in modo che tutto il traffico destinato al tunnel, venga indirizzato su questa interfaccia, dovremo
dare i seguenti ordini:
18) ip route 192.168.2.0 255.255.255.0 Tunnel0
19) ip route 192.168.3.0 255.255.255.0 Tunnel0
Questi comandi non hanno niente a che vedere con IPSec, sono però necessari per effettuare correttamente
il routing all’interno dei tunnel GRE.
5.2.4 Mappatura del traffico
A questo punto è necessario definire i tipi di politica da utilizzare per i diversi traffici, ovvero bisogna
definire la mappatura tra il traffico e le regole di sicurezza da applicare. Abbiamo detto che utilizzeremo
l’ESP, perciò:
20) crypto ipsec transform-set traffico_in_uscita esp-3des esp-sha
21)
mode transport
Questo transform-set in pratica è una Proposal per l’utilizzo di ESP in modalità trasporto con autenticazione.
E’ opportuno notare che questa modalità è molto comoda poiché, rispetto a quella tunnel, appesantisce di
meno il datagram inviato sulla rete (in questo caso specifico l’utilizzo della modalità tunnel introdurrebbe
soltanto una ridondanza di informazione). Inoltre è assolutamente sicuro poiché il tunnel GRE ha già
“inglobato” tutti i dati da proteggere quindi mittente, destinatario e contenuto effettivi della comunicazione
sono autenticati e confidenziali.
Una volta creato questo transform set, dobbiamo dire quale traffico dovrà utilizzarla:
22) crypto map Mntc 1 ipsec-isakmp
23)
set peer 20.52.151.82
24)
set transform-set traffic_in_uscita
25)
match address 100
Pagina 65 di 85
Questa avverte il router che tutto il traffico corrispondente all’access list 100 deve utilizzare le SA di tipo
traffico_in_uscita negoziate con isakmp. Inoltre specifica che l’ end-point per questo traffico IPSec sarà
20.52.151.82, ovvero Montecatini.
Con questo abbiamo terminato la fase di configurazione del router di Firenze (almeno per quel che riguarda
la parte IPSec).
5.2.4 In pratica
Vediamo in pratica come il router utilizza queste informazioni:
Traffico in uscita
Il traffico che dalla rete privata di Firenze deve andare a Montecatini o a Roma, deve passare dall’interfaccia
logica Tunnel0 (righe 18 e 19). Tutto il traffico che passa dal Tunnel0 deve essere crittografato con la crypto
map Mntc (riga 17). Se non esistono ancora delle SA-IPSec per questo traffico, è necessario contrattarle con
Montecatini (riga 23). Per fare questo si inizia la fase ISAKMP con i parametri già visti (righe da 2 a 7).
L’autenticazione avverrà con la chiave riportata in riga 8. Notare che da questo momento entreranno in
gioco anche le access list 101 per il trattamento del traffico ISAKMP via UDP.
Una volta contrattate le SA (che devono essere aderenti al transform-set traffic_in_uscita poiché è l’unico ad
essere stato definito), può avere inizio la spedizione del traffico. Il traffico deve essere immesso nel tunnel
GRE ma tutto il traffico GRE tra Firenze e Montecatini deve essere crittografato (righe da 22 a 25).
Traffico in entrata
L’unico traffico ammesso in entrata è quello GRE, UDP e ESP. Se il traffico in entrata è ESP e non esiste una
SA appropriata, il traffico viene scartato. Se invece esiste la SA, il traffico viene decrittato e autenticato.
Una volta decrittato il pacchetto svela il datagram contenuto al suo interno che deve essere ricontrollato
nella access list. Se sarà traffico GRE o UDP (righe 10 e 11) potrà passare, altrimenti verrà scartato.
5.3 Listato delle configurazioni IPSec.
Una volta descritta la configurazione del router di Firenze, è molto semplice capire come i router di
Roma e di Montecatini dovranno essere programmati. Roma sarà molto simile a Firenze (sarà sufficiente
modificare alcuni indirizzi). Montecatini avrà una “doppia” configurazione: una per Firenze e una per Roma.
Pagina 66 di 85
La configurazione Montecatini – Firenze sarà speculare a quella Firenze – Montecatini, così come la
configurazione Montecatini – Roma sarà speculare a quella Roma – Montecatini.
5.3.1 Firenze
!
! Abilita la negoziazione ISAKMP
!
crypto isakmp enable
!
! Descrizione della politica per lo scambio IKE
!
crypto isakmp policy 1
encryption 3des
hash md5
group 2
lifetime 86400
!
! Chiave pre-distribuita per l’autenticazione con Montecatini
!
crypto isakmp key ****** address 20.52.151.82
!
! Definizione delle access lists del router
!
access-list 100 permit gre host 20.11.32.74 host 20.52.151.82
access-list 101 permit udp host 20.52.151.82 host 20.11.32.74 eq 500
access-list 101 permit esp host 20.52.151.82 host 20.11.32.74
!
! Costruzione del canale GRE con Montecatini
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
crypto map Mntc
!
! Tutto il traffico privato deve andare nel tunnel GRE
!
ip route 192.168.2.0 255.255.255.0 Tunnel0
ip route 192.168.3.0 255.255.255.0 Tunnel0
!
! Definizione della politica di sicurezza delle comunicazioni tra le reti
!
crypto ipsec transform-set traffico_in_uscita esp-3des esp-sha
mode transport
!
! Mappatura del traffico sulla politica
!
crypto map Mntc 1 ipsec-isakmp
set peer 20.52.151.82
match address 100
Pagina 67 di 85
5.3.2 Roma
!
!
!
!
encryption 3des
hash md5
group 2
lifetime 86400
!
! Chiave pre-distribuita per l’autenticazione con Montecatini
!
!
!
!
! Costruzione del canale GRE con Montecatini
!
interface Tunnel0
ip address 10.0.0.4 255.255.255.0
crypto map Mntc
!
!
ip route 192.168.2.0 255.255.255.0 Tunnel0
ip route 192.168.1.0 255.255.255.0 Tunnel0
!
!
mode transport
!
!
crypto map Mntc 1 ipsec-isakmp
set peer 20.52.151.82
match address 100
Pagina 68 di 85
5.3.3 Montecatini
!
!
!
!
encryption 3des
hash md5
group 2
lifetime 86400
!
! Chiavi pre-distribuita per l’autenticazione con Firenze e Roma
!
!
!
!
! Costruzione del canale GRE con Firenze
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
crypto map Flr
!
! Costruzione del canale GRE con Roma
!
interface Tunnel1
ip address 10.0.0.3 255.255.255.0
crypto map Rm
!
!
ip route 192.168.3.0 255.255.255.0 Tunnel1
ip route 192.168.1.0 255.255.255.0 Tunnel0
!
!
mode transport
!
Pagina 69 di 85
!
crypto map Flr 1 ipsec-isakmp
set peer 20.11.32.74
match address 100
crypto map Rm 1 ipsec-isakmp
set peer 20.14.131.76
match address 101
Pagina 70 di 85
6. Svantaggi di IPSec
Alla luce di quanto visto fin’ora sarebbe quantomeno superficiale pensare che la tecnologia di Ipsec
costituisca la soluzione a tutti i problemi di sicurezza. Tant’è vero durante la pianificazione della presente
avevamo previsto un capitolo in cui elencare gli eventuali difetti insiti nella suddetta tecnologia. Speravamo
in verità di non scoprire molte “falle” e di non scrivere molto in merito. Ma, ahimè alcuni problemi esistono e
non sono affatto trascurabili. Questo non significa che la tecnologia è da “buttare”, anche perché ogni tipo di
soluzione in ambito di sicurezza presenta un “rovescio della medaglia”. Non è però consigliabile affidarsi
esclusivamente ad uno strumento ritenendolo la soluzione, conviene piuttosto combinare più strumenti, in
sinergia, alla ricerca di un livello di sicurezza ritenuto accettabile dalla politica aziendale.
6.1Prestazioni di Ipsec
Ma cominciamo ad elencare i problemi di Ipsec, iniziando con il considerarne le prestazioni. Il fatto
che Ipsec utilizzi un algoritmo di cifratura per codificare tutto il traffico tra un peer e l’altro non può che
inficiare sulle prestazioni della connessione. Ogni host o security gateway coinvolto nel tragitto (Ipsec) tra
mittente e destinatario è obbligato a consumare risorse per calcolare gli algoritmi di crittografia impiegati.
Tutto ciò viene parzialmente risolto utilizzando dei co-processori esterni dedicati al lavoro crittografico.
Tuttavia, vista la sempre più incalzante evoluzione dell’hardware e la sempre maggiore disponibilità di
larghezza di banda, non sembra essere questo il problema peggiore che affligge questa tecnologia.
6.2 Compatibilità tra implementazioni
Un altro problema da non sottovalutare è costituito dalla difficoltà di implementare lo standard
proposto dall’IETF in maniera compatibile. Purtroppo, nonostante la fonte teorica in comune (RFC 2401
ecc.), a vendors diversi corrispondono implementazioni diverse. Anche perché alcuni punti delle RFC, poiché
estremamente teorici, sono ancora troppo opinabili e soggetti a diverse interpretazioni. Tutto ciò ha come
effetto l’insoddisfazione dell’utenza finale che si trova troppo spesso nella spiacevole situazione di non veder
comunicare tra loro implementazioni diverse (es: Ipsec Microsoft e Ipsec Cisco non sono del tutto
compatibili).
Pagina 71 di 85
6.3 Vulnerabilità di Ipsec
Sebbene le suddette problematiche non siano da trascurare e anzi, siano già sufficienti per
scoraggiare un possibile utilizzo di Ipsec, i veri problemi che ne degradano l’immagine sono quelli relativi alle
vulnerabilità insite nella suite stessa.
Vediamole in dettaglio.
6.3.1 Sensibilità ai Denial of Service:
Il Denial of service è un attacco alla disponibilità delle informazioni che viene scagliato da una o più
postazioni (Distributed Denial of Service) verso un servizio di solito pubblico come può essere un sito web.
La vittima costituita da uno o più servers viene bombardato di informazioni inutili ma che comunque
rientrano nelle specifiche del traffico accettato in ingresso. In questo modo, il bersaglio, dopo aver
provveduto ad esaminare le prime n informazioni non può che inginocchiarsi di fronte al loro elevato
numero. In breve tempo, dopo aver esaurito tutta la propria capacità di calcolo, la vittima non sarà più in
grado di accettare nuove informazioni, neanche quelle veritiere. Ecco la negazione del servizio.
Oggi questo tipo di attacco è il più temuto perché difficilmente predicibile. Ipsec dal canto suo non
viene escluso dagli effetti del DOS, vediamo perché. Nella configurazione del Router, come abbiamo visto nel
capitolo 5, viene lasciata via libera al traffico UDP che trasporta ISAKMP per l’iniziazione delle SA. In questo
modo una “pioggia” di richieste ISAKMP falsificate potrebbe riempire il modulo IPSec di “spazzatura”
inducendolo al DOS.
6.3.2 Sensibilità all’attacco con uomo in mezzo
Per quanto riguarda questo tipo di attacco, abbiamo voluto inserire una slide per chiarire meglio il
concetto. Lo scopo dell’impostore, in questo caso C, è di intercettare il traffico che fluisce regolarmente tra
due peers A e B, modificarlo e reinserirlo così modificato nel normale tragitto. Per prima cosa il malfattore
“sniffa” i pacchetti che viaggiano sulla rete, per scoprirne i dettagli di indirizzamento. Dopo di che usa questi
dati per costruire dei pacchetti ad hoc da rispedire all’altro peer ignaro del tutto. I dettagli di questa tecnica
esulano dallo scopo di questo paragrafo e non verranno trattati, è comunque importante capire come un
simile attacco possa esser sferrato su di un traffico completamente cifrato come quello di Ipsec.
Pagina 72 di 85
Apparentemente, il problema non sembrerebbe riguardare la suite in oggetto, in realtà se andiamo a
rileggere il capitolo 4, possiamo notare che il primo algoritmo utilizzato nell’installazione della connessione
Ipsec è quello di Diffie Hellman. E’ proprio questo l’anello debole della catena. Questo algoritmo prevede la
generazione e lo scambio di una chiave simmetrica. I due peers utilizzano, guarda caso, proprio quest’ultima
per cifrare il primo tunnel SA, quello relativo alla contrattazione IKE. L’uomo in mezzo potrebbe intercettare
la chiave simmetrica, decodificare il primo tunnel e quindi intercettare anche la chiave di cifratura del
secondo, quello riferito ad Ipsec, da cui come sappiamo passano le informazioni sensibili. A questo punto è
facile capire come il nostro malfattore possa in un sol colpo far crollare l’intero “castello” di IPsec.
- Attacco con uomo in mezzo -
Pagina 73 di 85
Pagina 74 di 85
Conclusioni
In questa relazione abbiamo cercato di illustrare uno dei tanti strumenti proposti per garantire
maggiore sicurezza ai sistemi informativi. E’ importante sottolineare come questo non debba essere
considerato lo strumento definitivo sia perché, come abbiamo visto, presenta dei difetti, sia perché da solo,
senza l’ausilio di altri strumenti, non è in grado di coprire tutti i “buchi” della sicurezza.
E’ la “Ridondanza” quindi, la caratteristica desiderabile per un sistema sicuro, questo perché se è
vero che “Una catena è resistente quanto lo è il suo anello più debole”, è anche vero che più catene si usano
più è facile ottenerne una veramente resistente.
Pagina 75 di 85
Pagina 76 di 85
APPENDICE A - ISAKMP e IKE: scambio di messaggi
A.1 IKE – Fase 1
Fin qui abbiamo visto una enorme carrellata di contenuti di messaggi. Entriamo adesso un po’ più
nello specifico per vedere come sono organizzati gli scambi dei messaggi in ISAKMP e IKE.
Legenda:
HDR
header del messaggio ISAKMP (HDR* indica che i payloads sono cifrati);
SA
è un Security Association Payload con una o più proposte (Proposal Payload)
CKY-I
initiator cookie contenuto nell’ header ISAKMP;
CKY-R
responder cookie contenuto nell’ header ISAKMP;
KE
key exchange payload per lo scambio dei valori Diffie-Hellman;
Ni
nonce dell’ initiator;
Nr
nonce del responder;
IDii
identification payload dell’initiator;
IDir
identification payload del responder;
SIG
signature payload;
SIG_i
firma applicata alla funzione hash calcolata sul nonce dell’initiator;
SIG_r
firma applicata alla funzione hash calcolata sul nonce del responder;
CERT
certificate payload;
HASH
hash payload;
A.1.1 Autenticazione tramite firma digitale
Pagina 77 di 85
A.1.2 Autenticazione con crittografia a chiave pubblica
Indichiamo con <Nome_Campo>Pub_key_x , il fatto che il payload “Nome_Campo” viene inviato
criptato con la chiave pubblica di x:
A.1.3 Autenticazione con crittografia asimmetrica e chiave di sessione
In questo caso, per diminuire le operazioni di crittografia asimmetrica, SG1 e SG2 si calcolano una
coppia di chiavi di sessione per passare il prima possibile alla crittografia simmetrica. Nel grafico seguente, le
chiavi simmetriche sono identificata dalle sigla Ke_i e Ke_r. Per ottenere le chiavi SG1 procede nel seguente
modo: una volta generato il suo nonce (Ni), SG1 applica una funzione pseudo-randomica (che, a meno che
non sia negoziata nel SA Payload, è data dall’algoritmo HMAC (RFC 2104)), all’intero corpo del Nonce
Payload (Ni_b) e all’initiator cookie (prf(Ni, CKY-I)) per ottenere Ne_i, ovvero una sorta di versione criptata
del nonce. La chiave Ke_i viene ottenuta da Ne_i attraverso ulteriori passaggi descritti in dettaglio nella RFC
2409. Il nonce viene quindi passato cifrato con la chiave pubblica di SG2 (il nonce cifrato deve essere
inserito in un nuovo Nonce Payload). Come risultato, tutti i payloads, esclusi HDR e SA, sono crittografati.
Pagina 78 di 85
Vediamo:
A.1.4 Autenticazioni tramite sistema di chiavi pre-distribuite
Questo sistema prevede l’esistenza di un meccanismo di scambio delle chiavi “out-of-band”. In
questo caso l’utilizzo della chiave pre-distribuita permette l’autenticazione tra SG1 e SG2 dato che solo loro
sono capaci di autenticare i dati inviati. Ecco lo schema della comunicazione:
Pagina 79 di 85
A.2 IKE – Fase 2
IKE definisce un metodo per la fase 2: il Quick Mode. Anche se il New Group Mode segue la fase 1,
in realtà non viene utilizzato per lo scambio di SA per IPSec. Viene utilizzato invece per creare nuovi gruppi
di scambio (relativo alle chiavi Diffie Hellman).
Nella fase 1, SG1 e SG2 si sono autenticati e hanno stabilito una SA-IKE (che è bidirezionale) per
proteggere il traffico successivo che scorrerà tra di loro. Nella fase 2 dovranno iniziare a scambiare le
effettive SA-IPSec.
Con il Quick Mode, subito dopo l’ header ISAKMP devono essere inseriti, rigorosamente nell’ordine,
l’Hash Payload e l’ SA Payload. I campi dell’ header ISAKMP identificano la SA che viene utilizzata per questo
particolare scambio. Lo schema degli scambi durante il Quick Mode è il seguente:
Nel primo messaggio SG1 spedisce i seguenti dati:
•
il valore di hash calcolato sul Message-ID dell’ header ISAKMP concatenato con l’intero messaggio
che segue l’Hash Payload;
•
la (o le) proposta/e di SA seguita da una o più Transform;
•
un nuovo nonce;
•
(opzionale) materiale crittografico aggiuntivo per rinnovare le chiavi crittografiche DH;
•
(opzionale) materiale per l’identificazione per cui viene negoziata la SA.
Quest’ultimo punto merita una spiegazione. Le identità delle SA negoziate con il Quick Mode, sono,
implicitamente, date dagli indirizzi IP dei due servers. Quando ISAKMP sta funzionando come client per
negoziare una SA per una terza parte, le identità di tale terza parte devono essere obbligatoriamente
passate come payload (IDci – identità del vero initiator e IDcr – identità del vero responder).
Pagina 80 di 85
Il messaggio di risposta di SG2 deve contenere HASH(2), la SA prescelta tra le possibili offerte da
SG1, un nuovo nonce Nr e, opzionalmente, i payloads già visti prima relativi al materiale crittografico (KE) e
alle identità (IDci e IDcr).
Si rimanda alla RFC 2409 per le specifiche funzioni matematiche necessarie per i vari calcoli.
New Group Mode, come preannunciato serve per negoziare nuovi gruppi di scambio. Un gruppo, in
questo contesto, è dato dall’insieme delle operazioni e dei valori ammissibili per la creazione e lo scambio
delle chiavi crittografiche. La trattazione completa di questi aspetti è al di là degli obiettivi di questo scritto.
Per maggior informazione si rimanda a RFC 2412.
A.3 ISAKMP Informational Exchange
Un metodo per proteggere la confidenzialità dei messaggi di controllo di ISAKMP è definito in IKE.
Questo prevede una serie di comunicazioni del tipo:
Il corpo del messaggio è completamente crittografato. Hash(1) viene utilizzato per il controllo di integrità e
N/D indica la presenza di un Notification Payload o di un Delete Payload.
Pagina 81 di 85
Pagina 82 di 85
APPENDICE B – FRAMMENTAZIONE e PATH MTU
In quasi tutte le implementazioni del protocollo IP, viene utilizzata l’opzione di attivazione della Path
Maximum Transfer Unit Discovery (PMTU Discovery). Vediamo, in un esempio, di cosa si tratta:
R2
H1
Ethernet
MTU=1518
Ethernet
MTU=700
datagram da 1518 bytes
Flag DF
Ethernet
MTU=700
Ethernet
MTU=1518
R1
Messaggio ICMP
Necessaria
Frammentazione
H2
R3
H1 vuole spedire a H2 un messaggio. Al livello IP, dato che l’uscita sulla rete ha un Maximum
Transfer Unit di 1518 bytes, il messaggio viene eventualmente suddiviso in modo tale che ogni datagram IP
sia grande al più 1518 bytes. Inoltre il flag “don’t fragment” dell’ header IP viene settato. Il datagram
passerà tranquillamente R1 e arriverà a R2. R2 però non potrà far passare il datagram poiché l’MTU del
percorso R2-R3 non lo permette. R2 invierà quindi un messaggio ICMP a H1 avvisandolo che il datagram non
è potuto passare.
A questo punto H1 diminuisce la dimensione dei suoi datagrams in modo da farli fluire nella rete
senza che i router che vengono incontrati siano costretti a frammentarli. Questo procedimento serve a
trovare quale sia la dimensione massima per i datagram inoltrati su di una determinata rotta.
A parte la fase iniziale, in cui H1 cerca la dimensione migliore per i datagrams che invierà sulla rete,
tale procedimento rende comunque migliore l’efficienza del flusso delle informazioni che non subiranno né
frammentazione né deframmentazione.
E’ comunque vero che il PMTU è aggravato dal funzionamento di IPSec, infatti, una volta processato,
un datagram IP risulterà appesantito dai dati degli header AH e/o ESP. Per questo motivo è necessario
cercare di far convivere i due aspetti.
Il problema principale si pone, però, nel caso in cui IPSec venga utilizzato in modalità tunnel. In
questo caso un host, difficilmente può essere rintracciato dal messaggio ICMP. Vediamo perché:
Pagina 83 di 85
quando H1 invia un messaggio ad H2, mette in atto la politica del PMTU discovery. Passa il datagram
a R1 che lo processa con IPSec in modalità tunnel. Il datagram arriva a R2 con destinatario R3. Poiché R2
non è in grado di frammentare il datagram, invia un messaggio ICMP al mittente che risulterà R1 anzichè
H1. Come potrà fare H1 a ricevere il suo messaggio ICMP? Il messaggio ICMP contiene gli indirizzi di R1 e di
R3 e almeno 64 bits del payload del datagram IPSec. Visto il formato dei messaggi, all’interno di questi 64
bits sarà presente il solo SPI e nient’altro. Come si può allora informare H1 del messaggio ICMP?
La RFC 2401 propone due possibili soluzioni a questo problema:
•
R1, conoscendo il SPI vede chi sono tutti i possibili mittenti di quel messaggio e reinvia il
messaggio ICMP a tutti quanti. Questo tipo di soluzione può avere ripercussioni indesiderate. In
genere non è raccomandabile generare più traffico di quello che è effettivamente necessario.
•
R1 può mettere da parte il messaggio ICMP e mettersi in attesa di nuovi datagrams che
utilizzino una SA con lo stesso SPI contenuto nel messaggio ICMP. Appena uno di questi
datagrams viene intercettato da R1, se la sua dimensione è maggiore del MTU di R2, getta via il
pacchetto e assembla un messaggio ICMP per PMTU. Questa soluzione provoca comunque un
aggravio del ritardo nella fase iniziale delle comunicazioni tra H1 e H2.
Pagina 84 di 85
Bibliografia
Marco Strano - Computer Crime – Apogeo 2000
Jeff Schmidt – La sicurezza in Windows 2000 – MCGraw Hill 2000
J.F. Kurose & K.W. Ross – Internet e Reti – MCGraw Hill 2001
Paolo Ferragina e Fabrizio Luccio – Crittografia, principi algoritmi e applicazioni – Bollati Boringhieti 2001
Maurizio Cinotti – Internet Security – Hoeply Informatica 1999
Anonimo – Linux Massima Sicurezza – Apogeo 2000
Douglas E. Comer – Internetworking con TCP/IP – Jackson Libri 1992
Slides & Appunti dal “1° Convegno Net & System Secuity” tenutosi presso il C.N.R.(PI) l’8 marzo 2002.
RFC 1700 - Reynolds, Postel - Assigned Numbers - Ottobre 1994
RFC 1701 - Hancks, Li, Farinacci, Traina - Generic Routing Encapsulation - Ottobre 1994
RFC 2104 - Krawczyk, Bellare, Canetti - HMAC: Keyed-Hashing for Message Authentication - Febbraio 1997
RFC 2316 - Bellovino - Report of the IAB Security Architecture Workshop - Aprile 1998
RFC 2401 - Kent, Atkinson - Security Association for the Internet Protocol - Novembre 1998
RFC 2402 - Kent, Atkinson - IP Authentication Header - Novembre 1998
RFC 2406 - Kent, Atkinson - IP Encapsulating Security Payload - Novembre 1998
RFC 2407 – Piper - The Internet IP Security Domain of Interpretation for ISAKMP - Novembre 1998
RFC 2408 - Maughan, Schertler, Schneider, Turner - Internet Security Association and Key Management
Protocol - Novembre 1998
RFC 2409 - Harkins, Carrel - The Internet Key Exchange - Novembre 1998
Internet Draft "draft-simpson-danger-isakmp-01.txt
Simpson W. A. – IKE/ISAKMP Considered Dangerous – Giugno 1999
Internet Draft "draft-khetan-sp-greipsec-00.txt
Khetan A., Wang C., Beadles M., French L., Vyncke E. - Use of GRE for routing support in IPSec VPNs
Diffie W., Hellman M. - New Directions in Cryptography - IEEE Transaction of Information Theory, V. IT-22
n.6, Giugno 1977
Rivest R, Shamir A., Adleman L. - A Method for Obtaining Digital Signatures and Public-Key Cryptosystems Communications of the ACM, v. 21, n.2, Febbraio 1978
Cisco Systems Inc. - Configuring IPSec Network Security - Luglio 1999
Cisco Systems Inc. - Configuring Internet Key Exchange Security Protocol - Novembre 2001
Pagina 85 di 85
Ringraziamenti
La realizzazione di questo progetto è stata possibile grazie alla preziosa collaborazione di Micronix Computer
Spa.

VPN sicure con IPSEC

Transcript

Documenti analoghi

BEFVP41 v2-IT-DS-Rev_NC.fm

TAVOLA DEGLI SVILUPPI DI TAYLOR DELLE FUNZIONI

ntrout04 - Delta System srl

Table of Contents

I-Fly Wireless Router ADSL - Atlantis-Land

Router VPN 300Mbps wireless n

Pronto Networking

3x - Politecnico di Torino

CORSO virtuemart 2 2 1 3