9.5. Configuration de la sécurité du réseau

9.5.1.2.1. Restrictions d'accès avec tcpd

Le principe de fonctionnement du démon tcpd est le suivant : il s'intercale entre le super-démon inetd et les démons que celui-ci est supposé lancer lorsqu'un client le demande. Ainsi, il lui est possible d'effectuer des vérifications de sécurité primaires, principalement basées sur les adresses IP des clients.

Comme vous pouvez sans doute le constater dans le fichier /etc/inetd.conf de votre système, tcpd est lancé par inetd pour quasiment tous les services, et reçoit en paramètres de la ligne de commande le nom du démon à lancer si la machine cliente en a l'autorisation, ainsi que les paramètres à communiquer à ce démon. L'accès à quasiment tous les services est donc contrôlé par tcpd.

tcpd utilise les deux fichiers de configuration /etc/hosts.allow et /etc/hosts.deny pour déterminer si une machine a le droit d'accéder à un service donné. Le premier de ces fichiers indique quelles sont les machines autorisées à utiliser certains services locaux. Le deuxième fichier indique au contraire les machines qui ne sont pas considérées comme sûres et qui doivent se voir refuser toute demande de connexion sur les services locaux.

Le format de ces deux fichiers est identique. Il est constitué de lignes permettant de définir les règles d'accès pour certains démons. Chaque ligne utilise la syntaxe suivante :

démons : machines [: commande]

Une règle définie par une de ces lignes est utilisée dès qu'une des machines indiquées dans la liste des machines tente une connexion à l'un des services de la liste des services. Si la règle se trouve dans le fichier /etc/hosts.allow, la connexion est autorisée et le service est lancé par tcpd. Si elle se trouve dans le fichier /etc/hosts.deny, la connexion est systématiquement refusée. Si aucune règle n'est utilisée, la connexion est acceptée par défaut.

Les listes de machines peuvent contenir des noms de machines partiels, et utiliser des caractères génériques. Il est également possible d'interdire la connexion à toutes les machines d'un domaine en ne donnant que le nom de domaine (précédé d'un point). Enfin, des mots clés spéciaux permettent de représenter des ensembles de machines. Par exemple, le mot clé ALL représente toutes les machines et LOCAL représente toutes les machines du réseau local. Le mot clé ALL permet également de représenter l'ensemble des démons dans la liste des démons.

Par exemple, le fichier /etc/hosts.deny devrait contenir la ligne suivante :

# Exemple de fichier /etc/hosts.deny :
ALL : ALL

Cela permet de garantir que, par défaut, aucune demande de connexion n'est acceptée, ce qui est un comportement sain. Les machines ayant le droit de se connecter doivent être spécifiées au cas par cas dans le fichier /etc/hosts.allow, comme dans l'exemple suivant :

# Exemple de fichier /etc/hosts.allow :
telnetd, ftpd : LOCAL

Cela permet d'autoriser les connexions telnet et ftp pour toutes les machines du réseau local uniquement.

Vous trouverez de plus amples renseignements sur le fonctionnement de tcpd dans la page de manuel hosts_access(5).

9.5.1.2.2. Restrictions d'accès avec xinetd

Le super-démon xinetd intègre d'office un mécanisme de contrôle d'accès similaire à celui utilisé par tcpd. Grâce aux options only_from et no_access, il est possible de spécifier pour chaque service les machines qui sont autorisées à l'utiliser, ou inversement les machines qui doivent être explicitement rejetées.

Il faut toutefois prendre garde au fait que, comme pour tcpd, ne rien dire signifie accepter les connexions provenant de toutes les machines. La règle d'or est donc, encore une fois, de tout interdire par défaut et d'autoriser au compte-gouttes les accès aux services ouverts. Pour cela, il suffit d'ajouter la ligne suivante :

only_from =

Il faut ensuite redonner les droits sur les machines autorisées service par service. Ainsi, les connexions par telnet peuvent être autorisées sur le réseau local (supposé sûr) grâce à la ligne suivante :

only_from += 192.168.0.0/24 127.0.0.1

On prendra garde également au fait que xinetd implémente quelques services internes permettant de l'administrer par le réseau. Il est évident que ces services doivent être désactivés. Ces services sont respectivement les services servers, sercices et xadmin. Leur désactivation se fait classiquement en ajoutant la ligne suivante :

disabled = servers services xadmin

9.5.2.2.1. Principes de base de l'authentification SSH

La grande difficulté dans les mécanismes d'authentification est d'être capable de prouver son identité sans fournir suffisamment d'information pour que quelqu'un d'autre puisse se faire passer pour soi par la suite. La technique du mot de passe utilisée par les systèmes Unix est absolument insuffisante pour des communications réseau, car elle requiert justement de fournir ce mot de passe. Même si les mots de passe ne sont pas stockés en clair sur la machine (ce qui est la moindre des choses), il est possible de se faire passer pour une tierce personne. En effet, les mécanismes d'authentification comparent souvent une empreinte du mot de passe avec l'empreinte stockée dans les fichiers de définition des mots de passe, mais rien n'empêche un intrus de capter cette empreinte et de l'utiliser directement pour s'authentifier si l'on utilise la même technique en réseau. Il n'a même pas besoin de connaître le mot de passe en clair (cette technique est connue sous le nom d'attaque par « rejeu », car l'attaquant se contente dans ce cas de rejouer la séquence d'authentification). Une solution contre le rejeu est de demander à la personne que l'on cherche à authentifier de chiffrer un message aléatoire avec son mot de passe ou son empreinte, et de vérifier que le résultat qu'il renvoie est bien celui attendu, en chiffrant le même message de son côté. Cette technique est toutefois toujours vulnérable à l'attaque de l'homme du milieu, et elle souffre de l'énorme défaut que l'on doit stocker l'empreinte de son mot de passe sur tous les ordinateurs auxquels on désire se connecter. Cela multiplie d'autant les points de faiblesse : si un pirate s'introduit sur une seule machine, il obtient toutes les empreintes des mots de passe et peut donc se faire passer pour tout le monde !

SSH ne transmet donc ni les mots de passe, ni leurs condensés, en clair sur le réseau. Il établit d'abord un canal de communication chiffré à l'aide d'un des algorithmes d'échange de clef (la technique utilisée dépend de la version utilisée du protocole SSH). Une fois le canal chiffré établi, la machine serveur est authentifiée à l'aide de sa clef publique. Pour que cela fonctionne, il faut bien entendu que la clef publique de la machine serveur soit connue du client et ait été authentifiée comme étant bien celle de ce serveur. Inversement, le client peut être authentifié par le serveur. SSH fournit plusieurs possibilités pour cela, les deux plus courantes étant l'authentification par mot de passe et l'authentification par un algorithme à clef publique.

L'authentification par mot de passe est strictement la même que celle utilisée pour le login Unix classique, à la différence près que les informations du mot de passe sont transmises dans le canal chiffré, vers un serveur authentifié. La sécurité de ce mot de passe est donc garantie, et l'attaque de l'homme du milieu de fonctionne plus. Ce type d'authentification permet donc d'utiliser SSH exactement comme les commandes classiques rsh ou telnet. L'utilisation de SSH est donc complètement transparente pour les utilisateurs.

Cela dit, il est possible de faciliter encore plus l'authentification des clients tout en augmentant le niveau de sécurité, en utilisant également l'authentification par clef publique pour les utilisateurs. Dans ce mode d'authentification, chaque utilisateur dispose également d'un couple de clefs privée et publique. Les clefs publiques de ces utilisateurs sont diffusées dans les comptes des utilisateurs au niveau du serveur. Ainsi, il n'est plus nécessaire de fournir un mot de passe, car le serveur peut authentifier l'utilisateur du seul fait qu'il est le seul à connaître sa clef privée. La connexion est donc automatique (une fois le serveur correctement configuré, bien entendu) et aucun échange d'information sensible comme le mot de passe n'est réalisé (même si le fait que cet échange était réalisé dans un canal chiffré par SSH était déjà une bonne garantie).

Les clefs privées et publiques sont bien entendu stockées sur disque, dans les fichiers de configuration des serveurs et des clients. Il va de soi que si les clefs publiques peuvent être lues, il est impératif que les clefs privées ne soient lisibles que par leurs propriétaires. Les droits d'accès sur les fichiers de configuration doivent donc être fixées de manière correcte pour garantir la sécurité du système. En fait, le point faible du mécanisme d'authentification des clients est toujours au niveau des utilisateurs, qui peuvent perdre leur clef privée ou la communiquer à d'autres sans même savoir qu'ils font une erreur fondamentale (de la même manière qu'ils peuvent choisir un mot de passe trop facile à trouver ou simplement le communiquer à une tierce personne). C'est pour cela qu'il est possible de chiffrer les clefs privées avec un algorithme de chiffrement symétrique. L'utilisateur doit, dans ce cas, fournir une phrase clef à chaque fois qu'il désire réaliser une connexion SSH.

9.5.2.2.2. Compilation et installation d'OpentSSH

Comme nous l'avons dit plus haut, il est recommandé d'utiliser la dernière version d'OpenSSH, à savoir la version 3.7.1.p1. Il est probable que votre distribution fournisse une mise à jour sur son site, et il est recommandé d'utiliser ces mises à jours.

Si, toutefois, vous désirez effectuer l'installation à partir des fichiers sources, vous pourrez procéder comme suit. Il vous faudra récupérer l'archive des fichiers sources en premier lieu sur le site OpenSSH. Pour Linux, il faut prendre l'archive 3.7.1p1, le 'p' signifiant ici qu'il s'agit d'un portage des sources pour Linux. Une fois cela fait, vous pourrez exécuter la commande suivante dans le répertoire des sources :

./configure --prefix=/usr --sysconfdir=/etc/ssh --with-tcp-wrappers --with-pam

La compilation et l'installation en soi ne posent pas de problème particulier. Pour les réaliser, il vous suffira d'exécuter les deux commandes suivantes :

make
make install

9.5.2.2.3. Configuration d'OpenSSH côté serveur

OpenSSH utilise un démon nommé sshd pour prendre en charge les requêtes de connexion de la part des clients. Ce démon est à l'écoute des demandes de connexion et effectue les opérations d'authentification du serveur auprès des clients. Il vérifie également les droits du client avant de le laisser utiliser la connexion chiffrée.

Le démon sshd utilise un fichier de configuration général /etc/sshd_config et plusieurs fichiers contenant les clefs publiques et privées de la machine pour les différents protocoles cryptographiques utilisés par les clients. Les protocoles disponibles sont le protocole RSA pour la version 1 du protocole SSH, et les protocoles RSA et DSA pour la version 2. Comme il existe deux fichiers pour les clefs du serveur (un premier fichier lisible par tous les utilisateurs, pour la clef publique, et un fichier lisible uniquement par l'utilisateur root, pour la clef privée), il peut exister au total six fichiers de clefs. Ces fichiers sont nommés respectivement /etc/ssh_host_key et /etc/ssh_host_key.pub pour les clefs privées et publiques du protocole de version 1, et /etc/ssh_host_rsa_key, /etc/ssh_host_rsa_key.pub, /etc/ssh_host_dsa_key et /etc/ssh_host_dsa_key.pub respectivement pour les algorithmes RSA et DSA du protocole SSH de version 2.

Normalement, les fichiers de clefs du serveur ont été créés automatiquement lors de l'installation de SSH. Cependant, si vous installez SSH à partir d'une archive de distribution, ils peuvent ne pas être présents, et vous devrez générer ces clefs vous-même. Pour cela, il faut utiliser la commande ssh-keygen, dont la syntaxe est la suivante :

ssh-keygen [-t type]

Lorsque l'on invoque la commande ssh-keygen, celui-ci demande le chemin du fichier dans lequel la clef privée doit être écrite. Le fichier contenant la clef publique aura le même nom, mais portera l'extension .pub. Vous devez donc saisir le chemin du fichier correspondant au type de clef généré. ssh-keygen demande ensuite le mot de passe à utiliser pour le chiffrement de la clef privée. Dans le cas d'un serveur, il ne faut pas utiliser de mot de passe, car dans ce cas le démon sshd ne pourrait pas accéder à la clef privée de la machine. Il faut donc, dans ce cas, valider simplement sans rien taper.

Une fois les fichiers de clefs du serveur générés, vous pouvez vous intéresser au fichier de configuration sshd_config. Ce fichier de configuration contient un certain nombre d'options qui indiquent les paramètres que le démon doit utiliser. Vous trouverez ci-dessous un exemple de fichier de configuration :

# Paramètres de connexion :
Port 22
ListenAddress 0.0.0.0
KeepAlive yes

# Protocoles utilisables :
Protocol 2

# Chemin sur les fichiers de clefs :
HostKey /etc/ssh_host_rsa_key
HostKey /etc/ssh_host_dsa_key

# Paramètres des messages de traces :
SyslogFacility AUTH
LogLevel INFO

# On définit les modes d'authentification utilisables :

# Authentification par clef publique :
RSAAuthentication no
PubkeyAuthentication yes

IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no

# Authentification par mot de passe :
PasswordAuthentication no
PermitEmptyPasswords no

# Options générales :

# L'utilisateur root ne doit pouvoir se loguer qu'en local :
PermitRootLogin no

# Utilise le compte non privilégié sshd
# pour les communications réseau :
UsePrivilegeSeparation yes

# On n'autorise la connexion que pour les utilisateurs dont
# les fichiers de configuration sont correctement protégés :
StrictModes yes

# Encapsulation automatique du protocole X :
X11Forwarding yes
X11DisplayOffset 10

# Affichage des informations habituelles au login :
PrintMotd no
PrintLastLog yes

Comme vous pouvez le constater, un grand nombre d'options sont disponibles. Les options Port et ListenAddress permettent de définir l'adresse IP sur laquelle le démon sshd se mettra en attente de demandes de connexion, ainsi que le port TCP utilisé pour cela. L'adresse 0.0.0.0 signifie ici qu'il doit se mettre en attente sur toutes les adresses de la machine. L'option KeepAlive permet de demander au démon de vérifier régulièrement que la liaison est toujours valide, afin de fermer les connexions automatiquement en cas d'arrêt du client. L'option Protocol permet de spécifier les versions utilisables du protocole SSH. La version 1 étant obsolète, on spécifiera systématiquement la valeur 2 ici. L'option HostKey permet, comme son nom l'indique, de donner les noms des fichiers contenant les clefs pour les différents protocoles d'authentification. Les options SyslogFacility et LogLevel permettent d'indiquer le type et le niveau des messages de traces générés par le démon sshd dans le fichier de traces du système.

Viennent ensuite les options spécifiques aux différents modes d'authentification. Les options RSAAuthentication et PubkeyAuthentication permettent d'activer et de désactiver l'authentification par clef publique des clients, respectivement pour les protocoles SSH de version 1 et 2. Les options IgnoreRhosts, RhostsRSAAuthentication et HostbasedAuthentication permettent de contrôler un protocole d'authentification basé sur l'identité des machines. Ce type d'authentification n'a pas été présenté car il est extrêmement peu sûr, et il faut impérativement désactiver ces fonctionnalités. Enfin, les options PasswordAuthentication et PermitEmptyPasswords permettent d'activer ou de désactiver l'authentification par mot de passe. Vous êtes libre d'utiliser ou non ces fonctionnalités.

Le fichier de configuration peut également contenir des options complémentaires. Les plus importantes pour la sécurité sont sans doute PermitRootLogin et StrictModes, qui permettent d'interdire la connexion par le réseau à l'utilisateur root d'une part, et d'interdire la connexion aux utilisateurs qui n'ont pas bien fixé les droits d'accès sur leurs fichiers de configuration personnels dans leur compte local (il est donc impossible de garantir que ces fichiers n'ont pas été trafiqués par d'autres utilisateurs pour accéder à leur compte). L'option UsePrivilegeSeparation permet de demander au démon sshd de n'effectuer les communications réseau que dans le compte spécial sshd, compte auquel on n'affectera que le minimum de droits. Cette technique permet de protéger le système contre l'exploitation d'une éventuelle faille de sécurité dans le démon sshd. L'option X11Forwarding permet d'activer l'encapsulation automatique du protocole X et peut être relativement pratique. Le numéro de display auquel les utilisateurs devront connecter leurs applications sera alors décalé du nombre indiqué par l'option X11DisplayOffset. Cette option est utile pour éviter les conflits avec les serveurs X locaux. Vous trouverez de plus amples informations sur le protocole X11 et l'environnement graphique dans le Chapitre 10. Enfin, les options PrintMotd et PrintLastLog permettent de spécifier les informations affichées par le démon sshd lorsque la connexion des clients est acceptée. Il existe bien d'autres options, vous pourrez obtenir de plus amples renseignements dans la page de manuel du démon sshd.

9.5.2.2.4. Utilisation d'OpenSSH côté client

Les clients peuvent se connecter à un serveur SSH à l'aide de la commande ssh. Cette commande s'utilise exactement de la même manière que les commandes rsh ou rlogin. La syntaxe de la commande ssh est la suivante :

ssh [-l nom] machine [commande]

ssh nom@machine [commande]

Selon le mode d'authentification du client choisi par le serveur, il peut être nécessaire ou non de définir des clefs pour le client. Tout comme pour les clefs publiques et privées d'un serveur, la génération de ces clefs se fait à l'aide de la commande ssh-keygen. Cependant, contrairement à ce qui se passait pour le serveur, les chemins par défaut proposés pour stocker les clefs sont ici corrects, et il est vivement recommandé de saisir un mot de passe pour chiffrer la clef privée. Les fichiers de clefs générés par ssh-keygen sont les fichiers identity et identity.pub pour le protocole d'authentification RSA de la version 1 du protocole SSH, et les fichiers id_rsa, id_rsa.pub, id_dsa et id_dsa.pub respectivement pour les protocoles RSA et DSA de la version 2 du protocole SSH. Tous ces fichiers sont stockés dans le répertoire .ssh/ du répertoire personnel de l'utilisateur qui les génère. Il va de soi que les fichiers des clefs privées ne doivent pas être lisibles pour les autres utilisateurs, et que les fichiers des clefs publiques ne doivent pas pouvoir être écrits si l'on veut éviter qu'un usurpateur prenne notre place sur notre propre machine.

Afin de bénéficier de l'authentification des serveurs auxquels on se connecte, il faut placer les clefs publiqes de ces derniers dans le fichier .ssh/known_hosts. Si, lors d'une connexion à un serveur, la clef publique de celui-ci n'est pas connue, ssh vous le signalera. Il indiquera un message d'erreur indiquant que le serveur auquel on se connecte n'est pas forcément celui qu'il prétend être, et affiche un condensé de sa clef publique. Vous devrez vous assurer que ce condensé est bien celui de la clef publique du serveur auquel vous vous connectez, et ce par un moyen sûr (déplacement physique et connection en local par exemple). Si vous acceptez cette clef, ssh la placera pour vous dans votre fichier known_hosts, ce qui vous permettra de vous connecter par la suite en toute quiétude. Attention, le fichier known_hosts ne doit pas être accessible en écriture aux autres utilisateurs, car dans ce cas un pirate pourrait capter toutes vos communications !

Si le mode d'authentification utilisé est le mot de passe, ssh vous demandera de saisir le mot de passe du compte distant. Dans ce cas, ssh se comporte exactement comme rsh, à ceci près que votre mot de passe ne circulera pas en clair sur le réseau (quel progrès !).

Si, en revanche, le mode d'authentification utilisé est une authentification par clef publique, alors vous devrez avoir défini vos clefs privées et publiques. Pour que le démon sshd de la machine distante accepte la connexion, vous devrez placer vos clefs publiques dans le fichier authorized_keys du répertoire ./ssh/ du répertoire du compte distant. Cela permettra au démon sshd de s'assurer que c'est bien vous qui vous connectez. Attention, le fichier authorized_keys ne doit pas être accessible en écriture, faute de quoi un autre utilisateur de la machine distante pourrait se connecter en votre nom. Il est également impératif de réaliser l'écriture soi-même dans ce fichier par un moyen sûr (déplacement physique). En aucun cas la communication de votre clef publique à l'administrateur distant ne pourra être considérée comme un moyen sûr pour écrire cette clef : en effet, un pirate pourrait tout aussi bien lui demander d'écrire sa propre clef dans votre fichier !

Vous constaterez qu'un certain nombre de précautions doivent être prises pour les manipulations de clefs. Comme il l'a déjà été indiqué plus haut, le point faible est bel et bien l'authentification des clients. Cela concerne en premier lieu le client bien entendu, dont le compte peut être piraté, mais c'est aussi un trou de sécurité énorme pour le serveur, car une fois le loup dans la bergerie, il peut faire beaucoup de dégâts et chercher à accroître ses droits (jusqu'à devenir root) par d'autres techniques.

9.5.2.2.5. Création d'un tunnel SSH

L'un des principaux avantages de SSH est qu'il est possible de l'utiliser pour encapsuler n'importe quel protocole réseau TCP dans le canal de communication d'une connexion sécurisée. Un tel canal est communément appelé un « tunnel », en raison du fait qu'il est utilisé par les informations sensibles pour traverser un réseau non sûr. Grâce aux tunnels SSH, il est possible d'utiliser tous les protocoles classiques sans avoir à s'inquiéter de la confidentialité des informations transmises. SSH permet même de réaliser cette opération automatiquement pour le protocole X du système de fenêtrage X Window, ce qui est très commode si l'on désire afficher localement les fenêtres graphiques des programmes lancés sur le serveur.

Encapsuler le protocole X dans SSH est donc extrêmement aisé. En effet, il suffit simplement de donner la valeur « yes » à l'option X11Forwarding dans le fichier de configuration du serveur /etc/sshd_config et dans le fichier de configuration des clients (les valeurs par défaut pour tous les utilisateurs peuvent être définies dans le fichier de configuration /etc/ssh_config et être redéfinies par chaque utilisateur dans le fichier config de leur répertoire .ssh/). Si ces options sont activées, SSH se charge de fixer la variable d'environnement DISPLAY de la machine distante à un serveur X virtuel de cette machine. Les programmes X se connectent alors à ce serveur, et celui-ci effectue automatiquement le transfert des communications vers le serveur X du client. Il ne faut donc pas, quand on utilise SSH, modifier manuellement la variable d'environnement DISPLAY. Vous trouverez plus d'information sur X Window dans le Chapitre 10.

Pour les autres protocoles, les opérations ne sont pas réalisées automatiquement par SSH. Il faut donc établir un réseau privé virtuel manuellement. Le principe est le suivant : les programmes clients sont paramétrés pour se connecter sur un port local différent de celui utilisé habituellement pour leur protocole. Ainsi, ils ne s'adressent pas directement au serveur distant, mais plutôt à un proxy local établi par SSH pour l'occasion. Ce proxy établit un canal de communication chiffré avec le démon sshd de la machine distante. Toutes les informations du protocole encapsulé passent alors par le canal chiffré, et le démon sshd de la machine distante retransmet ces informations au service distant auquel le client devait se connecter.

Tout ce mécanisme ne fonctionne que parce qu'il est possible de rediriger les clients sur un port réservé par SSH sur leur machine locale. Cette redirection peut être initiée aussi bien du côté serveur que du côté client, lors de la connexion. Du côté du client, la redirection de port peut être réalisée avec la commande suivante :

ssh -Llocal:serveur:port machine [commande]

Il faut bien comprendre que cette redirection se fait en plus de la connexion SSH, et que la syntaxe donnée ci-dessus ouvre une connexion sur la machine distante (ou exécute la commande spécifiée en paramètre, s'il en est spécifiée une). Si l'on désire simplement établir un tunnel, on peut refermer la session juste après avoir lancé le programme qui doit utiliser ce tunnel. En effet, SSH maintient le tunnel ouvert tant qu'un programme détient une connexion sur le port redirigé. On peut aussi exécuter une commande sleep sur un délai arbitraire, qui permettra de se connecter sur le port redirigé et qui se terminera automatiquement.

Du côté serveur, la syntaxe est similaire. Cette fois, la commande permet d'indiquer le port que le client devra utiliser pour accéder à un service non sécurisé du serveur. La syntaxe à utiliser est la suivante :

ssh -Rport:client:local machine [commande]

9.5.2.3.1. Fonctionnement d'IPSec

IPSec définit des protocoles complémentaires permettant d'encapsuler les données transférées dans les paquets IP et assurant les services d'authentification et de confidentialité. Le protocole AH (abréviation de l'anglais « Authentication Header ») permet, comme son nom l'indique, d'assurer que les machines sont bien celles qu'elles prétendent être. Cela permet de supprimer tous les risques d'attaque de l'homme du milieu. Le protocole AH permet également d'assurer l'intégrité des données. En revanche, il n'en assure pas la confidentialité. Le protocole ESP (abréviation de l'anglais « Encapsulating Security Payload ») permet d'assurer cette confidentialité. En revanche, contrairement à ce que de nombreuses documentations affirment, il ne permet pas d'assurer l'authenticité des interlocuteurs, ce qui fait que la confidentialité peut être brisée par une attaque de l'homme du milieu. Il est donc nécessaire d'utiliser les deux protocoles si les interlocuteurs ne sont pas authentifiés de manière physique. Ces deux protocoles permettent également de prévenir les attaques par rejeu au niveau protocolaire, car ils utilisent un numéro de séquence dont la prédétermination est très difficile pour chaque paquet échangé.

AH et ESP peuvent être utilisées dans deux modes différents : le mode transport et le mode tunnel. Le mode transport est le mode de communication natif, dans lequel les en-têtes des protocoles AH et ESP sont insérés entre l'en-tête IP et ses données. De ce fait, les protocoles de haut niveau sont simplement encapsulés dans les protocoles AH et ESP. Le mode tunnel, quant à lui, permet de créer un réseau virtuel complet, en encapsulant la communication entre les interlocuteurs dans un canal chiffré. Ce sont donc les paquets IP de la communication qui sont eux-mêmes encapsulés dans les protocoles AH et ESP.

IPSec utilise les algorithmes de cryptographie symétriques pour assurer ces fonctionnalités. Par exemple, l'authenticité des machines et l'intégrité des données sont garanties par le protocole AH grâce à la génération de condensés cryptographiques paramétrés par une clef privée. Seule les machines partageant cette clef peuvent donc communiquer avec ce protocole, et toute modification des données serait détectée lors de la vérification de la signature. De même, ESP assure la confidentialité des données en les chiffrant avec un algorithme de chiffrement à clef privée.

Chaque canal de communication IPSec peut utiliser ses propres paramètres. Bien entendu, il est hors de question de transférer ces paramètres (et encore moins les clefs privées utilisées !) dans chaque paquet IP ! IPSec identifie donc ces paramètres par un numéro d'identification (appelé «« Security Parameter Index », « SPI » en abrégé), grâce auquel chaque interlocuteur peut retrouver les paramètres de la connexion chiffrée. L'association entre le SPI et ces paramètres est appelée une « SA » (abréviation de l'anglais « Security Association »). Les associations de sécurité sont stockées sur chaque machine dans une base de données que l'on appelle la SAD (de l'anglais « SA Database »).

Les associations de sécurité ne permettent que de définir la manière dont les communications doivent être protégées. Cela dit, une machine n'est pas obligée de chiffrer toutes ses connexions, et l'on peut parfaitement vouloir ne chiffrer les communications qu'entre deux machines, ou que pour certains protocoles. Il est donc également nécessaire de définir quelles communications doivent être chiffrées. Cela se fait grâce à une politique de sécurité (« Security Policy » en anglais, « SP » en abrégé). Les politiques de sécurité sont également stockées dans une base de données sur chaque machine, base de données que l'on appelle la « SPD » (abréviation de « SP Database »).

Bien entendu, la définition des clefs secrètes, des associations et des politiques de sécurité peut devenir une opération très lourde sur de grands réseaux. En effet, il est nécessaire de définir des clefs privées pour chaque couple de machines. Par conséquent, un protocole de gestion des clefs et des associations de sécurité a été défini pour automatiser l'établissement des connexions. Ce protocole est le protocole « ISAKMP » (abréviation de l'anglais « Internet Security Association and Key Management Protocol »). Comme SSH, ce protocole s'appuie sur les algorithmes de cryptographie asymétriques pour échanger les clefs privées et définir les associations de sécurité de manière sûre avec des machines authentifiées. Ainsi, grâce à ce protocole, seules les politiques de sécurité et les couples de clefs publiques / privées des machines doivent être définis. Les associations de sécurité et les clefs privées n'ont plus à être manipulées.

9.5.2.3.2. Configuration manuelle d'IPSec en mode transport

La configuration manuelle d'IPSec reste intéressante, car elle permet de bien saisir la manière dont les opérations se déroulent. Elle se fait simplement en définissant les SAs et les SPs sur chaque machine, à l'aide de l'outil setkey. Cet outil peut être retrouvé sur le site Web consacré à IPSec.

Les associations et les politiques de sécurité peuvent être spécifiées directement en ligne de commande si l'on lance setkey avec l'option -c. Toutefois, la manière la plus simple de charger les associations et les politiques dans les bases de données du système est de les définir dans un fichier de configuration et de demander à setkey de le lire en lui fournissant le chemin sur ce fichier à l'aide de l'option -f. En général, ce fichier de configuration est placé dans le répertoire /etc/ et se nomme ipsec.conf.

Les commandes acceptées par setkey sont nombreuses. Le fichier de configuration d'exemple suivant vous en donnera un apperçu :

#!/usr/sbin/setkey -f

# Vide la base de données des SAs :
flush;

# Vide la base de données des SPs :
spdflush;

# Définit les SAs pour le protocole AH :
# add source dest protocole SPI algo clef
add 170.20.57.31 170.20.58.40 ah 0x200 \
      -A hmac-md5 0x848255320c7fd11b6082f9628f078af7;
add 170.20.58.40 170.20.57.31 ah 0x201 \
      -A hmac-md5 0xcd23ef4b73ea54b626d16092293a298a;

# Définit les SAs pour le protocole ESP :
# add source dest protocole SPI algo clef
add 170.20.57.31 170.20.58.40 esp 0x300 \
      -E 3des-cbc 0xe6933d365096e13be514ea1d881d87371100b15119e2ffb9;
add 170.20.58.40 170.20.57.31 esp 0x301 \
      -E 3des-cbc 0xb2b630c9e9692c36d248b7206bda17c47f772f96290ac05f;

# Définit les politiques :
# spadd source dest protocole -P politique
# politique = direction action regles
# regle = ipsecp/mode/options/niveau
# options = règles de définition des tunnels
# niveau = use ou require
spdadd 170.20.57.31 170.20.58.40 any -P out ipsec
        esp/transport//require
        ah/transport//require;

spdadd 170.20.58.40 170.20.57.31 any -P in ipsec
        esp/transport//require
        ah/transport//require;

Ce fichier permet de décrire les associations de sécurité utilisées pour communiquer entre deux machines d'adresses 170.20.57.31 et 170.20.58.40, ainsi que la politique de sécurité de la machine 170.20.57.31. Bien que largement commenté, ce fichier requiert quelques explications complémentaires.

Tout d'abord, la première ligne permet de considérer ce fichier comme un fichier exécutable, dont l'interpréteur est la commande setkey elle-même. Les deux lignes suivantes permettent de vider les bases de données contenant les associations et les politiques de sécurité. Attention, cela a pour conséquence de désactiver complètement IPSec, les services réseaux qui doivent être protégés ne doivent donc pas être lancé lorsque ce fichier est interprété.

Viennent ensuite les définitions des associations de sécurité utilisées par les protocoles AH et ESP. Ces associations doivent être définies strictement de la même manière sur les deux machines pour lesquelles la liaison est sécurisée. Elles sont simplement ajoutées à la base de données des associations à l'aide de la commande add de setkey. Cette commande prend en paramètre les adresses IP source et destination des machines intervenant dans la communication sécurisée, suivies du nom du protocole pour lequel l'association est définie (à savoir, ah ou esp), suivi de l'identifiant de l'association (le « SPI »), et pour finir des options relatives au protocole.

Les options des protocoles dépendent évidemment de ceux-ci. Le protocole AH n'accepte que l'option -A, qui permet de spécifier l'algorithme d'authentification à utiliser (ici, l'algorithme MD5). ESP quant à lui peut également accepter l'option -E, qui permet de spécifier un algorithme de chiffrement des données. Il est inutile de spécifier un algorithme d'authentification pour ESP si l'on utilise également le protocole AH, comme c'est le cas ici. Il est également possible de n'utiliser que le protocole ESP et de lui demander de réaliser à la fois l'authentification et le chiffrement des communications. Toutefois, comme on l'a dit plus haut, cela nécessite d'avoir déjà une authentification des machines (ce qui n'est pas assuré en général, une adresse IP pouvant être vampirisée par un pirate).

Les algorithmes utilisables sont variés et dépendent des options que vous avez spécifiés dans la configuration du noyau. Ceux utilisés ici sont relativement fréquents, à savoir MD5 pour l'authentification et le triple DES pour le chiffrement. Vous remarquerez que ces algorithmes ont besoin d'une clef secrète pour fonctionner. Dans le fichier d'exemple précédent, cette clef est spécifiée en hexadécimal (c'est-à-dire en base 16). La taille des clefs dépend de l'algorithme utilisé. Pour MD5, il vous faudra utiliser une clef de 16 octets, et pour le triple DES, une clef de 24 octets. Les clefs de cet exemple ont été générées par lecture du fichier spécial de périphérique /dev/random, dont le but est de fournir des données aléatoires, avec la commande suivante :

dd if=/dev/random count=n bs=1 | xxd -ps

Comme il l'a déjà été indiqué, définir les associations de sécurité ne suffit pas pour sécuriser les communications. En effet, il est également nécessaire de définir la politique de sécurité. Cela est réalisé à l'aide de la commande spdadd. Cette commande prend en paramètre l'adresse source et l'adresse destination, le protocole ou le port qui doit être sécurisé (any signifiant que toutes les communications doivent être sécurisées), et la politique de sécurité elle-même. Cette politique permet d'indiquer la direction du trafic réseau (in signifiant le trafic entrant et out signifiant le trafic sortant), et ce que l'on doit faire des données. L'option ipsec indique qu'elles doivent être sécurisées par IPSec. L'option discard permet d'interdire le trafic entre les machines, et l'option none permet d'autoriser ce trafic et de laisser les communications se faire classiquement.

Si l'on indique qu'IPSec doit être utilisé, il faut indiquer, respectivement pour AH et ESP, le mode de fonctionnement (ici, transport) et le niveau de sécurité exigé. La valeur utilisée est généralement require, ce qui permet de n'accepter les communications que si elles se font par IPSec. Vous trouverez le détail des autres options dans la page de manuel de setkey

Ainsi, la première ligne spdadd du fichier donné en exemple ci-dessus indique que tout le trafic sortant de 170.20.57.31 et allant vers 170.20.58.40 doit être encapsulé en mode transport dans les protocoles AH et ESP, en utilisant les associations de sécurité définies précédemment. De même, la deuxième ligne spdadd indique que tout le trafic entrant dans 170.20.57.31 et en provenance de 170.20.58.40 doit être sécurisé par IPSec.

Vous constaterez que les adresses IP sources et destination sont inversées dans les deux commandes, parce que la direction indiquée est inversée et que l'on ne peut pas définir, sur la machine 170.20.57.31, les règles à appliquer sur la machine 170.20.58.40. Bien entendu, sur la machine 170.20.58.40, ces directions devront être échangées. Ainsi, pour reprendre l'exemple, les lignes permettant de définir la politique de sécurité sur cette machine doivent être les suivantes :

# Définit la politique de sécurité sur 170.20.58.40 :
spdadd 170.20.57.31 170.20.58.40 any -P in ipsec
        esp/transport//require
        ah/transport//require;

spdadd 170.20.58.40 170.20.57.31 any -P out ipsec
        esp/transport//require
        ah/transport//require;

9.5.2.3.3. Configuration manuelle d'IPSec en mode tunnel

La configuration d'IPSec en mode tunnel est similaire à celle utilisée pour le mode transport. Elle est toutefois légèrement plus compliquée, puisqu'il est nécessaire de spécifier les adresses des passerelles entre lesquelles le tunnel sera établi. Le fichier de configuration suivant donne un exemple de définition de tunnel IPSec utilisant les adresses 192.168.20.1 et 192.168.20.2, entre deux machines d'adresses 170.20.57.31 et 170.20.58.40 :

#!/usr/sbin/setkey -f

# Vide la base de données des SAs :
flush;

# Vide la base de données des SPs :
spdflush;

# Définit les SAs pour les en-têtes :
# add source dest protocole SPI algo clef
add 170.20.57.31 170.20.58.40 ah 0x200 -m tunnel -A hmac-md5 0x848255320c7fd11b6
082f9628f078af7;
add 170.20.58.40 170.20.57.31 ah 0x201 -m tunnel -A hmac-md5 0xcd23ef4b73ea54b62
6d16092293a298a;

# Définit les SAs pour les paquets :
# add source dest protocole SPU algo clef
add 170.20.57.31 170.20.58.40 esp 0x300 -m tunnel -E 3des-cbc 0xe6933d365096e13b
e514ea1d881d87371100b15119e2ffb9;
add 170.20.58.40 170.20.57.31 esp 0x301 -m tunnel -E 3des-cbc 0xb2b630c9e9692c36
d248b7206bda17c47f772f96290ac05f;

# Définit les politiques :
# spadd source dest protocoles politique
# politique = direction action regles
# regle = ipsecp/mode/options/niveau
# options = règles de définition des tunnels
# niveau = use ou require
spdadd 192.168.20.2 192.168.20.1 any -P in ipsec
        esp/tunnel/170.20.58.40-170.20.57.31/require
        ah/tunnel/170.20.58.40-170.20.57.31/require;

spdadd 192.168.20.1 192.168.20.2 any -P out ipsec
        esp/tunnel/170.20.57.31-170.20.58.40/require
        ah/tunnel/170.20.57.31-170.20.58.40/require;

Ce fichier commence par définir les associations de sécurité décrivant comment le trafic réseau doit se faire entre les machines 170.20.57.31 et 170.20.58.40. La première différence avec le mode transport est l'utilisation de l'option -m, qui prend en paramètre le mode de communication. Ici, il est demandé que tout le trafic IP, et non pas les communications elles-mêmes, soit encapsulé dans les protocoles AH et ESP. Cela a effectivement pour effet de faire un tunnel « IP over IPSec ».

La deuxième différence provient ensuite de la définition des politiques de sécurité. À présent, ces politiques ne portent plus sur les véritables adresses réseau des machines (à savoir 170.20.57.31 et 170.20.58.40), mais sur les adresses des interfaces réseau permettant d'accéder au tunnel (respectivement 192.168.20.1 et 192.168.20.2). De plus, les informations de routage pour le trafic dans le tunnel sont spécifiées dans les règles de la politique : il doit passer dans le tunnel IPSec établit entre 170.20.57.31 et 170.20.58.40.

9.5.2.3.4. Autoconfiguration avec ISAKMP

La configuration manuelle d'IPSec est réalisable pour l'établissement d'un tunnel ou pour le chiffrement des connexions entre deux ou trois machines, mais au delà de ce nombre, elle devient très vite lourde et contraignante. En effet, il est nécessaire de définir une clef privée de communication pour chaque couple de machine, ce qui peut faire un grand nombre de clefs. Par exemple, pour un réseau de trois machines, pas moins de six clefs AH et ESP sont nécessaires (douze si ces clefs ne sont pas utilisées pour les deux sens du trafic) !

C'est pour cette raison que le protocole d'échange de clef ISAKMP a été développé. Ce protocole utilise le port 500 du protocole UDP pour définir les associations de sécurité à utiliser pour les connexions IPSec, et de les renouveler régulièrement afin d'accroître la sécurité des communications. En effet, utiliser toujours la même clef dans une association de sécurité peut permettre à un attaquant de la calculer en observant certains paquets réseau dont il peut deviner une partie du contenu, comme par exemple les paquets de demande de connexion TCP.

Pour l'établissement des associations de sécurité, le protocole ISAKMP utilise plusieurs phase. La première phase permet d'établir une association de sécurité de contrôle entre les deux machines, par l'intermédiaire de laquelle les autres associations de sécurité seront établies. La deuxième phase est l'établissement des associations de sécurité utilisées pour les communications.

La première phase peut être réalisée selon plusieurs modes d'authentification. Le mode « principal » est le mode le plus sûr. Le mode « agressif » est plus économe en terme de trafic réseau, mais il n'est pas utilisable de manière fiable en pratique. Dans chacun de ces modes, plusieurs techniques d'authentification sont utilisables mais, en raison d'erreurs de conception du protocole ISAKMP, seul l'authentification basée sur les mécanismes de clefs publiques sont fiables. De ce fait, le protocole ISAKMP fonctionne de manière tout à fait similaire à OpenSSH, puisqu'il commence par établir une association de sécurité privée à partir des clefs publiques et privées, puis il utilise ce canal chiffré pour effectuer les échanges des associations de sécurité IPSec des communications. Dans ce type de configuration, il n'est plus nécessaire de définir qu'un couple de clefs privée et publique par machine.

Sous Linux, le protocole ISAKMP est implémenté par le démon racoon. racoon utilise des certificats x509 pour authentifier les machines, aussi vous faudra-t-il en générer pour chacune de vos machines.

Les certificats x509 sont des fichiers contenant l'identité d'une personne ainsi que sa clef publique, ce qui permet donc de l'authentifier de manière fiable à condition que l'on soit sûr de le certificat provient bien d'elle. Pour s'assurer de cela, il est courant de faire signer le certificat par une autorité de certification en laquelle on a confiance et dont le rôle est de bien s'assurer que la personne qui demande la signature de son certificat est bien celle qu'elle prétend être (moyennant finances bien entendu). Il est possible de signer soi-même ses propres certificats, ce qui ne résout bien sûr pas le problème de l'authenticité du certificat, mais permet au moins de s'assurer qu'il n'a pas été modifié par une tierce personne. Cela suppose bien entendu que le problème du transfert de l'empreinte du certificat vers le destinataire est résolu.

Les certificats peuvent être créés et manipulés à l'aide de l'outil OpenSSL, dont la ligne de commande est malheureusement relativement complexe. La création d'un nouveau certificat se fait typiquement avec la commande suivante :

openssl req -new -nodes -newkey rsa:1024 -sha1 \
   -keyform PEM -keyout machine1.private -outform PEM -out requete.pem

La création du certificat se fait ensuite simplement, en signant la requête de certification. Nous pouvons le faire nous-même, en signant la requête avec la clef privée que l'on vient de créer. Pour cela, il faut utiliser la commande suivante :

openssl x509 -req -in requete.pem \
   -signkey machine1.private -out machine1.public

Une fois que vous aurez créé vos clefs pour toutes vos machines, vous pourrez les distribuer sur vos différentes machines. Chaque machine doit bien entendu disposer de sa clef privée, ainsi que de l'ensemble des clefs publiques des autres machines. L'échange des clefs publiques est l'opération sensible, puisqu'il s'agit de s'assurer que les clefs reçues sont bien celles que l'on a émises. Pour cela, on pourra utiliser un condensé de la clef et s'assurer que ce condensé est bien le même après échange. Attention toutefois, il faut être certain que le condensé soit échangé de manière sûre. OpenSSL vous permet d'obtenir un condensé de vos clefs publiques avec la commande suivante :

openssl dgst clef.public

Le démon racoon utilise le fichier de configuration /etc/racoon.conf pour décrire la manière dont les différentes phases de la négociation des associations de sécurité doivent être faites. Il est possible de définir des options différentes pour différents clients, identifiés par leurs adresses IP. Toutefois, en raison de l'utilisation courante des adresses IP dynamiques, une configuration implicite doit souvent être donnée. Vous trouverez ci-dessous un exemple de fichier de configuration racoon.conf :

path certificate "/etc/ssl/certs";
remote anonymous
{
        exchange_mode main;
        certificate_type x509 "neptune.public" "neptune.private";
        verify_cert off;
        my_identifier asn1dn;
        peers_identifier asn1dn;
        proposal
        {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}

sainfo anonymous
{
        pfs_group modp1024;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}

La première ligne indique le chemin du répertoire dans lequel les fichiers de clefs publiques des clients se trouveront, ainsi que les fichiers de clefs publique et privée de la machine locale. La section remote permet de définir les options d'authentification d'un client pendant la première phase du protocole ISAKMP. Le mot-clé anonymous indique ici que tous les clients pour lesquels une section remote plus spécifique n'est pas disponible devront utiliser cette section. C'est donc la section à utiliser pour tous les clients disposant d'une adresse IP dynamique.

La définition de la première phase du protocole contient les directives suivantes :

• la directive exchange_mode, qui indique le mode de fonctionnement à utiliser pendant cette phase (le mode principal est choisi ici, parce que c'est le seul qui soit réellement sûr) ;

• la directive certificate_type, qui permet d'indiquer que le mécanisme d'authentification utilise des certificats X509 (grâce à l'option x509) ;

• la directive verify_cert, qui permet d'indiquer si les certificats manipulés doivent être vérifiés auprès d'une autorité de certification ou non (la configuration présentée ici ne le permet pas, car nous avons signé nous-même nos certificats) ;

• les directives my_identifier et peers_identifier, qui indiquent la manière dont les machines sont identifiées (leur option asn1dn indique que les informations qui ont été demandées lors de la création des certificats des machines sont utilisées pour retrouver leurs certificats) ;

• et enfin, la directive proposal, qui permet de fournir les paramètres cryptographiques utilisés pour l'association de sécurité de contrôle négociée pendant la première phase du protocole ISAKMP.

Les paramètres de l'association de sécurité de contrôle permettent de spécifier l'algorithme de chiffrement et l'algorithme de génération des signatures (directives encryption_algorithm et hash_algorithme respectivement), ainsi que la méthode d'authentification des machines (utilisation du protocole RSA, directive authentication_method). La directive dh-group permet de fournir un paramètre à l'algorithme d'échange de clefs Diffie Hellman, utilisé lors de l'échange des clefs privées.

La section sainfo permet de définir les paramètres des associations de sécurité négociées pendant la deuxième phase du protocole ISAKMP. Son format est semblable à la section de définition de l'association de sécurité de contrôle vue précédemment. Toutefois, une différence importante est que la méthode d'authentification est à présent basée sur un secret partagé et non plus sur le mécanisme des clefs publiques et privées des machines. De ce fait, l'algorithme de génération de signatures utilisé par le protocole AH nécessite une clef secrète échangée pendant la première phase. Ce n'est donc plus un simple algorithme de génération d'empreintes. La directive hmac_md5 permet d'utiliser un algorithme MD5 modifié pour être paramétré par la clef secrète.

Vous noterez que toutes ces informations permettent de définir la manière dont les associations de sécurité doivent être générées. Cependant, ces associations de sécurité ne sont pas forcément utilisées : il faut pour cela définir la politique de sécurité. Cette opération peut bien entendu se faire avec setkey. Le fichier de configuration ipsec.conf d'un serveur ressemble alors à celui-ci :

spdadd 0.0.0.0/0 serveur any -P in ipsec
        esp/transport//require
        ah/transport//require;

spdadd serveur 0.0.0.0/0 any -P out ipsec
        esp/transport//require
        ah/transport//require;

Il est également possible de demander à racoon de définir lui-même la politique de sécurité, lorsque des tentatives de connexion on lieu. Cela peut être réalisé à l'aide de la directive generate_policy de la section remote.

Une fois le fichier de configuration racoon.conf défini, il ne reste plus qu'à lancer racoon. Ceci peut se faire avec la commande suivante :

racoon -f /etc/racoon.conf