Chapitre 7. IPSEC: IP sécurisé à travers Internet

A ce jour, deux versions d'IPSEC sont disponibles pour Linux. FreeS/WAN, qui fût la première implémentation majeure, existe pour les noyaux Linux 2.2 et 2.4. Ce projet a un site officiel et également un site non officiel, qui est bien maintenu. FreeS/WAN n'a jamais été intégré dans le noyau pour un certain nombre de raisons. Celle qui est la plus souvent mentionnée concerne un problème "politique" avec les américains travaillant sur la cryptographie qui freinent son exportabilité. De plus, la mise en place de FreeS/WAN dans le noyau Linux est délicate, ce qui n'en fait pas un bon candidat pour une réelle intégration.

De plus, des personnes se sont inquiétées de la qualité du code. Pour configurer FreeS/WAN, de nombreuses documentations sont disponibles.

Une implémentation native d'IPSEC est présente dans le noyau à partir de la version Linux 2.5.47. Elle a été écrite par Alexey Kuznetsov et Dave Miller, qui se sont inspirés des travaux du groupe USAGI IPv6. Avec cette fusion, les CryptoAPI de James Morris deviennent également une partie du noyau, qui fait ainsi vraiment du cryptage.

Ce HOWTO ne documente que la version 2.5 d'IPSEC. FreeS/WAN est recommandé pour l'instant pour les utilisateurs de Linux 2.4. Faîtes cependant attention, dans la mesure où sa configuration est différente de l'IPSEC natif. Il y a maintenant une mise à jour qui permet au code FreeS/WAN de l'espace utilisateur de fonctionner avec l'IPSEC natif de Linux.

A partir du noyau 2.5.49, IPSEC fonctionne sans l'ajout de mises à jour supplémentaires.

[Note] Note

Les outils de l'espace utilisateur sont disponibles ici. Il y a plusieurs programmes disponibles ; celui qui est proposé dans le lien est basé sur Racoon.

Lors de la compilation du noyau, soyez sûr d'activer 'PF_KEY', 'AH' et tous les éléments de CryptoAPI !

[Avertissement] Avertissement

L'auteur de ce chapitre est un complet nigaud en ce qui concerne IPSEC ! Si vous trouvez les inévitables erreurs, envoyez un courrier électronique à Bert Hubert .

Tout d'abord, nous montrerons comment configurer manuellement une communication sécurisée entre deux hôtes. Une grande partie de ce processus peut être automatisée, mais nous le ferons ici à la main afin de comprendre ce qui se passe "sous le capot".

Passez à la section suivante si la seule gestion automatique des clés vous intéresse. Soyez cependant conscient que la compréhension de la gestion manuelle des clés est utile.

7.1. Introduction sur la gestion manuelle des clés

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] 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 : l'encryptage et l'authentification. Une vision naïve de la sécurité ne propose que le cryptage. On peut cependant montrer facilement que c'est insuffisant : il se peut que vous ayez une communication crypté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 cryptage 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 cryptage 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 cryptage, 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 encrypté 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 l'encryptage et l'authentification et l'hôte distant peut consulter les instructions de vérification et de décryptage 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 l'encryptage 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écrypter.

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 encrypté !

N'importe qui peut maintenant insérer des données "spoofées" (NdT : usurpées) et entièrement non crypté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 encrypté 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.