<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Chapitre 7. IPSEC: IP sécurisé à travers Internet</title><link href="style.css" rel="stylesheet" type="text/css" /><meta content="DocBook XSL Stylesheets V1.73.2" name="generator" /><link rel="start" href="index.html" title="HOWTO du routage avancé et du contrôle de trafic sous Linux" /><link rel="up" href="index.html" title="HOWTO du routage avancé et du contrôle de trafic sous Linux" /><link rel="prev" href="ch06.html" title="Chapitre 6. Tunnel IPv6 avec Cisco et/ou une dorsale IPv6 (6bone)" /><link rel="next" href="ch07s02.html" title="Gestion automatique des clés" /></head><body><div class="navheader"><table summary="Navigation header" width="100%"><tr><th align="center" colspan="3">Chapitre 7. IPSEC: IP sécurisé à travers Internet</th></tr><tr><td align="left" width="20%"><a accesskey="p" href="ch06.html">Précédent</a> </td><th align="center" width="60%"> </th><td align="right" width="20%"> <a accesskey="n" href="ch07s02.html">Suivant</a></td></tr></table><hr /></div><div class="chapter" lang="fr"><div class="titlepage"><div><div><h2 class="title"><a id="lartc.ipsec" />Chapitre 7. IPSEC: IP sécurisé à travers Internet</h2></div></div></div><div class="toc"><p><b>Table des matières</b></p><dl><dt><span class="sect1"><a href="ch07.html#lartc.ipsec.intro">Introduction sur la gestion manuelle des clés</a></span></dt><dt><span class="sect1"><a href="ch07s02.html">Gestion automatique des clés</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch07s02.html#lartc.ipsec.keying.theory">Théorie</a></span></dt><dt><span class="sect2"><a href="ch07s02.html#lartc.ipsec.automatic.keying.example">Exemple</a></span></dt><dt><span class="sect2"><a href="ch07s02.html#lartc.ipsec.x509">Gestion automatique des clés
en utilisant les certificats X.509</a></span></dt></dl></dd><dt><span class="sect1"><a href="ch07s03.html">tunnels IPSEC</a></span></dt><dt><span class="sect1"><a href="ch07s04.html">Autre logiciel IPSEC</a></span></dt><dt><span class="sect1"><a href="ch07s05.html">Interopérabilité d'IPSEC avec d'autres systèmes</a></span></dt><dd><dl><dt><span class="sect2"><a href="ch07s05.html#lartc.ipsec.interop.win32">Windows</a></span></dt><dt><span class="sect2"><a href="ch07s05.html#lartc.ipsec.interop.checkpoint"> Check Point VPN-1 NG</a></span></dt></dl></dd></dl></div><p>
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 <a class="ulink" href="http://www.freeswan.org/" target="_top">un site officiel</a> et également
<a class="ulink" href="http://www.freeswan.ca" target="_top">un site non officiel</a>, 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.
</p><p>
De plus, <a class="ulink" href="http://www.edlug.ed.ac.uk/archive/Sep2002/msg00244.html" target="_top">des</a>
personnes <a class="ulink" href="http://lists.freeswan.org/pipermail/design/2002-November/003901.html" target="_top">se
sont inquiétées</a> de la qualité du code. Pour configurer FreeS/WAN,
de nombreuses <a class="ulink" href="http://www.freeswan.ca/code/old/freeswan-Snapshot/doc/index.html" target="_top">documentations</a>
sont <a class="ulink" href="http://www.freeswan.org/doc.html" target="_top">disponibles</a>.
</p><p>
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.
</p><p>
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 <a class="ulink" href="http://gondor.apana.org.au/~herbert/freeswan/" target="_top">mise à jour</a>
qui permet au code FreeS/WAN de l'espace utilisateur de fonctionner
avec l'IPSEC natif de Linux.
</p><p>
A partir du noyau 2.5.49, IPSEC fonctionne sans l'ajout de mises à
jour supplémentaires.
</p><p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td valign="top" align="center" rowspan="2" width="25"><img alt="[Note]" src="images/note.png" /></td><th align="left">Note</th></tr><tr><td valign="top" align="left"><p>
Les outils de l'espace utilisateur sont disponibles <a class="ulink" href="http://sourceforge.net/projects/ipsec-tools" target="_top">ici</a>. Il y
a plusieurs programmes disponibles ; celui qui est proposé
dans le lien est basé sur Racoon.
</p><p>
Lors de la compilation du noyau, soyez sûr d'activer 'PF_KEY', 'AH' et
tous les éléments de CryptoAPI !
</p></td></tr></table></div>
<div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Warning"><tr><td valign="top" align="center" rowspan="2" width="25"><img alt="[Avertissement]" src="images/warning.png" /></td><th align="left">Avertissement</th></tr><tr><td valign="top" align="left"><p>
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 <code class="email"><<a class="email" href="mailto:ahu@ds9a.nl">ahu@ds9a.nl</a>></code>.
</p></td></tr></table></div>
</p><p>
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".
</p><p>
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.
</p><div class="sect1" lang="fr"><div class="titlepage"><div><div><h2 class="title"><a id="lartc.ipsec.intro" />Introduction sur la gestion manuelle des clés</h2></div></div></div><p>
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.
</p><p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Note"><tr><td valign="top" align="center" rowspan="2" width="25"><img alt="[Note]" src="images/note.png" /></td><th align="left">Note</th></tr><tr><td valign="top" align="left"><p>
Certaines configurations iptables rejettent les paquets
IPSEC ! Pour transmettre IPSEC, utilisez :
<span class="command"><strong>iptables -A xxx -p 50 -j ACCEPT</strong></span> et
<span class="command"><strong>'iptables -A xxx -p 51 -j ACCEPT</strong></span>.
</p></td></tr></table></div>
</p><p>
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.
</p><p>
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.
</p><p>
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 :
<pre class="screen">add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
</pre>
Ceci indique que le trafic allant de <code class="literal">10.0.0.11</code> vers
<code class="literal">10.0.0.216</code> a besoin d'un En-tête d'Authentification
(AH) qui peut être signé en utilisant HMAC-MD et le secret
<code class="literal">1234567890123456</code>. Cette instruction est repérée par
l'identificateur SPI (<em class="wordasword">Security Parameter Index</em>)
<code class="literal">15700</code>, 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 <code class="literal">10.0.0.11</code> vers
<code class="literal">10.0.0.216</code>. Pour un trafic bidirectionnel, deux
Associations de Sécurité (SA) sont nécessaires.
</p><p>
Un exemple d'Association de Sécurité (SA) pour le cryptage ESP :
<pre class="screen">add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
</pre>
Ceci signifie que le trafic allant de <code class="literal">10.0.0.11</code> vers
<code class="literal">10.0.0.216</code> est chiffré en utilisant 3des-cbc avec la
clé <code class="literal">123456789012123456789012</code>. L'identificateur SPI
est <code class="literal">15701</code>.
</p><p>
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
<em class="wordasword">Security Parameter Index</em>, 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".
</p><p>
Une "Politique de Sécurité" (Security Policy (SP)) typique ressemble
à ceci :
<pre class="screen">spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
esp/transport//require
ah/transport//require;
</pre>
Si cette configuration est appliquée sur l'hôte
<code class="literal">10.0.0.216</code>, cela signifie que tout le trafic allant
vers <code class="literal">10.0.0.11</code> 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.
</p><p>
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.
</p><p>
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.
</p><p>
Ce qui suit est une configuration très simple permettant le dialogue de
l'hôte <code class="literal">10.0.0.216</code> vers l'hôte
<code class="literal">10.0.0.11</code> 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.
</p><p>
Sur l'hôte <code class="literal">10.0.0.216</code> :
<pre class="screen">#!/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;
</pre>
</p><p>
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é :
<pre class="screen">#!/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";
</pre>
</p><p>
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 <span class="command"><strong>ping 10.0.0.11</strong></span> exécutée sur 10.0.0.216 va
donner la sortie suivante avec tcpdump :
<pre class="screen">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
</pre>
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.
</p><p>
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é !
</p><p>
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 :
<pre class="screen">#!/sbin/setkey -f
spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
esp/transport//require
ah/transport//require;
</pre>
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.
</p><p>
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 :</p><pre class="screen">#!/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;
</pre><p>Et sur 10.0.0.11 :</p><pre class="screen">#!/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;
</pre><p>
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é.
</p><p>
Pour examiner la configuration que nous venons de créer, exécuter
<span class="command"><strong>setkey -D</strong></span>, qui montre les SA ou <span class="command"><strong>setkey
-DP</strong></span> qui montre les politiques configurées.
</p></div></div><div class="navfooter"><hr /><table summary="Navigation footer" width="100%"><tr><td align="left" width="40%"><a accesskey="p" href="ch06.html">Précédent</a> </td><td align="center" width="20%"> </td><td align="right" width="40%"> <a accesskey="n" href="ch07s02.html">Suivant</a></td></tr><tr><td valign="top" align="left" width="40%">Chapitre 6. Tunnel IPv6 avec Cisco et/ou une dorsale IPv6 (6bone) </td><td align="center" width="20%"><a accesskey="h" href="index.html">Sommaire</a></td><td valign="top" align="right" width="40%"> Gestion automatique des clés</td></tr></table></div></body></html>
