Utilisateurs nomades et IPSec

François Morris Laboratoire de Minéralogie-Cristallographie

29/10/2002

 

Ce document est aussi disponible en format Word.

 

Je m’intéresse à la sécurisation des accès distants des utilisateurs nomades vers le réseau interne du laboratoire. Les besoins en ce domaine se font de plus en plus pressants. Le déménagement du laboratoire dans quelques mois va encore les accroître. Aujourd’hui IPSec est disponible en standard sous Windows 2000 et XP. Il existe un produit libre l’implémentant sous Linux. IPSec doit pouvoir permettre de réaliser à faible coût la sécurisation de ces accès distants.

Dans ce qui suit seront présentées la mise en œuvre d’une telle solution et les réflexions suscitées par l’expérience.

Plan

IPSec

Afin de faciliter la compréhension de ce qui va suivre il est utile de préciser quelques points concernant IPSec. IPSec a 2 modes de fonctionnement :

 

et 2 niveaux de sécurité

Mode tunnel

Dans ce mode les communications entre 2 machines A et B transitent par 2 passerelles G et H. On a donc le schéma suivant :

A ßà G ßà H ßà B

Les liaisons entre A et G ainsi que H et B ne sont pas sécurisées, tandis que celles entre G et H le sont. A peut être éventuellement confondu avec G, de même que H avec B. On peut donc avoir 3 types de tunnels :

L’en-tête d’un paquet IPSec contient les adresses IP des extrémités du tunnel (G et H), le protocole  esp (50) ou ah (51), il n’y a pas de numéro de port. Le contenu du paquet IPSec est sécurisé (authentifié et éventuellement chiffré). Outre les informations servant à sécuriser, il comprend le paquet IP original et donc les adresses IP et les ports des machines source et destination (A et B).

Mode transport

Dans ce mode on a une liaison directe entre deux machines. On a donc le schéma suivant :

A ßà B

 L’en-tête du paquet IPSec est celui du paquet IP original. Le contenu du paquet IP original est sécurisé par IPSec.

ESP

ESP (Encapsulating Security Payload) assure le chiffrement et l’authentification des paquets transmis.

AH

AH (Authentication Header) assure uniquement l’authentification de paquets transmis.

IKE

IKE (Internet Key Exchange) assure la négociation des paramètres de la connexion IPSec comme les algorithmes utilisés, les clés, les durées de vie). Le trafic se fait en UDP sur le port 500.

Différentes méthodes pour gérer les clés sont possibles :

Installation des produits

Linux

 

FreeS/WAN est une implémentation de IPSec pour Linux. RedHat constitue la distribution de référence pour le développement de FreeS/WAN. Il suffit de récupérer les rpm freewan et freeswan-modules  correspondant  à la version du noyau du système d’exploitation à l’URL suivante. L’installation est alors immédiate (rpm –i freeswan-*).

Cependant FreeS/WAN ne gère pas actuellement les certificats x509. Il faut alors récupérer un patch ainsi que le source de FreeS/WAN sous forme de tarball. Après extraction du source et application du patch on lance les commandes make programs suivi de make install ce qui a pour effet de reconstruire les commandes en « userland » sans toucher aux modules du noyau. En effet seules les commandes traitent des certificats x509. Ce court-circuit évite d’avoir à reconstruire un noyau. Attention le service IPSec doit avoir auparavant été arrêté (service ipsec stop) !

J’ai découvert par la suite qu’il existait des RPM de FreeS/WAN intégrant x509 à l’URL.

Pour d’autres distributions on sera conduit à reconstruire un noyau pour intégrer IPSec ce qui est un peu plus long.

Windows 2000

Windows 2000 est livré avec le support d’IPSec, il n’y a donc rien à installer. Il faut cependant avoir une version correspondant au « Service Pack » SP2 au moins.

Intégration des certificats x509

Linux

Le certificat utilisé est associé à la machine, lorsque l’on en fait la demande à l’IGC du CNRS il s’agit d’un « certificat serveur ».

Sous les répertoires /etc/ipsec.d/cacerts et /etc/ipsec.d/crls on installe les certificats des autorités de certification du CNRS ainsi que les listes de révocation associées. J’ai écris un script qui effectue cette action. Il peut être utilisé dans un crontab pour mettre à jour régulièrement les CRL. J’ai effectué une conversion de PEM en DER puisque que Windows exige ce dernier format pour les importations mais cela n’a rien d’obligatoire.

Sous le répertoire /etc/ipsec.d on copie le certificat de la machine et sous /etc/ipsec.d/private la clé associée. Attention pour d’évidente raisons de sécurité le fichier contenant la clé doit avoir root pour propriétaire et être accessible uniquement par celui-ci (chown root.root <clé> et chmod 400 <clé>).

On modifie le fichier /etc/ipsec.secrets en ajoutant en tête la ligne suivante :

: RSA <clé>

où <clé> est le nom du fichier contenant la clé privée (relatif au répertoire /etc/ipsec.d/private).

Windows 2000

Le certificat utilisé pour IPSec est associé à l’ordinateur et non pas à l’utilisateur comme on aurait pu l’imaginer ou le souhaiter pour une machine personnelle. D’après ce que j’ai pu comprendre Windows possède 3 catégories de magasins de certificats qui correspondent aux 3 comptes suivants :

 

Par ailleurs le magasin peut correspondre à un  magasin physique (carte à puce ou token USB) ou logique (rangé dans le registre). Cependant seul un utilisateur peut  avoir un magasin physique. Il n’est donc pas question de vouloir utiliser un token USB pour IPSec comme j’avais pu le penser un moment. En outre il n’est pas possible de protéger par un  mot de passe la clé privée associée au certificat de l’ordinateur car le processus doit pouvoir s’exécuter sans intervention humaine (il n’a pas de fenêtre pour demander un code).

L’attribut « personnel » pour un certificat indique simplement que ce n’est ni le certificat d’une autorité racine ni celui d’une autorité subordonnée. Il ne signifie pas nécessairement qu’il s’agit d’un certificat d’une personne physique, cela peut être aussi bien celui d’une machine ou d’un service. C’est une source de confusion.

Il est possible et même vivement conseillé de marquer la clé comme ne pouvant pas être exportée lors de l’importation du certificat. Ce qui signifie qu’il sera impossible de transférer sur une autre machine la clé privée. Du moins tant que l’on fait confiance à Windows. La clé est nécessairement rangée quelque part sur le disque et probablement chiffrée comme je l’espère (je n’ai pas vérifié) pour améliorer la sécurité. Il reste que le système doit pouvoir déchiffrer cette clé donc l’algorithme utilisée ne peut être totalement secret et résister à une ingénierie inverse. Un pirate qui a accès au disque doit pouvoir récupérer cette clé privée.

L’installation sous Windows est un peu délicate. Le certificat et la clé privée doivent être au préalable rangés dans un fichier au format PKCS#12. Actuellement avec l’IGC du CNRS il faut demander un certificat serveur. On doit alors fusionner dans un fichier au format PKCS#12 les fichiers récupérés contenant le certificat et la clé privée ainsi que les certificats de l’AC CNRS . J’ai écrit un script permettant d’effectuer cette opération.

Avec les privilèges de l’administrateur faut ensuite utiliser la MMC (Microsoft Management Console). Attention toute autre méthode pour essayer d’introduire le certificat comme ouvrir le fichier ou l’option certificat de « Utilisateurs et mot de passe » ne permet pas d’installer le certificat dans le bon magasin !

Création d’une console d’administration

La première étape consiste à créer une console d ‘administration. Il est possible de récupérer celle-ci. Dans ce cas on peut aller directement ici.

A partir du menu Démarrer sélectionner Exécuter puis entrer mmc et en enfin cliquer sur OK.

Dans le menu Console sélectionner Ajouter/Supprimer un composant de logiciel enfichable… cliquer alors dans la nouvelle fenêtre sur le bouton Ajouter… sélectionner alors Certificats

Cliquer sur le bouton Ajouter et dans la nouvelle fenêtre cocher la case Le compte de l’ordinateur. Attention c’est ce qui permettra par la suite de choisir le bon magasin de certificats !

 

 

Cliquez sur le bouton Suivant> et dans la nouvelle fenêtre cocher la case L’ordinateur local

 

 

Cliquer sur le bouton Terminer puis Fermer et enfin OK pour fermer les différentes fenêtres.

 

Importation du certificat

 

Se positionner sur Personnel et avec le bouton droit de la souris sélectionner Toutes les taches puis Importer…

 

 

Cliquez sur Suivant >

 

Spécifier le nom du fichier à importer et dans la fenêtre suivante donner le mot de passe et surtout ne pas cocher la case Marquer la clé privée comme étant exportable

 

 

Cliquer sur Suivant >  et dans la nouvelle fenêtre cocher Sélectionner automatiquement le magasin de certificats selon le type de certificats ce qui va permettre d’installer le certificat de ma machine dans le magasin « Personnel », celui de la racine CNRS dans « Autorités de certification racines de confiance » et celui de CNRS-Standard dans « Autorités intermédiaires »

 

 

Cliquer sur Suivant > puis Terminer.

 

Le certificat de la machine ainsi que ceux de l’AC CNRS sont alors installés.

Il est théoriquement possible et souhaitable d’installer les listes de révocations mais je ne le conseille pas vraiment. En je n’ai pas réussi à les faire fonctionner (cf. ci-dessous).

Configuration

Dans ce qui suit on va s’intéresser à la connexion des ordinateurs des nomades vers le réseau interne du laboratoire à travers un passerelle IPSec. Je préfère le terme de nomade à celui de « road warrior » qui est souvent employé. Chacun a ses références, les miennes sont moins belliqueuses.

Passerelle Linux

Les informations de configuration se trouve dans le fichier /etc/ipsec.conf.

Dans l’exemple n° 1 on notera les points particuliers suivants. On a 2 connexions « nomade » pour la liaison entre le poste nomade et la passerelle et « nomade-net » pour celle entre le poste nomade et le réseau situé derrière la passerelle. « nomade-net » a les mêmes paramètres que « nomade » ce qui est indiqué par le paramètre also à l’exception de leftsubnet qui définie le réseau derrière la passerelle. Il est possible dans le cas particulier où l’adresse de la passerelle appartient au même réseau que celui défini par leftsubnet de ne définir que la  seule connexion « nomade-net ». leftcert définit le certificat utilisé par la passerelle. Leftupdown définit un script utilisé lors de l’établissement d’une nouveau tunnel IPSec. Pour des raisons que l’on précisera par la suite on est souvent amené à modifier des paramètres de routage en fonction du contexte local. N’importe quel nomade ayant un certificat valide et non révoqué peut se connecter. Généralement on souhaite pouvoir contrôler les certificats et donc les machines ayant le droit de se connecter. Cela peut se faire comme dans l’exemple n° 2. La directive include définit un répertoire dans lequel on a un fichier de configuration par poste nomade ce qui facilite l’administration. Voici un exemple d’un tel fichier. Il faut noter rightid qui définit le « subject » du certificat du poste nomade.

Si le contrôle de validité des adresses sources est activé dans le noyau on peut rencontrer des problèmes il faut donc le désactiver :

echo  0 >  /proc/sys/net/ipv4/conf/<device>/rp_filter

Pour s’en apercevoir il faut tracer les paquets « martiens » :

echo 1 > /proc/sys/net/ipv4/conf/<device>/log_martians

 

Nomade Windows 2000

La configuration de IPSec sous Windows 2000 est plutôt complexe. Elle fait appel à ce qui est appelée « Stratégie de sécurité IP ». Pour simplifier elle est constituée d’un ensemble de règle. Chaque règle est constitué d’un filtre IP classique (protocole, adresse source, port source, adresse destination, port destination) auquel on associe un certain nombre d’attributs (utiliser ou non IPSec, adresse IP de l’extrémité du tunnel, options de chiffrement). Pour un tunnel if faut de règles, une dans chaque sens. La MMC (Microsoft Management Console) permet à l’aide d’une myriade de fenêtres de définir cette stratégie de sécurité. Pratiquement c’est inutilisable, il suffit de dénombrer le nombre de fenêtres dans l’exemple suivant pour s’en convaincre. Heureusement on trouve sur le site de ebootis un utilitaire permettant à partir d’un fichier texte au format semblable à celui de FreeS/WAN de définir la stratégie de sécurité. C’est la méthode que j’utilise. Cette utilitaire ipsec.exe utilise la commande ipsecpol.exe (ipseccmd pour Windows XP) ainsi que les dll ipsecutil.ddl et text2pol.dll disponibles dans le « Windows 2000 Resource Kit » ou directement à l’URL . Le fichier de configuration porte le nom de ipsec.conf en voici un  exemple right est l’adresse de la passerelle et rightsubnet est le réseau derrière la passerelle. rightca définit le certificat racine du CNRS. Ce certificat est utilisé par IPSec une première fois pour vérifier le certificat envoyé par la passerelle et une deuxième fois pour choisir le certificat à envoyer à la passerelle. En effet IPSec a un fonctionnement un  peu curieux, on ne spécifie pas le certificat à utiliser mais celui de la racine dont dépend le certificat. Il recherche alors dans le magasin de certificats personnel associé à l’ordinateur un certificat dépendant de la racine auquel est associée une clé privée. Je n’ai pas étudié le comportement  s’il y a plusieurs certificats qui répondent à ce critère.

 

Une difficulté à laquelle on est confronté est que l’adresse de l’extrémité du tunnel correspondant au poste nomade est  fixée dans la stratégie de sécurité. Or par définition pour un nomade cette adresse change régulièrement. Il faut donc à chaque fois lancer l’utilitaire ipsec.exe pour établir une nouvelle stratégie de sécurité. La commande ipsecpol.exe doit nécessairement s’exécuter avec les privilèges de l’administrateur ce qui n’est pas forcément compatible avec le fait que l’on veuille restreindre les privilèges de l’utilisateur. L’astuce que j’ai trouvée est de lancer une tache s’exécutant sous l’identité de l’administrateur au démarrage de chaque connexion d’utilisateur.

 

A vrai dire ce que l’on fait ici est totalement contraire à ce que préconise Microsoft. Pour la petite histoire mais cela peut expliquer certaines choses, IPSec sur Windows 2000 de même que le protocole L2TP ont été développés conjointement entre Microsoft et Cisco. Pour Microsoft en matière de VPN la solution est d’utiliser L2TP (un avatar de PPP) au dessus d’IPSec. Dans ce cas c’est L2TP qui gère le tunnel, permet l’authentification (PAP, CHAP) et pourrait aussi ce qu’il faut évidemment éviter assurer la confidentialité en chiffrant. IPSec est utilisé en mode  « transport » pour le chiffrement. Cet empilement de couches ne me satisfait pas. Il a pour seul but de circonvenir le fait que les extrémités des tunnels IPSec ont des adresses IP fixes. Il est vrai que IPSec a d’abord  été prévu pour interconnecter des réseaux à travers des passerelles qui elles ont des adresses IP fixes. Nous avons vu qu’avec FreeS/WAN sur la passerelle il est possible de gérer des nomades ayant des adresses qui varient par définition et d’adapter les tables de routages en conséquences. Pour le nomade Windows 2000 nous avons un outil pour reconfigurer automatiquement le tunnel pour tenir compte son adresse IP. Il existe aussi des clients à installer sous Windows pour créer des VPN uniquement IPSec. Je n’en connais pas de gratuit. La solution que j’utilise me semble élégante, n’exige rien de particulier sur le poste nomade. Pourquoi s’en priver ?

 

Le fait que l’on utilise des règles de filtrage pour déterminer les trafic IPSec, permet de ne sécuriser que ce qui est vraiment utile et de conserver des connexions IP normales pour le reste. IPSec est une stratégie de sécurité et peut donc être administré, diffusé en utilisant le mécanisme habituel de Windows c’est à dire « Active directory ». Si cette méthode est difficilement utilisable dans le cas de nomade elle peut être très intéressante sur le réseau interne pour ouvrir automatiquement des tunnels IPSec vers des services particuliers. Cela peut être une excellente solution pour sécuriser des connexions vers des applications

anciennes qu’il est difficile de modifier.

Quelques astuces

La façon la plus simple de réinitialiser IPSec est de lancer successivement les commandes :

net stop policyagent

net start policyagent

Pour obtenir un fichier journal il faut créer dans le registre la clé

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley

Et lui affecter une valeur de type REG_DWORD ayant pour nom EnableLogging et 1 comme contenu. Le fichier journal a pour nom \WINNT\DEBUG\oakley.log.

 

Conflit d’adresse IP

Après un redémarrage  il peut arriver que Windows refuse d’attribuer l’adresse IP à l’interface avec le message « Le système a détecté un conflit d’adresse IP avec un autre système sur le réseau. L’interface locale a été désactivée. » Cela est dû au fait qu’au démarrage de la pile IP, Windows envoie des requête ARP et écoute le trafic sur le réseau pour essayer de déterminer si une autre machine n’a pas la même adresse IP. Si la passerelle IPSec a toujours dans ses tables qu’elle doit faire du « proxy ARP » pour cette machine évidemment il va y avoir un conflit. La situation ne peut arriver que si le poste nomade est sur le même réseau Ethernet que la passerelle IPSec. Pratiquement cela n’arrive que lors de tests, évidemment cela m’est arrivé. Un méthode brutale mais efficace pour régler le problème est de redémarrer le service ipsec sur la passerelle. Je n’ai pas poussé plus loin l’analyse, ni cherché de solution plus élégante sachant que la situation n’arrivera pas dans un fonctionnement normal où le nomade est à l’autre bout du monde.

 

Nomades Linux

La configuration du poste nomade est tout à fait semblable à celle de la passerelle. Je donne un exemple du fichier ipsec.conf.

Routage et filtrage

Trafic IPSec

Il est nécessaire de laisser passer le trafic IPSec au niveau des routeurs et pare-feux. Cela concerne :

·        protocole 17 (UDP) port 500 (isakmp) : échange des clés

·        protocole 50 (ESP) :  IPSec avec chiffrement

·        protocole 51 (AH) :  IPSec sans chiffrement

 

Tout le trafic IPSec transitant dans un tunnel chiffré il n’est plus possible d’effectuer du filtrage au niveau du routeur ou du pare-feu. De même les détecteurs d’intrusion ne verront rien. Ce n’est pas parce que  l’interlocuteur est connu et authentifié qu’il faut renoncer à tout contrôle. A ce sujet rappelons que ce n’est pas une personne physique qui est authentifiée mais une machine ce qui offre moins de garanties. Il est donc judicieux d’effectuer un filtrage à la sortie du tunnel lorsque l’on retrouve de l’IP classique non chiffré. Cela peut se faire  en interposant un routeur ou pare-feu entre la passerelle et le réseau interne ou bien directement sur la passerelle en utilisant les possibilités de filtrage offertes par le noyau (commande iptables).

Au niveau du nomade il faut que le trafic isakmp ne transite pas dans le tunnel. Pour Windows 2000 il y a ce qui est appelée une exemption. Tout ce qui concerne UDP port 500, de même que les « broadcasts » et « multicasts ».

Fragmentation

Le protocole ISAKMP d’échange de clés utilise des datagrammes IP (UDP port 500). UDP à la différence de TCP n’a aucun mécanisme de fragmentation en propre et repose entièrement sur IP pour fragmenter et réassembler les paquets. Il arrive régulièrement que la taille de ces datagrammes dépasse le MTU (1500 en général) notamment pour ceux contenant les certificats qui peuvent être assez volumineux. Dans ce cas on a un paquet IP composé de plusieurs fragments. Le premier fragment contient les adresses et ports source et destination, un numéro d’identification, les suivants ne contiennent que les adresse source et destination et le numéro permettant d’assurer le lien avec le paquet IP précédent à l’exclusion des ports. Cela complique la réalisation de filtres et encore plus de mécanismes de traduction d’adresses NAT.

J’ai constaté que certains outils de filtrage sensés améliorer la sécurité ne laissaient passer que le premier fragment en ignorant les suivants. Il est vrai que de nombreuses attaques ont utilisé la fragmentation des paquets IP. Par exemple un pare-feu personnel dont l’utilisation est par ailleurs indispensable, peut en fonction de la configuration, bloquer tous les fragments suivants d’un datagramme UDP sortant. Utilisant ZoneAlarm j’ai dû adapter sa configuration pour laisser passer les fragments.

La gestion correcte de la fragmentation avec les dispositifs de traduction d’adresse est délicate sinon impossible dans certains cas (cf. RFC 3022). Comme la fragmentation est quasiment obligatoire avec ISAKMP cela pose des problèmes pour l’utilisation de IPSec avec des réseaux « NATés ». Des réflexions sont en cours, il existe à ce sujet un RFC à l’état de draft. Afin de vérifier si les fragments transitent bien sur le réseau on peut utiliser la commande ping . Ceci évidemment si les requêtes ICMP ne sont pas filtrées quelque part sur le réseau. L’idée est de choisir des paquets ICMP dont la taille dépasse le MTU pour force la fragmentation. Pour déterminer la taille du MTU on spécifie une taille en interdisant la fragmentation. Par exemple avec un MTU habituel de 1500 :

ping –f –l 1472 host sous Windows ou ping –M do –s 1472 host sous Linux doit passer et

ping –f –l 1473 host sous Windows ou ping –M do –s 1473 host sous Linux doit être refusé

ping –l 1473 host sous Windows ou ping –s 1473 host sous Linux doit passer si la fragmentation transite correctement sur le réseau.

D’après les informations que j’ai pu glaner sur Internet, il semblerait qu’un certain nombre de matériels effectuant de la traduction d’adresses ne gère pas correctement la fragmentation. Ce serait en particulier le cas de routeurs bon marché assurant la connexion au câble ou à ADSL.

Ouverture du réseau interne

Attribution d’une adresse IP au nomade

Mascarade d’adresse

Le poste nomade a par définition une adresse IP variable dont même le numéro de réseau est inconnu a priori . Pour faciliter la gestion du réseau et en particulier le filtrage il serait intéressant de pouvoir fixer cette adresse dans une certaine plage appartenant à un réseau interne. Cela peut être réalisé sur la passerelle IPSec à l’aide de iptables :

iptables –t nat –D POSTROUTING –s <nomade_ext> -j SNAT –to-source <nomade_int>

iptables –t nat –D PREROUTING –d <nomade_int> -j DNAT –to-destination <nomade_int>

Où <nomade_ext> est l’adresse IP du poste nomade sur Internet  et <nomade_int> celle que l’on veut lui attribuer sur le réseau interne. Pour communiquer entre le nomade et le réseau interne on utilisera l’adresse <nomade_int>.

 

DNS dynamique

Il est aussi possible d’attribuer à cette adresse IP dans le DNS dynamiquement le nom correspondant au certificat de la machine nomade. Cela peut faciliter l’administration en permettant de savoir tout de suite quelle machine est concernée sans avoir à explorer différentes tables pour trouver  la correspondance. Evidemment ce DNS dynamique n’a pas à être publié au monde entier. Avec la commande nsupdate cela peut des réaliser de la façon suivante :

nsupdate << EOF

update add <nom> 60 A <nomade_int>

update add <ip_arpa> 60 PTR <nom>.

send

EOF

<nom> est le nom que l’on veut donner à la machine comme par exemple pc-martin.machines.xx.yy.fr . Ce nom correspond à la valeur du CN du certificat.

Pour faciliter l’administration du serveur DNS, séparer ce qui est dynamique de ce qui ne l’est pas, établir des contrôles d’accès,  il est judicieux de prévoir une sous-zone particulière ici machines.xx.yy.fr. <ip_arpa> est l’adresse IP dans la pseudo zone in-addr.arpa par exemple 1.2.3.10.in-addr.arpa

Protection du poste nomade

Il ne faut surtout pas oublier que si IPSec sécurise les liaisons entre le laboratoire et le poste nomade, ce dernier est connecté directement à Internet sans la protection offerte par les routeurs ou pare-feux qui isolent le réseau interne. Il est donc impératif d’installer sur le poste nomade un pare-feu individuel.

Pour Linux un script à base de commandes iptables répond parfaitement au besoin et peut de plus être couplé avec FreeS/WAN pour gérer dynamiquement les contrôles en fonction des tunnels ouverts.

Tunnels et sous-réseaux

Les sous-réseaux accessibles à travers des tunnels IPSec ne doivent pas nécessairement recouvrir exactement le réseau interne. On peut définir plusieurs sous-réseaux disjoints ou non. On a une grande liberté de configuration.

Généralement seul un nombre limité de machines du réseau interne a besoin d’être accessible de l’extérieur. On définira dans la configuration un sous-réseau contenant ces machines mais plus restreint que le réseau interne. C’est un moyen supplémentaire d’assurer un contrôle de trafic dont on aurait tort de se priver. En matière de sécurité il généralement bon de mettre des contrôles partout où c’est possible ceci afin de se prémunir d’éventuelles failles dans les produits ou de possibles erreurs de configuration.

On peut aussi permettre à un poste nomade de se connecter à une machine externe en transitant par la passerelle IPSec. Le nomade apparaîtra pour cette machine externe comme faisant parti du réseau interne (son adresse IP est celle d’une machine interne). Cela permet de traiter des situations où le contrôle sur la machine distante se fait à partir de l’adresse IP.  source.

Où placer la passerelle ?

Il n’est pas nécessaire d’avoir plusieurs interfaces Ethernet pour la passerelle, une seule suffit. Le fait de faire transiter les trafics interne et externe sur la même interface n’est pas pénalisant en terme de performances tant que la puissance des processeurs ne permet pas de saturer la liaison Ethernet.

Différentes architecture sont possibles  L’important que l’on puisse joindre la passerelle à la fois depuis l’extérieur (UDP port 500, protocoles 50 et 51) et depuis l’intérieur (tout trafic IP pertinent). Il ne faut pas oublier qu’il faut un chemin passant par la passerelle dans les deux sens. La principale difficulté est d’établir les bonnes routes.

 

J’ai  effectué des essais avec la passerelle en deux endroits :

 

Réseau interne

Il faut configurer les routeurs et firewalls pour accepter le trafic IPSec (UDP port 500, protocoles 50 et 51) entre l’extérieur et la passerelle et refuser tout autre trafic.

FreeS /WAN établit automatiquement une route de retour pour faire passer tout le trafic IP reçu sur la passerelle et  à destination du poste nomade par IPSec. Le trafic IPSec reçu de l’extérieur est décodé et envoyé en IP vers les machines internes sans problème puisque celles-ci sont directement accessibles depuis la passerelle.

Par contre la difficulté consiste à envoyer depuis une machine interne un paquet IP à destination du poste nomade. Comme on utilise généralement des routes fixes (route par défaut) sur les machines internes il n’y a pas de moyen simple de faire transiter par la passerelle un paquet à destination d’une adresse externe. Si  la passerelle fait de la mascarade d’adresse pour présenter le poste nomade avec une adresse interne (cf. ci-dessus) et en plus fait du « proxy arp » pour cette adresse le problème est réglé.

arp –i <interface> -Ds <nomade_int> <interface> pub

où <interface> est le nom de l’interface Ethernet reliant la passerelle au réseau interne et

<nomade_int> est son adresse IP dans le réseau interne.

Cette architecture est la plus simple pour débuter des essais sans avoir à modifier trop de choses dans le routage/filtrage du réseau.

IPSec intégré au pare-feu

C’est la solution qui me semble la plus logique. Il n’a plus comme précédemment le délicat problème de routage d’une machine interne vers le poste nomade. Comme j’utilise comme pare-feu une machine Linux je n’ai eu aucune difficulté à ajouter la gestion de IPSec. De fait IPSec introduit de nouvelles interfaces ipsecn tout à fait semblables aux ethn et on peut appliquer des règles de filtrage analogues.

Script _updown

FreeS/WAN fait appel au script _updown à chaque changement d’état d’une liaison IPSec. J’ai modifié le script existant pour gérer l’attribution du numéro IP de poste nomade, mettre à jour le DNS et régler les problèmes de routage. On en trouvera une copie ici. Dans le fichier de configuration ipsec.conf il faut ajouter une directive leftupdown contenant le nom de ce fichier.

Performances

J’ai utilisé pour évaluer les performances le transfert par FTP d’un gros fichier (200 Moctets). La passerelle IPSec est un Pentium III à 450 Mhz et avec 256 Moctets de mémoire. Le poste client est un portable Dell Latitude avec un Pentium III à 1,1 GHz et 256 Moctets de mémoire.

Ce qui est cohérent avec ce qui est indiqué dans la documentation de FreeS/WAN. Le facteur limitant est la passerelle. Il faut noter que les développeurs de FreeS/WAN considérant que le simple DES n’est pas suffisamment sûr ont fait le choix de n’implémenter que le triple DES. AES est aussi en cours d’intégration. D’après des premières indications ont peut en attendre un gain d’un facteur 2 environ.

Ces performances sont tout à fait acceptables pour sécuriser les connexions de nomades depuis l’extérieur ou les machines reliées à un réseau sans fil. Il ne semble par contre pas raisonnable de vouloir sécuriser toutes les connexions sur le réseau local en utilisant IPSec.

 

Retour d’expériences et quelques réflexions

Actuellement IPSec n’est utilisé que par moi-même.

VPN

Il est possible de considérer des postes nomades comme faisant parti du réseau interne du laboratoire tout en conservant une bonne sécurité. Avec mon ordinateur portable sous Linux j’ai pu ainsi effectuer sans problème sous Linux du partage de fichiers NFS et sous Windows du partage de fichiers CIFS. Je ne suis pas certain que dans la réalité cela soit vraiment une bonne idée. Mais si pour de bonnes ou mauvaises raisons on est amené à faire du partage de fichiers,  la bonne solution consiste à utiliser IPSec. De toute façon ce test est exigeant en matière de réseau et est une bonne validation des possibilités offertes par IPSec.

Listes de révocation et Windows 2000

A ce jour je n’ai pas réussi à faire fonctionner le mécanisme de liste de révocation pour Windows. J’ai bien trouvé comment l’activer : il faut affecter à la clé

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley

une valeur de type REG_DWORD ayant pour nom StrongCrlCheck et 1 (ou 2 pour être plus strict) comme contenu. Le fichier journal oakley.log indique que IPSec et incapable de trouver les CRPs (certificate revocation list distribution point). A priori cette information est pourtant bien disponible dans les certificats produits par l’IGC du CNRS. Un analyseur réseau montre qu’il n’a pas la moindre connexion vers l’URL indiquée dans le certificat. Peut-être est ce lié à un problème de compatibilité dans le format du certificat ?

 

Déploiement

Si la configuration est un peu délicate, l’utilisation est très simple. Il suffit de connecter le poste nomade à un réseau local utilisant DHCP et tant sous Linux que Windows 2000 automatiquement on s’intègre au réseau interne du laboratoire.

 

Comparaison de différents tunnels

IPSec n’est pas la seule façon pour forer des tunnels à travers Internet. On peut utiliser SSH, PPP (L2TP ou PPTP), des produits comme OpenVPN.  Il possède à mon avis quelques atouts.

IPSec est normalisé et devrait être inter-opérable sur les différentes plates-formes.

Les tunnels sont spécifiés directement au niveau du paquet IP sans encapsulage dans un autre protocole. Cela devrait être nettement plus efficace car tout peut être traité par le noyau sans avoir à échanger des données avec un processus en zone utilisateur (démon sshd, pppd) comme pour les autres solutions. Il est aussi possible d’appliquer des règles de filtrage à l’extrémité du tunnel comme pour n’importe quelle autre interface. Ceux qui ont essayé de contrôler ce qui transite par un tunnel SSH apprécieront.

Certificats

Les certificats utilisés par IPSec sont associés à la machine et non à une personne physique. Qui plus est il est quasiment impossible de protéger par un mot de passe la clé privée. IPSec apporte une bonne garantie que l’on dialogue avec la bonne machine mais n’offre rien en matière d’authentification de l’individu. Le risque le plus banal est le vol de l’ordinateur portable. Il faut être suffisamment réactif dans la gestion  des listes de révocation. La protection de la clé privée repose entièrement sur le système d’exploitation.

IPSec n’est absolument pas exclusif de l’utilisation de méthodes complémentaires pour l’authentification des personnes. Si on utilise des solutions comme SSH ou SSL/TLS qui ne permettent pas de séparer authentification et confidentialité cela conduit à empiler plusieurs chiffrements.

IGC CNRS

Actuellement l’IGC du CNRS délivre deux types de certificats, des certificat personnels et des certificat serveurs. Pour IPSec le certificat est lié à la machine, le plus approprié est un certificat serveur. Cependant j’ai rencontré quelques difficultés.

Une adresse email est spécifiée dans le « subject » du certificat ce qui allonge la taille des informations à donner dans les fichiers de configuration. Je pense que l’on pourrait s’en dispenser puisque ce certificat ne va jamais être utilisé pour le courrier électronique. De toute façon il existe un autre champ du certificat x509 pour définir une adresse de courrier électronique qui est exploitable par la dernière version de S/MIME.

Pour un certificat serveur la clé est générée par l’AC et on récupère le certificat et la clé dans deux fichiers séparés ce qui est bien adapté pour un poste nomade sous Linux mais pas vraiment sous Windows 2000 où il faut un  fichier PKCS#12. Par ailleurs on peut se poser la question de l’endroit où doit être générée la clé privée, pourquoi sur l’AC et non pas sur la machine à laquelle est attribuée le certificat.

Une autre question. Pour IPSec qui doit faire la demande et l’installation du certificat : l’utilisateur du poste nomade ou l’administrateur ? Il n’y a pas forcément de réponse unique.

AH

On a souvent besoin de sécurité (intégrité, authentification, anti-rejeu) sans exiger  nécessairement la confidentialité. AH est adapté à cette situation et a l’avantage de consommer moins de ressources (pas de chiffrement). Cependant avec FreeS/WAN pour utiliser AH il faut démarrer manuellement les tunnels. Ce n’est pratiquement pas utilisable dans notre contexte.

Par ailleurs tant qu’il existera sur nos réseaux des applications utilisant des mots de passe en clair il ne sera pas sain de ne pas chiffrer les connexions des postes nomades.

Par conséquent  nous utilisons uniquement ESP.

Tunnel pour relier des sous-réseaux

 Dans le cadre du déménagement prochain et afin de faciliter le déplacement des machines je compte établir un tunnel IPSec pour relier les réseaux de départ et d’arrivée. Cela ne pose aucune difficulté, c’est bien plus simple que gérer un VPN pour des nomades.

Sécurisation d’applications existantes

Une autre application d’IPSec, tout à fait à l’opposé du poste nomade, me paraît intéressante. Il s’agit de sécuriser des applications existantes n’intégrant pas elles-mêmes des mécanismes d’authentification forte et de chiffrement  (SSL/TLS,  SSH). L’utilisation d’un tunnel entre le client et  le serveur évite de modifier les logiciels sur le serveur et les clients. Sous Windows 2000 la configuration de IPSec fait partie intégrante de la stratégie de sécurité et peut donc être diffusée automatiquement à partir d’ « Active Directory ».

Conclusions

Nous avons vu comment il est possible de mettre en œuvre un VPN pour des postes nomades sous Windows 2000 ou Linux en utilisant une passerelle sous Linux. Si ce n’est pas la panacée pour sécuriser les accès distants c’est une solution qui répond dans un certain nombre de cas au besoin de sécurité.

 

Références

RFC

 

Windows 2000

Linux