rapport de projet de fin de parcours

ISET NABEUL JUIN 2015

Sana AFLI, Nadine HRIRA Page | i

Dédicaces

À notre raison de vivre,

D’espérer,

À notre source de courage,

À ceux qu'on a de plus chères,

Nos petites familles pour leurs sacrifices sans limite,

À nos enseignants pour leurs patience, leurs soutien, leurs

encouragements,

Et à nos amis pour leur témoigner une amitié et fidélité indéfinies.


Sana AFLI, Nadine HRIRA Page | ii

Remerciement

Au terme de ce travail, nous saisissons cette occasion pour exprimer nos vifs

remerciements à toute personne ayant contribué de près ou de loin, à la

réalisation de ce travail.

Nous souhaitons tout d’abord remercier notre encadreur madame Sana

HAOUAS, qui n’a pas cessé de nous encourager pendant la durée du projet,

pour son entière disponibilité et sa générosité en matière de formation et

d’encadrement.

Nous adressons l’expression de notre profonde gratitude à l’ensemble des

enseignants de l’Institut Supérieur des Etudes Technologiques de Nabeul qui ont

assuré notre formation et nous ont transmis la base de connaissances et du

savoir-faire qui nous permet d’aller toujours de l’avant.

Enfin nous exprimons également notre gratitude aux membres du Jury, qui nous

ont honoré en acceptant de juger ce modeste travail.


Sana AFLI, Nadine HRIRA Page | iii

Sommaire

Introduction générale ................................................................................................ 1

CHAPITRE I : ETAT DE L’ART ......................................................................... 2

Introduction.................................................................................................................... 3

I.1 Les architectures réseaux commutées ............................................................. 3

I.1.1 Le modèle de réseau hiérarchique ........................................................................................... 3

I.1.1.1 Motivations ......................................................................................................................... 3

I.1.1.2 Structuration ....................................................................................................................... 4

I.1.2 La commutation au niveau 2 ................................................................................................... 5

I.1.3 La commutation au niveau 3 ................................................................................................... 6

I.1.4 Technologie d'agrégation de liens ........................................................................................... 6

I.1.4.1 Définition ........................................................................................................................... 6

I.1.4.2 Avantages ........................................................................................................................... 7

I.1.4.3 Agrégation de liens avec EtherChannel ......................................................................... 7

I.1.4.3.1 Définition .................................................................................................................... 7

I.1.4.3.2 Fonctionnalités offertes ............................................................................................ 8

I.1.4.3.3 Terminologie et vocabulaire spécifiques ................................................................ 9

I.1.4.3.4 Protocole de négociation .......................................................................................... 9

I.1.5 La redondance de niveau 2 ................................................................................................... 11

I.1.5.1 Le STP (Spanning Tree) .................................................................................................. 11

I.1.6 La redondance de niveau 3 ................................................................................................... 11

I.1.6.1 La redondance de passerelle avec HSRP (Hot Standby Router Protocol) .............. 11

I.1.6.2 Le protocole VRRP (Virtual Router Redundancy Protocol) ..................................... 12


Sana AFLI, Nadine HRIRA Page | iv

I.1.6.3 Le protocole GLBP (Gateway Load Balancing Protocol) ......................................... 13

I.2 Sécurisation des réseaux sans fil .................................................................... 13

I.2.1 Les réseaux locaux sans fil...................................................................................................... 13

I.2.2 La sécurité Wi-Fi...................................................................................................................... 14

I.2.2.1 Les protocoles de sécurité .............................................................................................. 14

I.2.2.1.1 WEP (Wired Equivalent Privacy) ......................................................................... 14

I.2.2.1.2 Wi-Fi Protected Access (WPA et WPA2) ........................................................... 15

I.2.2.2 Les méthodes d'authentification ................................................................................... 16

I.2.2.2.1 EAP (Extensible Authentication Protocol) ......................................................... 16

I.2.2.2.2 PEAP (Protected Extensible Authentication Protocol) ...................................... 17

I.2.2.3 Les portails captifs .......................................................................................................... 17

I.2.2.3.1 Définition .................................................................................................................. 17

I.2.2.4 Les proxys ........................................................................................................................ 19

I.2.2.4.1 Squid .......................................................................................................................... 19

I.2.2.4.2 SquidGuard .............................................................................................................. 19

I.2.3 La sécurité au niveau applicatif............................................................................................. 20

I.2.3.1 Les annuaires  .................................................................................................................... 20

I.2.3.1.1 Active Directory ........................................................................................................ 20

I.2.3.1.2 Active Directory Certificate Services ..................................................................... 21

I.2.3.1.3 Le serveur NPS (Network Policy Server) .............................................................. 22

I.2.3.1.4 Le protocole RADIUS ............................................................................................. 22

Conclusion .................................................................................................................... 24

CHAPITRE II : CONCEPTION ET IMPLEMENTATION DE

L’ARCHITECTURE RESEAU A DEPLOYER ............................................. 25

Introduction.................................................................................................................. 26

II.1 Etude des besoins ............................................................................................. 26

II.1.1 Besoins en infrastructure ...................................................................................................... 26


Sana AFLI, Nadine HRIRA Page | v

II.1.2 Besoins en services ................................................................................................................ 26

II.1.3 Besoins en sécurité................................................................................................................. 27

II.1.4 Environnement de simulation.............................................................................................. 27

II.2 Présentation de l'architecture proposée ...................................................... 27

II.2.1 Schéma de l'architecture........................................................................................................ 27

II.2.2 Plan d'adressage ................................................................................................................. 30

II.2.3 Zone DMZ ......................................................................................................................... 31

II.2.4 Zone des clients internes .................................................................................................. 32

II.2.2 Politique de sécurité ............................................................................................................... 33

II.3 Les étapes de configuration de l’architecture ........................................... 34

II.3.1 Configuration de la couche Distribution et Accès ........................................................... 34

II.3.1.1 Configuration du port Channel ................................................................................... 35

II.3.1.2 Vérification du port Channel ........................................................................................ 37

II.3.1.3 Configuration des VLANs .......................................................................................... 38

II.3.1.4 Vérification des VLANs ............................................................................................... 39

II.3.1.5 Configuration du protocole VTP ................................................................................. 40

II.3.1.6 Vérification du protocole VTP ..................................................................................... 42

II.3.1.7 Configuration du protocole STP .................................................................................. 43

II.3.1.8 Configuration du protocole HSRP .............................................................................. 47

II.3.1.9 Vérification du protocole HSRP .................................................................................. 49

II.3.1.10 Configuration d’ACL ................................................................................................... 55

II.3.1.11 Vérification de l’ACL ................................................................................................... 56

II.3.2 Configuration de la couche Distribution et Cœur ............................................................ 57

II.3.2.1 Configuration du port channel ..................................................................................... 58

II.3.2.2 Configuration du protocole eigrp................................................................................. 59

II.3.2.3 Vérification des routes eigrp ......................................................................................... 59

II.3.2.4 Configuration des routes statiques ............................................................................... 60


Sana AFLI, Nadine HRIRA Page | vi

II.3.2.5 Vérification des routes statiques ................................................................................... 61

II.3.2.6 Configuration de la surcharge NAT (PAT) ................................................................ 62

II.3.2.7 Vérification de la translation d’adresse ........................................................................ 63

II.3.2.8 Configuration de la route par défaut ........................................................................... 63

II.3.2.9 Vérification de la route par défaut .............................................................................. 64

Conclusion .................................................................................................................... 66

CHAPITRE III : DEPLOIMENT DES SERVICES RÉSEAU ET

SÉCURISATION DE L'ACCES SANS FIL ..................................................... 67

Introduction.................................................................................................................. 68

III.1 Mise en place des services réseau ............................................................... 68

III.1.1 Installation des rôles ............................................................................................................ 68

III.1.1.1 Active Directory pour les clients internes ................................................................ 68

III.1.1.2 Network Policy Service et Services de certificats Active Directory ...................... 70

III.1.1.2.1 Mise en place des stratégies d'accès (NPS) ........................................................ 71

III.1.1.2.2 Les services de certificats Active Directory (AD CS) ....................................... 73

III.1.2 Test d’authentification des clients internes....................................................................... 76

III.2 Mise en place des techniques de sécurité ................................................. 80

III.2.1 Mise en place du firewall pfSense ...................................................................................... 80

III.2.1.1 Configuration des interfaces ........................................................................................ 80

III.2.1.2 Configuration des règles .............................................................................................. 80

III.2.2 Mise en place du portail captif pour les clients "GUEST" ........................................... 83

III.2.2.1 Configuration du portail captif ................................................................................... 83

III.2.2.2 Authentification et gestion des utilisateurs ............................................................... 84

III.2.2.2.1 Gestion des comptes utilisateurs ......................................................................... 85

III.2.2.2.2 Sécurisation de l'authentification ......................................................................... 85

III.2.2.3 Test du portail captif .................................................................................................... 88

III.2.3 Mise en place d’un proxy .................................................................................................... 88


Sana AFLI, Nadine HRIRA Page | vii

III.2.3.1 Configuration du package Squid ................................................................................ 89

III.2.3.2 Configuration du package SquidGuard ..................................................................... 90

III.2.3.3 Test du proxy ................................................................................................................. 91

III.2.4 Sécurisation du point d’accès réservé aux clients invités ............................................... 92

III.3 Evaluation du niveau de sécurité de notre maquette ............................ 93

Conclusion .................................................................................................................... 97

Conclusion générale ................................................................................................. 98

Bibliographie .............................................................................................................. 99

Annexes ...................................................................................................................... A1

Annexe1. Les étapes d'intégration des machines virtuelles dans le réseau ............................ A1

Annexe2. Connectivité des firewalls à GNS3 et aux différents segments .............................. A3

Annexe3. Architecture générale sous GNS3 ............................................................................... A5


Sana AFLI, Nadine HRIRA Page | viii

Liste des figures

Figure 1 : Le modèle de réseau hiérarchique ...................................................................................... 4

Figure 2 : Agrégation de liens avec EtherChannel ............................................................................. 8

Figure 3 : Agrégat EtherChannel .......................................................................................................... 8

Figure 4 : Les réseaux locaux sans fil ................................................................................................. 14

Figure 5 : WPA-Personal ou WPA2-Personal .................................................................................. 16

Figure 6 : WPA-Enterprise ou WPA2-Enterprise ........................................................................... 16

Figure 7 : Le protocole MS-CHAP .................................................................................................... 17

Figure 8 : Principe du portail captif ................................................................................................... 18

Figure 9 : Fonctionnement de portail captif ..................................................................................... 19

Figure 10 : Active directory ................................................................................................................. 21

Figure 11 : Principe de Radius ............................................................................................................ 23

Figure 12 : Fonctionnement de RADIUS ......................................................................................... 24

Figure 13 : Maquette générale ............................................................................................................. 29

Figure 14 : Configuration des interfaces de TP-LINK ................................................................... 32

Figure 15 : Configuration des interfaces d’EDIMAX ..................................................................... 33

Figure 16 : Limitation d'accès par ACL ............................................................................................. 33

Figure 17 : La couche distribution et accès ....................................................................................... 34

Figure 18 : Vérification d’EtherChannel au niveau de sdist1 ......................................................... 37

Figure 19 : Vérification d’EtherChannel au niveau de sdist2 ......................................................... 38

Figure 20 : Test de connectivité du VLAN 10 au VLAN 99 ......................................................... 40

Figure 21 : Vérification du vtp au niveau de sdist1 ......................................................................... 43

Figure 22 : Vérification du vtp au niveau de sdist2 ......................................................................... 43

Figure 23 : Vérification du statut du protocole HSRP au niveau de sdist1.................................. 50

Figure 24 : Désactivation des ports fastEthernet de sdist1 ............................................................ 51

Figure 25 : Vérification du statut du protocole HSRP au niveau de sdist2.................................. 52

Figure 26 : Vérification de l'état du protocole HSRP au niveau de sdist1 ................................... 53

Figure 27 : Réactivation des ports fastEthernet de sdist1 .............................................................. 54

Figure 28 : Requête ping vers la passerelle de sdist1 du vlan 10 .................................................. 55

Figure 29 : Empêchement du VLAN 88 de communiquer avec le VLAN 10 ............................ 56

Figure 30 : Empêchement du VLAN 88 de communiquer avec le VLAN 99 ............................ 57

Figure 31 : Les couches distribution et cœur .................................................................................... 57

Figure 32 : Vérification des routes eigrp ........................................................................................... 60


Sana AFLI, Nadine HRIRA Page | ix

Figure 33 : Configuration des routes statiques au niveau du pfSense ........................................... 61

Figure 34 : Vérification des routes statiques au niveau core_ex .................................................... 61

Figure 35 : Vérification de la route statique au niveau de R1 ......................................................... 62

Figure 36 : Vérification de la translation d’adresse .......................................................................... 63

Figure 37 : Vérification de la route par défaut au niveau R1 .......................................................... 64

Figure 38 : Vérification de la route par défaut au niveau core_ex ................................................. 64

Figure 39 : Requête ICMP à partir d'une machine appartenant au VLAN 10 ............................ 65

Figure 40 : Navigation sur Internet à partir d’une machine du VLAN 10 ................................... 65

Figure 41 : Requête ICMP à partir d'une machine appartenant au VLAN 99 ............................ 66

Figure 42 : Navigation sur Internet à partir d’une machine du VLAN 99 ................................... 66

Figure 43 : Création d’un nouvel utilisateur AD .............................................................................. 69

Figure 44 : Modification du domaine ................................................................................................ 69

Figure 45 : Modification du nom de l’ordinateur ............................................................................. 70

Figure 46 : Authentification réussie ................................................................................................... 70

Figure 47 : Principe de fonctionnement NPS+ADCS .................................................................... 70

Figure 48 : Création de connexion sans fils sécurisée ..................................................................... 71

Figure 49 : Ajout de client Radius ...................................................................................................... 71

Figure 50 : Choix de la méthode d'authentification ......................................................................... 72

Figure 51 : Ajout de groupe ................................................................................................................ 72

Figure 52 : Ajout d'un modèle de certificat....................................................................................... 73

Figure 53 : Ajout de certificat ............................................................................................................. 73

Figure 54 : Ajout d'une autorité de certificat .................................................................................... 74

Figure 55 : Paramétrage d'un nouveau certificat .............................................................................. 74

Figure 56 : Modification de nom de sujet ......................................................................................... 75

Figure 57 : Demande d’un certificat .................................................................................................. 75

Figure 58 : Inscription au certificat .................................................................................................... 76

Figure 59 : Demande d'authentification ............................................................................................ 77

Figure 60 : Propriété de sécurité du client ........................................................................................ 77

Figure 61 : Client connecté ................................................................................................................. 78


Figure 63 : Les interfaces du firewall ................................................................................................. 80

Figure 64 : Page de configuration des règles .................................................................................... 81

Figure 65 : Liste des règles de l'interface WAN ............................................................................... 82

Figure 66 : Liste des règles de l'interface LAN................................................................................. 82


Sana AFLI, Nadine HRIRA Page | x

Figure 67 : Liste des règles de l'interface DMZ ............................................................................... 82

Figure 68 : Activation du portail captif ............................................................................................. 83

Figure 69 : Modification de la page d'accueil du portail .................................................................. 84

Figure 70 : Gestion des utilisateurs par FreeRADIUS .................................................................... 85

Figure 71 : Création de client NAS .................................................................................................... 85

Figure 72 : Activation de HTTPS pour l'accès au webguid ............................................................ 86

Figure 73 : Choix du type de certificat .............................................................................................. 87

Figure 74 : Paramètres du certificat ................................................................................................... 87

Figure 75 : Activation de SSL pour le portail captif ........................................................................ 88


Figure 77 : Packages Squid et SquidGuard ....................................................................................... 89

Figure 78 : Configuration de Squid .................................................................................................... 90

Figure 79 : Téléchargement du blacklist ............................................................................................ 90

Figure 80 : Blocage des catégories ...................................................................................................... 91

Figure 81 : Empêchement de la connexion par le proxy ................................................................ 91

Figure 82 : Changement de SSID ....................................................................................................... 92

Figure 83 : Filtrage des adresses MAC .............................................................................................. 93

Figure 85 : Scénario d'attaque ............................................................................................................. 93

Figure 86 : Liste des interfaces sans fil .............................................................................................. 94

Figure 87 : Activation du mode moniteur ......................................................................................... 94

Figure 88 : Scan du réseau ................................................................................................................... 95

Figure 89 : Capture de trafic sur le réseau sans fil "Employer" ..................................................... 95

Figure 90 : Capture du mot de passe ................................................................................................. 96

Figure 91 : Mot de passe en clair ........................................................................................................ 96

Figure 92 : Liste des cartes virtuelles ................................................................................................ A1

Figure 93 : Choix du mode d'accès réseau ....................................................................................... A2

Figure 94 : Propriété de la carte réseau en IPv4 .............................................................................. A3

Figure 95 : Configuration de la carte réseau du nuage ................................................................... A4

Figure 96 : Liaison entre le nuage de PFsense et le routeur Core_ex .......................................... A4

Figure 97 : Configuration de la carte réseau du nuage ................................................................... A5

Figure 98 : Liaison entre le nuage Internet et R1 ............................................................................ A5

Figure 99 : Maquette de la solution générale ................................................................................... A6

Figure 100 : Les machines virtuelles sous l'environnement VirtualBox ...................................... A6


Sana AFLI, Nadine HRIRA Page | xi

Liste des tableaux

Tableau 1 : Plan d'adressage ................................................................................................................ 30

Tableau 2 : Mappages de ports et configuration des réseaux locaux virtuels .............................. 31

Tableau 3 : Affectation des ports ....................................................................................................... 31

Tableau 4 : Affectation du port channel ........................................................................................... 31

Tableau 5 : Adressage des serveurs .................................................................................................... 31

Tableau 6 : Adressage des hôtes ......................................................................................................... 32


Sana AFLI, Nadine HRIRA Page | xii

Liste des acronymes

VLAN Virtual Local Area Network

PAgP Port Aggregation Protocol

LACP Link Aggregation Protocol

STP Spanning Tree Protocol

HSRP Hot Standby Router Protocol

VRRP Virtual Router Redundancy Protocol

GLBP Gateway Load Balancing Protocol

EIGRP Enhanced Interior Gateway Routing Protocol

WEP Wired Equivalent Privacy

WPA Wi-Fi Protected Access

EAP Extensible Authentication Protocol

PEAP Protected Extensible Authentication Protocol

RADIUS Remote Authentication Dial-In User Service

MS-CHAP v2 Microsoft Challenge Handshake Authentication Protocol version 2

ADCS Active Directory Certificate Services

NPS Network Policy Server

NAS Network Access Server

DMZ Demilitarized Zone

http://windows.microsoft.com/fr-fr/windows/what-are-wireless-network-security-methods



Sana AFLI, Nadine HRIRA Page 1 sur 99

Introduction générale

Dans le monde de l'entreprise, la technologie de réseau sans fil (WLAN) fait l'objet de

nombreuses controverses. La plupart des entreprises ont d'ores et déjà déployé un WLAN ou

équivalent, ou au moins débattu des avantages et des inconvénients de la technologie sans fil.

Dans tous les cas, les entreprises qui ont déployé des réseaux sans fil sont préoccupées par la

sécurité de leur réseau et celles qui ont évité cette technologie s'interrogent quant aux gains de

productivité et aux économies d'infrastructure qu'elles auraient pu réaliser.

C'est sous cette optique que nous nous proposons de concevoir et de déployer, au niveau de

ce PFP, un réseau de campus de petite taille avec le support de clients sans fil où la mise en

place de mesures de sécurité sans fil est l'un des objectifs primordiaux à atteindre dans ce

projet.

Il est exigé que l'architecture réseau à mettre en place soit évolutive, redondante, disponible,

facile à gérer et à maintenir. Les clients sans fil qui vont s'y connecter peuvent avoir des droits

d'accès différents, cela dépend de leur profil : ce sont ou bien des clients internes au réseau ou

bien des clients invités. Plusieurs méthodes d'authentification pour l'accès au réseau seront

considérées, étudiées et évaluées.

Ce présent rapport sera structuré en trois grands chapitres :

Le premier chapitre présente un état de l’art dans lequel nous allons évoquer toutes les

notions théoriques qui serviront à la bonne conception de notre architecture réseau et à la

mise en place d'une politique de sécurité efficace.

Le deuxième chapitre détaillera la conception et l’implémentation de notre maquette

réseau.

Le troisième chapitre sera consacré à la description de la phase de déploiement des

services réseau (serveurs de l’entreprise) et des techniques de sécurisation employées. Il

contiendra au final à une évaluation du niveau de sécurité de notre maquette.

Nous finirons par une conclusion générale qui synthétisera le travail réalisé.



CHAPITRE I : ETAT DE L’ART



Introduction

Comme tout projet réseau, il est important de commencer par une étude approfondie sur les

technologies à exploiter et à mettre en œuvre dans la maquette réseau finale. En nous référant

au cahier des charges, nous avons axé notre étude sur un ensemble de services réseau qu'il est

utile de déployer dans un LAN ainsi que sur les technologies qu'on applique dans les LAN

modernes afin de répondre aux besoins en terme d'évolutivité, de mobilité, de redondance et

de sécurité.

L'accent a été mis en particulier sur l'aspect sécurité des réseaux sans fil puisque la finalité de

notre projet est de proposer et d'étudier des solutions d'accès sans fil sécurisé pour un LAN

commuté.

I.1 Les architectures réseaux commutées

I.1.1 Le modèle de réseau hiérarchique

I.1.1.1 Motivations

Les modèles de réseaux semblent se conformer à l'une ou l'autre des deux structures générales

de conception : maillée ou hiérarchique. Dans une structure maillée, la topologie du réseau est

linéaire. Tous les routeurs remplissent essentiellement les mêmes fonctions et il n'existe

généralement pas de définition précise des fonctions exécutées par chaque routeur.

L'expansion du réseau s'effectue au hasard et de façon arbitraire. Dans une structure

hiérarchique, le réseau est divisé en couches. Une ou plusieurs fonctions précises sont

associées à chaque couche.

Voici quelques-uns des avantages que procure l'utilisation d'un modèle hiérarchique :

L'évolutivité : Les réseaux créés selon le modèle hiérarchique peuvent connaître une

croissance plus forte, sans effet négatif sur le contrôle et la facilité de gestion, parce que les

fonctionnalités sont localisées et il est plus facile de détecter les problèmes qui surviennent. Le

réseau téléphonique public commuté est un exemple de réseau hiérarchique à très grande

échelle.

La facilité de mise en œuvre : Puisqu'un modèle hiérarchique attribue des fonctionnalités

précises à chaque couche, la mise en œuvre du réseau s'en trouve facilitée.



La facilité de dépannage : Les fonctions de chaque couche étant clairement définies, il

devient plus facile d'isoler les problèmes qui peuvent survenir sur le réseau. Il est également

plus facile de segmenter temporairement le réseau pour réduire l'étendue d'un problème.

La prévisibilité : Il est relativement facile de prévoir le comportement d'un réseau utilisant

des couches fonctionnelles. La planification de la capacité de croissance du réseau s'en trouve

considérablement simplifiée, tout comme la modélisation des performances du réseau à des

fins d'analyse.

La prise en charge de protocoles : La combinaison d'applications et de protocoles actuels et

futurs est beaucoup plus facile sur des réseaux créés selon un modèle hiérarchique, en raison

de l'organisation logique de l'infrastructure sous-jacente.

La facilité de gestion : Tous les avantages énumérés ci-dessus rendent le réseau plus facile à

gérer.

I.1.1.2 Structuration

Plus généralement nommé par sa version anglaise, « tree-layers hierarchical internet working

design/model », ce modèle a été inventé et diffusé par Cisco.

Le principe est simple, c’est de créer un design réseau structuré en trois couches (layers),

chacune ayant un rôle précis impliquant des différences de matériel, performances et outils

(voir figure 1).

Ces trois couches sont :

La couche cœur « Core layer »

La couche distribution « Distribution layer »

La couche accès « Access layer »

Figure 1 : Le modèle de réseau hiérarchique



Couche Accès

C’est la dernière couche du modèle. Son rôle est simple mais très important : connecter les

périphériques « end-users » au réseau et assurer aussi la sécurité. Il n'y a pas de routeur au

niveau de cette couche, seuls des switchs, et des hubs, sont implémentés. On ne s’occupe que

de connecter les utilisateurs finaux au réseau, que ce soit en Wifi, Ethernet ou autre.

Couche Distribution

La couche distribution du réseau constitue le point de démarcation entre la couche principale

et la couche accès. Elle peut remplir plusieurs fonctions, notamment :

le regroupement d'adresses ou de zones

l'accès à la couche principale par un service ou un groupe de travail

la définition des domaines de diffusion et de diffusion multipoint

le routage des réseaux locaux virtuels

la conversion de médias, si nécessaire

la sécurité

Couche Cœur

C’est la couche supérieure. Son rôle est de relier entre eux les différents segments du réseau,

par exemple les sites distants, les LANs ou les étages d’une société.

Nous trouvons généralement les routeurs à ce niveau.

I.1.2 La commutation au niveau 2

Un commutateur de niveau 2 est similaire à un concentrateur dans le sens où il fournit un

seul domaine de diffusion. En revanche, chaque port a son propre domaine de collision. Le

commutateur utilise la micro-segmentation pour diviser les domaines de collision, un par

segment connecté. Ainsi, seules les interfaces réseau directement connectées par un lien point

à point sollicitent le medium. Si le commutateur auquel il est connecté supporte le full-duplex,

le domaine de collision est entièrement éliminé.

http://fr.wikipedia.org/wiki/Hub_Ethernet

http://fr.wikipedia.org/wiki/Domaine_de_diffusion

http://fr.wikipedia.org/wiki/Domaine_de_collision

http://fr.wikipedia.org/wiki/Full-duplex

http://fr.wikipedia.org/wiki/Domaine_de_collision



I.1.3 La commutation au niveau 3

La plupart des switchs opèrent la commutation au niveau 2 du modèle OSI. Cependant,

certains switchs embarquent aussi des fonctionnalités de niveau 3. Comme nous allons le voir,

la distinction entre la commutation de niveau 3 (switchs de niveau 3) et le routage (routeurs)

est très fine.

Lorsqu’un routeur reçoit un paquet, il regarde à la couche 3 les adresses source et destination

afin de déterminer le meilleur chemin entre ces 2 points. Un switch standard, donc de niveau

2, s’appuie sur les adresses MAC émettrices et destinataires.

La différence fondamentale entre un routeur et un switch de niveau 3 est que ce dernier

embarque une couche matérielle optimisée pour passer les données aussi vite qu’au niveau 2.

Mais la décision vers où transmettre le paquet se prend au niveau 3. La commutation étant

plus rapide que le routage (car c’est matériel et non logiciel), les switchs de niveau 3 sont plus

rapides que les routeurs. Cependant, les switchs, qu’ils soient de niveaux 2 ou 3, ne peuvent

être utilisés que sur des LAN.

La conception interne des switchs de niveau 3 est similaire à celle des routeurs. Les 2 utilisent

un protocole de routage et une table de routage pour déterminer le meilleur chemin.

Cependant, un switch de niveau 3 a la capacité de reprogrammer la couche matérielle

dynamiquement avec les informations de routage de niveau 3 courantes. C’est cela qui lui

permet de traiter plus rapidement les paquets. Actuellement dans les switchs de niveau 3, les

informations reçues des protocoles de routage sont utilisées pour mettre à jour les tables de

cache de la couche matérielle.

I.1.4 Technologie d'agrégation de liens

I.1.4.1 Définition

L'agrégation de liens est une notion de réseau informatique décrivant le regroupement de

plusieurs ports réseau comme s'il s'agissait d'un seul. Le but est d'accroitre le débit au-delà des

limites d'un seul lien, et éventuellement de faire en sorte que les autres ports prennent le relai

si un lien tombe en panne (redondance).

http://fr.wikipedia.org/wiki/R%C3%A9seau_informatique

http://fr.wikipedia.org/wiki/Port_mat%C3%A9riel



Les liens d’agrégations permettent d’augmenter le débit, mais aussi la redondance des liens en

cas de panne d’une liaison entre équipements. On peut mettre en place un lien d’agrégation

entre différents équipements, tels que les commutateurs, les routeurs mais aussi les serveurs.

I.1.4.2 Avantages

Cette technologie présente plusieurs avantages, dont nous citons :

l'évolution de la bande passante

Les besoins en bande passante n'évoluent pas de manière linéaire. Historiquement, les débits

disponibles en Ethernet ont augmenté d'un facteur 10 à chaque génération

(10 Mbit/s, 100 Mb/s, 1 000 Mb/s, 10 000 Mb/s). Si l'on se trouve proche d'un seuil, la seule

solution consistait à migrer vers la nouvelle génération, le plus souvent avec un coût prohibitif.

La solution alternative, introduite par la plupart des constructeurs réseaux au début des années

1990, consiste à associer deux liens Ethernet physiques en un lien logique via le « Channel

Bonding ». La plupart de ces solutions requièrent une configuration manuelle.

le renforcement de la disponibilité

La connexion de deux équipements via un lien implique trois points individuels de

défaillance : les deux ports et le lien lui-même, que ce soit dans le contexte d'un raccordement

d'un ordinateur à un commutateur, ou dans le contexte de connexion de deux commutateurs.

Plusieurs connexions physiques peuvent être mises en place, cependant, beaucoup de

protocoles de niveaux supérieurs n'ont pas été conçus de manière à basculer de manière

totalement transparente en cas de dysfonctionnement.

I.1.4.3 Agrégation de liens avec EtherChannel

I.1.4.3.1 Définition

La technologie Cisco Etherchannel permet d’agréger plusieurs liens afin d’augmenter la bande-

passante entre deux commutateurs. Cette technologie existe – sous d’autres appellations –

chez d’autres constructeurs et peut même être utilisée entre un serveur et son commutateur

d’accès.

http://fr.wikipedia.org/wiki/Point_individuel_de_d%C3%A9faillance

http://fr.wikipedia.org/wiki/Point_individuel_de_d%C3%A9faillance



Figure 2 : Agrégation de liens avec EtherChannel

I.1.4.3.2 Fonctionnalités offertes

La technologie EtherChannel permet d’exploiter des liens redondants entre commutateurs,

routeurs et serveurs. Elle peut également permettre d’augmenter le débit entre équipements.

EtherChannel gère automatiquement les pannes éventuelles de liens physiques en redistribuant

la charge sur les liens qui restent fonctionnels – cela sans interruption de services.

Généralement, un lien entre deux commutateurs est un lien en mode trunk. Il s’agit de liens

Ethernet classiques mais qui peuvent transporter des trames de VLANs différents. Pour cela,

chaque trame est taguée avec une étiquette de VLAN – on parle d’étiquette ou de tag

802.1q en référence au standard qui normalise ce format de trame Ethernet.

L’agrégation de lien consiste à créer un groupe de plusieurs liens physiques (voir figure 3) . Les

liens agrégés peuvent être en mode access ou en mode trunk mais les liens d’un même

groupe doivent tous être du même type (soit access, soit trunk). Enfin un lien agrégé peut

éventuellement être un port routé (de niveau 3).

Le mécanisme d’agrégation de lien consiste donc à créer un lien virtuel composé de plusieurs

liens physiques.

Figure 3 : Agrégat EtherChannel



Ainsi, la bande-passante de ce nouveau lien virtuel correspond à la somme des bandes

passantes des liens physiques qui composent le lien virtuel. L’agrégat est vu comme un lien

unique même s’il ne s’agit que d’un lien logique.

Contrairement au protocole spanning-tree, tous les liens physiques sont simultanément utilisés

par une répartition de la charge sur les différents liens physiques.

Le partage de charge est réalisé sur la base des adresses MAC de la trame qui doit traverser le

lien logique (c’est-à-dire l’agrégat). Ceci permet de résoudre le problème des boucles Ethernet

de façon plus efficace que le spanning-tree puisque ce dernier conduit à désactiver

logiquement des liens qui ne sont pas utilisés en situation normale. Avec l’agrégation de liens,

tous les liens sont simultanément utilisés en situation normale (sans panne).

I.1.4.3.3 Terminologie et vocabulaire spécifiques

Le Port-Channel (ou Channel-Group) est l’appellation donnée au lien logique (ou à

l’agrégat). La configuration de certains attributs du lien logique se fait sous une

nouvelle interface virtuelle qui est créée simultanément avec l’agrégat.

Les member interfaces sont les interfaces physiques qui appartiennent au même

agrégat (donc au même Port-Channel). En environnement Cisco, tous les liens

membres d’un agrégat doivent avoir les mêmes caractéristiques et configurations, c’est

à dire :

même type d’interface physique (par exemple, uniquement des ports 100 Mbps cuivre

ou que des ports fibres 10Gbps, etc).

même mode de transmission (duplex par exemple).

même configuration de VLANs (mode d’encapsulation, VLAN natif, VLANs

supportés sur les interfaces).

I.1.4.3.4 Protocole de négociation

La création d’un port-channel peut être préalablement négociée entre les deux équipements.

Pour cela, deux protocoles de négociation peuvent être définis sur les équipements Cisco :

Port Aggregation Protocol (PAgP) est un protocole propriétaire Cisco, de ce fait

disponible sur les commutateurs Cisco ainsi que sur les équipements disposant de la

licence adéquate. Son utilisation permet de faciliter et d'automatiser la configuration



des agrégats de liens (EtherChannel chez Cisco) en échangeant les informations

nécessaires entre les ports Ethernet.

PAgP utilise 3 modes au niveau des ports:

o Auto (mode par défaut): le port attend une requête du port voisin.

o Desirable : le port négocie avec le port voisin.

o On: le port ne prévient pas et ne négocie pas avec l’autre.

Link Aggregation Protocol (LACP) est un protocole standardisé par l'IEEE qui est

implémenté par différents constructeurs. Le principe de fonctionnement consiste à

émettre des paquets LACP vers l'équipement partenaire, directement connecté et

configuré pour utiliser LACP. Le mécanisme LACP va permettre d'identifier si

l'équipement en face supporte LACP, et groupera les ports configurés de manière

similaires (vitesse, mode duplex, VLAN, trunk de vlan, etc.)

Un équipement configuré pour utiliser LACP peut fonctionner en trois modes :

o Passif : l'équipement n'initiera pas de négociation LACP. Il répondra uniquement aux

sollicitations des équipements « partenaires ».

o Actif : l'équipement initiera les négociations LACP.

o On : l'équipement suppose que l'équipement partenaire est également dans ce mode et

fera de l'agrégation de liens

Ces deux protocoles de négociation sont totalement incompatibles. Il est donc impossible

d’utiliser PAgP sur un équipement et LACP sur l’autre équipement. Soulignons également que

la négociation préalable à l’établissement d’un agrégat est un processus facultatif (non

obligatoire pour créer un port-channel). La désactivation de cette négociation se fait en

configurant, sur l’équipement Cisco, le mode « on ».

L’intérêt de la négociation consiste essentiellement à vérifier qu’il n’y a pas de problèmes

susceptibles de conduire à une boucle réseau Ethernet.



I.1.5 La redondance de niveau 2

I.1.5.1 Le STP (Spanning Tree)

Pour prévenir les tempêtes de diffusion et autres effets de bords de boucles sur le réseau,

Digital Equipment Coporation créa le spanning-tree Protocol (STP) qui fut ensuite standardisé

par l’IEEE (Institute of Electrical and Electronic Engineers) comme norme 802.1d. Le STP

utilise le spanning-tree algorithm (STA) qui prend en compte le fait qu’un switch puisse avoir

plus d’un seul chemin pour atteindre un destinataire.

Il détermine alors le chemin optimal et bloque l’utilisation des autres chemins. Cependant, il

garde en mémoire les autres chemins au cas où le premier serait défaillant.

I.1.6 La redondance de niveau 3

I.1.6.1 La redondance de passerelle avec HSRP (Hot Standby

Router Protocol)

Le protocole HSRP est un protocole propriétaire Cisco. Il permet de gérer la redondance de

routeur (ou commutateur de niveau 3) pour que lorsqu’un routeur tombe en panne, un

routeur de secours prenne le relais. HSRP permet d’augmenter la tolérance de panne sur un

réseau en créant un routeur virtuel à partir de 2 routeurs physiques (ou plus), une élection

déterminera le routeur actif et les autres routeurs seront en "attente" (standby). L’élection du

routeur actif est réalisée grâce à la priorité configurée sur chaque routeur. [2]

Principe de fonctionnement du HSRP

En pratique, HSRP permet qu’un routeur de secours prenne immédiatement, de façon

transparente, le relais dès qu’un problème physique apparaît.

En partageant une seule et même adresse IP et MAC, plusieurs routeurs peuvent être

considérés comme un seul routeur “Virtuel”. Les membres du groupe de ce routeur virtuel

sont capables de s’échanger (par multicast) des messages d’état et des informations.

Un routeur physique peut donc être “responsable” du routage et un autre en redondance. Si le

routeur, que nous appellerons primaire, a un problème, le routeur secondaire prendra sa place

automatiquement. Les paquets continueront de transiter de façon transparente car les 2

routeurs partagent les mêmes adresses IP et MAC.



Un groupe de routeurs va négocier au sein d’un même groupe HSRP (ou standby group), un

routeur primaire (Active router), élu au moyen d’une priorité, pour transmettre les paquets

envoyés au routeur virtuel. Un autre routeur, le routeur secondaire (Standby router), sera élu

lui aussi afin de remplacer le routeur primaire en cas de problème. Le secondaire assumera

donc la tâche de transmettre les paquets à la place du primaire en cas de défaillance.

Le processus d’élection se déroule pendant la mise en place des liens, une fois ce processus

terminé, seul le routeur primaire (Active) va envoyer des messages HSRP multicast en UDP

aux autres afin de minimiser le trafic réseau. Si ces messages ne sont plus reçus par le routeur

secondaire (Standby), c’est que le routeur primaire a un problème et le secondaire devient

donc actif.

I.1.6.2 Le protocole VRRP (Virtual Router Redundancy

Protocol)

Le VRRP (protocole de redondance de routeur virtuel) est un protocole standard dont le but

est d'augmenter la disponibilité de la passerelle par défaut des hôtes d'un même réseau.

VRRP est très semblable à HSRP, sauf qu’il est standard. Il y a quelques différences mineures,

tels que les Timers qui ont été réduits. [3]

Principe de fonctionnement du VRRP

Ce protocole a pour but de redonder la Gateway d’un sous-réseau. Deux routeurs (ou plus)

fonctionneront ensemble, l’un sera le routeur principal, qui sera utilisé pour router le trafic. Le

deuxième sera là pour prendre le relai en cas de panne du premier.

En VRRP, le groupe de routeur est appelé le VRRP group.

Les routeurs peuvent avoir deux rôles contrairement à HSRP, plusieurs routeurs peuvent avoir

le rôle Backup. Ces deux rôles sont :

Master (Actif en HSRP)

Backup (Standby en HSRP)

http://fr.wikipedia.org/wiki/Disponibilit%C3%A9

http://fr.wikipedia.org/wiki/Passerelle_(informatique)



I.1.6.3 Le protocole GLBP (Gateway Load Balancing Protocol)

Gateway Load Balancing Protocol est un protocole propriétaire Cisco qui reprend les

concepts de base de HSRP et VRRP mais qui permet aussi de faire de la répartition de charge

sur plusieurs routeurs utilisant une seule adresse IP virtuelle, mais plusieurs adresses MAC

virtuelles.

Contrairement à ces 2 protocoles, tous les routeurs du groupe GLBP participent activement

au routage alors que dans VRRP ou HSRP, il n’y en a qu’un qui est en mode actif, tandis que

les autres patientent.

Le protocole GLBP élit un Active Virtual Gateway (AVG) qui va répondre aux requêtes ARP

pour l’adresse IP virtuelle. GLBP permet de donner un poids variable à chacun des routeurs

participants pour la répartition de la charge entre ces routeurs. La charge est donc répartie par

hôte dans le sous-réseau. [4]

I.2 Sécurisation des réseaux sans fil

I.2.1 Les réseaux locaux sans fil

La plupart des réseaux d’entreprise actuels reposent sur des réseaux locaux avec commutateurs

pour les opérations quotidiennes à l’intérieur du bureau. Toutefois, les employés, de plus en

plus mobiles, entendent pouvoir accéder aux ressources LAN de l’entreprise ailleurs que

depuis leur propre bureau. Les employés sédentaires souhaitent pouvoir emmener leur

ordinateur portable aux réunions ou dans le bureau d’un collègue. Lorsqu’il s’agit d’utiliser un

ordinateur portable dans un autre lieu, compter sur une connexion filaire est une source de

désagrément. C'est là que les réseaux sans fil (WLAN) prennent toute leur importance.

Combiner des technologies sans fil sur différents types de réseaux est un gage de mobilité

pour les employés.

Ainsi un réseau local sans fil est une extension du réseau local Ethernet. Le réseau local a

évolué pour devenir mobile. La figure ci-dessous (figure 4) illustre les normes de technologies

sans fil existantes :



Figure 4 : Les réseaux locaux sans fil

I.2.2 La sécurité Wi-Fi

La sécurité doit être une priorité pour tout utilisateur ou administrateur de réseaux. La

difficulté de préserver la sécurité d’un réseau filaire est amplifiée avec un réseau sans fil. Un

réseau local sans fil est ouvert à toute personne qui se trouve à portée d’un point d’accès et qui

dispose des identifiants appropriés pour s’y associer.

Nous présentons dans cette partie les méthodes de sécurité et les méthodes d’authentification

pour les LAN WiFi.

I.2.2.1 Les protocoles de sécurité

Pour assurer la sécurité des liaisons Wi-Fi, il existe des protocoles de cryptage. Nous citons

WEP, WPA et WPA2.

I.2.2.1.1 WEP (Wired Equivalent Privacy)

WEP est la méthode de sécurité réseau la plus ancienne qui est encore disponible pour

prendre en charge des périphériques anciens. Son utilisation n’est cependant plus

recommandée. Lorsque vous activez WEP, vous configurez une clé de sécurité réseau. Cette

clé chiffre les informations envoyées par un ordinateur à un autre sur le réseau. Cependant, la

sécurité WEP est relativement facile à déchiffrer.




Il existe deux types de WEP : l’authentification OSA (Open System Authentification) et

l’authentification par clé partagée. Aucune n’est très sûre, mais l’authentification par clé

partagée est la moins sûre des deux. Pour la plupart des ordinateurs sans fil et des points

d’accès sans fil, la clé d’authentification par clé partagée est identique à la clé de chiffrement

WEP statique (la clé utilisée pour sécuriser votre réseau). Un utilisateur malveillant qui capture

les messages relatifs à une authentification par clé partagée peut utiliser des outils d’analyse

pour déterminer la clé d’authentification par clé.

I.2.2.1.2 Wi-Fi Protected Access (WPA et WPA2)

WPA chiffre les informations et vérifie que la clé de sécurité réseau n’a pas été modifiée. Par

ailleurs, WPA authentifie les utilisateurs pour garantir que seules les personnes autorisées

peuvent accéder au réseau.

Il existe deux types d’authentification WPA : WPA et WPA2.

WPA est conçu pour fonctionner avec toutes les cartes réseau sans fil, mais peut ne pas

fonctionner avec des routeurs ou des points d’accès plus anciens.

WPA2 est plus sûr que WPA, mais ne fonctionnera pas avec certaines cartes réseau anciennes.

WPA est conçu pour fonctionner avec un serveur d’authentification 802.1X qui distribue des

clés différentes pour chaque utilisateur. On parle de WPA-Enterprise ou WPA2-Enterprise.

Il peut également être utilisé en mode de clé pré-partagée (PSK), où un mot de passe identique

est attribué à chaque utilisateur. On parle de WPA-Personal ou WPA2-Personal.

Les deux versions de Wi-Fi Protected Access (WPA / WPA2) peuvent être mises en œuvre

dans un des deux modes :

WPA-Personal ou WPA2-Personal :

WPA-Personal ou WPA-PSK (Pre-Shared Key): ce mode est approprié pour la plupart des

réseaux domestiques. Quand un mot de passe est défini sur un routeur sans fil ou un point

d'accès (AP), il doit être saisi par les utilisateurs lors de la connexion au réseau Wi-Fi.




Figure 5 : WPA-Personal ou WPA2-Personal

WPA-Enterprise ou WPA2-Enterprise :

WPA-Enterprise est conçu pour les réseaux d'entreprise et nécessite un serveur

d'authentification RADIUS. Cela nécessite une configuration plus compliquée, mais offre une

sécurité supplémentaire (par exemple de la protection contre les attaques par dictionnaire sur

les mots de passe courts).

Figure 6 : WPA-Enterprise ou WPA2-Enterprise

I.2.2.2 Les méthodes d'authentification

Il existe aujourd'hui divers méthodes d’authentification telles que :

I.2.2.2.1 EAP (Extensible Authentication Protocol)

Il s'agit d'une méthode de communication réseau pouvant être utilisé sur les liaisons point à

point, les réseaux filaires et les réseaux sans fil tel que les réseaux Wi-Fi.

http://translate.googleusercontent.com/translate_c?depth=1&hl=fr&prev=search&rurl=translate.google.fr&sl=en&u=http://en.wikipedia.org/wiki/RADIUS&usg=ALkJrhhGOG3NhE_qI0s1uU26exqIsGf_9A

http://fr.wikipedia.org/wiki/Protocole_point_%C3%A0_point

http://fr.wikipedia.org/wiki/Protocole_point_%C3%A0_point

http://fr.wikipedia.org/wiki/R%C3%A9seau_informatique

http://fr.wikipedia.org/wiki/R%C3%A9seau_sans_fil

http://fr.wikipedia.org/wiki/Wi-Fi



I.2.2.2.2 PEAP (Protected Extensible Authentication Protocol)

Il s'agit d'un nouveau membre de la famille de protocoles EAP (Extensible Authentication

Protocol). Le protocole PEAP utilise la sécurité TLS (Transport Level Security) pour créer un

canal crypté entre un client PEAP d'authentification, tel qu'un ordinateur sans fil, et un

authentificateur PEAP, tel qu'un serveur IAS (Internet Authentication Service) ou RADIUS

(Remote Authentication Dial-In User Service). [5]

Le protocole PEAP ne spécifie aucune méthode d'authentification, mais il fournit une sécurité

supplémentaire pour d'autres protocoles d'authentification EAP, notamment le protocole

EAP-MSCHAPv2, qui peut opérer par l'intermédiaire du canal crypté TLS fourni par le

protocole PEAP. Le protocole PEAP est utilisé comme méthode d'authentification pour les

ordinateurs clients sans fil 802.11, mais il n'est pas pris en charge pour les clients de réseau

privé virtuel (VPN, Virtual Private Network) ni pour les autres clients d'accès distant.

Le protocole MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol

version 2) est un protocole d'authentification par mot de passe.

Figure 7 : Le protocole MS-CHAP

I.2.2.3 Les portails captifs

I.2.2.3.1 Définition

Un portail captif est une infrastructure qui redirige les connexions HTTP des utilisateurs vers

une page d’authentification. Le portail captif propose à l’utilisateur d’entrer un nom et un mot

de passe, qui lui permettra d’accéder à une ressource en fonction de son statut. Cette page



d’authentification est stockée sur le portail captif, que l’on accède via un navigateur web. Les

identifiants de connexion (nom et mot de passe) sont stockés dans une base de données locale

ou à travers un serveur distant via le protocole RADIUS (Remote Authentication Dial-In User

Service). Quand l’utilisateur est connecté, le portail captif autorise la connexion pour une

durée déterminée, sinon celui-ci ne peut pas se connecter. Ce type d’infrastructure est

particulièrement bien adapté dans le cadre de réseaux sans-fil.

Dans la pratique, il existe plusieurs solutions pour déployer un portail Captif dont pfSense,

auquel nous allons nous intéresser en particulier dans notre projet.

Figure 8 : Principe du portail captif



Figure 9 : Fonctionnement de portail captif

I.2.2.4 Les proxys

I.2.2.4.1 Squid

Squid est un serveur mandataire, en anglais un proxy, entièrement libre et très performant.

Squid est capable de gérer les protocoles FTP, HTTP, HTTPS et Gopher. Il est généralement

utilisé dans certaines entreprises et universités pour des fonctions de filtrage d'URL ou en tant

que tampon. Les pages Internet sont stockées localement ce qui évite d'aller les recharger

plusieurs fois et permet d'économiser la bande passante Internet. [6]

I.2.2.4.2 SquidGuard

SquidGuard est un outil permettant de filtrer les pages web en se servant des URI (Uniform

Resource Identifier) et, éventuellement, des noms d'utilisateurs, si l'on fait de l'authentification

de ces derniers.

http://fr.wikipedia.org/wiki/Uniform_Resource_Identifier



SquidGuard utilise lors du filtre des URLs regroupées en listes blanches et listes noires. Une

liste noire est une liste de sites interdits. On va donc filtrer l'accès à Internet via cette liste

noire. Si l'utilisateur essaie de se connecter à l'un des sites contenus dans cette liste, il sera

redirigé vers une page choisie.

Une liste blanche permet d'accéder aux adresses qu'elle contient, qui sont considérées comme

valides. L'inconvénient de ce genre de filtrage repose sur des défauts dans la mise-à-jour de ces

listes, puisque des URLs non valides se créent chaque jour, et que SquidGuard peut

difficilement les prendre en compte. De même on peut passer par un proxy HTTP et

contourner de ce fait le filtrage mis en place par SquidGuard.

I.2.3 La sécurité au niveau applicatif

I.2.3.1 Les annuaires 

Un annuaire est une base de données spécialisée conçue pour des interrogations fréquentes

mais avec des mises à jour moins fréquentes. Au contraire des bases de données générales, il

ne comprend pas de prise en charge des transactions ou de fonctionnalités de retour en

arrière. Les annuaires sont facilement répliqués pour en augmenter la disponibilité et la

fiabilité. Lorsque les annuaires sont répliqués, des incohérences temporaires sont autorisées

jusqu'à ce qu'elles soient synchronisées à la fin. [7]

I.2.3.1.1 Active Directory

Active Directory est le service d'annuaire fourni par Windows 2000 Server (et par d'autres

versions de Windows Server). Il est sécurisé, distribué, partitionné et dupliqué. Il a été conçu

pour fonctionner correctement quelle que soit la taille de l'installation, d'un serveur unique

comportant quelques centaines d'objets à un ensemble de milliers de serveurs et de millions

d'objets.

Active Directory offre nombre de nouvelles fonctionnalités qui rendent aisée la navigation

parmi d'importants volumes d'informations et facilitent leur gestion, en permettant des gains

de temps importants tant pour les administrateurs que pour les utilisateurs finals. [8]



Figure 10 : Active directory

I.2.3.1.2 Active Directory Certificate Services

Active Directory Certificate Services ou L'ADCS est un rôle d'Active Directory proposant

différents services configurables pour créer et gérer des clés et certificats utilisés pour la

protection des logiciels. Cela signifie qu'ADCS est très utilisé par les entreprises afin améliorer

la sécurité. En effet, grâce à ADCS nous allons pouvoir lier facilement un utilisateur ou un

périphérique à une clé privée qui lui correspondra. Pour une organisation ayant besoin

d'utiliser de nombreux certificats afin de protéger un grand nombre de données, gérer ses

certificats de manière non centralisée peut vite s'avérer être une tâche problématique voir

même impossible. ADCS se présente donc comme un produit efficace pour gérer l'utilisation

de certificats de manière centralisée et sécurisée. [9]

ADCS prend en charge de nombreuses applications utilisés pour les réseaux (se trouvant ou

non sur internet). Les différents services proposés par ADCS peuvent être installés sur un

unique serveur ou sur plusieurs serveurs selon les besoins d'une organisation.

Ces services sont:

- Le répondeur en ligne: Ce service est basé sur le protocole OSCP (Online Certificate Status

Protocol) qui est un protocole Internet utilisé pour valider un certificat numérique. Il est utilisé

pour demander l'état des certificats et recevoir une réponse signée. C'est grâce à l'utilisation du

protocole OSCP qu'il est possible de recevoir uniquement les informations dont l'utilisateur a

besoin.

http://fr.wikipedia.org/wiki/Protocole_de_communication

http://fr.wikipedia.org/wiki/Certificat_num%C3%A9rique



- Les autorités de certification: Elles servent à émettre des certificats aux utilisateurs,

ordinateurs, services et permettent ainsi de vérifier la validité des certificats.

- L'inscription d'autorité de certification Web: Elle permet aux utilisateurs de demander des

certificats directement via le Web.

- Services de périphériques réseau: Cette fonctionnalité a pour but de permettre à tous les

périphériques réseau (routeur ...) d'obtenir des certificats.

I.2.3.1.3 Le serveur NPS (Network Policy Server)

Le serveur NPS (Network Policy Server) permet de créer et d’appliquer des stratégies d’accès

réseau à l’échelle de l’organisation pour l’intégrité des clients et pour l’authentification et

l’autorisation des demandes de connexion. Le serveur NPS peut être également utilisé en tant

que proxy RADIUS pour le transfert des demandes de connexion aux serveurs NPS ou à

d’autres serveurs RADIUS configurés dans les groupes de serveurs RADIUS distants. Le

serveur NPS contient aussi des composants clés pour le déploiement de la protection d’accès

réseau (NAP) sur votre réseau, et peut être déployé en tant que serveur de stratégie de

contrôle d’intégrité NAP.

I.2.3.1.4 Le protocole RADIUS

Le protocole RADIUS (Remote Authentication Dial-In User Service), mis au point

initialement par Livingston, est un protocole d'authentification standard, défini par un certain

nombre de RFC.

Le fonctionnement de RADIUS est basé sur un système client/serveur chargé de définir les

accès d'utilisateurs distants à un réseau. Il s'agit du protocole de prédilection des fournisseurs

d'accès à internet car il est relativement standard et propose des fonctionnalités de

comptabilité permettant aux FAI de facturer précisément leurs clients.

Le protocole RADIUS repose principalement sur un serveur (le serveur RADIUS), relié à une

base d'identification (base de données, annuaire LDAP, etc.) et un client RADIUS,

appelé NAS (Network Access Server), faisant office d'intermédiaire entre l'utilisateur final et le

serveur. L'ensemble des transactions entre le client RADIUS et le serveur RADIUS est chiffré

et authentifié grâce à un secret partagé.

Il est à noter que le serveur RADIUS peut faire office de proxy, c'est-à-dire transmettre les

requêtes du client à d'autres serveurs RADIUS.



Figure 11 : Principe de Radius

Fonctionnement de RADIUS

Le fonctionnement de RADIUS est basé sur un scénario proche de celui-ci :

Un utilisateur envoie une requête au NAS (Network Access Server) afin d'autoriser

une connexion à distance.

Le NAS achemine la demande au serveur RADIUS.

Le serveur RADIUS consulte la base de données d'identification afin de connaître le

type de scénario d'identification demandé pour l'utilisateur. Soit le scénario actuel

convient, soit une autre méthode d'identification est demandée à l'utilisateur. Le

serveur RADIUS retourne ainsi une des quatre réponses suivantes :

o ACCEPT : l'identification a réussi,

o REJECT : l'identification a échoué,

o CHALLENGE : le serveur RADIUS souhaite des informations supplémentaires de la

part de l'utilisateur et propose un « défi » (en anglais « challenge »).



Figure 12 : Fonctionnement de RADIUS

Conclusion

Dans ce chapitre, nous avons fait une étude théorique de toutes les technologies qu'on prévoit

utiliser dans notre projet. Nous pouvons à présent passer à la phase de conception et de

déploiement de notre maquette réseau.



CHAPITRE II : CONCEPTION ET

IMPLEMENTATION DE L’ARCHITECTURE

RESEAU A DEPLOYER



Introduction

Dans ce chapitre nous allons présenter la conception et l’implémentation de l’architecture

réseau qu'on souhaite mettre en place. Nous commençons par une présentation générale de

notre maquette réseau, puis nous présentons en détail les différentes étapes de sa

configuration.

II.1 Etude des besoins

Les besoins de notre projet peuvent être répartis en trois catégories :

des besoins en infrastructure qui décrivent en particulier l'architecture réseau physique

à mettre en place (matériel à utiliser, protocoles de couche liaison de données et de

couche réseau à configurer)

des besoins en services pour pouvoir gérer les accès client au réseau,

et des besoins en sécurité auxquels on devrait répondre pour obtenir une architecture

opérationnelle avec un minimum niveau de sécurité.

II.1.1 Besoins en infrastructure

Disposition du réseau en couches en utilisant des commutateurs de niveau 2 et de

niveau 3 ainsi que des routeurs Cisco

Connexion hôte via des points d’accès sans fil (modèles utilisés : AP Edimax, AP TP-

Link)

Redondance assurée avec HSRP et STP

Segmentation par des VLAN

II.1.2 Besoins en services

Tous les hôtes sont des clients Wifi

Accès Internet pour tout le monde

Accès par portail captif (avec pfSense) pour les invités (guests)

Accès au réseau par authentification Active Directory pour les clients internes

SQUID pour le filtrage des requêtes clients



II.1.3 Besoins en sécurité

Utilisation du pare-feu pfSense pour la mise en place du portail captif

Routage inter-vlan contrôlé par des listes de contrôle d'accès (ACL, Access Control

List)

Evaluation du niveau de sécurité de la maquette par des tests de pénétration lancés à

partir d'un hôte Wifi interne moyennant l'outil de test Kali Linux

II.1.4 Environnement de simulation

Pour concevoir et déployer notre architecture, nous avons opté pour l'environnement de

virtualisation VirtualBox pour héberger nos machines clients et nos serveurs, et nous avons

choisi l'émulateur réseau GNS3 (Graphical Network Simulator) pour simuler matériellement

nos routeurs et switchs.

Etant donné qu'il est impossible d'émuler des points d'accès sous GNS3, nous avons interfacé

notre environnement simulé avec des points d'accès réels.

II.2 Présentation de l'architecture proposée

II.2.1 Schéma de l'architecture

Le réseau que nous avons conçu se divise en trois couches distinctes (voir figure 13).

Les utilisateurs du réseau sont principalement des clients sans fil. Toutefois, les clients filaires

sont aussi pris en charge.

Nous distinguons deux types de clients : les clients internes à l'entreprise qui sont des

employés de l'entreprise et les clients externes à l'entreprise qui sont des invités, qui viennent

en visite pour de courtes périodes (pour une conférence par exemple, ou dans le cadre d'une

collaboration).

Les clients internes (employés) sont des clients Windows qui ont le droit d'accéder aux

ressources du réseau interne et à l'Internet. Ils seront authentifiés par un contrôleur de

domaine Active Directory et ils vont utiliser des certificats pour l'authentification de l'accès



réseau car ces derniers procurent une sécurité élevée. Cela est rendu possible grâce aux

services "Active Directory Certificate Service" et serveur NPS. De plus, PEAP sera utilisé

comme méthode d’authentification pour les clients.

Les clients externes (guests) n'ont accès qu'à l'Internet et sont authentifiés par un portail

captif (portail pfSense).

Nous avons aussi réparti notre réseau en trois zones moyennant le pare-feu pfSense :

Une zone DMZ privée au niveau de laquelle nous avons placé le serveur d’entreprise

Active Directory,

Une zone LAN qui contient les switchs, les points d'accès et les machines,

Une zone WAN qui assure la connectivité vers Internet.



Figure 13 : Maquette générale



II.2.2 Plan d'adressage

Périphérique

Interface Adresse IP Masque de sous réseau

R1

Fa0/0 192.168.0.118 255.255.255.0

Fa1/1 172.17.1.5 255.255.255.252

Core_ex

Fa0/0 172.17.1.30 255.255.255.252

Fa1/0 172.17.1.26 255.255.255.252

Fa1/1 192.168.0.118 255.255.255.0

Fa2/0 172.168.1.5 255.255.255.252

R1_core1

Fa0/0 172.17.1.21 255.255.255.252

Fa1/0 172.17.1.14 255.255.255.252

Fa1/1 172.17.1.38 255.255.255.252

Fa2/0 172.17.1.29 255.255.255.252

R2_core2

Fa0/0 172.17.1.22 255.255.255.252

Fa1/0 172.17.1.18 255.255.255.252

Fa1/1 172.17.1.34 255.255.255.252

Fa2/0 172.17.1.25 255.255.255.252

score1 Fa0/0 172.17.1.13 255.255.255.252

Fa4/0 172.17.1.33 255.255.255.252

score2 Fa0/0 172.17.1.17 255.255.255.252

Fa4/0 172.17.1.37 255.255.255.252

sdist1

VLAN 2 172.17.2.1 255.255.255.252

VLAN 3 172.17.3.1 255.255.255.252

VLAN 10 172.17.10.3 255.255.255.0

VLAN 77 172.17.77.3 255.255.255.0

VLAN 88 172.17.88.3 255.255.255.0

VLAN 99 172.17.99.3 255.255.255.0

sdist2

VLAN 4 172.17.4.1 255.255.255.252

VLAN 5 172.17.5.1 255.255.255.252

VLAN 10 172.17.10.1 255.255.255.0

VLAN 77 172.17.77.1 255.255.255.0

VLAN 88 172.17.88.1 255.255.255.0

VLAN 99 172.17.99.1 255.255.255.0

Tableau 1 : Plan d'adressage



Numéro du vlan Adresse réseau Nom du VLAN Mappage du port

10 172.17.10.1/24 Wired-employé Asemploye, Fa1/10

77 172.17.77.1/24 employé Asemploye, Fa1/11

88 172.17.88.1/24 Guest Asguest, Fa1/10

99 172.17.99.1/24 Admin Asadmin, Fa1/10

Tableau 2 : Mappages de ports et configuration des réseaux locaux virtuels

Périphérique Liaison Port VLAN Agrégat Adresse IP

Score1

score1-sdist1 Fa1/0-Fa2/1 Vlan 2 Port channel 1 172.17.2.2


score1-score2 Fa3/0-Fa3/1 -------- Port channel 3 172.17.1.9

Score2



score2-score1 Fa3/0-Fa3/1 ------- Port channel 3 172.17.1.10

Sdist1 sdist1-score1 Fa1/6-Fa1/7 Vlan 2 Port channel 2 172.17.2.1

sdist1-score1 Fa1/8-Fa1/9 Vlan 3 Port channel 3 172.17.3.1

Sdist2 sdist2-score2 Fa1/6-Fa1/7 Vlan 5 Port channel 5 172.17.5.1

sdist2-score1 Fa1/8-Fa1/9 Vlan 4 Port channel 4 172.17.4.1

Tableau 3 : Affectation des ports

Périphérique Port Agrégat Mode

Sdist1 Fa1/4, Fa1/5 Port channel 1 Trunk

Fa1/0, Fa1/1, Fa1/2 ------------------- Trunk

Sdist2 Fa1/4, Fa1/5 Port channel 1 Trunk

Fa1/1, Fa1/2, Fa1/3 ------------------- Trunk

Asemploye Fa1/0, Fa1/1 ------------------- Trunk

Asadmin Fa1/1, Fa1/2 ------------------- Trunk

Asguest Fa1/2, Fa1/3 ------------------- Trunk

Tableau 4 : Affectation du port channel

II.2.3 Zone DMZ

Nom du serveur Adresse IP Masque de sous-réseau

Active Directory 192.168.16.5 255.255.255.248

Tableau 5 : Adressage des serveurs



II.2.4 Zone des clients internes

Les hôtes

Nom de la machine Adresse IP Masque Passerelle par défaut

Pcadmin (ubuntu) 172.17.99.5 255.255.255.0 172.17.99.2

Pcvlan10 (windows 7) 172.17.10.5 255.255.255.0 172.17.10.2

Tableau 6 : Adressage des hôtes

Les points d'accès

Nous avons configuré les interfaces WAN et LAN de notre point d'accès TP-LINK pour les

employés du vlan 77 comme l'indique la figure ci-après :

Figure 14 : Configuration des interfaces de TP-LINK

Nous avons configuré les interfaces WAN et LAN de notre point d'accès EDIMAX pour les

utilisateurs du vlan 88 (dédié aux invités) comme l'indique la figure ci-après :



Figure 15 : Configuration des interfaces d’EDIMAX

II.2.2 Politique de sécurité

Nous avons empêché les clients guest de communiquer avec les autres VLANs et ce

moyennant l'utilisation d'une liste de contrôle d'accès (ACL) qui sera explicitée par la suite.

Figure 16 : Limitation d'accès par ACL



II.3 Les étapes de configuration de l’architecture

II.3.1 Configuration de la couche Distribution et Accès

La couche Distribution est représentée par deux switchs Cisco de niveau 3 (sdist1 et sdist2)

qui sont connectés à trois switchs de niveau 2 (asemploye, asadmin et asguest) appartenant à la

couche Accès.

Figure 17 : La couche distribution et accès

Afin de mettre en place la maquette de la couche Distribution et Accès, nous allons

configurer:

Les ports channels au niveau de sdist1 et sdist2

Des VLANs

Le protocole VTP

Le protocole STP

Le protocole HSRP



Une ACL qui interdit le VLAN 88 (VLAN Guest) de communiquer avec les autres

VLANs

II.3.1.1 Configuration du port Channel

Les ports Channel sont configurés au niveau des switchs de distribution (sdist1 et sdist2).

L’exemple ci-dessous décrit la configuration du port Channel :

// configuration des ports channel sur sdist1//

sdist1(config)#interface port-channel 1

sdist1(config-if)#switchport mode trunk

sdist1(config-if)#no shutdown


sdist1(config-if)#switchport access vlan 2


sdist1(config-if)#exit




sdist1(config)interface range fastEthernet 1/4 -5

sdist1(config-if-range)#switchport mode trunk

sdist1(config-if-range)#channel-group 1 mode on

sdist1(config-if-range)#no shutdown

sdist1(config-if-range)#exit

sdist1(config)#interface range fastEthernet 1/6 -7

sdist1(config-if-range)#switchport access vlan 2











// configuration des ports channel sur sdist2//

sdist1#conf t


sdist2(config-if)#switchport mode trunk









sdist2(config)interface range fastEthernet 1/4 -5

sdist2(config-if-range)#switchport mode trunk
















II.3.1.2 Vérification du port Channel

La commande « «show EtherChannel summary » nous permet de vérifier notre

configuration d’EtherChannel comme l’indique les deux figures suivantes :

Figure 18 : Vérification d’EtherChannel au niveau de sdist1



Figure 19 : Vérification d’EtherChannel au niveau de sdist2

II.3.1.3 Configuration des VLANs

Les VLANs 2, 3, 4, 5, 10, 77, 88 et 99 ont été configurés au niveau du switch sdist1.

L’exemple ci-dessous décrit la configuration des VLANs :

// configuration du VLAN 2

sdist1#vlan databasesdist1(vlan)#vlan 2

VLAN 2 added:

Name: VLAN0002


sdist1(vlan)#vlan 3

VLAN 3 added:

Name: VLAN0003


sdist1(vlan)#vlan 4

VLAN 4 added:

Name: VLAN0004




sdist1(vlan)#vlan 5

VLAN 5 added:

Name: VLAN0005


sdist1(vlan)#vlan 10 name wired_employe

VLAN 10 added:

Name: wired_employe


sdist1(vlan)#vlan 77 name employe

VLAN 77 added:

Name: employe


sdist1(vlan)#vlan 88 name guest

VLAN 88 added :

Name: guest


sdist1(vlan)#vlan 99 name admin

VLAN 99 added:

Name: admin

II.3.1.4 Vérification des VLANs

La capture d’écran ci-dessous montre la communication du VLAN 10 avec le VLAN 99 :



Figure 20 : Test de connectivité du VLAN 10 au VLAN 99

II.3.1.5 Configuration du protocole VTP

Nous avons configurés le switch sdist1 comme serveur VTP et le reste des switchs comme des

clients VTP. L’exemple ci-dessous montre une configuration du protocole VTP.

//activation du VTP server sur sdist1

sdist1#vlan database

sdist1(vlan)#vtp v2-mode

sdist1(vlan)#vtp server

Device mode already VTP SERVER.

sdist1(vlan)#vtp domain pfe

Changing VTP domain name from NULL to pfe

sdist1(vlan)#vtp password Cisco

Setting device VLAN database password to Cisco.

//activation du VTP client pour le Switch de distribution sdist2

Sdist2#vlan database



Sdist2(vlan)#vtp v2-mode

sdist2(vlan)#vtp client

Setting device to VTP client mode.

sdist2(vlan)#vtp domain pfe


sdist2(vlan)#vtp password Cisco


sdist2(vlan)#

//activation du VTP client sur le Switch asadmin

asadmin #vlan database

asadmin (vlan)#vtp v2-mode

asadmin(vlan)#vtp client


asadmin(vlan)#vtp domain pfe


asadmin(vlan)#vtp password Cisco


asadmin(vlan)#

//activation du VTP client sur le Switch asemploye

asemploye #vlan database

asemploye (vlan)#vtp v2-mode

asemploye(vlan)#vtp client




asemploye(vlan)#vtp domain pfe


asemploye(vlan)#vtp password Cisco


asemploye(vlan)#

//activation du VTP client sur le Switch asguest

asguest #vlan database

asguest (vlan)#vtp v2-mode

asguest(vlan)#vtp client


asguest(vlan)#vtp domain pfe


asguest(vlan)#vtp password Cisco


asguest(vlan)#

II.3.1.6 Vérification du protocole VTP

La commande « show vtp status » est utilisée pour vérifier la configuration VTP sur les

switch Cisco (voir figure 22).



Figure 21 : Vérification du vtp au niveau de sdist1

Figure 22 : Vérification du vtp au niveau de sdist2

II.3.1.7 Configuration du protocole STP

Le protocole STP a été configuré de sorte que le switch sdist1 soit root primaire pour les

VLANs (2, 3, 10, 77, 88 et 99) et sdist2 soit root secondaire pour les VLANs (10, 77, 88 et 99)

et root primaire pour les deux VLANs (4 et 5).

L’exemple ci-dessous décrit la configuration du STP au niveau du sdist1.

//activation du STP sur VLAN 2

sdist1(config)#spanning-tree vlan 2 root primary

VLAN 2 bridge priority set to 8192



VLAN 2 bridge max aging time unchanged at 20

VLAN 2 bridge hello time unchanged at 2

VLAN 2 bridge forward delay unchanged at 15

































L’exemple ci-dessous décrit la configuration du STP au niveau du sdist2 :















sdist2(config)#


sdist2(config)#spanning-tree vlan 10 root secondary

























II.3.1.8 Configuration du protocole HSRP

Nous avons activé le protocole HSRP au niveau des switchs de la couche distribution sdist1 et

sdist2.

L’exemple ci-dessous montre une configuration du HSRP au niveau du sdist1 qui est notre

switch primaire.

//activation du HSRP sur VLAN 10

sdist1(config)#int vlan 10

sdist1(config-if)ip address 172.17.10.3 255.255.255.0

sdist1(config-if)standby use-bia

sdist1(config-if)standby 10 ip 172.17.10.2 // Déclarer le passerelle du VLAN10 .

sdist1(config-if)standby 10 preempt // Permet d’augmenter la rapidité d’élection.







sdist1(config-if)standby 77 ip 172.17.77.2

sdist1(config-if)standby 77 preempt








sdist1(config)#int vlan 99 Vlan99





L’exemple ci-dessous montre une configuration du HSRP au niveau du sdist2 qui est notre

switch de secours :






















sdist2(config)#int vlan 99 Vlan99





II.3.1.9 Vérification du protocole HSRP

La commande « show standby » permet d’afficher le statut du HSRP sur les deux switchs de

la couche distribution.



La capture d’écran ci-dessous monter que sdist1 est notre commutateur primaire alors que

sdist2 est en Standby prêt à prendre le routage si sdist1 a un problème.

Figure 23 : Vérification du statut du protocole HSRP au niveau de sdist1



Nous avons effectué un petit test qui consiste à désactiver tous les ports du switch sdist1.

Comme la figure ci-dessous nous l’indique, les fastEthernet (fa1/0-9) de Switch sdist1 ont été

désactivés.

Figure 24 : Désactivation des ports fastEthernet de sdist1

Nous avons étudié tout d’abord le statut du HSRP sur les deux switchs pour savoir comment

ils ont géré le problème en utilisant la commande « show standby ».

La capture d’écran ci-dessous montre que sdist2 est bien passé à l'état actif.



Figure 25 : Vérification du statut du protocole HSRP au niveau de sdist2

La capture d’écran ci-dessous montre que sdist1 est toujours "down" car toutes ses interfaces

sont toujours désactivées.



Figure 26 : Vérification de l'état du protocole HSRP au niveau de sdist1

Ensuite nous avons réactivé les interfaces du Switch sdist1 en utilisant la commande « no

shutdown » et nous avons remarqué que ce dernier est repassé en « actif » (voir figure 27).



Figure 27 : Réactivation des ports fastEthernet de sdist1

Nous avons fait un Ping à la passerelle du Switch sdist1 (172.17.10.2) à partir d’une machine

appartenant au VLAN 10 qui a l’adresse IP 172.17.10.5. Nous avons constaté que le Ping a

réussi (voir figure 28) mais au moment où nous avons désactivé les interfaces de sdist1, tous

les paquets ICMP sont perdus à un certain moment et puis ils se basculent vers le Switch

sdist2 ensuite grâce à l’option « preempt », le routeur Standby (sdist2) qui remplaçait le routeur

actif lors d’une panne de ce dernier, retournera en mode standby si le routeur actif revient en

ligne (sdist1).



Figure 28 : Requête ping vers la passerelle de sdist1 du vlan 10

II.3.1.10 Configuration d’ACL

Une ACL a été configurée au niveau des commutateurs sdist1 et sdist2 pour interdire le

VLAN 88 de communiquer avec les VLANs 10, 77 et 99.

Ci-dessous, la configuration de l’ACL au niveau des deux switchs :

// configuration des ACLs sur le commutateur sdist1

sdist1(config)#access-list 1 deny 172.17.88.0 0.0.0.255

sdist1(config)access-list 1 permit any


sdist1(config-if)#ip access-group 1 out










// configuration des ACLs sur le commutateur sdist2

sdist2(config)#access-list 1 deny 172.17.88.0 0.0.0.255

sdist2(config)access-list 1 permit any










II.3.1.11 Vérification de l’ACL

Les deux figures ci-dessous montrent comment le trafic provenant du VLAN 88 n'est pas

autorisé à aller à destination des autres VLANs.

Figure 29 : Empêchement du VLAN 88 de communiquer avec le VLAN 10



Figure 30 : Empêchement du VLAN 88 de communiquer avec le VLAN 99

II.3.2 Configuration de la couche Distribution et Cœur

La couche cœur est représentée par trois routeurs Cisco (Core_ex, R1_core1 et R2_core2) et

deux Switchs de niveau 3 (score1 et score2) connectés à deux switchs de niveau 3 (sdist1 et

sdist2) appartenant à la couche Distribution.

Figure 31 : Les couches distribution et cœur

Afin de mettre en place la maquette de la couche Distribution et Cœur nous allons configurer :

Les ports channels au niveau du score1 et score2

Le protocole de routage dynamique eigrp sur tous les routeurs et tous les switchs L3

Configuration des routes statiques

L'accès Internet sur le routeur d’extrémité



II.3.2.1 Configuration du port channel

Les ports channel sont configurés au niveau de deux switch cœur (score2 et score2).

L’exemple ci-dessous décrit la configuration du port Channel :

// configuration des ports channel au niveau de score1//

score1(config)#interface port-channel 1

score1(config-if)#ip address 172.17.2.2 255.255.255.252

score1(config-if)#no shutdown

score1(config-if)#exit




score1(config)#interface port-channel



// configuration des ports channel au niveau de score1//




score2(config-if)#exit




score2(config)#interface port-channel





II.3.2.2 Configuration du protocole eigrp

Le protocole eigrp a été configuré au niveau tous les routeurs et switchs L3 de la même

manière.

L’exemple ci-dessous décrit la configuration du protocole eigrp sur core_ex :

//activation du protocole eigrp au niveau core_ex

core_ex(config)#router eigrp 1

core_ex(config-router)#network 172.17.0.0

core_ex(config-router)#no auto-summary

II.3.2.3 Vérification des routes eigrp

La figure ci-dessous représente la table du routage du routeur core_ex, en utilisant la

commande « show ip route ». La lettre D définit les routes découvertes par le protocole eigrp.



Figure 32 : Vérification des routes eigrp

II.3.2.4 Configuration des routes statiques

Nous avons configuré des routes statiques au niveau du routeur (R1) et (core_ex) et aussi au

niveau du firewall (pfSense).

Voici un exemple de configuration des routes statique au niveau du deux routeurs :

//définition de la route statique au niveau R1

R1 (config)#ip route 172.17.0.0 255.255.0.0 172.17.1.6

//définition de la route statique au niveau core_ex

Core_ex (config)#ip route 172.17.1.4 255.255.255.252 172.17.1.2

Core_ex (config)#ip route 192.168.16.0 255.255.255.0 172.17.1.2

core_ex (config)#ip route 192.168.0.0 255.255.255.248 172.17.1.2



//redistribution des adresses statiques dans le protocole eigrp

Core_ex (config)#router eigrp 1

Core_ex (config-router)#redistribute static

Core_ex (config-router)#

Voici la configuration des routes statiques au niveau de pfSense :

Figure 33 : Configuration des routes statiques au niveau du pfSense

II.3.2.5 Vérification des routes statiques

La commande « show ip route » permet d’afficher nos routes statiques comme l’indique les

deux figures qui suivent :

Figure 34 : Vérification des routes statiques au niveau core_ex



Figure 35 : Vérification de la route statique au niveau de R1

II.3.2.6 Configuration de la surcharge NAT (PAT)

Nous avons configuré la surcharge NAT pour autoriser l'accès Internet aux clients internes et

externes sur le routeur d'extrémité (R1).

//translation d'adresse privé en adresse publique

R1(config)#access-list 1 permit 172.17.10.0 0.0.0.255



R1(config)#access-list 1 permit 172.17.99.0 0.0.0.255R1 (config)#ip nat inside

source list 1 interface fastEthernet 0/0 overload

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip nat outside

R1(config-if)#exit

R1(config)#interface fastEthernet 1/1

R1(config-if)#ip nat inside

R1(config-if)#exit



II.3.2.7 Vérification de la translation d’adresse

La commande « sh ip nat translations » permet d’afficher la translation des adresses privées

en adresses publiques.

Figure 36 : Vérification de la translation d’adresse

II.3.2.8 Configuration de la route par défaut

Nous avons configuré une route par défaut au niveau du routeur d’extrémité (R1) et au niveau

de core_ex pour permettre aux clients de connecter à l'Internet simulée.

Voici un exemple pour la configuration du R1 et core_ex :

//définition de la route par défaut au niveau R1

R1(config)#ip route 0.0.0.0 0.0.0.0.0 192.168.0.1

//définition de la route par défaut au niveau core_ex

Core_ex(config)#ip route 0.0.0.0 0.0.0.0.0 172.17.1.2

//redistribution de l'adresse par défaut dans le protocole eigrp

R1 (config)#router eigrp 1

R1 (config-router)#redistribute static

R1 (config-router)#



II.3.2.9 Vérification de la route par défaut

La commande « show ip route » permet d’afficher la route par défaut que nous avons

configuré :

Figure 37 : Vérification de la route par défaut au niveau R1

Figure 38 : Vérification de la route par défaut au niveau core_ex



Nous avons fait un Ping à partir d’une machine de VLAN 10 et une machine de VLAN 99

vers l’adresse IP de Google et nous avons pu naviguer sur internet comme l’indique les

figures qui suivent :

Figure 39 : Requête ICMP à partir d'une machine appartenant au VLAN 10

Figure 40 : Navigation sur Internet à partir d’une machine du VLAN 10



Figure 41 : Requête ICMP à partir d'une machine appartenant au VLAN 99

Figure 42 : Navigation sur Internet à partir d’une machine du VLAN 99

Conclusion

Tout au long de ce chapitre, nous avons présenté la maquette générale de notre projet ainsi

que les détails de configurations qu'on a appliqué pour assurer une connectivité de bout en

bout. Une fois notre architecture établie et opérationnelle, nous pourrons nous consacrer à la

mise en place des services réseaux requis. C'est ce que nous allons détailler dans le chapitre

suivant.



CHAPITRE III : DEPLOIMENT DES

SERVICES RÉSEAU ET SÉCURISATION DE

L'ACCES SANS FIL



Introduction

Dans ce chapitre, nous allons mettre en place les serveurs nécessaires pour administrer,

sécuriser et surveiller notre architecture réseau et nous allons présenter les techniques de

sécurité que nous avons appliqué à notre architecture.

III.1 Mise en place des services réseau

III.1.1 Installation des rôles

Un rôle est un ensemble d'autorisations qu'un utilisateur doit détenir pour effectuer une tâche.

Des rôles bien conçus doivent correspondre à une catégorie de travail ou à une responsabilité

(par exemple, réceptionniste, responsable de l'embauche ou archiviste) et nommés en

conséquence. Le Gestionnaire d'autorisations vous permet d'ajouter des utilisateurs à un rôle

et de leur accorder une autorisation correspondant à leur fonction

III.1.1.1 Active Directory pour les clients internes

Les Services de domaine Active Directory (AD DS) stockent des informations sur les

utilisateurs, les ordinateurs et d'autres périphériques sur le réseau. Les AD DS permettent aux

administrateurs de gérer en toute sécurité ces informations et facilitent le partage des

ressources et la collaboration entre les utilisateurs. Les AD DS doivent aussi être installés sur

le réseau afin d'installer des applications d'annuaire et d'autres technologies Windows Server,

telles que la stratégie de groupe.

Après avoir installé le service d'annuaire Active Directory, notre serveur deviendra le

contrôleur de domaine principal de la forêt.

Création de nouveaux utilisateurs

Nous avons créé de nouveaux utilisateurs qui peuvent s'authentifier au AD à partir du notre

réseau local. Ci-dessous un exemple de création d'un nouvel utilisateur sous notre domaine :



Figure 43 : Création d’un nouvel utilisateur AD

Authentification à AD

Les employés de l'entreprise peuvent s'authentifier au service AD comme indiqué dans les

figures suivantes :

Figure 44 : Modification du domaine



Figure 45 : Modification du nom de l’ordinateur

Figure 46 : Authentification réussie

III.1.1.2 Network Policy Service et Services de certificats Active

Directory

Nous avons utilisé ces procédures pour installer les services de certificats Active Directory et

mettre en place des stratégies d'accès sans fil à travers le serveur NPS (Network Policy Server)

pour assurer l'authentification des clients internes au réseau.

Figure 47 : Principe de fonctionnement NPS+ADCS



III.1.1.2.1 Mise en place des stratégies d'accès (NPS)

Le serveur NPS est un serveur d'accès réseau permettant de définir une stratégie d'accès au

réseau (modifiable à tout moment).

Cette stratégie peut accepter n'importe quel paramètre de connexion (adresse IP source,

adresse de serveur Radius, type de protocole d'authentification, type de chiffrement, base

d'utilisateurs et mots de passe).

Après l'installation du rôle NPS, nous l'avons configuré comme suit [10] :

Figure 48 : Création de connexion sans fils sécurisée

Figure 49 : Ajout de client Radius



Figure 50 : Choix de la méthode d'authentification

Figure 51 : Ajout de groupe



III.1.1.2.2 Les services de certificats Active Directory (AD CS)

Les service de certificats AD CS sont une technologie de sécurité de contrôle d'accès et

d'identité qui fournit des services personnalisables de création et de gestion des certificats de

clé publique utilisés dans les systèmes logiciels de sécurité qui emploient les techniques de clé

publique.

Après l'installation de notre service de certificat nous l'avons configuré en passant par trois

étapes:

o ajout d'un modèle de certificat

o ajout d’un certificat

o ajout d'une autorité de certificat

Figure 52 : Ajout d'un modèle de certificat

Figure 53 : Ajout de certificat



Figure 54 : Ajout d'une autorité de certificat

Après l'ajout de certificats, nous allons dupliquer le modèle de certificat "ordinateur" avec

l'addition de Windows server 2008 et avec le nom "Wireless user's certificat auth" par suite

nous allons modifier les droits des utilisateurs comme l'indiquent les figures suivantes :

Figure 55 : Paramétrage d'un nouveau certificat



Figure 56 : Modification de nom de sujet

Figure 57 : Demande d’un certificat



Figure 58 : Inscription au certificat

III.1.2 Test d’authentification des clients internes

Après avoir installé le service de stratégie NPS et le service de certificat, notre serveur

deviendra la source d'authentification des employés de vlan 77. Les employés de l'entreprise

peuvent s'authentifier auprès du serveur NPS. Nous présentons dans la suite un scénario

d'authentification :



Figure 59 : Demande d'authentification

Figure 60 : Propriété de sécurité du client



Figure 61 : Client connecté

Nous avons consulté le fichier log de notre serveur pour consulter les utilisateurs authentifiés

et nous avons obtenu le résultat suivant :



III.2 Mise en place des techniques de sécurité

III.2.1 Mise en place du firewall pfSense

PfSense est un OS transformant n’importe quel ordinateur en routeur/pare-feu. Basé sur

FreeBSD, connu pour sa fiabilité et surtout sa sécurité, pfSense est un produit OpenSource

adapté à tout type d’entreprise.

Ses avantages principaux sont :

Sa disponibilité (Base FreeBSD, load balancing, etc.)

Sa confidentialité (HTTPS Web GUI, HTTPS authentification, IPSEC, PPTP, etc.)

Ses possibilités de suivi et audits

Sa mise à jour (packages visibles et téléchargeables)

Une interface d’administration web

Simplicité d’administration, d’installation

Autonomie complète

III.2.1.1 Configuration des interfaces

Tout d'abord, nous avons configuré de nouvelles interfaces, dans notre cas nous avons trois

interfaces WAN, LAN et DMZ :

Figure 63 : Les interfaces du firewall

III.2.1.2 Configuration des règles

PfSense permet de réaliser un filtrage par protocole(s), port(s), sur chaque interface. Pour cela,

il faut paramétrer les règles dans l’onglet Firewall/Rules. Les règles fonctionnent de manière

hiérarchique. En effet, pfSense va « lire » les règles de haut en bas, et dès qu’il trouvera une

règle s'appliquant au trafic, il l'appliquera.



Afin de réaliser un « meilleur » filtrage, il est d’abord conseillé de bloquer tout trafic et

d’ensuite autoriser un à un les ports et/ou protocole. Nous devons :

choisir si nous allons rejeter, bloquer ou passer le paquet définis dans la règle,

choisir l'interface qui va appliquer cette règle,

choisir le protocole qui va gérer la règle,

choisir l'adresse IP source,

choisir l'adresse IP destination,

et enfin spécifier les protocoles ou l'intervalle des protocoles à gérer avec cette règle.

Les figures suivantes illustrent les règles que nous avons mis en place sous pfSense :

Figure 64 : Page de configuration des règles



Figure 65 : Liste des règles de l'interface WAN

Figure 66 : Liste des règles de l'interface LAN

Figure 67 : Liste des règles de l'interface DMZ



III.2.2 Mise en place du portail captif pour les clients

"GUEST"

III.2.2.1 Configuration du portail captif

Pour activer le portail captif sur l'interface LAN de pfSense, nous avons coché la case Enable

Captive portal dans l'onglet Service > Captive portal. Nous avons ensuite choisi l'interface

sur laquelle le portail captif va écouter le LAN puisque nous voulons que les utilisateurs de

notre réseau local passent par le portail captif pour aller sur Internet et particulièrement le

VLAN88 (voir figure 68) [11]

Figure 68 : Activation du portail captif

Une fois cette configuration sauvegardée, le portail captif devrait être fonctionnel. Nous avons

par la suite modifié la page d'accueil du portail pour l'adapter à notre besoin et afin de la

rendre plus conviviale.



Figure 69 : Modification de la page d'accueil du portail

III.2.2.2 Authentification et gestion des utilisateurs

L'authentification est un point essentiel de pfSense puisqu'elle définit l'autorisation d'accès

vers l'extérieur, une sorte de portail physique fermé accessible par clé. Ainsi trois méthodes

d'authentification sont offertes:

sans authentification (No authentification) : les clients sont libres ; ils verront le portail

mais il ne leur sera pas demandé de s'authentifier.

authentification via un fichier local (Local User manager) : les paramètres des comptes

utilisateur sont stockés dans une base de données locale au format XML.

authentification via un serveur RADUIS (RADIUS Authentification) : à ce niveau,

nous avons le choix entre utiliser un serveur embarqué FreeRADIUS et utiliser un

serveur RADIUS qui se situe à distance du serveur pfSense.

Dans notre projet, nous avons testé les trois types d'authentification avec succès et nous avons

retenu l'authentification RADIUS embarqué car non seulement cela permet de gérer un grand

nombre d'utilisateurs, mais aussi pour des raisons de sécurité. A ce stade, le portail est déjà

accessible : un utilisateur qui se connecte au réseau local et qui souhaite accéder à un site Web



sera redirigé vers la page captive qui lui demandera de s'authentifier avant d'avoir accès à la

page demandée initialement.

III.2.2.2.1 Gestion des comptes utilisateurs

Pour configurer un compte avec authentification Radius, il faut aller dans l'onglet Service >

FreeRADIUS > User. Pour notre cas, nous avons créé trois comptes utilisateurs (sana, Nadine

et internet) qui peuvent se connecter à l'internet chaque semaine de lundi au vendredi à entre

08h du matin et 18h. Tous les comptes expireront le 15/janvier/2017(voir figure 70).

Figure 70 : Gestion des utilisateurs par FreeRADIUS

Et nous avons aussi créé un client NAS comme l'indique la figure ci-après :

Figure 71 : Création de client NAS

III.2.2.2.2 Sécurisation de l'authentification

Dans cette partie, il est question d'une part de sécuriser l'accès à l'interface web de

configuration de pfSense (webguids) par le protocole SSL et d'autre part de permettre un

cryptage des mots de passe des utilisateurs pour assurer une certaine confidentialité des

transactions après authentification. Pour se faire l'utilisation d'un certificat est plus que



nécessaire. Un certificat électronique (aussi appelé certificat numérique ou certificat de clé

publique) étant vu comme une carte d'identité numérique. Pour la sécurisation de l'accès au

webguid, nous allons dans l'onglet System> Advanced, puis dans la section Admin Access

pour activer le service HTTPS avec son numéro de port 443 (SSL) dans TCP port.

Figure 72 : Activation de HTTPS pour l'accès au webguid

De même pour crypter les mots de passe des utilisateurs et les échanges après leur

authentification, il faut créer un certificat pour pouvoir activer HTTPS. Ce qui se fait en trois

étapes:

choix du type de certificat (autogéré ou proclamé par une autorité de certification),

création et téléchargement du certificat,

activation du certificat sur le portail.

Pour ce faire, nous allons dans l'onglet System puis Cert Manager (voir figure 73).



Figure 73 : Choix du type de certificat

Figure 74 : Paramètres du certificat



Figure 75 : Activation de SSL pour le portail captif

III.2.2.3 Test du portail captif

À partir de notre machine client du VLAN88, nous avons tenté de naviguer sur internet et

d'emblée nous avons été redirigé vers la page captive du portail (voir figure 72).


III.2.3 Mise en place d’un proxy

Un proxy est un mécanisme de sécurité déployé par les administrateurs réseau dans un

environnement intranet pour désactiver l'accès à certains sites Web offensants ou

dangereux pour le réseau et les utilisateurs ou filtrer les demandes d'accès au contenu de ces

sites. Pour pouvoir utiliser les fonctionnalités de proxy, nous avons ajouté les packages

«Squid» et «SquidGuard» puis nous avons configuré les blacklists [7].



Figure 77 : Packages Squid et SquidGuard

III.2.3.1 Configuration du package Squid

Sous l'onglet services > proxy server > Access control, nous avons ajouté les adresses des

vlan 10, 77, 88 et 99.

Dans l’onglet Général, nous avons configuré les options suivantes :

Proxy interface

Allow user on interface

Log store directory : /var/log (dossier contenant déjà d'autres logs).

Proxy port : 9090

Language : French

blacklist : .facebook.*



Figure 78 : Configuration de Squid

III.2.3.2 Configuration du package SquidGuard

Sous l'onglet proxy server, nous avons coché la case blacklist et nous avons renseigné l'url

de la blacklist (il est possible de trouver des blacklists prédéfinies sur internet).

Figure 79 : Téléchargement du blacklist

On peut visualiser sous l'onglet Common ACL les catégories qu'on souhaite bloquer.



Figure 80 : Blocage des catégories

III.2.3.3 Test du proxy

Après la configuration de notre proxy, nous avons essayé de nous connecter à l'internet et en

particulier à facebook.com mais le proxy a bloqué cette connexion comme l'indique la figure

suivante :

Figure 81 : Empêchement de la connexion par le proxy



III.2.4 Sécurisation du point d’accès réservé aux clients

invités

Un point d’accès (AP) permet de donner un accès au réseau filaire (auquel il est raccordé) aux

différentes stations avoisinantes équipées de cartes Wi-Fi.

Le piratage d'une connexion wifi est très simple à réaliser si nous n'avons pas correctement

configuré et sécurisé notre réseau. Voici un rappel des protections que nous avons mis en

œuvre sur le point d'accès EDIMAX pour sécuriser notre réseau wifi :

Nous avons changé le SSID par défaut en un nom en évitant qu'il soit trop simple et

nous l'avons caché à la vue des utilisateurs malintentionnés. Il ne sera donc pas visible

dans la liste des connexions possibles de clients sans fil.

Figure 82 : Changement de SSID

Nous avons procédé à un filtrage des adresses MAC : dans l'utilitaire de configuration

de notre point d’accès, nous avons activé l'option de filtrage puis nous avons saisi les

adresses MAC de chacune de nos machines. Ainsi seuls ces appareils (reconnus sur le

réseau par leurs adresses MAC) pourront accéder au réseau.

http://forums.cnetfrance.fr/topic/1678-wifi/



Figure 83 : Filtrage des adresses MAC

III.3 Evaluation du niveau de sécurité de notre

maquette

Pour tester le niveau de sécurité de notre maquette, nous avons procédé à une attaque pour

récupérer la clé de sécurité (le mot de passe WiFi) du réseau sans fil des clients invités (que

nous avons nommé « Employer »). Le scénario de l'attaque est décrit par la figure suivante :

Figure 84 : Scénario d'attaque



Nous avons utilisé le fameux outil de tests de pénétration "Kali Linux".

Avant de commencer notre attaque, nous avons fait ouvrir un terminal en tant que super-

utilisateur, et nous avons tapé la commande suivante : airmon-ng.

Cette commande permet de voir les cartes connectées à la machine Kali. Dans notre cas, nous

avons utilisé la carte wifi, nommée wlan0.

Figure 85 : Liste des interfaces sans fil

Ensuite, nous avons activé son mode moniteur comme suit :

Figure 86 : Activation du mode moniteur

Une fois le mode moniteur actif, la carte va nous permettre d’écouter (scanner) le réseau à

porter. Pour se faire, il nous faut l’outil airodump-ng qui permet de lister les réseaux aux

alentours et voici ce que cela nous donne :



Figure 87 : Scan du réseau

BSSID : représente l’adresse MAC de notre point d'accès.

CH : représente le canal de notre point d'accès.

L'étape suivante consiste à capturer seulement le trafic vers et en provenance du SSID

"Employer". Pour avoir l'adresse MAC d'un client connecté au point d'accès, nous avons tapé

la commande : airodump-ng -c 11 --00:1F:1F:DA:3A:BC -w /root/Desktop/ mon0.

La figure ci-dessous montre les détails d'une machine victime (son adresse physique, ...).

Figure 88 : Capture de trafic sur le réseau sans fil "Employer"

En ayant en main une adresse physique valide et autorisée, il ne nous reste qu'à forcer la

machine victime à se reconnecter au réseau en lui envoyer des requêtes (deauth). Nous

avons utilisé un autre terminal pour lancer les requêtes de réauthentification avec la

commande aireplay-ng –0 2 –a 00:1F:1F:DA:3A:BC –c B0:10:41:3F:18:8F mon0.

En parallèle, la commande airodump-ng reste en exécution dans l'autre terminal. Il suffit de

voir apparaitre le mot WPA Handshake à l'exécution de la commande airodump pour

conclure que le mot de passe a été finalement capturé (voir figure 90)



Figure 89 : Capture du mot de passe

Une fois le mot de passe capturé, il ne nous reste que de le décrypter en tapant la commande

suivante :

aircrack-ng -a2 -b 00:1F:1F:DA:3A:BC -w /root/WPA.txt /root/Desktop/*.cap.

-a : indique la méthode que aircrack va utiliser pour cracker le mot de passe. C'est la

méthode WPA dans notre cas.

-b: indique l'adresse physique de notre point d'accès.

-w: pour les listes de mots (dictionnaire).

wpa.txt: est un fichier qui contient les listes de mots.

*.cap : les fichiers qui contiennent le mot de passe non cracké.

La figure suivante montre au final le mot de passe dérobé par la machine attaquant.

Figure 90 : Mot de passe en clair



Après avoir "craquer" le mot de passe, nous avons tenté de nous connecter à partir de la

machine Kali mais la connexion a été refusée car un filtrage d'adresses MAC a été configuré au

préalable au niveau de notre point d'accès : l'adresse MAC de l'attaquant ne figure pas dans la

liste des adresses MAC autorisées à se connecter à notre réseau.

La cohabitation de plusieurs techniques de sécurité dans notre système nous a permis

d'atteindre un niveau très élevé de protection contre les infiltrations non autorisées mais il

peut être brisé.

Nous avons planifié de tester le niveau de sécurité pour les clients internes, malheureusement

cette phase de test n'a pas été achevée à cause du manque de ressources matérielles et

logicielles.

Conclusion

Au cours de ce chapitre, nous avons présenté le déploiement des services réseau et les

techniques de sécurité que nous avons mis en place, puis nous avons évalué le niveau de

sécurité de notre maquette en procédant à un test de pénétration avec Kali Linux.



Conclusion générale

Nous tirons globalement de ce projet un bilan très positif, vu qu'il met en

évidence une configuration de réseau hiérarchique, en démarrant par une

configuration entre ses trois couches en utilisant divers protocoles comme HSRP,

VTP, STP et EIGRP.

Ce projet a été pour nous l'occasion de découvrir plusieurs systèmes de sécurité

tels que les serveurs d'annuaires, Proxy Squid et SquidGuard, le pare-feu pfSense

et l'accès par portail captif. C'est également à travers ce projet que nous avons eu

l'opportunité d'étudier et de mettre en place des techniques de sécurisation de

WLAN (Wireless LAN) telles que les méthodes d'authentification EAP et PEAP

et les protocoles de sécurité WPA et WPA2.

Enfin, ce projet nous a donné l'occasion de mettre en pratique la formation

théorique que nous avons reçue à L'ISET, qui s'est révélée adaptée aux

compétences souhaitées.



Bibliographie

[1] https://llabetsio.wordpress.com

[2] http://idum.fr/spip.php?article226

[3] http://docs.oracle.com/

[4] http://www.it-connect.fr/

[5] https://msdn.microsoft.com

[6] http://doc.ubuntu-fr.org/squid

[7] http://www.caron.ws/index.html?711ServeurLDAP1.html

[8] https://msdn.microsoft.com/fr-fr/library/bb469881.aspx

[9] http://www.labo-microsoft.org/articles/ActiveDirectory_Roles/3/?action=print

[10] https://www.youtube.com/watch?v=PjdFwQc_tCw

[11] https://www.youtube.com/watch?v=B6Hjxd1Af-s

[12] https://www.youtube.com/watch?v=H-6_13P8pS8


Sana AFLI, Nadine HRIRA A1

Annexes

Annexe1. Les étapes d'intégration des machines virtuelles

dans le réseau

Ajout des cartes virtuelles au niveau du Virtual Box :

Afin d'interconnecter les machines virtuelle à leur réseau approprié, il faut créer de nouvelles

cartes virtuelles au niveau du Virtual Box.

Figure 91 : Liste des cartes virtuelles

Configuration du mode d’accès réseau

Sur une machine (déjà installée), il faut aller modifier les paramètres réseau :

Choisir le mode d'accès réseau « Réseau privé hôte » au niveau du notre firewall et au

niveau de la machine virtuelle (Windows server).



Mettre une carte réseau (ex : numéro 2) en “Host-Only Adapter” et laisser le nom par

défaut “VirtualBox Host-Only Ethernet Adapter #2“. Les autres paramètres avancés

sont aussi à laisser par défaut, il faut juste s'assurer que le câble est connecté pour que

la liaison s'effectue correctement.

Figure 92 : Choix du mode d'accès réseau

Configuration de la carte réseau au niveau de la machine

La carte réseau de la machine doit être configurée avec une adresse IP, un masque et une

passerelle compatible avec la carte réseau virtuelle.

Voici un exemple de configuration d'une carte réseau d'une machine en IPv4.



Figure 93 : Propriété de la carte réseau en IPv4

Annexe2. Connectivité des firewalls à GNS3 et aux

différents segments

Pour assurer la connectivité de firewalls à GNS3, il faut :

Ajouter des cartes virtuelles au niveau du firewall.

Ajouter un nuage au niveau de GNS3 et configurer sa carte réseau par une

carte virtuelle liée au firewall (interface WAN et interface LAN) comme le

montre la figure suivante :



Figure 94 : Configuration de la carte réseau du nuage

Figure 95 : Liaison entre le nuage de PFsense et le routeur Core_ex

Pour assurer la connectivité GNS3 à internet, il faut :

Ajouter un nuage au niveau du GNS3 et configurer sa carte réseau en tant que

carte loopback qu'il faudrait par la suite lier au routeur d'extrémité R1 comme

le montre la figure ci-dessous :



Figure 96 : Configuration de la carte réseau du nuage

Figure 97 : Liaison entre le nuage Internet et R1

Annexe3. Architecture générale sous GNS3

Ci-dessous une figure qui illustre notre maquette sous GNS3 :



Figure 98 : Maquette de la solution générale

Figure 99 : Les machines virtuelles sous l'environnement VirtualBox

rapport de projet de fin de parcours

Education