Dans la section précédente, le chiffrement était configuré pour utiliser simplement le partage de secrets. En d'autres termes, pour rester sécurisé, nous devons transférer la configuration de notre chiffrage à travers un tunnel sécurisé. Si nous avons configuré l'hôte distant par telnet, n'importe quel tiers pourrait avoir pris connaissance de notre secret partagé et, ainsi, notre configuration ne serait plus sûre.
De plus, puisque le secret est partagé, ce n'est pas un secret. L'hôte distant ne peut pas en faire grand chose, mais nous devons être sûrs d'utiliser un secret différent pour les communications avec tous nos partenaires. Ceci nécessite un grand nombre de clés. Pour 10 partenaires, nous devrions avoir au moins 50 secrets différents.
En plus du problème des clés symétriques, le renouvellement des clés est également nécessaire. Si un tiers écoute suffisamment le trafic, il peut être en position de retrouver la clé par rétro ingénierie. On peut s'en prémunir en modifiant la clé de temps en temps, mais ce processus a besoin d'être automatisé.
Un autre problème est que la gestion manuelle des clés décrite au-dessus impose de définir précisément les algorithmes et les longueurs de clés utilisées, ce qui nécessite une grande coordination avec l'hôte distant. Il serait préférable d'avoir la capacité à décrire une politique des clés plus large comme par exemple "Nous pouvons faire du 3DES et du Blowfish avec les longueurs de clés suivantes".
Pour résoudre ces problèmes, IPSec fournit l'Echange de Clé sur Internet (Internet Key Echange (IKE)) permettant d'automatiser l'échange de clés générées aléatoirement. Ces clés sont transmises en utilisant une technologie de chiffrement asymétrique négociée.
L'implémentation IPSec de Linux 2.5 fonctionne avec le démon IKE "KAME racoon". Depuis le 9 novembre, la version de racoon présente la distribution iptools d'Alexey peut être compilée en supprimant, au préalable #include <net/route.h> dans deux fichiers. Je fournis une version précompilée.
![[Note]](/images/note.png) |
Note |
|---|---|
|
L'Echange de Clé sur Internet (IKE) doit avoir accès au port UDP 500. Soyez sûr que iptables ne le bloque pas. |
Comme expliqué avant, la gestion automatique des clés réalise beaucoup d'opérations pour nous. Spécifiquement, il crée à la volée les Associations de Sécurité. Il ne configure cependant pas la politique pour nous, ce qui est le fonctionnement attendu.
Donc, pour bénéficier de IKE, configurez une politique, mais ne fournissez aucune Association de Sécurité. Si le noyau découvre qu'il y a une politique IPSec, mais pas d'Association de Sécurité, il va le notifier au démon IKE qui va chercher à en négocier une.
De nouveau, rappelons que la Politique de Sécurité spécifie CE QUE nous voulons tandis que l'Association de Sécurité décrit COMMENT nous le voulons. L'utilisation de la gestion automatique des clés nous permet de ne spécifier que ce que nous voulons.
Kame racoon possède un grand nombre d'options dont la plupart des valeurs par défaut sont corrects ; nous n'avons donc pas besoin de les modifier. Comme nous l'avons dit auparavant, l'opérateur doit définir une Politique de Sécurité, mais pas d'Associations de Sécurité. Nous laissons cette négociation au démon IKE.
Dans cet exemple, 10.0.0.1 et 10.0.0.216 sont encore une fois sur le point d'établir des communications sécurisées mais, cette fois, avec l'aide du démon racoon. Par soucis de simplification, cette configuration utilisera des clés pré-partagées, les redoutés 'secrets partagés'. Nous discuterons des certificats X.509 dans une section à part. Voir Section 7.2.3, « Gestion automatique des clés en utilisant les certificats X.509 ».
Nous allons à peu près rester fidèle à la configuration par défaut, qui est identique sur les deux hôtes :
path pre_shared_key "/usr/local/etc/racoon/psk.txt";
remote anonymous
{
exchange_mode aggressive,main;
doi ipsec_doi;
situation identity_only;
my_identifier address;
lifetime time 2 min; # sec,min,hour
initial_contact on;
proposal_check obey; # obey, strict or claim
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
sainfo anonymous
{
pfs_group 1;
lifetime time 2 min;
encryption_algorithm 3des ;
authentication_algorithm hmac_sha1;
compression_algorithm deflate ;
}
Beaucoup de paramètres. Je pense que l'on peut encore en supprimer pour se rapprocher de la configuration par défaut. Remarquons ici quelques éléments notables. Nous avons configuré deux sections "anonymous", ce qui convient pour tous les hôtes distants. Ceci va ainsi faciliter les configurations supplémentaires. Il n'est pas nécessaire d'avoir de sections spécifiques à une machine particulière, à moins que vous ne le vouliez vraiment.
De plus, la configuration précise que nous nous identifions grâce à notre adresse IP ('my_identifier address') et que nous pouvons faire du 3des, sha1 et que nous utiliserons une clé "pré-partagée" se trouvant dans psk.txt.
Dans le fichier psk.txt, nous avons configuré deux entrées qui sont différentes suivant les hôtes. Sur 10.0.0.11 :
10.0.0.216 password2
Sur 10.0.0.216 :
10.0.0.11 password2
Soyez sûr que ces fichiers sont la propriété de root, et qu'ils ont le mode 0600. Dans le cas contraire, racoon ne pourra faire confiance à leur contenu. Notez que ces fichiers sont symétriques l'un de l'autre.
Nous sommes maintenant prêt à configurer notre politique qui est assez simple. Sur l'hôte 10.0.0.216 :
#!/sbin/setkey -f
flush;
spdflush;
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
esp/transport//require;
spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
esp/transport//require;
Et sur 10.0.0.11 :
#!/sbin/setkey -f
flush;
spdflush;
spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
esp/transport//require;
spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
esp/transport//require;
Noter que ces politiques sont encore une fois symétriques.
Nous sommes maintenant prêt à lancer racoon ! Une fois lancé, au moment où nous essayons une connexion un telnet depuis 10.0.0.11 vers 10.0.0.216, ou l'inverse, racoon aura démarré la négociation :
12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA request for 10.0.0.11 queued due to no phase1 found. 12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500] 12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode. 12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: KAME/racoon 12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address. 12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680 12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2 negotiation: 10.0.0.216[0]<=>10.0.0.11[0] 12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established: ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b) 12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established: ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)
L'exécution de la commande setkey -D, qui nous montre les Associations de Sécurité, nous indique qu'elles sont en effet présentes :
10.0.0.216 10.0.0.11
esp mode=transport spi=224162611(0x0d5c7333) reqxml:id=0(0x00000000)
E: 3des-cbc 5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04
A: hmac-sha1 c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Nov 11 12:28:45 2002 current: Nov 11 12:29:16 2002
diff: 31(s) hard: 600(s) soft: 480(s)
last: Nov 11 12:29:12 2002 hard: 0(s) soft: 0(s)
current: 304(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 3 hard: 0 soft: 0
sadb_seq=1 pxml:id=17112 refcnt=0
10.0.0.11 10.0.0.216
esp mode=transport spi=165123736(0x09d79698) reqxml:id=0(0x00000000)
E: 3des-cbc d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a
A: hmac-sha1 41ccc388 4568ac49 19e4e024 628e240c 141ffe2f
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Nov 11 12:28:45 2002 current: Nov 11 12:29:16 2002
diff: 31(s) hard: 600(s) soft: 480(s)
last: hard: 0(s) soft: 0(s)
current: 231(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 2 hard: 0 soft: 0
sadb_seq=0 pxml:id=17112 refcnt=0
Nous avons les Politiques de Sécurité que nous avons nous-même configurées :
10.0.0.11[any] 10.0.0.216[any] tcp
in ipsec
esp/transport//require
created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002
lifetime:0(s) validtime:0(s)
spxml:id=3616 seq=5 pxml:id=17134
refcnt=3
10.0.0.216[any] 10.0.0.11[any] tcp
out ipsec
esp/transport//require
created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002
lifetime:0(s) validtime:0(s)
spxml:id=3609 seq=4 pxml:id=17134
refcnt=3
Si cela ne marche pas, vérifiez que tous les fichiers de configuration sont la propriété de root et qu'ils ne peuvent être lus que par celui-ci. Pour démarrer racoon en avant-plan, utilisez '-F'. Pour le forcer à lire un fichier de configuration à la place de celui précisé lors de la compilation, utilisez '-f'. Pour obtenir de nombreux détails, ajouter l'option 'log debug' dans le fichier racoon.conf.
Comme nous l'avons dit avant, l'utilisation de secrets partagés est compliquée car ils ne peuvent pas être facilement partagés et, une fois qu'ils le sont, ils ne sont plus secrets. Heureusement, nous avons la technologie de chiffrement asymétrique pour nous aider à résoudre ce problème.
Si chaque participant d'une liaison IPSec crée une clé publique et privée, des communications sécurisées peuvent être mises en place par les deux parties en publiant leur clé publique et en configurant leur politique.
Créer une clé est relativement facile, bien que cela exige un peu de travail. Ce qui suit est basé sur l'outil 'openssl'.
OpenSSL dispose d'une importante infrastructure de gestions des clefs, capable de gérer des clefs signées ou non par une autorité de certification. Pour l'instant, nous avons besoin de court-circuiter toute cette infrastructure et de mettre en place une sécurité de charlatan, et de travailler sans autorité de certification.
Nous allons tout d'abord créer une requête de certificat (certificate request) pour notre hôte, appelé 'laptop' :
$ openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \ laptop.private -outform PEM -out request.pem
Des questions nous sont posées :
Country Name (2 letter code) [AU]:NL State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:Delft Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced Routing & Traffic Control Organizational Unit Name (eg, section) []:laptop Common Name (eg, YOUR name) []:bert hubert Email Address []:ahu@ds9a.nl Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Vous avez toute liberté quant aux réponses. Vous pouvez ou non mettre le nom d'hôte, en fonction de vos besoins de sécurité. C'est ce que nous avons fait dans cet exemple.
Nous allons maintenant "auto signer" cette requête :
$ openssl x509 -req -in request.pem -signkey laptop.private -out \ laptop.public Signature ok subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \ Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl Getting Private key
Le fichier "request.pem" peut maintenant être éliminé.
Répétez cette procédure pour tous les hôtes qui ont besoin d'une clé. Vous pouvez distribuer le fichier '.public' en toute impunité, mais garder le fichier '.private' privé !
Une fois que nous avons les clés publiques et privées pour nos hôtes, nous pouvons indiquer à racoon de les utiliser.
Reprenons notre configuration précédente et les deux hôtes 10.0.0.11 ('upstairs') et 10.0.0.216 ('laptop').
Dans le fichier racoon.conf
présent sur 10.0.0.11, nous ajoutons :
path certificate "/usr/local/etc/racoon/certs";
remote 10.0.0.216
{
exchange_mode aggressive,main;
my_identifier asn1dn;
peers_identifier asn1dn;
certificate_type x509 "upstairs.public" "upstairs.private";
peers_certfile "laptop.public";
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 2 ;
}
}
Ceci indique à racoon que les certificats se trouvent dans
/usr/local/etc/racoon/certs/. De
plus, il contient des éléments spécifiques pour l'hôte distant
10.0.0.216.
La ligne 'asn1dn' indique à racoon que l'identification pour l'hôte local et distant doit être extraite des clés publiques. Ceci correspond à la ligne 'subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl' donné au-dessus.
La ligne certificate_type précise
l'emplacement des clés publiques et privées locales. La déclaration
peers_certfile
précise à racoon que la clé publique de l'hôte distant se trouve
dans le fichier laptop.public.
La section proposal reste inchangée par rapport à ce que nous avons vu plus tôt, à l'exception de authentification_method qui est maintenant rsasig, ce qui indique l'utilisation de clé RSA publique/privée pour l'authentification.
La configuration ajoutée sur 10.0.0.216 est presque identique, exception faite de l'habituelle symétrie :
path certificate "/usr/local/etc/racoon/certs";
remote 10.0.0.11
{
exchange_mode aggressive,main;
my_identifier asn1dn;
peers_identifier asn1dn;
certificate_type x509 "laptop.public" "laptop.private";
peers_certfile "upstairs.public";
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group 2 ;
}
}
Maintenant que nous avons ajouté ces éléments sur les deux
hôtes, la seule chose qui reste à faire est de mettre en place les
fichiers contenant les clés. La machine 'upstairs' doit avoir les
fichiers upstairs.private,
upstairs.public, et laptop.public placés dans /usr/local/etc/racoon/certs. Soyez sûr que le
répertoire est la propriété de root et qu'il possède les droits
0700. Dans le cas contraire, racoon pourrait refuser de lire le
contenu de ce répertoire.
La machine 'laptop' doit avoir les fichiers upstairs.private, upstairs.public, et laptop.public placés dans /usr/local/etc/racoon/certs. Autrement dit,
chaque hôte doit avoir ses propres clés publique et privée et, de
plus, la clé publique de l'hôte distant.
Vérifiez que la Politique de Sécurité est en place (exécutez la commande 'spdadd' vue dans Section 7.2.2, « Exemple »). Lancez alors racoon et tout devrait fonctionner.
Pour configurer des communications sécurisées avec un hôte distant, nous devons échanger des clés publiques. Bien qu'il ne soit pas nécessaire que la clé publique reste secrète, il est important d'être sûr que cette clé n'a pas été modifiée. En d'autres termes, vous devez être certain qu'il n'y a pas de 'man in the middle'. [NdT : 'man in the middle' est le nom d'une attaque qui consiste à se placer entre l'hôte émetteur et l'hôte de destination]
Pour faciliter ceci, OpenSSL propose la commande 'digest' :
$ openssl dgst upstairs.public MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1
La seule chose que nous devons faire est de vérifier que notre partenaire distant voit la même empreinte. Ceci peut être effectué en se rencontrant physiquement, ou par téléphone, en s'assurant que le numéro de téléphone de l'hôte distant n'a pas été envoyé dans le même courrier électronique que celui qui contenait la clé !
Une autre manière de faire ceci est d'utiliser un tiers de confiance qui exécute le service d'autorité de certification (Certificate Authority). Cette autorité de certification (CA) peut alors signer votre clé ; celle que nous avons nous-même créé au-dessus.