4. Linux Kernel 2.5/2.6 utilizzando gli strumenti di KAME
Questo capitolo spiega l'utilizzo dello stack IPsec nativo in Linux dalla versione ≥2.5.47 e nei kernel 2.6.*. L'installazione e la configurazione dello stack IPsec è molto differente da FreeS/WAN e molto più simile alle diverse varianti di *BSD come FreeBSD, NetBSD e OpenBSD.
Illustrerò prima la configurazione e l'installazione del kernel e degli strumenti in user space. Quindi mostrerò come effettuare una connessione con i parametri impostati manualmente in transport mode ed in tunnel mode. Infine sarà presentata una connessione con negoziazione automatica dei parametri utilizzando preshared keys e certificati X.509. Per ultimo verrà trattato il supporto per i roadwarriors.
4.1. Installazione
L'installazione richiede un kernel 2.5.47 o successivi oppure un 2.6.*. I sorgenti del kernel possono essere prelevati da http://www.kernel.org. Dopo averli scaricati vanno decompressi, configurati e compilati.
cd /usr/local/src
tar xvjf /path-to-source/linux-<version>.tar.bz2
cd linux-<version>
make xconfig
make bzImage
make modules
make modules_install
make install
|
Questi sono i comandi più comuni per configurare e compilare un kernel Linux. In caso si necessiti di un setup particolare è opportuno fare riferimento al Kernel-Howto.
Durante la configurazione del kernel è importante attivare le seguenti opzioni:
Networking support (NET) [Y/n/?] y
*
* Networking options
*
PF_KEY sockets (NET_KEY) [Y/n/m/?] y
IP: AH transformation (INET_AH) [Y/n/m/?] y
IP: ESP transformation (INET_ESP) [Y/n/m/?] y
IP: IPsec user configuration interface (XFRM_USER) [Y/n/m/?] y
Cryptographic API (CRYPTO) [Y/n/?] y
HMAC support (CRYPTO_HMAC) [Y/n/?] y
Null algorithms (CRYPTO_NULL) [Y/n/m/?] y
MD5 digest algorithm (CRYPTO_MD5) [Y/n/m/?] y
SHA1 digest algorithm (CRYPTO_SHA1) [Y/n/m/?] y
DES and Triple DES EDE cipher algorithms (CRYPTO_DES) [Y/n/m/?] y
AES cipher algorithms (CRYPTO_AES) [Y/n/m/?] y
|
A seconda di quale versione si stia utilizzando potrebbe essere necessario abilitare anche il supporto per IPv6.
Compilato ed installato il kernel è necessario procurarsi gli strumenti in user space. Attualmente sono disponibili presso http://ipsec-tools.sourceforge.net/.Compilando a mano il pacchetto è necessario specificare la posizione degli header del kernel. Sono necessari gli header della versione 2.5.47 o successive.
./configure --with-kernel-headers=/lib/modules/2.5.47/build/include
make
make install
|
Ora tutto dovrebbe essere pronto per funzionare.
4.2. Connessione manuale usando setkey
Con connessione manuale (manual keyed connection) si intende che tutti i parametri necessari vengono forniti dall'amministratore. Il protocollo IKE non viene utilizzato per l'autenticazione delle due parti e la negoziazione di questi parametri. L'amministratore decide quale protocollo, algoritmo e chiave utilizzare per la creazione delle security association e popola di conseguenza il security association database (SAD).
4.2.1. 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 SA 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 SA 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 policy
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 SA e le ESP SA. 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 policy: 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 SA 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 SA 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 policy
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) |
4.2.2. 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 policy 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 SA 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 policy
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 policy 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.
4.3. Connessione automatizzata utilizzando racoon
Il demone IKE di KAME, racoon, è stato portato su Linux. È in grado di instaurare automaticamente le SA necessarie al funzionamento del protocollo IPsec. Racoon supporta l'autenticazione con preshared keys, con certificati X.509 e con Kerberos. Il demone può utilizzare il main mode o l'aggressive mode nella prima fase dell'IKE. In questo capitolo mostreremo la configurazione di racoon in main mode utilizzando preshared keys e certificati X.509 (ToDo: Kerberos). Infine verrà introdotto brevemente uno scenario relativo ad una configurazione di tipo roadwarrior.
4.3.1. 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 policy 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 policy su 192.168.1.100:
#!/usr/sbin/setkey -f
#
# Svuota SAD e SPD
flush;
spdflush;
# Crea le policy 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 policy 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 file /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) |
4.3.2. 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 |
4.3.3. 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.