Création de tunnels sécurisés avec IPsec

1. Introduction

Au départ, l'Internet utilisait du texte clair et aucun chiffrement. Pendant longtemps, la suite de protocole TCP/IP n'a eu aucun mécanisme pour protéger cryptographiquement les données transportées. Le chiffrement a été ajouté à la couche application — la SSL (Secure Socket Layer) en est un exemple éminent. Le processus de conception d'IPv6a incorporé le chiffrement dans le protocole lui-même et l'interface IPsec (sécurité IP) a vu le jour. IPsec fournit le chiffrement et l'authentification au niveau paquet. Alors qu'IPsec est obligatoire pour IPv6, vous pouvez optionnellement l'utiliser avec IPv4. La série 2.6.x du noyau Linux a ajouté la fonctionnalité IPsec complète à l'arborescence source principale. Dans cet article, nous étudierons comment nous pouvons utiliser IPsec pour construire des chemins de données chiffrés entre machines en réseau.

2. Les parties d'IPsec

IPsec est composé d'un certain nombre de protocoles. Le chiffrement n'était pas le seul critère de conception. La protection contre les attaques de rejeu, la détection de la modification non autorisée de paquets et l'authentification correcte des partenaires de communication sont également inclus dans les exigences de conception. IPsec offre aussi des méthodes pour gérer les clefs utilisées pour la communication chiffrée. Les protocoles par nom ont la tâche suivante :

• AH (Authentication Header, en-tête d'authentification)

  Ce protocole protège contre les attaques de rejeu et s'assure que les partenaires de communication sont « corrects » (il vérifie l'authentification).

• ESP (Encapsulating Security Payload, encapsulation de charge utile de sécurité)

  Ce protocole fournit le chiffrement. Il protège également contre les attaques de rejeu et assure en sus l'authentification.

• IKE (Internet Key Exchange, échange de clés Internet)

  C'est un protocole hybride qui établit les politiques de sécurité entre deux points limites IPsec et fournit les clefs d'authentification pour des services tels qu'IPsec. Si vous fournissez les clefs manuellement, vous n'avez pas à utiliser IKE.

Les paquets AH et ESP transportent les données. Ce sont l'un et l'autre de nouveaux protocoles dont les numéros de protocole se trouvent dans /etc/protocols. AH et ESP sont gérés par le noyau, alors qu'IKE l'est par un programme de l'espace utilisateur.

3. Préparation du noyau et du système

Pour pouvoir utiliser IPsec, votre noyau doit avoir certaines options de code activées. La plupart des distributions GNU/Linux ont des noyaux offrant la fonction IPsec. Si vous voulez compiler le vôtre, n'oubliez pas de cocher les options suivantes :

• IPsec user configuration interface

• PF_KEY sockets

• IP: AH transformation

• IP: ESP transformation

• IP: IPComp transformation

• IP: tunnel transformation

Ces options se trouvent dans la section Networking -->Networking options. Vous devez également cocher certains chiffres cryptographiques ou la totalité dans le sous-menu de Cryptographic options. Il vous faudra au moins MD5, SHA1, HMAC, DES, Triple DES EDE et AES. N'oubliez pas que le chiffrement est géré par le noyau. Si celui-ci ne sait rien d'un chiffre, il ne peut l'utiliser. C'est important si vous voulez communiquer avec d'autres périphériques ou hôtes IPsec (tels que les machines MS Windows ou Cisco). Si vous souhaitez employer IPsec avec IPv6, alors vous veillerez à ce que les transformations IP sont définies pour IPv6 également. J'ai réalisé pour vous deux copies d'écran sur lesquelles vous pouvez voir le menu make menuconfig : la copie d'écran 1 et la copie d'écran 2. Si votre machine agit en tant que routeur, il se peut que vous envisagiez d'activer l'option IP: advanced router également. Le noyau considère les files d'attente de paquets différemment si vous cochez l'option advanced routing.

Dorénavant, notre noyau peut gérer IPsec. Il nous faut à présent certains outils pour le faire fonctionner, dont au moins le paquetage ipsec-tools. C'est le nom du projet et du paquetage Debian. Si nous souhaitons prendre en charge la gestion des clefs et IKE, un autre programme sera nécessaire. La pile IPsec Linux peut fonctionner de concert avec pluto, du projet Openswan, isakmpd, du projet OpenBSD ou racoon, du projet KAME. L'emploi d'IKE est optionnel cependant. Nous ferons appel à racoon dans nos exemples.

4. Mode manual keying, politiques, mode tunnel et mode transport

IPsec peut être utilisé pour lier des réseaux via des tunnels en utilisant ce qu'on appelle le mode tunnel. Dans la forme la plus simple, il peut également servir à chiffrer le trafic réseau entre deux ou plusieurs hôtes à l'aide du mode transport. Tout ce dont vous avez besoin pour ce faire, ce sont les clefs et un moyen d'indiquer au noyau quels sont les paquets à envoyer via IPsec. Les noyaux 2.6.x n'ont pas de périphérique spécial pour gérer les paquets IPsec. Tout est envoyé au travers des interfaces réseau déjà existantes. La SPD (Security Policy Database, base de données de politique de sécurité) décide quels sont les paquets que gérera IPsec. Pour pouvoir manipuler cette base de données, il vous faut la commande setkeys du paquetage ipsec-tools. Habituellement, vous préparez un fichier avec tous les paramètres et l'activez à l'aide de setkey -f /etc/setkey.conf. À titre d'exemple, supposons que vous souhaitiez activer IPsec entre les machines 10.0.0.23 et 10.0.0.42. Voici à quoi ressemble la politique pour informer le noyau :

#!/usr/sbin/setkey -f
#
# SPD pour 10.0.0.23
#
spdadd 10.0.0.23 10.0.0.42 any -P out ipsec
       esp/transport//require
       ah/transport//require;

spdadd 10.0.0.42 10.0.0.23 any -P in ipsec
       esp/transport//require
       ah/transport//require;

La première politique déclare que tout paquet provenant de 10.0.0.23 et sortant en direction de 10.0.0.42 doit être encapsulé dans des paquets IPsec. Le mode transport doit être employé. La politique est valide pour les paquets ESP et AH également (c'est pourquoi nous avons utilisé spdass deux fois). IPsec est obligatoire comme indiqué par le mot-clé require. S'il manque la bonne clé à l'un des hôtes ou s'il n'a pas initialisé sa SPD, il n'y aura pas de trafic parce qu'il ne peut pas être chiffré.

La seconde politique est la première, mais inversée. Les adresses IP sont permutées et la direction est changée de out à in.

Ainsi, le noyau sait quand utiliser IPsec. Il n'y a encore pas de clés. En-dehors de celle que j'ai mentionné à propos des contrôles d'authentification que les protocoles IPsec peuvent effectuer à notre place. Notre setkey.conf doit être étendu pour contenir ces informations également. setkey définit aussi la SAD (Security Association Database, base de données d'association de sécurité). La SAD indique au noyau qui sont nos voisins et comment nous pouvons nous assurer que nous ne nous adressons pas à un imposteur. L'extension de notre setkey.conf par les lignes suivantes permet l'authentification et le chiffrement. De plus, nous fournissons les clés pour chaque hôte.

# Éléments SAD AH avec des clés de 160 bits
add 10.0.0.23 10.0.0.42 ah 0x200 -A hmac-sha1 0x46915c30ed7e2465b42861b6ab19f2772813020c;
add 10.0.0.42 10.0.0.23 ah 0x300 -A hmac-sha1 0xc4dac594f8228e0b94a54758f7fbf2fdf4e37f3e;

# Éléments SAD ESP avec clés de 192 bits
add 10.0.0.23 10.0.0.42 esp 0x201 -E rijndael-cbc 0xa3993b3dfc41ef0a1aa8d168a8bf2c27e48249ac17b61e09;
add 10.0.0.42 10.0.0.23 esp 0x301 -E rijndael-cbc 0x8f6498928ba354bd45cfad147f54c67b3b742896b3bafc02;

Ici aussi, nous avons une ligne pour chaque direction. Les adresses IP sont inversées mais nous emplyons une clé différente pour chaque IP et chaque protocole. La longueur des bits de la clé correspond à l'algorithme d'authentification ou de chiffrment utilisé. Les commutateurs -A et -E indiquent l'algorithme à employer pour AH et ESP, respectivement. hmac-sha1 exige une longueur de clé de 160 bits ou 20 octets. rijndael-cbc peut être utilisé avec 128, 192 ou 256 bits. Dans l'exemple, ce sera 192 bits ou 24 octets. La page de man de setkey comporte une table avec toutes les valeurs possibles pour chaque algorithme pris en charge. Bear in mind that the kernel must a1lso have a module for the algorithm in its cryptographic options or else you cannot use this particular algorithm. The hexadecimal value behind the protocol name is called Security Parameters Index (SPI). The SPI identifies a set of parameters used for the IPsec connection in combination with the IP addresses involved. When doing manual keying, make sure that the SPIs are unique. Speaking of unique, make sure that your keys are unique and random. Never use any keys that have been published! I used Ralf's method from the IPsec HOWTO to extract the sample keys from the Linux random device.

# dd if=/dev/random count=24 bs=1 | xxd -ps
24+0 records in
24+0 records out
8f6498928ba354bd45cfad147f54c67b3b742896b3bafc02
24 bytes transferred in 0.000180 seconds (133298 bytes/sec)

Affectez à count la quantité d'octets souhaitée. La commande xxd utilisée pour convertir la sortie binaire du périphérique fait partie du paquetage vim.

5. Test du mode transport

Nous sommes à présent prêts à tester notre configuration. Pour ce faire, nous aurons besoin de full setkey.conf. JE n'ai ajouté que deux lignes qui effacent les SAD et SPD avant de charger de nouvelles règles, juste pour être sûrs.

flush;
spdflush;

Copiez-les dans vos hôtes. Faites attention, nous n'avons créé que le setkey.conf pour 10.0.0.23. Si vous utilisez ce fichier sur 10.0.0.42, vous devez permuter la politique pour la direction du flux de paquets (les mots-clés in et out pour la SPD). Faisons à présent appel à un shell root sur 10.0.0.23 et saisissons la commande suivante :

setkey -f /path/to/setkey.conf

Vérifiez si vous pouvez faire un ping sur 10.0.0.42. Cela ne devrait pas être possible, car nous avons demandé à 10.0.0.23 de communiquer avec 10.0.0.42 sur IPsec uniquement. Si vous lancez la commande setkey sur 10.0.0.42 également, vous devriez être en mesure de faire un ping sur 10.0.0.42 depuis 10.0.0.23. Jetez un coup d'œil à votre renifleur favori afin de vous assurer que le noyau ne fonctionne pas de manière non chiffrée. Si vous utilisez un ping ICMP (Internet Control Message Protocol), le renifleur ne devrait vous présenter que des paquets AH ou ESP chiffrés. Il en va de même pour les transmissions TCP et UDP.

La prochaine fois, nous configurerons un tunnel IPsec pour connecter deux réseaux différents et nous jetterons un coup d'œil à la création automatique de clés avec des certificats X.509.

6. Lecture complémentaire (en anglais)

• The official IPsec Howto for Linux

• An Introduction to IP Security (IPSec) Encryption

• IPsec-Tools

• KAME Project

• Openswan