|
|
Documentation NetBSD :IPsec et NetBSD |
Cette page est en construction. Tous commentaires et suggestions sont les bienvenus.
Notez que, pour pouvoir l'utiliser, le noyau doit être re-configuré. Cette caractéristique n'étant pas incluse dans le noyau GENERIC.
Les logiciels utilisateur comprennent le code IPsec par défaut là où c'est possible. Il n'est donc pas utile de les recompiler même si vous passez d'un noyau avec IPsec à un sans IPsec.
Si votre système date d'avant 1.5, votre situation est la suivante :
NOTE : Nous utilisons parfois le mot «sécurité IP» dans un sens plus large comme pare-feu IP, filtrage de paquets et ainsi de suite.
En fait, IKE est optionnel. Vous pouvez manuellement configurer les clés secrètes de AH et ESP. Mais prenez garde à une chose : n'utilisez pas la même clé définitivement. Si vous utilisez la même clé pendant longtemps, la confidentialité aura de plus en plus de chances d'être compromise.
NOTE : la sécurité des protocoles IPsec repose sur la confidentialité de clé secrètes. Si les clés sont découvertes, les protocoles IPsec ne sont plus sûrs. Faites attention aux autorisations d'accès des fichiers de configuration, de la base de données des clés et de tout ce qui peut causer des fuites d'informations.
Il existe deux ensembles de RFC. Celui qui concerne l'ancien IPsec commence au RFC1825 et le nouveau au RFC2401 (NDT : vous trouverez certains RFC traduits en français sur abcdrfc.free.fr). Comme NetBSD reconnait les deux, utilisez préférenciellement le nouvel IPsec.
programmes utilisateur démon IKE
^ | socket AF_INET{,6} ^ | socket PF_KEY
========= | | =========================== | | ======== frontière noyau/ utilisateur
| v | v
couche transport TCP/UDP table de gestion de clés
^ | ^ | clé
| | | |
| v | v
entrée/sortie IP logique <-------> AH/ESP/IPcomp logique
^ |
| v
Pilotes réseau (ethernet)
[[mode transport]]
ma machine ======== autre machine
mode transport
paquets: [IP: moi->autre] données ESP utiles
<-----------------> chiffrées
[[mode tunnel]]
(a) (b) (c)
ma machine ---- ma passerelle VPN ======== autre passerelle VPN ---- autre machine
mode tunnel
paquets en (a) : [IP: moi->autre] données utiles
paquets en (b): [IP: mapassrl->autrepassrl] ESP [IP: moi->autre] données utiles
<----------------------------------> chiffré
paquets en (c): [IP: moi->autre] données utiles
La politique IPsec peut agir sur les paquets ou sur les sockets :
options IPSEC options IPSEC_ESP
Les outils utilisateur gèrent IPsec par défaut. Aucune compilation supplémentaire n'est donc nécessaire.
Vous pouvez éventuellement aussi installer racoon et/ou isakmpd.
#! /bin/sh # # les paquet ressemblent à : IPv4 ESP données utiles # le noeud est 10.1.1.1, l'autre machine 20.1.1.1 setkey -c <<EOF add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge"; add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef; spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use; EOF
Les deux premières lignes définissent les clés secrètes utilisées par ESP. Le nombre décimal, en quatrième position, est appelé SPI (security parameter index : index du paramètre de sécurité). Sa valeur sera inscrite dans les paquets ESP afin que la partie recevante puisse trouver la clé correspondante. Ce numéro doit être unique dans un noeud.
La dernière ligne configure la politique IPsec par paquet pour ce noeud. Les paquets envoyés par (10.1.1.1) à (20.1.1.1) seront chiffrés avec la clé définie dans le noyau. Il n'est pas interdit que des paquets non-chiffrés envoyés par 20.1.1.1 atteignent 10.1.1.1. Si vous voulez qu'ils soient rejetés, ajoutez la ligne suivante :
spdadd 10.1.1.1 20.1.1.1 any -P in ipsec esp/transport//require;
De l'autre côté (sur 20.1.1.1), la configuration est la suivante. Notez que les adresses doivent être inversées sur la ligne «spdadd» et non sur les lignes «add».
#! /bin/sh # # les paquet ressemblent à : IPv4 ESP données utiles # le noeud est 20.1.1.1, l'autre machine 10.1.1.1 setkey -c <<EOF add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge"; add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef spdadd 20.1.1.1 10.1.1.1 any -P out ipsec esp/transport//use; EOF
La syntaxe de la configuration de la politique est décrite dans ipsec_set_policy(3).
Lancez tcpdump(8) pour voir les paquets qui circulent sur le câble. S'ils sont chiffrés, il ne sera plus possible de les mettre sur écoute.
L'exemple ci-dessus utilise des clés lisibles. Leur utilisation est désencouragée par les spécifications car elles sont plus faciles à forcer que des clés binaires. Dans un contexte réel, mieux vaut donc utiliser des clés binaires.
La taille des clés est déterminée par les algorythmes. Pour 3des-cbc, par exemple, la clé DOIT faire 192 bits (24 octets). Si vous en indiquez une plus courte ou plus longue, setkey(8) vous renverra une erreur.
Si vous préférez utiliser d'autres algorythmes, la configuration est similaire. Voici un exemple avec rijndael-cbc (alias AES). rijndael-cbc utilise des clés de 128, 192 ou 256 bits.
#! /bin/sh # # les paquet ressemblent à : IPv4 ESP données utiles # le noeud est 10.1.1.1, l'autre machine 20.1.1.1 # rijndael-cbc avec clé de 128 bits setkey -c <<EOF add 10.1.1.1 20.1.1.1 esp 9876 -E rijndael-cbc "hogehogehogehoge"; add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use; EOF
#! /bin/sh # # les paquet ressemblent à : IPv4 AH données utiles # le noeud est 10.1.1.1, l'autre machine 20.1.1.1 setkey -c <<EOF add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge"; add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga"; spdadd 10.1.1.1 20.1.1.1 any -P out ipsec ah/transport//use; EOF
#! /bin/sh # # les paquet ressemblent à : IPv4 AH données utiles # le noeud est 10.1.1.1, l'autre machine 20.1.1.1 setkey -c <<EOF add 10.1.1.1 20.1.1.1 esp 9876 -E 3des-cbc "hogehogehogehogehogehoge"; add 20.1.1.1 10.1.1.1 esp 10000 -E 3des-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef; add 10.1.1.1 20.1.1.1 ah 9877 -A hmac-md5 "hogehogehogehoge"; add 20.1.1.1 10.1.1.1 ah 10001 -A hmac-md5 "mogamogamogamoga"; spdadd 10.1.1.1 20.1.1.1 any -P out ipsec esp/transport//use ah/transport//use; EOF
L'exemple qui suit considère la configuration réseau suivante. Les buts sont :
((( 10.0.1.0/24 ))) réseau VPN, branche Tokyo |10.0.1.1 passerelle 1 |20.0.0.1 |tunnel IPsec |20.0.0.2 passerelle 2 |10.0.2.1 ((( 10.0.2.0/24 ))) réseau VPN, le siège à New York
Voici la configuration de la passerelle 1.
#! /bin/sh # #Notez que le routage doit exister. Pour notre exemple : # route -n add -net 10.0.2.0 10.0.2.1 # route -n add 10.0.2.1 10.0.1.1 # les paquets ressemblent à : IPv4 ESP IPv4 données-utiles # le noeud est 10.0.1.1/20.0.0.1, l'autre machine 10.0.2.1/20.0.0.2 setkey -c <<EOF add 20.0.0.1 20.0.0.2 esp 13245 -E blowfish-cbc "blowfishtest.001" ; add 20.0.0.2 20.0.0.1 esp 13246 -E blowfish-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef; spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec esp/tunnel/20.0.0.1-20.0.0.2/require ; spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec esp/tunnel/20.0.0.2-20.0.0.1/require ; EOF
(contribution de Per Harald Myrvang)
Pour ce noeud (leaf node), utilisez :
#! /bin/sh # # le noeud est en 10.0.1.5, le routeur en 10.0.1.1 setkey -c <<EOF add 10.0.1.1 10.0.1.5 esp 1011 -E rijndael-cbc "rijndaeltest.001" ; add 10.0.1.5 10.0.1.1 esp 1012 -E rijndael-cbc 0xdeadbeefdeadbeefdeadbeefdeadbeef; spdadd 10.0.1.5/32 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.1.5-10.0.1.1/require; spdadd 0.0.0.0/0 10.0.1.5/32 any -P in ipsec esp/tunnel/10.0.1.1-10.0.1.5/require; EOF
Pour le routeur, intervertissez les mots «in» et «out» des commandes «spdadd».
Veuillez suivre les étapes soigneusement. Lancez tcpdump(8) pour voir comment les paquets sont échangés entre deux machines. Les statistiques de «netstat -sn» sont aussi utiles pour voir comment fonctionne la partie IPsec du noyau.
A# setkey -c spdadd A B any -P out ipsec esp/transport//require; spdadd B A any -P in ipsec esp/transport//require; ^D
B# setkey -c spdadd B A any -P out ipsec esp/transport//require; spdadd A B any -P in ipsec esp/transport//require; ^D
A# cat >/etc/racoon/psk.txt B spamspamspam ^D A# chmod 600 /etc/racoon/psk.txt B# cat >/etc/racoon/psk.txt A spamspamspam ^D B# chmod 600 /etc/racoon/psk.txt
# /usr/pkg/sbin/racoon -f /etc/racoon/racoon.conf -d 0xffffffff
A# ping -n B (vous commencerez à avoir des réponses au bout d'un certain délais) ^C A# setkey -D (vous verrez les clés échangées par racoon)
A# setkey -c spdadd A[110] A tcp -P out none; spdadd A A[110] tcp -P in none; spdadd A[110] 0.0.0.0/0 tcp -P out ipsec ah/transport//require; spdadd 0.0.0.0/0 A[110] tcp -P in ipsec ah/transport//require; ^D B# setkey -c spdadd B A[110] tcp -P out ipsec ah/transport//require; spdadd A[110] B tcp -P in ipsec ah/transport//require; ^D
/sbin/setkey -c < /etc/ipsec.confPar exemple, vous pouvez monter /usr par NFS chiffré. Le fichier /etc/ipsec.conf doit contenir les commandes valides de setkey(8), similaires à celles de l'exemple ci-dessus mais sans les sections setkey -c <
Depuis NetBSD 1.5, ipf(4) et le mode tunnel d'IPsec ne s'entendent pas. Veuillez ne pas configurer une machine avec des règles de filtrage ipf(4) et le mode tunnel de IPsec (comme «passerelle NAT et IPsec en même temps»). Le problème est dû au fait que ipf(4) regarde les paquets encapsulé et non-encapsulés, rendant impossible la mise en place de règles de filtrages.
Depuis février 2001, dans NetBSD-current, l'interaction ipf(4)/IPsec a été clarifiée de la façon suivante :
Malgré l'ordre d'exécution, prêtez attention aux points suivants :
Le diagramme suivant résume la nouvelle façon de faire.
Traitement du flux entrant :
programmes démon IKE
^ socket AF_INET{,6} ^ | socket PF_KEY
========= | ============================= | | ======== frontière noyau/utilisateur
| | v
couche transport, TCP/UDP table de gestion de clés
^ ^ | clé
| | |
| | v
+-----entrée/sortie IP <-------> AH/ESP/IPcomp
v ^ ^ |
périph | +----------------------+ packets IPsec décapsulés
tunnel |
| règles ipfilter
| ^
+------>|
|
Pilote réseau (ethernet)
Traitement du flux sortant :
programmes démon IKE
| socket AF_INET{,6} ^ | socket PF_KEY
=========== | =========================== | | ======== frontière noyau/utilisateur
v | v
couche transport, TCP/UDP table de gestion de clés
| ^ | clé
| | |
v | v
+---->entrée/sortie IP <------------> AH/ESP/IPcomp
| | (encapsulation par tunnel IPsec)
périph |
tunnel |
| règles ipfilter
| |
+---------+
v
Pilote réseau (ethernet)
L'interaction avec d'autres implémentations a été confirmée à diverses occasions. La page KAME's NetBSD Implementation Note liste les implémentations avec lesquelles l'interaction correcte a été confirmée par le passé. Notez cependant que, des deux cotés, le code a pu être changé depuis les tests et qu'il soit devenu incompatible. Il est aussi possible que l'implémentation de NetBSD et celle de l'interlocuteur n'interagisse que dans certaines configurations.
Si vous tentez de faire dialoguer NetBSD avec une implémentation différente, notez bien que les spécifications d'IPsec mettent en place énormément de boutons avec lesquels jouer. Vous devez configurer NetBSD et son interlocuteur exactement de la même façon afin qu'ils se comprennent.
L'API PF_KEY RFC2367 permet de manipuler la base de données des clés secrètes du noyau. La base de ces API est commune aux autres piles IPsec Unix et peut être compatible à certains degrés (par exemple, OpenBSD implémente aussi l'API PF_KEY). KAME l'étend d'une certaine façon, comme d'autres le font. Mais ces extensions ne sont pas compatibles avec d'autres piles IPsec (non KAME).
Il n'existe aucun document définissant une API de gestion de la politique IPsec. Nous ne pouvons donc attendre aucune compatibilité avec d'autres piles IPsec (non KAME) dans la gestion de la politique.
Il n'existe aucun standard définissant la syntaxe des fichiers de configuration. Il vous faudra les convertir si vous voulez les transférer vers ou depuis un autre système que NetBSD.
Comme NetBSD et FreeBSD ont tiré la base de leur code IPsec de son origine (KAME), il y a de grandes chances pour que les API soient compatibles. Notez cependant qu'il y a une différence entre le code IPsec de NetBSD et le code IPsec de FreeBSD, ceux-ci ayant été intégrés à des dates différentes. A l'heure où ces lignes sont écrites, les applications normales n'ont pas à se soucier de ces différences.
Durant le développement de NetBSD-current, entre NetBSD 1.4 et NetBSD 1.5, nous avons importé des portions de l'arborescence IPsec KAME. Ces imports rompent la compatibilité ascendante des API. Assurez-vous d'utiliser le code le plus récent si vous utilisez NetBSD-current entre NetBSD 1.4 et NetBSD 1.5. Avec NetBSD 1.5, nous assurerons une compatibilité binaire complète ou une vérification de numéro de version, dans les API de NetBSD 1.5.
|
|
