�ݺ�ߣ

IPsec Cos'è ? IPsec [2] (IP Security) è una suite di protocolli utilizzati per creare reti private virtuali [1] (VPN). Università dell'Insubria - Relazione di Sicurezza Definizione IETF (Internet Engineering Task Force): “ Protocollo di sicurezza a livello rete sviluppato per fornire servizi di sicurezza crittografica che fornisce un supporto flessibile per autenticazione, integrità e confidenzialità.” IPsec sta diventando lo standard di fatto per la creazione di VPN.

Tipi di VPN LAN-to-LAN VPN: La connessione di due reti private per formare una sola rete privata virtuale. Client-to-LAN VPN: L’estensione di una rete privata per consentire l’accesso remoto agli utenti che diventano parte della rete privata. Università dell'Insubria - Relazione di Sicurezza

LAN-to-LAN VPN Università dell'Insubria - Relazione di Sicurezza

Client-to-LAN VPN Università dell'Insubria - Relazione di Sicurezza

Protocolli di IPsec Università dell'Insubria - Relazione di Sicurezza IKE: Internet Key Exchange[2] Fornisce un framework per la negoziazione dei parametri di sicurezza e lo scambio delle chiavi. ESP: Encapsulating Security Payload[4] fornisce un framework per la sicurezza dei dati e opzionalmente l'autenticazione. AH: Autentication Header[3] fornisce un framework per l’autenticazione e la sicurezza dei dati.

IKE Università dell'Insubria - Relazione di Sicurezza È una combinazione di 3 diversi protocolli: SKEME: Fornisce un meccanismo per l’utilizzo di crittografia a chiave pubblica per scopi di autenticazione. Oakley: Protocollo per lo scambio delle chiavi basato su Diffie-Hellman. ISAKMP[2]: Definisce l’architettura di scambio di messaggi, inclusi i formati dei pacchetti e le varie transizioni tra nodi IPsec.

ISAKMP Università dell'Insubria - Relazione di Sicurezza È un protocollo che definisce: Le procedure necessarie per attivare, negoziare, modificare e cancellare le Security Association[1] (SA). I formati dei pacchetti per lo scambio dei dati di generazione e autenticazione delle chiavi.

Procedure Università dell'Insubria - Relazione di Sicurezza Un tunnel IPsec viene costruito attraverso le seguenti fasi: Un nodo IPsec inizializza il collegamento con il nodo remoto o con la rete remota. I due nodi creano una Security Association (SA), ovvero un canale sicuro da utilizzare per i messaggi. I due nodi utilizzano la SA appena creata per negoziare le Security Association (SA) per altri protocolli. I dati iniziano a passare attraverso il tunnel criptato utilizzando le tecniche di incapsulamento AH o ESP.

Formati Università dell'Insubria - Relazione di Sicurezza L’intestazione di un messaggio ISAKMP ha la seguente struttura: Un messaggio ISAKMP è costituito da un’intestazione seguita da uno o più payload. Tutto ciò viene trasportato con il protocollo UDP.

Tipi di negoziazione IKE Università dell'Insubria - Relazione di Sicurezza IKE può realizzare diversi tipi di negoziazione:

Main Mode Università dell'Insubria - Relazione di Sicurezza La modalità “Main Mode[1]” avviene tramite lo scambio di 6 messaggi tra i due nodi IPsec.

Messaggio 1 (initiator -> responder) Università dell'Insubria - Relazione di Sicurezza SA Payload: Transform Payload: Proposal Payload:

Messaggio 2 (responder -> initiator) Università dell'Insubria - Relazione di Sicurezza SA Payload: È identico al precedente. Proposal Payload: Contiene le informazioni che il Responder ha deciso di accettare. Transform Payload: Contiene le informazioni che il Responder ha deciso di accettare.

Messaggio 3 (initiator -> responder) Università dell'Insubria - Relazione di Sicurezza Key Exchange Payload : Nonce Payload: Contiene il valore pubblico di Diffie-Hellman:

Messaggio 4 (responder -> initiator) Università dell'Insubria - Relazione di Sicurezza KE Payload: Contiene il valore pubblico di Diffie-Hellman: Nonce Payload: Contiene il nonce del responder N r

Calcolo delle chiavi Università dell'Insubria - Relazione di Sicurezza A questo punto entrambi i nodi sono in grado di calcolare il segreto condiviso: initiator: responder: A partire dal segreto condiviso S initiator e responder calcolano 3 chiavi: SKEYID: SKEYID_d: SKEYID_a: SKEYID_e:

Messaggio 5 (initiator -> responder) Università dell'Insubria - Relazione di Sicurezza Identification Payload : Hash Payload : Contiene un valore di hash calcolato nel seguente modo:

Messaggio 6 (responder -> initiator) Università dell'Insubria - Relazione di Sicurezza Identification Payload: Contiene ID-R. Hash Payload: Contiene un valore di hash calcolato nel seguente modo:

Autenticazione con PSK Università dell'Insubria - Relazione di Sicurezza Se i due valori di hash calcolati da Initiator e Responder sono gli stessi allora la sessione viene autenticata e quindi è stata creata la SA. Initiator: Responder: Decifra il messaggio 6 utilizzando SKEYID_e Trova la PK-R (Preshared-Key del responder) utilizzando ID-R Calcola HASH_R Se HASH_R ricevuto = HASH_R calcolato l’autenticazione ha successo Decifra il messaggio 5 utilizzando SKEYID_e Trova la PK-I (Preshared-Key del initiator) utilizzando ID-I Calcola HASH_I Se HASH_I ricevuto = HASH_I calcolato l’autenticazione ha successo

Aggressive Mode Università dell'Insubria - Relazione di Sicurezza Nell’aggressive mode[1] si ottiene lo stesso risultato che con il main mode, ma in soli 3 scambi di messaggi.

Quick Mode Università dell'Insubria - Relazione di Sicurezza Come la modalità Main mode è usata per concordare i parametri dell’ISAKMP SA, la modalità quick mode[1] è usata per concordare i parametri della IPsec SA. Nel nostro esempio, supponiamo che l’iniziatore ha deciso di utilizzare una proprietà conosciuta come Perfect Forward Secrecy (PFS).

Messaggio 1 (initiator -> responder) Università dell'Insubria - Relazione di Sicurezza Hash Payload : Valore di hash calcolato a partire dal segreto S e dal Nonce N i . SA Payload : Identico a quello del main mode. Proposal Payload : Contiene il tipo di incapsulamento e l’SPI. Transform Payload : Contiene la modalità tunnel o transport, l’algoritmo di crittografia, l’algoritmo di hash e il metodo di autenticazione. KE Payload : Contiene il valore Nonce Payload : Contiene il nonce dell’initiator N i ID-S Payload : ID-source in genere è l’indirizzo IP dell’initiator. ID-D Payload : ID-destination in genere è l’indirizzo IP del responder.

Messaggio 2 (responder -> initiator) Hash Payload : Valore di hash calcolato a partire dal segreto S e dal Nonce N r . SA Payload : Identico a quello del main mode. Proposal Payload : Contiene il tipo di incapsulamento e l’SPI nella direzione opposta. Transform Payload : Contiene la modalità tunnell o transport, l’algoritmo di crittografia, l’algoritmo di hash e il metodo di autenticazione scelti dal responder. KE Payload : Contiene il valore Nonce Payload : Contiene il nonce dell’responder N r ID-S Payload : ID-source in genere è l’indirizzo IP dell’initiator. ID-D Payload : ID-destination in genere è l’indirizzo IP del responder.

Calcolo delle chiavi Università dell'Insubria - Relazione di Sicurezza A questo punto entrambi i nodi sono in grado di calcolare il segreto condiviso: initiator: responder: A partire dal segreto condiviso S initiator e responder calcolano la chiave per la IPsec SA: Initiator: Responder:

Messaggio 3 (initiator -> responder) Università dell'Insubria - Relazione di Sicurezza Hash Payload : L’ultimo messaggio viene inviato per verificare la “Liveness” del responder. Esso contiene semplicemente un Hash calcolato nel seguente modo: Questo messaggio serve al responder per sapere se il messaggio 2 è arrivato all’initiator. Dopo che il responder ha ricevuto il messaggio 3 la negoziazione della SA è terminata e la SA può essere utilizzata per lo scambio dei dati sicuri.

Autenticazione con Digital Signature Università dell'Insubria - Relazione di Sicurezza L’unica differenza tra l’autenticazione con Preshared Key e Digital Signature è nei passaggi 5 e 6 del main mode. La prima differenza importante riguarda il modo in cui le SKEYs vengono generate:

Messaggio 5 (Digital Signature) Università dell'Insubria - Relazione di Sicurezza ID Payload : Contiene un identificativo per l’initiator come l’indirizzo IP o il nome dell’host. Signature Payload : Contiene la signature dell’initiator calcolata nel seguente modo:

Messaggio 6 (Digital Signature) Università dell'Insubria - Relazione di Sicurezza ID Payload : Contiene un identificativo per il responder come l’indirizzo IP o il nome dell’host. Signature Payload : Contiene la signature del responder calcolata nel seguente modo:

Autenticazione con Digital Signature Università dell'Insubria - Relazione di Sicurezza Se i due valori di hash calcolati da Initiator e Responder sono gli stessi allora la sessione viene autenticata e quindi è stata creata la SA. Initiator: Responder: Decifra il messaggio 6 utilizzando SKEYID_e Decifra HASH_R usando PK_R Calcola HASH_R Se HASH_R ricevuto = HASH_R calcolato l’autenticazione ha successo Decifra il messaggio 5 utilizzando SKEYID_e Decifra HASH_I usando PK_I Calcola HASH_I Se HASH_I ricevuto = HASH_I calcolato l’autenticazione ha successo

Sicurezza IKE (1) Clogging Attack: L’attacco clogging [1] è un attacco di tipo DoS in cui l’attaccante crea un indirizzo sorgente di un utente legittimo e invia una chiave pubblica Diffie-Hellman all’altro utente forzandolo ad eseguire un esponenziale modulare per calcolare la chiave segreta. Una serie ripetuta di messaggi di questo tipo può mettere in ginocchio il sistema della vittima. Il cookie evita questo attacco, ma deve seguire le specifiche ISAKMP: Deve dipendere dalle specifiche parti. Questo impedisce a un estraneo di derivare un cookie da un indirizzo IP e una porta UDP. Non deve essere possibile per nessuno, tranne per l’entità emettitrice, generare dei cookie che vengano accettati da tale entità. I metodi di generazione e verifica di un cookie devono essere veloci per evitare attacchi che mirano a consumare le risorse di elaborazione. Un attaccante non potrà più eseguire un attacco di tipo clogging perché quando invierà all’altro utente una chiave pubblica di Diffie-Hellman, l’altro utente prima verificherà il cookie e poi inizierà la computazione, ma essendo il cookie un numero pseudo-casuale l’attaccante non è in grado di crearne uno falso da solo.

Sicurezza IKE (2) Università dell'Insubria - Relazione di Sicurezza Replay Attack: In un attacco a replay [2], un estraneo ottiene copia di un pacchetto e successivamente lo ritrasmette alla destinazione prevista. Questo può causare problemi al funzionamento del servizio. Il Nonce ha lo scopo di sventare questo genere di attacchi.

Sicurezza IKE (3) Man-in-the-middle Attack: L'algoritmo Diffie-Hellman è soggetto all'attacco man in the middle [2]: Nello scambio di chiavi con IKE questo attacco non può funzionare perché i 2 nodi devono autenticarsi: Nel caso di autenticazione con Preshared Key il nodo E dovrebbe conoscere la Preshared Key. Nel caso di autenticazione con Digital Signature il nodo E dovrebbe conoscere la chiave segreta per la Firma di A e di B.

Openswan Università dell'Insubria - Relazione di Sicurezza OpenSwan[6] è l’implementazione IPsec più diffusa sui Linux recenti. Deriva da FreeSwan, progetto non più mantenuto. Il progetto è composto da 2 componenti: KLIPS : Il modulo del kernel per il supporto IPsec. PLUTO : Demone che implementa il protocollo IKE.

File di Configurazione di Openswan Università dell'Insubria - Relazione di Sicurezza Openswan utilizza principalmente 2 file di configurazione per configurare una connessione IPsec: /etc/ipsec.secrets : Contiene le chiavi RSA pubbliche e private oppure la PSK. /etc/ipsec.conf : Contiene i setting, le opzioni e le connessioni per openswan.

Il file “/etc/ipsec.conf ” Università dell'Insubria - Relazione di Sicurezza Il file è suddiviso in 3 sezioni: config setup : Parametri e opzioni globali. conn %default : Opzionale, è una sezione di default che contiene parametri globali che vengono ereditati dalle “conn” successive. conn nome-connesione : Definizione di una particolare connessione.

Il file “/etc/ipsec.secrets ” Università dell'Insubria - Relazione di Sicurezza Questo file contiene le chiavi RSA pubbliche e private oppure la PSK dell’host. Il file può essere generato automaticamente lanciando il comando: >ipsec newhostkey –output /etc/ipsec.secrets

host-to-host tunnel “ipsec.conf” version 2 config setup interfaces=%defaultroute conn %default authby=rsasig conn A-B left= 192.168.0.1 right= 192.168.0.2 type=tunnel leftrsasigkey= 0ArOk... rightrsasigkey= 0sAQP... auto=start version 2 config setup interfaces=%defaultroute conn %default authby=rsasig conn B-A left= 192.168.0.2 right= 192.168.0.1 type=tunnel leftrsasigkey= 0sAQP... rightrsasigkey= 0ArOk... auto=start

host-to-host tunnel “ipsec.secrets” Università dell'Insubria - Relazione di Sicurezza 192.168.0.1 (A) “ /etc/ipsec.secret” : RSA { # RSA 2192 bits A # Sat Dec 20 15:52:44 2008 #pubkey= 0ArOk... Modulus: 0xa... PublicExponent: 0x03 PrivateExponent: 0x1b... } leftrsasigkey= 0ArOk... rightrsasigkey= 0sAQP... “ /etc/ipsec.conf” 192.168.0.2 (B) “ /etc/ipsec.secret” : RSA { # RSA 2192 bits B # Sun Dec 21 15:00:44 2008 #pubkey= 0sAQP... Modulus: 0xc... PublicExponent: 0x04 PrivateExponent: 0x5b... } leftrsasigkey= 0sAQP... rightrsasigkey= 0ArOk... “ /etc/ipsec.conf”

Avvio di Openswan Per avviare openswan lanciamo il comando: Se tutto funziona correttamente apparira un “log” simile al seguente: Sep 15 20:05 A pluto[20362]: " A-B " #365: initiating Main Mode Sep 15 20:05 A pluto[20362]: " A-B " #365: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 Sep 15 20:05 A pluto[20362]: " A-B " #365: I did not send a certificate because I do not have one. Sep 15 20:05 A pluto[20362]: " A-B " #365: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 Sep 15 20:05 A pluto[20362]: " A-B " #365: Peer ID is ID_IPV4_ADDR: ' 192.168.0.1 ' Sep 15 20:05 A pluto[20362]: " A-B " #365: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 Sep 15 20:05 A pluto[20362]: " A-B " #365: ISAKMP SA established Sep 15 20:05 A pluto[20362]: " A-B " #366: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#365} Sep 15 20:05 A pluto[20362]: " A-B " #366: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2 Sep 15 20:05 A pluto[20362]: " A-B " #366: sent QI2, IPsec SA established {ESP=>0xe5f72aaa <0xc51033f4} > /etc/init.d/ipsec {start | stop | restart }

host-to-host tunnel (PSK) Università dell'Insubria - Relazione di Sicurezza A volte c’è bisogno di connettere Openswan a un dispositivo che non può gestire chiavi RSA. Immaginiamo che “A” sia questo host. In questo caso dobbiamo modificare il file “/etc/ipsec.secrets” nel seguente modo: 192.168.0.1 192.168.0.2 : PSK segreto Inoltre dobbiamo modificare la connessione nel file “/etc/ipsec.conf ” nel seguente modo: conn A-B authby=secret left=192.168.0.1 right=192.168.0.2 type=tunnel auto=start

LAN-to-LAN tunnel version 2 config setup interfaces=eth1 conn %default authby=rsasig conn LAN_A-LAN_B left= 87.9.19.54 leftsubnet= 192.168.0.0/24 right= 87.9.19.58 rightsubnet= 192.168.1.0/24 leftrsasigkey= 0sAQ43A1.... rightrsasigkey= 0sAQfP63... type=tunnel auto=start version 2 config setup interfaces=eth1 conn %default authby=rsasig conn LAN_B-LAN_A left= 87.9.19.58 leftsubnet= 192.168.1.0/24 right= 87.9.15.54 rightsubnet= 192.168.0.0/24 leftrsasigkey= 0sAQfP63... rightrsasigkey= 0sAQ43A1.... type=tunnel auto=start Università dell'Insubria - Relazione di Sicurezza

Roadwarriors tunnel Università dell'Insubria - Relazione di Sicurezza version 2 config setup interfaces=eth1 conn %default authby=rsasig conn Roadwarriors left= 87.9.19.54 leftsubnet= 192.168.0.0/24 right= %any rightid= @notebook_B leftrsasigkey= 0sAQ43A1.... rightrsasigkey= 0sAQfP63... type=tunnel auto=add version 2 config setup interfaces=%defaultroute conn %default authby=rsasig conn Roadwarriors left= %defaultroute leftid= @notebook_B right= 87.9.19.54 rightsubnet= 192.168.0.0/24 leftrsasigkey= 0sAQfP63... rightrsasigkey= 0sAQ43A1.... type=tunnel auto=start

Roadwarriors tunnel (PSK) Università dell'Insubria - Relazione di Sicurezza In questo caso dobbiamo modificare il file “/etc/ipsec.secrets” nel seguente modo su “A”: 192.168.0.1 %any : PSK password Inoltre dobbiamo modificare il file “/etc/ipsec.secrets” nel seguente modo su “B”: %defaultroute 87.9.19.54 : PSK password

Altre opzioni di Openswan Università dell'Insubria - Relazione di Sicurezza L'opzione IKE : è usata per impostare i parametri di negoziazione della ISAKMP SA come ad esempio: L'opzione ESP : è usata per impostare i parametri di negoziazione della IPsec SA come ad esempio: ike=”3des-sha1-96,aes-md5-96“ esp=”aes256-sha1,aes128-sha1,3des-sha1“ L'opzione aggrmode : imposta l'aggressive mode nella negoziazione della ISAKMP SA: aggrmode=yes

Certificati x.509 e openswan Università dell'Insubria - Relazione di Sicurezza Finora abbiamo visto come creare una connessione IPsec per uno specifico utente, ma questo è sicuramente poco scalabile. In questa parte vogliamo creare un server VPN che sia in grado di distribuire differenti credenziali VPN ad ogni singolo utente. Il modo più usato per fare questo è attraverso i certificati X.509. x.509 è uno standard definito dalla ITU-T (International Telecommunication Union - Telecommunication Standardization Sector). I certificati vengono rilasciati da una Autorità di Certificazione (CA) la cui firma apposta sul certificato garantisce il legame tra chiave ed entità.

Struttura x.509 Università dell'Insubria - Relazione di Sicurezza La struttura delle CA è di tipo gerarchico: RDNs: Michele Rossi DN(Distinguished Name): C=CA / State=Italy / Locality=Milan / Organization=Microsoft / OU=Sales Staff / UserID=Michele Rossi

Struttura di un certificato x.509 Università dell'Insubria - Relazione di Sicurezza Certificate: Version: 3 (0x2) Serial Number: e4...48 Sign Algorithm:sha1WithRSAEnc Issuer: C=CA, ST=Italy, L=Milan, O=Microsoft, OU=Support Staff, CN=Microsoft Root Validity Not Before: Feb 19 Not After : Mar 21 Subject: C=CA, ST=Italy, L=Milan, O=Microsoft, OU=Sales Staff, CN=Michele Rossi Subject Public Key Info: Public Key Algorithm:RSA RSA Public Key: Modulus:00...db Exponent: 65...77 X509v3 extensions: ... Signature Algorithm:sha1WithRSA 2b...5e

x.509 e Openswan Università dell'Insubria - Relazione di Sicurezza Quando la connessione è configurata per l’utilizzo di certificati x.509, invece di caricare la chiave privata RSA da ”/etc/ipsec.secrets“, la chiave privata viene caricata dal un file ”.key“ e la chiave pubblica viene caricata da un file ”.cert”. Questi file vengono caricati automaticamente se vengono inseriti nelle directory corrette: /etc/ipsec.d/certs : contiene i certificati con le chiavi pubbliche. /etc/ipsec.d/cacerts : contiene i CA certificates. /etc/ipsec.d/private : contiene le chiavi private.

Connessione con self-signed certificate Università dell'Insubria - Relazione di Sicurezza version 2 config setup interfaces=%defaultroute conn A-B left= 192.168.0.1 leftcert= A.cert right= 192.168.0.2 rightcert= B.cert type=tunnel auto=start version 2 config setup interfaces=%defaultroute conn B-A left= 192.168.0.2 leftcert= B.cert right= 192.168.0.1 rightcert= A.cert type=tunnel auto=start

Connessione con Certification Authority version 2 config setup interfaces=eth1 conn A-roadwarriors left= 87.9.19.54 leftsubnet= 192.168.0.0/24 leftcert= A.cert right=%any rightrsasigkey=%cert rightid="C=CA, S=Europe, O=Microsoft, CN=*" auto=add version 2 config setup interfaces=%defaultroute conn B-A left= %defaultroute leftcert= B.cert right= 87.9.19.54 rightsubnet= 192.168.0.0/24 rightcert= A.cert type=tunnel auto=start

Conclusioni Università dell'Insubria - Relazione di Sicurezza Sicurezza : IPsec porta un indubbio vantaggio in termini di sicurezza, trasferendo al network layer i problemi di autenticazione e confidenzialità prima risolti con soluzioni tipicamente ad application layer (ad es. ssh, kerberos, ssl). Complessità : l'infrastruttura IPsec è quanto meno complessa sia in termini di protocollo sia per quanto riguarda l'utilizzo di applicativi (come Openswan) o di dispositivi (come i Router ad es: Cisco) che la implementano. Uso limitato : pur essendo stato definito ormai alcuni anni fa IPsec è utilizzato al momento in casi abbastanza limitati.

Bibliografia Università dell'Insubria - Relazione di Sicurezza Saadat Malik, Network Security Principles and Practices, Cisco Press, Chap. 13, February 2002. S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998 S. Kent, R. Atkinson, IP Encapsulating Security Payload (ESP), RFC 2406, November 1998 S. Kent, R. Atkinson, IP Authentication Header, RFC 2402, November 1998 D. Piper, The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, November 1998. Wouters P. & Bantolf K. (2006) Building and integrating Virtual Private Networks with Openswan, Packt Publishing Ltd

�ݺ�ߣ

IPsec

More Related Content

IPsec