Xvpnd - extended VPN Dæmon. Jonathan DERQUE Jean-François SMIGIELSKI 30 mai 2005

Xvpnd - extended VPN Dæmon Jonathan DERQUE Jean-François SMIGIELSKI 30 mai 2005 1

Table des matières 1 Introduction 5 2 Contexte 6 2.1 Présentation des VPN................................... 6 2.1.1 Introduction..................................... 6 2.1.2 Présentation générale............................... 6 2.1.3 Conclusion..................................... 7 2.2 Présentation d IPSec.................................... 7 2.2.1 Introduction..................................... 7 2.2.2 Présentation générale............................... 8 2.2.3 Modes de fonctionnement............................. 8 2.3 Les associations de sécurité................................ 9 2.3.1 Conclusion..................................... 9 2.4 Notre situation........................................ 9 2.4.1 Sujet......................................... 9 2.4.2 Xvpnd en action.................................. 10 3 Implémentation 15 3.1 Présentation générale du dæmon et des sources.................... 15 3.2 Séquence de démarrage.................................. 16 3.3 Récupérer des paquets................................... 17 3.3.1 Présentation..................................... 17 3.3.2 Des solutions envisagées à la solution retenue................. 17 3.3.3 Dernières considérations.............................. 18 3.3.4 Difficultés rencontrées............................... 18 3.4 Réinjecter les paquets.................................... 18 3.4.1 Problèmes liés à l injection............................. 18 3.4.2 Nos solutions à ces problèmes.......................... 19 3.5 Plugins............................................ 20 3.5.1 Flexibilité, extensibilité............................... 20 3.5.2 Problèmes liés aux plugins............................ 21 3.6 Transporter des paquets.................................. 21 3.6.1 Caractéristiques du transport de paquets.................... 21 3.6.2 Des solution envisagées à la solution retenue.................. 22 3.7 Effets des incohérences................................... 23 3.7.1 Cohérence sur une passerelle........................... 23 3.7.2 Cohérence entre passerelles............................ 23 4 L infrastructure de test 25 5 Limitations et perspectives d évolutions 27 6 Conclusion 29 7 Utilisation 30 7.1 Compilation et installation................................. 30 7.2 Configuration........................................ 30 7.3 Démarrage.......................................... 31 7.4 Pour plus de renseignements................................. 32 2

Remerciements Nous tenons à remercier Philippe Dumont et Eric Piel pour leur accompagnement et leur soutien, pour les tests innombrables réalisés et la liberté de choix qu ils nous ont accordée. Nous espérons en avoir tiré le meilleur parti. Nous tenons en outre à remercier toute l équipe West du LIFL pour nous avoir accueilli en ses locaux et avoir mis à notre disposition le matériel nécessaire à une infrastructure de test efficace. 3

1 Introduction La sécurité occupe une place de plus en plus importante dans l informatique. Paradoxalement, la plupart des communications qui circulent dans les réseaux informatiques ne sont pas chiffrées. Il est plus alarmant de savoir que même les mots de passe des utilisateurs circulent en clair dans bien des cas et sont susceptibles d être récupérés facilement par une personne mal intentionnée. Dans certains cas, seul le chiffrement de certaines données sensibles peut suffire (authentification par mot de passe), mais souvent l ensemble des données doit être caché (les applications bancaires par exemple). Les techniques de chiffrement s étant démocratisées, l utilisateur normal est en droit d exiger un maximum de sécurité pour l ensemble des données circulant sur le réseau. Dans le cas de plusieurs sous-réseaux distants reliés par l internet, il existe une solution : le VPN 1. Nous nous somme intéressés à une catégorie de VPN chiffrant leurs communications entre les passerelles au moyen du protocole IPsec. Malheureusement, les VPNs basés sur IPSec ne supportent qu une partie des protocoles au dessus d IP. Notre projet consista donc à développer un outil permettant le support de protocoles additionnels pour les VPNs basés sur IPSec. Le présent document présente donc cet outil, xvpnd, ainsi que la démarche qui a conduit à son élaboration. 1 Virtual Private Network 4

2 Contexte 2.1 Présentation des VPN 2.1.1 Introduction Le principe des réseaux privés repose sur le principe que les données circulant sur ce réseau sont cachées du grand public. Un moyen facile pour parvenir à ce but est d isoler le réseau d internet. Dans le cas d une entreprise ayant plusieurs agences ou partenaires répartis dans des endroits éloignés, le problème est plus délicat. Une première solution consiste à utiliser des lignes téléphoniques dédiées. Cette méthode est plutôt coûteuse pour de petites entreprises. Le VPN s impose alors comme une bonne alternative. Un VPN est un mécanisme reliant un ensemble de machines avec pour objectif de faire croire à l existence d un unique réseau les reliant. 2.1.2 Présentation générale Supposons que l on ait deux réseaux A et B et que l on veuille faire communiquer de façon sure les machines du sous réseau A avec les machines du sous réseau B (voir figure 1). Pour cela, on va installer un VPN entre ces deux sous réseaux. Le seul pré-requis est que l on doit munir A 0 et B 0 d adresses publiques (c est à dire que ces deux machines peuvent être désignées par ces adresses uniques sur internet), car le VPN doit pouvoir transporter nos informations à travers internet vers la bonne machine. La seule façon de désigner cette machine est de la munir d une adresse publique. Une fois le VPN en production, les informations circulant entre A 0 et B 0 (mais pouvant être émises ou à destination d autres machines des réseaux A et B) sont chiffrées et donc inintelligible pour une personne extérieure. Par contre, le VPN ne protège les données que vis-à-vis d une personne extérieure aux réseaux reliés par VPN. Si une personne s est introduite dans l un des sous-réseau, rien ne l empêche de récupérer les informations circulant dans tout le VPN. L adressage des machines d un réseau à l autre se fait alors de façon transparente, c est-à-dire que pour les machines du réseau A, les machines du réseau B sont des machines locales (comme si le VPN et internet n existaient pas), et inversement. Un VPN est donc un moyen d isoler des communications, afin de faire circuler des informations privées sur un réseau public. La mise en place de ce tunnel permet d accomplir les tâches suivantes : la confidentialité des données circulant dans le tunnel ; l authentification des machines distantes ; l intégrité des messages. Pour s acquitter de ces tâches,les VPN s appuient généralement sur des protocoles dédiés au tunneling. Parmi eux, on trouve : PPTP développé par Microsoft, est un protocole de niveau 2. L2F développé par Cisco. Ce protocole de niveau 2 est maintenant obsolète ; L2TP développé par l IETF est un protocole reprenant les fonctionnalités de PPTP et L2F. IPSec (cf. section 2.2) développé lui aussi par l IETF. L organisation des réseaux hors du tunnel n a pas d importance. De multiples architectures sont envisageables : d un réseau où chaque machine est est connectée à chaque autre (fullymeshed) à un réseau organisé en étoile autour d un hub. De plus, la mise en place d un VPN peut être soit matérielle soit logicielle. 5

A 1 192.168.0.11 B 1 192.168.0.21 A 2 192.168.0.12 A 0 10.0.0.1 B 0 10.0.0.2 B 2 192.168.0.22 A 3 192.168.0.13 internet B 3 192.168.0.23 FIG. 1 exemple de VPN 2.1.3 Conclusion Au milieu de toutes ces possibilités, le type de VPN avec lequel nous avons du travailler est organisé en sites reliés entre eux par des machines passerelles, une par site. Chaque passerelle possède une ou plusieurs interfaces, chacune reliée à un sous-ensemble du réseau. 2.2 Présentation d IPSec 2.2.1 Introduction IPSec 2 est un protocole de niveau 3, développé par l IETF 3 afin de fournir un véritable standard répondant aux attentes du tunneling, des VPN et de la sécurisation des réseaux IP. IPSec fut à l origine développé pour IPv6 (dont il fait partie intégrante), mais fut adapté pour IPv4. IPSec est disponible sur un grand nombre de système d exploitation : Windows, Linux, BSD... 2.2.2 Présentation générale Le but premier d IPSec est de fournir des services de sécurité, tels que : authentification (via des signatures DSS ou RSA) ; confidentialité des données échangées (via DES, triple DES, Blowfish, etc...) ; intégrité des données échangées (via SHA1, MD5, etc...). IPSec va donc transformer les données pour les "sécuriser". Le tableau suivant montre la place d IPSec au sein des couches de protocoles. APPLICATION TCP UDP IPSec IP Pour effectuer ces diverses tâches, IPSec s adjoint les services de protocoles annexes : 2 Internet Protocol Security, RFC 2401 3 Internet Engineering Task Force 6

IKE 4 établit des tunnels de maintenance : il ne sert pas a la transmission des données. Son rôle est d établir une première connexion entre les machines distantes. AH 5 dont le rôle principal est d établir les identités. AH n a pas de capacité de chiffrement des données, mais des mécanismes qui s assurent de l intégrité des données est présent. ESP 6 qui possède également des fonctionnalités d authentification et d intégrité, mais fournit en plus des possibilités de chiffrement des données. 2.2.3 Modes de fonctionnement On distingue 2 principaux modes de fonctionnement pour IPSec : transport ; tunnel. Le mode tunnel est plus riche en fonctionnalités et est donc plus intéressant que le mode transport, malgré une utilisation plus gourmande des ressources. Mode Transport Le mode Transport a la particularité de ne pas modifier l entête du paquet IP. AH insère simplement son en-tête entre l en-tête IP et l en-tête TCP ou UDP. IP AH TCP/UDP DATA ESP chiffre uniquement la partie TCP/UDP + DATA, après insertion de son en-tête. IP ESP TCP/UDP DATA On peut également utiliser conjointement AH et ESP comme suit : IP AH ESP TCP/UDP DATA Mode Tunnel Le mode Tunnel, lui, ajoute un nouvel en-tête IP et encapsule complètement le paquet et son en-tête IP d origine. AH insère son en-tête entre les deux en-tête IP. IP A AH IP B TCP/UDP DATA En ce qui concerne ESP, le datagramme original est chiffré dans son intégralité et encapsulé dans un nouveau paquet. Un en-tête ESP est inséré entre l en-tête IP et le paquet chiffré. IP A ESP IP B TCP/UDP DATA Mode Nesting Le mode Nesting est un mode hybride qui reprend les caractéristiques des deux modes précédents. IP A AH IP B ESP TCP/UDP DATA IP A ESP IP B AH TCP/UDP DATA 4 Internet Key Exchange, RFC 2409 5 Authentification Header, RFC 2402 6 Encapsulating Security Payload, RFC 2406 7

2.3 Les associations de sécurité Afin de définir les transformations effectuées sur les paquets et comment ces transformations seront effectuées, on définit une Security Association (SA). Celle-ci permet de spécifier : le type de protection (AH ou ESP) ; les algorithmes utilisés pour l authentification AH et ESP ; l algorithme de chiffrement pour ESP ; les différentes clefs en usage ; la durée de vie de la SA ; le séquencement des datagrammes propre à IPSec. Une SA peut être utilisée statiquement, c est-à-dire pour toute la durée de la connexion, ou bien renégociée en cours de transmission. 2.3.1 Conclusion IPSec peut être vu comme un assemblage ou un regroupement de plusieurs protocoles et mécanismes ce qui le rend techniquement très complexe. Heureusement la standardisation de ce protocole a apporté une solution souple et modulaire, ce qui permet de l adapter à un grand nombre de situations. 2.4 Notre situation 2.4.1 Sujet Le but de ce projet est de développer un outil permettant le support de protocoles additionnels pour les VPN basés sur IPSec. Il a été convenu au départ que notre outil doive supporter 4 protocoles : IP broadcast. Les paquets broadcast sont utilisés par bon nombre d applications ; ARP. Ce protocole est destiné à la maintenance de tables d adresse IP pour le système d exploitation. DHCP. L attribution dynamique d adresses IP est devenue une application centrale des réseaux, évitant aux administrateurs un laborieux travail de gestion des adresses. IPX. Ce protocole développé par Novell est utilisé dans ses applications Netware, ainsi que dans certains jeux. Notre programme doit supporter ces protocoles supplémentaires. Il ne s agit donc pas d implémenter ou d ajouter des fonctionnalités à un VPN, mais de transformer les paquets appartenant à ces protocoles afin qu ils soient pris en compte par le VPN. La méthode employée est celle de l encapsulation : il s agit de faire transiter le paquet dans une entête de protocole supporté par le VPN. L action de notre dæmon doit être transparente à deux niveaux : 1. transparence vis-à-vis des sous-réseaux : le dæmon doit réussir à récupérer des paquets destinés au sous-réseau distant sans que l application émettrice des paquets n aie à être configurée particulièrement. 2. transparence vis-à-vis du VPN : le dæmon doit agir comme une application émettant des paquets pris en compte par le VPN. L avantage de cette méthode est qu il n est pas nécessaire de modifier la configuration du VPN ou des applications existantes. Il est même possible d installer xvpnd sans arrêter le VPN luimême. L inconvénient est que le traitement les paquets des protocoles additionnels est plus lourd que pour des paquets supportés nativement par le VPN. Ce sur-coût se mesure à deux endroits : 8

192.168.0.3 192.168.0.4 gateway 0 10.0.0.1 192.168.0.x 192.168.1.3 internet 192.168.1.4 gateway 1 10.0.0.2 192.168.1.x gateway n 10.0.0.n FIG. 2 Fonctionnement général à l encapsulation du paquet ; à la décapsulation du paquet, où l on doit relâcher le paquet tel qu il a été encapsulé. 2.4.2 Xvpnd en action Nous considérons les réseaux organisés comme suit (voir figure 2) : un sous-réseau est composé de feuilles toutes les feuilles possèdent une route (directe ou non) vers la passerelle du réseau. sur chaque passerelle est installé une application de VPN. Notre dæmon doit être installé sur chacune des passerelles qui constituent le VPN. Xvpnd utilise deux types d interfaces (cf figure 3) : les interfaces dirigées vers le sous-réseau (eth0 sur la figure) sur lesquelles xvpnd capture et injecte les paquets ; les interfaces gérées par le VPN (ipsec0 sur la figure) servent à transporter les paquets entre les différentes instances du dæmon. Les configurations du réseau local n ont pas vraiment d importance. En effet, xvpnd considère tous les paquets arrivant des interfaces dirigées vers le sous-réseau. Considérons un cas simple : une machine d un sous-réseau A envoie des paquets (dont le protocole est pris en charge par xvpnd) vers le sous-réseau B (cf figure 1 pour la topologie du réseau). Notre dæmon n aura pas la même fonction sur les deux passerelles : sur le réseau A émettant les paquets, xvpnd doit récuperer les paquets émis, les encapsuler et les envoyer vers le sous-réseau B ; sur le réseau B, xvpnd attend de recevoir des paquets qui lui sont déstinés. Quand un paquet est reçu, il le "décapsule" et le relâche sur le sous-réseau. Le paquet se retrouve alors sur le réseau B tel qu il avait été capturé sur le réseau A. 9

gateway xvpnd subnet eth0 ipsec0 internet FIG. 3 Composition d une gateway gateway xvpnd subnet eth0 ipsec0 internet FIG. 4 Paquet pris en charge par le VPN côté client Dans une architecture client/serveur, la partie envoyant les paquets sur le réseau A est appelée client et la partie attendant les paquets sur réseau B est appelée serveur, car elle attend les requêtes du ou des client(s) (dans notre cas, des envois de paquets) pour effectuer des traitements (relâcher des paquets). En pratique, les communications ne sont jamais unidirectionnelles : le réseau B doit pouvoir être en mesure d envoyer des informations vers A en plus d en recevoir. C est pourquoi les deux parties client et serveur sont présentes sur toutes les passerelles. De plus ces parties doivent être indépendantes et pouvoir fonctionner simultanément (A et B doivent pouvoir parler "en même temps"). Les paragraphes suivants détaillent plus grandement ces deux parties. Prise en charge des paquets côté client On distingue trois types de paquets pris en charge différemment : les paquets qui ne sont pas à destination d un sous-réseau distant (destination locale) ; les paquets à destination d un sous-réseau distant pris en compte par le VPN ; les paquets à destination d un sous-réseau distant pris en compte. Les paquets qui ne sont pas à destination d un sous-réseau distant ne présentent que pas d intérêts ni pour le VPN ni pour xvpnd. En effet, les règles de routage des machines et celles inclues dans les configuration du VPN et de xvpnd se chargent d éviter ou de mettre fin au traitement du paquet par ces programmes. La prise en charge des paquets dont le protocole est supporté par le VPN est décrit figure 4. Les paquets rentrant dans cette catégorie sont ignoré par notre dæmon. 10

gateway xvpnd subnet eth0 ipsec0 internet FIG. 5 Paquet pris en charge par xvpnd côté client gateway xvpnd internet ipsec0 eth0 subnet FIG. 6 Paquet pris en charge par le VPN côté serveur La dernière catégorie de paquets est celle que prend en compte notre dæmon (voir figure 5). Le paquet est ignoré par le VPN, mais pas par notre dæmon. L action de xvpnd se découpe en plusieurs points : 1. Le paquet est récupéré par ce dernier, le dæmon détermine le sous-réseau de destination du paquet. 2. le dæmon encapsule le paquet dans un format pris en charge par le VPN, et l envoie. Prise en charge des paquets côté serveur Les paquets arrivant dans un sous réseau depuis l interface publique sont tous pris en compte par le VPN. Une fois que le VPN a décapsulé les paquets, on peut alors les distinguer en deux catégories : les paquets dont le protocole est pris en compte nativement par le VPN. les paquets envoyés par xvpnd depuis un sous-réseau distant. Une des difficultés ici pour notre dæmon est de ne prendre en charge que les paquets qui lui sont destinés, la solution a ce problème est exposée à la section 3.4.1. Les paquets dont le protocole est pris en charge par le VPN n interessent pas notre dæmon. Ils sont directement envoyés vers le sous-réseau (cf. figure 6). Les paquets déstinés à xvpnd sont pris en charge de la manière suivante (cf. figure 7) : 1. le paquet est récupéré ; 2. le paquet est décapsulé ; 11

gateway xvpnd internet ipsec0 eth0 subnet FIG. 7 Paquet pris en charge par xvpnd côté serveur 3. le paquet est relâché sur le sous-réseau tel qu il a été récupéré dans le sous-réseau distant. 12

3 Implémentation Cette section détaille l implémentation du programme en elle-même, quels choix se sont offerts à nous, avec quelles contraintes nous avons du composer, etc. 3.1 Présentation générale du dæmon et des sources A titre d introduction, rappelons qu on peut distinguer deux grandes tâches pour le dæmon : récupérer des paquets, les encapsuler et les envoyer à d autres instances de dæmons Xvpnd (l instance est cliente des autres) ; recevoir des paquets venant d autres instances de dæmons Xvpnd et les relâcher de façon appropriée, à savoir dans le même état que celui où ils ont été sniffés (l instance est serveur des autres). Pour des raisons pratiques de clarté de code et de maintenabilité, nous avons pris le parti de séparer la tâche de sniffage/transmission en deux composantes bien distinctes. Pour ces mêmes raisons, toute personne qui inspectera le code le trouvera réparti (nous l espérons vivement) en fichiers à thème, chaque thème étant construit à l identique, avec : une fonction d initialisation qui alloue la mémoire nécessaire et une fonction de nettoyage qui la libère une ou plusieurs fonctions de chargement qui assignent aux composantes du thème les valeurs nécessaires à son bon fonctionnement ; les fonction d utilisation proprement dite (souvent des fonctions de récupération d information) Cette programmation a l avantage de guider le néophyte en lui présentant un contenu structuré mais a le désavantage d alourdir les écritures et de faire proliférer les fonctions d initialisation et de libération. Nous avons factorisé ces dernières en une fonction d initialisation générale (qui appelle les fonctions d initialisation de chaque module et les fonction de chargement avec les informations lues dans le fichier de configuration) et une fonction de libération générale (qui fonctionne selon le même principe). Un dæmon comme le notre a besoin de paramètres. Nous avons fait en sorte qu il aille les chercher dans un fichier de configuration dont le chemin peut lui être donné en option sur la ligne de commande ou laissé à une valeur par défaut, écrite en dur dans le code du programme. Comme cela sera explicité ci-après (cf section 3.5), il existe un certain nombre de comportements variant selon le type de protocole. Pour ne pas figer dans un programme monolithique tous ces comportements, nous avons décidé de rassembler ces comportements dans des plugins 7 qui peuvent être chargés dynamiquement en fonction de ce qui est lu dans le fichier de configuration. 3.2 Séquence de démarrage Le démarrage du dæmon s effectue sur le schéma suivant. 1. le dæmon récupère ses arguments, réduits au strict minimum : éventuellement le chemin du fichier de configuration et une action à effectuer ; 2. le dæmon lit le fichier de configuration, celui par défaut ou celui passé sur la ligne de commande ; 3. le dæmon fork ; 7 greffons 13

4. le rôle du père consiste juste à sauvegarder le pid du fils dans un fichier de lock 8 pour un usage ultérieur et à rendre la main (quitter). Les tâches du fils sont détaillés dans les sections suivantes. L arrêt du dæmon consiste à récupérer le pid du fils et à le tuer proprement. L action de tuer se fait par l envoi d un signal qui déclenchera la rupture des boucles de sniffages (partie client), de réception (partie serveur), et libérera les zones de mémoires allouées par le dæmon. Nous avons choisi d utiliser les générateurs d analyseurs lexical et syntaxique lex et yacc, pour mettre en oeuvre une grammaire simple que nous avons décorée d action sémantiques à placer en cours d analyse. Le fichier de configuration est une suite d associations clés/valeurs, clés et valeurs étant des chaînes de caractères sans espace. Ce fichier est parcouru une seule fois, son contenu est analysé et s il est correct est chargé dans une table de hachage. L ensemble des clés admises dans le fichier n est pas restreint (même pas aux clés utilisées effectivement dans le programme) pour permettre par exemple à des plugins d aller y piocher des renseignements sur mesure. Vous trouverez dans la section 7.2 (Utilisation) de plus amples informations sur la grammaire utilisée. Journalisation Enfin, touchons un mot de la journalisation des informations de fonctionnement de Xvpnd et des facteurs qui l influencent. Le premier facteur concerne la destination des informations. L utilisateur, à la compilation, a le choix entre : laisser s afficher les informations dans un fichier de son choix s il fournit un chemin valide dans le ficher de configuration (cf. section 7.2), ou dans un fichier par défaut si aucun chemin n est donné ; utiliser les logs système. L utilisateur se voit aussi offrir le choix à la compilation d ativer le mode de débogage verbeux, qui donnera d amples informations à propos de tout ce qui se produit, y-compris l arrivée de message. Ceci fait que ce mode est déconseillé pour un dæmon en pleine charge car les affichage alourdissent considérablement le traitement d un message. Il est néanmoins très utiles pour détecter les erreurs (de configuration notamment). 3.3 Récupérer des paquets 3.3.1 Présentation Le principal travail de cette partie du programme est de faire le tri entre les trames que peut capter le dæmon. Il ne faut surtout pas traiter un paquet déjà pris en charge par le VPN sous peine de surcharger le réseau avec des paquets inutiles. La capture des trames est confiée à la libpcap. L utilisation de cette librairie nous a apporté certaines simplifications : la librairie nous évite des développements supplémentaires. la librairie permet déjà de trier les paquets passant dans l interface grâce aux BPF (Berkeley Packet Filter). 3.3.2 Des solutions envisagées à la solution retenue Il y a plusieurs possibilités quant à l organisation du sniffer de paquets. Les principales implémentations considérées sont détaillées dans les paragraphes suivants. 8 Ce fichier permet aussi de s assurer que deux instances du dæmon ne tournent en même temps. 14

La première méthode consiste en un seul sniffer capturant tous les paquets des protocoles voulus. L inconvénient de cette méthode est qu il nous faut ensuite "deviner" à quel protocole appartient le paquet et vers quel sous-réseau le router. Une seconde méthode consiste en un sniffer pour chaque combinaison possible entre les protocoles, les passerelles distantes et les interfaces de sniffage. Cette méthode a l avantage de reléguer l ensemble des calculs de filtrage à la libpcap. Ainsi chaque thread envoie des paquets vers une unique passerelle. Ceci a pour effet de rejeter les paquets non désirés le plus tôt possible et donc d améliorer la disponibilité du dæmon. De plus, le traitement des paquets par notre dæmon est quasiment nul, chaque paquet sniffé doit être encapsulé de façon inconditionnelle : plus aucun filtrage n est nécessaire. Enfin les règles de filtrages étant du code compilé BPF, sont plus rapide qu un filtrage fait "à la main". La règle BPF est alors du type : protocol_rule and dst net network_address mask mask Malheureusement, la primitive dst net network_address mask mask de la libpcap ne fonctionne que pour des paquets IPv4, ce qui la rend incompatible avec les paquets IPX/SPX qui doivent être supportés par notre programme. Nous avons donc opté pour une solution intermédiaire : un maximum de filtrage est relégué à la libpcap. Nous avons donc un sniffer dédié à un protocole particulier sur une interface donnée ; le filtrage résiduel (déterminer vers quelle(s) passerelle(s) distante(s) il faut envoyer notre paquet) est assurée par notre dæmon. Cela implique que notre dæmon doit savoir retrouver l adresse de destination du paquet, quelque soit le type de paquet. Cette information dépendant du protocole du paquet sniffé, ce traitement est déporté dans les plugins (cf. section 3.5). Cette solution permet de garder un nombre de threads assez restreint. Le nombre de threads est en effet donné par le produit nb_interfaces nb_protocoles. 3.3.3 Dernières considérations L appel du callback libpcap étant bloquant pour pcap_loop(), il a egalement été envisagé d executer le traitement du paquet dans un thread séparé. De cette façon, l appel du callback ne serait plus bloquant pour pcap_loop(). Or nos différents tests (sans déporter le traitement dans un thread) n ont pas montré un manque de disponibilité des sniffers. 3.3.4 Difficultés rencontrées La principale difficulté rencontrée dans cette partie du projet a été de savoir jusqu à quel point on pouvait reléguer des calculs vers la libpcap. En effet, nous avions décidé de déporter un maximum de filtrage vers la libpcap. Malheureusement, nous avons rencontré les difficultés exposées ci-dessus quant au support du IPX. Il a donc fallu revenir à une version antérieure du sniffer. 3.4 Réinjecter les paquets 3.4.1 Problèmes liés à l injection Le premier problème avec l injection est purement technique. Il a été de trouver de la documentation fiable simplement à propos des fonctions à employer pour injecter des paquets et quels types de paramètres leur donner quand ce n était pas clair. Il aura fallu décortiquer les sources de quelques programmes et souvent inspecter les fichiers d en-têtes (.h) du système d exploitation pour avoir des renseignements précis. 15

Deuxièmement, si l on ne doit pas avoir à se soucier du mode de transfert utilisé (en mode connecté ou datagram) ni du type de serveur mis en place (itératif ou concurrent) il faut que l injection soit la plus rapide possible pour permettre l utilisation d un serveur itératif (qui demande un temps de réponse et de traitement aussi court que possible) ou l utilisation d un transfert en mode datagram (qui demande elle aussi un temps de traitement très court pour qu un minimum de paquets soit perdus. Enfin, nous sniffons des interfaces sur lesquelles nous réinjectons les paquets reçus des autres interfaces. Ainsi, un paquet qui vient d être injecté sera resniffé (si nous n y prenons pas garde), et pourra être ré-émis à d autres passerelles qui reproduiront le même comportement, créant ainsi des boucles sans fin. Ceci est dû à l homogénéité des configurations des démons sur le VPN. 3.4.2 Nos solutions à ces problèmes Pour éviter les paquets injectés/re-sniffés et transmis sans fin de passerelle à passerelle, il a été mis en place un mécanisme de marquage des paquets décrit comme suit : 1. l injecteur calcule une clé à partir du paquet et l insère dans une table de clés 9. 2. le paquet est injecté 3. le paquet est immédiatement récupéré par le sniffer. Ce dernier recalcule la clé du paquet et regarde dans la table si elle est présente. Si oui le paquet n est pas traité est la clé est effacée de la table. Sinon le paquet est traité normalement. Une table est nécessaire pour chaque interface et puisque notre démon est multi-threadé, chacune de ces tables de clés est protégée par un sémaphore. Ce système très simple est mis en oeuvre de manière entièrement transparente dans les fichiers msg_mem.c et msg_mem.h, de telle sorte qu il n y a aucun sémaphore à manipuler à l extérieur des fonctions de ce module, les appels à ses fonctions sont bloquant quand le besoin est présent. Une fois ce système d identification disponible, le traitement de chaque paquet transféré vers une passerelle distante est limité aux actions suivantes : 1. déterminer le type de paquet et trouver le plugin associé à sa gestion propre. Comme cela sera expliqué plus tard (cf. section 3.6.2), en associant au sein du serveur un type de paquets à un port déterminé, le type du paquet et son plugin sont connus dès la réception du paquet ; 2. déterminer la clé d identification du paquet ; cette étape dépend de la structure du paquet, donc du plugin associé au type de paquet, et n est souvent qu une récupération directe d informations binaires ; 3. déterminer les interfaces vers lesquelles le paquet doit être réinjecté ; pour les protocoles actuellement pris en compte, il est nécessaire d injecter le paquet sur toutes les interfaces ouvertes ; Nous nous sommes débrouillés pour qu un minimum d allocations et libérations de mémoire soit invoquées. Pour cela, nous avons pu allouer une zone de mémoire capable de stocker le plus grand MTU susceptible d être sniffé, encapsulé et envoyé vers les autres passerelles. Comme cela sera répété à la section 3.7, cela laisse présager une nécessité de cohérence dans la configuration de Xvpnd sur les passerelles, à savoir qu une instance du dæmon sur une passerelle connaît la taille de son MTU maximal mais pas celui de ses voisines. Donc si un message trop grand est reçu par le serveur, il sera tronqué sans qu on ait, a priori, de moyen de détecter la troncature. 9 en pratique, une table à un seul élément suffit 16

3.5 Plugins 3.5.1 Flexibilité, extensibilité Pour une plus grande extensibilité, le support des différents protocoles est géré via un système de plugins. Le principal avantage d un tel système est le suivant : nous déléguons au plugin la gestion de toute tâche susceptible de dépendre du protocole pris en compte. Grâce à ces plugins, nous avons pu rendre générique le traitement d un paquet par le démon, et un protocole peut facilement être mis en oeuvre et intégré au programmes par un simple ajout des informations nécessaires au fichier de configuration puis en redémarrant le dæmon. L API des plugins est plus grandement détaillée dans la manpage de xvpnd(1). Au fur et à mesure de l implémentation, nous en sommes arrivés à la conclusion qu un plugin devait contenir les informations suivantes, même si toutes ne sont pas utiles à toute implémentation possible : une règle libpcap servant à distinguer les paquets du protocole ciblé des autres ; une fonction retournant l adresse IP d un paquet donné, la position et le codage de cette dernière à l intérieur du paquet changeant d un protocole à l autre ; une fonction calculant une clé unique associée à un paquet donné (cf section 3.4.1) ; un identifiant de type de paquet qui doit être unique entre tous les protocoles supportés par une configuration. une fonction se chargeant d injecter le paquet sur les interfaces adéquates ; un numéro de port sur lequel transmettre le paquet lorsque le mode de transfert requiert un port. Nous verrons dans l explication de l implémentation du transport entre passerelles (cf section 3.6.2) lesquelles de ces informations sont véritablement utiles dans notre version. Nous avons factorisé la fonction d injection en mettant à disposition une fonction de broadcast sur toutes les interfaces à disposition du programme. Certains protocoles peuvent toutefois être programmés pour pouvoir récupérer les informations de routage nécessaires à l identification d une interface spécifique. Dans trois des quatre plugins proposés, nous retransmettons directement l injection du paquet à cette fonction de diffusion. La fonctionnalité renvoyant un identifiant de type de paquet n est pas utilisée en pratique mais devient nécessaire lorsque l on désire à un mode d identification d un paquet dans un flux autrement que par le numéro de port. Nous proposons à tout programmeur désireux d implémenter un plugin de s en tenir à la numérotation proposée par l ARPA pour identifier les protocoles transportés par des trames Ethernet. 3.5.2 Problèmes liés aux plugins Outre l effort de documentation qui a été nécessaire pour réaliser un le chargement dynamique, propre et robuste de plugins, la partie technique de l implémentation des plugins n a pas posé de problème particulier. Les problèmes qui se sont posés ont concerné le contenu et non la forme : disposer d information fiables sur les protocoles à gérer et être capable de les exploiter. Citons les deux plugins qui ont été les plus gênants. DHCP DHCP est le protocole qui nous aura donné le plus de fil à retordre en ce qui concerne la règle de filtrage à donner à la libpcap. Le problème a été qu une partie du protocole est de l IP broadcast (gérée par le plugin de même nom) et qu une autre partie peut déjà être prise en compte par le VPN. 17

IPX Pour IPX, il aura fallu trouver des programmes capables d en générer et trouver quelles parties de l en-tête IPX pouvaient être utilisées pour déterminer une adresse IPv4 de passerelle destination. 3.6 Transporter des paquets Des trois principales parties de notre projet (récupération, transport et injection), le transport entre démons constitue celle que nous avons désignée comme la moins bien interchangeable. La raison est que le changement ne sera pratiquement jamais opéré, une solution optimale devant être choisie le plus rapidement possible. Néanmoins, aucun système de plugin n a été prévu car il engendrerait un surcroît de travail tout à fait vain. Un programmeur désireux de modifier notre mode de transfert devra recompiler le programme avec son module propre. Le choix d un protocole pour encapsuler les paquets est large, d UDP à PPP, en passant par TCP ou un protocole "maison", il a fallu peser le pour et le contre de chaque solution. Veuillez trouver dans la section suivantes les critères que nous avons rassemblés. 3.6.1 Caractéristiques du transport de paquets Une des caractéristiques du protocole de transfert est qu il doit être pris en charge par le VPN existant. Notre choix va donc être dirigé essentiellement vers un transport au dessus du protocole IP. Reste à déterminer si nous utilisons l IP brut, de niveau 3 (couche réseau ), ou si nous utilisons un protocole de niveau 4 (couche transport ). Les règles identifiant un paquet à prendre en charge concernent le protocole de ces messages. Ces protocoles ne se limitent pas à un étage particulier de l empilement des couches réseau, et ils faut prendre en compte les caractéristiques principales de chacune de ces couches. Prenons l exemple de paquets à encapsuler faisant partie d un protocole dit fiable (comme l est TCP), ils possèdent un système de vérification du bon acheminement des paquets (comme l émission de paquets ACK couplés à une gestion du temps de réponse par exemple). Imaginons que nous utilisions TCP comme protocole d encapsulation, nous disposons donc nous aussi du même système de vérification du bon acheminement des paquets. Il est fort probable que le délai de temps de réponse du paquet émis par l application cliente soit différent du délai du paquet de notre dæmon. Si le plus court de ces deux délais est dépassé, alors le paquet sera considéré comme perdu à la fois pour l application client et pour notre dæmon. Les deux délais seront donc revus à la hausse alors que seul le plus petit des délais nécessitait un changement. Il en résulte une diminution des performances du réseau, en effet les deux applications émettront de nouveau leur paquet, alors qu une seule ne devait le faire. De plus, les paquets ACK qu émettrait ou recevrait l application seraient eux aussi assurés d un bon acheminement comme n importe quel autre paquet encapsulé, ce qui générerait un trafic supplémentaire, une mise en abîme de TCP dans TCP, avec les tous les délais supplémentaires que cela implique. Enfin, dans la situation qui nous intéresse, il n y a pas une application de tunneling, mais deux : xvpnd et le VPN déjà présent. Cette duplication des vérifications de bon acheminement sur deux niveau aurait de lourdes conséquences sur les performance du VPN. Ces considérations orientent naturellement notre choix vers une solution sans mécanisme de synchronisation et non fiable : soit le protocole encapsulé est fiable, et dans ce cas les éventuelles erreurs de transmission du paquet encapsulé seront interprétée comme des erreurs pour le paquet hors de sa capsule, et le protocole de l application va gérer cette situation comme il le doit ; 18

soit le protocole de l application est non fiable (sans doute pour des raisons de performances), et nous ne voulons introduire que des délais réduits au minimum. Un dernier point est à prendre en compte dans le transfert de paquets, il s agit de disposer d un moyen de reconnaissance des paquets transmis, et ce pour disposer d informations précises lors de l injection du paquet. 3.6.2 Des solution envisagées à la solution retenue Nous avons retenu pour le protocole de transport les solutions suivantes, toutes fonctionnant au moins au dessus d IP, TCP étant déjà écarté : IP brut, qui ne propose rien d autre qu un moyen d acheminer le paquet d une machine à une autre, sans moyen de s assurer que le paquet arrive une et une seule fois. GRE, qui propose une entête dont beaucoup de champs sont optionnels, tels un checksum, un identifiant de type de paquet encapsulé, un numéro de séquence pour réordonner les paquets, etc. Il faut noter que le calcul du checksum est à notre charge. UDP, qui est très largement répandu, propose dans son entête une vérification du contenu transporté au moyen d un checksum, qui propose un numéro de port émetteur et récepteur pour identifier les applications communicantes, etc. Pour l identification du type d un message, nous avons retenu les deux façons de faire qui suivent : utiliser une encapsulation maison avec un champ marquant le type, ce qui est nécessaire avec IP brut et UDP mais inutile avec GRE qui remplit ce rôle ; utiliser un champ de l en-tête du paquet encapsulant pour marquer la différence, ce qui n est possible qu avec GRE ou UDP via le numéro de port. La solution retenue Nous avons opté pour UDP, avec une identification du type des paquets par le numéro de port récepteur, à configurer via le fichier de configuration. Cette solution a l immense avantage de nous permettre d ouvrir une socket par port dédié à un protocole encapsulé, et d associer le plugin de gestion de ce protocole directement à cette socket. Ainsi il ne nous faudra pas parcourir un ensemble de plugins pour trouver lequel convient au paquet reçu. 3.7 Effets des incohérences Face aux possibilités de configuration de notre dæmon, il faut adopter une attitude prudente. La cohérence de son utilisation en assurera le succès. Il est bon de rappeler que xvpnd ne s adresse pas au grand public mais répond à un besoin précis qui correspond à un public ciblé, celui qui utilise et est capable de configurer un VPN. 3.7.1 Cohérence sur une passerelle Il appartient à celui ou celle qui mettra en place notre dæmon sur une passerelle de vérifier que la configuration de la machine est saine. Par exemple, s il indique dans le fichier de configuration d une passerelle deux interfaces à sniffer qui ne sont en réalité qu une interface et un de ses alias, notre mécanisme de détection de paquets auto-injectés (cf section 3.4.1) ne sera plus opérant car le paquet sera sniffé autant de fois qu il n y a d alias pour la même interface, puis sera transmis et ré-injecté autant de fois, et la clé du message sera libérée à l injection du premier. 3.7.2 Cohérence entre passerelles Un VPN basé sur notre dæmon ne sera que entièrement opérationnel si une configuration complète est donnée à chaque passerelle du VPN. Ceci est dû au fait qu une passerelle se repose 19

uniquement sur les informations contenues dans son fichier de configuration. Si un plugin est chargé sur toutes les passerelles sauf une, il sera difficile de détecter le problème. Il appartient à celui ou celle qui construira lesdits fichiers de signaler pour chaque passerelle les coordonnées de chaque autre. Mais il est impératif de ne pas y mettre les coordonnées de la passerelle elle-même car une boucle est ainsi créée et il suffira d un seul message pour occuper le dæmon et encombrer les communications. Xvpnd n a pas à détecter ce type d erreur. La version d Xvpnd installée sur chaque passerelle a son importance. Rien n indique a priori dans le numéro de version que tel ou tel autre protocole de transport a été utilisé, et il est évident que cette donnée doit être homogène sur tout ensemble de dæmons qui communiquent entre eux. Comme cela a été cité dans la rubrique 3.4.2 et sera répété dans la rubrique 5, il est actuellement essentiel que le type d interfaces sniffées par un ensemble communiquant de dæmons soit homogène. Le non-respect de cette injonction peut causer la troncature de paquet à une taille égale à celle de la plus petite unité de transfert 10 des interfaces utilisées. 10 MTU, Message Transfer Unit 20

4 L infrastructure de test Grâce à la mise à disposition par l équipe West du Lifl de trois ordinateurs et de tout le matériel nécessaire à leurs connexions, nous avons pu installer ces trois machines plus un ordinateur portable nous appartenant en un réseau simulant deux sous-réseaux distincts (constitués chacun d une passerelle 11 et d une feuille 12 ) reliés par un troisième réseau simulant l Internet (cf figure 8). Nous avons installé sur chaque machine qui nous était prêtée un Linux de la distribution Mandrake 10.0. Puisque nous n utiliserions que les quelques outils de configuration, n importe quelle distribution aurait fait l affaire, nous n avions que la contrainte de tout avoir a disposition sur CD car notre réseau était destiné à être coupé du monde. Nous avons pris le parti de la facilité. La configuration nécessaire au bon fonctionnement du réseau a été concentrée dans de petits scripts shell, un par machine exécuté à chaque démarrage. Les tests concernant l IPX, l IP broadcast et l ARP ont tous comporté cette même suite d actions : 1. Compiler le programme sur l une des machines, en l occurrence l ordinateur portable ; 2. Propager le binaire du dæmon et ceux des plugins sur chaque passerelle ; 3. Lancer un dæmon sur chaque passerelle ; 4. Lancer le programme tcpdump sur chaque feuille avec une règle permettant de capter les messages attendus, et injecter des paquets sur l interface de chaque feuille ; 5. Observer ce qui a pu être capté de part et d autre du réseau. Cette suite d opérations a sensiblement du être modifiée pour tester le DHCP car ce protocole établit une noouvelle configuration IP pour les interface de la machine qui l emploie. Il aura donc fallu relancer le script de configuration des interfaces sur les feuilles qui ont participé au test de DHCP. Dans un premier temps, nous n avons pas mis en place de VPN car ce n est pas une tâche aisée et notre dæmon doit être capable de s en passer pour fonctionner correctement. Chaque feuille n a connaissance que de sa passerelle et envoie toutes ses communications vers celle-ci. Chaque passerelle a connaissance de son sous-réseau et de l autre passerelle et sa route par défaut est dirigée vers l internet. Le fait pour une passerelle de connaître son homologue n est pas nécessaire à la simulation, cela nous a seulement permis des connexions par SSH sur une passerelle depuis l autre. 11 gateway 12 leaf 21

gateway0 gateway1 eth0 hub eth0 xvpnd xvpnd eth1 eth1 eth0 eth0 leaf0 leaf1 FIG. 8 Infrastructure de tests 22

5 Limitations et perspectives d évolutions Configuration des plugins Nous admettons que les plugins ne sont pas configurables. Par exemple les règles destinées à former les filtres de la libpcap sont écrites en dur dans le code du programme, alors que si un protocole est à identifier par un numéro de port, l utilisateur peut avoir configurer ce protocole pour utiliser un port autre que celui utilisé par défaut. Les perspectives d évolution suivantes apportent des réponses à cette limitation-ci. Initialisation des plugins Tels que leur API a été conçue, les plugins n ont pas à implémenter de fonction d initialisation et de fermeture. C est une limitation dans le sens ou le programmeur d un plugin est limité dans l allocation et l utilisation des zones de mémoires qui lui seraient utiles, dans la récupération une fois pour toutes d informations utiles, etc. La fonction d initialisation pourrait prendre en paramètre les mêmes arguments que ceux passés à la fonction main, issus de la ligne de commande. Un plugin se verrait ainsi offrir une possibilité de configuration. Compilation des plugins Pour le moment, rien n est mis à disposition pour compiler un plugin sans avoir à se plonger dans les sources du dæmon. Il conviendrait de proposer un paquetage contenant les entêtes utiles de notre dæmon et une documentation appropriée afin que chaque plugin ait accès aux fonctions que le dæmon met à disposition. Une telle fonctionnalité apporterait par exemple une solution au problème de la configuration des plugins, par la récupération de données lues dans le fichier de configuration général, et ce via une mise à disposition des entêtes. Le démon a été programmé au dessus d un système d exploitation Linux (munis de diverses variantes de la version 2.6 du noyau Linux). Une amélioration évidente serait d en assurer la portabilité sur d autres systèmes d exploitation, nos pensées vont vers les UNIX tels la série des BSD. Chemin des plugins Il serait bon de permettre à l utilisateur de charger des plugins au chemin arbitraire. Notre politique actuelle consiste à nous reposer sur les chemins par défaut fournis par la suite d outils autotools, et sur ces chemins uniquement. Types d interfaces Notre dæmon ne supporte actuellement que les interfaces Ethernet. Il serait bon de donner un support pour des interfaces telles que PPP ou Token-Ring voire mieux, avec des interfaces sans-fil. Un tel changement ne peut pas se faire sans mal, car comme cela a été cité dans la section 3.4.1, il faut réussir à spécifier quelque part une taille de MTU maximale valable pour tout le réseau de dæmons. Homogénéité des interfaces Xvpnd ne supporte actuellement qu un seul type d interfaces en même temps pour un groupe de dæmons configurés pour communiquer. Le seul cas de figure ou deux types d interfaces sont utilisables simultanément et celui où ces interfaces utilisent des messages au même format et à la même signification (i.e. des protocoles identiques). 23

6 Conclusion Conclusion technique Nous sommes satisfaits du résultats obtenu sur cette première version fonctionnelle de xvpnd qui offre toutes les possibilités que nous lui voulions et même d autres encore. Les perspectives d évolution sont attrayantes, encouragées par une architecture souple, portée par un code clair, commenté et donc facilement maintenable. Ses performances, avec les choix actuels (tels le choix d UDP comme mode de transport) offrent des performances qui nous satisfont, bien que des tests à plus grande échelle s imposent. Nous nous apprêtons à proposer xvpnd à la communauté du logiciel libre, sans doute par le site SourceForge et à le promouvoir auprès des développeurs et utilisateurs de VPN qui lui trouveront un intérêt, nous n en doutons pas! Conclusions personnelles Ce projet a indéniablement consolidé nos connaissances générale en matière de réseau, en nous replongeant dans les concepts essentiels de leur configuration et leur utilisation. Nous avons pu, par la même occasion, acquérir de bonnes connaissances dans les domaines de la programmation réseau et de la programmation système. Le développement des plugins (IP-broadcast, D.H.C.P., A.R.P. et I.P.X.) a demandé une bonne connaissance des protocoles sous-jacents et de leur implémentation dans les systèmes d exploitation utilisés. Un gros effort de documentation a été nécessaire pour maîtriser toutes ces notions, documentation dépassant souvent le cadre strict des VPN, et cela a été et restera très profitable. 24

7 Utilisation Nous tenons à rappeler que ce programme cible principalement les utilisateurs de VPN, qui, s ils ont été capable d installer et configurer un VPN, ne devraient pas éprouver de difficultés à installer et configurer notre programme. Ce programme reste cependant utilisable sans VPN mais l utilisateur doit garder à l esprit que le but du dæmon n est pas d assurer le cryptage des données transmises et qu elle seront transmises en clair. 7.1 Compilation et installation Le dæmon a été élaboré avec les outils de la suite de programmes autotools, ce qui simplifie la suite d opérations à effectuer pour compiler et installer le programme. Une fois que les sources ont été récupérées et extraites de leur archive, déplacez vous à la racine du répertoire racine des sources. La version courte de cette suite d instructions est :./configure [--with-debug] [--with-syslog] [--with-suid] make su make install Outre les options courantes de la suite autotools, il y a deux options donner à la commande configure, à savoir : l option --with-debug active l affichage verbeux de commentaires en cours d exécution. Ils sont très utiles pour repérer un éventuels défaut dans la configuration et nous conseillons ce mode de fonctionnement à tout nouvel utilisateur. l option --with-syslog active la sortie des commentaires normaux en cours d utilisation vers les journaux du système d exploitation plutôt que vers un fichier propre au dæmon. l option --with-suid provoque le positionnement du bit SUID sur le binaire installé. Le dæmon peut alors exécuter avec des droits privilégiés certaines opérations qui requièrent ces droits. Les autres opérations sont exécutées avec les droits de l utilisateur qui a lancé le dæmon. Si configure a été lancé sans --with-suid, toutes les opérations du dæmon sont effectuées avec les droits privilégiés. Le dæmon a été développé sur un système d exploitation Linux, noyau 2.6 et ces étapes doivent se passer sans problème sur une configuration semblable. 7.2 Configuration Une fois installé, il faut donner au dæmon les renseignements requis. Tout se trouve dans un fichier de configuration dont le chemin peut être donné sur la ligne de commande (option -c), sans quoi le chemin par défaut sera /etc/xvpnd.conf. Le fichier de configuration contient une suite de définitions (chacunes sur une ligne) qui peuvent adopter l un des formats suivants : clé = valeur clé += valeur Le premier format associe chaîne valeur à la chaîne clé. Toute chaîne précédemment associée au même mot-clé (partie gauche de la règle) est oubliée. Le deuxième format associe chaîne valeur à la chaîne clé sans effacer les valeurs précédemment associées. L ordre de mémorisation est le même que celui contenu dans le fichier de configuration. Les clés comme les valeurs ne peuvent contenir que des caractères alphanumériques plus ceux de la liste {, ;/_-}, donc pas de caractères blancs ni tabulations. 25