|
IPsec
par
Brieuc Jeunhomme
1 - Introduction
2 - Les services offerts par IPsec
2.1 - Les deux modes d'échange IPsec
2.2 - Les protocoles à la base d'IPsec
2.2.1 - AH (authentication header)
2.2.2 - ESP (encapsulating security payload)
2.2.3 - Implantation d'IPsec dans le datagramme IP
3 - Architectures de sécurité
3.1 - Associations de sécurité
3.2 - Architectures supportées
3.2.1 -
Dialogue entre deux hôtes protégeant le trafic eux-mêmes
3.2.2 -
Dialogue entre deux LANs à l'aide de passerelles de sécurité
3.2.3 -
Dialogue entre deux hôtes traversant deux passerelles de sécurité
3.2.4 -
Dialogue entre un hôte et une passerelle de sécurité
4 - Gestion des clefs
5 - La compression des en-têtes
6 - Problèmes divers
6.1 -
Limitations dûes à la gestion manuelle des clefs
6.2 - Broadcast et multicast
6.3 - Firewalls
6.4 - NATs
6.5 - Protocoles autres qu'IP
6.5.1 - PPTP
6.5.2 - L2TP
6.5.3 - PPTP ou L2TP ?
7 - Quelques implémentations actuelles
7.1 - Windows
7.2 - Linux
7.3 - NetBSD
7.4 - FreeBSD
7.5 - OpenBSD
7.6 - Solutions hardware
8 - Les écueils
9 - Discussion autour de la
documentation
10 - Suivi du document
Cet article présente le fonctionnement du protocole IPsec, qui permet de créer
des réseaux privés virtuels de manière conforme aux spécifications de l'IETF.
Les services offerts par IPsec et leurs limitations y sont détaillés, de même
que les problèmes d'interopérabilité, tant avec d'autres protocoles qu'entre
applications différentes. Enfin, quelques implémentations sont présentées, et un
rapide aperçu de leur conformité aux standards est donné.
Le protocole IPsec est l'une des méthodes permettant de
créer des VPN (réseaux
privés virtuels), c'est-à-dire de relier entre eux des systèmes informatiques de
manière sûre en s'appuyant sur un réseau existant, lui-même considéré comme non
sécurisé. Le terme sûr a ici une signification assez vague, mais peut en
particulier couvrir les notions d'intégrité et de confidentialité.
L'intérêt majeur de cette solution par rapport à d'autres techniques (par
exemple les tunnels SSH) est qu'il s'agit d'une méthode standard (facultative en
IPv4, mais obligatoire en IPv6), mise au point dans ce but précis, décrite par
différentes RFCs, et donc interopérable.
Quelques avantages supplémentaires sont l'économie de bande passante, d'une part
parce que la compression des en-têtes des données transmises est prévue par ce
standard, et d'autre part parce que celui-ci ne fait pas appel à de trop lourdes
techniques d'encapsulation, comme par exemple les tunnels PPP sur lien SSH. Il
permet également de protéger des protocoles de bas niveau comme
ICMP et IGMP,
RIP, etc...
IPsec présente en outre l'intérêt d'être une solution évolutive, puisque les
algorithmes de chiffrement et d'authentification à proprement parler sont
spécifiés séparément du protocole lui-même. Elle a cependant l'inconvénient
inhérent à sa flexibilité : sa grande complexité rend son implémentation
délicate.
Les différents services offerts par le protocole IPsec sont ici détaillés. Les
manières de les combiner entre eux que les implémentations sont tenues de
supporter sont ensuite présentées. Les moyens de gestion des clefs de
chiffrement et signature sont étudiés et les problèmes d'interopérabilité
associés sont évoqués. Enfin, un aperçu rapide de quelques implémentations IPsec, en s'intéressant essentiellement à leur conformité aux spécifications est
donné.
Une communication entre deux hôtes, protégée par IPsec, est susceptible de
fonctionner suivant deux modes différents : le mode transport et le mode tunnel.
Le premier offre essentiellement une protection aux protocoles de niveau
supérieur, le second permet quant à lui d'encapsuler des datagrammes IP dans
d'autres datagrammes IP, dont le contenu est protégé. L'intérêt majeur de ce
second mode est qu'il rend la mise en place de passerelles de sécurité qui
traitent toute la partie IPsec d'une communication et transmettent les
datagrammes épurés de leur partie IPsec à leur destinataire réel réalisable. Il
est également possible d'encapsuler une communication IPsec en mode tunnel ou
transport dans une autre communication IPsec en mode tunnel, elle-même traitée
par une passerelle de sécurité, qui transmet les datagrammes après suppression
de leur première enveloppe à un hôte traitant à son tour les protections
restantes ou à une seconde passerelle de sécurité.
AH est le premier et le plus simple des protocoles de protection des données qui
font partie de la spécification IPsec. Il est détaillé dans la
Rfc 2402. Il a
pour vocation de garantir :
L'authentification : les datagrammes IP reçus ont effectivement été émis par
l'hôte dont l'adresse IP est indiquée comme adresse source dans les en-têtes.
L'unicité (optionnelle, à la discrétion du récepteur) : un datagramme ayant été
émis légitimement et enregistré par un attaquant ne peut être réutilisé par ce
dernier, les attaques par rejeu sont ainsi évitées.
L'intégrité : les champs suivants du datagramme IP n'ont pas été modifiés depuis
leur émission : les données (en mode tunnel, ceci comprend la totalité des
champs, y compris les en-têtes, du datagramme IP encapsulé dans le datagramme
protégé par AH), version (4 en IPv4, 6 en IPv6), longueur de l'en-tête (en
IPv4), longueur totale du datagramme (en IPv4), longueur des données (en IPv6),
identification, protocole ou en-tête suivant (ce champ vaut 51 pour indiquer
qu'il s'agit du protocole AH), adresse IP de l'émetteur, adresse IP du
destinataire (sans source routing).
En outre, au cas où du source routing serait présent, le champ adresse IP du
destinataire a la valeur que l'émetteur a prévu qu'il aurait lors de sa
réception par le destinataire. Cependant, la valeur que prendront
les champs
type de service (IPv4), indicateurs (IPv4), index de fragment (IPv4), TTL
(IPv4), somme de contrôle d'en-tête (IPv4), classe (IPv6), flow label (IPv6), et
hop limit (IPv6) lors de leur réception n'étant pas prédictible au moment de
l'émission, leur intégrité n'est pas garantie par AH.
L'intégrité de celles des options IP qui ne sont pas modifiables pendant le
transport est assurée, celle des autres options ne l'est pas.
Attention, AH n'assure pas la confidentialité : les données sont signées mais
pas chiffrées.
Enfin, AH ne spécifie pas d'algorithme de signature particulier, ceux-ci sont
décrits séparément, cependant, une implémentation conforme à la
Rfc 2402 est
tenue de supporter
les algorithmes MD5 et SHA-1.
ESP est le second protocole de protection des données qui fait partie de la
spécification IPsec. Il est détaillé dans la Rfc 2406. Contrairement à AH, ESP
ne protège pas les en-têtes des datagrammes IP utilisés pour transmettre la
communication. Seules les données sont protégées. En mode transport, il assure :
La confidentialité des données (optionnelle) : la partie données des datagrammes
IP transmis est chiffrée.
L'authentification (optionnelle, mais obligatoire en l'absence de
confidentialité) : la partie données des datagrammes IP reçus ne peut avoir été
émise que par l'hôte avec lequel a lieu l'échange IPsec, qui ne peut
s'authentifier avec succès que s'il connaît la clef associée à la communication
ESP. Il est également important de savoir que l'absence d'authentification nuit
à la confidentialité, en la rendant plus vulnérable à certaines attaques
actives.
L'unicité (optionnelle, à la discrétion du récepteur).
L'integrité : les données n'ont pas été modifiées depuis leur émission.
En mode tunnel, ces garanties s'appliquent aux données du datagramme dans lequel
est encapsulé le trafic utile, donc à la totalité (en-têtes et options inclus)
du datagramme encapsulé. Dans ce mode, deux avantages supplémentaires
apparaissent:
Une confidentialité, limitée, des flux de données (en mode tunnel uniquement,
lorsque la confidentialité est assurée) : un attaquant capable d'observer les
données transitant par un lien n'est pas à même de déterminer quel volume de
données est transféré entre deux hôtes particuliers. Par exemple, si la
communication entre deux sous-réseaux est chiffrée à l'aide d'un tunnel ESP, le
volume total de données échangées entre ces deux sous-réseaux est calculable par
cet attaquant, mais pas la répartition de ce volume entre les différents
systèmes de ces sous-réseaux.
La confidentialité des données, si elle est demandée, s'étend à l'ensemble des
champs, y compris les en-têtes, du datagramme IP encapsulé dans le datagramme
protégé par ESP).
Enfin, ESP ne spécifie pas d'algorithme
de signature ou de chiffrement particulier, ceux-ci sont décrits séparément,
cependant, une implémentation conforme à la Rfc 2406 est tenue de supporter l'algorithme de chiffrement DES en
mode CBC, et les signatures à l'aide des fonctions de hachage MD5 et SHA-1.
La figure 1 montre comment les données nécessaires au bon fonctionnement des
formats AH et ESP sont placées dans le datagramme IPv4. Il s'agit bien d'un
ajout dans le datagramme IP, et non de nouveaux datagrammes, ce qui permet un
nombre théoriquement illimité ou presque d'encapsulations IPsec : un datagramme
donné peut par exemple être protégé à l'aide de trois applications successives
de AH et de deux encapsulations de ESP.
La Rfc 2401 (Security Architecture for the Internet Protocol) décrit le
protocole IPsec au niveau le plus élevé. En particulier, elle indique ce qu'une
implémentation est censée permettre de configurer en termes de politique de
sécurité (c'est-à-dire quels échanges IP doivent être protégés par IPsec et, le
cas échéant, quel(s) protocole(s) utiliser). Sur chaque système capable
d'utiliser IPsec doit être présente une SPD (security policy database), dont la
forme précise est laissée au choix de l'implémentation, et qui permet de
préciser la politique de sécurité à appliquer au système. Chaque entrée de cette
base de données est identifiée par un SPI (security parameters index) unique (32
bits) choisi arbitrairement.
Une communication protégée à l'aide d'IPsec est appelée une SA (security
association). Une SA repose sur une unique application de AH ou sur une unique
application de ESP. Ceci n'exclut pas l'usage simultané de AH et ESP entre deux
systèmes, ou par exemple l'encapsulation des datagrammes AH dans d'autres
datagrammes AH, mais plusieurs SA devront alors être activées entre les deux
systèmes. En outre, une SA est unidirectionnelle. La protection d'une
communication ayant lieu dans les deux sens nécessitera donc l'activation de
deux SA. Chaque SA est identifiée de manière unique par un SPI, une adresse IP
de destination (éventuellement adresse de broadcast ou de multicast), et un
protocole (AH ou ESP). Les SA actives sont regroupées dans une SAD (security
association database).
La SPD est consultée pendant le traitement de tout datagramme IP, entrant ou
sortant, y compris les datagrammes non-IPsec. Pour chaque datagramme, trois
comportements sont envisageables : le rejeter, l'accepter sans traitement IPsec,
ou appliquer IPsec. Dans le troisième cas, la SPD précise en outre quels
traitements IPsec appliquer (ESP, AH, mode tunnel ou transport, quel(s)
algorithme(s) de signature et/ou chiffrement utiliser).
Les plus importants de ces termes sont récapitulés dans le tableau suivant :
SPD
base de données définissant la politique de sécurité
SA
une entrée de la SPD
SAD
liste des SA en cours d'utilisation
Les règles de la SPD doivent pouvoir, si l'adminsitrateur du système le
souhaite, dépendre des paramètres suivants :
adresse ou groupe d'adresses IP de
destination
adresse ou groupe d'adresses IP source
nom du système (DNS complète, nom X.500
distingué ou général)
protocole de transport utilisé (typiquement, TCP ou
UDP)
nom d'utilisateur complet, comme foo@bar.net
(ce paramètre n'est toutefois pas obligatoire sur certains types
d'implémentations)
importance des données (ce paramètre
n'est toutefois pas obligatoire sur certains types d'implémentations)
ports source et destination (UDP et TCP
seulement, le support de ce paramètre est facultatif)
Certains paramètres peuvent être
illisibles à cause d'un éventuel chiffrement ESP au moment où ils sont traités,
auquel cas la valeur de la SPD les concernant peut le préciser, il s'agit de :
l'identité de l'utilisateur
le protocole de transport
les ports source et destination
Il est donc possible de spécifier une politique de sécurité relativement fine et
détaillée. Cependant, une politique commune pour le trafic vers un ensemble de
systèmes permet une meilleure protection contre l'analyse de trafic qu'une
politique extrêmement détaillée, comprenant de nombreux paramètres propres à
chaque système particulier.
Enfin, si l'implémentation permet aux applications de préciser elles-mêmes à
quelle partie du trafic appliquer IPsec et comment, l'administrateur doit
pouvoir les empêcher de contourner la politique par défaut.
Le protocole IPsec permet théoriquement n'importe quelle combinaison, en un
nombre quasiment illimité de niveaux d'encapsulation, c'est-à-dire
d'accumulations de SA. Néanmoins, les implémentations ne sont pas tenues
d'offrir une telle flexibilité. Les architectures qu'une application conforme à
la Rfc 2401 doivent supporter, au nombre de quatre, sont décrites ci-dessous.
Deux hôtes engagent une communication IPsec, en encapsulant le protocole de haut
niveau dans :
en mode transport :
des datagrammes AH
des datagrammes ESP
ou des datagrammes ESP encapsulés dans des datagrammes
AH
en mode tunnel :
des datagrammes AH
ou des datagrammes ESP
Ici, deux passerelles de sécurité gèrent les conversations entre les hôtes de
deux LANs différents, IPsec s'appliquant de manière transparente pour les hôtes.
Les deux passerelles de sécurité échangent des datagrammes en mode tunnel, à
l'aide de AH ou ESP (après routage, ceci correspond simplement à la deuxième
partie du cas précédent), puis transmettent les datagrammes obtenus après
traitement IPsec aux hôtes destinataires. Ainsi, les datagrammes IP émis par un
système de l'un des deux LANs sont encapsulés dans d'autres datagrammes IP+IPsec
par la passerelle du "LAN émetteur", encapsulation supprimée par la passerelle
du "LAN récepteur" pour obtenir de nouveau les datagrammes IP originaux.
Le troisième cas n'ajoute pas vraiment de prérequis sur les implémentations
IPsec. Ainsi, une passerelle de sécurité doit avoir la capacité de transmettre
dans un tunnel IPsec du trafic déjà sécurisé par IPsec. Celà autorise les
dialogues IPsec entre deux hôtes situés eux-mêmes dans des LANs reliés par des
passerelles de sécurité.
Le dernier cas est celui d'un hôte externe se connectant à un LAN protégé par
une passerelle de sécurité. Les documentations techniques désignent souvent un
tel hôte sous le nom de road warrior. Il engage une conversation IPsec avec un
système du LAN en mode transport, le tout encapsulé dans un tunnel IPsec établi
entre le road warrior lui-même et la passerelle de sécurité. Dans ce cas, les
datagrammes du tunnel sont de type AH ou ESP et les datagrammes utilisés en mode
transport doivent pouvoir être de type AH, ESP, ou ESP encapsulé dans AH.
Les services de protection offerts par IPsec s'appuient sur des algorithmes
cryptographiques, et reposent donc sur des clefs. Si celles-ci sont gérables
manuellement dans le cas où peu d'hôtes seront amenés à engager des
conversations IPsec, ceci devient un véritable cauchemar quand le système
commence à prendre un peu d'extension (le nombre de couples de clefs augmentant
de manière quadratique avec le nombre de systèmes). C'est pourquoi la
spécification IPsec propose également des procédés d'échange automatique de
clefs, dont les aspects les plus importants sont ici évoqués. Une présentation
complète de cette procédure dépasse toutefois le cadre de cet article. La
Rfc
2401 précise qu'une implémentation IPsec est tenue de supporter la gestion
manuelle de clefs et la méthode d'échange automatique de clefs IKE, bien que
d'autres algorithmes existent. Un point important est que la gestion de clefs
automatique est considérée comme plus sûre que la gestion manuelle.
Le protocole IKE (internet key exchange) est décrit par la
Rfc 2409. Il permet
l'échange de clefs entre deux hôtes d'adresses IP connues préalablement ou
inconnues selon le mode d'échange de clefs sélectionné. Parmi ses avantages
figure le mode agressif (cette caractéristique n'est pas obligatoire), qui
permet d'accélérer la négociation, au prix de la protection d'identité.
L'identité est toutefois protégée dans le cas d'une négociation IKE authentifiée
à l'aide de signatures à clef publique.
Deux manières d'échanger des clefs sont abondamment utilisées : les clefs
pré-partagées, et les certificats X.509 (dans ce dernier cas, deux systèmes
d'adresses initialement inconnues pourront protéger leurs échanges).
La seconde
manière de procéder a l'avantage de permettre à des clients d'adresses IP
dynamiques et changeant éventuellement de créer des SAs, mais n'est pas
obligatoirement supportée par les implémentations conformes à la
Rfc 2409.
Enfin, une définition qui peut s'avérer utile lors de la lecture de
documentations techniques sur IPsec : la PFS (perfect forward secrecy) est
définie par la Rfc 2409 comme la notion selon laquelle la compromission d'une
clef ne permettra l'accès qu'aux données protégées par cette clef, mais ne sera
pas suffisante pour déchiffrer tout l'échange IPsec, seule la partie de la
communication protégée par la clef corrompue sera déchiffrable.
La Rfc 3095 décrit un protocole de compression d'en-têtes pouvant s'appliquer à RTP, UDP, et ESP sur IP. La compression des données elles-mêmes n'est
malheureusement pas couverte par cette spécification, il n'est donc pas prévu, à
l'heure actuelle, de les compresser. En revanche, il est conçu pour s'accommoder
des taux d'erreurs de transmission importants des communications par voie
hertzienne. Enfin, la compression décrite s'appuie sur une couche de liens
garantissant la transmission des données dans leur ordre d'émission et sans
duplication, ce qui peut rendre dangereuse son utilisation sur certains réseaux.
Enfin, la couche de liens doit permettre la négociation des paramètres ROHC
(robust header compression), cette négociation peut cependant se faire à priori
ou en s'appuyant sur d'autres protocoles.
L'utilisation simultanée d'IPsec et d'autres protocoles ou de certains
équipements réseau pose, dans certains cas, quelques problèmes. En outre, la
gestion manuelle de clefs introduit quelques restrictions sur les usages
possibles du protocole.
Les services d'unicité offerts par AH et ESP s'appuient sur des numéros de
séquence initialisés à 0 lors de la création d'une SA et incrémentés lors de
l'envoi de chaque datagramme. Ces numéros de séquence sont stockés dans un
entier de 32 bits, qui ne doit jamais être diminué. Le nombre maximal de
datagrammes qu'une SA peut permettre d'échanger est donc de l'ordre de quatre
milliards. Passé cette limite, il est nécessaire de créer une nouvelle SA et
donc une nouvelle clef. Ceci rend pénible la mise en oeuvre simultanée de la
gestion manuelle de clefs et de la protection contre la duplication de
datagrammes. Cette dernière étant optionnelle, il est possible de la désactiver,
auquel cas le numéro de séquence peut être annulé lorsqu'il a atteint sa valeur
maximale.
L'utilisation d'IPsec pour l'envoi et la réception de datagrammes multicast et
broadcast pose quelques problèmes dont certains ne sont pas encore résolus. Des
problèmes de performances d'une part, et des difficultés qu'une simple
augmentation de la puissance de calcul ne saurait résoudre, comme la
vérification des numéros de séquence. Le service de protection contre la
duplication des données n'est donc pas utilisable en environnement multicast et
broadcast à l'heure actuelle.
Le filtrage de datagrammes IPsec est délicat pour deux raisons :
les RFCs ne précisent pas si, sur un
système remplissant simultanément les fonctions de passerelle de sécurité et de
firewall, le décodage de l'IPsec doit avoir lieu avant ou après l'application
des règles de firewalling
il n'est pas possible au code de firewalling
de lire certaines données, par exemple des numéros de port, dans des données
chiffrées, ou transmises dans un format qu'il ne connaît pas
Il est donc important de lire la documentation de l'implémentation IPsec
utilisée sur les systèmes destinés à gérer simultanément IPsec et firewalling.
Il est également utile de noter que les systèmes qui appliquent les règles de
firewalling avant le décodage IPsec sont néanmoins souvent capables de filtrer
les datagrammes décodés en utilisant des outils de tunneling comme ipip et gif,
ou en filtrant au niveau de l'interface de sortie des données.
Enfin, AH utilise le numéro de protocole 51 et ESP le numéro de protocole 50.
Quant à IKE, il utilise le numéro de port UDP 500. Ces informations sont
indispensables lors de la configuration d'un firewall qui doit laisser passer ou
bloquer les échanges IPsec.
Théoriquement, toute translation d'adresse sur un datagramme IPsec devrait être
évitée, car ce type d'opération modifie le contenu des datagrammes, ce qui est
incompatible avec les mécanismes de protection de l'intégrité des données
d'IPsec.
Il existe une solution à ce problème, proposée par SSH Communications Security : l'IPsec NAT-Traversal. Il s'agit d'un draft, donc
encore incomplet, mais suffisant pour envisager ce que l'avenir réserve.
Certains équipement permettent d'ailleurs déjà de traverser des NAT, en
utilisant des protocoles plus ou moins normalisés et avec plus ou moins de
bonheur.
Comme il ne s'agit que d'un draft, il est décrit dans des documents dont le nom
et l'adresse changent souvent, mais un moyen simple de le retrouver est d'entrer
la chaîne draft-stenberg-ipsec-nat-traversal dans votre moteur de recherche
favori.
Enfin, ce protocole ne peut être mis en oeuvre que si le protocole IKE est
utilisé simultanément.
Un inconvénient d'IPsec est que ce protocole ne prévoit que le convoyage
sécurisé de datagrammes IP. Ceci n'est pas suffisant, car d'autres standards
comme IPX et NetBIOS sont utilisés sur un grand nombre de réseaux. Il existe
cependant une solution à ce problème : encapsuler les données à protéger dans du
PPP, lui-même transporté par IPsec. Le rôle de PPP est en effet de permettre la
transmission de différents protocoles au-dessus d'un lien existant. Ceci
implique de pouvoir encapsuler PPP dans les datagrammes IPsec, cette opération
est décrite dans les paragraphes suivants.
La première solution permettant cette encapsulation est le protocole PPTP,
décrit par la Rfc 2637. PPTP offre ainsi à un client, dit PAC (PPTP access
concentrator), la possibilité d'établir un lien PPP avec un serveur dit PNS
(PPTP network server), encapsulé dans des datagrammes IP. Si le client a
préalablement établi une SA avec une passerelle de sécurité (éventuellement
distincte du PNS), qui lui permet de protéger ces datagrammes IP, les données
PPP seront donc également sécurisées, de même que les protocoles de niveau
supérieur s'appuyant sur le lien PPP.
Deux points s'avèrent importants lors de la configuration d'un firewall placé
entre un PAC et un PNS :
PPTP s'appuie sur le protocole d'encaspulation
général GRE, auquel l'IANA a attribué le numéro 47
un lien PPTP est contrôlé par une connexion TCP vers le port 1723 du PNS
Enfin, PPTP seul, c'est-à-dire sans IPsec, peut être et a été utilisé pour
crééer des VPNs, assurant des échanges authentifiés, en protégeant les mots de
passes utilisés d'un éventuel attaquant, mais sans chiffrer le reste de la
communication. Cependant, ce système offre une authentification nettement moins
fiable que ce qu'il est possible d'obtenir avec IPsec. En outre, de nombreuses
implémentations de ce protocole, notamment celles de Microsoft, ont fait l'objet
de découvertes de vulnérabilités et d'incapacité à protéger efficacement les
mots de passe des utilisateurs. Aussi l'usage de ce système est-il risqué.
Une deuxième solution d'encapsulation de PPP dans IP est
le protocole L2TP,
décrit par la Rfc 2661. Il permet la transmission de PPP à l'aide des protocoles
de niveau 2 comme ethernet. Il offre également un mécanisme d'encapsulation de
PPP dans UDP. Ainsi, il est possible de protéger PPP à l'aide d'UDP encapsulé
dans IPsec. L2TP offre en outre une architecture plus modulaire que PPTP : on
suppose le client capable d'échanger des trames par l'intermédiaire d'un
protocole de niveau 2 ou des datagrammes UDP avec un LAC (L2TP access
concentrator), qui transmet les données à un LNS (L2TP network server). Si le
LAC et le LNS sont situés physiquement sur le même système, celui-ci joue alors
exactement le même rôle que le PNS de PPTP.
Un détail important lors du paramétrage d'un firewall : le L2TP encapsulé dans UDP utilise le port 1701.
L'utilisation de PPTP ou L2TP ne change pas grand-chose du point de vue de la
sécurité, celle-ci étant assurée par la couche inférieure IPsec. La question qui
se pose est donc celle de la consommation de bande passante, parce que toutes
ces encapsulations commencent à représenter un volume de données non
négligeable.
Dans le cas d'un client se connectant à un ISP et établissant ensuite le tunnel
vers un réseau destination, PPTP devrait permettre d'économiser les
en-têtes UDP. En revanche, dans le cas d'un client se connectant, par exemple à l'aide
d'un modem ou d'une ligne ISDN, directement sur le réseau privé, et disposant
donc d'un lien de niveau 2 vers ce réseau, L2TP semble plus économe.
Un dernier point à prendre compte est que l'os tournant sur le serveur imposera
parfois des limitations :
pour Windows 2000 et ultérieures,
Microsoft semble privilégier très fortement L2TP
les versions précédentes de Windows ne
supportent pas L2TP
les Unix-like libres semblent accuser un
léger retard en matière de support L2TP
Cette partie donne un aperçu des capacités de quelques OS populaires en matière
de support IPsec. Les informations fournies constituent une synthèse des sites
des OS, des éditeurs et des FAQs des logiciels concernés : de plus amples
détails sont donc disponibles sur ces sites.
Windows XP et 2000 incluent un support du mode transport d'IPsec et de l'échange
de clefs à l'aide de certificats en natif. Il existe de très nombreux logiciels
permettant de créer des VPN sous Windows, y compris un serveur VPN en option
sous Windows 2000 et XP, capable de mettre en place des tunnels IPsec/L2TP.
D'autre part, Windows 95, 98 et NT 4 disposent d'une grande quantité
d'implémentations IPsec commerciales et à peu près toutes les versions de
Windows depuis 95 sont capables de créer des tunnels PPTP.
Une solution intéressante est également proposée par
SSH Communications Security. Leur implémentation est à l'heure actuelle l'une des
rares à supporter IPsec NAT-Traversal. Le client est disponible pour les
versions 95, 98, Me, NT 4, 2000 et XP de Windows.
L'implémentation IPsec la plus utilisée sous Linux est sous licence GPL, il
s'agit de FreeS/WAN. La partie kernel de cette
implémentation s'appelle KLIPS.
Sont notamment supportés :
l'échange dynamique de clefs IKE à l'aide
du logiciel pluto, qui permet l'utilisation de clefs pré-partagées aussi bien
que de certificats
la protection des connexions d'un road warrior à un LAN, même si son adresse IP
est attribuée dynamiquement et est susceptible de changer
la création de tunnels PPTP (côté serveur), grâce au logiciel PoPToP
la création de tunnels PPTP (côté client), grâce au logiciel
PPTP-linux
la création de tunnels L2TP, grâce au logiciel
l2tpd
le chiffrement opportuniste, qui permet
la protection des données échangées entre deux systèmes totalement étrangers
jusqu'alors (les clefs publiques sont alors échangées à l'aide de la
DNS)
Les principaux problèmes connus lors de l'écriture de ce document étaient :
KLIPS présente une très légère fuite de
mémoire
si plusieurs connexions sont établies
entre deux passerelles de sécurité, la compression d'en-têtes doit être activée
pour toutes ou aucune de ces connexions
KLIPS ne gère pas les datagrammes dans lesquels des options IP
sont présentes
Enfin, FreeS/WAN décode les paquets IPsec avant de les transmettre au code de
firewalling. Les règles de firewalling peuvent néanmoins tester si les
datagrammes ont été envoyés en clair ou non.
NetBSD utilise
KAME, une implémentation IPsec (et plus
généralement IPv6) sous licence BSD. La foire aux questions concernant IPsec
pour NetBSD.
Sont notamment supportés :
l'utilisation simultanée d'IPsec en mode
tunnel ou transport avec IPv6, au moins pour la version courante de NetBSD
la configuration socket par socket (à
l'aide de l'appel système setsockopt(2))
la création de tunnels IPsec grâce aux
ports pptp et pptp-server
un nombre quasiment illimité de SA
imbriquées
l'échange dynamique de clefs IKE, en utilisant soit racoon, qui peut fonctionner
à l'aide de clefs pré-partagées ou de certificats, soit isakmpd, qui en est
encore à son stade alpha, et supporte également ces deux méthodes
Les principaux problèmes connus lors de l'écriture de ce document étaient :
les clefs associées à une SA mise en place à l'aide de l'appel setsockopt(2)
ne peuvent être négociées par racoon
le protocole AH en mode tunnel ne fonctionne pas correctement
Enfin, lors d'une utilisation conjointe de KAME et IPfilter sous NetBSD, les
datagrammes sont traités par le firewall avant d'être décodés par KAME.
FreeBSD s'appuie également KAME. L'utilisation d'IPsec sous
FreeBSD
est documentée.
Sont notamment supportés :
l'utilisation simultanée d'IPsec en mode
tunnel ou transport avec IPv6, au moins pour la version courante de FreeBSD
la création de tunnels PPTP (côté client)
la création de tunnels PPTP (côté serveur), grâce au logiciel PoPToP
la création de tunnels L2TP, grâce au logiciel (dont le portage sous FreeBSD en
est encore au stade alpha) l2tpd
l'échange dynamique de clefs IKE, en utilisant racoon
A l'instar de FreeBSD et NetBSD, OpenBSD utilise KAME. La documentation relative
à l'utilisation d'IPsec sous OpenBSD.
Sont notamment supportés :
l'échange dynamique de clefs ISAKMP grâce
au logiciel isakmpd, qui supporte le mode agressif et l'utilisation de
certificats comme de clefs pré partagées, et la création de SAs avec des clients
d'adresse IP variables et attribuées dynamiquement, photuris peut également être
employé, mais il est encore en stade alpha et peu documenté
la création de tunnels PPTP (côté
client), grâce au port pptp
la création de tunnels PPTP (côté serveur), grâce au logiciel PoPToP
l'échange dynamique de clefs selon le standard Photuris, en s'appuyant sur le
logiciel photurisd
Si de nombreuses SA doivent être maintenues, compte tenu de la forte charge CPU
liée au chiffrement, il sera peut-être nécessaire d'avoir recours à l'une des
multiples solutions hard disponibles dans le commerce (Redcreek,
Timestep).
Nous conclurons cet article sur une mise en garde : il est fondamental, lors de
la mise en place de VPNs à l'aide d'IPsec de parfaitement comprendre à quoi la
protection va s'appliquer. Il est en effet très facile de commettre des erreurs
aux conséquences extrêmement graves. Par exemple, placer une passerelle de
sécurité derrière un firewall et configurer ce dernier pour laisser passer tout
trafic IPsec implique un paramétrage soigneux de la passerelle de sécurité, pour
éviter qu'un attaquant l'utilise pour contourner le firewall. Notamment, si
cette passerelle met en oeuvre le chiffrement opportuniste de l'implémentation
FreeS/WAN, le firewall peut ne plus être d'aucune utilité. Il est de manière
générale recommandé d'appliquer des règles de firewalling après au même titre
qu'avant les traitements IPsec (pour fixer les idées, une manière simple bien
qu'exorbitante d'appliquer ce conseil est de placer un premier firewall avant la
passerelle de sécurité et un second après cette passerelle).
En outre, le chiffrement des données ne doit pas créer l'illusion de la
sécurité, comme SSL l'a trop souvent fait : chiffrer n'est pas authentifier (un
attaquant peut très bien engager une conversation chiffrée avec une passerelle
de sécurité), et authentifier le système émetteur d'un datagramme à l'aide du
protocole AH ne suffit pas nécessairement à assurer la sécurité : si un
administrateur utilise un protocole permettant une authentification en clair
comme telnet, en encapsulant les données dans des datagrammes protégés par AH,
un attaquant pourra lire son mot de passe, et s'il est ensuite possible
d'établir des connexions non authentifiées à l'aide d'IPsec vers le système, ce
dernier peut alors être considéré comme compromis.
Ces deux exemples illustrent la complexité de la mise en place d'IPsec. Cette
complexité ne saurait que difficilement s'accommoder de solutions soi-disant
magiques et clefs en mains, paramétrées en quelques clics de souris. IPsec est
excessivement complexe, et masquer cette complexité derrière des interfaces
graphiques n'appelant pas les choses par leurs noms est aussi dangereux
qu'irresponsable (serait-il grand temps de mettre un terme à l'anarchie dans le
vocabulaire ?-D).
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos d'IPSEC. Pour cela,
rendez-vous sur le
Forum "Les
réseaux privées virtuels".
En mars 2002, par
Brieuc Jeunhomme, création du document.
|