4
METHODOLOGIE ET CHOIX TECHNIQUES
Les protocoles de sécurité utilisés dans les réseaux VPN présentent cer-taines failles qui peuvent être utilisées par les attaquants pour les déstabiliser.
Il est donc important de pouvoir analyser les flux qui circulent sur le réseau afin de détecter d’éventuelles attaques.
Dans ce chapitre, nous présenterons la Méthodologie d’étude ainsi que les différents choix techniques opérés pour assurer le renforcement de la sécurité dans les réseaux VPN.
4.1 Le type du réseau VPN choisi
Dans le présent travail, nous allons utiliser une architecture d’un réseau VPN site à site parce qu’elle garantit non seulement une bonne qualité de service à l’entreprise du fait de la prise en charge du VPN et du cryptage par des processeurs spécialisés mais aussi facilite le contrôle du trafic autorisé et offre la possibilité d’initier les connexions VPN d’un côté ou de l’autre du tunnel comme le montre le tableau 1.1 de la section 1.2.2.
Avec ce modèle, les deux extrémités du tunnel utilisent des équipements situés dans le périmètre de l’entreprise pour négocier et rendre des services de sécurité. Avec ce système, on rend entièrement transparents les mécanismes
35
de sécurité au niveau des utilisateurs finaux [6]. Les données transmises par les postes clients traversent le tunnel comme elles traverseraient n’importe quel autre réseau public ou privé lui permettant d’accéder à sa destination, sans aucune implémentation spécifique d’un quelconque mécanisme de sécu-rité au niveau des postes clients ce qui apporte une flexibilité et permet un déploiement rapide et simple.
4.2 Le protocole de tunneling choisi
Plusieurs protocoles sont utilisés pour établir des tunnels VPN. Il s’agit des protocoles PPTP, L2F, L2TP, MPLS, IPsec, SSL /TLS.
Les deux protocoles utilisés pour assurer à la fois l’authentification, la confi-dentialité et l’intégrité des données sur le réseau VPN sont les protocoles SSL et IPsec (tableau 2.1 de la section 2.7) puisqu’ils utilisent des mécanismes de hachage et de chiffrement des données [18].
Pour la présente étude, nous allons utiliser IPsec puisqu’il permet d’inter-cepter les trames au niveau 3 pour leur appliquer des mécanismes de hachage et d’authentification ce qui le rend particulièrement plus intéressant en ma-tière de sécurité que SSL [6]. IPsec supporte l’algorithme AES (Advanced Encryption Standard) pour le chiffrement des données alors que la majorité des applications SSL ne l’ont pas encore implémenté [14].
IPsec utilise le protocole IKE (Internet Key Exchange) qui se charge de la gestion automatique (négociation, mise à jour, suppression) de tous les paramètres relatifs à la sécurisation des échanges. Afin de stocker et de ma-nipuler facilement l’ensemble des paramètres gérés par IKE et utilisés par les mécanismes de sécurisation, IPsec a recours à la notion d’association de sécu-rité (Security Association, SA) qui est une structure de données qui regroupe
CHAPITRE 4. METHODOLOGIE ET CHOIX TECHNIQUES
l’ensemble des paramètres de sécurité associés à une communication donnée [11].
Pour stocker l’ensemble des associations de sécurité actives, on utilise une base de données des associations de sécurité (Security Association Database, SAD). Les éléments stockés dans cette base de données sont créés et modi-fiés par IKE puis consultés par la couche IPsec pour savoir comment traiter chaque paquet reçu ou à émettre.
Les protections offertes par IPsec sont basées sur des choix définis par l’ad-ministrateur du réseau par le biais de politiques de sécurité. Ces politiques sont généralement stockées dans une base de données de politique de sécurité (Security Policy Database, SPD) et se présentent sous forme d’une liste or-donnée de règles, chaque règle comportant un certain nombre de critères qui permettent de déterminer quelle partie du trafic est concernée. La consulta-tion de la base de données des politiques de sécurité permet de décider, pour chaque paquet, s’il se verra apporter des services de sécurité, sera autorisé à passer outre ou sera rejeté. C’est également cette base qui indique à IKE quelles associations de sécurité il doit négocier et, en particulier, quels tunnels sécurisés il doit établir.
4.3 Fonctionnement du protocole IKE
Le protocole IKE se décompose en deux phases distinctes [1]. Dans une première phase, un canal sécurisé (chiffré et authentifié) est créé entre les deux participants. Dans une deuxième phase, ce canal est utilisé pour négocier les divers paramètres de la SA.
La phase 1 permet d’établir un canal sécurisé avec authentification des deux extrémités d’un tunnel, canal dénommé ISAKMP (Internet Security
Réalisé par Henoc YATAKPO 37
Association and Key Management Protocol) SA. Ce canal sert ensuite aux échanges d’informations nécessaires à la phase 2. Elle peut se dérouler selon deux modes : principal (en anglais main) et agressif (en anglais aggressive).
Le mode agressif a la caractéristique de nécessiter moins de messages que le premier mais de ne pas cacher l’identité des participants à un éventuel attaquant en écoute passive sur le réseau.
La phase 2 négocie et établit les SA IPsec permettant de protéger les échanges de données. Elle ne peut se dérouler que si la phase 1 s’est achevée correctement. La structure d’une en-tête ISAKMP est montrée par la figure 4.1 :
Figure4.1 – En-tête ISAKMP [1].
Ensuite viennent une ou plusieurs charges (payload), chacune d’entre elles commençant par l’en-tête suivant :
Figure4.2 – En-tête des charges dans un datagramme ISAKMP [1].
CHAPITRE 4. METHODOLOGIE ET CHOIX TECHNIQUES
Le schéma 4.3 résume la structure complète d’un datagramme ISAKMP.
Figure4.3 – Structure complète d’un datagramme ISAKMP [1].
4.4 Le protocole de hachage choisi
Les algorithmes de hachage utilisés dans IPsec sont MD5 et SHA-1.
La fonction MD5 a été développée par Ron Rivest en 1992 afin de pallier les faiblesses détectées dans sa version précédente MD4. MD5 génère un hash de 128 bits, soit 32 caractères hexadécimaux. Mais cette longueur de 128 bits est maintenant considérée comme peu sûre pour éviter les collisions puisque plusieurs attaques ont été conduites contre ce protocole et ont permis de générer des collisions [9].
SHA-1 a été développé par NSA (National Security Agency). Elle présente beaucoup de points communs avec MD5 mais utilise un hash de 160 bits.
Réalisé par Henoc YATAKPO 39
Parmi les fonctions de hachage citées nous avons utilisé la fonction de hachage SHA-1 car, comparée aux fonctions MD5, la taille de ses hash est plus grande soit 160 bits contre 128 bits pour MD5.
Pour toujours renforcer la sécurité et rendre le protocole SHA-1 moins sensible aux attaques, on y ajoute le protocole HMAC (hash message authen-tication code) qui est basé sur une clé d’authentification pour aboutir à une signature électronique du message attestant à la fois de son intégrité et de son origine.
4.5 Les solutions matérielle et logicielle du marché
Plusieurs variétés de systèmes permettent la réalisation d’un VPN site à site avec le protocole IPsec. Nous avons entre autres les boitiers Cisco ASA, les firewalls WatchGard XTM et Cyberoam et les paquets open sources FreeS/WAN et Racoon.
Le tableau 4.1 montre les différentes caractéristiques de ces systèmes.
Nous pouvons utiliser Racoon ou FreeS/WAN malgré qu’ils n’aient pas de systèmes de prévention d’intrusion parcequ’ils sont opensource et gratuits.
Dans le cadre de notre étude, nous avons choisi Racoon puisque la solution FreeS/wan a été stoppée en mars 2004 à cause des bugs enregistrés et de la lenteur de son developpement.
4.6 Choix du système de détection d’intrusion
Plusieurs systèmes de détection sont utilisés dans les réseaux. A voir les dif-férentes caractéristiques, nous pouvons utiliser trois produits à savoir Snort, Prélude et Bro qui sont tous des produits open source. Les IDS Snort et Prélude sont issus des projets très actifs, aussi bien dans le développement
CHAPITRE 4. METHODOLOGIE ET CHOIX TECHNIQUES
Tableau 4.1 – Caractéristiques des systèmes et logiciels permettant la réalisation d’un VPN.
Cisco ASA WatchGard XTM
Cyberoam Cisco PIX XSR IPsec-tools et Racoon
Oui Oui oui oui Oui Oui Oui
Possède
Oui Oui Non Non Oui Non Non
Nature de l’équi-pement
ou du
logiciel
Propriétaire Propriétaire Propriétaire Propriétaire Propriétaire Open source Open source
que dans la mise à jour des signatures. Bro est conçu pour servir de sup-port didactique dans les milieux universitaires, en laboratoire notamment. Il n’existe pas de plugins ni d’interface graphique pour paramétrer l’outil. Le système étant produit par des chercheurs, les mises à jour et les communautés d’utilisateurs sont parfois aussi insuffisantes.
Nous allons utiliser pour notre étude le sytème de détection d’intrusion Snort. Ce choix est justifié par sa disponibilité et le fait qu’il soit
multiplate-Réalisé par Henoc YATAKPO 41
forme. Cette solution peut être adaptée pour une entreprise quelle que soit sa taille, mais aussi la disponibilité de nombreuses règles dans la communauté de Snort et des projets comme Ouikmaster qui gèrent la mise à jour des si-gnatures et fournissent un nombre important de règles optimisées et efficaces pour la détection des intrusions. De plus Snort dispose d’un ensemble de plu-gins qui aident à étendre ses fonctionnalités, notamment Snortsam qui ajoute des fonctionnalités permettant à Snort de jouer le rôle d’IPS.
4.7 Methologie à suivre
Nos différents tests seront effectués sur le réseau interne du camp Guézo.
En effet, le réseau interne du camp est constitué de plusieurs réseaux locaux à savoir ESPACE, EMG, BCE.
Pour notre étude nous allons d’abord déployer un réseau VPN site à site entre les réseaux locaux espace et emg en utilisant le protocole de tunne-ling IPsec. Pour cela nous allons installer et configurer les paquets Racoon et IPsec-tools sur un système d’exploitation Linux (Debian). Ces paquets permettront de définir les différentes politiques et associations de sécurité à utiliser pour les différents échanges sur le réseau VPN mis en place. Ils per-mettront de définir également les protocoles de cryptographie et de hachage à utiliser pour l’authentification et pour le chiffrement des données.
Nous allons ensuite installer un générateur d’attaques pour tester la vul-nérabilité du réseau déployé. Pour ce faire, nous allons installer et configurer Metasploit sur un poste du réseau. Metasploit permettra de faire le scan du réseau afin de savoir les différents ports ouverts, les systèmes d’exploitation utilisés et leur version. Ce scan permettra de savoir les types d’attaques qui peuvent passer sur ce réseau.
CHAPITRE 4. METHODOLOGIE ET CHOIX TECHNIQUES
Enfin nous allons mettre en place sur le réseau les systèmes de sécurité à savoir un pare-feu et un système de détection d’intrusion. Nous allons alors installer, configurer et utiliser Snort et Netfilter pour le contrôle du réseau.
Netfilter permettra de bloquer les adresses et les protocoles qui ne sont pas autorisés. Snort quant à lui permettra d’accéder au contenu des différents pa-quets pour les analyser et déclencher d’alertes en cas de détection de papa-quets suspects. Puis nous allons générer sur ce nouveau réseau les mêmes attaques pour comparer les vulnérabilités des deux réseaux.
4.8 Choix techniques de réalisation
Les choix techniques de réalisation ont porté sur des outils et systèmes informatiques présentés ci-dessous.
4.8.1 Wireshark
Wireshark est un logiciel libre qu’on installe sur une machine physique et qui permet d’analyser les protocoles réseaux à partir d’une interface. Son utilisation nécessite qu’il soit démarré avec les privilèges de root. Pour l’exé-cuter sous Linux il suffit d’ouvrir un terminal et de taper la commande :sudo wireshark.
Pour réaliser une capture avec wireshark, il est nécessaire de sélectionner d’abord une interface réseau. On va alors dans le menu Capture ensuite dans interfaces et on choisit l’Interface. Une fois l’interface choisie une nouvelle fenêtre s’ouvre et la capture commence.
4.8.2 Metasploit
Metasploit est un projet open-source sur la sécurité informatique qui four-nit des informations sur des vulnérabilités, aide à la pénétration de systèmes informatisés et au développement de signatures pour les IDS. Le plus connu
Réalisé par Henoc YATAKPO 43
des sous-projets est le Metasploit Framework, un outil pour le développe-ment et l’exécution d’exploits contre une machine distante. Créé à l’origine en langage de programmation Perl, Metasploit Framework a été complète-ment réécrit en langage Ruby. Il est un puissant outil pour les chercheurs en sécurité étudiant des vulnérabilités potentielles.
4.8.3 DIA
Dia est un logiciel libre de création de diagramme. Il est conçu de manière modulaire avec plusieurs paquetages de formes pour permettre de réaliser des diagrammes UML, circuit électrique, réseau d’ordinateurs, etc.
Pour notre étude, nous avons utilisé DIA pour représenter les différentes architectures de réseaux.
Le tableau 4.2 fait la synthèse de tous les logiciels et systèmes utilisés.
Tableau 4.2 – Synthèse des outils utilisés.
Numéro Outils Version
5
CONFIGURATION DU VPN SITE A SITE ENTRE DEUX RESEAUX LOCAUX DISTANTS (LAN1 et LAN2)
La configuration du VPN site à site a été faite entre deux réseaux lo-caux distants LAN1 et LAN2. Le réseau LAN1 utilise pour ses postes le plan d’adressage suivant 10.143.7.0 avec pour masque de sous-réseau 255.255.255.224 alors que le LAN2 utilise comme plan d’adressage 192.168.1.0 et 255.255.255.0 pour masque de sous-réseau.
5.1 Politique de sécurité définie pour le réseau VPN à mettre en place
Pour assurer une communication sécurisée, une disponibilité des services et une qualité de service au niveau du réseau VPN, il faudrait respecter certaines règles dans la configuration et l’utilisation du réseau VPN. Ainsi il faut :
- définir le cadre global d’utilisation : il est impératif de savoir dans quelles conditions et pour quels objectifs le réseau VPN veut être utilisé pour pouvoir définir le débit de l’Internet et les équipements à utiliser. De même, les utilisateurs du réseau doivent être conscients que leur respon-sabilité risque d’être engagée si quelqu’un d’autre utilise à d’autres fins leur compte ou leur machine sur le réseau.
- définir le cadre individuel d’utilisation : une fois le cadre global défini,
45
chaque groupe d’utilisateurs peut avoir besoin de certaines spécificités.
Il est donc nécessaire de définir les différents groupes d’utilisateurs avec des droits spécifiques selon leurs besoins et privilèges.
- respecter les données privées de chaque utilisateur : comme dans le réseau local, les utilisateurs ne doivent pas utiliser ce moyen de connexion pour accéder aux données auxquelles ils ne sont pas censés avoir accès comme les partages privés de chacun et tout autre élément que des utilisateurs inexpérimentés auraient laissé sans protection.
- préserver le système d’information : il est nécessaire de sensibiliser les uti-lisateurs aux risques qu’ils encourent s’ils utilisent un quelconque moyen qui risquerait de compromettre l’intégrité du système d’information, que ce soit consciemment ou inconsciemment. Il peut arriver parfois qu’un utilisateur essaie d’utiliser un mécanisme quelconque téléchargé sur In-ternet et qui fonctionne en mode VPN. Les traces laissées par une telle tentative feront penser à une tentative d’intrusion, ce qui va provoquer de fausses alertes dans le réseau.
5.2 Installation des paquets Racoon et IPsec-tools sur les serveurs des LAN1 et LAN2
Pour la configuration d’un serveur VPN, il faut d’abord installer sur les deux serveurs le système d’exploitation Linux, ensuite les paquets Racoon et IPsec-tools. Le paquet Racoon de Linux est un serveur d’échange de clés IKE.
Son rôle est de négocier les clés entre deux serveurs ou entre un serveur et un client dans le but d’établir une association de sécurité IPsec et le paquet IPsec-tools fournit l’outil setkey qui sert à configurer les politiques de sécurité.
La commande pour installer le paquet Racoon et ipsec-tools est :
CHAPITRE 5. CONFIGURATION DU VPN SITE A SITE ENTRE DEUX RESEAUX LOCAUX DISTANTS (LAN1 ET LAN2)
root@henoc :/home/henocblaise# apt-get install racoon ipsec-tools
5.3 Gestion des clés et certificats
La gestion des clés (aussi bien publiques que privées) et certificats com-prend notamment les actions de les générer, les distribuer et les garder dans un endroit sûr.
Ces éléments et leur gestion représentent un socle important de la sécurité des VPN. Ainsi, en cas de compromission de l’un d’entre eux, il est important de pouvoir le désactiver rapidement de manière à ne pas courir le risque de compromettre l’ensemble du réseau.
Ces clés sont généralement installées sur des serveurs afin de permettre les opérations de chiffrement/déchiffrement. Ces serveurs doivent alors être sécurisés de manière à ne pas rendre inutiles toutes les précautions prises pour la garde de ces clés.
5.4 Génération de la clé partagée pour l’authentification
Nous allons générer une clé partagée aléatoire pour l’authentification. Nous avons utilisé la commande dd de linux pour le faire. Cette commande, lors-qu’elle utilise le pseudo device random, permet de générer un fichier rempli de caractères aléatoires. Nous allons juste spécifier le nombre de caractères vou-lus. Dans notre cas, nous fixons une longueur minimale de 20 octets pour res-pecter les recommandations de SHA-1 [13]. La commande ci-dessous montre la génération de la clé.
root@henoc :/home/henocblaise#dd if=/dev/random count=1 bs=20
Réalisé par Henoc YATAKPO 47
| xxd-ps
- dd : le nom de la commande
- if : input file qui est le /dev/random
- bs : block size qui précise le nombre de caractères à générer
- count : qui précise le nombre de blocs à générer. Dans notre cas nous avons généré un seul bloc.
Comme les caractères sont générés en binaire, il est nécessaire de les convertir en hexadécimal pour les utiliser comme clé. C’est le rôle de la commande xxd -ps
5.5 Configuration du serveur VPN
Pour créer un VPN avec Racoon, il faut renseigner deux fichiers : le fichier racoon.conf et le fichier ipsec-tools.conf.
Le fichier racoon.conf est situé dans le répertoire /etc/racoon qui contient tous les paramètres liés aux négociations des associations de sécurité entre les deux extrémités.
Le fichier ipsec-tools.conf contient l’ensemble des instructions à exécuter par la commande setkey pour renseigner la base SPD avec les SA.
Voici le fichier racoon.conf mis en œuvre pour la configuration du LAN1.
Notons que les lignes qui commencent par # sont des commentaires.
log notify ;
#Nous allons spécifier les chemins pour les clés partagées path pre_shared_key "/etc/racoon/cles.txt" ; remote "adresse de l’interface WAN"
{
CHAPITRE 5. CONFIGURATION DU VPN SITE A SITE ENTRE DEUX RESEAUX LOCAUX DISTANTS (LAN1 ET LAN2)
exchange_mode main ;
# Nous allons utiliser pour le chiffrement l’AES256
#et SHA-1 pour l’authentification
lifetime time 86400 sec ; }}
#Nous allons passer a la phase 2 pour les SA ipsec
#les paramètres spécifiés pour cette phase vont s’appliquer pour tous les échanges
#entre nos deux LAN c’est-à-dire à tous les protocoles.
#mais il est possible d’avoir des SA différentes selon les adresses et/ou les protocoles
sainfo adress "adresse réseau source"/"masque de sous-réseau" any "adresse réseau destination"/"masque de sous-réseau" any
{ pfs_group 5 ;
encryption_algorithm aes256 ;
authentication_algorithm hmac_sha1 ; compression_algorithm deflate ;
lifetime time 28800 sec ; } Voici le fichier ipsec-tools.conf :
#Suppression des SA éventuellement présentes dans la base SPD
Réalisé par Henoc YATAKPO 49
spdflush ;
#Création de la SA IPsec en sortie
spadd "adresse réseau source"/"masque de sous-réseau" any "adresse réseau destination"/"masque de sous-réseau" any -P out ipsec
#Passerelles à changer
esp/tunnel/adresse du serveur VPN source-adresse du serveur VPN destination/require ;
#Création de la SA IPsec en entrée
spadd adresse du réseau destination adresse du réseau source any -P in ipsec
esp/tunnel/adresse du serveur VPN destination-adresse du serveur VPN destination/require ;
Les commandes qui sont dans le fichier sont utilisées par setkey. Voici les
Les commandes qui sont dans le fichier sont utilisées par setkey. Voici les