IPSec est un sujet compliqué. De nombreuses informations sont disponibles en ligne. Ce HOWTO se concentrera sur la mise en place et à l'explication des principes de base. Tous les exemples sont basés sur Racoon dont le lien est donné au-dessus.

	Note
	Certaines configurations iptables rejettent les paquets IPSec ! Pour transmettre IPSec, utilisez : iptables -A xxx -p 50 -j ACCEPT et 'iptables -A xxx -p 51 -j ACCEPT.

IPSec offre une version sécurisée de la couche IP (Internet Protocol). La sécurité dans ce contexte prend deux formes : le chiffrement et l'authentification. Une vision naïve de la sécurité ne propose que le chiffrement. On peut cependant montrer facilement que c'est insuffisant : il se peut que vous ayez une communication chiffrée, mais vous n'avez aucune garantie que l'hôte distant est bien celui auquel vous pensez.

IPSec supporte 'Encapsulated Security Payload' (Encapsulation Sécurisée de la Charge utile) (ESP) pour le chiffrage et 'Authentication Header' (Entête d'Authentification) (AH) pour authentifier le partenaire distant. Vous pouvez configurer les deux, ou décider de ne faire que l'un des deux.

ESP et AH s'appuient tous les deux sur des Associations de Sécurité (Security Associations (SA)). Une Association de Sécurité (SA) consiste en une source, une destination et une instruction. Un exemple simple d'Association de Sécurité (SA) pour l'authentification peut ressembler à ceci :

add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";

Ceci indique que le trafic allant de 10.0.0.11 vers 10.0.0.216 a besoin d'un En-tête d'Authentification (AH) qui peut être signé en utilisant HMAC-MD et le secret 1234567890123456. Cette instruction est repérée par l'identificateur SPI (Security Parameter Index) 15700, dont nous parlerons plus par la suite. Le point intéressant à propos des Associations de Sécurité (SA) est qu'elles sont symétriques. Les deux cotés de la conversation partagent exactement la même Association de Sécurité (SA), qui n'est pas recopiée sur l'hôte distant. Notez cependant qu'il n'y a pas de règles "d'inversion automatique". Cette Association de Sécurité (SA) décrit une authentification possible de 10.0.0.11 vers 10.0.0.216. Pour un trafic bidirectionnel, deux Associations de Sécurité (SA) sont nécessaires.

Un exemple d'Association de Sécurité (SA) pour le chiffrement ESP :

add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";

Ceci signifie que le trafic allant de 10.0.0.11 vers 10.0.0.216 est chiffré en utilisant 3des-cbc avec la clé 123456789012123456789012. L'identificateur SPI est 15701.

Jusqu'ici, nous avons vu que les Associations de Sécurité (SA) décrivent les instructions possibles, mais pas la politique qui indique quand ces SA doivent être utilisées. En fait, il pourrait y avoir un nombre arbitraire de SA presques identiques ne se différenciant que par les identificateurs SPI. Entre parenthèses, SPI signifie Security Parameter Index, ou Index du Paramètre de Sécurité en français. Pour faire vraiment du chiffrage, nous devons décrire une politique. Cette politique peut inclure des choses comme "utiliser ipsec s'il est disponible" ou "rejeter le trafic à moins que vous ayez ipsec".

Une "Politique de Sécurité" (Security Policy (SP)) typique ressemble à ceci :

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
 esp/transport//require
 ah/transport//require;

Si cette configuration est appliquée sur l'hôte 10.0.0.216, cela signifie que tout le trafic allant vers 10.0.0.11 doit être chiffré et encapsulé dans un en-tête d'authentification AH. Notez que ceci ne décrit pas quelle SA sera utilisée. Cette détermination est un exercice laissé à la charge du noyau.

En d'autres termes, une Politique de Sécurité spécifie CE QUE nous voulons ; une Association de Sécurité décrit COMMENT nous le voulons.

Les paquets sortants sont étiquetés avec le SPI SA ('le comment') que le noyau utilise pour le chiffrement et l'authentification et l'hôte distant peut consulter les instructions de vérification et de déchiffrement correspondantes.

Ce qui suit est une configuration très simple permettant le dialogue de l'hôte 10.0.0.216 vers l'hôte 10.0.0.11 en utilisant le chiffrement et l'authentification. Notez que le trafic de retour de cette première version est en clair et que cette configuration ne doit pas être déployée.

Sur l'hôte 10.0.0.216 :

#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
   esp/transport//require
   ah/transport//require;

Sur l'hôte 10.0.0.11, nous donnons les mêmes Associations de Sécurité (SA). Nous ne donnons pas de Politique de Sécurité :

#!/sbin/setkey -f
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

Avec la mise en place de la configuration ci-dessus (ces fichiers peuvent être exécutés si 'setkey' est installé dans /sbin), la commande ping 10.0.0.11 exécutée sur 10.0.0.216 va donner la sortie suivante avec tcpdump :

22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)
22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply

Notez que le paquet de retour provenant de 10.0.0.11 est en effet complètement visible. Le paquet ping émis par 10.0.0.216 ne peut évidemment pas être lu par tcpdump, mais celui-ci montre l'Index du Paramètre de Sécurité (SPI) de l'AH, ainsi que l'ESP, qui indique à 10.0.0.11 comment vérifier l'authenticité de notre paquet et comment le déchiffrer.

Quelques éléments doivent être mentionnés. La configuration ci-dessus est proposée dans de nombreux exemples d'IPSec, mais elle est très dangereuse. Le problème est qu'elle contient la politique indiquant à 10.0.0.216 comment traiter les paquets allant vers 10.0.0.11 et comment 10.0.0.11 doit traiter ces paquets, mais ceci n'INDIQUE pas à 10.0.0.11 de rejeter le trafic non authentifié et non chiffré !

N'importe qui peut maintenant insérer des données "spoofées" (NdT : usurpées) et entièrement non chiffrées que 10.0.0.1 acceptera. Pour remédier à ceci, nous devons avoir sur 10.0.0.11 une Politique de Sécurité pour le trafic entrant :

#!/sbin/setkey -f
spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
   esp/transport//require
   ah/transport//require;

Ceci indique à 10.0.0.11 que tout le trafic venant de 10.0.0.216 nécessite d'avoir un ESP et AH valide.

Maintenant, pour compléter cette configuration, nous devons également renvoyer un trafic chiffré et authentifié. La configuration complète sur 10.0.0.216 est la suivante :

#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
           esp/transport//require
           ah/transport//require;

Et sur 10.0.0.11 :

#!/sbin/setkey -f
flush;
spdflush;

# AH
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

# ESP
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";


spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
           esp/transport//require
           ah/transport//require;

Notez que, dans cet exemple, nous avons utilisé des clés identiques pour les deux directions du trafic. Ceci n'est cependant en aucun cas exigé.

Pour examiner la configuration que nous venons de créer, exécuter setkey -D, qui montre les SA ou setkey -DP qui montre les politiques configurées.