2. Traduzione di policy di sicurezza di medio
livello in configurazioni IPsec di basso livello
per sistemi Unix
Policy di alto livello
Policy di medio livello
Configurazioni di basso livello
2
INTRODUZIONE
3. Policy di alto livello
Policy di medio livello
Configurazioni di basso livello
vendor-independent
technology-independent
Creare un canale sicuro per le comunicazioni tra il PC 1 e il PC 2
3
INTRODUZIONE
4. Policy di alto livello
Policy di medio livello
Configurazioni di basso livello
vendor-independent
technology-dependent
Proteggere il traffico tra 10.0.50.1 e 10.0.50.2 utilizzando ESP
transport mode ed IKEv2
4
INTRODUZIONE
5. Policy di alto livello
Policy di medio livello
Configurazioni di basso livello
vendor-dependent
technology-dependent
Il contenuto dei file ipsec.conf e ipsec.secrets presenti in /etc/
5
INTRODUZIONE
6. 1. Studio approfondito di IPsec ed IKE
2. Studio del D4.1
3. Scelta dell’implementazione IPsec di
riferimento
4. Estensione del MSPL
5. Realizzazione del plugin
6. Testing
6
INTRODUZIONE
7. Header: AH ed ESP
Modalità: Transport Mode e Tunnel Mode
Scenari di utilizzo:
◦ Accesso remoto
◦ Site-to-site
◦ End-to-end
RFC-430x
7
STUDIO DI IPsec
8. Window
L H
8
Miglioramento protezione da attacchi replay
Dimensione: 64 bit
Valore locale: da 0 a 2^64 -1
Sequence Number in AH/ESP: solo i 32 bit
meno significativi
STUDIO DI IPsec
9. Transport Mode
◦ L’header IPsec è applicabile solo a datagram IP
completi
Stack IP del ricevente deve riassemblare prima di
processare IPsec
Tunnel Mode
◦ L’header IPsec è applicabile anche a frammenti
Nessun problema
9
STUDIO DI IPsec
10. Path MTU Discovery
Conoscere la MTU minima Minore probabilità di frammentazione
WAN
MTU:1300
Fragmentation
needed
MSG
[1400 B]
A B
MTU:1480
MTU:1480
MTU:1480
MTU:1480
Miglioramento delle prestazioni
10
Frammentazione in locale
STUDIO DI IPsec
11. Extended Sequence Number
Supporto per AH declassato a MAY
Combined mode algorithms (algoritmi di
cifratura autenticata)
TFC: Variable-length Padding e dummy
packets
SA unicast univocamente identificata da SPI e,
opzionalmente, dal protocollo
Entry del SAD decorrelate
NULL authentication declassata a MAY
11
STUDIO DI IPsec
12. IKEv2: RFC-7296
IKEv1: RFC-2409
Mutua autenticazione delle parti
Stabilire Security Association
2 Exchange principali
◦ IKE_SA_INIT
◦ IKE_AUTH
12
STUDIO DI IKE
13. Security Association (SA)
Configuration (CP)
Notify Payload (N)
Traffic Selector (TSi/TSr)
Authentication (AUTH)
Certificate (CERT)
Certificate Request (CERT_REQ)
13
STUDIO DI IKE
15. 15
in-place rekeying è abilitato
◦ CREATE_CHILD_SA request
◦ meno messaggi scambiati
◦ più veloce
in-place rekeying non abilitato
◦ necessario terminare la vecchia SA
◦ eventualmente stabilirne una nuova
ri-autenticazione
risorse
tempo
tempo
risorse
STUDIO DI IKE
16. Problemi
◦ Transport mode: la modifica degli indirizzi IP
causerebbe il fallimento della verifica della
checksum per la controparte
◦ Tunnel mode: problemi di routing
Soluzione
◦ Rilevamento di NAT attraverso i Notify Payload
NAT_DETECTION_[SOURCE/DESTINATION]_IP
◦ IKE e IPsec incapsulati in UDP (src/dst port 4500)
16
STUDIO DI IKE
17. Supporto al NAT-Traversal
Tempo di vita della SA autonomo per ogni peer
MOBIKE
Meccanismo di keepalive
Message ID e acknowledgment
Supporto per autenticazione EAP
17
STUDIO DI IKE
18. Valutate diverse implementazioni: IPsec-Tools,
FreeSWAN, OpenSwan, Libreswan e strongSwan
La scelta: strongSwan
◦ più funzionalità
◦ adatta a VPN grandi e complesse
◦ continuo aggiornamento
◦ ampiamente documentata
◦ inclusa in Ubuntu 14.04 LTS (Aprile 2014)
18
IMPLEMENTAZIONE IPSEC
20. Virtual IP
ESN
MOBIKE
SA lifetime, rekey margin e rekeying tries
Passphrase per chiave privata RSA crittata
Local|Remote ID e filename (certificati)
Modifiche di cardinalità
20
ESTENSIONE DEL MSPL
22. 22
Generazione automatica delle classi
Unmarshalling
Parsing
Traduzione
Popolamento dei wrappers
Trasformazione
REALIZZAZIONE DEL PLUGIN
23. Caratteristiche del software
◦ Astrazione
◦ Separazione dei componenti
◦ Flessibilità
◦ Javadoc
23
REALIZZAZIONE DEL PLUGIN
24. Estendere il plugin ad una nuova funzionalità
di strongSwan
◦ Aggiornare il wrapper del file di configurazione
◦ Effettuarne il set nell’opportuno punto del workflow
Estendere il plugin al supporto di un’altra
implementazione IPsec
◦ Estendere il parser astratto
24
REALIZZAZIONE DEL PLUGIN
25. Stratificazione
Minor probabilità di commettere errori
Traduzione automatica
Velocità
25
Medio livelloAlto livello Basso livello
CONCLUSIONI
26. Punti di forza del plugin
◦ Estendibilità
altre implementazioni IPsec
nuove funzionalità di strongSwan
◦ Manutenibilità
Java Bean e separazione dei compiti
◦ Documentazione
manuali utente e sviluppatore
Javadoc
istruzioni per replica degli scenari
26
CONCLUSIONI
L’obiettivo di questo lavoro è la realizzazione di un plugin per la traduzione di policy di medio livello in configurazioni IPsec di basso livello per sistemi Unix.
Questa stratificazione delle policy in livelli di astrazione è stata definita nel modello illustrato nel documento D4.1 redatto dal TORSEC , che si è ispirato al paper intitolato “Policy Continuum – A formal model”, ovvero un paper che tratta la definizione di alcuni livelli di astrazione per quanto riguarda le policy in generale.
Il modello proposto nel D4.1 è suddiviso in tre livelli di astrazione - che saranno analizzati in seguito - ognuno dei quali è destinato ad un particolare bacino d’utenza ed è caratterizzato da un proprio linguaggio.
vendor-independent: non dipendono dal prodotto hardware nel quale vengono installate
technology-independent: non dipendono da una particolare tecnologia software o hardware, in altre parole, l’utente che le definisce non si deve preoccupare di acquisire particolari conoscenze tecniche (a.e. IP, IPsec, ecc)
Un utente in grado di delineare tali policy è l’utente di casa ed un esempio di tali policy è riportato in figura...
Nel modello proposto dal TORSEC il linguaggio che permette di definire tali policy è HSPL.
vendor-independent: come le policy di alto livello
technology-dependent: queste policy dipendono dalla tecnologia software a cui si riferiscono, ad esempio che modalità di ESP utilizzare, quale versione di IKE utilizzare, che algoritmi di cifratura utilizzare, ecc...
Un utente in grado di delineare tali policy è il sistemista o lo sviluppo, in altre parole, un utente che abbia conoscenze in merito alle tecnologie supportate da queste policy. Un esempio di tali policy è riportato in figura...
Infine ci sono le configurazioni di basso livello, ovvero l’effettiva realizzazione delle policy di più alto livello.
Vendor-dependent: dipendono dal sistema operativo e dall’hardware dove vengono installate.
Technology-dependent: come le policy di medio livello, queste policy sono specifiche per determinate technologie software.
+VELOCE
Questo lavoro si è sviluppato in diverse fasi.
IPsec ed IKE: sono stati studiati nel dettaglio i protocolli IPsec ed IKE al fine di delinearne lo stato dell’arte e acquisire nozioni riguardo ad alcune funzionalità avanzate.
D4.1: la fase successiva è stata lo studio del documento D4.1 redatto dal TORSEC e riguardante le policy di sicurezza di alto e medio livello.
In particolare si è data maggior attenzione al MSPL.
Scelta: una volta delineato lo stato dell’arte del MSPL, si sono confrontate alcune implementazioni IPsec presenti sul mercato al fine di scegliere quella per cui realizzare poi le configurazioni di basso lvello.
Modifiche al MSPL: avendo studiato lo stato dell’arte dell’implementazione IPsec scelta e del MSPL è stato possibile confrontarle al fine di aggiungere alcune funzionalità al MSPL al fine di supportare alcune funzionalità trovate in strongSwan
Realizzazione del plugin: design delle classi e realizzazione del parser che costituisce il core del plugin
Testing: sono state effettuate alcune verifiche, testando:
1- la coerenza delle configurazioni di basso livello prodotte in relazione alle policy di medio livello definite
2- l’effettivo funzionamento di tali configurazioni di basso livello, attraverso la replica dei più comuni scenari di rete (remote access, site 2 site, end 2 end) in locale
IPsec è un protocollo creato al fine di realizzare comunicazioni sicure nelle reti IP. I due header che compongono questo protocollo sono AH ed ESP.
In questa fase della presentazione si illustreranno alcune funzionalità avanzate di IPsec come l’utilizzo dell’Extended Sequence Number e la gestione della frammentazione.
ESN: estensione del già esistente meccanismo di anti replay.
Questa opzione permette di utilizzare una finestra di 64 bit anzichè 32, al fine di proteggersi da attacchi di tipo replay.
questa funzionalità SHOULD essere implementata
IKE suppone che si usi questa funzionalità a meno che non si richieda di utilizzare 32 bit
solo i 32 bit meno significativi saranno trasmessi nel pacchetto
- si può impostare che questo esn non venga utilizzato, con payload CFG
RAPPORTO TRA IPSEC E FRAMMENTAZIONE
TRANSPORT: in Transport Mode l’header IPsec è applicabile solamente a datagram IP completi. ==> In fase di riassemblamento dei frammenti, lo stack IP del ricevente dovrà prima di tutto riassemblare il pacchetto e poi processare l’header IPsec.
TUNNEL: in Tunnel mode questo header può essere applicato anche a frammenti.
Dal momento che la frammentazione è un’operazione abbastanza onerosa in termini di memoria e tempo, è più conveniente che il nodo invii pacchetti della dimensione minima supportata dalle reti attraversate lungo il percorso. Per poter sapere qual’è la MTU minima esiste un meccanismo chiamato Path MTU Discovery che consiste nell’invio di un primo messaggio CON IL BIT DON’T FRAGMENT SETTATO AD 1 di grandezza coerente con la MTU della rete collegata all’interfaccia. Se un router lungo il percorso non riesce ad inoltrare tale pacchetto, invierà al mittente un messaggio con il quale lo informa del valore della sua MTU. (ICMP – Fragmentation Needed)
Così facendo A conoscerà l’MTU minima del path verso B e pre-frammenterà il pacchetto in modo tale che lungo il percorso non sia necessaria la frammentazione.
L’implementazione IPsec deve essere in grado di mandare questo tipo di messaggi ICMP
ESN: visto in precedenza
AH-MAY: ESP fa tutto quello che fa AH eccezion fatta per la protezione dell’header IP con l’integrity check, il vantaggio continua ad essere la riduzione del pacchetto e si risparmia una SA (conf+ integr). AH non va d’accordo con il NAT perchè fa fallire integrity check quando il NAT cambia gli indirizzi, mentre ESP non proteggendo l’hader esterno non da problemi.
COMBINED MODE: Aggiunta di particolari algoritmi che offrono confidenzialità e integrità in un unica soluzione
SA_ID = SPI+ PROTO: Come affermato nell’ RFC-6701 intitolato IPsec/IKE Roadmap nella sezione inerente alle novità presenti in IPsec-v3
TFC: l’inserimento di questo padding speciale che si trova dopo il payload e prima del padding normale. Questo padding, anche chiamato TFC padding,
rientra nell’ambito del Traffic Flow Confidentiality ovvero nel meccanismo che intende nascondere ad eventuali attaccanti le caratteristiche del flusso di traffico.
Per poter utilizzare questo padding è necessario che il protocollo contenuto nel payload, a livello 4 per capirsi, contenga le informazioni (a.e. length) necessarie a rimuovere opportunamente tale padding. Questo servizio deve essere negoziato in fase di creazione della SA in modo tale da assicurarsi che le parti siano pronte a ricevere tale padding.
Inoltre sono stati definiti dei pacchetti speciali definiti dummy packets che contengono dati random, e servono per confondere eventuali attaccanti, il valore del campo next header che identifica tali pacchetti è il 59, e quando un implementazione IPsec li riceve, li scarta senza generare alcuna notifica.
SAD-DECO: Le entry del Security Association Database sono ora decorrelate, indipendenti dall’ordine. Questo approccio migliora le prestazioni in fase di ricerca di una SA. L’esistenza di SA correlate ed ordinate in base ad una specificità maggiore complicava la ricerca. In questo modo la ricerca e il caching sono molto più semplici in quanto si riferiscono solamente al SPI e al protocollo
NULL: prima era MUST ora è MAY
Per l’autenticazione delle parti, per la negoziazione delle chiavi e degli algoritmi utilizzati per la cifratura.
Sia per stabilire quali algoritmi crittografici saranno utilizzati per proteggere la comunicazione, sia per proteggere la comunicazione di negoziazione, ovvero la comunicazione IKE.
IKEv2 RFC: 4306 updated by 5996 updated by 7296
IKEv1 RFC: 2409
IKE_SA_INIT: utilizzato per negoziare i parametri di sicurezza per la IKE SA, mandare i nonce e i valori Die-Hellman. Questo scambio non e cifrato in quanto e il primo ad avvenire e la negoziazione degli algoritmi di cifratura non e ancora avvenuta.
IKE_AUTH:secondo scambio utilizzato per la trasmissione delle identità, provare la conoscenza dei segreti corrispondenti alle identita ed inizializzare la prima CHILD SA. Parte dei messaggi inviati in questo scambio e cifrata utilizzando gli algoritmi negoziati nella fase precedente;
Altri exchange :
CREATE_CHILD_SA: per creare SA glie (anche chiamate CHILD SA) facenti capo ad una IKE SA. Una Child SA e una normale SA che e stata creata sfruttando una SA gia esistente. Questa funzionalita trova largo impiego nella fase di rekeying
INFORMATIONAL: per lo scambio di informazioni, errori e notiche tra gli endpoint. Un particolare utilizzo con payload vuoto viene sfruttato come keepalive.
SA: per la negoziazione degli attributi della security association. Contiene lista di proposal, i quali contengono più protocolli (a.e. IKE, ESP,AH), ogni protocollo contiene uno o più transform e ogni transform uno o più attributi.
CP: scambiare informazioni di configurazione tra i peer (IP delle parti, sottoreti, indirizzi IP dei server DCHP e DNS)
N: utilizzato per scambiare informazioni come notifiche di errore o transazioni di stato, insomma informazioni riguardanti lo stato dei peer durante la comunicazione
TSi/TSr: trasportare un set di selettori di traffico (strutture dati che consistono in un range di indirizzi, range di porte e un protocollo), rispettivamente per Initiator e Responder. Utilizzato per descrivere il traffico transitante in una SA.
AUTH: contiene le informazioni utilizzate per l’autenticazione della controparte
CERT: permette il trasporto di certificati X.509
CERT_REQ: permette di richiedere uno o più certificati alla controparte
Attraverso il configuration payload del Configuration Payload
CFG_SET può essere un singolo IP, un range o una subnet
CFG_RESPONSE può essere lo stesso IP, o un IP del range o un IP della subnet
E’ opportuno proteggere una quantità limitata di dati per un tempo limitato. SA deve avere durata limitata. => Quando scade deve essere rinegoziata.
2 casi:
implementazione IPsec supporta “in-place rekeying” (opzionale): attraverso l’uso di CREATE_CHILD_SA , è possibile creare SA figlia che rimpiazzerà la vecchia SA . VANTAGGI: - pacchetti, - tempo perso
implementazione IPsec non supporta request di tipo CREATE_CHILD_SA, sarà necessario terminare la IKE SA e stabilirne un’altra SVANTAGGIO: oneroso in termini di tempo, risorse e banda, immaginiamoci di trovarci in un gw aziendale con molte SA attive
Il NAT-traversal è una tecnica per la risoluzione di problemi legati alla comunicazione di rete in presenza dei NAT, dispositivi che effettuano la rimappatura dello spazio degli indirizzi di rete.
In base al tipo di modalità scelta per il traffico, si presentano problemi differenti: TRANSPORT MODE: il NAT modifica gli indirizzi IP dell’header IP e questo fa fallire la verifica della checksum da parte della controparte
TUNNEL MODE: problemi di routing dovuti, risolvibili solamente aggiungendo al NAT una logica che permetta di capire come tradurre tali indirizzi. Non realizzabile.
RILEVAMENTO
INCAPSULAMENTO: Dal momento che gli header IPsc non hanno il concetto di port number, si sfrutta l’header UDP già supportato dai NAT e si incapsula il pacchetto ESP ad esempio al suo interno. (esempio RFC:3948 - UDP Encapsulation of IPsec ESP Packets)
Esempio di Incapsulamento di ESP in transport mode NAT :
rimpiazza gli IP e il SRC_PORT
Vedere esempio presente a pag.67 RFC 7296 , sostituzione degli indirizzi mappati in TSi TSr
DECAPSULAMENTO:
rimuovere header UDP
Modificati i campi Total Length, Protocol, Header Checksum in modo coerente con il nuovo pacchetto
Effettuata il normale processing di ESP per i pacchetti in entrata
Decapsulamento Transport mode del NAT
NATTRA: IKEv2 fornisce supporto nativo al NAT-Traversal
LIFETIME: ogni peer può stabilire autonomamente il tempo di vita della SA, allo scadere del più breve la SA viene rinegoziata. In precedenza questa opzione veniva negoziata
MOBIKE: RFC-4555. IKEv2 include questa funzionalità che permette ad utenti mobili e multi-home di utilizzare le caratteristiche di una SA negaoziata pur cambiando il proprio punto di accesso alla rete (a.e. una nuova interfaccia di un router o un nuovo indirizzo) senza dover rinegoziare la SA. Nel caso di utenti mobili questo meccanismo si basa sul continuo update dell’indirizzo IP dell’initiator man mano che questo cambia (a.e. cellette) tramite il messaggio UPDATE_SA_ADDRESSES.
Ottimo perchè non è necessaria una nuova interazione con l’utente (autenticazione), meno tempo.
KEEPALIVE: attraverso l’exchange denominato “Informational”, scambi che possono contenere uno o più payload di tipo Notification, Delete e Configuration. Se connessione si è chiusa => rekeying. In IKEv1 ci sono dei workaround ma non c’è un meccanismo standardizzato.
MESSAGE ID: analogo di Sequence Number, serve a proteggere IKE (parzialmente) da attacchi di tipo replay.
Acknowledgement serve a rendere più affidabile la comunicazione
EAP: supporto per metodi di autenticazione basati su EAP ed autenticazione asimmetrica, in questo modo Initiator e Responder possono utilizzare metodi di autenticazione differenti tra loro
EAP è un protocollo che serve a trasportare protocolli di autenticazione. Rende indipendente qualche cosa dalla tecnica di autenticazione!
Dubbio:
MESSAGGI: Request , Response e relativi acknowledgement. Mentre in IKE-v1 Main mode (6 messaggi), Aggressive mode (3 messaggi). => snellimento comunicazione => meno banda
StrongSwan è una soluzione IPsec OpenSource completa. Questa implementazione è stata scelta dopo un confronto con diverse altre implementazioni presenti sul mercato: IPsec-Tools e FreeS\WAN più datate e non più aggiornate.
OpenSwan un’implementazione abbastanza completa ma quasi abbandonata da 3 anni a questa parte. LibreSwan, una fork di OpenSwan dopo un contenzioso avvenuto tra alcuni membri del team di sviluppo. StrongSwan è risultata essere l’implementazione più aggiornata, più ricca e meglio documentata.
E’ installato nell’ultima release Long Term Support di Ubuntu (Ubuntu Thrusty Thar 14.0)
Ricordare cos’è il MSPL
Modificare il MSPL consiste nella modifica del file xsd di riferimento illustrato in seguito.
Una volta studiato lo stato dell’arte di IPsec, IKE e strongSwan sono state apportate delle modifiche al MSPL al fine di supportare alcune funzionalità.
Il plugin è stato realizzato sotto forma di una Java Application.
Il sorgente è stato organizzato in diversi package e diverse classi in modo tale da separarne le diverse componenti
ASTRAZIONE: il parser che effettua la traduzione delle policy di medio livello in configurazioni strongSwan non è altro che un’astrazione di un generico parser implementato sotto forma di classe astratta, che permette l’estensione di questo plugin ad altre implementazioni IPsec (come quelle citate in precedenza). In particolare il parser generico ( o astratto) contiene un unico metodo concreto che costituisce il flusso di operazioni di business logic (ad esempio “ispeziona i parametri di IKE”, “ispeziona i parametri riguardanti IPsec”, ecc..) e un insieme di metodi astratti che effettueranno le singole operazioni coerentemente con l’implementazione di riferimento.
SEPARAZIONE: sono stati creati diversi classi e package al fine di isolare i diversi componenti e separarne i compiti sia perchè alcuni componenti eseguono operazioni per natura diverse dagli altri e sia perchè alcuni componenti appartengono ad un diverso livello di astrazione (come il parser generico ed il parser per strongSwan illustrato in precedenza)
SEMPLICITA’: utilizzo di Java Bean, ovvero classi Java implementate secondo un pattern che prevede la presenza di soli getters e setters.
FLESSIBILITà: 1 approccio “contains” in fase di ricerca di determinati valori + case e sinonimi (a.e. any per il campo IP).
2 processo di trasformazione da wrapper a file illustrato in precedenza
COMMENTI PER JAVADOC: tutte le classi e i metodi sono commentati utilizzando la notazione proposta dal tool Javadoc al fine di generare una documentazione ben formattata. Allegato.
EXT FUNZ:
EXT IMPL: principalmente basta estendere il parser astratto al fine di poter riutilizzare il workflow
CONCLUDENDO Questo lavoro, come detto nell’introduzione, rientra nel più ampio processo di realizzazione di configurazioni di sicurezza di basso livello a partire da policy di alto livello.
- è importante perchè permette ad un utente qualunque, che non ha competenze tecniche, di realizzare configurazioni di basso livello sfruttando le potenzialità del proprio sistema operativo.
la traduzione è AUTOMATICA in quanto questo plugin sarà utilizzato da un altro software che si occuperà dell’intero processo di traduzione, ottimizzandone l’esecuzione
vi è inoltre una minor probabilità di commettere degli errori sia perchè questo processo è automatizzato, sia perchè gli utenti appartenenti ai diversi livelli di astrazione si sono specializzate
AUTOMAZIONE + ASTRAZIONE = RIDUZIONE PROBABILITà D’ERRORE E OTTIMIZZAZIONE DEL PROCESSO
EST: estendere nelle due direzioni illustrate in precedenza, di vitale importanza se si vuole rimanere allineati con lo stato dell’arte delle implementazioni IPsec.
MANU: vista la semplicità delle classi e la separazione di classi e package è facile modificare o analizzare il codice.
DOCU: manuale utente e sviluppatore + javadoc + 3 esempi txt con istruzioni
Grazie per la vostra attenzione
Initiator invia un set di proposal. Quese proposal sono contenute nel payload Security Association Payload illustrato in precedenza.
Nell’esempio riportato in figura, le proposal riguardano gli algoritmi per fornire confidenzialità e l’integrità di ESP
Il responder può accettarne una , o rifiutarle tutte (NO_PROPOSAL_CHOSEN).Il responder deve per forza rispondere con una Transform per ogni Transform Type. In questo caso ci sono Transform di tipo ENCR e AUTH.
Attraverso l’utilizzo dei payload TS è possibile scambiare info riguardanti le entry del SPD.
La figura presenta uno scenario semplificato in cui questi payload descrivono solamente degli indirizzi IP.
In realtà il payload TS contiene:
- range di indirizzi
- range di porte
-
Questo esempio presenta il caso in cui il gateway A volesse instaurare un tunnel con il gateway B al fine di inoltrare il traffico proveniente dalla sua sottorete, nella sottorete protetta da B.
Questo meccanismo permette inoltre che B possa selezionare un sottoinsieme dei selettori proposti da A.
