Linux Kernel 2.5/2.6 utilizzando i KAME-tools

Transport Mode

Si illustrerà prima una connessione manuale in transport mode. Probabilmente è il modo più facile per iniziare poichè è la connessione più semplice da realizzare. Poniamo che vi siano due macchine con indirizzi IP 192.168.1.100 e 192.168.2.100 che comunicano attraverso IPsec.

Tutti i parametri contenuti nel SAD e nel SPD possono essere modificati attravreso il comando setkey. Esiste una man page piuttosto esaustiva su questo comando. Dunque solo le opzioni necessarie per realizzare una connessione in transport mode sono mostrate qui di seguito. setkey legge i propri parametri da un file quando invocato con l'opzione -f setkey -f /etc/ipsec.conf. Un modello di /etc/ipsec.conf piuttosto realistico:

#!/usr/sbin/setkey -f

# Configurazione per 192.168.1.100

# Svuoto il SAD e SPD
flush;
spdflush;

# Attenzione: utilizzate queste chiavi solo per i test!
# Generate delle chiavi vostre!

# Le AH SAs utilizzano chiavi di 128 bit
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 \
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 \
0x96358c90783bbfa3d7b196ceabe0536b;

# Le ESP SAs utilizzano chiavi di 192 bit (168 + 24 parity)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc \
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc \
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;

# Security policies
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P in ipsec
           esp/transport//require
           ah/transport//require;
	

Saranno necessarie delle chiavi per rimpiazzare quelle dello script di esempio in caso si desideri utilizzare una connessione manuale in transport mode in un ambiente di produzione. Per generare le proprie chiavi è possibile utilizzare il seguente metodo:

$ # chiavi a 128 Bit 
$ dd if=/dev/random count=16 bs=1| xxd -ps
16+0 Records ein
16+0 Records aus
cd0456eff95c5529ea9e918043e19cbe

$ # chiavi a 192 Bit 
$ dd if=/dev/random count=24 bs=1| xxd -ps
24+0 Records ein
24+0 Records aus
9d6c4a8275ab12fbfdcaf01f0ba9dcfb5f424c878e97f888
	

Utilizzate sempre il device /dev/random quando generate delle chiavi poichè garantisce un buon grado di casualità.

Per prima cosa lo script effettua il flush del security association database (SAD) e del security policy database (SPD). Quindi crea le AH SAs e le ESP SAs. Il comando add aggiunge una security association al SAD e richiede un IP sorgente ed uno di destinazione, il protocollo IPsec (ah), l'SPI (0x200) e l'algortimo. L'algoritmo di autenticazione viene specificato con l'opzione -A (la cifratura utilizza -E, la compressione -C; la compressione di IP non è ancora supportata però). Dopo l'algoritmo deve essere inserita la chiave. Quest'ultima deve essere formattata in double-quoted “ASCII” o in esadecimale con prefisso 0x.

Linux supporta i seguenti algoritmi per AH ed ESP: hmac-md5 and hmac-sha, des-cbc and 3des-cbc. Tra poco sarà possibile anche utilizzare: simple (senza cifratura), blowfish-cbc, aes-cbc, hmac-sha2-256 and hmac-sha2-512.

spdadd aggiunge una security policy ad un SPD. Con queste è possibile specificare quali protocolli vadano protetti con IPsec e quali chiavi utilizzare. Il comando richiede l'indirizzo IP sorgente e destinazione del pacchetto da proteggere, il protocollo (la porta, nel nostro esempio any) e la policy da utilizzare (-P). La policy indica la direzione (in/out), l'azione da intraprendere (ipsec/discard/none), il protocollo (ah/esp/ipcomp), la modalità (transport) ed il livello (use/require).

Un file di configurazione simile va creato su entrambe le parti interessate alla comunicazione IPsec. Il nostro esempio funziona senza alcun cambiamento su 192.168.1.100, ma sono necessarie alcune modifiche per 192.168.2.100, per riflettere la diversa direzione dei pacchetti. La maniera più semplice per adattare la configurazione è scambiare le direzioni nelle security policies: sostituire -P in con -P out e vice versa. Qui di seguito un esempio:

#!/usr/sbin/setkey -f

# Configurazione per 192.168.2.100

# Flush SAD e SPD
flush;
spdflush;

# Attenzione: utilizzate queste chiavi solo per i test!
# Generate delle chiavi vostre!

# Le AH SAs utilizzano chiavi di 128 bit
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 \
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 \
0x96358c90783bbfa3d7b196ceabe0536b;

# Le ESP SAs utilizzano chiavi di 192 bit (168 + 24 parity)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc \
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc \
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;

# Security policies
spdadd 192.168.1.100 192.168.2.100 any -P in ipsec
           esp/transport//require
           ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P out ipsec
           esp/transport//require
           ah/transport//require;
	

Quando il file di configurazione è correttamente posizionato per entrambe le parti, è possibile renderlo operativo con il comando setkey -f /etc/ipsec.conf. Il corretto caricamento può essere verificato visualizzando il contenuto dei due database, SAD ed SPD:

# setkey -D
# setkey -DP
	  

Il setup attuale ricalca lo scenario in Figure 4.

Se si effettua un ping da una macchina all'altra il traffico viene cifrato e tcpdump mostra il seguente risultato:

12:45:39.373005 192.168.1.100 > 192.168.2.100: AH(spi=0x00000200,seq=0x1): 
ESP(spi=0x00000201,seq=0x1) (DF)
12:45:39.448636 192.168.2.100 > 192.168.1.100: AH(spi=0x00000300,seq=0x1): 
ESP(spi=0x00000301,seq=0x1)
12:45:40.542430 192.168.1.100 > 192.168.2.100: AH(spi=0x00000200,seq=0x2): 
ESP(spi=0x00000201,seq=0x2) (DF)
12:45:40.569414 192.168.2.100 > 192.168.1.100: AH(spi=0x00000300,seq=0x2): 
ESP(spi=0x00000301,seq=0x2)
	

Tunnel Mode

Il tunnel mode viene utilizzato quando le due parti sono anche dei gateway ed è in grado di proteggere il traffico tra le due reti (Figure 5). Il pacchetto IP originale viene cifrato ed incapsulato da un gateway e spedito all'altra parte. Quest'ultima estrae il pacchetto originale e lo consegna.

La configurazione delle security association e delle policies per il tunnel mode è simile al transport mode ed illustrata qui di seguito.

#!/usr/sbin/setkey -f

# Flush the SAD and SPD
flush;
spdflush;

# ESP SAs cifra utilizzando chiavi a 192 bit (168 + 24 parity)
# e chiavi a 128 per l'autenticazione
add 192.168.1.100 192.168.2.100 esp 0x201 -m tunnel -E 3des-cbc \
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 \
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

add 192.168.2.100 192.168.1.100 esp 0x301 -m tunnel -E 3des-cbc \
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df \
-A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

# Security policies
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
           esp/tunnel/192.168.1.100-192.168.2.100/require;

spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
	

Questo esempio utilizza il solo protocollo ESP. L'ESP è in grado di garantire integrità e confidenzialità. In questo caso l'ordine degli algoritmi ESP è importante. Prima si indica l'algoritmo di cifratura e la rispettiva chiave, quindi l'algoritmo di autenticazione e la chiave di quest'ultimo.

A differenza della realizzazione di IPsec su BSD una security association in Linux può essere utilizzata sia per il transport che per il tunnel mode. Il primo è il default, dunque qualora sia necessario il secondo, la security association deve essere definita con l'opzione -m tunnel.

Le security policies specificano ora gli IP delle reti protette: i pacchetti con quella sorgente o destinazione saranno protetti da IPsec. Nel tunnel mode è sempre necessario definire il tunnel e gli indirizzi IP delle due parti. Queste informazioni sono necessarie per riconoscere l'IPsec SA appropriata.

Preshared Keys

La forma più semplice di autenticazione utilizzando racoon sono le preshared keys. Devono essere definite nel file /etc/psk.txt, che non deve essere leggibile da utenti non privilegiati (chmod 400 /etc/psk.txt) ed utilizza la seguente sintassi:

# IPv4 Adressen
192.168.2.100          simple psk
5.0.0.1                0xe10bd52b0529b54aac97db63462850f3
# USER_FQDN
ralf@spenneberg.net    This is a psk for an email address
# FQDN
www.spenneberg.net     This is a psk
	

È organizzato in colonne. La prima contiene un identificativo della parte autenticata dalla psk. Tutto ciò che è scritto nella seconda colonna è la PSK.

La configurazione di racoon è piuttosto veloce. Una configurazione tipica è riportata qui di seguito, /etc/racoon.conf:

path pre_shared_key "/etc/psk.txt";

remote 192.168.2.100 {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo address 172.16.1.0/24 any address 172.16.2.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

Per prima cosa viene indicato dove racoon troverà le preshared keys. Quindi viene definita la configurazione per 192.168.2.100 ed i parametri da utilizzare per la prima fase della negoziazione con IKE. Il secondo paragrafo specifica quali parametri utilizzare per la security association. Questa parte potrebbe interessare un solo indirizzo IP o servirsi del generico comando anonymous al posto di un IP. Sempre qui vengono definiti gli algoritmi di cifratura, autenticazione e compressione per la SA. Devono essere specificati tutti e tre per non incorrere in errori all'avvio di racoon.

Il demone IKE racoon non inizia la negoziazione del tunnel appena avviato. Piuttosto attende fino a che il tunnel si rende necessario. Perche' questa segnalazione ci sia, il kernel deve sapere quando notificare racoon . Per ottenere ciò e' necessario specificare una security policy senza la corrispondente security association. Ogni qualvolta Linux dovrà proteggere un pacchetto in accordo con le security policies e quando nessuna security association e' disponibile richiamerà racoon e gli domanderà di instaurare le necessarie security association. Racoon inizierà le negoziazioni IKE e creerà le SA al termine. Linux potrà quindi spedire i pacchetti.

Per lo scenario descritto sono necessarie le seguenti policies su 192.168.1.100:

#!/usr/sbin/setkey -f
#
# Svuota SAD e SPD
flush;
spdflush;

# Crea le policies per racoon
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
           esp/tunnel/192.168.1.100-192.168.2.100/require;

spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
	

Dopo che le policies sono state caricate con setkey -f /etc/ipsec.conf racoon può essere lanciato. A scopo di test si può usare racoon -F -c /etc/racoon.conf. Di nuovo è necessario modificare la configurazione dell'altra parte perchè rifletta le differenti direzioni del traffico. Gli indirizzi IP nei files /etc/psk.txt, /etc/ipsec.conf e /etc/racoon.conf devono essere cambiati.

L'instaurazione del tunnel può essere seguita attraverso i log:

2003-02-21 18:11:17: INFO: main.c:170:main(): @(#)racoon 20001216 20001216
 sakane@kame.net
2003-02-21 18:11:17: INFO: main.c:171:main(): @(#)This product linked Open
SSL 0.9.6b [engine] 9 Jul 2001 (http://www.openssl.org/)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 127.0.0.1[500] use
d as isakmp port (fd=7)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 192.168.1.100[500]
 used as isakmp port (fd=9)
2003-02-21 18:11:37: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA r
equest for 192.168.2.100 queued due to no phase1 found.
2003-02-21 18:11:37: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new 
phase 1 negotiation: 192.168.1.100[500]<=>192.168.2.100[500]
2003-02-21 18:11:37: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Identit
y Protection mode.
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:38: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA es
tablished 192.168.1.100[500]-192.168.2.100[500] spi:6a01ea039be7bac2:bd288f
f60eed54d0
2003-02-21 18:11:39: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new p
hase 2 negotiation: 192.168.1.100[0]<=>192.168.2.100[0]
2003-02-21 18:11:39: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA establish
ed: ESP/Tunnel 192.168.2.100->192.168.1.100 spi=68291959(0x4120d77)
2003-02-21 18:11:39: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
 ESP/Tunnel 192.168.1.100->192.168.2.100 spi=223693870(0xd554c2e)
	

Certificati X.509

Racoon supporta l'utilizzo di certificati X.509 per l'autenticazione. Dovrebbero essere verificati attraverso una certificate authority (CA). La configurazione è simile alla PSK e differisce per le sole fasi di autenticazione:

path certificate "/etc/certs";

remote 192.168.2.100 {
        exchange_mode main;
        certificate_type x509 "my_certificate.pem" "my_private_key.pem";
	verify_cert on
        my_identifier asn1dn;
	peers_identifier asn1dn;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}

sainfo address 172.16.1.0/24 any address 172.16.2.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

Il certificato e la chiave privata sono conservati all'interno della directory /etc/certs. Il percorso viene specificato attraverso l'opzione path certificate, nel file di configurazione. I certificati e le revoche sono in formato PEM, così come sono stati generati da openssl. Per la creazione dei certificati si veda il capitolo dedicato qui di seguito. Se per la verifica si utilizza una CA ((verify_cert on è l'azione compiuta per default), il certificato di quest'ultima deve essere posto in questa stessa directory. È necesario rinominare il certificato o creare il link simbolico in modo che il file col certificato sia raggiungibile nel file system attraverso l'hash:

ln -s CAfile.pem `openssl x509 -noout -hash < CAfile.pem`.0
	

Se il certificato dovesse inoltre essere verificato attraverso un certificate revocation file (CRL), quest'ultimo dovrebbe risiedere nella stessa directory del certificato ed essere anch'esso raggiungibile attraverso l'hash:

ln -s CRLfile.pem `openssl crl -noout -hash < CAfile.pem`.r0
	

Quando si mantengono certificati e chiavi private bisogna tenere presente che racoon non è in grado di decifrare una chiave privata cifrata. Quindi la chiave deve essere conservata in chiaro. Se si è generata una chiave cifrata sarà necessario decifrarla:

# openssl rsa -in my_private_key.pem -out my_private_key.pem
read RSA key
Enter PEM pass phrase: password
writing RSA key
	

Roadwarrior

I Roadwarrior sono client che utilizzano IP dinamici per connettersi al gateway della VPN. In combinazione con racoon sorgono due diversi problemi:

• L'IP è sconosciuto e non può essere indicato nel file di configurazione o in /etc/psk.txt. È necessario trovare un altro modo per determinare l'identità del client. Nel caso delle pre-shared keys diviene necessario l'aggressive mode! La soluzione migliore è utilizzare i certificati X.509.

• Non è possibile creare una security policy per attivare racoon sino a quando l'indirizzo IP non sia noto. racoon dovrà dunque impostare quest'ultima e la security association a connessione già stabilita.

È necessario quindi effettuare diverse modifiche al file /etc/racoon.conf per rendere possibile quanto illustrato sopra:

path certificate "/etc/certs";

remote anonymous {
        exchange_mode main;
        generate_policy on;
        passive on;
        certificate_type x509 "my_certificate.pem" "my_private_key.pem";
        my_identifier asn1dn;
        peers_identifier asn1dn;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}


sainfo anonymous {
        pfs_group modp1024;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

L'opzione generate_policy on fa in modo che racoon crei la policy appropriata soltanto a connessione già stabilita. L'opzione passive on indica a racoon di attendere che la connessione inizi dall'esterno. Racoon non potrà iniziarne.

I cambiamenti più importanti sono comunque il parametro anonymous nella voce remote e in sainfo. Questo fa in modo che racoon accetti connessioni da qualsiasi host.