Rapport de stage. ETUDE IPSec ET INTEGRATION DE L EXTENSION MODE CONFIG DANS LE MODULE IPSec DES UTMs NETASQ. Jigar SOLANKI. Avril-Septembre 2008

Transcription

1 Rapport de stage ETUDE IPSec ET INTEGRATION DE L EXTENSION MODE CONFIG DANS LE MODULE IPSec DES UTMs NETASQ Jigar SOLANKI Avril-Septembre 2008 Master 2 Cryptologie et Sécurité Informatique Responsables Université : Emmanuel Fleury NETASQ : Yvan Vanhullebus Abdou Guermouche Université Bordeaux 1 NETASQ - We Secure IT 351, Cours de la Libération 3 rue Archimède Talence Cedex Villeneuve d Ascq

2 .

3 Table des matières Remerciements 8 Introduction 10 NETASQ en quelques mots Objetifs du stage Plan du rapport I Les protocoles IPSec 14 I.1 Présentation I.1.1 Champ d action d IPSec I.1.2 Historique I.1.3 Pourquoi déployer IPSec? I.2 Vue générale des protocoles I.2.1 Mode Transport, Mode Tunnel I.2.2 Protocole AH, Protocole ESP I.2.3 Etablissement d une négociation IPSec I.3 Design et architecture de sécurité I.3.1 Extrémités de tunnel, de trafic I.3.2 Associations de Sécurité I.3.3 politiques de sécurité I.4 Phases de négociation I.4.1 Phase1 : ISAKMP SA I.4.2 Phase2 : IPSEC SA

4 I.5 Résumé II Extensions IPSec et problématiques de sécurité 33 II.1 Authentification XAuth II.1.1 Principe et fonctionnement II.1.2 Notifications de type XAuth II.1.3 Sécurité de XAuth II.1.4 XAuth et le Group Password II.2 Hybrid-Auth II.2.1 Présentation générale II.2.2 Fonctionnement II.2.3 Authentification forte et complète II.3 Mode Configuration II.3.1 Présentation Générale II.3.2 Fonctionnement II.3.3 Paramètres disponibles II.3.4 Pool et pénurie d adresses IP II.4 Interactions XAuth, Hybrid et Mode Config II.5 Faiblesses d IPSec II.5.1 Failles cryptographiques intrinsèques II.5.2 Problèmes d implémentation II.5.3 Déploiements réels IIILes UTMs NETASQ 45 III.1 Présentation des UTMs III.1.1 Qu est ce que l UTM? III.1.2 La première génération des UTMs NETASQ : Les séries F III.1.3 La nouvelle génération G2 : Les séries U III.2 L ASQ - Active Security Qualification III.2.1 Présentation III.2.2 ASQ : Pile OSI Virtuelle III.2.3 Analyses de l ASQ

5 III.3 Fonctionalités Avancées III.3.1 Authentification et PKI III.3.2 Traitement des paquets III.3.3 High Availability III.4 Managment et Monitoring IV Intégration du Mode Config 61 IV.1 Tests et audit sur ipsec-tools IV.1.1 Etat d ipsec-tools IV.1.2 Configurations Racoon basique IV.1.3 Injection de politiques de sécurité par setkey IV.1.4 Configuration en XAuth IV.1.5 Mode Config : racoon vs racoon IV.1.6 Mode Config : racoon vs quelques clients VPN IV.1.7 Bilan des tests IV.2 Extension du format du fichier de configuration IPSec IV.2.1 Fichiers de configuration NETASQ et parseurs IV.2.2 Conception et extension du fichier IV.3 Intégration et validation IV.3.1 Impératifs d implémentation IV.3.2 Premiers tests IV.3.3 Validation et Commit dans le firmware Conclusion et Bilan 78 Annexe A : Protocole AH et ESP appronfondis 81 Annexe B : Echange Diffie-Hellman 91 RFCs IPSec 93 Références et Bibliographie

6 Table des figures I.1 Positionnement d IPSec dans la pile IP I.2 IPSec en Mode Transport I.3 En-tête en Mode Transport I.4 IPSec en Mode Tunnel I.5 En-tête en Mode Tunnel I.6 Authentication Header - AH I.7 Encapsulating Security Payload - ESP I.8 Synoptique de Fonctionnement IPSec I.9 Extrémités de tunnel, de trafic I.10 Echanges de Phase 1 en Main Mode I.11 Echanges de Phase 1 en Aggressive Mode I.12 Quelques exemples de paramètres négociés lors d une Phase II.1 Principaux attributs lors d un échange XAuth III.1 Gamme pour PME : F25, F50, F III.2 Moyenne et Grosse gamme : F200 au F III.3 Haute Gamme pour grands comptes : F2500 et F III.4 Anciens UTMs G III.5 Nouveaux UTMs G III.6 ASQ : Pile OSI virtuelle en 7 couches III.7 Différentes étapes d analyses de l ASQ III.8 Haute Gamme pour grands comptes : F2500 et F III.9 Synoptique des UTMs NETASQ III.10High Availability III.11Suite d administration des IPS-Firewalls NETASQ III.12NETASQ Firewall Manager IV.1 ScreenShot ShrewSoft IV.2 Paquet IPv4 Générique IV.3 Champ de l en-tête AH IV.4 Hash AH en mode Transport IV.5 Hash AH en mode Tunnel

7 IV.6 En-tête ESP avec (à d.) et sans (à g.) Authentification IV.7 Paquet ESP en Mode Transport IV.8 Paquet ESP en Mode Tunnel IV.9 Protocole Diffie-Hellman

8 Remerciements Je voudrais en tout premier lieu adresser mes sincères remerciements à Yvan Vanhullebus, qui a bien voulu me faire l honneur d accepter de superviser mes travaux au sein de NETASQ. Son attention et sa disponibilité, dont j ai usé et abusé, m ont été d une aide tout à fait précieuse ; ses recommandations et ses conseils rééllement enrichissants. Je dois également beaucoup à Damien Deville et, plus indirectement à Frédéric Raynal, sans qui je ne serai sans doute jamais arrivé à NETASQ. Mes chaleureux remerciements à tous ceux que j ai pu cotoyer, de près ou de loin, à NETASQ et en particluer, à l ensemble des équipes du laboratoire R&D. M avoir acceuilli avec cette amabilité et gentillesse qui les caractérisent m ont été d un réel réconfort tout au long de cette période. Être entouré de personnes extrêmement compétentes dans leur domaine n a fait qu accroître mon envie de progresser et d apporter ma minuscule petite pierre à l édifice. Que ce soit à travers l ambiance chaleureuse au sein de la société, ou encore à travers ces déjeuners copieux, propres à ces chèrs ch tis, rendant souvent les après-midi compliqués, j y ai passé de très agréables moments. Un grand merci à Abdou Guermouche d avoir accepté d être rapporteur et à Emmanuel Fleury pour sa disponibilité et sa réactivité à l université. L ensemble des remarques dont ils m ont fait part m ont été d un grand secours. Une pensée pour l ensemble de mes amis qui m ont toujours aidé, encouragé et soutenu, dans les bons moments comme dans les mauvais. Leur bonne humeur et joie de vivre m ont été d un réconfort inestimable. Qu ils trouvent ici ma plus profonde gratitude. Un immense merci à ma famille, mes parents, qui m ont permis de poursuivre dans la voie qui m intéressait et qui m ont toujours aidé à aller de l avant, et enfin, à celle qui m a soutenu sans faille aucune et sans qui je ne serai sûrement pas là aujourd hui, merci à toi!

9 À mes parents.

10 Truth never damages a cause that is just. Mahatma Gandhi Introduction Les protocoles IPSec sont déployés à des échelles de plus en plus grandes, qu il s agisse de relier des réseaux d agences et de sucursalles par l Internet, ou de protéger des réseaux difficilement sécurisables comme le WiFi. De plus avec l apparition du nomadisme, de plus en plus de personnes cherchent à pouvoir accéder aux ressources internes de l entreprise de manière sécurisée de l extérieur. On peut citer les commerciaux terrains, les ingénieurs travaillant de chez eux ou encore les directeurs en déplacement. NETASQ propose des solutions robustes de sécurisation des flux, et transparente pour l utilisateur, basés sur des VPN/IPSec en particulier. Plus généralement, NETASQ fournit des solutions de sécurité, d antivirus ou de pare-feux à des entreprises de tailles différentes, allant de la petite PME aux grands comptes ou encore à l Armée Française. Le module VPN/IPSec NETASQ propose aujourd hui embarquer l ensemble de le configuration réseau nécessaire aux clients nomades pour qu ils puissent accéder aux ressources internes de l entreprise. Ce module est destiné à être amélioré, notamment par l intégration d une extension IPSec appellée Mode Configuration. Cette extension permet d envoyer cette configuration réseau au client nomade de manière sécurisée, dynamiquement à la volée, pour que celui ci n aie plus à embarquer ces informations de manière statique sur sa machine. D autre part, cette intégration permettra d alléger la charge de l administrateur qui n aura plus à maintenir individuellement l ensemble du parc des machines nomades de son entreprise. Après avoir exposé les activités principales de la société NETASQ, nous présenterons les objectifs principaux du stage. On détaillera un plan des principaux chapitres traités afin de guider le lecteur, averti ou pas.

11 NETASQ en quelques mots... Crée en 1998, NETASQ est l une des sociétés européennes majeures sur le marché de la sécurité informatique dont le siège social est à Villeneuve d Ascq dans le nord de la France. Elle propose des solutions qui permettent de répondre aux enjeux et problématiques de la sécurité des entreprises sur plusieurs segments : la sécurité unifiée par les appliances UTMs firewalls, la détection des vulnérabilités par SEISMO ou encore le filtrage et la protection des messageries par les boitiers MFILTRO. NETASQ commercialise donc toute une gamme de solutions de sécurité unifiée (UTM). D autre part, l ensemble des UTMs NETASQ intègrent l ASQ (Active Security Qualification), technologie de prévention d intrusion en temps réel protégée par plusieurs brevets. NETEASQ a été présente dès le début en Europe, notamment en Belgique, en Italie et au Royaume uni. Aujourd hui présente dans plus de cinquante pays, par l intermédiaire de partenaires certifiés, elle apporte des solutions adaptées aux marchés locaux. Ces clients viennent de secteurs et de tailles très variées, des petites entreprises jusqu aux grands comptes comme Orange Business Services ou Portugal Telecom. A la pointe de l innovation technologique, toujours à l affût des dernières avancées en termes de sécurité, intégrant sa technologie de prévention ASQ sur l ensemble de sa gamme, les raisons faisant de NETASQ une société en sécurité informatique en avance sur son temps ne manquent pas. Certifiée par plusieurs organismes, NETASQ a, entre autres, été récompensée par le Fast 50 en France pendant deux années consécutives. Elle a en outre reçu la certification internationale des Critères Communs V2.2 au niveau EAL2+ (norme ISO et ISO 18045). Les UTMs sont testés dans des conditions réelles d exploitation par des appliances SPIRENT. Enfin, les retours des clients étant révélateurs de la qualité des produits d une société, on peut notamment citer Sébastien Truttet, responsable des infrastructures du groupe IS Altran : Nous avons décidé de supprimer les pare-feux de l autre fabriquant et de n utiliser que des pare-feux NETASQ comme barrière de sécurité unique et dans un tout autre domaine, Frédéric André, Responsable Technique et Informatique du Centre Hospitalier de Valenciennes : Depuis plus de trois ans, nous apprécions la réactivité de NETASQ aussi bien sur les mises à jours que sur le service après vente

12 Objectifs du stage Le module VPN/IPSec du firmware NETASQ est basé sur le projet ipsec-tools, sous licence BSD. ipsec-tools est constitué de setkey, utilisaire de manipulation et d injection de politiques de sécurité, de racoon, démon de négociation IKE que nous allons manipuler tout au long du stage, et de racoonctl, utilitaire de manipulation de racoon. Le but principal du stage consite à intégrer l extension IKE Mode Configuration dans le firwmare NETASQ. Cette extension permet d envoyer les informations de configuration réseau aux clients mobiles nomades. On appelle ces clients des road warriors, ils ont la particularité de ne pas avoir d adresse IP fixe connue de la passerelle. Cette intégration pourrait se faire en plusieurs étapes : Dans un premier temps, prendre en main l environnement de travail sous FreeBSD, et avoir une pile IPSec opérationnelle. Etudier les extensions IKE XAuth, Hybrid et Mode Configuration, puisque les trois extensions sont activées par une seule option de racoon. Evaluer l implémentation actuelle du Mode Configuration d ipsec-tools, à travers une lecture et un audit de code, une batterie de tests destinés à confirmer ou infirmer la stabilité. Le cas échéant, modifier le code d ipsec-tools afin de corriger d éventuels bugs ou erreurs de conception et d en améliorer les performances. Prendre en main les UTMs NETASQ, étudier les différentes fonctionalités et modules disponibles et se familiariser avec le firmware NETASQ. Effectuer un travail de conception avec l ensemble de l équipe R&D afin d étendre le fichier de configuration VPN NETASQ pour y intégrer le Mode Configuration. Implémenter les différentes librairies. Effectuer les premiers tests pour valider l implémentation. Effectuer des tests beaucoup plus poussés avec l équipe de Qualification, notamment des tests de performances sur des SPIRENT et des tests de non-régression. Repartir sur un travail de conception avec l équipe IHM afin qu elle puisse intégrer les boutons et/ou fenêtres Mode Configuration de la manière la plus adéquate possible compte tenu des contraintes de racoon, mais également de la manière la plus ergonomique possible pour le client final. Le Mode Config, si les objectifs sont atteints, sera disponible en tant que fonctionalité optionnelle dans la future version du firmware NETASQ

13 Plan du rapport Ce rapport présente l ensemble du travail réalisé sur ces six derniers mois, à travers essentiellement quatre chapitres qui reflètent le fil directeur que j ai suivi durant le stage : Chapitre 1 : IPSec Ce chapitre présente les protocoles IPSec, leur fonctionnement, leur design et la manière dont ils sont déployés. Cette étude permettra de mieux finaliser l ensemble des tests réalisés sur IPSec et le Mode Configuration en particulier. Chapitre 2 : Extensions IPSec Ce chapitre décrit les extensions XAuth, Hybrid et Mode Configuration. Ces extensions permettent d avoir une authentification supplémentaire durant la phase de négociation (Hybrid et XAuth) et de transmettre les informations de manière dynamique et sécurisée (Mode Config). Une section est également consacrée à certaines problématiques de sécurité posées par les déploiements réel d IPSec. Chapitre 3 : UTM NETASQ On étudie, dans ce chapitre, les fonctionalités des firewalls NE- TASQ. Une description du fonctionnement de l ASQ permet de mieux comprendre le firmware NETASQ. Chapitre 4 : Intégration du Mode Config On présente ici l ensemble de nos travaux, après avoir pris en main l environnement dans son ensemble (étude IPSec, prise en main des UTMs, étude sur le firmware, etc). Le fichier de configuration NETASQ est étendu et les champs Mode Configuration ajoutés. Une batterie de tests finaux finissent l intégration. Un approndissement des principaux protocoles IPSec est disponible en annexe

14 An error does not become truth by reason of multiplied propagation, nor does truth become error because nobody sees it. Mahatma Gandhi CHAPITRE I Les protocoles IPSec Résumé : IPSec est une suite de protocoles destinés à sécuriser le trafic au niveau IP. Il a été initiallement développé au sein du projet KAME pour IPv6, puis backporté à IPv4. IPSec fournit notamment la confidentialité des données qui transitent, leur authentification, leur intégrité en mode non-connecté et une protection contre le rejeu. Il permet ainsi de protéger l ensemble des couches supérieures reposant sur IP. IPSec peut fonctionner suivant deux modes : en mode transport pour une utilisation de type Host-T o-host ou en mode tunnel pour le déploiement de passerelle VPN (Gate- To-Gate ou Host-To-Gate). Les flux sont chiffrés et/ou signés par des algorithmes cryptographiques à clé secrète, à travers deux protocoles : AH assurant l authentification et l intégrité des données et ESP assurant principalement leur confidentialité mais permet de les authentifier également. L échange et le renouvellement de l ensemble des clés cryptographiques est assuré par le protocole IKE - Internet Key Exchange qui lui même est une instanciation du protocole ISAKMP - Internet Security Association and Key Managment Protocol utilisant entre autres, le protocole Oakley permettant de réaliser les échanges Diffie-Hellman notamment. Les paramètres d une politique de sécurité (identité de l hôte, algorithmes à utiliser, etc) sont stockés dans une Security Association (SA). L ensemble des SA sont alors stockées dans une base de données de SA appellées Security Association Database (SAD). Enfin, les différentes politiques de sécurité à appliquer aux paquets transitant par le module IPSec sont stockées dans une structure noyau appellée Security Policy Database (SPD).

15 CHAPITRE I. LES PROTOCOLES IPSEC I.1.1 I.1 Présentation Champ d action d IPSec En matière de sécurisation des échanges sur un réseau (a fortiori sur un réseau TCP/IP), les services disponibles peuvent être relativement différents suivant la couche de la pile réseau dans laquelle ils opèrent. On peut citer : Les protections au niveau applicatif intégrés dans l application en elle même. Les protections au niveau de la couche transport (TCP, UDP...) en utilisant les protocoles SSL/TLS et OpenVPN pour l établissement de tunnels SSL. Les protections au niveau de la couche liaison avec par exemple des tunnels PPTP. Quant à IPSec (Internet Protocol Security), il définit une collection de protocoles destinés à sécuriser l ensemble du trafic sur un réseau réputé non sécurisé, typiquement à travers l Internet. En effet, le protocole IP tel qu il a été conçu ne prévoit pas la protection et la sécurisation des données transmises. IPSec définit une extension d IP destiné à palier à ce manque. Il intervient au niveau de la couche 3 - Réseau - du modèle OSI (cf. Fig I.1) en sécurisant les flux IP. Il opère donc de manière totalement transparente pour l utilisateur, moyennant le temps de latence dû aux négociations avec l hôte distant et aux traitements des paquets du point de vue cryptographique, les algorithmes de chiffrement et d authentification étant gourmands en ressources. Le support d une pile IPSec est optionnel pour IPv4, mais obligatoire pour toute implémentation conforme d une pile IPv6. Normalisé pour la première fois en 1998 dans la RFC 2401, l architecture IPSec a connu bien des évolutions en une décenie, qu il s agisse de la pile IPSec noyau ou des démons IKE de négociation de clés ou de manipulation de règles de SPD. I.1.2 Historique Les piles IPSec Une des toutes premières implémentations d IPSec fut celle du projet KAME. Ce projet regroupait près d une dizaine de grosses compagnies japonaises, dont Fujitsu, Hitachi, NEC ou encore Toshiba, dans le but de fournir une implémentation d une pile IPv6, IPSec et IPMobile pour les systèmes BSD. Les systèmes qui ont integré la pile KAME/IPSec s avèreront être, par la suite, FreeBSD et NetBSD. Dans le même temps, il se trouve qu OpenBSD avait déjà implémenté sa propre pile IPSec depuis la version 2.1 datant de 1997, avec ses différents avantages et inconvénients. Le principal avantage de la pile IPSec d OpenBSD était l intégration de l accélération cryptographique materielle en natif, permettant d accroître considérablement les débits et les performances. Concernant les systèmes d exploitation basés sur un noyau Linux, la toute première implémentation d une pile IPSec fut réalisée par le projet FreeS/WAN dont la dernière version, 2.06,

16 I.1. PRÉSENTATION Applications Transport : TCP, UDP IPSec Anciennes Piles IPv4 IPSec Récentes Piles IPv4 Intégrant IPSec Pile IPv6 Intégrant Nativement IPSec Liaison, Physique Fig. I.1 Positionnement d IPSec dans la pile IP date de FreeS/WAN fut alors divisé en deux autres projets que sont OpenS/WAN et StrongS/WAN. Toutefois, aucunes de ces trois piles IPSec ne fut intégrée dans les noyaux Linux. En effet, à l horizon 2002, deux développeurs du noyau Linux, A. Kuznetsov et D. S. Miller ont entièrement implémenté une pile IPSec en s inspirant des des travaux du groupe U SAGI IP v6. Cette pile est celle qui est aujourd hui intégrée en natif dans les noyaux 2.6.x. Sur FreeBSD, la pile intégrée dans le noyau fut à l origine la pile KAME/IPSec. Toutefois, un portage de la pile IPSec d OpenBSD intégrant l accélération cryptographique materielle a été réalisé, ce qui a donné la pile FastIPSec. Deux piles IPSec ont alors été maintenues, et lorsque l ensemble des fonctionalités présentes dans KAME/IPSec l ont également été dans FastIPSec, les développeurs FreeBSD ont abandonné la pile KAME. Ainsi, depuis la version FreeBSD 7.0, seule une pile IPSec est intégrée et maintenue, à savoir FastIPSec. Les démons en espace-utilisateur Parallèlement au développement des différentes piles IPSec, il était nécessaire, comme nous le verrons plus tard, d avoir des démons s exécutant une espace utilisateur afin de manipuler, configurer, maintenir, administrer les différentes configurations et politiques à appliquer aux flux ; comme par exemple l authentification du site distant, l échange sécurisé des clés cryptographiques, savoir si le site distant est toujours disponible, etc. Théoriquement, les démons en espace utilisateur sont indépendants de la pile IPSec dans le

17 CHAPITRE I. LES PROTOCOLES IPSEC noyau, et il est possible d utiliser n importe quel démon sur toutes 1 les piles IPSec décrites plus haut. Nous verrons un peu plus tard pourquoi ce n est pas totalement vrai, puisque l interfaçage à travers lequel ils communiquent avec le noyau n offre pas autant de requêtes qu il serait souhaitable d en avoir. Ainsi, le projet KAME disposait de son propre démon, racoon, repris plus tard par le projet ipsec-tools. C est sur ce projet qu est basé en grande partie le stage. D autre part, OpenBSD avait implémenté son démon en parallèle de la pile, isakmpd aujourd hui encore intégré dans OpenBSD 4.x. Enfin, pour les systèmes Linux, plusieurs ont vu le jour. On peut citer pluto, démon des projets xs/wan, ou encore racoon qui supporte Linux, FreeBSD et NetBSD. IPSec est aujourd hui très largement déployé, en particulier pour la mise en place de VPNs 2, afin de sécuriser les échanges entre sites distants. L avantage par rapport à d autres solutions de tunnelling comme OpenVPN, basé sur SSL/TLS sécurisant TCP, réside dans la totale transparence au niveau de l utilisateur et la sécurisation de l ensemble des couches basées sur IP, notamment l ensemble des couches de transport comme TCP et UDP. Les implémentations propriétaires Toutes les implémentations IPSec ne sont en effet pas OpenSource. Des grands comptes comme Microsoft ou Cisco possèdent aujourd hui leur propre implémentation de pile IPSec. Bien qu IPSec soit un moyen extrêmement robuste afin de transmettre du trafic chiffré, il n en reste pas moins vrai que l interaction avec d autres piles IPSec pose par moments des problèmes de compatibilités. I.1.3 Pourquoi déployer IPSec? Qu il s agisse de l ensemble des services de sécurité fourni, ou de la flexibilité dans le déploiement, ou encore du coût moindre par rapport à des lignes dédiées, les VPN/IPSec sont de plus en plus présents dans l architecture réseau des entreprises. Services de sécurité Le pannel de services disponibles sous IPSec est assez varié ce qui lui permet d être très flexible lors du déploiement de topologies réseaux sécurisées. On regroupe ici quelques mécanismes de sécurité disponibles : Authentification des correspondants : Il s agit d une authentification à double sens où chaque extrémité s assure de l adresse de son correspondant. Il s agit principalement des adresses IPs des machines déploiyant IPSec et non pas des réels utilisateurs des dites machines. Nous verrons la manière dont les extentions ISAKMP/XAuth et ISAKMP/Hybrid permettent de remédier à cela en offrant une authentification forte supplémentaire des utilisateurs en plus de celle 1 sous réserve que les démons soient bien en environnement compatible, racoon ne fonctionnera bien entendu pas sur une architecture de type Win32 2 VPN :Virtual Private Network, ou Réseaux Virtuels Privés (RVP)

18 I.1. PRÉSENTATION des machines, notamment pour les clients mobiles possédant une IP dynamique. Authentification des flux : Il s agit de vérifier que les flux qui circulent dans le tunnel ont bien été émis et/ou sont bien à destination de l une ou l autre des extrémités. IPSec dispose principalement de méthodes de hachages afin de réaliser cette opération, à travers le protocole AH et/ou ESP. Confidentialité des flux : Le payload des paquets IP est entièrement chiffré à l aide d algorithmes cryptographiques à clé secrète, envoyé à travers le tunnel et déchiffré une fois arrivé à destination. Intégrité des flux : Lorsqu un paquet IPSec 3 subit une quelconque modification lors de son trajet, elle est détectée et le paquet est ignoré. L intégrité en mode non-connecté permet de détecter une quelconque modification d un datagramme individuel, mais pas sur l ordre des datagrammes, leur ordonnancement, ou la perte de paquets où l on parle d intégrité en mode connecté. Cela protège les flux de toute altération qu ils peuvent subir et permet notamment de se prémunir contre des attaques actives. Nous verrons pourquoi ceci est très problématique lorsqu il s agit de traversser des équipements NAT 4 et comment l extension IPSec NAT-T permet d y remédier. Protection contre le rejeu et l analyse de trafic : Bien qu un attaquant ne puisse pas déchiffrer ou modifier un paquet chiffré, il pourrait juste le capturer et le renvoyer plus tard. IPSec permet de se protéger contre ce type d attaque par rejeu de paquets. Ceci apporte également une protection supplémentaire contre les éventuelles écoutes et analyses de trafic puisque l ensemble du payload étant chiffré, un éventuel attaquant ne pourrait pas savoir quelle couche de transport est utilisée (TCP UDP ICMP...) ou encore quelle type de protocole de niveau supérieur (HTTP FTP SMTP), etc. Souplesse cryptographique : IPSec n est lié à aucun algorithme cryptographique en particulier. Il supporte de multiples algorithmes à clé secrète, et est capable de négocier dynamiquement les algorithmes supportés par tel ou tel hôte tentant d établir une connexion. Bien que cette souplesse de négociation soit avant tout un avantage, nous mettrons l accent sur le fait que cela peut être d un niveau de sécurité moindre lorsque certains paramètres ne sont pas choisis de manière adéquate. A titre d exemple, un proposal check obey peut faire en sorte que les hôtes négocient le chiffrement DES alors que les deux supportent AES. Services de flexibilité Les passerelles VPN/IPSec sont typiquement déployées dans des entreprises qui disposent de locaux géographiquement éloignés les uns des autres. L ensemble des services disponibles sur le site central doivent également l être sur les différents sites distants. Outre une grande souplesse dans 3 paquet AH ou ESP 4 NAT - Network Address Translation

19 CHAPITRE I. LES PROTOCOLES IPSEC la mise en place de tunnels VPNs, on peut noter : Bande passante : Les WANs traditionnels utilisés pour la communication inter-sites sont basés sur Frame Relay 5, ou sur ATM. Avec l apparition de nouveaux services nécessitant de plus en plus de débit, il a fallu choisir entre multiplier les lignes entre les sites ou trouver d autres alternatives sécurisées et de débits acceptables. D où le compromis trouvé d adopter des solutions basées sur IPSec. Réduction des coûts : Avec la diminution des coûts des abonnements des fournisseurs d accès, avoir une ligne dédiée coûte beaucoup trop chèr en terme de déploiement et de maintenance. De plus en plus d entreprises se tournent vers des fournisseurs d accès et sécurisent leur flux plutôt que d acheter des lignes dédiées. Disponibilité, adaptabilité : IPSec peut être déployé en tout point disposant d un accès réseau. Tandis que la plupart des sociétés possèdent déjà des lignes de communication dédiées entres leurs différents sites distants, le débit est bien souvent insuffisant lorsqu il s agit d accéder à une panoplie de services de plus en plus gourmands en bande passante. Dans ces cas, comme précédemment, il est possible de déployer des tunnels IPSec entre ces différents sites, en y faisant passer les informations les moins critiques, alors que les données très sensibles continuent à être acheminées à travers le WAN dédié. I.2 Vue générale des protocoles IPSec regroupe toute une suite de protocoles, de spécifications, d acronymes décrits dans différentes RFCs se référençant les unes aux autres, ce qui rend sa prise en main relativement délicate de prime abord. On présente ici une vue d ensemble de ces différents protocoles afin de mieux comprendre ce que font les différents modules avant d approfondir les caractéristiques des protocoles en question. I.2.1 Mode Transport, Mode Tunnel Suivant les besoins et les utilisations, IPSec peut fonctionner sur deux modes, le mode Transport et le mode Tunnel. Mode Transport IPSec en mode Transport (à ne pas confondre avec la couche transport du modèle OSI) est particulièrement adapté pour la communication entre deux hôtes. Cela présuppose donc l installation et la configuration préalables d une pile IPSec sur les deux systèmes. En mode Transport, les mécanismes de sécurisation viennent s intercaler entre les couches Transport et Réseau : les entêtes IPSec appropriées (AH et/ou ESP) sont appliqués après que les 5 Relai de trames : transfert de données par commutation par paquets, à haut débit et sur de longues distances, évolution de X

20 I.2. VUE GÉNÉRALE DES PROTOCOLES Alice Bob IPSec Transport Host To Host Host A Host B Fig. I.2 IPSec en Mode Transport données soient passées par la couche -4- Transport et avant de les passer à la couche -3- Réseau. Ce mode protège donc l ensemble des données au dessus d IP. IP Hdr Data IP Hdr IPSec Hdr Data A Protéger Fig. I.3 En-tête en Mode Transport Ainsi, le principal défaut de ce mode réside-t-il dans l absence de masquage d adresses puisque les adresses IP des deux correspondants sont visibles. Pour permettre une protection de tout le paquet IP, le mode le plus souvent déployé est le mode Tunnel. Mode Tunnel IPSec en mode Tunnel est utilisé pour le déploiement de passerelles VPNs et permet de relier un ensemble de réseaux de manière sécurisée à travers un réseau peu sûr comme l Internet. L ensemble des postes n ont alors nullement besoin d installer et/ou de configurer des systèmes supportant IPSec, seules les deux passerelles en sont dotées. En mode Tunnel, les traitements IPSec sont appliqués après que l ensemble des données aient traversés la couche IP également. Les entêtes (AH et/ou ESP) portent sur un datagramme IP en entier et non plus seulement sur un datagramme TCP ou UDP ; et une nouvelle entête IP est rajoutée

21 CHAPITRE I. LES PROTOCOLES IPSEC Tunnel Gate To Gate IPSec Gateway A IPSec Gateway B Fig. I.4 IPSec en Mode Tunnel au paquet. IP Hdr Data New IP Hdr IPSec Hdr IP Hdr Data A Protéger Fig. I.5 En-tête en Mode Tunnel Comme on peut le voir, les adresses source et destination sont entièrement masquées, les correspondants rééls ne sont pas visibles, et l on dispose d une protection contre l analyse de trafic. Le mode Tunnel est le mode le plus souvent utilisé et déployé à grande échelle. I.2.2 Protocole AH, Protocole ESP IPSec repose principalement sur deux protocoles destinés à sécuriser le trafic : AH : Le protocole AH - Authentication Header. ESP : Le protocole ESP - Encapsulating Security Protocol

22 I.2. VUE GÉNÉRALE DES PROTOCOLES Protocole AH AH (Authentication Header) est utilisé principalement pour fournir une authentification et un contrôle d intégrité des données. AH ne permet pas de chiffrer les paquets. Il ne doit donc pas être utilisé lorsque l on souhaite avoir la confidentialité des données. AH protège l ensemble des données, ainsi que l ensemble des en-têtes non modifiables (numéro de protocole, port de destination, etc). Il n offre, en revanche, pas de protection sur l ensemble des en-têtes susceptibles d être modifiées lors du trajet du paquet comme par exemple le champ TTL ou le champ ToS de l en-tête IP. Suivant le mode Transport ou Tunnel, la figure I.6 décrit la manière dont AH encapsule les données. IP Hdr Data Paquet Original IP Hdr AH Data Mode Transport Authentifié sauf les champs modifiables dans IP Hdr New IP Hdr AH IP Hdr Data Mode Tunnel Authentifié sauf les champs modifiables dans New IP Hdr Fig. I.6 Authentication Header - AH Comme on peut le voir, AH protège l ensemble des champs non-modifiables du paquet. Il peut être utile lorsque la confidentialité des données n est pas recherchée d une part, et d autre part lorsqu une authentification forte du paquet est exigée. La transmission du résultat d une élection où les données sont destinées à être publiques mais doivent provenir de source sûre est un bon exemple

23 CHAPITRE I. LES PROTOCOLES IPSEC Protocole ESP ESP est le deuxième protocole définit dans la suite IPSec. Protocole le plus répandu dans la pratique, ESP (Encapsulating Security Payload) offre également la confidentialité des données. L ensemble des données sont alors chiffrées avant dêtre transmises, suivant différents mécanismes et protocoles que l on détaille à la section I.2.3. ESP chiffre, d une part, le champ Data des paquets suivant un ensemble de paramètres négociés au préalable avec l hôte distant, et d autre part, utilise des mécanismes d authentification (comme HMAC) afin de fournir une protection anti-rejeu ou encore une intégrité des données. A ce titre, ESP est un protocole très complet, offrant toute une panoplie de protections allant du simple chiffrement des données jusqu à leur authentification en plus. La figure I.7 décrit la manière dont ESP encapsule l ensemble des champs des paquets. IP Hdr Data Mode Transport IP Hdr ESP Hdr Data ESP Trailer ESP Auth CHIFFRE AUTHENTIFIE Mode Tunnel New IP Hdr ESP Hdr IP Hdr Data ESP Trailer ESP Auth CHIFFRE AUTHENTIFIE Fig. I.7 Encapsulating Security Payload - ESP

24 I.2. VUE GÉNÉRALE DES PROTOCOLES AH et ESP Il est tout à fait possible d utiliser les deux protocoles conjointement, même si cela reste très peu utilisé. Lorsque l on recherche à avoir une confidentialité des données et une authentification complète du paquet, il est possible d utiliser dans un premier temps ESP afin de chiffrer les données et authentifier les champs concernés, puis d aposer AH sur le paquet ESP obtenu. On a ainsi une authentification complète de tous les champs du paquet et un chiffrement des données. Ce mode de fonctionnement est néanmoins très lourd et gourmand en bande passante. En pratique, le mode Tunnel ESP reste très sécurisé et offre l ensemble des services de sécurité mentionnés plus haut. I.2.3 Etablissement d une négociation IPSec Phases IPSec Il existe deux façons d établir des échanges chiffrés entre deux hôtes IPSec : Dynamique : La négociation dynamique est la plus répandue, la plus sécurisée et la plus conseillée. Elle permet de négocier à la volée l ensemble des paramètres nécessaires et assure le renouvellement périodique des clés cryptographiques mises en jeu et leur échange de manière sécurisée. Statique : Principalement maintenue pour des raisons de compatibilités, ce mode de négociation est très obsolète et présente quelques failles de sécurité, puisque les clés sont non seulement statiques, donc jamais renouvellées. Ainsi, les tentatives d attaques par brute force ont plus de chances d aboutir. Cette méthode de négociation ne sera pas abordée dans le cadre de ce rapport. Une négociation IPSec dynamique, c est à dire utilisant un démon de négociation IKE, se fait principalement en deux étapes ou phases. Phase 1 : La première phase sert à authentifier mutuellement les deux correspondants et d établir un canal de transmission sécurisé. Par la suite, l ensemble de la configuration et paramètres nécessaires sont négociés afin de protéger les différents échanges (les durée de vie, les informations diverses, etc). Lorsque cette phase est terminée, les deux correspondants disposent d une ISAKMP SA. Il s agit d un canal de transmission securisé par lequel les deux correspondants vont s échanger différentes informations, y compris les clés cryptographiques destinées à chiffrer et/ou authentifier le trafic des données proprement dites. Phase 2 : La deuxième phase permet essentiellement de se mettre d accord sur les protocoles cryptographiques à utiliser pour chiffrer et authentifier tel ou tel type de trafic entre les deux hôtes ; et de transférer les clés cryptographiques nécessaires. Une fois cette phase réalisée, les correspondants disposent de deux IPSec SA chacun

25 CHAPITRE I. LES PROTOCOLES IPSEC A partir de ce moment, les deux hôtes peuvent alors s échanger du trafic de manière sécurisée. Les SAs sont développées plus en détails dans la section I.3.2. Politiques et Associations de sécurité Etant donné un trafic qui doit être chiffré avec tel protocole, un autre avec tel protocole et un dernier ne devant pas l être, comment ce trafic est-il effectivement traité? Lorsque les paquets arrivent (cf Fig I.8) entre la couche Transport et la couche Réseau, le noyau vérifie tout d abord si ce trafic doit subir un traitement IPSec ou non en fonction de différents champs contenus, entre autres, dans l en-tête IP. Pour cela, le noyau cherche une politique de sécurité correspondant au paquet, dans une base de politiques (SPD) préalablement configurée par l administrateur. La SPD permet de savoir si un type de trafic doit subir un traitement IPSec ou pas. Si ce n est pas le cas, le paquet sera envoyé en clair. On pourrait schématiser la SPD - Security Policy Database - par une seconde table de routage. Pqt en Clair IP IPSec Consulte IPSec:Oui /Non? S P D Pqt en Clair Administrateur Configure Maintient, Négocie Consulte Modifie, Supprime logs I K E SA1 SA2 SA3... S A D Pqt Chiffré Tunnel IPSec Demande de Création de SA Fig. I.8 Synoptique de Fonctionnement IPSec Si c est le cas, il faut à présent savoir à quel type de tunnel il correspond. Le type (Tunnel, Transport, ESP, AH) est également stocké dans la SPD. Une base de données de SA (SAD) est maintenue en temps réel et contient l ensemble des SAs des politiques IPSec actives. Dans le cas où le noyau trouve une SA correspondante, il va y lire les paramètres nécessaires (protocole à utiliser,

26 I.3. DESIGN ET ARCHITECTURE DE SÉCURITÉ taille des clés, etc) et traiter le paquet en conséquence (ESP ou AH, Tunnel ou Transport) avant de l envoyer. Si la SA n est pas trouvé, le noyau demande au démon IKE le démon racoon du projet ipsec-tools en locurrence de négocier une SA avec l hôte distant. Durant cette négociation, l ensemble des paquets devant subir un traitement IPSec à destination de cet hôte sont ignorés. Ceci explique le temps de latence lors de la première communication à travers un tunnel IPSec. Le détail et l étude approndie des protocols AH et ESP est disponible dans l annexe A. Maintenant que l on a étudié les protocoles de transmission d IPSec, il s agit de voir comment les différents paramètres, clefs de chiffrement, protocoles, identités des correspondants, etc. sont gérés dans le système. Comment se fait le renouvellement périodique des clés? Comment detecte t-on lorsque l hôte en face ne répond plus? Que faire dans ces cas là? Faut-il garder les paramètres en espérant que l absence soit temporaire? Ou au contraire les supprimer directement? Autant de question auxquelles nous tenterons de répondre dans la section suivante. I.3 Design et architecture de sécurité L architecture complexe d IPSec repose sur le principe d Association de Sécurité. Il s agit d une structure contenant un ensemble de paramètres négociés avec l hôte avec lequel l on souhaite établir une connexion IPSec. Ces différentes associations sont stockées dans des bases de données d associations, afin de retrouver rapidement celle qui correspond à tel ou tel hôte. I.3.1 Extrémités de tunnel, de trafic On appelle extrémité de tunnel (cf. Fig I.9) les deux extrémités entre lesquelles le trafic sera effectivement chiffré et/ou signé. Il s agit des adresses des deux passerelles IPSec dans le cas d une configuration en mode tunnel ou de l adresse des deux correspondants dans le cas d une configuration en mode transport. On appelle extrémité de trafic (cf. Fig I.9) les sous-réseaux qui sont autorisés à emprunter le tunnel de part et d autre de la passerelle. Les extrémités de trafic constituent un point essentiel de l architecture IPSec : un sous-réseau bien que faisant partie du réseau interne de l entreprise, s il n est pas autorisé à envoyer du trafic IPSec vers telle ou telle passerelle sera détecté au moment de la vérification sur l extrémité de tunnel

27 CHAPITRE I. LES PROTOCOLES IPSEC Fig. I.9 Extrémités de tunnel, de trafic - I.3.2 Associations de Sécurité Les SAs représentent une structure au coeur de toute connexion IPSec. Il s agit d un ensemble ou d une collection de paramètres permettant d établir un tunnel de commmunication sécurisé entre deux hôtes. Les SAs sont unidirectionnelles, il en faut ainsi deux pour une communication bi-directionnelle. Lorsque deux entités communiquent au travers d IPSec, il faut pouvoir distinguer la manière dont telles ou telles données sont chiffrées et/ou authentifiées de telles ou telles manières. Les SAs contiennent ainsi, pour un hôte distant donné, le protocole à utiliser (AH et/ou ESP), les algorithmes cryptographiques associés, les clés de chiffrement, la période de renouvellement des clés, etc. Elles sont identifiées par un numéro de SPI (Security Parameter Index). Le SPI permet de savoir comment un paquet arrivé sur l interface ipsec doit être authentifié et/ou déchiffré en allant consulter les paramètres de la SA à laquelle il correspond; ou alors, il permet de connaître les protocoles et clés à utiliser lors du chiffrement d un paquet à envoyer à un hôte donné. Le concept de SA permet d avoir différents degrés de chiffrement et/ou d authentification entre deux, voire plusieurs hôtes. A titre d exemple, si l on considère deux filiales où l accès aux services de mail est moins critique que l accès à des applications financières. Bien que le tunnel IPSec soit physiquement le même, il existera deux politiques de chiffrement, donc deux SAs de chaque coté afin de chiffrer les paquets à destination des applications financières à l aide de méthodes tres robustes (donc plus coûteuses en temps et en ressources), et les flux à destination des services mails à l aide de chiffrement d un degré moindre. Les différentes SAs négociées avec les différents hôtes sont stockées dans une base de données

28 I.4. PHASES DE NÉGOCIATION de SAs appellée SAD ou SADB (Security Association Database). I.3.3 politiques de sécurité Pour chaque paquet entrant ou sortant, il faut être capable de déterminer si ce paquet est destiné à une quelconque interface IPSec ou s il doit être envoyé en clair sur le réseau. Il existe pour cela une table d entrées de politiques de sécurité, pouvant être assimilée à une table de routage interne, permettant de savoir à quel type de traffic est destiné un paquet. Ces différentes politiques sont stockées dans une SPD (Security Policy Database) qui est donc consultée à chaque paquet sortant ou entrant. L administrateur a la charge de configurer et maintenir les politiques dans le noyau à travers des outils userland comme setkey du projet ipsec-tools, largement utilisé pendant le stage, de pair avec le démon IKE racoon. Lorsqu une SA n existe pas ou n est plus valide et qu un paquet doit être envoyé au travers d une connexion IPSec, le noyau demande a un démon IKE de négocier une SA avec l hôte distant. I.4 Phases de négociation La négociation d une SA se fait principalement en deux phases. A l issue de la Phase 1, une ISAKMP SA est crée. A partir de ce moment, les deux entités disposent d un tunnel sécurisé et peuvent négocier les paramètres de sécurisation des données en elles-mêmes : il s agit de la Phase 2 et permet d établir une IPSEC SA. I.4.1 Phase1 : ISAKMP SA La Phase 1 représente la négociation initialle afin d établir la ISAKMP SA 6 entre les deux hôtes. Elle peut se faire de manière robuste lorsque les conditions le permettent (notamment lorsque l adresse IP du correspondant est connue à l avance), il s agit dans ce cas du Main Mode ; ou elle peut se faire par l Aggressive Mode qui ne présuppose pas la connaissance de l IP de l hôte. La Phase 1 commence par envoyer la liste des propositions d authentification, de chiffrement ainsi que les durées de vies à négocier. Suivant la manière dont est configuré l hôte distant, la négociation peut être ou ne pas être acceptée. La deuxième étape consiste à calculer des clés de session par l intermédiaire d un échange Diffie- Hellman. Une fois les clés de sessions établies, tout le traffic à partir de ce moment est chiffré. 6 Contrairement à une IPSEC SA, la ISAKMP SA est bidirectionnelle

29 CHAPITRE I. LES PROTOCOLES IPSEC Authentification des correspondants Il faut, à présent, authentifier les deux correspondants. racoon dispose de plusieurs méthodes d authentification, dont deux très couramment utilisées : Pre Shared Key : Il s agit d une clé pré-partagée à l avance par les deux hôtes (par hôte, on entend une adresse IP, un login ou encore un FQDN). A noter qu à l heure actuelle, dans le démon racoon, il n est pas possible de configurer une clé qui soit partagée par un ensemble d utilisateurs ou par tout le monde (appellé aussi Wildcard ou Goup Password chez TM ), ce qui présente des risques de sécurité non négligeables. C est la méthode d authentification la plus fréquemment utilisée car la plus simple à mettre en place. Néanmoins, comme nous le verrons dans le chapitre suivant, l authentification en pre shared key est très déconseillée voire à proscrire lorsqu il s agit d authentifier des hôtes de types Road Warrior, c est à dire ceux dont l adresse IP n est pas connue à l avance. Certificats X509 : Utilisant une Public Key Infrastructure, c est une méthode d authentification par certificats numériques X Il s agit de la méthode la plus sûre actuellement disponibles à au moins deux conditions : avoir une CRL 8 à jour très régulièrement et en ce qui concerne les Road Warrior, avoir deux CA différentes, l une pour signer le certificat de la passerelle IPSec et la deuxième pour signer les certificats utilisateurs. Une fois l authentification des correspondants achevée, chacun accuse de la bonne réception des différents paramètres et la ISAKMP SA est considérée comme établie. Main Mode - Aggressive Mode L établissement de la ISAKMP SA peut se faire soit par six échanges (Main Mode) ou par un couple d échanges en moins (Aggressive Mode). Le Main Mode (cf Fig. I.10) permet d avoir la Protection des Identités des correspondants (Identity Protection Mode)! Les échanges des empreintes des différentes identités ne se font qu après l établissement d un secret commun partagé par les deux entités : l échange Diffie Hellman est fait au niveau 3 et 4 pour établir la clé de session et l échange des empreintes est faite au niveau 5 et 6. L identité et l empreinte de l identité sont tous deux chiffrés avec la clé partagée. En Main Mode avec une authentification en Pre Shared Key, comme les échanges 5 et 6 sont chiffrés, c est l adresse IP du correspondant qui fait office d identifiant ; ce qui va devenir problématique pour les road warriors puisque leur IP n est a priori pas connue à l avance! L Aggressive Mode (cf Fig. I.11) en revanche ne supporte pas la Protection des Identités 9 : les identifiants sont envoyés en clair sur le réseau. En effet, l échange se fait avant 7 Un certificat X509 est une méthode d authentification liant une clé publique à un nom ou une adresse 8 CRL : liste de révocation mise à jour régulièrement, elle a définir l ensemble des certificats qui ne sont plus valides. 9 Sauf lorsqu il s agit d une authentification en Hybrid

30 I.4. PHASES DE NÉGOCIATION MAIN MODE Initiateur Repondeur HDR, SA =============> <============= HDR, SA HDR, KE, NONCE =============> <============= HDR, KE, NONCE HDR*, IDii, HASH =============> <============= HDR*, IDir, HASH Fig. I.10 Echanges de Phase 1 en Main Mode qu un secret commun ne soit determiné entre eux. L empreinte d authentification n est pas chiffré, contrairement au Main Mode et est envoyé en clair. Des identités non protégées et une empreinte d authentification non chiffrée rend l Agressive Mode susceptible à des attaques de type Man In The Middle (MITM) lorsqu il est utilisé de paire avec une authentification en Pre Shared Key. Si de plus, les Pre Shared Keys sont faibles, un attaquant potentiel peut déterminer la clé, hors ligne, par une attaque par force brute sur l empreinte non chiffrée. AGGRESSIVE MODE Initiateur Repondeur HDR, SA, KE =============> NONCE, IDii <============= HDR, SA, KE, NONCE IDir, HASH HDR*, HASH =============> Fig. I.11 Echanges de Phase 1 en Aggressive Mode

31 CHAPITRE I. LES PROTOCOLES IPSEC Chiffrement Hash PFS Lifetime IPSec Mode AES SHA-1 Désactivé 3600 sec Tunnel DES MD5 Group 1 2h Transport 3DES Group 2 1 week Blowfish Group 5 Fig. I.12 Quelques exemples de paramètres négociés lors d une Phase 2 I.4.2 Phase2 : IPSEC SA Après la Phase 1, durant la Phase 2, les IPSEC SAs sont négociées par IKE, pour sécuriser le flux de données en lui même. Ces négociations sont déjà chiffrés et authentifiés puisqu elles reposent sur la ISAKMP SA fraîchement établie. On appelle également ce mode de négociation le Quick Mode. Comme les IPSEC SA sont uni-directionnelles par nature, il va en suivre un double échange de clés de chiffrement, l une pour le trafic entrant et l autre pour le trafic sortant. L avantage que représente cette stratégie est de doubler le travail de l attaquant à l écoute du réseau, puisqu il lui faudra déchiffrer le trafic dans les deux sens. Durant cette Phase sont négociés des paramètres comme les algorithmes de chiffrement, de calcul de signature, les clés de chiffrement ou encore les durées de vies des différentes SAs (cf Tab. I.12). Perfect Forward Secrecy Le PFS - Perfect Forward Secrecy determine la manière dont sont générées les clés de chiffrement des différentes IPSEC SAs. Lorsqu il est désactivé, les clés de(s) IPSEC SA(s) sont générées à partir de la clé principale de la ISAKMP SA correspondante. Lorsque l on l active, ces clés ne sont plus dépendantes de la clé principale, mais au contraire générées à partir d un nouvel échange Diffie Hellman à chaque nouvelle IPSEC SA négociée. La taille du Group PFS peut être de : 1 avec une longueur de clé de 768 bits, 2 avec une longueur de clé de 1024 bits, 5 avec une longueur de clé de 1536 bits. L activation du PFS permet d accroîttre la sécurité des SAs et donc des échanges en fournissant une entropie plus importante et donc une plus grande robustesse face aux attaques cryptographiques liées à ce type de génération de clés. Il faut tout de même porter attention au fait que les échanges Diffie Hellman sont basés sur des exponentiations de taille non négligeable et sont de ce fait gourmands en ressources CPU. Il n est

32 I.5. RÉSUMÉ pas impossible de constater une perte de performances par l activation d un group PFS trop grand. I.5 Résumé IPSec constitue une suite de protocole de sécurisation du trafic au niveau IP. Il repose sur deux protocoles : AH - Authentication Header et ESP - Encapsulating Security Payload. Les paramètres nécessaires à l utilisation de ces mécanismes (clés, algorithmes, durée de vie) sont stockée dans des SAs. Une base de donnée de SAs est maintenue dans le noyau et gérée à grâce au protocole IKE implémenté dans différents démons, comme racoon utilisé ici. Lorsqu un flux arrive au niveau IP, une base de données de politiques de sécurité - SPD est consultée afin de savoir le type de sécurité à fournir au flux. Le noyau recherche alors la SA correspondante, chiffre le paquet et l envoie. Si la SA n existe pas, une demande création est envoyée au démon IKE qui se charge de la négocier auprès de l hôte distant. Plusieurs modifications, évolutions, extensions ont été apportée à différentes parties des protocoles IPSec depuis une dizaine d année. Certaines ont été normalisées par l IETF (bien qu il faille toujours supporter les drafts non RFC) et d autres non. Les extensions IPSec les plus significatives se concentrent d une part sur l authentification des tiers communiquants et d autre part sur la transmission d informations internes à des hôtes mobiles, de manière sécurisée

33 First they ignore you, Then they laugh at you, Then they fight you, Then you win. Mahatma Gandhi CHAPITRE II Extensions IPSec et problématiques de sécurité Résumé : Les extensions IPSec sont des modifications apportées au fur et à mesure afin d améliorer non pas les protocoles en eux mêmes, mais plutôt un certain manque de communication et/ou d authentification des deux hôtes. Un des objectifs principaux du stage étant l étude de ces extensions, nous en approfondirons trois dont l une est destinée à etre intégrée dans la pile IPSec du firmware NETASQ. XAuth : Extension principalement destinée aux clients mobiles, il permet d avoir une authentification forte du côté du client. On authentifie non seulement la machine, mais également l utilisateur. Hybrid : Lorsque le mode hybrid est activé, l authentification des correspondants peut être asymétrique, c est à dire utilisant des méthodes d authentification différentes des deux côtés. Une passerelle IPSec pourrait s authentifier par certificats tandis qu un client mobile en face par clé pré-partagée. Mode-Config : Est une extension permettant de transmettre de manière sécuriée et à la volée certaines informations relatives à l architecture interne des réseaux aux clients mobiles en particulier. Lorsqu un client mobile se connecte au réseau interne de son entreprise par un tunnel IPSec, à moins de les embarquer statiquement sur sa machine, il faudrait, par exemple, lui envoyer une adresse IP locale 1, ou encore des serveurs DNS et/ou WINS internes. Cette extension est destinée à être intégrée dans le module IPSec NETASQ. D autre part, si IPSec englobe une suite de protocoles très robustes théoriquement, nous verrons qu elle présente quelques problématiques voire failles de sécurité lorsqu elle est déployée de manière inapropriée, ou configurée de manière bancale ; comme les SAs statiques, ou encore une mauvaise de gestion (pas de gestion du tout) de CRLs, l utilisation de clé pré-partagée en mode aggressif, etc.

34 II.1. AUTHENTIFICATION XAUTH Ce chapitre présentant les extensions IPSec principalement dans le cadre des road warriors, on appellera Client un client mobile, ne disposant pas d une adresse IP fixe connue à l avance ; et Passerelle le serveur ou la passerelle IPSec sur laquelle le client mobile souhaite établir une connexion. L adresse IP de la passerelle est fixe et connue à l avance du client. II.1 Authentification XAuth XAuth (Extended Authentication in IKE) permet d avoir un mécanisme supplémentaire afin d authentifier le client, après l établissement d une ISAKMP-SA. Dans le cas ou XAuth est utilisé comme méthode d authentification du client, il est important que la passerelle ne fasse absolument rien avant que XAuth n ait correctement abouti. Ce point sera rappelé à la section II.1, lors de la description d XAuth. II.1.1 Principe et fonctionnement XAuth est une méthode extension IKE décrite dans le draft-beaulieu-ike-xauth-02.. Elle permet d avoir un complément d authentification après l établissement d une ISAKMP-SA. Il s agit d une extension permettant d authentifier le client par diverses méthodes (Radius, OTP, Kerberos, LDAP, SecurID, etc). Pour signaler l utilisation d XAuth, celui ci dispose d un Vendor ID envoyé à la passerelle lors de la négociation de phase 1. Il s agit des 8 octets suivant : VendorID = 0x DFD6B712 Les types de messages utilisés pour XAuth sont les mêmes que ceux utilisés lors d un Mode Config (cf. section II.3), à savoir ISAKMP-CFG-REQUEST, ISAKMP-CFG-REPLY, ISAKMP-CFG-SET, ISAKMP-CFG-ACK. Seuls les attributs des messages changent. Ces messages sont dits de type Transaction Exchange, donc des messages envoyés à titre d informations, et protégés par les paramètres de négociation de la ISAKMP-SA. Nous reviendrons plus en détails sur ce type d échanges lors de la description du mode config et du développement de celui ci. Le tableau II.1 nous montre les principaux attributs dont dispose la méthode XAuth afin d authentifier le client. Un échange de type XAuth peut être initié par le client ou par la passerelle. Les messages échangés seront ainsi de type REQUEST/REPLY ou SET/ACK. L authentification peut se faire par un simple jeu de login/password ou être basée sur plusieurs facteurs comme un Challenge/Password pour cacher le mot de passe, ou encore une authentification demandant un Challenge après l insertion d une clé USB ou autre. II.1.2 Notifications de type XAuth Lors de l établissement de la ISAKMP-SA, la passerelle doit être notifiée de l XAuth, sinon elle pourrait envoyer au client des paquets Mode Config ou des paquets de Phase 2 Quick Mode. Ceci

35 CHAPITRE II. EXTENSIONS IPSEC ET PROBLÉMATIQUES DE SÉCURITÉ XAUTH-TYPE XAUTH-USER-NAME XAUTH-PASSCODE XAUTH-PASSWORD XAUTH-MESSAGE XAUTH-CHALLENGE XAUTH-DOMAIN XAUTH-STATUS type d échanges définis dans Transaction exchanges. login, nom dans un X.509, un DN, un , etc. token passcode le mot de passe de l utilisateur. un message ascii en clair, un challenge par exemple. challenge au format texte. domaine dans lequel l utilisateur doit s authentifier. OK=1, FAIL=0, statut de l authentification. XAUTH-NEXT-PIN XAUTH-ANSWER Fig. II.1 Principaux attributs lors d un échange XAuth peut se faire de deux manières différentes : Notification lors d un échange de phase 1 Le client peut indiquer qu un XAuth va suivre en mettant une notification dans le payload de n importe quel paquet de phase 1. A moins que les deux entités supportent les mécanismes de calcul d empreinte décrits dans le draft-ietf-ipsec-ike-hash-revised-03.txt, ce payload n est pas authentifié et ne doit par conséquent pas être utilisé. Notification via les attributs de la ISAKMP-SA L utilisation de XAuth est notifiée en donnant la méthode d authentification choisie dans les attributs de la ISAKMP-SA négociée lors du premier échange (section proposal dans la section remote de racoon). Lorsque la passerelle reçoit une demande de XAuth dans les attributs de la ISAKMP-SA, aucun échange à part XAuth n est possible après une phase 1 correctement négociée. A choisir une implémentation plutôt qu une autre, en plus des contraintes de comptatibilité, il serait plus raisonnable de transmettre la notification de XAuth en tant qu attribut spécifique dans le payload de la ISAKMP-SA en cours de négociation. Dans le cas général, un échange XAuth est le plus souvent initié par le client, la passerelle se contentant de répondre aux requêtes. II.1.3 Sécurité de XAuth XAuth et ISAKMP-SA Le niveau de sécurité de XAuth est directement lié à celui de la ISAKMP-SA établie. La sécurité de XAuth repose entièrement sur la ISAKMP-SA, et offre une authentification complémentaire du client uniquement sous réserve que la ISAKMP-SA ait été négociée de manière

36 II.1. AUTHENTIFICATION XAUTH sûre : un XAuth après une phase 1 établie en Aggressive Mode Pre-Shared-Key a un niveau de sécurité assez faible. Ce point est développé dans la section suivante présentant l authentification en Group Password. Un XAuth, même s il est fait avec des méthodes d authentification fortes à plusieurs facteurs, présente des faiblesses s il est fait sur la base d une ISAKMP-SA ayant un faible niveau de sécurité. Ainsi l authentification du client, même si elle est, certes, faite au niveau de XAuth, est basée sur la robustesse de la phase 1 associée : il ne faudrait en aucun cas précipiter l établissement d une ISAKMP-SA, sous prétexte que l authentification du client se fera de toute façon au moment de l échange XAuth qui s en suit. XAuth et...uniquement XAuth Lorsque l authentification de l utilisateur inclut un échange XAuth, on doit considérer que la phase 1 n est pas complètement finie (et donc que la ISAKMP-SA n est pas encore établie entre les deux hôtes) tant que XAuth n est pas terminé et validé. Une fois que l utilisateur s est correctement authentifié échanges XAuth terminés et validés, la ISAKMP-SA peut être considérée comme opérationnelle et l on peut alors commencer des échanges, par exemple, de type Mode Config ou des négociations Quick Mode en phase 2. D autre part, avant que l échange XAuth ne soit terminé, l utilisateur n est pas encore complètement authentifié sur la passerelle. A ce titre, aucun échange ne doit survenir entre les deux hôtes tant que XAuth n a pas abouti (c est à dire terminé et validé). Toute tentative de négociation de type Mode Config ou de négociation de phase 2, entre autres, sont donc obligatoirement rejettées. Dans le cas où XAuth se termine mais que l authentification échoue pour une raison ou pour une autre, aucune information n aura ainsi été transmise. Le dialogue s arrête alors immédiatement, et la ISAKMP-SA correspondante est supprimée 2. En effet, si le Xauth n est pas validé (i.e que l authentification échoue), l utilisateur n est toujours pas authentifié auprès de la passerelle! Dans ce cas, il n est pas pertinent d avoir une ISAKMP-SA avec ce client : elle doit donc être supprimée. XAuth et transmission d informations sensibles Puisqu un échange Auth fait intervenir le client et la passerelle d un côté, et la passerelle et le serveur d authentification de l autre, il faut être en mesure de maîtriser les deux parties, alors que jusqu ici, nous nous sommes uniquement intéressés au côté public entre le client et la passerelle. La transmission des informations relatives à l authentification des utilisateurs doit se faire de manière sécurisée entre le client et la passerelle, mais également entre la passerelle et le serveur qui authentifie! L échange de mots de passe ne se fait pas en clair entre le client et la passerelle IPSec, et lorsque l échange se fait de manière chiffrée, le récepteur est préalablement authentifié, en utilisant 2 le draft préconise sa suppression

37 CHAPITRE II. EXTENSIONS IPSEC ET PROBLÉMATIQUES DE SÉCURITÉ un Mode Hybrid par exemple, qui est développé à la section II.2. D autre part, le transit d informations entre le serveur qui authentifie et la passerelle IPSec est également sensible, y compris sur un réseau local interne. Si les équipements d authentification sont physiquement isolés du réseau interne et directement reliés à la passerelle, les mots de passe (ou des empreintes de mots de passe, etc) ne circulent pas exactement de la même manière que si les serveurs sont branchés sur un HUB relié à plusieurs centaines de stations de travail, où tout le monde possède un accès potentiel aux données en les sniffant sur le réseau. II.1.4 XAuth et le Group Password La négociation d une phase 1 en Aggressive Mode Pre-Shared-Key présente un faible niveau de sécurité, même lorsqu un XAuth s en suit. Lorsque qu une seule Pre-Shared-Key est utilisé afin d authentifier plusieurs utilisateurs (!) (méthode connue également comme Goup Password, un mot de passe de "groupe"), il n est plus possible de garantir la sécurité des identifiants des utilisateurs légitimes s y connectant, en particulier les road warriors, bien que ce type d authentification soit la méthode par défaut de quelques clients VPN/IPSec. La stratégie adoptée par NETASQ a été de ne pas proposer ce type d authentification : les clients mobiles auront un certificat X509 ou une clé RSA. Pourquoi ce type d authentification est-il si peu sûr? Comme nous l avons vu, lors de la négociation d une phase 1 en Main Mode, les différents idientifiants sont protégés (Identity Protection Mode), qu il s agisse d une authentification par Pre Shared Key ou par certificats X.509. Puisque l empreinte d authentification est chiffrée, sa provenance est determinée uniquement par l IP de l émetteur. Or, les road warrios n ont, par définition, pas d adresse IP fixe. En Aggressive Mode combiné avec une authentification en Pre-Shared-Key, même lorsque la clé est uniquement partagée deux entités, rien n empêche un potentiel attaquant écoutant le trafic réseau d intercepter l empreinte et d en déduire la clé si jamais celle ci se revélait faible. Une authentification en Pre-Shared-Key en Aggressive Mode, lorsqu elle est destinée aux road warriors, est encore plus vulnérable puisque la passerelle IPSec et l ensemble des road warriors possèdent la même Pre-Shared-Key! Lorsque la négociation se met en place, la passerelle sait, dans le meilleur des cas, qu elle parle à l un des road warriors, elle n a aucun moyen de savoir précisément lequel. Certes, XAuth intervient après l établissement de la phase 1, pour authentifier le client. Comme nous l avons vu précédemment, l authentification du client, même si elle se pas fait au niveau de XAuth, repose sur la robustesse de la ISAKMP-SA associée. Si celle ci a été établie sur la base d une Pre-Shared-Key, une authentification supplémentaire grâce au XAuth n y apporte

38 II.2. HYBRID-AUTH pas un niveau de sécurité supplémentaire puisque le niveau de sécurité de l ensemble d une chaîne equivaut à celui de son maillon le plus faible! Il serait, dans ce cas, envisageable d attribuer une clé dédiée à chaque utilisateur. Cette approche possède un inconvénient majeur : il n est pas possible, à la réception du paquet, de savoir quelle clé utiliser pour valider l empreinte, puisqu aucun nom d utilisateur n est transmis et que l adresse IP du client est dynamique. Pour utiliser l authentification en clé pré-partagée, il devient alors impossible de ne pas utiliser une clé de groupe. D autre part, on peut également envisager que le client soit légitime et qu il négocie avec une passerelle frauduleuse. Un road warrior n a aucun moyen de savoir qu il dialogue bien avec la passerelle : un potentiel attaquant pourrait déjà posséder la clé, et il pourrait à son tour négocier avec la vraie passerelle, et ainsi, écouter, intercepter, modifier, etc l ensemble du traffic...combiné avec Mode Config, ceci peut permettre à un attaquant de connaître l ensemble de l architecture réseau interne, d usurper des données, etc. La solution serait donc de transmettre un username lors de la négociation...et ceci peut se faire en utilisant des certificats. Si le client en arrive à être victime d une telle attaque MITM pendant un XAuth, celui ci dispose alors, non seulement d un moyen d écouter le traffic, mais également de pouvoir négocier autant de sessions IKE qu il le désire, et pour peu que le mot de passe de l utilisateur soit le même à différents endroits, l attaquant peut lire les mails de l utilisateur, s authentifier auprès de différents serveurs internes, accéder à des informations confidentielles sur diverses base de donées, etc. Lors d une négociation de phase 1, on authentifie alors la passerelle dans un premier temps : le client doit être certain qu il dialogue bien avec la passerelle légitime. II.2 Hybrid-Auth Hybrid Auth est une autre extension IKE décrite dans le draft-zegman-ike-hybrid-auth-01.. Elle permet de réaliser une authentification asymétrique entre les différentes entités. II.2.1 Présentation générale Les méthodes classiques d authentification IKE reposent sur le fait que celle-ci soit mutuelle, chacune des entités s authentifie vis à vis de l autre en utilisant la même méthode d authentification. L authentification en Hybrid Auth fournit une asymétrie dans la manière dont la passerelle et le client s authentifient : la passerelle utilise des méthodes de cryptographie asymétrique (clés publiques, clés privées) alors que le client (typiquement un road warrior) va utiliser une authentification de type Challenge/Réponse. Il est tout à fait possible de faire l inverse également. Ainsi,à la fin d une négociation aboutie de phase 1 utilisant le Mode Hybrid, la passerelle s est unidirectionnelement authentifiée auprès du client. Il n en est rien quant à l authentification du client. Pour compléter l authentification, XAuth (cf. II.1) pourra être utilisé. Après un échange Hybrid Auth, on se retrouve donc dans la situation suivante : Le client mobile sait à présent qu il dialogue bien à la bonne passerelle

39 CHAPITRE II. EXTENSIONS IPSEC ET PROBLÉMATIQUES DE SÉCURITÉ Les échanges entre le client et la passerelle sont sécurisés sur la base de la ISAKMP-SA établie. La passerelle ne connait pas encore l identité du client mobile. Une authentification du client est nécessaire. II.2.2 Fonctionnement Le Mode Hybrid intervient lors des échanges de négociation de phase 1 : une méthode d authentification Hybrid est proposée dans les attributs de la ISAKMP-SA. Les valeurs peuvent être les suivantes : HybridInitRSA HybridInitDSA HybridRespRSA HybridRespDSA Lorsqu un client initie la négociation, il choisit les attributs HybridInit* tandis que lors de l initiation par la passerelle, il s agit de HybridResp*. Ainsi, lorsque la négociation se fait en Main Mode initié par le client, le paquet 6 de la négociation envoyé par la passerelle est de la forme : HDR*, IDir, [ CERT, ] SIG_R où [ CERT, ] SIG_R permettent d authentifier celle-ci. En Aggressive Mode initié par la passerelle, le paquet 3 envoyé par la passerelle sera de la forme : HDR, [ CERT, ] SIG_I II.2.3 Authentification forte et complète Hybrid Mode authentifie la passerelle auprès du client. Pour que le client le soit également, on peut forcer l utilisation de XAuth juste après l établissement de la ISAKMP-SA. C est d ailleurs ce que préconise le draft, et c est la manière avec laquelle NETASQ authentifiera les road warriors. Ainsi, l utilisation du mode Hybrid est suivi, dans tous les cas, par un échange XAuth. Aucune information complémentaire, y compris en Mode Config ne doit être envoyée et/ou acceptée. Lorsque XAuth est terminé et validé, les deux entités se sont authentifiés mutuellement. Peuvent alors commencer des échanges en Mode Config, ou des négociations de phase 2, etc. Que l échange XAuth soit précédé d un échange Hybrid Auth ou pas, en cas d échec d authentification à l issue du XAuth, la ISAKMP-SA fraîchement établie est supprimée. Une fois que les hôtes sont authentifiés, dans le cas d un road warrior, à moins qu il n ait embarqué l ensemble des paramètres réseaux statiquement sur la machine, il faut les lui transmettre à présent. Le Mode Configuration se charge de cette tâche

40 II.3. MODE CONFIGURATION II.3.1 II.3 Mode Configuration Présentation Générale L extension Mode Config est décrite dans le draft-dukes-ike-mode-cgf-02.. Elle permet de transmettre à une machine hôte distante, typiquement un road warrior, certains paramètres réseaux, notamment ses extrémités distantes de trafic. Ces paramètres sont transmis de telle sorte que le client distant se comporte comme s il était sur un LAN du réseau interne, à ceci près que la connexion se fera par un tunnel IPSec. Cette transmission est protégée par la ISAKMP-SA, et intervient par conséquent après la négociation aboutie d une Phase 1, et impérativment avant toute tentative de négociation de Phase 2 puisque celle ci nécessite l ensemble des paramètres transmit lors du Mode Config. Lorsque que le Mode Config est utilisé seul, c est à dire sans XAuth ou Hybrid Auth, les négociations sont de la forme : (*) Phase 1 Main Mode ou Phase 1 Aggressive Mode (**) Mode Config - Transaction Exchanges (***) Phase 2 - Quick Mode pour la négociation initiale, et : (*) Mode Config - Transaction Exchanges (**) Phase 2 - Quick Mode pour les renouvellements de IPSec-SAs. II.3.2 Fonctionnement Les attributs disponibles peuvent être de nature diverse : il peut s agir de transmettre toute une configuration réseau à un road warrior comme une adresse locale, un masque de sous réseau, un serveur DNS/WINS, etc ; ou il peut juste s agir de transmettre l adresse d un serveur DNS interne pour qu il puissse résoudre les noms internes. Types de messages disponibles : ISAKMP CFG REQUEST ISAKMP CFG REPLY ISAKMP CFG SET

41 CHAPITRE II. EXTENSIONS IPSEC ET PROBLÉMATIQUES DE SÉCURITÉ ISAKMP CFG ACK Les paquets Transaction Exchanges sont basés sur un échange mutuel initié soit par la passerelle soit par le road warrior. Dans le cas où la passerelle souhaite transmettre les paramètres de son propre chef, il s agit d un couple d échange SET - ACK dans lequel la passerelle propose un certain nombre de paramètres (DNS, WINS, etc) et où le client envoie juste un accusé de récéption. Dans le cas où le client demande ces informations à la passerelle, il s agit d un couple REQUEST - REPLY où le client demande une configuration réseau formée de certains attributs et où la passerelle répond avec les mêmes attributs correctement définis, suivant sa configuration. Il existe déjà quelques implémentations permettant aux clients mobiles de se connecter sur les passerelles IPSec en ayant leur configuration réseau statique embarquée sur leur machine. Pour des raisons de compatibilités, il est nécessaire que l ajout d une implémentation Mode Config soit interopérable avec les implémentations actuelles : un client mobile supportant le Mode Config est censé pouvoir se connecter même s il refuse les paramètres qui lui ont été transmis en Mode Config qu il négocie avec des paramètres statiques, sous réserve que ceux ci soient valides. II.3.3 Paramètres disponibles Le démon racoon du projet ipsec-tools propose un ensemble de paramètres pouvant être transmis en Mode Config, en étant le plus conforme possible vis à vis du draft. Authentification : lors d un échange XAuth, permet de définir l équipement d authentification à utiliser : PAM, Kerberos, Radius... Adresse IP : transmission d une adresse IP locale (RFC 1918) au client mobile sur son interface IPSec. Masque de sous réseau : transmission du masque. DNS, WINS : transmission d adresse ou liste d adresse de serveurs DNS/WINS. Bannière : bannière personalisée lors de la connexion du client mobile. II.3.4 Pool et pénurie d adresses IP En Mode Config, le client peut se voir attribuer notamment une adresse IP locale. Cette attribution peut être gérée directement dans les fichiers de configuration de racoon ou alors à un niveau supérieur dans les fiches des utilisateurs d une base LDAP, par exemple. Il serait ainsi possible d imposer une adresse IP locale à un utilisateur, pour qu il ne puisse par exemple pas négocier une autre adresse IP que celle qu on lui a attribué lors d une phase 2. Dans le cas où la gestion des IPs est faite par LDAP, il faut au préalable s assurer qu il n y ait pas de collisions lors de l attribution : une IP attribuée à un client est peut être déjà utilisée, ou plusieurs pools d IPs se chevauchent peut être. D autre part, lorsqu un pool d adresses IP a été défini, lorsque l ensemble des adresses ont été attribuées à des road warriors, il faudrait pouvoir remonter un message de manière la plus standardisée possible à l administrateur et au road warrior essayant de se connecter. Dans la version

42 II.4. INTERACTIONS XAUTH, HYBRID ET MODE CONFIG actuelle d ipsec-tools (0.7.1), racoon ne peut encore le faire. On peut également avoir le cas où certaines adresses sont déjà reservées, alors que les road warrios correspondants ne sont pas en train de les utiliser. Il faudrait ainsi trouver le meilleur compromis possible en terme de performances. II.4 Interactions XAuth, Hybrid et Mode Config Bien que les trois extensions soient indépendantes, dans le cadre d une configuration robuste il est préférable de vérouiller certaines interactions quant à l utilisation de l une ou l autre de ces méthodes. Mode Config : Indépendant, peut être utilisé avec/sans XAuth ou Hybrid mais uniquement après que le client se soit correctement authentifié, c est à dire après une phase 1 forte, ou après une phase 1 suivi d un XAuth. XAuth : Indépendant Hybrid : le mode Hybrid devrait être suivi d un XAuth afin de compléter l authentification. Ainsi, dans le cas idéal, l établissement d un tunnel IPSec entre une passerelle et un road warrior devrait se faire comme suit : 1. Initiation de la négociation de phase 1 par le client, authentification par Certificats ou par Hybrid Mode. 2. Transaction Exchange XAUTH pour authentifier le client. 3. Transaction Exchange ModeConfig pour lui transmettre ses paramètres réseaux. 4. Quick(s) Mode(s). II.5 Faiblesses d IPSec Le doigt a déjà été mis sur quelques unes des faiblesses des protocoles IPSec, comme l utilisation de l authentification en clé pré-partagée lorsque l on négocie en aggressif, ou encore l utilisation de SAs statiques rendant les attaques par force brute plus probables. Il ne s agit néanmoins pas des seules. Le but n étant pas de faire une liste exhaustive de l ensemble des failles connues, quelques pistes sont plus approfondies afin d avoir les configurations les plus robustes et sécurisées possibles. II.5.1 Failles cryptographiques intrinsèques La sécurité des protocoles IPSec est basée sur l implémentation des briques cryptographiques sur lesquelles ils reposent d une part, et sur les réseaux IP et leur fonctionnement d autre part. Lorsque les clés de sessions de renouvellement de Phase 2 sont par défaut dérivées à partir de données de Phase 1 par défaut. Elles ne sont donc pas indépendantes. Une attaque par force brute aboutie sur une clé de session uniquement donnerait des informations non négligeables sur la clé suivante, voire permettrait de la déduire. Le PFS - Perfect Forward Secrecy - permet

43 CHAPITRE II. EXTENSIONS IPSEC ET PROBLÉMATIQUES DE SÉCURITÉ de remédier à ce problème : les clés de sessions sont calculées uniquement sur la base d un échange Diffie-Hellman et non plus sur la base d informations déjà connues. Elles sont ainsi indépendantes les unes des autres. On peut également citer les attaques par bit flipping des protocoles de chiffrement en CBC - Cypher Bloc Chaining. Il s agit d inverser des bits dans un paquet ESP sans avoir à le déchiffrer puis le réémettre en espérant que cela génère une erreur ICMP qui, elle, sera envoyée en clair. II.5.2 Problèmes d implémentation Qu il s agisse de configurations par défaut, de configurations trop complexes ou même de failles dans le traitement des paquets dans la pile IPSec, les problèmes d implémentations existent et sont corrigés le plus rapidement possible. Certaines implémentations proposent des paramètres, par défaut, faibles lors de la négociation de Phase 1 et 2. Ces paramètres, si ils sont combinés consitiuent une faille non négligeable. La vérification de proposition par défaut de racoon est en mode strict. Or, près de 9 configurations sur 10 ont un mode de négociation en obey qui accepte la première proposition de l hôte. Les deux hôtes se retrouveront alors à chiffrer en DES alors que tout deux supportent AES. De plus, parmi les algorithmes de chiffrement par défaut, on retrouve toujours DES qui s est pourtant essouflé depuis les années Le PFS désactivé par défaut ne viendra que renforcer l insécurité de l ensemble. Certains bugs d implémentation permettent également à certains paquets qui ne sont pas censés emprunter le tunnel d être tout de même chiffré en passant à travers les politiques de sécurité. L inverse est plus dangeureux, lorsqu un paquet censé être chiffré sort en clair sur le réseau. On peut également citer tous les problèmes liés à la validation des certificats, aux CRLs non mises à jour, ou même à l absence de confrontation d un certificat à une CRL. Un utilisateur révoqué, ayant un certificat qui n est plus valide, pourra tout de même monter un tunnel IPSec vers sa passerelle. II.5.3 Déploiements réels L ensemble des faiblesses citées plus haut provoquent également des configurations bancales lors de leur déploiement effectif. Certaines configurations ne correspondent pas du tout aux attentes de sécurité des administrateurs, dû le plus souvent à une mauvaise compréhension des protocoles. A titre d exemple, le mot clé require dans racoon est utilisé dans l injection de politiques de sécurité par setkey. Lorsque l on désire établir plusieurs Phase 2 avec un même correspondant, require ne permet pas de distinguer une SA spécifique avec laquelle il faudrait chiffrer tel ou tel trafic. Il en résulte que n importe quel SA peut être utilisée pour chiffrer n importe quel type de trafic avec cet hôte donné : il n est pas du tout garanti que le trafic que l on désirait protéger de telle manière le sera

44 II.5. FAIBLESSES D IPSEC effectivement! Dans le pire des cas, on peut en arriver à chiffrer les données les plus importantes avec les configurations les plus faibles! D autre part, nombre d administrateurs sont persuadés que les politiques de filtrage ne sont pas nécessaires lors de la mise en place de tunnels IPSec. Les flux passant à travers ces tunnels ne sont donc pas surveillés. Une politique de filtrage est absolument nécessaire à la sortie du tunnel IPSec lorsque le paquet est déchiffré et qu il passe dans le réseau local classique. Enfin, on peut rajouter la mauvaise protection des secrets ou des certificats. Lorsque les clépartagée sont faibles ou connues par beaucoup trop de personnes, on ne peut garantir une authentification forte. Il en est de même pour les certificats, où les CRLs ne sont pas mises à jour assez régulièrement

45 Live as if you were to die tomorrow. Learn as if you were to live forever. Mahatma Gandhi CHAPITRE III Les UTMs NETASQ Résumé : NETASQ développe aujourd hui une gamme complète de solutions firewalls, VPNs et AntiSpam pour des entreprises de toute taille. on présentera ici une description avancée des fonctionalités des firewalls NETASQ. - Une présentation complète de l ancienne et de la nouvelle gamme des UTMs. - L ASQ TM : Active Security Qualification, technologie propriétaire de prevention d intrusion analysant le traffic sur l ensemble des couches réseaux. L ASQ équipe l ensemble de la gamme des solutions. - L administration des firewalls : la suite logicielle graphique dont le Manager et le Monitor permettant de suivre l ensemble de l activité réseau et de prendre les mesures nécessaires en cas de problèmes. - Les fonctionalités avancées des firewalls, comme la HA, le portail d authentification ou encore le mode hybrid 1 des interfaces réseaux ; afin de sécuriser des architectures réseaux complexes et éclatées sur plusieurs sites géographiques. L interaction entre les différents modules, en particulier avec le module IPSec facilite la prise en main, et ainsi l intégration du Mode Config.

46 III.1. PRÉSENTATION DES UTMS III.1 Présentation des UTMs III.1.1 Qu est ce que l UTM? Les solutions de sécurité NETASQ sont toutes basées sur le concept d UTM - Unified Threat Managment. On ne parle alors plus tellement de firewall, ou d IPS (Intrusion Prevention System) ou encore d IDS (Intrusion Detection System). Les UTMs intègrent, en standard, l ensemble des fonctionalités de sécurité essentielles répondant aux besoins de des différentes entreprises. L avantage sur des architectures de sécurité basées sur des produits multiples est triple : Le prix des infrastructures : Lorsque l on s oriente vers de multiples produits, l addition augmente assez rapidement, non seulement en termes de produits en eux mêmes, mais également en termes de maintenance et demises à jour. Ainsi, une solution UTM sera moins chère qu un ensemble de solutions de Firewall, d Antivirus, d Antispyware, de Detection d Intrusion, d Antispam, etc. L administration et la maintenance : Il est toujours plus simple et efficace d administrer une seule solution UTM plutôt que de gérer un ensemble de produits. Cela évite d avoir recours à des méthodes d installation et de déploiement multiples, des supervisions multiples et une plus grande difficulté à sécuriser l ensemble de l infrastructure réseau. Il en résulte parfois des possibilités de trous de sécurité multiples. L attente du marché : Ainsi, lorsqu une entreprise sécurise son informatique interne, elle s attend à ce que les produits soient unifiés, que les formations soient courtes, l installation rapide et surtout un verrouillage de la sécurité qui soit central. Ainsi, les UTMs NETASQ embarquent dans toute leur gamme l ensemble des modules disponibles : IPS en temps réel : Il s agit de l ASQ TM présenté à la section III.2.2. Firewall : Non seulement firewall réseau, mais également applicatif. PKI : Il est possible de créer une CA et des Certificats pour l ensemble des utilisateurs, le tout embarqué sur l UTM. Proxy et filtrage de contenu : Permettant une meilleure gestion des sites visités, en particulier en verrouillant des navigateurs, comme Firefox uniquement. VPN SSL et IPSec : Technologies de VPN très répandue, SSL et surtout IPSec interconnectent des sites géographiquement éloignés et permettent également aux clients nomales (des commerciaux terrains par exemple) d accéder au réseau interne de l entreprise

47 CHAPITRE III. LES UTMS NETASQ III.1.2 La première génération des UTMs NETASQ : Les séries F Afin de répondre aux attentes des petites entreprises, des UTMs d entrée de gammes comme le F25, F50 ou le F60 (cf. III.1). Ces modèles intègrent un haut niveau de sécurité et peuvent rapidement être déployé sur les petites infrastructures sans en modifier l architecture. F25 5 ports Ethernet 10/ sessions simultanées. F50 3 ports Ethernet 10/ sessions simultanées. F60 7 ports Ethernet 10/ sessions simultanées. Fig. III.1 Gamme pour PME : F25, F50, F60 Ces modèles n ont pas de disque dur intégré, uniquement une mémoire flash. Les logs sont alors transférés sur un serveur externe, de même pour le serveur LDAP qui doit être externe. La gamme supérieure est la plus commercialisée et la plus répandue chez NETASQ. Elle correspond aux moyennes entreprises, du F200 jusqu au 1200 (cf. III.2). Les tests, le développement, l intégration et l ensemble du stage a été réalisée sur un modèle F200, modèle NETASQ par excellence. Cette gamme intègre des disques durs avec l ensemble des fonctionalités disponibles : PKI, LDAP interne, présence des logs, partition de sauvegarde et restauration, etc. Pour les très grandes entreprises, deux produits NETASQ (cf. III.3) apportent des performances Multi-Gigabits et un grand nombre d interfaces, faisant alors une protection parfaite pour des zones démilitarisées assez sensibles. Une sécurité optimale pour protéger entre autres les sièges

48 III.1. PRÉSENTATION DES UTMS F200 4 ports Ethernet 10/ sessions simultanées. F500 4 ports Ethernet 10/100 et 2 ports Gigabits sessions simultanées. F ports Ethernet 10/100/ sessions simultanées. F ports Ethernet 10/100/ sessions simultanées. Fig. III.2 Moyenne et Grosse gamme : F200 au F

49 CHAPITRE III. LES UTMS NETASQ sociaux. F ports Ethernet 10/ sessions simultanées. F ports Ethernet 10/100/1000 Disques durs Hot Swap en RAID sessions simultanées. Fig. III.3 Haute Gamme pour grands comptes : F2500 et F5500 Ces modèles arrivent aujourd hui en fin de vie (cf. III.4) et ont récemment été remplacés par une nouvelle génération de très hautes performances, et à la pointe de la technologie comme par exemple la précense de port en fibre optique. III.1.3 La nouvelle génération G2 : Les séries U L ancienne génération des UTMs était plus référencé comme des firewalls d où le F. Afin de rompre avec cette idée en mettant sur le marché une toute nouvelle génération d UTMs, d où le U, avec des performances inégalées jusqu à aujourd hui. De l U70 à l U6000 (cf. III.5), de très hautes performances (Interface Gigabits sur l ensemble de la gamme entre autres), une nouvelle version du firmware NETASQ (version 8.0, Codename DELOS) devant être présentée aux Assises de la Securite et des Systèmes d Informations qui se tiendra à Monaco en octobre, cette nouvelle génération est largement en avance sur son temps

50 III.1. PRÉSENTATION DES UTMS Fig. III.4 Anciens UTMs G1 Fig. III.5 Nouveaux UTMs G

51 CHAPITRE III. LES UTMS NETASQ III.2.1 III.2 L ASQ - Active Security Qualification Présentation Le firewall classique bloquant les protocoles interdits par l administrateur et filtrant le trafic commence à être dépassé. Il s agit aujourd hui de pouvoir détecter et surtout de prévenir en temps réel les comportements anormaux au sein même du trafic autorise. A titre d exemple, la majorité des attaques se basent aujourd hui sur des protocoles applicatifs comme HTTP ou FTP. L ASQ - Active Security Qualification est une technologie de prévention d intrusion en temps réel développée par l équipe R&D dès 1998 et intégrée dans les appliances. Il fournit une prévention d intrusion basée sur le contexte en interceptant les paquets au niveau de la couche 2 OSI, en analysant le traffic de la couche 3 OSI jusqu à la couche 7 OSI applicative et en appliquant de multiples méthodes pour identifier et bloquer tout trafic malveillant. L ASQ utilise des familles d attaques lui garantissant une précision optimale afin de protéger le réseau contre les menaces tout en conservant des hautes performances et des gros débits. Les firewalls réalisent ainsi un traitement préventif en temps réel, tant au niveau de la couche réseau qu applicative, sans diminuer les performances du système. III.2.2 ASQ : Pile OSI Virtuelle Lorsque l ASQ reçoit un paquet à analyser, il n effectue aucune décapsulation à proprement parler, on ne remonte pas la pile IP. Il effectue toutes ses analyses de sécurité au niveau noyau sur un paquet mis en tampon (cf. III.6). Cele permet notamment d accroître considérablement les performances et les débits. Ainsi, lorsque l ensemble des analyses de sécurité sont réalisées, le paquet est transmis à l interface sortante. Le contexte du paquet est gardé en mémoire pour le traitement du paquet suivant. Le paquet suivant sera alors analysé suivant le contexte sauvegardé. De fait, toute donnée malformée ou malicieuse sera détruite. III.2.3 Analyses de l ASQ Beaucoup plus loin que les simples classement dépassés analyse niveau réseau et analyse niveau applicatif, l ASQ protège les flux suivant trois grandes catégories d analyse. L ASQ est lié au filtrage et à ce titre effectue toute une série d analyses (cf. III.7) de la couche 3 jusqu à la couche 7 avant de délivrer le paquet à l application en attente ou de l envoyer sur le réseau

52 III.2. L ASQ - ACTIVE SECURITY QUALIFICATION Fig. III.6 ASQ : Pile OSI virtuelle en 7 couches Fig. III.7 Différentes étapes d analyses de l ASQ

53 CHAPITRE III. LES UTMS NETASQ L analyse Protocolaire Il s agit, comme son nom l indique, d une analyse des paquets par protocole. Les flux sont analysés suivant leur protocole et tout trafic malformé, non conforme au protocole associé (réseau ou applicatif) est supprimé. L analyse protocolaire vérifie ainsi la conformité par rapport aux différentes RFCs (Ethernet, IP, TCP, UDP) des protocoles réseaux et transports. D autre part, une vérification est faite par rapport aux RFCs des protocoles applicatifs comme HTTP, SMTP ou encore FTP grâve aux plugins applicatifs développés dans la section suivante. Ainsi, sont notamment évitées l ensemble des attaques basées sur des options des protocoles mal positionnés. Afin de prévenir l administrateur, le firewall peut lever une alarme, et il en existe aujourd hui près de 120 classes réparties sur près de 11 catégories. L analyse des fragments La seconde type d analyse effectuée par l ASQ évite les attaques basées sur l exploitation du sequencement des fragments. Les vérifications ne sont plus effectuées sur le paquet isolé en lui même mais sur le datagramme dans son environnement : la cohérence entre les données des différents paquets qui précèdent et/ou qui suivent est validée. On confirme alors qu aucun fragment ne se chevauche avec un autre, que le paquet initial est bien reconstitué, qu il n y a pas de débordement de taille, etc. Les fragments sont mémorisés dans un buffer et le paquet est renvoyé uniquement s il est reconstitué sans erreur. L analyse Globale L analyse Globale s intéresse au contexte des connexions. Pour chaque connexion acceptée, ses différents éléments caractéristiques comme les adresses IPs de source et de destination, le contexte TCP, etc sont mémorisés. Il s agit de la technologie Stafeull Inspection permettant d analyser les flux suivant leur contexte de connexion. D autre part, dans l ASQ, la sauvegarde des états de connexion est persistante au reboot, et les connexions semi-ouvertes sont également reprises. Les numéro de séquence TCP sont modifiés avec un aléat fort et le SACK (Selective Acknowledgment Option) 2 est activé. La persistance des connexions au reboot permet notamment d éviter l ensemble des attaques DoS qui redémarrent le firewall après un débordement de pile réseau, et qui espèrent pouvoir voler des sessions TCP à l aide des numéros de séquence des rétablissements de toutes les connexions coupées. 2 Le SACK permet de renvoyer un paquet particuler sans renvoyé tous les paquets suivant le dernier ACK reçu

54 III.2. L ASQ - ACTIVE SECURITY QUALIFICATION ASQ Dynamic Filtering Le filtrage NETASQ est de type Statefull Inspection. Le Statefull, contrairement au Stateless, sauvegarde l ensemble du contexte des différentes connexions établies et autorise automatiquement le flux entrant en relation avec un contexte d une connexion déjà établie. L intérêt est alors de vérifier le trafic au niveau contexte de connexione et non plus au niveau paquet uniquement. Le contenu des paquets est également analysé à la volée sans décapsulation et sans interruption de liaison, ce qui assure de meilleures performances. NETASQ a également développé un optimiseur d évaluation de règles de filtrage : SKIP. SKIP permet de regrouper un ensemble de règles ayant un ou plusieurs critères en commun. Ainsi lors de l application de règles de filtrage sur un flux, l ensemble des règles ayant un critère éliminatoire en commun sont sautées et ne sont pas évaluées puisqu elles retourneront forcément une réponse négative (cf. III.8). Les performances en sont alors meilleures. Num Action Protocole Iface Sce Destination Port... 4 Pass TCP IN LAN3 Srv-ftp 21 5 Block ICMP OUT Any LAN2 6 Pass TCP OUT Any Srv-web 80 7 Block TCP OUT LAN1 Srv-smtp 25 8 Pass UDP IN LAN2 Srv-dns Fig. III.8 Haute Gamme pour grands comptes : F2500 et F5500 On peut voir dans le tableau des règles de filtrage qu un paquet qui provient du réseau interne à destination de l Internet sautera les règles 5, 6 et 7. L analyse Applicative L analyse applicative est basée sur une architecture à plugin, permettant de l activer ou de la désactiver. Un plugin va s attacher à un certain type de protocole et de services afin de vérifier la conformité des protocoles applicatifs par rapport aux normes et différentes RFCs, et d en prévenir les utilisations frauduleuses connues. En outre est effectuée une vérification de cohérence entre les données transportées par le paquet et les en-têtes de celui-ci. Cela permet d identifier des attaques propres à chaque type de protocole applicatif. On peut remarquer que ce système d analyse pourra bloquer les attaques basées sur des signatures qui ont été intentionnellement modifiées afin de tromper les IDS classiques. Tous ces types d analyses font de l ASQ un puissant analyseur temps réel de trafic, et n en affectant pourtant pas les performances globales

55 CHAPITRE III. LES UTMS NETASQ III.3 Fonctionalités Avancées En plus de l ASQ, coeur du firmware NETASQ, les appliances disposent de fonctionalités de plus en plus riches comparées aux pare-feux traditionnels. III.3.1 Authentification et PKI A partir des modèles F200 (gamme G1), les appliances disposent toutes d un disque dur et peuvent alors embarquer des annuaires utilisateurs et une mécanique complète d établissement de PKI. Il est toujours possible d authentifier sur une base externe lorsque les modèles n intègrent pas de disque dur. Plusieurs méthodes d authentification sont alors disponibles : None : les utilisateurs ne s authentifient pas. LDAP : les utilisateurs s authentifient à l aide de leur mot de passe, dont une empreinte est stockée dans un champ approprié de leur fiche LDAP. L authentification peut se faire sur une interface web en HTTPS ou HTTP. SSL : les utilisateurs s authentifient en présentant au firewall un certificat valide. SRP : cette méthode permet de ne transmettre ni le mot de passe, ni l empreinte du mot de passe à travers le réseau. Il s agit d une authentification à base de challenge-response (Diffie-Hellman en particulier). SRP-LDAP : Méthode d authentification développée par NETASQ. Le mot de passe LDAP de l utilisateur est utilisé pour générer une clé jetable SRP et permettre l authentification en SRP. Kerberos : les utilisateurs s authentifient via un serveur Kerberos (AS et TGS). RADIUS : les utilisateurs s authentifient au moyen d un serveur RADIUS externe. Les mécanismes de transmission de l empreinte du mot de passe sont les même que pour l authentification via LDAP. NTLM : les utilisateurs s authentifient via un serveur NTLM, exécuant Windows NT 4.0 ou une version précédente. Parmi ce large éventail de méthodes disponibles, les plus utilisées par les clients sont l authentification par certificats et par LDAP, SRP-LDAP. Méthode SRP SRP - Secure Remote Password Protocol permet d authentifier les utilisateurs sans divulguer leur mot de passe, ni leur empreinte de mot de passe sur le réseau. L idée de l authentification en SRP fut lancée sur USENET en 1996 pour la première fois. Deux clés de sessions sont échangées durant la phase d authentification, à l aide d un Diffie Hellman et de l empreinte du mot de passe. On vérifie que les deux parties connaissent bien le mot de passe sans que celui ci ou son empreinte

56 III.3. FONCTIONALITÉS AVANCÉES n ait transité. Ce protocole d authentification est résistant face aux attaques d écoute de réseau comme aux attaques par injection de trafic dans la séquence d authentification. Il est ainsi robuste, y compris lorsque l entropie du mot de passe en lui même est faible. Kerberos et Radius RADIUS - Remote Authentication Dial-In User Service est un protocole d authentification centralisée fonctionnant en mode client-serveur. On peut l utiliser, dans le cadre d IPSec en Mode Config par exemple, pour authentifier les roads warriors se connectant à la passerelle IPSec. L UTM NETASQ peut alors se comporter comme un client RADIUS et envoyer des demandes d authentification au serveur. L utilisateur sera identifié et authentifié sur le firewall uniquement s il l est sur le RADIUS. Kerberos a une vision différente de l authentification. Plutôt que de laisser les mots de passe ou empreinte de mot de passe circuler sur les réseaux, entre les clients et les machines, il propose un système de tickets permettant de s authentifier sur n importe quel service kerbérisé. Les services ou applications authentifiant le feront sur la base du ticket et non plus du mot de passe de l utilisateur. III.3.2 Traitement des paquets A quel module et dans quel ordre sont exactement confrontés les paquets entrants/sortants depuis les différentes interfaces réseaux? Quels sont les priorités? Pourquoi est ce qu un même paquet peut passer plusieurs fois par l ASQ? Une synoptique interne de traitement des paquets est présentée sur la figure III.9). Un paquet entrant est, avant tout, confronté à la politique NAT du firewall avant d être transmis à l ASQ. Celui ci effectue toutes les analyses qu il peut faire et passe la main au module IPSec qui se charge de décapsuler les données. Ces données sont alors confontrées à l ASQ (à la premiere vérification, l ASQ peut juste vérifier la validité du paquet en lui même et non pas des données qu il contient puisque celles ci sont chiffrées), validées puis transmises sur l interface ou aux applications en attente. En sortie, il s agit du chemin inverse : les paquets sortant sont confrontés aux analyses ASQ, aux règles de SPD afin de vérifier s il correspond à un tunnel IPSec ou pas, puis au NAT. La table des translations est donc consultée pour chaque session. Concernant le routage des paquets, il existe quatre types de routage : Route Statique : Il s agit des routes prioritaires sur toutes les autres

57 CHAPITRE III. LES UTMS NETASQ Fig. III.9 Synoptique des UTMs NETASQ Routage par interface : Permet de faire du load balancing par exemple, lorsque l on doit router le trafic internet en fonction de la navigation et/ou des téléchargements. Table Load Balancing : Permet de gérer et maintenir les règles de routes par interfaces. Routes par défaut : Routes consultées en dernier, lorsque toutes les autres n ont pas matchées. III.3.3 High Availability La H.A - Hight Availability ou Haute Disponibilité permet de prévenir la défaillance matérielle sur les boitiers. La HA fonctionne en mode actif-passif : deux firewalls sont reliés par une liaison spécifique avec les mêmes configurations, et un seul est actif à un instant donné. Ils communiquemnt régulièrement afin de vérifier que tout se passe bien et lorsqu une défaillance survient, le firewall passif reprend la main automatiquement. Cela permet d assurer la continuité du service même en cas de dysfonctionnement de l un des deux firewalls. La liaison de communication entre les deux firewalls fut une liaison série autrefois. Ne pouvant garantir des débits suffisants, il s agit aujourd hui d une liaions Ethernet

58 III.4. MANAGMENT ET MONITORING Fig. III.10 High Availability III.4 Managment et Monitoring Les UTMs NETASQ sont fournis avec une suite d administration graphique (cf. III.11) développée par l équipe IHM. Cette suite est composée de trois logiciels graphiques permettant une configuration fine et poussée des UTMs : Manager : Constitue le logiciel d administration principal. La communication entre le logiciel et le firewall se fait sur le port TCP 1300 et est chiffrée en AES 128 bits. Monitor : Est un logiciel permettant de monitorer, de surveiller l ensemble du trafic en temps réel. Ce logiciel répertorie l ensemble des logs et calcule un ensemble de statistiques configurables par l administrateur. Reporter : Permet de collecter les logs des différents modules des UTMs. En sortie d usine, les UTMs ont tous l adresse La première connexion à l appliance (cf III.12) s effectue obligatoirement par l intermédiaire du M anager et sur une interface dite protégée, c est à dire une interface qui acceptera des connexions provenant uniquement du sous réseau auquel elle appartient. Par défaut, le filtrage est le plus restrictif possible : le firewall rejette la totalité des flux qu il reçoit, excepté le trafic sur le port TCP

59 CHAPITRE III. LES UTMS NETASQ Fig. III.11 Suite d administration des IPS-Firewalls NETASQ Fig. III.12 NETASQ Firewall Manager

60 III.4. MANAGMENT ET MONITORING D autre part, le gestion des différents logs et traces d activités sur les réseaux se fait par l intermédiaire du Monitor et du Reporter. Le M onitor loggue l ensemble du trafic, comme les indicateurs systèmes et de sécurité (Débits par interface, CPU, RAM, HA, etc) ; peut chiffrer les logs et les envoyer à un serveur syslog distant. On peut ainsi suivre, en temps réel, l ensemble des services et prendre les mesures qui nécessaires en cas de problèmes : Un historique des actions d administrations. Les utilisateurs authentifiés Les événements systèmes L activité des différents modules... Ainsi, l administrateur, en cas de problèmes sur le réseau, peut immédiatement mettre tel ou telle partie du réseau en quarantaine, ou encore supprimer un utilisateur authentifié ou encore se faire notifier par une alarme lors d une tentative d intrusion détectée par l ASQ. La suite graphique a très peu été utilisée durant ces six mois de stages. L ensemble de l administration du firewall s est faite par ssh et Port Série, directement sur les fichiers de configurations manipulés par la suite graphique. Ces fichiers de configurations seront ceux qui sont manipulés lors de l intégration du Mode Config d IPSec

61 An ounce of practice is worth more than tons of preaching. Mahatma Gandhi CHAPITRE IV Intégration du Mode Config Résumé : Ce dernier chapitre, après avoir étudié en détails IPSec et pris en main les UTMs de manière avancée, s intéresse à l intégration proprement dite du module Mode Configuration d IPSec dans les firewalls. Pour cela, de multiples étapes : Il a fallu tout d abord effectuer de très nombreux tests avec racoon et setkey afin de savoir exactement l état du Mode Config dans le projet ipsec-tools. A partir de ce moment là, réaliser un travail de conception qui ferait ressortir la manière dont serait intégré cette extension dans le format du fichier de configuration NETASQ existant déjà. Le choix s est finalement porté sur quatre nouveaux tokens : cfg_src, cfg_dst, cfg_dns, cfg_wins. Implémenter cette extension dans le parseur NETASQ. Tester l ensemble, une fois l implémentation réalisée, et vérifier le bon comportement lors de configurations bancales ou non-valides. Tester ensuite le code afin d en évaluer les performances, notamment à l aide d outils comme Spirent. Enfin, réaliser un audit auprès de l équipe de développement de la suite graphique afin d intégrer ces tokens de la manière la plus ergonomique possible pour le client. Parralèllement, il a fallu réaliser un audit du code du projet ipsec-tools afin de combler les manques et d apporter des améliorations concernant le Mode Config, notamment au niveau du nouveau token clientaddr.

62 IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS IV.1.1 IV.1 Tests et audit sur ipsec-tools Etat d ipsec-tools L un des objectifs à atteindre dans le cahier des charges était de dresser une évaluation de racoon, démon de négociation IKE du projet KAME ipsec-tools, évaluation générale dans un premier temps, puis sur l aspect des différentes extensions, et enfin sur l aspect Mode Config en particulier. L évaluation générale consistait plus en une prise en main de racoon. Il fallait se familiariser avec l ensemble des options disponibles dans racoon, et connaître l impact sur les différentes associations de sécurité établies. L aspect extensions IPSec - Mode Config - XAuth - Hybrid est venu renforcer le côté authentification des correspondants lors de l établissement d un tunnel IPSec. Il fallait, en effet, dans un soucis de compatibilité future, étudier les trois extensions, même si seule Mode Config était initiallement destinée à être intégrée dans le firmware NETASQ, dans le cadre du cahier des charges du stage en tout cas. Enfin, une évaluation assez poussée de tout l aspect Mode Config. Une implémentation du Mode Config existait déjà dans le projet ispec-tools. Toutefois, peu de personnes l avait utilisé ou testé. L objectif était donc double : évaluer le Mode Config en effectuant une batterie de tests poussés, vérifier le comportement correct de racoon en cas de mauvaises configurations, et le cas échéant corriger le code et/ou apporter des modifications afin d en accrôitre les performances. L ensemble des tests effectués en Mode Config ont été concluants, il s avère que l implémentation du Mode Config existante était stable et opérationnelle dans un cadre de déploiement massif. Ainsi a-t-on mis l accent sur le fichier de configuration NETASQ afin de l intégrer aussi vite que possible. IV.1.2 Configurations Racoon basique Un fichier de configuration basique de racoon se présente de la manière suivante : remote { exchange_mode main; doi ipsec_doi; situation identity_only; my_identifier asn1dn; certificate_type x509 "my.cert.pem" "my.key.pem"; initial_contact on; proposal_check strict; # obey, strict, or claim

63 CHAPITRE IV. INTÉGRATION DU MODE CONFIG } proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method rsasig; dh_group 2; } sainfo address any address any { pfs_group 2; lifetime time 30 sec; encryption_algorithm des; authentication_algorithm hmac_md5; compression_algorithm deflate; } ISAKMP SA La section remote IP ou remote anonymous nous renseigne sur l adresse de l hôte distant. Il peut s agir d une configuration anonyme également, lorsque l adresse IP du correspondant est dynamique, typiquement dans le cas des road warriors. L ensemble des champs présents dans la section remote permettent de négocier la ISAKMP SA, IKE-Phase 1. Ils définissent, entre autres, la durée de vie de la phase 1, les algorithmes de chiffrement et d authentification utilisés et surtout la flexibilité de négociation à travers le champ proposal check. Ce champ est par défaut à strict. Très nombreuses sont les configurations racoon où l on remarque ce champ positionné à obey. Il serait judicieux de n utiliser le mode obey que pour réaliser des tests et passer à une plus grande robustesse ensuite en utilisant les mode strict, exact, claim. Dans le mode strict, racoon accepte une négociation de Phase 1 uniquement si les propositions de chiffrement, d authentification et de durées de vies sont au moins équivalentes à celles présentes dans la configuration. Si elles sont d un niveau de sécurité moindre ou de durées de vies plus faibles, la négociation échoue. exact n accepte que des propositions rigoureusement exactes, claim essaie de négocier une proposition équivalente au moins en terme de durées de vies. D autre part, le champ exchange_mode définit le mode de négociation principal (Identity Protection Mode) ou aggressif. La plupart du temps, lorsque les IPs des deux correspondants sont connues à l avance, le mode utilisé est main, comme nous l avons décrit précédemment

64 IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS IPSEC SA La section sainfo suivante permet de définir les paramètres de négociations de la IPSEC-SA, IKE-Phase 2. Il s agit des paramètres qui vont être utilisés pour chiffrer et/ou authentifier le trafic utile. Cette section se présente de la manière suivante : sainfo src_ntwork/mask proto dst_ntwork/mask proto {...} On définit ainsi les sous-réseaux qui communiqueront de manière chiffrée à travers le tunnel. En outre, les IPSec SAs sont renouvellées à 80% de leur durée de vie. Ainsi, il existe, dans le noyau, un flag correspondant à la mâturité des SAs : Larval : La SA est référencée dans le noyau, en cours de négociation et non-utilisable à cet instant donné. Mature : La SA peut être utilisée ou est en cours d utilisation actuellement. Dying : La SA a atteint ou est proche de 80% de sa durée de vie. Elle peut continuer à être utilisée, mais il faudra la renouveller sous peu. Dead : La SA n est plus valide, mais toujours référencée dans le noyau. Elle ne peut plus être utilisée. Cette configuration est classique : les adresses IPs des correspondants sont connues, en mode main avec une authentification en Certificats X509. C est la configuration la plus largement déployée aujourd hui pour relier des sites distants. IV.1.3 Injection de politiques de sécurité par setkey setkey est un utilitaire userland développé au sein du projet ipsec-tools permettant de manipuler et afficher la Security Policy Database - SPD et la Security Association Database - SAD. setkey est appelé lors que l on souhaite injecter des politiques de sécurité dans la SPD : flush; spdflush; spdadd / /8 any -P in none; spdadd / /8 any -P out none; #Police sortante spdadd /24 any /32 any -P out ipsec esp/tunnel/ /require ; #Police Entrante spdadd /32 any /24 any -P in ipsec esp/tunnel/ /require ;

65 CHAPITRE IV. INTÉGRATION DU MODE CONFIG Aucun trafic entrant ou sortant n est chiffré sur la boucle locale. Une politique de sécurité pour le trafic sortant est ajouté : l ensemble du trafic provenant du réseau /24 à destination de est du trafic IPSec, et sera chiffré suivant la SA correspondante entre les extrémités de tunnels que sont et Une autre politique de sécurité pour le trafic entrant, qui représente le chemin inverse emprunté par les paquets : il s agit du trafic provenant de à destination de /24, passant à travers le même tunnel IPSec. On peut voir la table des politiques par setkey -DP : /8[any] /8[any] any in none spid=37 seq=3 pid=61636 refcnt= [any] /24[any] any in ipsec esp/tunnel/ /require spid=40 seq=2 pid=61636 refcnt= /8[any] /8[any] any out none spid=38 seq=1 pid=61636 refcnt= /24[any] [any] any out ipsec esp/tunnel/ /require spid=39 seq=0 pid=61636 refcnt=1 Les extrémités de tunnels correspondent aux extrémités ( ) entre lequel le trafic sera effectivement sécurisé (chiffré, authentifié) et les extrémités de trafic, les extrémités communiquantes à travers ce tunnel ( / ). Un paquet en provenance, par exemple, de ne pourra pas emprunter le tunnel puisqu il ne fait pas partie des extrémités de trafic. Une fois la phase de testsipsec-tools basique et une prise en main avancée deracoon réalisées, il a fallu passer à l étape de vérification des implémentations des extensions XAuth et Mode Config en particulier. IV.1.4 Configuration en XAuth Comme nous l avons présenté au chapitre consacré aux extensions IPSec décrites dans différents drafts, XAuth utilise des paquets de type Transaction Exchange, paquet ISAKMP particuliers. Les tests surxauth ont été réalisée, avec en mode serveurracoon et en mode client TheGreenBow TM. TheGreenBow est un client VPN développé par TheGreenBow Enterprise Security Solutions et

66 IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS fournit par NETASQ, pour les plateformes Microsoft Windows. En Mode XAuth ou en Mode Config, un ensemble de clients mobiles dont l adresse IP n est pas connue à l avance se connectent sur la passerelle, et doivent s authentifier. En plus de l authentification normale réalisée par racoon, XAuth réalise une authentification complémentaire de l utilisateur à proprement parler. On peut rappeller que, bien que l authentification de l utilisateur se fasse au niveau de XAuth, les échanges sont protégés par la ISAKMP SA établie au préalable. Une ISAKMP SA faible ne protège pas d une éventuelle attaque ou intrusion, même si l authentification de l utilisateur par XAuth est faite sur la base de méthodes robustes. La configuration deracoon en mode anonyme en plus du Mode Config est quelque peu différente du cas classique. remote anonymous # On ne connait pas l adresse du road warrior!! {... generate policy on; # On ne connait pas les politiques de securite a l avance mode_cfg on; # On active les echanges Mode Config... } mode_cfg { auth_source system ; # pam, radius... auth_throttle 15 ; # Refuse la connexion de ce user pdt 15s en cas d échec d auth... } sainfo ip_passerelle any anonymous {... } Les différents champs rajoutés permettent une configuration dynamique à la volée des SAD et SPD : anonymous : la section remote devient anonyme puisque l on ignore les adresses IPs des clients mobiles. Il faut donc que la section match toutes les adresses. generate policy : génère et injecte dynamiquement les politiques de sécurité via PF_KEY et la librairie IPSec. Puisque l on ignore les IPs des mobiles, on ne peut établir des politiques de sécurité par avance. Elles doivent l être à la volée au moment de la connexion des road warriors. mode cfg on : permet d activer les échanges Mode Configuration (paquets de type Transaction Exchange) permettant de réaliser une authentification en XAuth. La section mode_cfg vient s ajouter aux différentes sections remote et sainfo déjà présentes. Elle présente les paramètres des paquets Mode Config échangés. Il se trouve que dans le cas présent,

67 CHAPITRE IV. INTÉGRATION DU MODE CONFIG nous utiliserons la section Mode Config uniquement pour authentifier l utilisateur en XAuth. On signale donc à la passerelle que l authentification se fera sur les comptes système, et qu en cas d échec d authentification d un login particulier, celui ci ne pourra refaire une tentative avant quinze secondes. Après XAuth, il a fallu valider le Mode Configuration proprement dit, tel que décrit dans le draft draft-dukes-ike-mode-cgf-02. IV.1.5 Mode Config : racoon vs racoon Principe Lorsqu un client mobile se présente à la passerelle IPSec pour y établir une connexion, deux choix s offrent à lui : Test Il a embarqué sur sa machine, au préalable, toute la configuration réseau nécessaire à l établissement de sa connexion IPSec. Il ne lui reste plus qu à s authentifier auprès de la passerelle pour que celle ci puisse lui établir son tunnel IPSec. Les informations embarquées sont, au minimum, l extrémité distante de tunnel, les extrémités distantes de trafic, les adresses d éventuels serveurs de noms, et les clés d authentification. Toutefois, maintenir plusieurs dizaines voire centaines de machines mobiles peut très vite devenir un casse-tête infernal pour l administrateur, qui se voit attribuer un double travail : garder tous ces mobiles à jour en fonction des changements éffectués sur la passerelle IPSec et sur les membres de l entreprise en général (suppression de compte, révocation de certificats, création de compte, etc). L idée serait donc de pouvoir envoyer toute la configuration réseau nécessaire dynamiquement au client mobile, une fois qu il s est correctement authentifié. Le Mode Configuration peut servir, comme décrit au chapitre sur les extensions, à envoyer ces informations à la volée. racoon est utilisé des deux cotés client et serveur dans un premier temps. Seules les sections Mode Config sont modifiées, la section remote restant toujours anonyme du côté du serveur, et ayant l adresse de la passerelle du côté du client.... mode_cfg { network ; netmask ; split_network include /16 ; dns ; } On spécifie dans la section Mode Config l ensemble des paramètres à transmettre au client mobile lors de sa connexion :

68 IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS network4 : Il s agit du réseau RFC1918 dans le lequelracoon va piocher une adresse IP locale à transmettre à l interface IPSec du client mobile, pour que celui-ci puisse prétendre être sur le LAN de l entreprise. Les adresses sont attribuées dans l ordre croissant aux différents clients, sont recyclées, et en cas de pénurie, les négociations échouent. Dans notre cas, le réseau est /24, 254 clients mobiles peuvent se connecter au maximum. split network : Il s agit de l extrémité de trafic locale à transmettre au client mobile. Il pourra ainsi établir des politiques de sécurité afin de communiquer en IPSec. Suivant ce champ, generate_policy injecte les règles sur la passerelle. dns4 : Adresse du serveur de nom à transmettre. Du côté du client, en revanche, aucune section mode_cfg n est nécessaire. La récupération des informations de connexion se fait via deux scripts prédéfinis dans racoon : remote ip_passerelle {... script " /etc/racoon/phase1-up.sh" phase1_up; script " /etc/racoon/phase1-down.sh" phase1_down;... } Ces scripts sont disponibles dans le repertoire samples de toute installation de racoon. Ils se chargent, entre autres, de récupérer l adresse RFC1918 envoyée par le serveur, de l attribuer à l interface IPSec et d injecter les politiques de sécurité reçues dans la SPD du client et de rajouter les entrées dans les serveurs de noms déjà disponibles. IV.1.6 Mode Config : racoon vs quelques clients VPN racoon en mode client n étant pas vraiment réaliste, au vue des configurations des clients de NETASQ, sur des machines portables souvent sur des plateformes Windows, et cherchant le moins de configuration possible, on s est orienté vers des clients VPN déjà disponibles : le client fourni par Cisco Systems, le client VPN TheGreenBow et ShrewSoft, un client VPN sous licence GPL développé par un membre de la core team du projet ipsec-tools, Matthiew Grooms. Cisco VPN Client La configuration racoon est restée la même du côté du serveur durant ces tests. Le client VPN Cisco a été testé sur une plateforme Windows 2000 SP4. Les tests en XAuth ont été concluants, bien que la gestion des certificats soit lourde et peu ergonomique. Les tests en Mode Config n ont pas été totalement concluant : Une session Mode Config seule n aboutit pas, tandis qu une session Mode Config suivie d un XAuth valide récupère correctement certains paramètres, comme l adresse IP RFC

69 CHAPITRE IV. INTÉGRATION DU MODE CONFIG Toutefois, il s avère que ce client VPN a été très décevant au niveau de l ensemble des propositions de Phase 1 qu il envoie à la passerelle. En ayant écouté le trafic réseau au moment de la négociation, le client Cisco envoye toute une panoplie de propositions en espérant que l une d elle sera retenue. Les passerelles IPSec pour les clients mobiles sont, en effet, le plus souvent configurées en mode passif et se contentent de répondre aux propositions des clients. L inconvénient majeur du client Cisco est de ne pas tenir compte des réponses de la passerelle configurée sous racoon, et d envoyer encore plus de protocoles de chiffrement, de tailles de clés, de protocoles d authentification, de durées de vies différentes, etc. ce qui a tendance à saturer le réseau assez rapidement, même si la connexion aboutit in fine. TheGreenBow TM Les tests effectués sur les maquettes TheGreenBow ont été concluant sur XAuth, mais malheureusement très decevant sur le Mode Config. Bien qu une fenêtre entière soit dédiée au Mode Config, lors des écoutes réseaux, il s est avéré que le support n est pas intégré dans TheGreenBow puisqu aucune demande (paquet ISAKMP- REQUEST, ISAKMP-SET) ni réponse (paquet ISAKMP-REPLY, ISAKMP-ACK) n est envoyée ou reçue par le client VPN. Le service R&D a donc été contacté afin de connaître les fonctionalités exactes quant au Mode Config. Lors de la sortie de la version suivante, le Changelog annonçait une nouvelle fois le Mode- Config, et les tests ont donc été refaits plusieurs mois après. Ils ont néanmoins échoués également. Les requêtes ne sont toujours pas transmises, aucun paquet annonçant le support du Mode-Config n est détécté lors de la négociation de Phase 1. The- GreenBow ne supporterait vraisemblablement pas correctement l extension Mode Config dans son ensemble. ShrewSoft ShrewSoft est un client VPN/IPSec développé récemment, sous licence GPL, dont la dernière version date du 19 juin Le Mode Config a également été testé avec Shrew et l ensemble des tests effectués ont été tout à fait satisfaisants, avec une passerelle où tourne racoon. L ensemble des champs disponibles dans le Mode Config de racoon sont correctement transmis à Shrew qui configure correctement les politiques de sécurité et met en place le tunnel. Qu il s agisse du Mode Config seul, ou du Mode Config suivi de XAuth, la configuration est correctement transmises et l ensemble des paramètres correctement pris en compte

70 IV.1. TESTS ET AUDIT SUR IPSEC-TOOLS Fig. IV.1 ScreenShot ShrewSoft On veillera toutefois à désactiver la fragmentation des paquets, fonctionalité encore en cours de développement. IV.1.7 Bilan des tests Prendre en main IPSec, à différents niveaux (noyau, interfaçage PF KEY permettant la communication entre le noyau et l espace utilisateur, et les démons en espace utilisateur), m a fallu plusieurs semaines. Il a fallu établir l état dans lequel était les implémentations des extensions dans le projet ipsec-tools. L ensemble de ces tests, à commencer par le plus plausible, celui d un racoon en mode serveur et client, m ont permis de valider les implémentations. XAuth et Mode Config sont implémentés et opérationnels dans ipsec-tools. Les tests ont été fait sur des machines sous FreeBSD 7.0, et beaucoup de configurations non-valides ont été testées afin de bien valider la bonne remontée d erreur. On peut citer le cas d une demande de Mode Config alors qu un XAuth est en cours ou n a pas abouti. La passerelle doit refuser toute tentative de Mode Config ou de négociation de Phase 2 tant que l utilisateur n est pas correctement authentifié. A alors débuté un travail conception afin de pouvoir intégrer ce Mode Config dans le firmware NETASQ

71 CHAPITRE IV. INTÉGRATION DU MODE CONFIG IV.2.1 IV.2 Extension du format du fichier de configuration IPSec Fichiers de configuration NETASQ et parseurs Fichiers de configuration Le module IPSec du firmware NETASQ est basé sur la pile IPSec FastIPSec et sur le projet ipsec-tools. Toutefois, l ensemble des modules du firmware NETASQ n utilise pas directement les fichiers de configuration des différents projets BSD. NETASQ a, en effet, fait le choix d avoir ses propres fichiers de configuration dans un soucis d indépendance vis à vis, notamment, du système FreeBSD et des projets BSD sous jacents. Comment les fichiers NETASQ interagissent-ils avec ceux des modules du système? NETASQ définit dans un premier temps un format de fichier de configuration, en décrivant l ensemble des champs nécessaires, l ensemble des valeurs disponibles, les valeurs par défaut, etc. Dans un second temps, ce fichier de configuration est parse à l aide de multiples librairies de parsing développée par NETASQ. En sortie, on obtient alors un fichier de configuration au format du projet sous jacent qui est utilisé pour éxécuter le module. L avantage qu offre ce choix est de pouvoir garder la même signature des fichiers de configuration vis à vis du client final. Il arrive que NETASQ doive changer tel projet par tel autre, parce que des améliorations ont été apportées, ou parce que le projet actuel n est plus maintenu, etc. Dans ce cas, NETASQ ne peut se permettre de changer de module et de laisser le client final se débrouiller dans un nouvel environnement qu il ne maîtrise pas forcément. Ainsi, lorsque cela arrive, le fichier de configuration NETASQ reste le même, seules sont modifiées les librairies de parsing en arrière plan afin d en sortir le fichier de configuration au format du nouveau module fraîchement intégré. Le client manipule ainsi le même fichier de configuration. Exemple Le module NAT 1 utilisé est, à l heure actuelle, le module FreeBSD ipnat. Le fichier de configuration NETASQ du NAT se présente comme suit : [Config] KeepNAT=0 [NAT] map bridge Network_inJup to any -> pessac port ephemeral_fw rdr bridge merignac to pessac port ssh -> pessac_local port ssh rdr bridge any to pessac port VNC_port -> pessac_local port VNC rdr bridge any to pessac port vnc_java -> pessac_local port vnc_java 1 NAT - Network Adress Translation

72 IV.2. EXTENSION DU FORMAT DU FICHIER DE CONFIGURATION IPSEC Il s agit du fichier de configuration NAT que j ai utilisé sur mon réseau de travail durant les six mois de stage. Bien que la syntaxe du fichier NETASQ ressemble à celle d ipnat, le parseur permet, à partir du fichier de configuration NETASQ, d obtenir le fichier de configuration au format ipnat : map sis /24 -> /32 portmap tcp/udp 20000:59999 map sis /24 -> /32 portmap tcp/udp 20000:59999 map sis /24 -> /32 portmap tcp/udp 20000:59999 map sis /24 -> /32 map sis /24 -> /32 map sis /24 -> /32 rdr sis0 from /32 to /32 port = 22 -> port 22 tcp rdr sis1 from /32 to /32 port = 22 -> port 22 tcp rdr sis3 from /32 to /32 port = 22 -> port 22 tcp rdr sis0 from 0/0 to /32 port = > port 5099 tcp rdr sis1 from 0/0 to /32 port = > port 5099 tcp rdr sis3 from 0/0 to /32 port = > port 5099 tcp rdr sis0 from 0/0 to /32 port = > port 5800 tcp rdr sis1 from 0/0 to /32 port = > port 5800 tcp rdr sis3 from 0/0 to /32 port = > port 5800 tcp Il s agit d une configuration NAT basique permettant de translaté un réseau, en locurrence /24, en une adresse IP, en locurrence ; d une redirection de port ssh, TCP 22, et d une redirection de port VNC, TCP 5800 et TCP Lorsque dans le cahier des charges des versions futures du firmware, il ne sera plus question d utiliser ipnat, si cela arrive, le fichier NETASQ restera le même. Seul changera la librairie de parsing qui génerera, cette fois ci, un fichier au format du nouveau module NAT. Le fichier de configuration IPSec est basé sur le même principe, c est ce fichier que nous nous proposons d étendre en vue de l intégration de l extension Mode Config. IV.2.2 Conception et extension du fichier Conception Après ma prise en main des appliances NETASQ et le succès des nombreux tests réalisés avec racoon, une nouvelle roadmap a été établie. En fonction des demandes des clients, des champs Mode Config disponibles dans racoon, et du délai imparti pour l intégration, il a finalement été décidé d envoyer la configuration réseau suivante aux clients mobiles : Une adresse IP de type RFC 1918 afin que l interface IPSec du client mobile soit configurée de telle manière qu elle croit être sur le réseau interne, d où tout l intérêt. Transmettre son extrémité distante de trafic pour qu il puisse négocier les IPSec SA sans embarquer ces informations de manière statique sur la machine

73 CHAPITRE IV. INTÉGRATION DU MODE CONFIG Transmettre l adresse d un serveur DNS 2. Transmettre l adresse d un serveur WINS 3 Fichier VPN Un fichier de configuration NETASQ IPSec se présente de la manière suivante : [Global] Tunnels=Tunnel_1 [Tunnel_1_1_1] Dh=2 Hash=1/160 Enc=11/256 [Tunnel_1_2_1] Mode=ESP,TUNNEL Auth=3/160 Enc=11/256 Dh=2 Lifetime=3600 Src=any Dst=merignac keepalive=60 [Tunnel_1] Name=tunnel_2 Method=PSK Mode=MAIN Lifetime=3600 CheckMode=Exact ResponderOnly=1 AdvancedMode=1 dpd_mode=passive Src=fw_out Peer=merignac State=1 2 DNS - Domain Name System permet la résolution des noms. 3 WINS - Windows Internet Naming Service permet également la résolution de noms pour les systèmes utilisant NetBIOS

74 IV.2. EXTENSION DU FORMAT DU FICHIER DE CONFIGURATION IPSEC Ce fichier de configuration, lorsqu il sera parse, donne en sortie un fichier de configuration racoon, qu on appellera plus simplement le fichier racoon.conf par la suite. Les différents champs sont volontairement intuitifs, afin de configurer les tunnels IPSec de la manière la plus ergonomique possible : La section [Tunnel_1_1_1] décrit l ensemble des paramètres de proposition de phase 1. Elle comprend notamment le groupe Diffie-Hellman, les algorithmes de chiffrement et d authentification. Cette section donne une partie de la section proposal du racoon.conf. La section [Tunnel_1_2_1] décrit l ensemble des paramètres de Phase 2 et comprend notamment les durées de vie des SAs proposées. Cette section sera parsée en la section sainfo{...} du racoon.conf. Enfin la section [Tunnel_1] permet de configurer l ensemble des paramètres globaux relatifs au tunnel mis en place. Cela comprend notamment le mode de négociation, la flexibilité de négociation et les durées de vie proposées. Les algorithmes de chiffrement et d authentification sont renseignés dans une table maintenue à part : l ajout ou la suppression d un algorithme se fait ainsi à un seul endroit. Cette façon de procéder permet de se conformer à des contraintes législatives en fournissant des versions ne comportant que certains algorithmes ou ne rendant possible l utilisation que de certaines longueurs de clef. Ceci est particulièrement utile lorsqu il s agit d exporter les appliances NETASQ vers des pays où l Europe impose une législation différente en terme d algorithmes de chiffrement. Définition des champs Lors de la conception des différents champs destinés à être intégré, l accent a été mis sur le fait d avoir une architecture peu gourmande en terme de taille de fichier. Il existe déjà un champ dst dans le fichier de configuration NETASQ : ce champ définit l extrémité distante de trafic d un tunnel IPSec. Parralèlement, le champ src définit l extrémité locale de trafic correspondante. D autre part, nous avons fait le choix de n autoriser le Mode Config que dans le cas des road warriors, c est à dire dans le cas où les adresses IP ne sont pas connues à l avance, c est à dire dans le cas de configurations anonymes. On se rend compte que l extrémité de trafic distante (définit par dst) est en fin de compte limitée à une seule adresse, celle que l on souhaite transmettre en Mode Config : les extrémités distantes de tunnel et de trafic sont confondues. Il est ainsi judicieux d utiliser le champdst déjà défini en tant que pool d adresses IP à transmettre aux différents clients, dans le cas d une configuration en Mode Config. Pour récapituler, lorsque l option Mode Config n est pas activée, le champ dst se comporte comme étant l extrémité de trafic distante. Lorsque l option Mode Config est activée, le champ dst se comporte comme pool d adresses IP. Une adresse est prise dans le pool et transmise au client

75 CHAPITRE IV. INTÉGRATION DU MODE CONFIG L activation de l option Mode Config se fait par la définition de quatres champs créés à cette fin : cfg dns : Ce champ définit le serveur DNS à transmettre en Mode Config. Ce champ sera parsé en dns4 dans le racoon.conf. cfg wins : Comme DNS, ce champ définit un serveur WINS à transmettre et sera parsé en wins4. cfg src : Ce champ peut être positionné à 1 pour l activer ou 0, valeur par défaut, permet de transmettre l extrémité locale de trafic au client, stockée dans le champ src. Il correspond à la partie du réseau interne auquel le client est autorisé à accéder. Cette information est aujourd hui embarquée statiquement sur les machines. Dorénavant, elle pourra être transmises à la volée, par Mode Config, suivant l identité du client qui se présente. cfg dst : Positionnable à 1 ou 0, valeur par défaut. Il s agit du pool d adresses IP disponibles définit sous la forme d un réseau et masque correspondant. A titre d exemple, si cfg_dst est positionné à 1 et le champ dst à /24, les road warriors qui se présentent auront une IP du réseau /24 et 254 road warriors pourront négocier au maximum au même moment. Les adresses libérées sont ensuite recyclées par racoon. IV.3.1 IV.3 Intégration et validation Impératifs d implémentation Implémenter les fonctions dans la librairie afin de parser les quatres champs ne suffit pas pour générer des configurations correctes. Il a fallu vérouiller plusieurs champs afin qu il ne puissent interférer avec certaines configurations bancales ou interdites. Le tout premier verrou a été celui de l utilisation du Mode Config uniquement dans le cadre des road warriors. Rien n empêche, en effet, à racoon de transmettre des informations en Mode Config à un hôte distant classique qui soit lui même une passerelle IPSec. Les tentatives d utilisation du Mode Config lorsqu il ne s agit pas d un tunnel anonyme n aboutiront plus. Ensuite s est posé le problème du champdst qui peut très bien être positionné àany, l ensemble du trafic à destination de cet hôte est alors du trafic IPSec. Dans le cas du Mode Config (donc le champ cfg_dst = 1, le champ dst ne peut valoir any, puisque dans ce cas, on ne définit aucun pool d IP dans lequel racoon pourrait piocher. Cette configuration a donc été interdite également : l utilisation du Mode Config pour la transmission d adresses RFC1918 impose la définition du champ dst. Les objectifs du cahier des charges ont été correctement remplis, les impératifs d implémentation réspectés. Une fois réalisée, une maquette a alors été montée et la validation a pu être lancée. IV.3.2 Premiers tests Une fois la maquette en place, l on a pu tester les quatres champs, d abord un par un, puis en essayant les combinaisons des différents champs : [Tunnel_3_2_1] Mode=ESP,TUNNEL

76 IV.3. INTÉGRATION ET VALIDATION Auth=3/160,4/128 Enc=11/128 Dh=2 Lifetime=3600 Src=Netasq_network Dst=rw_test Cfg_dst=1 Cfg_src=1 Cfg_dns=rw_dns Cfg_wins=rw_wins keepalive=0 Les quatres champs Mode Config ont été définis. Au moment de l activation de la configuration, le fichierracoon.conf est généré etracoon est démarré. Si le parsing échoue ou s il n est pas valide, racoon ne démarrera pas. On peut vérifier le parsing correct : mode_cfg { dns ; wins ; split_network include /16; pool_size 254 ; network /24 ; netmask ; } La section Mode Config est tout à fait correctement crée et les différents champs correctement positionnés : Dns4 et Wins4 correspondent aux serveurs de noms à transmettre. Split network include correspond à l extrémité locale de trafic à transmettre, à savoir le champ src du fichier NETASQ. Les trois derniers définissent la manière dont les road warriors se voient attribuer leur adresse IP RFC1918. On dispose ici d un pool d IPs de 254 adresses disponibles sur le réseau /24. L action de l option Mode Config en elle même aurait pu être définie par un champ spécifique. Finalement, la présence d un seul des quatres champs Mode Config suffit à activer l option Mode Config. IV.3.3 Validation et Commit dans le firmware Une fois les premiers tests passés avec succès, la nouvelle librairie de parsing et le nouveau module IPSec ont été testés et validés par l équipe de Qualification au laboratoire R&D NETASQ. NETASQ dispose, pour ses tests de validation et de non régression, entre autres, de deux Spirent. La société Spirent offre des solutions de tests, validation et monitoring de services réseaux. Sont

77 CHAPITRE IV. INTÉGRATION DU MODE CONFIG notamment testés le routage, la QoS, les protocoles Wireless, IPSec, etc. Malheureusement, les systèmes Spirent ne supportent pas le Mode Config et n ont donc pas pu être mis à contribution lors de la validation du code. Les tests ont été réalisés avec ShrewSoft, non plus avec racoon d ipsec-tools en face comme nous l avions fait lors de nos tests préliminaires, mais en face d une appliance NETASQ intégrant le Mode Config dans son module IPSec. L ensemble des tests se sont déroulés avec succès : la récupération des informations en Mode Config est correcte, les configurations interdites sont bien ignorées et les erreurs adéquates sont remontées à l administrateur à chaque fois. L ensemble du code a donc pu être officiellement intégré dans le firmware NETASQ. Lors de la prochaine sortie de version majeure, la version 8.0, dont la sortie officielle est prévue durant le dernier trimestre de cette année, les clients disposeront d une option Mode Config opérationnelle

78 Be the change that you want to see in the world. Mahatma Gandhi Conclusion et Bilan La sortie de la prochaine version majeure est prévue pour le dernier trimestre Les premiers retours sur l utilisation du Mode Configuration d IPSec devraient arriver dans le courant du premier trimestre Pourtant, lors de mon arrivée à NETASQ rien ne prédisait que le Mode Configuration puisse être effectivement intégré dans un délai aussi court, délai comprenant la conception, le développement et surtout la validation à travers une batterie de tests de non-régression et de performances, autant sur la partie ipsec-tools et projet OpenSource que sur la partie firmware NETASQ. Le stage sur IPSec et sur le Mode Configuration en particulier avait pour objectif de débroussailler l implémentation de cette extension dans ipsec-tools avant tout : évaluer l état de l implémentation actuelle du Mode Configuration à travers des tests sur des maquettes montées pour l occasion, évaluer les performances et confirmer ou infirmer la stabilité de racoon confronté à des configurations réseaux complexes et pas forcément valides du point de vue des draft et des RFCs. L ensemble des tests effectués sur le Mode Configuration ont été concluants, que racoon soit en mode serveur ou en mode client : l ensemble des informations sont transmises correctement à la volée, juste après l établissement de la ISAKMP-SA 4. Après avoir validé de nombreuses configurations, j ai pu mettre l accent sur l étude du produit en lui même, l appliance NETASQ et son firmware : les différents modules en général, le processus de ports de FreeBSD, l ASQ, coeur du firmware, le fonctionnement par fichiers de configurations NETASQ et leur librairies de parsing, la communication entre la suite graphique et le firewall, etc. La prise en main de l appliance NETASQ et l étude du firmware ont été facilitées par les certifications NETASQ Certified Administrator - NCA et NETASQ Certified Expert - NCE que j ai eu l honneur de pouvoir passer. 4 Sous reserve que l authentification XAuth soit désactivée, si ce n est pas le cas, les informations sont transmises juste après la validation de l authentification en XAuth.

79 CHAPITRE IV. INTÉGRATION DU MODE CONFIG Cette étape a marqué le début du travail sur le firmware : intégrer le Mode Configuration en tenant compte de toutes les contraintes existantes. Ces contraintes ont été de plusieurs ordres. Prendre en main le code des librairies de parsing déjà existant. Tenir compte du fichier de configuration existant et l étendre dans la mesure de l acceptable : pas d ajout de champs inutiles, pas de configuration supplémentaire non nécessaire pour le client. Comportement par défaut correct si le Mode Configuration n est pas activé. Il s agit de l implémenter comme une option à part entière, pour que par défaut, le module IPSec se comporte comme dans les versions précédentes. Tenir compte des contraintes indirectes, notamment en terme de Suite Graphique NETASQ : la lecture des champs par défaut ne doit pas être perturbée par l apparition des nouveaux champs que la suite graphique ne connait pas. La prise en compte de l ensemble de ces contraintes a été sujette à plusieurs discussions fructueuses, et a finalement mené à la création des quatres champs Mode Configuration implémentés dans le firmware. Une fois le Mode Configuration implémenté, validé et opérationnel, j ai pu me concentrer sur l amélioration de l implémentation du Mode Configuration d ipsec-tools par l étude d un nouveau champ dans racoon : le champ CLIENTADDR. Le CLIENTADDR permet de matcher l identité de l hôte distant suivant qu il s agisse de l adresse IP de l hôte ou de l adresse IP RFC1918 définie dans la configuration Mode Configuration, si celui ci est activé. Le CLIENTADDR peut être utile pour restreindre la génération de politiques de sécurité lors que racoon agit comme une passerelle pour les clients mobiles. Il se trouve que Matthiew Grooms avait déjà réalisé une partie de l implémentation sur la branche principale du projet ipsec-tools. J ai porté le champ de la branche principale vers la version stable d ipsec-tools actuelle, Tout au long des six mois passés à NETASQ, plusieurs idées reçues de l étudiant terminant son cursus ont été bousculées, à juste titre et tant mieux. J ai, avant tout, pu constater qu il ne suffit pas d avoir une conception parfaite une bonne implémentation pour qu elle puisse être intégrée dans un firmware déjà existant et soumis à un certains nombres de contraintes

80 IV.3. INTÉGRATION ET VALIDATION Déjà fasciné par la sécurité à l université, j ai pu porter un regard différent sur ce monde qui parait toujours renfermé et reservé vu de l extérieur. J ai ainsi pu suivre l évolution des failles OpenSSL et DNS du point de vue d une société spécialisée en sécurité informatique où il fallait toujours être sur le qui-vive, suivre les différents PoC 5 où encore étudier les différents articles et impressions sur de grandes conférences en sécurité informatique, qu elles soient francophones comme le SSTIC, ou internationales comme BlackHat ou DefCon. Je citerai ici Ferdinand Foch - Il n y a pas d hommes cultivés, il n y a que des hommes qui se cultivent - tout à fait approprié lorsqu il s agit de sécurité informatique ou de cryptologie. Pendant toute cette période, j ai eu l honneur d être entouré d ingénieurs extrêmement compétents dans leur domaine, me permettant d avoir les meilleurs conseils possibles de la part de la part de personnes toujours disponibles et à l écoute. Je porte aujourd hui un regard tout à fait différent sur un projet OpenSource, sur l utilisation subtile des différentes licences (GPL, BSD, Libre, Open- Source...). J ai également pu améliorer mon niveau en développement de façon conséquente, en étant confronté à des styles de programmation différents tout en respectant la charte de programmation de NETASQ. D autre part, j ai pu remarquer l aide apportée par la communeauté lorsqu il s agit d auditer du code source ou de comprendre une RFC où se chevauchent des subtilités, souvent anglaises, de termes comme M AY, M IGHT ou SHOU LD ne facilitant pas toujours l intégration de telle ou telle fonctionalité. Enfin, le plus important à mes yeux concerne le regard critique que j ai pu adopter face à la formation que j ai reçue à l université. Cette expérience m a non seulement permis d approndir certains points clés, mais également de poser des bases solides pour commencer une carrière qui, je l espère, me permettra d être acteur plutôt que spectateur dans le monde de la sécurité informatique. 5 PoC : Proof Of Concept

81 Annexe A : Protocole AH et ESP approfondis En-tête IP Les protocoles AH et ESP reposant sur sur IP, une description sommaire des champs d IP est donnée dans le tableau??. IP est un des protocoles réseau les plus répandu aujourd hui, dans sa version IPv4 qui commence à s essoufler du manque d adresses disponibles et dans version IPv6 déjà massivement déployé au Japon. Il apporte l adressage en couche 3 permettant de router les paquets. Les champs principaux de l entête IP sont définis de la manière suivante : ver : Il s agit de la version du protocole IP utilisé (4 ou 6), codé sur 4 bits. Placé en tête, il permet de vérifier le format correct du paquet et de le détruire de suite en cas de version inconnue. IHL : Pour Iinternet Header Lengh, IHL, codé sur 4 bits, représente la longueur de l en-tête IP en mots de 32 bits. Sa valeur peut varier de 5 à 15 (donc de = 60octets max) suivant les options IP et est à 5 (20 octets) par défaut. TOS : Pour Type Of Service, sur 8 bits, permet de contrôler la QoS directement au niveau OSI 3. TOS regroupe des données comme la priorité, le délai ou encore le coût. TOS est l unique champ récupéré par ESP pour l encapsulation ESP-Tunnel. pkt-len : Il s agit de la longueur totale du paquet IP, codé sur 16 bits, en-tête et données comprises. Exprimée en octets, la longueur totale maximale est donc de = 65535octets. ID : Codé sur 16 bits, le champ Identification permet de reconstituer les différents fragments. Les en-têtes IP des fragments sont les mêmes à l exception de la longueur et du checksum. Flags : Codé sur 3 bits, ces flags permettent de connaître l état actuel de la fragmentation. Le premier bit est à 1 (Reserved), le deuxième autorise ou non la fragmentation (DF Don t Fragment) et le dernier indique s il existe d autres fragments (MF More Fragments). frag offset : Codé sur 13 bits, indique à quel position se trouve le fragment par rapport au premier. Le premier possède donc un champ frag offset à 0.

82 IV.3. INTÉGRATION ET VALIDATION TTL : Le champ Time TO Live indique la durée de vie maximale du paquet. Lorsqu il baisse à 0, le paquet est détruit. A chaque passage dans un routeur, ce champ sera décrémenté. Ceci permet d éviter les boucles infinies dans la propagation des trames. proto : Codé sur 8 bits, il représente le champ Protocol. Les plus répandus sont -01-ICMP, -06-TCP et -17- UDP. Les numéros de protocoles sont attribués par l IANA - Internet Assigned Number Security. Checksum : Codé sur 16 bits, la somme de contrôle permet de vérifier la validité du paquet (et uniquement celle du paquet et non pas des données qu il contient : deux trames IP ayant les même champs auront la même somme de contrôle). Src IP address : Représente l IP source codée sur 32 bits. Dst IP address : Représente l IP de destination codée sur 32 bits également. IP Options : Codé de 0 à 40 octets, ce champ permet de passer certaines options à IP, comme la Classe ou le Numero permettant de lister les options disponibles. ver IHL TOS pkt-len ID flags frag offset TTL proto = TCP header checksum Src IP address Dst IP address Options IP (si présentes) TCP Header (proto=6) TCP Payload : Couvert par le checksum 32 bits Fig. IV.2 Paquet IPv4 Générique Ces champs nous serviront, par exemple, à définir la manière dont ESP gère les priorités de communications (par la récupération du T OS) ou encore à comprendre pourquoi il était très difficile de déployer IPSec à travers des équipements NAT, avant le développement de l extentions NAT Traversal

83 CHAPITRE IV. INTÉGRATION DU MODE CONFIG AH - Authentication Header AH est uniquement utilisé pour de l authentification pas de chiffrement. Il permet de valider l identité de l hôte distant avec lequel on communique afin de se prémunir des attaques MITM. Il détecte ainsi toute altération des données et offre une protection forte contre le rejeu de paquets. En-tête AH L Authentification est faite à partir d une empreinte cryptographique d authentification basé sur l ensemble des champs non modifiables du paquet IP. Cela exclut, par exemple, le champ TTL est décrémenté, ou encore le checksum qui est recalculé à chaque passage dans un routeur. Cette empreinte est alors aposé au paquet avant que celui ci ne soit envoyé. Lors de la récéption du paquet, l hôte distant calcule à son tour une empreinte du paquet fraîchement reçu et le compare avec celui contenu dedans afin de le valider. next hdr AH lengh Reserved SPI (Security Parameters Index) Sequence Number Authentication Data hash MD5 ou SHA-1 Fig. IV.3 Champ de l en-tête AH Champs de l en-tête AH : Next Header : Codé sur un octet, il contient le numéro de protocol de l en-tête suivante, donc le numéro de protocole des données que le paquet transporte. Ce champ permet de lier les différentes en-têtes. AH lengh : Codé sur un octet également, il contient la taille de l en-tête AH en mots de 32 bits, ôtée de 2 (ceci n inclue pas les données mais l en-tête uniquement). Les 64 bits sont enlevés afin d être cohérent avec la manière dont IPv6 calcule la taille de l en-tête AH. IPSec dans IPv6 n est pas abordé dans ce rapport, on peut en trouver une description à??. Reserved : est comme son nom l indique, un champ reservé pour un usage futur, codé sur 16 bits

84 IV.3. INTÉGRATION ET VALIDATION SPI : Le Security Parameter Index est un identifiant permettant de trouver à quel politique le paquet doit-il être soumis, et donc à quel SA dans la SAD il correspond. Le SPI est codé sur 32 bits et sera développé plus en détails dans la section??. Sequence Number : Codé sur 32 bits, il représente un compteur initialisé à 0 lorsqu une SA entre deux hôtes est établie. Il est incrémenté pour chaque datagramme correspondant à cette SA. Il permet d identifier chaque paquet de manière unique et ainsi de se protéger contre des attaques par rejeu. Authentication Data : Contient l empreinte calculée par le protocole AH. Comme décrit précédemment, IPSec peut fonctionner suivant le mode Tunnel ou Transport. AH n est donc pas calculé de la même manière. AH en mode Tranport En mode Transport, l en-tête AH est insérée entre l en-tête du protocole de Transport (TCP le plus souvent) et l en-tête IP (cf Fig. IV.4). Comme l en-tête AH vient s intercaler entre les en-tête TCP et IP, les champs proto sont successivement modifiés : Le champ proto du paquet IP, à l origine en TCP, est modifié au profit de AH. AH, quant à lui, garde dans son champ next une trace du protocole Transport utilisé, à savoir TCP, ceci permet de faire le lien entre les en-têtes. AH n offrant pas de chiffrement, un attaquant potentiel aura accès non seulement à l en-tête, mais également aux données, bien qu il ne puisse pas altérer le paquet ou le rejouer. Une fois que le paquet aura été validé à la réception, il sera décapsulé, l en-tête AH enlevé, les champs remis à jour et le paquet sera passé à l application concernée. AH en mode Tunnel En mode Tunnel, le paquet IP est entièrement réencapsulé dans un autre paquet IP avant d être envoyé. Une en-tête AH est aposée au paquet, comme en mode Transport, ce qui permet de valider l authenticité du paquet à la réception et de se prémunir de l altération des paquets sur le chemin. Mais contrairement au mode AH-Transport, AH-Tunnel encapsule le paquet IP dans sa totalité, c est à dire l en-tête IP et le payload. Les addresses réelles de l émetteur et du destinataire sont donc masquées (cf Fig. IV.5), seules les adresses des deux passerelles formant les deux bouts du tunnel sont visibles

85 CHAPITRE IV. INTÉGRATION DU MODE CONFIG IP Hdr TCP Hdr + Pload Couvert par AH verlen TOS pkt-len ID flgs offset TTL Proto Checksum Src IP Address Dst IP Address TCP Header TCP Payload verlen TOS pkt-len ID flgs offset TTL Proto Checksum Src IP Address Dst IP Address nxt=tcp AH len Reserved S P I Seq. Number Authentication Data TCP Header TCP Payload TCP Hdr + Pload AH Hdr IP Hdr Fig. IV.4 Hash AH en mode Transport

86 IV.3. INTÉGRATION ET VALIDATION IP Hdr TCP Hdr + IP Hdr + Pload Couvert par AH verlen TOS pkt-len ID flgs offset TTL Proto Checksum Src IP Address Dst IP Address TCP Header TCP Payload verlen TOS pkt-len ID flgs offset TTL Prto=AH Checksum Src IP Address Dst IP Address nxt=ip AH len Reserved S P I Seq. Number Authentication Data ver len TOS pkt-len ID flgs offset TTL Prto=TCP Checksum Src IP Address Dst IP Address TCP Header TCP Hdr + Pload AH Hdr IP Hdr TCP Payload Fig. IV.5 Hash AH en mode Tunnel

87 CHAPITRE IV. INTÉGRATION DU MODE CONFIG Les vérifications du paquet arrivant à destination sont les mêmes qu en mode Transport : l Integrity Check Value est extrait d une part, calculé sur les différents champs du paquet reçu d autre part, puis comparé. Lorsque le paquet est valide, il est décapsulé et délivré à l application en attente, ou routé vers le sous réseau de destination suivant l IP réelle. A partir de ce moment, il s agit d un paquet IP normal. La différence entre le Mode Transport et le Mode Tunnel dans IPSec n est pas explicite puisqu il n existe pas de champ Mode à proprement parler. Elle se fait au niveau du champ Next Hdr : lorsqu il vaut IP, il s agit du Mode Tunnel puisqu il encapsule entièrement un paquet IP. A l inverse, lorsque ce champ est positionné à un autre protocole de transport comme TCP, UDP ou ICMP, il s agit là du Mode Transport qui sécurise le traffic de bout en bout. ESP - Encapsulating Security Payload En-tête ESP ESP peut être considéré comme le coeur de la suite de protocoles IPSec. Il permet d avoir un chiffrement de toute les données présentes dans le paquet et éventuellement de les authentifier. ESP est constitué d un header (cf Fig. IV.6) et d un trailer et peut être utilisé en mode Tunnel comme en mode Transport tout comme AH. Le chiffrement des données n est lié à aucun algorithme cryptographique en particulier, comme expliqué dans la présentation d IPSec??. Les plus couramment utilisés sont AES, DES, TripleDES et Blowfish. Les paramètres de chiffrement et la clé utilisée sont dynamiquement négociés par un démon IKE (racoon d ipsec-tools en locurrence dans le cadre de notre cahier des charges) et stockés dans une Security Association. Les champs d un paquet ESP sont principalement : Payload chiffré : Correspond aux données chiffrées, de taille variable. Next Header : utilisé comme dans AH, permet de connaître le type de payload du paquet, à savoir IP, TCP, UDP, etc. Padding : il s agit de bourrage permettant l utilisation d algorithmes cryptographiques par blocs (comme AES en mode cbc par exemple). Pad len : Taille du bourrage. D autre part, ESP fournit une authentification optionnelle. Lorsqu elle est activée, l empreinte d authentification vient se greffer après le trailer ESP et utilise les même mécanismes que dans AH à ceci près que l authentification ESP est basée uniquement sur l en-tête ESP et le payload, et non pas sur le paquet IP en entier. De l extérieur, un attaquant ne peut determiner le contenu d un paquet ESP, ni même savoir s il contient une empreinte d authentification ou non. Néanmoins, lors de l encapsulation ESP, le

88 IV.3. INTÉGRATION ET VALIDATION S P I Sequence Number Encrypted Payload padding pad len nxt hdr ESP Hdr ESP Trl S P I Sequence Number Encrypted Payload padding pad len nxt hdr Authentication Data Auth ESP Trl ESP Hdr Chiffré Fig. IV.6 En-tête ESP avec (à d.) et sans (à g.) Authentification champ ToS du paquet IP est récupéré à partir du paquet original. Ce champ, comme nous l avons vu, sert entre autres, à définir le champ QoS utilisé dans les transmissions de type VoIP par exemple pour avoir un ordre de priorité important. ESP en mode Transport ESP en mode Transport (cf Fig. IV.7) fonctionne à peu de choses près comme AH en mode Transport. Destiné à sécuriser les transferts de données entre deux hôtes A et B, ESP-Transport encapsule uniquement le payload (données utiles). Comme pour AH, les adresses source et destination sont donc visibles dans le paquet transmis. ESP en mode Tunnel Le mode ESP-Tunnel (cf Fig. IV.8) encapsule entièrement le paquet IP original dans un autre paquet IP. C est ce qui se rapproche le plus d un tunnel VPN au sens où la plupart des utilisateurs l entendent : un tunnel chiffré parlequel ils peuvent faire transiter des flux sensibles de manière sécurisée afin de contacter un réseau distant. C est le mode le plus souvent utilisé lorsqu il s agit de monter une passerelle IPSec

89 CHAPITRE IV. INTÉGRATION DU MODE CONFIG IP Hdr Chiffré Authentifié verlen TOS pkt-len ID flgs offset TTL Proto Checksum verlen TOS pkt-len TTL ID nxt=esp flgs offset Checksum Src IP Address Dst IP Address IP Hdr Src IP Address Dst IP Address S P I Seq. Number TCP Hdr + Pload TCP Header TCP Payload TCP Payload padding padlen nxthdr Authentication Data Fig. IV.7 Paquet ESP en Mode Transport

90 IV.3. INTÉGRATION ET VALIDATION IP Hdr Chiffré Authentifié verlen TOS pkt-len ID flgs offset TTL Proto Checksum verlen TOS pkt-len TTL ID nxt=esp flgs offset Checksum Src IP Address Dst IP Address IP Hdr Src IP Address Dst IP Address S P I Seq. Number TCP Hdr + Pload TCP Header TCP Payload IP Hdr TCP Payload padding padlen nxthdr Authentication Data Fig. IV.8 Paquet ESP en Mode Tunnel

91 Annexe B : Echange Diffie-Hellman Présentation L échange de clés Diffie-Hellman, ou pour être plus exact, la négociation de clés par Diffie- Hellman a été développé par Diffie et Hellman en 1976, et publié dans le New Directions in Cryptography. Ce protocole permet à deux utilisateurs, que nous appellerons traditionnellement Alice et Bob, de s échanger un secret à travers un canal non-sécurisé. Ce protocole est utilisé dans des domaines variés, et intervient notamment dans la négociation de clés de sessions IPSec. Principe Le protocole met en place deux paramètres publics : p, un nombre premier, et g, un générateur, inférieur à p défini comme suit : Pour tout entier compris entre 1 et p 1 inclus, il existe une puissance k de g telle que n = g k mod p. Supposons qu Alice et Bob souhaitent échanger un secret par Diffie-Hellman, ils procèdent alors comme suit (cf. IV.9) (toutes les opérations sont modulo p) : Alice choisit un nombre aléatoire a et Bob choisit un nombre aléatoire b. Alice calcule alors x = g a et Bob calcule y = g b. Alice envoie x à Bob et Bob envoie y à Alice. Alice calcule alors (g b ) a = g ab. Bob calcule (g a ) b = g ab. Alice et Bob se retrouvent tout deux avec g ab. Le secret partagé par Alice et Bob est alors k = g ab.

92 IV.3. INTÉGRATION ET VALIDATION Fig. IV.9 Protocole Diffie-Hellman - Sécurité et Faiblesses La sécurité de l algorithme Diffie-Hellman repose sur la difficulté du calcul du logarithme discret. Il suppose qu il est très difficile de calculer le secret partagé g ab à la seule connaissance de g a et de g b lorsque le nombre premier p est grand. Casser un algorithme Diffie-Hellman est aussi difficile que de calculer le logarithme discret sous certaines conditions. (Maurer - Advances in Cryptology 1994). L échange de clés Diffie-Hellman est vulnérable à des attaques de type Man In The Middle. Un attaquant potentiel, traditionnellement appellé Oscar, intercepte la valeur publique d Alice (g a ) et envoie sa propre valeur publique à Bob. Lorsque Bob envoie sa valeur publique, Oscar l intercepte également et envoie encore sa propre valeur à Alice. Ainsi, Alice et Oscar établissent un secret partagé et Oscar et Bob établissent un autre secret partagé, tandis que Alice et Bob croient tous les deux communiquer l un avec l autre. Oscar est alors capable de déchiffrer et modifier l ensemble du trafic entre Alice et Bob. Cette attaque fonctionne car les correspondants ne s authentifient pas au préalable. Le protocole Diffie-Hellman authentifié a été développé en 1992 afin d empêcher l attaque MITM. Ce protocole préconise l utilisation de signatures et de certificats numériques afin d authentifier les deux correspondants. Alice et Bob signent alors leur valeur publique à l aide de leur clé privée. Il est impossible à Oscar de modifier cette signature sans les clés privées respectives