|
REPUBLIC OF CAMEROON
Peace-Work-
Fatherland
MINISTRY OF HIGHER
EDUCATION
THE UNIVERSITY OF
NGAOUNDERE
REPUBLIQUE DU CAMEROUN
Paix-
Travail-Patrie
MINISTERE DE
L'ENSEIGNEMENT
SUPERIEUR
UNIVERSITE DE NGAOUNDERE
INSTITUT UNIVERSITAIRE DE TECHNOLOGIE DE
NGAOUNDERE
B.P. 455 NGAOUNDERE
TEL.:77 51 21 08/ 77 11 22 17/
74 91 60 57
dstages2004@yahoo.fr
Division
des stages, de la formation permanente et des Relations avec les
milieux
professionnels
En vue de l'obtention du Diplôme de Licence
Professionnelle
Mention : GENIE INFORMATIQUE (GIN)
Parcours: RESEAUTIQUE ET INTERNET (RI)
|
CONCEPTION ET DEPOIEMENT
|
|
D'UNE ARHITECTURE RESEAU SECURISEE
|
|
A L'IUT DE NGAOUNDERE
|
Stage effectué du 11 Juillet au 11 octobre
2013 à L'IUT de Ngaoundéré
Par :
NGOUCHEME MBOUOUMBOUO A.
Matricule : 10I037IU
Encadreur Industriel:
Dr YENKE Blaise omer Chargé des cours
IUT Année Académique 2012/2013
Encadreur Académique:
M.NDAM NJOYA AROUNA Enseignant IUT
Rédiger par NGOUCHEME MBOUOMBOUO A Page
ii
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
DEDICACE
Je dédie ce modeste travail A toute ma famille
MBOUOMBOUO.
Rédiger par NGOUCHEME MBOUOMBOUO A Page
iii
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
REMERCIEMENTS
Je rends grâce à ALLAH tout puissant qui a permis
à la réalisation de ce travail en m'accordant santé et
courage pour arriver à ce chemin. .
Je suis très sensible aux multiples efforts fournis par
les uns et les autres pour leur contribution, leur collaboration, leur soutien
sans faille, de nombreuses personnes de bonne volonté de près ou
de loin m'ayant assisté. Je tiens à exprimer ma gratitude :
- A mon père MBOUOMBOUO MAMA pour son attention et son
soutien moral et financier ;
- A ma très chère mère pour toute son
affection :
- Mes frères ma soeur pour leur soutien affectif, moral
et financier, je pense comme ça à ABDOURAHMAN MAMA ; FESSAL BABA,
ABOUBAKAR SIDDIQ, ISSA, DUGA FEH ISSA, sans oublier ceux dont le nom
m'échappe ;
- A mon meilleur ami d'enfance ALIOU NANA pour son soutien
moral et psychologique - Dr YENKE BLAISE OMER, Chef de Département
Génie Informatique de l'IUT de
Ngaoundéré, pour ses conseils, et pour son suivi
pédagogique tout au long de notre
formation ;
- M. NDAM NJOYA AROUNA pour les connaissances qu'il nous a
apportées tout au long de ces deux dernières années ;
- Tous les enseignants de l'IUT pour toutes les connaissances
qu'ils nous inculquent chaque jour sans réserve ;
- Tous mes camarades de promotion qui n'ont cessé de me
tenir à l'épaule au moment critique de notre formation. Je pense
particulièrement à : YAMEN JOEL ; NDZIE AHANDA ; KANI JACQUES
MENDIAJEU NEL ALHADJI DIBRILLA ; SOULEMANOU BOUBA ; et tous ceux dont le nom ne
figure pas ici.
Rédiger par NGOUCHEME MBOUOMBOUO A Page
iv
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
PRESENTATION DE L'ENTREPRISE
Dans ce chapitre nous présentons l'entreprise, les postes
de travail et l'organisation hiérarchique de la structure qui nous a
accueillis durant cette période de stage.
1 - Situation Géographique
L'Université de Ngaoundéré est située
dans la région de l'Adamaoua dans le département de la vina.
C'est l'une des universités camerounaises qui compte l'Institut
Universitaire de Technologie (IUT) parmi ses grandes écoles.
Localisation (cf. Annexe1)
2 - Adresse complète
Pour entrer en contact avec l'iut, il est possible de se rendre
dans ses locaux ou alors d'utiliser les informations de contacts suivants :
Tel. : 77 11 22 18 / 77 11 22 20 B.P.455 Ngaoundéré
Email :
iutngaoundere@yahoo.fr
Site-web:
www.iut-un.net
Désormais vous pouvez vous connecter en ligne sur le site
officiel de l'IUT de Ngaoundéré par le biais de :
www.iut-un.net
3 - Historique
L'Institut Universitaire de Technologie (IUT) de
Ngaoundéré est un établissement technologique
d'enseignement supérieur créé par Arrêté
n°009/CAB/PR du 19 janvier 1993 portant création d'instituts
Universitaire de Technologie au sein des universités. Depuis sa
création, elle a connu une évolution tant sur ses formations que
sur la qualité de ses enseignements. Nous retenons ici quelques dates
marquantes de son évolution :
1993 : Création de l'JUT de Ngaoundéré
1995 : Création de la spécialité
Génie informatique 2003 : GAI devient Génie Biologique
Rédiger par NGOUCHEME MBOUOMBOUO A Page
v
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
2003 : Création de la spécialité
Génie Thermique et Énergétique 2007 : Passage au
système Licence-Master-Doctorat (LMD) 2008 : Ouverture de la Licence
Professionnelle en Génie
Informatique
2009/2010 : Ouverture de la Licence Professionnelle en
Génie Biologique
2011 : Ouverture de la Licence Professionnelle en Génie en
Maintenance Industrielle, GTE, GEL
4 - Organisation Générale
L'IUT de Ngaoundéré dans son livre blanc
présente une organisation générale ainsi qu'il suit :
Un conseil de direction composé :
Du Recteur de l'université de Ngaoundéré
;
Du Vice-recteur de l'université de
Ngaoundéré : vice- président ;
Du Directeur de la formation et de l'orientation de
l'enseignement supérieur au Ministère chargé de
l'enseignement supérieur : Membre ;
Du Directeur de l'IUT de Ngaoundéré : Membre ;
Du Directeur-Adjoint de l'IUT de Ngaoundéré :
Membre ; Du représentant du Ministre chargé de l'industrie et
du
Commerce : Membre ;
Du représentant du Ministre de l'agriculture : Membre ;
Une Direction
Placée sous l'autorité du Recteur de
l'Université de Ngaoundéré et assuré par un
Directeur assisté d'un Directeur- adjoint, nommés suivant la
réglementation en vigueur, la Direction de l'IUT comprend :
Les Divisions notamment :la Division de la Formation Initiale et
la Division des Stages de la formation Permanente et des Relations avec les
Milieux professionnels ;
Le service des Affaires Générales ;
Rédiger par NGOUCHEME MBOUOMBOUO A Page
vi
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Le service de la Documentation et de la Reprographie.
Le service de la scolarité et de l'orientation
professionnelle ;
Le service de l'Intendance ;
La bibliothèque ;
Le bureau du courrier.
Un Conseil de professeurs
Le conseil de professeurs émet un avis préalable
sur le régime des études, leur organisation et
les modalités de leur évaluation, les programmes,
le recrutement et l'avancement des
membres du corps enseignant. Il suit la coordination des
activités scientifiques et
académiques entre le corps enseignant et celui des autres
établissements de l'université.
Une assemblée de l'Institut
Elle se compose essentiellement de :
Tous les enseignants permanents de l'Institut ;
Toute personnalité étrangère invitée
à titre consultatif ;
02 représentants de l'Association des élèves
de l'Institut ;
02 Délégués du Personnel Administratif et
Technique.
L'assemblée de l'institut émet des voeux sur toutes
les questions intéressant la vie de
l'institut, se réuni une fois par trimestre et chaque
fois que cela est jugé nécessaire. Elle est convoquée et
présidée par le Directeur de l'institut.
5 - Secteur d'activité
L'IUT de Ngaoundéré a pour missions :
-de dispenser en formation initiale un enseignement moyen
supérieur préparant aux fonctions de techniciens supérieur
et
D'ingénieur de travaux dans les domaines des techniques
Industrielles et du génie des procédés ;
-d'assurer en formation permanente dans les mêmes domaines
qu'en formation initiale. Les études à l'Université de
Ngaoundéré sont divisées en deux cycles :
Rédiger par NGOUCHEME MBOUOMBOUO A Page
vii
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Le cycle du Diplôme Universitaire de Technologie, d'une
durée de quatre semestres (2 ans) et sanctionné par le
Diplôme Universitaire de Technologie en abrégé DUT
Le cycle de Licence Professionnelle (cycle post DUT) d'une
durée de 2 semestres et sanctionné par le diplôme de
Licence Professionnelle (niveau BAC +3) en :
o Génie Informatique
o Génie Biologique
o Maintenance Industrielle et Productive
o Génie Chimique (nouvellement crée)
6 - Nombre de Personnel
Le personnel de l'IUT est divisé en deux : le personnel
d'administratifs qui est constitué de 33 personnes et le personnel
enseignant qui comprend 31 personnes.
7 -Présentation des postes de travail
Les différents maillons de la chaine administrative de
l'IUT sont formés de la direction, des Divisions et de divers services
allant des affaires générales de l'intendance.
La Direction : elle est composée d'un Directeur
assisté d'un adjoint. Elle est chargée de la police
générale de l'établissement, de la gestion des
crédits et du personnel, de la représentation de l'Institut
auprès du Recteur de l'université, du suivi de la
coopération, de la coordination et de l'animation des activités
académiques ;
Les Divisions : il y en deux : celle en charge de la formation
initiale qui gère l'organisation, l'animation et le suivi des
activités de l'ensemble des départements, et celle des stages et
de la formation permanente et des relations avec les milieux professionnels.
Le service chargé des affaires qui s'occupe de la
gestion du personnel administratif et de l'instruction des affaires
générales ;
Le service de la documentation de la documentation et de la
reprographie qui organise et anime les activités d'impression et de
diffusion des matériels pédagogiques ;
Le service de la scolarité et de l'orientation
professionnelle, chargé de l'information et de l'orientation des
candidats à l'inscription dans les différentes filières et
la gestion des statistiques ;
Rédiger par NGOUCHEME MBOUOMBOUO A Page
viii
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Le service de l'intendance qui a en charge l'instruction des
Affaires financières ;
Le service des stages qui est chargé de la gestion des
étudiants en stage et des relations avec les entreprises
8 - Organisation hiérarchique
L'Institut Universitaire de Technologie est un
établissement d'enseignement supérieur qui a à sa
tête un Directeur assisté d'un Directeur Adjoint et est
constitué d'un ensemble de services et de départements qui sont
regroupés sous la direction du Directeur et de son Adjoint. Chaque
service ou département est dirigé par un chef de service ou chef
de département. Pour la représentation graphique de la structure
fonctionnelle et de l'organisation hiérarchique des services et des
départements de l'IUT (voir annexe 2).
Rédiger par NGOUCHEME MBOUOMBOUO A Page
ix
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
REMERCIEMENTS iii
PRESENTATION DE L'ENTREPRISE iv
1 - Situation Géographique iv
2 - Adresse complète iv
3 - Historique iv
4 - Organisation Générale v
5 - Secteur d'activité vi
6 - Nombre de Personnel vii
7 -Présentation des postes de travail vii
8 - Organisation hiérarchique viii
SOMMAIRE ix
TABLE DES FIGURES xii
LISTE D'ABREVIATIONS xvi
RESUME 1
INTRODUCTION GENERALE 2
CHAPITRE 1 : PROBLÉMATIQUE DE SÉCURITÉ DANS
UN RÉSEAU D'ENTREPRISE : CAS DE L'IUT DE
NGAOUNDÉRÉ 6
I.1 GENERALITE SUR LA SECURITE 6
I. 2. AUDIT DU RÉSEAU DE L'IUT DE NGAOUNDÉRÉ
6
I. 2.1. ETUDE DE L'EXISTANT 7
I. 2.2. Présentation du réseau de l'IUT de
Ngaoundéré 8
I. 2.3. Architecture du réseau existant 8
I.3. RÉSULTAT DE L'AUDIT DU RÉSEAU EXISTANT 8
I.3.1. sécurité 8
I.3.2. parc informatique 9
Rédiger par NGOUCHEME MBOUOMBOUO A Page
x
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
I.4. LES SOLUTIONS APPORTÉES 11
I.4.1. Besoins fonctionnels 11
I.4.2. Besoins non fonctionnels 12
CHAPITRE 2 : METHODE DE CONCEPTION ET DE DEPLOIEMENT DU
RESEAU SECURISEE DE L'IUT DE
NGAOUNDERE 12
II.1. PHASE DE PLANIFICATION DU DEPLOIEMENT 12
II.1.1. PLANIFICATION DU DEPLOIEMENT 12
II.1.2. LES DIFFERENTS SERVICES ET L'ADRESSAGE 13
II.2. MISE EN OEUVRE DE L'ARCHITECTURE DE VIRTUALIUT 16
II.2.1. Configuration réseau d'un serveur Linux 16
II.2.2. la translation d'adresse IP ou NAT 18
II.2.3. mis en place du serveur SVRLAN 18
II.2.4. configuration d'un serveur de dépôts de
paquetages 20
II.2.5. Installation de deux systèmes sur un PC 23
CHAPITRE 3 : DEPLOIEMENT ET TEST DE L'ARCHITECTURE RESEAU
SECURISEE 26
III.1. Installation du service DNS 26
III.1.1. Avant l'installation du service DNS 26
III.1.2. Installation du DNS sur le serveur SVRLAN 27
III.1.3. Configuration du serveur SVRDMZ en serveur DNS
secondaire 30
III.2. Service DHCP et DNS dynamique 32
III.2.1. Installation du service DHCP sur le serveur SVRLAN 32
III.3. Installation d'un serveur de temps avec NTP 34
III.3.1. Principe d'un serveur NTP 34
III.4. Installation d'un serveur d'annuaire LDAP 36
III.4.1. installation du paquetage du service LDAP 37
III.4.2. Authentification des utilisateurs par LDAP 40
III.5. Mise en place d'un serveur de messagerie 42
Rédiger par NGOUCHEME MBOUOMBOUO A Page
xi
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
III.5.1. Activité 42
III.6. Configuration de serveurs Web virtuels sous Apache
44
III.6.1. Activité 45
III.7. Installation d'un serveur mandataire Squid 46
III.7.1. Installation et configuration du serveur Squid 46
III.8. SECURISATION DU RESEAU VIRTUALIUT 48
III.8.1. Le SPLIT DNS 49
III.9. Le chiffrement des échanges 54
III.9.1. L'activité 55
III.10. Utilisation d'un réseau privé virtuel
59
III.10.1. Génération des certificats et
clés d'authentification 61
III.11. Installation d'une politique de sécurité
64
III.11.1. les mesures de sécurité 65
III.11.2. l'activité 66
CONCLUSION ET PERSPECTIVES 73
BIBIOGRAPHIE 74
ANNEXES 75
Rédiger par NGOUCHEME MBOUOMBOUO A Page
xii
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
TABLE DES FIGURES
Figure 1 : Architecture du réseau existant 8
Figure 2 : Modèle de réseau d'entreprise 13
Figure 3 : Architecture du réseau de l'IUT de
Ngaoundéré 15
Figure 4 : Configuration IP du serveur SVRLAN 17
Figure 5 : vérification de la carte réseau du
serveur SVRLAN 17
Figure 6 : Augmentation de la route statique 18
Figure 7 : configuration de l'interface réseau eth0 du
SVRLAN 18
Figure 8 : configuration de l'interface réseau eth1 du
SVRLAN 19
Figure 9 : vérification de la présence du paquet
Iptables 19
Figure 10 : Extension du réseau de l'entreprise
VIRTUALIUT 21
Figure 11 : Extrait du script pour la création du
miroir 22
Figure 12 : Schéma du réseau VIRTUALIUT avec les
clients 25
Figure 13 : configuration du fichier hosts du serveur 26
Figure 14 : configuration du fichier hosts du client 26
Figure 15 : contenu du fichier named.conf 27
Figure 16 : contenu du fichier named.conf.local 28
Figure 17 : configuration du fichier virtualiut.db 28
Figure 18 : configuration du fichier inverse de virtualiut.db
29
Figure 19 : contenu du fichier resolv.conf 29
Figure 20 : configuration du fichier resolv.conf 30
Figure 21 : configuration du fichier named.conf.options 30
Figure 21 : nouvelle configuration du fichier named.conf 31
Figure 22 : nouvelle configuration du fichier
named.conf.options 31
Figure 23 : nouvelle configuration du fichier named.conf.local
32
Figure 24 : copie du fichier de configuration du DHCP 33
Figure 26 : configuration du fichier dhcp-relay 34
Rédiger par NGOUCHEME MBOUOMBOUO A Page
xiii
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 27 : exemple d'adresse statique fixée pour un
utilisateur 34
Figure 28 : configuration du fichier dhclient du CLIENT 34
Figure 29 : configuration du fichier ntp.conf 35
Figure 30 : configuration dans le fichier ntpdate 36
Figure 31 : Synchronisation de SVRDMZ sur SVRLAN 36
Figure 31 : installation du paquet sldap 37
Figure 32 : copie du mot de passe sur pass.txt 38
Figure 33 : paramètre de l'accès en
écriture 38
Figure 34 : paramètre de l'accès en lecture
38
Figure 35 : Définition de la structure de l'annuaire au
format LDIFF 39
Figure 36 : ajout d'une fiche utilisation 40
Figure 37 : création d'une fiche pour un utilisateur
user_linux1 40
Figure 38 : installation du paquet ldap 41
Figure 40 : création d'un groupe d'utilisateur 41
Figure 41 : configuration du fichier ldap.conf 41
Figure 42 : installation du paquet postfix 43
Figure 43 : installation du paquet dovecot pop3 43
Figure 44 : configuration du fichier dovecot.conf 44
Figure 45 : Modifiez le ficher de configuration Postfix 44
Figure 46 : ajout de la nouvelle configuration sur le fichier
db.virtualiut.lan 44
Figure 47 : configuration de l'interface eth0:0 45
Figure 48 : Paramétrage du proxy sous Firefox 47
Figure 49 : accès impossible par le proxy Squid 47
Figure 50 : ajout de la définition ACL du réseau
48
Figure 51 : contrôle d'accès suivant une heure
déterminée 48
Figure 52 : réseau d'entreprise VIRTUALIUT sans serveur
pare-feu SVRFWL 50
Figure 53 : schéma du réseau d'entreprise final
50
Rédiger par NGOUCHEME MBOUOMBOUO A Page
xiv
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 54 : configuration de l'interface eth0 du serveur
SVRFWL 51
Figure 55 : configuration final des interfaces du serveur
SVRFWL 51
Figure 56 : contenu du fichier /etc/bind/rndc.key 52
Figure 57 : définition d'une ACL pour le LAN 53
Figure 58 : création de l'arborescence 53
Figure 59 : nouvelle configuration du fichier virtualiut.lan
54
Figure 60 : gestionnaire de certificats de FireFox 55
Figure 61 : Schéma OpenSSL dans le cas d'un serveur
Apache 56
Figure 62 : initialisation du certificat 56
Figure 63 : extrait de la création du certificat racine
57
Figure 64 : contenu du web.csr 57
Figure 65 : configuration d'hébergement virrtuelsur IP
58
Figure 66 :création d'un certificat d'autorité
(CA) 58
Figure 67 : limitation de droit d'accès sur la cl
é generée 59
Figure 68 : installation du paquet openvpn pour le VPN 60
Figure 69 : initialisation des variables du fichier easy-rsa
61
Figure 70 : génération des paramètres de
Diffie Hellman 62
Figure 71 : copie des fichiers generés du serveur au
client_linux par SSH 63
Figure 72 : configuration du fichier server.conf 63
Figure 73 : configuration du fichier client.conf 63
Figure 74 : aperçu du tunnel créer par le VPN
64
Figure 74 : test de connexion entre le serveur et le client
VPN 64
Figure 75 : fonctionnnement de netfilter 66
Figure 76 : debut du script pour l'initialisation des
variables 67
Figure 77 : vidage de toutes les régles existantes et
verroullage 67
Figure 78 : ajout de la fonction TableFILTER() au script 68
Figure 79 : activation du routage 68
Rédiger par NGOUCHEME MBOUOMBOUO A Page
xv
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 80 : fermeture de toutes portes pour ensuite les ouvrir
une par une 69
Figure 81 : ouverture de la connexion avec l'extérieur
69
Figure 82 : Schéma de circulation des flux pour la
chaîne FORWARD 70
Figure 83 : autorisation de la communication pour le routage
des demandes pour le LAN 70
Figure 84 : interdiction de la communication vers l'exterieur
71
Figure 85 : autorisation de la communication pour la DMZ 71
Figure 86 : autorisation de la communication avec les services
publics de la DMZ 71
Figure 87 : blocage des paquets suspect venant de
l'extérieur 72
Figure 88 : autorisation du trafic dans le réseau
d'entreprise 72
Figure 1A : Organigramme de l'IUT 75
Figure 1B : Plan de localisation de l'IUT de
Ngaoundéré 76
Rédiger par NGOUCHEME MBOUOMBOUO A Page
xvi
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
LISTE D'ABREVIATIONS
BIND: Berkley Internet Naming Daemon
DHCP: Dynamic Host Configuration Protocol
DMZ: Demilitarized zone
DNS: Domain Name Sever
FDDI: Fiber Distributed Data Interface
FTP: Foiled Twisted Pair
HTTP: Hypertext Transfert Protocol
IAP: Internet Access Provider
ICMP: Internet Control Message Protocol
IGMP (Internet Group Management Protocol)
IMAP: Internet Message Access Protocol
IP: Internet Protocol
IPsec: Internet Protocol Security
IPV4: Internet Protocol version 4
LDAP: Lightweight Directory Access Protocol
LAN: Local Area Network
MAC: Media Access Control
MAN: Metropolitan Area Network
NAT: Network Address Translation
PCMCIA: Personal Computer Memory Card International
Association
POP: Post Office Protocol
QOS: Quality Of Service
Rédiger par NGOUCHEME MBOUOMBOUO A Page
xvii
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
SGBD: Système de Gestion de Base de Données
SVRLAN: serveur du LAN
SVRDMZ : serveur du la DMZ
SVRFWL: serveur du firewall
SNMP: Simple Network Management Protocol
SSL: Secure Sockets Layer
TCP: Transport control Protocol
URI: Uniform Resource Identifier
UTP: Unshielded Twisted Pair
VLAN: Virtual Local Area Network
VPN: Virtual Private Network
WAN : Wide Area Network
RESUME
Rédiger par NGOUCHEME MBOUOMBOUO A Page
1
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
RESUME
Dans l'optique de facilité et d'améliorer les
échanges d'informations d'une manière sécurisée,
l'Institut Universitaire de Technologie de Ngaoundéré envisage de
mettre en place une architecture réseau, dont l'objectif est
d'implémenter la sécurité des informations et services
véhiculés. Notre travail consiste à proposer une
architecture réseau puis à concevoir et déployer
différents services.
Pour atteindre ces objectifs nous avons utilisé une
démarche qui consiste à auditer le réseau de l'IUT
existant, à déployer la DMZ (zone démilitarisée)
qui offrent les services publics du réseau, à déployer le
serveur SVRLAN (serveur du LAN) qui offrent les services privés du
réseau, à déployer le serveur SVRFWL qui joue le
rôle du pare-feu.
Le résultat de notre travail permet à l'IUT de
Ngaoundéré de disposer d'une architecture réseau
sécurisée, de gérer les équipements hôte
à hôte, de filtrer les paquets à travers un pare-feu, de
garantir aussi la fiabilité des informations circulants dans le
réseau.
INTRODUCTION GENERALE
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
2
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
INTRODUCTION GENERALE
De nos jours, la communication s'effectue dans les entreprises
via les réseaux informatiques. Les réseaux informatiques
permettent et facilitent les échanges des informations à
l'intérieur et à l'extérieur des entreprises à
travers les réseaux locaux (LAN) et les réseaux étendus
(WAN, MAN). L'Institut Universitaire de Ngaoundéré (IUT) dispose
d'un réseau local reliant les salles de travaux pratique et les machines
des enseignants et, d'une connexion Internet pour les échanges des
informations et services du réseau local vers l'extérieur. Vu
l'importance des informations véhiculées dans ces réseaux,
ceux-ci exigent un certain degré de sécurité.
Pour garantir la confidentialité et la fiabilité
des informations échangées et se prémunir des attaques et
intrusions externes, il nous a été demandé de mettre en
place une architecture réseau sécurisée au sein de l'IUT.
L'objectif de ce travail est de proposer une architecture du réseau de
l'IUT, de permettre une communication sécurisée entre
différents postes, de détecter les intrusions et attaques dans le
réseau de l'IUT.
Pour y parvenir nous avons utilisé une démarche
qui consiste à auditer le réseau de l'IUT existant, à
déployer la DMZ (zone démilitarisée) qui offrent les
services publics du réseau, à déployer le serveur SVRLAN
(serveur du LAN) qui offrent les services privés du réseau,
à déployer le serveur SVRFWL qui joue le rôle pare-feu.
Le résultat de notre travail permet à l'IUT de
Ngaoundéré de disposer une architecture réseau
sécurisée, de gérer les équipements hôte
à hôte, de filtrer les paquets à travers un pare-feu, de
garantir aussi la fiabilité des informations circulants dans le
réseau.
Ce mémoire est structuré autour de trois
chapitres : le chapitre 1 revient sur la problématique de
sécurité dans les réseaux d'entreprises et traite le cas
spécifique de l'Institut Universitaire de Ngaoundéré
(IUT), le chapitre 2 présente la méthode utilisée pour la
conception et le déploiement du réseau sécurisé de
l'IUT de Ngaoundéré, le chapitre 3 est consacré aux tests
et implémentations, et enfin nous avons une conclusion et des
perspectives.
CHAPITRE 1 :
PROBLEMATIQUE DE SECURITE
DANS UN RESEAU D'ENTREPRISE
CAS DE L'IUT DE NGAOUNDERE
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
6
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
CHAPITRE 1 : PROBLÉMATIQUE DE
SÉCURITÉ DANS UN RÉSEAU
D'ENTREPRISE : CAS DE L'IUT DE
NGAOUNDÉRÉ
I.1 GENERALITE SUR LA SECURITE
Tout ordinateur connecté à un réseau
informatique est potentiellement vulnérable à une attaque. Une
attaque est l' exploitation d' une faille d' un système informatique
(système d' exploitation, logiciel, erreur de configuration, etc.)
à des fins non connues par l' exploitant du système et
généralement préjudiciables. Sur l'Internet, des attaques
ont lieu en permanence, à raison de plusieurs attaques par minute sur
chaque machine connectée. Ces attaques sont pour la plupart
lancées automatiquement à partir de machines infectées
(par des virus, chevaux de Troie, vers, etc.), à l'insu de leur
propriétaire. Plus rarement il s' agit de l' action de pirates
informatiques.
Rappelons qu'un réseau informatique est un maillage de
micro-ordinateurs interconnectés dans le but du partage des informations
et du matériel redondant. Quelque soient le type de systèmes
informatiques utilisés au sein d'une entreprise, leur interconnexion
pour constituer un réseau est aujourd'hui obligatoire. La constitution
de celui-ci passe par une conception qui consiste à définir
- L'architecture physique si le réseau est inexistant,
ou faire évoluer l'architecture le cas contraire. Il est abordé
ici la cartographie des sites, des bâtiments, des salles devant
être connectés ; de même que les supports physiques et les
équipements actifs.
- L'architecture logique autrement dit la topologie logique,
elle fait référence à toutes les couches du réseau,
les protocoles, le plan d'adressage, le routage.
- Utiliser les services des opérateurs ou des
sous-traitants.
- La politique d'administration et de surveillance des
équipements
- Les services réseaux
- Les outils de sécurité
- La connexion avec l'extérieur : Internet
I. 2. AUDIT DU RÉSEAU DE L'IUT DE
NGAOUNDÉRÉ
L'audit du réseau de L'IUT de Ngaoundéré
vise à établir une cartographie précise du réseau
informatique. Il sera question pour nous de tester les équipements du
réseau (routeurs,
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
7
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Switch, câbles, etc.) afin de produire leur rapport de
performances. Par la suite on pourra proposer une architecture optimisée
du réseau. Les tâches consignées dans cet audit concernent
:
- Inventaire des équipements du réseau - Test de
connectivités des équipements
- Test d'allocation des adresses IP (serveur DHCP, etc.) aux
différents équipements du réseau (poste de travail, etc.)
;
- Test de segmentation du réseau
- Test des services déployés sur le
réseau
- Test de bande de passante
- Test d'intrusion dans le réseau
I. 2.1. ETUDE DE L'EXISTANT
Une meilleure compréhension de l'environnement
informatique aide à déterminer la portée du projet et de
la solution à implémenter. Il est indispensable de disposer
d'informations précises sur l'infrastructure réseau et les
problèmes qui ont une influence au fonctionnement du réseau. Il
est essentiel de disposer d'informations précises sur l'infrastructure
réseau physique et matériel et les problèmes qui ont une
influence sur le fonctionnement du réseau. En effet, ces informations
affectent la décision que nous allons prendre dans le choix de la
solution et de son déploiement. Cette étude consiste à
mettre à découvert, l'analyse qualitative et quantitative du
fonctionnement actuel du réseau informatique. Une telle étude
consiste dans un premier temps à recueillir les informations ; elle est
réalisée à partir d'entretiens ou de questionnaires,
tableaux de bords, catalogues, documentation existante, l'audit du
réseau.
Par la suite on peut passer à une analyse, classer et
donner une vue synthétique de l'ensemble des informations
collectés sur le parc informatique (matériels et logiciels), la
dimension du réseau (LAN : étages, bâtiments, salles, sites
géographiques, diamètre du réseau, interconnexion, WAN,
MAN). Enfin, on peut esquisser une modélisation à grande
échelle des données ainsi obtenues.
L'état des lieux étant effectué, elle
peut aboutir à une critique de l'existant qui analyse les ponts positifs
et négatifs de l'environnement informatique déjà en place
et dégager les améliorations à apporter : les tâches
rendues et les tâches non rendues, les services rendus et les services
non rendus, etc. cette critique sera ainsi un tremplin pour l'analyse des
besoins. Par conséquent, l'étude des besoins consiste à
dégager les critères de migration vers la nouvelle
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
8
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
solution ou de l'implémentation de celle-ci, à
évaluer les divers avantages attendus (retour sur investissement). Elle
est à réaliser sous forme de questionnaire. Cette étude
donne une vue globale des besoins fonctionnels (les besoins qui expriment des
actions qui doivent être menées sur l'infrastructure à
définir en réponse à des demandes) et techniques mais
aussi des besoins des utilisateurs.
I. 2.2. Présentation du réseau de l'IUT de
Ngaoundéré
Le réseau de l'IUT de, est un réseau Ethernet
commuté à 100Mbps, essentiellement basé sur une topologie
étoile. La norme de câblage réseau utilisée est
T568A au détriment de T568B. Il ne dispose d'aucune subdivision en
sous-réseau, ni d'aucun control d'accès au réseau public
pareil qu'au réseau local ; pas de système d'authentification ;
ceci laisse libre cour aux potentiels attaques et vols d'informations dont peut
être victime les ordinateurs de l'administration.
I. 2.3. Architecture du réseau existant
Figure 1 : Architecture du réseau
existant
I.3. RÉSULTAT DE L'AUDIT DU RÉSEAU
EXISTANT
Nous avons remarqué après l'audit du réseau
il en ressort plusieurs problèmes.
I.3.1. sécurité
La sécurité informatique est de nos jours
devenue un problème majeur dans la gestion des réseaux
d'entreprise ainsi que pour les particuliers toujours plus nombreux à se
connecter à Internet. La transmission d'informations sensibles et le
désir d'assurer la confidentialité de celles-ci est devenue un
point primordial dans la mise en place de réseaux informatiques. Nous
avons déterminé les problèmes comme :
- La rechercher d'informations, tout le monde peut
accès au même informatique le directeur s'il est connecté
au réseau.
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Cela peut causer l'interruption qui vise la
disponibilité de l'information pas DOS (déni de
service), interception visant la confidentialité des
informations par capture du contenu, et analyse du trafic à
l'aide d'un sniffer ...
- Le manque de segmentation du réseau en
sous-réseau, il peut aboutir au conflit d'adresse IP dans le
réseau ou à l'épuisement de la plage d'adresse
attribuée au réseau etc.
- Une politique de firewall qui n'a pas été
implémentée, laisse accès une libre circulation aux
paquets non filtrés.
- Manque de système d'authentification (login et mot de
passe...) pour accéder certaines informations confidentielles
- Manque de système centré administrateur par
exemple le contrôle d'adressage d'adresse IP pour un sous
réseau
I.3.2. parc informatique
Dans le parc informatique de l'IUT compte environs une
soixantaine d'ordinateurs de marque HP et Dell sur différents sites
entre autres :
Deux salles Machines (laboratoire) et 4 bureaux d'enseignants
du coté de Génie informatique. A l'entrée une
scolarité qui renferme trois machines et la division des stages qui
renferment une machine et 1 ordinateur dans chaque bureau des responsables de
GIM et GBIO. Les ordinateurs listés renfermaient les
caractéristiques suivantes :
512 - 1Ghz CAPACITE DISQUE DUR
40-350 Go CARACTERISTIQUE PROCESSEUR
2.20-3.20 GHz
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
9
Tableau 1 : caractéristique de la plupart de
poste de travail ? Scolarité
Après le recensement nous avons déterminé
que la scolarité dispose de :
? 3 postes (ordinateurs) de travail ? 1 Switch de 8 ports
? Secrétariat du directeur
Après le recensement nous avons déterminé
que le secrétariat du directeur dispose de :
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
10
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
> 2 postes > 2 ports
? Chef de département de génie
informatique
Dans le bureau du chef de département de génie
informatique nous avons pu recenser :
> 1poste
> 1 port
? Département de génie biologie
Dans le département de génie biologie on a pu
recenser :
> 5 ports
> 2 Switch de 8 ports
? Laboratoire informatique
L'Institut Universitaire de Technologie de
Ngaoundéré dispose de deux laboratoires qui sont :
> Laboratoire de génies informatiques 1 et 2
Ce laboratoire dispose de 16 postes et 2 ports
> Laboratoire de licence professionnelle
Celui-ci dispose d'une baie de brassage de 13 postes et 7ports
Une analyse du réseau de l'IUT nous a permis de
définir un nombre de contraintes pouvant réduire ses performances
ainsi sa dégradation ; et de plus certains de ces contraintes peuvent
être un obstacle à la réalisation de la mission de
l'IUT:
Trafic web important
Volume accru du trafic généré par chaque
utilisateur Accès non restreint aux données de l'administration
Démotivation de certains professeurs
Conflit d'adressage IP
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
11
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
...
I.4. LES SOLUTIONS APPORTÉES
Les solutions que nous avons proposées consistent
à déployer les différents services, sécuriser les
accès à ces services et implémenter une
sécurité accrue à travers un filtrage de paquet au niveau
du firewall et un proxy cache jouant le rôle d'un firewall à
relayage de paquets. Nous proposons également une sécurité
sur un plan global en faisant référence à la mise en place
d'un local technique, la restriction des accès.
L'enjeu principal d'une architecture réseau
sécurisée, est de pouvoir réglementer les accès aux
ressources du réseau tant à partir du réseau local
qu'à l'extérieur, tout en essayant au maximum de limiter les
failles d'éventuelles attaques ou vols d'informations à fin
d'accroître la sécurité du réseau local. En effet,
face à des applications telle la messagerie qui permettent la
mobilité donc les accès d'origine diverse, il est toujours
important de définir une architecture fiable de sécurisation du
réseau. L'implémentation d'une telle architecture aboutira
à un gain en termes de performance et sécurité du
réseau.
I.4.1. Besoins fonctionnels
Les besoins fonctionnels expriment une action qui doit
être menée sur l'infrastructure à définir en
réponse à une demande. C'est le besoin exprimé par le
client; ce besoin peut être exprimé de manière
fonctionnelle mettant en évidence les fonctions de services (pour
répondre à la question «A quoi ça sert ?») et
les fonctions techniques (comment cela peut marcher ?). Dans ce cadre, nous
allons :
· Déployer un serveur DHCP dans le but de
centraliser la gestion de l'adressage et d'éviter des conflits
d'adresses IP,
· Déployer un serveur DNS qui permettra la
résolution de nom dans le réseau local,
· Déployer un serveur Web l'hébergement
des applications web.
· Déployer un serveur mandataire
générique qui va relayer différentes requêtes et
entretenir un cache des réponses. Il permettra aussi de
sécurisé le réseau local,
· Déployer un firewall pour protéger le
réseau interne,
· Déployer un serveur de mail pour la gestion de
la messagerie local,
· Déployer un serveur de fichiers à fin de
mieux gérer les droits d'accès aux informations de
l'école.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
12
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
· Mise en place d'une sonde avec un NDIS (Network detected
Intrusion System) analyse le trafic et prévention d'intrusion du
système.
· Déployer un serveur NTP d'unification du temps.
I.4.2. Besoins non fonctionnels
Les besoins non fonctionnels représentent les exigences
implicites auquel le système doit répondre. Ainsi à part
les besoins fondamentaux, notre système doit répondre aux
critères suivants :
· La simplicité d'utilisation des services
implémentés,
· La centralisation de l'administration,
· La sécurité des accès (local, mot de
passe : longueur, caractères spéciaux, politique de
réutilisation), sécurité wifi,
· La performance du réseau (temps de
réponse),
· La disponibilité (heures de connexion),
· La fiabilité (moyenne de temps de bon
fonctionnement, Le temps moyen de Rétablissement),
· La gestion des sauvegardes (fichiers, mails),
· La documentation du réseau.
Après avoir évoqué les
généralités sur l'administration et de la
sécurité d'un système et décrit le problème
dans le cadre de notre étude, nous nous intéressons dans le
chapitre suivant à la méthode et conception de déploiement
du réseau sécurisé de l'IUT de
Ngaoundéré.
CHAPITRE 2 : METHODE DE
CONCEPTION ET DE DEPLOIEMENT DU
RESEAU SECURISEE DE L'IUT DE
NGAOUNDERE
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
12
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
CHAPITRE 2 : METHODE DE CONCEPTION ET DE DEPLOIEMENT
DU RESEAU SECURISEE DE L'IUT DE NGAOUNDERE
II.1. PHASE DE PLANIFICATION DU DEPLOIEMENT
II.1.1. PLANIFICATION DU DEPLOIEMENT
Une bonne mise en oeuvre des solutions requiert une bonne
planification. Dans cette phase, nous allons présenter le
matériel et les prérequis nécessaires à la mise en
place de la solution.
Il est important de noter les différentes contraintes qui
pourront être rencontrées :
Les services rendus à l'utilisateur doivent être
interrompu le moins longtemps possible pendant les heures de travail
L'accès aux pages web ne doit pas être de
piètre performance du fait de la mise en place de la DMZ.
II.1.1.1. Prérequis
Dans ce document il est question de créer des serveurs
particuliers, ce qui requiert dans un environnement Unix la connaissance de
certaines commandes, une certaine connaissance sous l'utilisation est
recommandée, cela facilitera la prise en main et ainsi une manipulation
facile du système Unix.
II.1.1.2. Modèle de réseau
d'entreprise
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
13
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 2 : Modèle de réseau
d'entreprise
Elle dispose d'un ou plusieurs réseaux internes, d'un
site web avec serveur de messagerie accessible de l'extérieur dans une
zone communément appelée DMZ ou zone démilitarisée.
Cette zone est séparée pour un but de sécurité.
Les serveurs de l'école offrent aussi d'autres
services comme la résolution DNS (on suppose le nom de domaine
déposé et résolu pour l'extérieur par
l'école), des services plus internes comme NFS, NIS, SAMBA, LDAP, DHCP,
etc.
Bien sûr nous nous heurtons tout de suite à un
problème : celui des moyens ! Il est rare de posséder autant de
machine que décrit dans le modèle.
Nous devons aboutir à un modèle pratique
limitant au maximum le nombre de machine. On peut ramener le nombre de machine
à quatre. Bien sûr, le modèle subit des modifications
importantes par rapport à une situation d'entreprise, mais l'esprit de
la structure reste et avec les principales configurations des services. Comme
la démarche de réalisation est acquise, votre adaptions à
une autre modèle s'effectuera sans problème.
II.1.1.3. Architecture de déploiement
A travers le logiciel Microsoft Visio, nous avons reproduit
notre environnement de travail (figure 3) .Cet environnement nous permettra
d'aboutir à une bonne configuration de notre solution.
II.1.2. LES DIFFERENTS SERVICES ET L'ADRESSAGE
II.1.2.1. Services
Vu les contraintes de matériels, nous avons
cumulé plusieurs services sur un des serveurs. Nous avons opté
pour une plate-forme open source, ainsi tous les logiciels que nous avons
utilisés pour déployer les services sont des logiciels
open-source. Le modèle auquel nous allons aboutir est comme:
Nous aurons en trois réseaux
? Le réseau externe pour l'accès
à Internet.
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
? Le réseau local entre le serveur pare-feu (n°3
que l'on va nommer SVRFWL), le serveur du réseau local (n°1 que
l'on va nommer SVRLAN) et le(s) client(s) nommés (CLIENT).
? Le réseau liant le serveur de la DMZ (n°2 que
l'on va nommer SVRDMZ) au serveur pare-feu (SVRFWL).
II.1.2.2. Adressage
Le plan d'adressage IP que nous avons utilisé est le
suivant :
? Le réseau Pare-feu/DMZ en 192.168.2.0,
masque 255.255.255.0 ? Le réseau Pare-feu/LAN en
192.168.3.0, masque 255.255.255.0
Pour le réseau d'accès vers l'extérieur
elle dépend, nous matérialiserons la sortie vers
l'extérieur par une liaison avec le routeur /Modem, elle correspond
à celui fourni par FAI et la plupart des modèles proposent une
configuration DHCP (attribution à la volée d'une adresse IP) mais
aussi une adresse IP fixe. Le réseau proposé est
généralement le 192.168.0.0 avec un masque de
classe C soit 255.255.255.0
Nous fixons l'adresse 192.168.254.0 pour le réseau
WAN
Voici le schéma pratique du réseau de notre
entreprise que nous allons monter au fur et à mesure et que l'on nommera
VIRTUALIUT
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
14
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
15
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 3 : Architecture du réseau de l'IUT de
Ngaoundéré
II.1.2.3. plus de détails sur les serveurs et
les clients Le serveur numéro 1 : SVRLAN
Normalement le serveur principal de notre réseau
interne, il se charge en priorité et en premier lieu de
l'authentification des utilisateurs sur :
- Le client Windows avec Samba : partage de fichiers et
contrôleur principal de domaine, serveur d'impression
- Le client linux avec le couple NIS/NFS : pour
l'appartenance à un domaine et le partage de fichiers.
- Puis avec une amélioration plus professionnelle :
les deux types de clients avec LDAP (service d'annuaire)
Il sert aussi de serveur DNS secondaire sur la zone de
l'entreprise et, vis-à-vis des clients, il dispose du service DHCP en
distribuant les adresses IP. Il cumule aussi les fonctions de serveur LDAP, et
de serveur VPN. On peut aussi ajoute la notion de serveur de temps (serveur
NTP) pour une uniformisation de l'heure sur nos différents
réseaux.
Le Serveur numéro 2 : SVRDMZ
Ce serveur se situe dans une zone communément
appelée DMZ, c'est-à-dire une zone tampon d'un réseau
d'entreprise, située entre le réseau local et l'Internet,
derrière le Pare-feu. Cela correspond à un réseau
intermédiaire regroupant des services publics (HTTP, SMTP, FTP, etc.) et
enclavé de façon à prévenir toute attaque venant de
l'extérieur sur le réseau interne.
Il sert de serveur DNS principal vis-à-vis de
l'extérieur. Dans le monde réel cela veut dire que l'entreprise a
déposé et (payé) auprès des autorités
compétentes (AF-NIC) son nom de domaine et qu'elle est maître de
sa zone. Dans notre cas, nous passerons par un serveur DNS tiers. Ensuite, on
implémentera une infrastructure de type split DNS (plusieurs vues). La
création d'une zone pour la résolution locale (celle du
réseau interne) et l'autre pour la résolution externe
(Internet).
Les services fournis seront, outre le DNS : les pages web
pour le site de l'entreprise avec liaison sur une base de données via le
langage PHP, l'accès à un serveur de base de données de
type SGBDR, le filtrage des pages web externes via le, le courrier aussi bien
interne qu'en externe, la
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
16
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
possibilité de transfert de fichiers par FTP ou sous la
forme de distribution collaborative par le serveur CVS
- Serveur DNS principal avec BIND9 ;
- Serveur Web avec APACHE2 et proxy avec SQUID ;
- Serveur base de données avec MySQL ;
- Serveur de courrier avec Postfix (SMTP), serveur POP3 et IMAP
;
- Serveur de fichiers FTP ;
- Serveur CVS.
Le serveur numéro 3 : SVRFWL
Il joue le rôle de Pare-feu, de routeur logiciel pour
notre réseau. Il effectue la translation d'adresse IP (NAT)
vis-à-vis de notre réseau interne.
Sa principale fonction sera de filtrer les accès et
trafic sur ses trois interfaces réseaux. Construit en dernier, il peut
s'installer sur une machine peu performante n'ayant pas une activé
très grande.
- Pare-feu (Firewall) principal - routeur
II.2. MISE EN OEUVRE DE L'ARCHITECTURE DE VIRTUALIUT
II.2.1. Configuration réseau d'un serveur Linux
En règle générale le système Linux a
dû détecter le pilote de périphérique Ethernet
adéquat.
Concepts mis en oeuvre configuration
réseau, routage, NAT
Machine utilisée SVRLAN
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
17
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 4 : Configuration IP du serveur
SVRLAN
II.2.1.1. l'installation de la carte réseau
Le module correspondant à notre
périphérique de carte réseau est eth0 est
détecté à l'installation du système et
chargé. Cela peut être vérifié par la commande
Figure 5 : vérification de la carte
réseau du serveur SVRLAN II.2.1.2. le routage sous Linux Ubuntu
- . la table de routage
Les machines ont besoins de « parler » avec des
ordinateurs situés sur d'autre réseaux et évidemment le
réseau des réseaux : Internet, une route à travers une
passerelle (ou porte de sortie) doit être définie.
- Par une table de routage statique, gérée par
l'admirateur dans un le cas d'un nombre réduit de passerelle
- Par une table de routage dynamique, construite par des
protocoles de routage dans les autres cas.
- Route par défaut et route statique
Dans le cas classique d'un réseau où l'une des
machines fait fonction de routeur (ou alors d'un équipement de type
commutateur/routeur) pour l'accès à l'Internet, il faut
configurer un route statique par défaut pour les accès externes.
Rappelons le routeur sera dans ce cas appelé passerelle.
Elle se fait par la commande route
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
18
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 6 : Augmentation de la route statique
II.2.2. la translation d'adresse IP ou NAT
L'acronyme NAT se forge à partir des initiales de
Network Adress Translation, ou « Translation d'adresse Réseau
». Fondamentalement, NAT modifie l'adresse IP dans l'en-tête d'un
datagramme IP effectuée par le routeur. Le fonctionnement est qu'il
offre deux avantages certains :
- Masque les adresses IP vis-à-vis de
l'extérieur (pour la sécurité et il permet de s'affranchir
de la gestion des tables de routage, le NAT s'en occupe)
- Le serveur DNS sur le réseau n'aura (et ne
connaîtra) que l'adresse IP du routeur de votre réseau. Ce dernier
se chargera de la transmission des trames IP sur son réseau interne.
II.2.3. mis en place du serveur SVRLAN II.2.3.1.
L'activité
Nous allons modifier la configuration réseau de notre
serveur SVRLAN en ajoutant une nouvelle carte réseau à la machine
et la fonctionnalité de routeur/NAT.
II.2.3.2- configuration réseau du serveur
SVRLAN
Il nous suffit de changer la configuration du fichier
/etc/network/interfacess pour l'interface eth0 qui
montre au départ une configuration en DHCP et que nous
allons passer en statique :
Figure 7 : configuration de l'interface réseau
eth0 du SVRLAN
Nous procèderons de la même manière pour
interface eth1 à la seule différence que
:
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
19
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 8 : configuration de l'interface réseau
eth1 du SVRLAN
II.2.3.3. Transformation de SVRLAN en routeur
Il va falloir penser aux autres machines de votre réseau
et faire transite les paquets arrivant par eth1 vers
eth0. Juste en tapant la commande positionnant un drapeau pour
le processus ip_foward :
[root]# echo 1 >
/proc/sys/net/ipv4/ip_foward
Le résultat est immédiat mais temporaire, car
annulé au redémarrage du système, il faut le rendre
définitif par la modification du fichier de configuration
/etc/sysctl.conf (la ligne
net.ipv4.conf.default.forwarding=yes). Après cela notre mini
réseau peut communiquer avec l'extérieur, il reste à faire
la translation d'adresse
II.2.3.4. Mis en place de la translation d'adresse
(NAT)
NAT fonctionne avec le service iptables. On
retrouvera ce service lors de la configuration du pare-feu. On s'assure que le
paquet est vraiment là par la commande:
Figure 9 : vérification de la présence du
paquet Iptables
Il nous reste saisir la commande suivante
[root]# Iptables -t nat -A POSTROUTING -o eth0 -i
MASQUERADE Ce qui s'explique par:
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
20
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
-t nat pour indiquer l'utilisateur de la table NAT.
-A POSTROUTING pour ajouter la règle sur les
paquets sortant de l'interface.
-o eth0 pour indiquer l'interface (celle sur
l'extérieur).
-i MASQUERADE pour indiquer l'échange de
l'adresse IP avec celle du serveur.
Il nous reste à relance notre système et
vérifier l'existence de la règle NAT à l'aide de la
commande iptables -t nat -L
II.2.4. configuration d'un serveur de dépôts
de paquetages
Installer et gérer plusieurs distributions Linux devient
vite fastidieux et Ubuntu ne déroge pas à la règle.
Plusieurs aspects que l'on peut traiter différemment sont à
prendre en compte : l'installation proprement dite, automatisée ou non,
soit par un support type CD-Rom soit par le réseau ; l'installation
ultérieure de paquetages avec le choix de la source et les mises
à jour.
Concepts mis en oeuvre apt, rsync, debmirror,
Apache
Machine utilisée SVRLAN, SVRDMZ
II.2.4.1. Pourquoi construire un serveur de
dépôts ?
Dans une entreprise où l'on se retrouve avec un nombre de
PC élevé tournant sous Ubuntu, cela minimiserai les temps de
transferts de mises à jour tout en ayant la maîtrise exacte des
paquetages distribués
II.2.4.2. La démarche Cela consiste à
:
- Choisir les répertoires de dépôts (par un
script bash)
- Miroiter (mirroring) un serveur officiel avec debmirror et
rsync
- Exporter ces répertoires pour les clients via un
serveur http, ftp, rsync
II.2.4.3. L'organisation
Un dépôt est un serveur qui contient un ensemble de
paquets. On peut avoir
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
21
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
- Main : paquets
supportés officiellement ;
- Restricted : paquets au
copyright restreint (exemple ; pilote spécifique à un
matériel) : - Universe : paquets en licence
GPL mais non supportés officiellement ;
- Multiverse : paquets non libres et
non supportés.
II.2.4.4. L'utilitaire de synchronisation rsync
Cet outil permet la synchronisation des répertoires ou
plus exactement s'utilise afin de sauvegarder automatiquement sur un serveur ou
un disque dur externe des fichiers. Pour qu'existe une synchronisation, il faut
qu'il y ait un serveur rsync, côte serveur et client car
celle-ci n'est pas installé par default.
II.2.4.5. Préparation du serveur de
dépôts
Le serveur sert de serveur de dépôts pour les
mises à jour de toutes les machines Linux. Nous allons aussi ajouter le
serveur SVRDMZ à notre réseau « derrière » le
serveur n°1 et branché sur son interface eth1.
Figure 10 : Extension du réseau de l'entreprise
VIRTUALIUT
Nous remangeons qu'un autre serveur s'ait augmenté,
sur notre schéma, nous pouvons passer à la section d'installation
du serveur SVRDMZ. Mais avant cela, nous devons préparer le serveur de
dépôts qui est SVRLAN.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
22
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
II.2.4.6. Constriction du miroir
Après avoir créé un répertoire et
ainsi la table de partition suivante le point de montage pour accueillir nos
paquets, (chose nous avons choisir d'omettre dans le paragraphe
précédente) nous devons commence par installer le paquet
debmirror :
[root]# apt-get install debmirror
Les commandes rsync sont très complexes aussi il est
indispensable d'écrire un script en Shell BASH pour gérer la
création du miroir comme celle-ci-dessous :
Figure 11 : Extrait du script pour la création du
miroir
Après cela nous pouvons modifier notre source liste et
remplacez toutes les lignes par : # sources à partir du miroir
SVRLAN
deb file:/core/lucid main restricted
deb file:/core/ updates lucid-updates main restricted deb
file:/core/ security lucid-security main restricted
# sources à partir du de l'extérieur
deb
http://fr.archive.ubuntu.com/ubuntu/
lucid universe deb
http://fr.archive.ubuntu.com/ubuntu/
lucid-updates universe
deb
http://fr.archive.ubuntu.com/ubuntu/
lucid-security universe
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
23
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
II.2.4.7. Configuration du miroir pour les autres
machines
Pour compléter la démo, nous encore agrandir
une fois de plus notre réseau, qui commence petit à petit
à prendre former. Actuellement nous disposons d'un SVRLAN avec deux
cartes réseaux, l'une vers l'extérieur (eth0
192.168.254.10) et l'autre vers le réseau interne (eth1
192.168.2.1). Nous avons choisi pour les tributaires de notre miroir la
méthode http, ce implique l'installation d'un serveur web,
Apache2. Deux modifications sont capitales après
l'installation; il faut modifier le fichier
/etc/apache2/sites-enabled/000-default. Les lignes oû nous avons
comme désignqtion de réportoire /var/www pour la
remplacer par /core :
# DocumentRoot /core Et
#Directory /core
II.2.4.8. installation du serveur SVRDMZ
Puisque nous n'avons pas encore installé et
configuré le service DHCP pour la distribution d'adresse sur le SVRLAN,
ainsi nous devons spécifier le même DNS que pour SRVLAN car nous
ne disposons pas encore du serveur DNS, nous devons entrer manuellement la
configuration réseau par l'option de configurer nous même le
réseau en utilisant les renseignements suivants
Adresse IP : 192.168.2.2
Masque de sous-réseau : 255.255.255.0
Passerelle : 192.168.2.1
DNS : 192.168.254.2
Nom de machine : SVRDMZ
La configuration finale se déroule classiquement, en
testant le réseau par les commandes habituelles (ifconfig,
ping).
II.2.5. Installation de deux systèmes sur un PC
Comme nous sommes dans une configuration d'étude et
non dans d'une situation de production en entreprise, autrement dit, prenons
ça un prototype. Le but premier est de pouvoir disposer de deux
systèmes clients afin de montrer deux approches différentes, la
deuxième raison
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
24
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
est inhérente à l'architecture client/serveur :
montrer comment fournir des services réseau) des postes clients.
II.2.5.1. L'activité
Troisième étape dans l'agrandissement de notre
réseau : l'installation des deux clients. Ils auront le même nom :
CLIENT. Nous devons ajouter une nouvelle carte réseau au serveur SVRLAN,
ce qui lui fera trois, sur le réseau. Configurons la nouvelle interface
augmentée.
II.2.5.2. Configuration de la troisième carte
réseau de SVRLAN
Comme nous avons fait les deux précédentes
configurations des cartes eth0, et eth1 ;
auto eth2
iface eth2 inet static
address
|
192.168.3.1
|
netmask
|
255.255.255.0
|
network
|
192.168.3.0
|
broadcast
|
192.168.3.255
|
|
II.2.5.3. Installation du client Windows
L'installation du système Windows étant
triviale. Nous effectuons l'installation classique de la station en respectant
cependant les points suivants et en spécifiant cependant les
paramètres
du réseau suivant :
|
|
Adresse IP :
|
192.168.3.10
|
Masque de sous-réseau :
|
255.255.255.0
|
Passerelle :
|
192.168.3.1
|
DNS :
|
192.168.254.2
|
Nom de machine :
|
client
|
|
II.2.5.4. installation du client Linux
Le client Linux va recevoir un système Ubuntu
10.04 plus adapté à la configuration d'un poste de
travail. La particularité de cette version d'Ubuntu est qu'elle se
présente en système LIVE.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
25
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 12 : Schéma du réseau VIRTUALIUT
avec les clients
Dans ce chapitre nous avons présenté la
méthode de conception de l'architecture réseau. Dans le chapitre
suivant nous parlerons de déploiement et test de l'architecture
réseau conçue.
CHAPITRE 3 : DEPLOIEMENT ET
TEST DE L'ARCHITECTURE RESEAU
SECURISEE
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
26
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
CHAPITRE 3 : DEPLOIEMENT ET TEST DE
L'ARCHITECTURE
RESEAU SECURISEE
III.1. Installation du service DNS
Notre réseau commence à prendre forme ; toutes
nos machines sont installées et opérationnelles. Le service DNS
se met en place au début afin d'identifier l'ensemble des composantes de
votre réseau et faciliter l'accès vers l'extérieur. Nous
avons opté pour deux DNS : l'un principal et l'autre en cas de panne du
premier.
III.1.1. Avant l'installation du service DNS
Rappel : on peut bien se
passé du DNS dans le cas des petits réseaux en utilisant le
fichier /etc/hosts de chaque machine. Dans ce cas il faut
renseigner la correspondance entre l'adresse IP et le nom de la machine
manuellement. Cela est valable pour le client Linux et le client Windows (le
fichier se trouve dans le répertoire
c:\WINDOWS\system32\drivers\etc.).
Sous linux, il faut de toute façon mettre deux lignes dans
le fichier /etc/hosts lorsque l'implante un service
DNS : Exemple : pour un serveur DNS de nom Ubuntu et de Zone testdns et @ip
192.168.1.1
Figure 13 : configuration du fichier hosts du
serveur
Ceci consiste à faire la résoudre le nom de la
machine par elle-même : en gros, elle doit connaitre son nom ! Dans le
cas d'un client qui obtient son adresse IP par DHCP mais ayant bien sûr
un nom, on peut écrire :
Figure 14 : configuration du fichier hosts du
client
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
27
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
III.1.2. Installation du DNS sur le serveur SVRLAN
Nous allons mettre en place un service DNS, le serveur SVRLAN va
fournir le service DNS principal.
III.1.2.1. Installation de Bind9
Installation se fait comme tous les autres paquets, nous avons
les fichiers de configuration suivants :
- etc/bind/name.conf qui est le fichier
général ;
- etc/bind/named.options qui est le fichier
contenant les options de Bind ; - etc/bind/named.local qui est
le fichier contenant notre zone
Précisons qu'Ubuntu « éclate » le
fichier de configuration en trois alors que cela n'est pas le cas sous d'autres
distributions.
- configuration dans le ficher
/etc/named.conf
Figure 15 : contenu du fichier named.conf
Le fichier /etc/named.conf contient quatre zones
faisant référence à la zone de la boucle locale suivant la
spécification de RFC 1912et dont l'utilité est de traiter les
requêtes accidentelles (ou usurpées) pour le broadcast ou les
adresses locales.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
28
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Les deux dernières zones dans le ficher
named.conf.local traitera de la zone virtualiut.lan
(qui est notre zone)
- Configuration dans le fichier
/etc/bind/named.conf.local
Figure 16 : contenu du fichier
named.conf.local
- création du fichier pour la zone directe pour
nos machines
Figure 17 : configuration du fichier virtualiut.db
- Création du fichier pour la zone inverse
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
29
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 18 : configuration du fichier inverse de
virtualiut.db
Cela est aussi recommandé de modifier ou de changer le
groupe propriétaire d'un fichier, elle est effectuée par la
commande : chgrp bind /var/cache/bind/*
Redémarrons le service et modifions le fichier
/etc/resolv.conf qui contient les suivantes :
Figure 19 : contenu du fichier resolv.conf
Rappelons que la directive search fait ajouter le
domaine virtualiut.lan par défaut aux demandes avec un nom
d'hôte non entièrement qualifié. Ensuite, notre serveur DNS
sera interrogé et, lorsque le temps imparti à la requête
sera dépassé, le serveur secondaire sera interrogé.
Gardons de vu que ce mécanisme n'est valide si et seulement si le
premier serveur n'a pas répondu dans le temps et non en cas d retour
avec une erreur. Dans ce cas celle-ci est transmise au client et le
deuxième serveur ne sera pas interrogé. Maintenant nous pouvons
lance notre service et ainsi vérifié les fichiers logs (ce
fichier est très important pour un administrateur réseau)
On peut avoir une petite idée du fonctionnement du
service DNS, et nous allons le rendre plus performant! Actuellement, il
s'occupe des résolutions de la zone virtualiut.lan mais aussi
des résolutions externes pour les machines de notre réseau et
construit donc son cache n fonction. De façon à réduire sa
charge de travail, nous pouvons faire en sorte que cette seconde tâche
soit dévolue au serveur DNS "au-dessus de lui".
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
30
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
- Supprimons la référence au DNS externe dans le
fichier /etc/resolv.conf
Figure 20 : configuration du fichier
resolv.conf
- Commentons les lignes ayant trait aux serveurs racines dans le
fichier /etc/bind/named.conf
- Modifions les lignes suivantes dans le fichier
/etc/bind/named.conf.options
Figure 21 : configuration du fichier
named.conf.options
Relançons les services réseau et DNS et testons
à nouveau une résolution externe à partir du serveur
SVRLAN et partir du CLIENT Windows en lui indiquant que 192.168.3.1 comme
serveur DNS.
III.1.3. Configuration du serveur SVRDMZ en serveur DNS
secondaire
La mise en place d'un serveur secondaire s'effectue de la
même façon que pour un serveur principal. Pour pallier un
arrêt du service sur le serveur principal, nous utilisons SVRDMZ comme
serveur secondaire sur la zone virtualiut.lan, en cas de panne
complète du serveur principal, le serveur secondaire ne sert à
rien car il se sert de SVRLAN pour l'accès à l'extérieur
et même au réseau interne...
III.1.3.1. Installation du DNS secondaire
Plusieurs changements seront apportés sur le DNS
principal SVRLAN :
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
31
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 21 : nouvelle configuration du fichier
named.conf
Au niveau du fichier de zone db.virtualiut.lan,
ajoutons le serveur secondaire comme faisant
autorité : @ IN NS svrdmz.virtual.lan
Et ainsi pour la zone inverse : @ IN NS
svrdmz.virtual.lan
III.1.3.2. Installation du le serveur DNS secondaire sur
SVRDMZ
Nous devons procéder comme pour le serveur SVRLAN
(installation et sauvegarde des fichiers de configuration). Nous devons
modifier /etc/bind/named.conf.options de la même façon
que pour SVRLAN en ce qui corcerne les instructions forward et
forwarders mais avec un changement sur allow-recursion pour
explicitement indiquer les réseaux autorisés :
Figure 22 : nouvelle configuration du fichier
named.conf.options
Modifions le fichier /etc/bind/named.conf de la
même façon ; ainsi que
/etc/bind/named.conf.local pour la declaration en
serveur secondaire.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
32
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 23 : nouvelle configuration du fichier
named.conf.local
Modifions le fichier /etc/resol.conf cette fois
SVRDMZ sera son propre serveur DNS : nameserver192.168.2.2
Et pour finir le fichier /etc/hosts :
127.0.0.1 localhost
192.168.2.2 svrdmz.virtualiut.lan svrdmz
III.1.3.3. Simulation de panne
Pour simuler un panne, il est très simple pour voir le
fonctionnement du DNS secondaire, il nous suffit d'arrêter le service DNS
sur SVRLAN via la commande : /etc/init.d/bind9 stop
Nous devons toujours accéder à Internet
à partir du client, car cette fois ci c'est le serveur SVRDMZ qui a pris
le relais.
III.2. Service DHCP et DNS dynamique
DHCP constitue la suite logique au DNS dans l'élaboration
d'un réseau. Cela ne concerne bien sûr que les ordinateurs sur
notre réseau local. Le service DHCP donne le « la »en
transmettant adresse IP, adresse du serveur passerelle, du serveur de temps,
etc.
III.2.1. Installation du service DHCP sur le serveur
SVRLAN
Le principe de base consiste à affecter dynamiquement
une adresse IP à chaque client avec différents paramètres
tels que serveurs DNS, passerelle par défaut, etc. cette allocation
possède une durée limitée : le bail, renouvelé
suivant un intervalle défini. De son côté, le client
libère cette adresse quand la session se termine.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
33
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
III.2.1.1. Installation du paquet dhcp3-server
Le serveur SVRLAN servira de serveur DHCP pour les clients du
réseau local, aussi bien Windows que Linux. Nous devons sauvegarder le
fichier de configuration par défaut qui est dhcpd.conf
Figure 24 : copie du fichier de configuration du DHCP
- Configuration du fichier pour le DHCP
Figure 25: configuration du fichier
dchpd.conf
III.2.1.2. Agent relais DHCP
Un agent relais DHCP écoute les requêtes
d'amorçage DHCP et les transfère à un serveur DHCP. Il
doit se trouver sur le même segment de réseau que le client DHCP
mais forcement sur celui du serveur car la communication s'établit cette
fois avec l'adresse IP. Le relais DHCP s'exécute par la commande
dhcrelay. Le paquetage dhcp-relay sur ubuntu. :
- Le script /etc/init.d/dhcp-relay
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
34
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
- Le fichier de configuration
/etc/default/dhcp-relay
Figure 26 : configuration du fichier
dhcp-relay
On peut supprimer l'attribution statique de l'adresse
192.168.3.10 pour le DNS au niveau du fichier db.virtualiut.lan et
rev.virtualiut.lan, rerlançons le service DNS et
SVRLAN et sur SVRDMZ.
On peut si l'on désire réserver une ou
plusieurs adresses IP de la plage d'adresses dans le cas par exemple du
directeur et ton staff ou d'un serveur d'imprimante. Exemple de
réservation en fonction de l'adresse MAC
Figure 27 : exemple d'adresse statique fixée pour
un utilisateur III.2.1.3. DNS dynamique pour le client LINUX
Il suffit d'un ajout sur le client au niveau du fichier de
configuration DHCP client, l'ajout se fait sur le fichier dhclient.conf
du client Linux :
Figure 28 : configuration du fichier dhclient du
CLIENT
III.3. Installation d'un serveur de temps avec NTP
Pour un réseau, le principe d'un serveur de temps permet
à toutes les machines d'être synchronisée au niveau de la
date et l'heure système ce qui facilite la tâche dans certaines
mis à jour, des fichiers logs.
III.3.1. Principe d'un serveur NTP
Le service NTP (Network Time Protocol) se base sur un serveur de
référence afin de régler son heure système. Il est
formé de plusieurs strates car, chaque serveur se synchronise
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
35
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
avec un élément au-dessus de lui et synchronise
les éléments en dessous de lui, cela implique chaque serveur joue
aussi le rôle d'un client. Nous allons installer le
service NTP sur le serveur SVRLAN de façon à ce que le serveur
SVRDMZ et le CLIENT puissent s'y référer afin de se
synchroniser.
III.3.1.1. Installation du paquet NTP
[root]# apt-get install ntp-server
ntp-doc
Cette commande a pour effet d'installer le serveur avec
dépendances ntp (utilitaire) et ntp-simple (démon)
et sa documentation.
- Configuration du serveur
Elle passe par le fichier /etc/ntp.conf
Nous avons trois serveurs de temps de niveau (strate) 2
normalement disponibles, le mot clé prefer indique le serveur
interrogé de préférence. Pour continuer nos configuration
nous devons stopper le service par : /etc/init.d/ntp-server
stop
Figure 29 : configuration du fichier
ntp.conf
- La synchronisation force
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
36
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Lors de la toute première demande de synchronisation,
le serveur peut présenter des écarts importants, pouvant
entraîner un problème se démarrage. Le service ntpdate
ne s'installe pas au démarrage pour le serveur. Il faut indique
dans son fichier de configuration /etc/defautl/ntpdate comme
NTPSERVERS le serveur NTP d'Ubuntu.
Figure 30 : configuration dans le fichier
ntpdate
Synchronisions directement notre serveur par la commande :
ntpdate -dv
fr.pool.ntp.org,
après cela nous pouvons redémarrer notre service
NTP.
III.3.1.2. Synchronisation du client
Cette à réalise sur chaque système,
prenons le serveur SVRDMZ en tant que client, et indiquons la
référence à SVRLAN dans le fichier
/etc/default/ntpdate du serveur SVRDMZ
Il est recommandé toujours de renseigner l'adresse IP au
nom DNS car NTP a quelque fois des problèmes avec la résolution
de nom, ensuite lançons la commande ntpdate -dv 192.168.2.1
pour effectuer la synchronisation
Figure 31 : Synchronisation de SVRDMZ sur
SVRLAN
III.4. Installation d'un serveur d'annuaire LDAP
Quel que soit le système, Windows ou Linux, le
système d'information de l'entreprise s'adapte et s'intègre au
réseau informatique au travers d'une structure d'annuaire.
Active Directory de Microsoft et de façon plus
naturelle Linux, utilisent le service d'annuaire LDAP
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
37
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
(Lightweight Directory Acess Protocol). LDAP
est un protocole permettant l'accès à l'information contenue dans
l'annuaire ; en cela un serveur LDAP n'est pas uniquement un serveur d'annuaire
mais peut aussi être un serveur d'authentification et de
définition de droits. Le service d'annuaire LDAP se base donc
classiquement sur un modèle client/serveur. Pour concevoir un annuaire
LDAP, il faut une analyse préalable qui va permettre de
déterminer l'organisation de notre système et sa
représentation sous forme arborescente.
- Détermination du schéma de l'entreprise
dc=virtiualiut, dc= lan
ou=sites
ou=groupes ou=utilisateur
ou=ordinateurs
III.4.1. installation du paquetage du service LDAP
Par défaut l'installation du paquet va utiliser le
domaine virtualiut.lan, il nous sera simplement demandé le mot
de passe de l'administrateur LDAP et sa vérification.
Figure 31 : installation du paquet sldap
III.4.1.1. Configuration du service LDAP
La configuration générale du service se trouve
dans le fichier /etc/ldap/slapd.conf, pour un debut nous devons
vérifier le contexte de nommage qui identifie l'entre racine de
l'arbre ; ici, nous le faisons correspondre au nom de domaine local,
cela sera renseigné sur le fichier /etc/ldap/slapd.conf au
niveau du suffixe :
Il faut à nouveau déterminer le mot de passe,
crypté de préférence afin de l'inclure dans le fichier de
configuration.
Lançons l'utilitaire de création de mot de
passe LDAP avec retour dans un simple fichier texte nommé pass.txt,
après l'entrée du mot de passe et de sa vérification,
celui-ci se trouve dans le fichier pass.txt, éditons à
nouveau le fichier slapd.conf et à la suite des
précédents
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
38
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
modifications, ajoutons rootpw sur la ligne suivante
et insérons à partir de nano le contenu du fichier
pass.txt
Figure 32 : copie du mot de passe sur
pass.txt
Ensuite vérifions le paramétrage de
l'accès en écriture de la base par la présence des lignes
suivantes :
Figure 33 : paramètre de l'accès en
écriture Vérifions aussi l'accès en lecture seule
de la base
Figure 34 : paramètre de l'accès en
lecture
Il nous reste qu'a lancé le service par la commande
/etc/init.d.slapd restart
III.4.1.2. Utilisation du serveur LDAP
Une fois l'annuaire configuré et lancé, nous
avons un annuaire des plus simples : le tronc, et aucune entrée.
Même si nous disposons de clients graphiques, nous allons dans un premier
temps utiliser la ligne de commande pour manipuler notre fichier LDIF. La
commande pour visualiser l'ensemble de l'annuaire est ldapsearch -x -b
"dc=virtualiut,dc=lan"
- Définition de la structure de l'annuaire au
format LDIFF
Ce format de fichier est utilisé pour faire des
imports/exports entre plusieurs bases ou pour modifier ou ajouter des
données dans une base. Pour ce faire nous devons vider le contenu de
l'annuaire LDAP existant situé dans le fichier /var/lib/ldap ;
ensuite créer le fichier LDIFF correspondant à la structure
de notre annuaire. (nom du fichier: virtualiut.ldiff)
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
39
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 35 : Définition de la structure de
l'annuaire au format LDIFF
Nous pouvons maintenant ajouter notre annuaire à la base
LDAP par le biais de la commande :
Ldapadd -x -W -D "cn=admin,dc=int,dc=virtualiut,dc=lan" -f
virtualiut.ldiff - Ajout Manuel d'une fiche
Ajoutons une fiche d'utilisateur pour un utilisateur Linux
existant, cela s'effectue toujours grâce au fichier ldiff (utilisateur
User_Linux1). Pour ajouter notre utilisateur User_Linux1, il s'effectue par la
commande adduser
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
40
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 36 : ajout d'une fiche utilisation
Nous devons créer le fichier User_Linux1
(User_Linux1.ldiff),
Figure 37 : création d'une fiche pour un
utilisateur user_linux1
Nous pouvons procéder à la suppression d'une
entrée, pour cela il ne faut que deux lignes : la ligne du dn
et celle de changeType positionnée à
delete, ainsi que modifier, faire une recherche d'une entrée par la
commande :" ldapsearch -x -b ou=utilisateurs, dc=virtualiut,dc=lan"
"cn=*"
III.4.2. Authentification des utilisateurs par LDAP
Le but principal de LDAP se révèle dans la
gestion des utilisateurs. La démarche consiste à centraliser les
comptes utilisateurs sur un unique serveur et d'autre part ce même
mécanisme pour tout autre service désirant une validation
utilisateur. LDAP supporte le chiffrement SSL et coopère parfaitement
avec les applications Samba, DNS, NFS... avec plus concrètement la
gestion dans le cadre d'une authentification utilisateur :
- Des accès non autorisés (authentification) ;
- Des droits d'accès aux données (autorisation)
;
- De la confidentialité et de l'intégré des
communications avec le serveur.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
41
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Nous allons mettre en place l'authentification utilisateurs
par LDAP sur SVRLAN pour le CLIENT. Sous Linux, cette authentification
s'effectue par l'intermédiaire de deux outils : NSS (Name Service
Switch) et PAM (Pluggable Authentication Module). Nous rajouterons ensuite la
couche SSL mais dans une autre fiche axée sur la
sécurité.
III.4.2.1. Authentification par PAM-LDAP
Le système PAM intègre de façon
transparente les technologies classiques d'authentification sur des services du
système (comme entre autre login, ftp, ssh...) et ce, sans
aucune modification sur ces services. Bien évidement nous avons besoin
de paquets sur le serveur SVRLAN
Figure 38 : installation du paquet ldap
- Configuration des différents
fichiers
Ajouter LDAP comme d'authentification pour passwd,
group, et shadow dans le fichier /etc/nsswitch.conf :
Figure 40 : création d'un groupe
d'utilisateur
/etc/pam_ldap.conf et /etc/libnss_ldap.conf
Figure 41 : configuration du fichier
ldap.conf
Nous allons maintenant configurer les fichiers PAM qui est
une phase un peu délicate : qui sont /etc/pam.d/common-account,
/etc/pam.d/common-auth, /etc/pam.d/common-password, /etc/pam.d/common-session,
il est très recommandé de mettre les lignes existantes en
commentaire.
? Fichier /etc/pam.d/common-account ajouter les lignes
suivantes account sufficient pam_unix.xo md5
account required pam_ldap.so use_first_pass
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
42
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
? Fichier /etc/pam.d/common-auth ajouter les lignes
suivantes auth sufficient pam_unix.xo md5
auth required pam_ldap.so use_first_pass
? Fichier /etc/pam.d/common-password ajouter les lignes
suivantes password sufficient pam_unix.xo md5
password required pam_ldap.so use_first_pass
? Fichier /etc/pam.d/common-session ajouter les lignes
suivantes session required pam_mkhomedir.so skel=/etc/skel umask=022
session sufficient pam_unix.xo md5
session required pam_ldap.so use_first_pass
III.5. Mise en place d'un serveur de messagerie
Un système de messagerie comporte nombre
d'éléments en interaction les uns avec les autres, la mise en
place de cet ensemble doit suivre une démarche rigoureuse sous peine de
deux principaux avatars : une gestion difficile et un manque de
sécurité avec l'intrusion de virus et du courrier non
désiré.
III.5.1. Activité
Nous utilisons comme serveur SMTP le logiciel libre Postfix,
plus simple à configurer, son niveau de sécurité est bon
et il consomme peu de ressources systèmes. Un serveur de messagerie
complet se compose de plusieurs serveurs : le serveur de courrier entrant
(SMTP) et celui sortant (POP et IMAP). Concrètement notre système
de messagerie sera composé de :
- L'UA (User Agent) chargé de poster et de lire le
courrier (Thunderbird sur le client Linux et Outlook Express sur Windows)
- Un MTA (Message Transfer Protocol) chargé de
transférer un message d'un PC à l'autre (Postfix sur SVRLAN)
- Le MDA (Mail Delivery Agent) chargé de
délivrer le message provenant du MTA dans une boîte aux lettres
(Procmail sur SVRLAN)
- Un serveur POP chargé du courrier sortant
(Dovecot-pop3d sur SVRLAN)
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
43
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
III.5.1.1. Postfix en tant que serveur local de
messagerie
La première étape consiste à configurer un
MTA sur un poste (SVRLAN), ce qui correspond à une installation locale.
Dans ce type de configuration les messages sont envoyés et reçus
localement par les utilisateurs du système.
- Installation du paquet Postfix et de l'agent simple
mail
Après le message d'information, choisissons pour
l'instant utilisation locale simplement. Validons le nom de courrier
par défaut: svrlan.virtualiut.lan. Le MTA Postfix
démarre. Le processus installe le MD Procmail.
Figure 42 : installation du paquet postfix
En règle générale, le courrier de
l'utilisateur root est dirigé vers un autre compte : le
nôtre ou celui indiqué à l'installation du serveur. Il nous
permet de surveiller notre système sans devoir se connecter avec tous
les droits. Nous devons utiliser les alias dans le fichier /etc/aliases
(dans notre cas l'utilisateur privilégié est aroun).
III.5.1.2. Configuration de Postfix en serveur pour un
domaine
Nous allons ajouter à notre serveur MTA la
capacité d'un serveur POP. Pour cela, il faut le transformer en serveur
pour un domaine. A partir du client, un utilisateur pourra consulter ses
courriers sur la machine SVRLAN. Nous utiliserons comme serveur POP le logiciel
Dovecot, serveur performant, sécurisé et, ce qui ne gâte
rien, plus facile à configurer que des serveurs comme Cyrus ou XU. La
coopération entre Postfix et un serveur est simple : lorsque Postfix
accepte la distribution d'un courrier, il le place dans l'espace de stockage.
Ce dernier est utilisé ensuite par le serveur POP pour
récupérer les courriers.
- Installation du serveur POP
Figure 43 : installation du paquet dovecot
pop3
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
44
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Nous allons pour commencer une politique d'authentification
simple en `plain text' sans sécurité, Remplaçons
les valeurs des lignes suivantes du fichier de configuration de Dovecot
/etc/dovecot/dovecot.conf, étant donné que nous sommes
en test,
Figure 44 : configuration du fichier
dovecot.conf
Nous pouvons relancer le service Dovecot par la commande :
/etc/init.d/dovecot restart - Modifiez le ficher de
configuration Postfix
Figure 45 : Modifiez le ficher de configuration
Postfix
Nous devons revenir sur le DNS pour ajouter quelque lignes, en y
référence au serveur de messagerie et les alias pour les serveurs
SMTP et POP et par la même occasion l'alias pour le serveur LDAP :
Figure 46 : ajout de la nouvelle configuration sur le
fichier db.virtualiut.lan
Enfin redémarrons les services DNS et Postfix :
/etc/init.d/bind9 restart, /etc/init.d/postfix restart
Nous pouvons stocker les informations du système de
messagerie dans l'annuaire LDAP pour que Postfix utilise l'annuaire comme
source de ses alias de messagerie, il faut installer le paquet sur SVRLAN :
postfix-ldap.
La configuration de Postfix est loin d'être vue dans sa
totalité... Actuellement nous disposons d'un serveur Postfix sur le
domaine virtualiut.lan, donc uniquement sur le réseau
interne.
III.6. Configuration de serveurs Web virtuels sous
Apache
Le principe de l'hébergement virtuel est devenu
incontournable dans la version 2 d'Apache, à tel point que l'on imagine
plus l'un sans l'autre. Cette technique propose plusieurs sites sur un
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
45
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
même serveur Web avec la possibilité d'un
premier niveau de sécurité par un filtrage des utilisateurs. Un
serveur HTTP est un logiciel capable d'interpréter les requêtes
HTTP qu'il reçoit et de fournir une réponse dans ce même
protocole. Apache est le serveur HTTP le plus répandu sur Internet. Ce
serveur est très extensible. Il permet en effet d'ajouter des modules
supplémentaires qui enrichissement le serveur en termes de
fonctionnalités. Dans cette partie, nous allons installer et configurer
un serveur Apache et y ajouter un interpréteur de scripts PHP On peut
souligner qu'il existe trois types d'hébergement virtuel :
- Par adresse IP
- Par nom
- Dynamique (non abordé ici, plus spécialement
destiné aux FAI)
III.6.1. Activité
Dans cette partie deux choses nous intéressent ici :
- L'installation de deux hôtes virtuels par adresse IP
(mécanisme de l'alias) pour pouvoir plus tard mettre en place un
accès SSL.
- L'installation de deux hôtes par nom avec accès
sécurisé (on sépare un de deux hôtes virtuel par IP)
pour une configuration classique de deux sites Web.
Nous utiliserons SVRDMZ et son service
Apache.
III.6.1.1. Hébergement virtuel par adresse
IP
Avant toute chose l'installation de deux hôtes virtuels
par adresse IP nécessite... deux adresses IP ! Soit le serveur dispose
de deux cartes réseaux ; la même carte répondra donc
à deux IP différentes.
Ajoutons l'alias IP sur eth0 dans le fichier
/etc./network/interfaces :
Figure 47 : configuration de l'interface
eth0:0
Relançons bien le service réseau avec un test
par ping sur la nouvelle adresse.
Nous allons installer deux hôtes virtuels par l'IP car
on désirera un accès sécurisé SSL (https)
et la couche des sockets sécurisés exige un couple unique
adresse IP/nom d'hôte. Créons les deux répertoires
nécessaires pour les deux hébergements virtuels.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
46
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
- mkdir /var/www/secu - mkdir /var/www/web
III.6.1.2. hébergement virtuel par nom
Les deux techniques peuvent se combiner et c'est pour cela
que nous avons mis en premier dans le fichier des hôtes virtuels
l'adresse 192.168.2.3. Il est préférable de définir la
configuration dans cet ordre.
III.7. Installation d'un serveur mandataire Squid
Le terme proxy se traduit littéralement par le mot
procuration mais on lui préfère celui de mandat. Un serveur proxy
se définit donc comme un serveur mandataire réalisant à
notre place des requêtes réseaux protocolaires comme par exemple
http ou encore FTP. On dégage trois grandes fonctionnalités d'un
serveur proxy :
- le partage de connexion Internet ;
- la mise en cache des éléments (images pages
HTML, sons,...) ; - le filtrage des données.
Si la première fonctionnalité peut être
réalisée autrement, la deuxième accélère les
réponses pour les navigateurs clients (on parlera
généralement de proxy-cache) et la dernière offre la
possibilité de sélectionner les sites autorisés et ceux
qui ne le sont pas...
Un proxy agit selon deux modes différents, serveur ou
transparent :
- En mode serveur, une modification se fera
dans les paramètres de connexion du navigateur des postes clients afin
d'indiquer l'adresse du serveur et le port sur lequel il doit s'y connecter.
- En mode transparent, aucune modification
n'est nécessaire sur le poste client mais il ne peut plus y avoir alors
d'authentification utilisateur
III.7.1. Installation et configuration du serveur
Squid
Nous utiliserons le serveur SVRDMZ et son service Apache pour
installer le service Squid. A partir de cette activité, le(s) client(s)
passeront obligatoirement par le serveur SVRDMZ via Squid pour leurs
requêtes Web à partir du navigateur. Nous allons installer le
paquet de Squid via la commande apt-get install squid squid-common.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
47
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Classiquement le comportement d'un serveur Squid se
contrôle par l'édition de son fichier /etc/squid/squid.conf
dans l'état actuel de Squid, paramétrons un navigateur
client qu(il utilise le proxy, par exemple FireFox sous Linux
Figure 48 : Paramétrage du proxy sous
Firefox
Cela ne marchera pas car le Squid a un comportement de
blocage suite à l'installation : le client aura sur son navigateur ce
message
Figure 49 : accès impossible par le proxy
Squid
III.7.2. Configuration du contrôle
d'accès
La configuration du contrôle d'accès de nos
machines clientes, est le but principal du Squid. Nous utiliserons à cet
effet les contrôles de types ACL. Le fichier de configuration montre deux
grandes parties : la définition des listes ACL, puis la
détermination des droits. Modifions le fichier de configuration pour un
contrôle de notre réseau
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
48
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 50 : ajout de la définition ACL du
réseau
La ligne sur l'ACL lan se positionne avant les
autres, on autorise le réseau local avant de tout bloquer par
http_access deny all. Il nous reste qu'à redémarrer le
service Squid, cette fois-ci l'accès est autorisé à partir
du navigateur client.
- Contrôle d'accès suivant un horaire
particulier
On peut faire beaucoup e de choses avec le mécanisme
des ACL, comme par exemple restreindre l'accès de certains clients
à une plage horaire précise.
Figure 51 : contrôle d'accès suivant une
heure déterminée
Dans cet exemple, l'accès est autorisé pour
deux machines d'IP 100, 101 entre 08 heures et 17heures30. Dans le cadre d'un
TP en salle l'enseignant peut décider de bloquer les machines
utilisées par les étudiants en classe pour une bonne attention et
compréhension du cours pour une période.
III.8. SECURISATION DU RESEAU VIRTUALIUT
Après toutes les différentes installations et
configurations, notre réseau tourne bien mais reste incomplet ! Par
rapport au modèle de base présente au chapitre
précédent, il manque la notion de DMZ et surtout toutes les
sécurisations nécessaires. A partir de cet agrandissement, la
gestion du DNS change en employant une technique très
particulière : celle de vues. Nous allons commencer par le DNS et
ensuite installer enfin le dernier serveur SVRFWL.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
49
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
III.8.1. Le SPLIT DNS
BIND9 apporte une nouvelle possibilité appelée les
vues (views) permettant de délivrer des informations
différenciées sur les zones DNS qu'un serveur gère, en
fonction des adresse IP des clients qui interrogent le serveur. L'idée
générale veut que l'on teste l'adresse IP d'un client et que l'on
modifie le comportement du serveur BIND en fonction de l'appartenance du client
du client à certains réseaux.
Ce type de configuration se réalisait auparavant avec
différents serveurs pour les versions internes et externes de la
réalité. L'instruction view de BIND9 simplifie cette
configuration en plaçant les deux ensembles de données (interne
et externe) dans la même version de bind
- Le principe de vues appliqué à notre
réseau
Le traitement des vues se construit sur SVRDMZ et, comme chaque
vue est traitée tout à tour, nous commencerons par la vue la plus
restrictive (vue interne).
Dans notre configuration le serveur SVMDMZ se prête au
mécanisme de vues car nous voulons :
? Interdire la récursivité du DNS
vis-à-vis des requêtes externes dans un but de
sécurité
? Filtrer éventuellement plus tard des
sous-réseaux du réseau interne vis-à-vis de ses
requêtes DNS
Installation de SVRFWL et la sécurisation du
DNS
Nous allons installer notre dernier serveur SVRFWL, il aura
la fonction de routeur ave le NAT auparavant dévolue à SVRLAN :
ce sera lui notre rempart vis-à-vis de l'extérieur. Ensuite nous
nous consacrons plus particulièrement à la sécurisation du
DNS et Cela repose sur quatre points :
- Utilisation les ACL pour les vues.
- Configurer les fichiers pour une transaction
sécurisée par RNDC. - Masquer la version BIND
- Emprisonner (chroot) le DNS dans une arborescence.
III.8.1.1. Installation du serveur SVRFWL
En rappel, le schéma réseau actuel de notre
entreprise virtuelle est le suivant
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 52 : réseau d'entreprise VIRTUALIUT
sans serveur pare-feu SVRFWL Après ajout et modification du
serveur SVRFWL, notre schéma final aboutira à ceci
Figure 53 : schéma du réseau d'entreprise
final - Modifications sur SVRLAN
Une fois l'installation de SVRFWL terminée, supprimez
virtuellement deux cartes réseaux sur SVRLAN et branchons celle restante
sur le commutateur de SVRFWL avec CLIENT, ensuite modifions le fichier
/etc/network/interfaces de SVRLAN pour qu'il ne contienne qu'une
référence à une carte et boucle locale.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
50
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
51
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 54 : configuration de l'interface eth0 du serveur
SVRFWL
Supprimons la fonctionnalité de NAT et le routage en
enlevant les deux lignes s'y rapportant dans le fichier /etc/rc.lan
(la ligne echo et la ligne iptables). Et fin nous devons
changer la passerelle par défaut dans le fichier
/etc/dhcp3/dhcpd.conf pour les clients en mettant
192.168.3.2.
III.8.1.2. Construction finale de SRVFWL
Nous devons faire un transfert de carte réseau de la
SVRLAN au SVRFWL, après notre nouvelle configuration réseau du
serveur SVRFWL est :
Figure 55 : configuration final des interfaces du
serveur SVRFWL
Nous devons mettre comme DNS dans le fichier
/etc/resolv.conf sur SVRFWL. Dans un premier temps soit l'adresse de
notre FAI (fournisseur d'accès à Internet) soie celle de notre
routeur
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
52
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
accédant à l'Internet. Mettons le NAT et le
routage dans le fichier /etc/rc.lan avec les lignes identiques
à celles que nous avions sur SVRLAN : echo 1 >
/proc/sys/net/ipv4/ip_foward et Iptables -t nat -A
POSTROUTING -o eth0 -j MASQUERADE
III.8.1.3. sécurisation du DNS - Utilisation
de RNDC
BIND9 contient un utilitaire appelé RNDC qui permet
d'utiliser des lignes de commande pour administrer la démo,
named à partir de l'hôte local ou d'un hôte distant
(cas d'un serveur secondaire). Afin d'empêcher l'accès non
autorisé au démon named, BIND9 utilise une
méthode de clé secrète partagée pour accorder des
privilèges aux hôtes. Dans une telle situation, une clé
identique doit être présente aussi bien dans /etc/named.conf
que dans le fichier de configuration RNDC, àsavoir
/etc/rndc.conf. Pour que RNDC puisse se connecter au service
bind9, créons une déclaration controls et une
inclusion du fichier rndc.key dans le fichier /etc/bind/named.conf
(après la directive options) :
Cette déclaration indique à named de se
mettre à l'écoute du port 953 par défaut de l'adresse
inversée et d'autoriser les commandes rndc provenant de
l'hôte local, si la clé adéquate est
présentée. Nous utilisons l'utilitaire rndc-confgen
(clé 256 bits, appelée clé TSIG, Transaction
SIGnatures)
Nous pouvons voir le contenu du fichier /etc/bind/rndc.key
crée par rndc-confgen
Figure 56 : contenu du fichier
/etc/bind/rndc.key
- Utilisation des ACL (Access Control List)
Les listes ACL (ou contrôle d'accès) sont des
listes établissant une correspondance nommée. Déjà
aborde avec le proxy Squid et SquidGuard. Dans notre cas nous aurons une liste
ACL, celle pour le réseau interne, l'autre n'est pas nécessaire
car le mot clé any suffix. Pour le réseau « interne
» est plus parlant que 192.168.2.0 non ? Nous allons passer à la
création de l'ACL dans le fichier /etc/bind/named.conf :
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
53
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 57 : définition d'une ACL pour le
LAN
Modifions l'instruction match-clients, notre ACL est
en place : match-clients { lans ; } ; enfin relancer le service BIND
sur SVRDMZ
- Emprisonner le serveur
Cette technique (chroot) consiste à faire croire au
démon bind9 que son répertoire d'exécution
correspond à la racine root (/). En cas d'intrusion
via le service bind9, notre système est préservé.
Pour mettre en place cette technique, on doit créer l'arborescence
minimale de l'environement `chrooté', placer les fichiers et droits
adéquats et démarrer le démon bind9 avec l'option
-t pour l'utilisateur bind. Dans d'autres distributions on
trouve un paquetage qui réalise tout cela à notre place
:bind-chroot. Ce n'est pas le cas pour Ubuntu donc, nous devons
créer l'arborescence minimale nécessaire :
Figure 58 : création de
l'arborescence
Ensuite créons quelque fichier spécial
nécessaire à notre système :
· mknod dev/null c 1 3
· mknod dec/random c 1 8
· mknod dev/urandom c 1 9
· chmod 666 dev/null
· chmod 640 dev/random
dev/urandom
· chmod 775 var/run/bind
var/run/bind/run
· chown root.bind dev/random
dev/urandom
· chown root.bind var/run/bind var/run/bind/run
Utilisons en la recopiant la configuration DNS existante :
· cp /etc/bind/* etc/bind/
· cp /etc/locatetime etc/
· chown bind.bind etc/bind/*
· cp -Rf /var/cache/bind/* var/cache/bind/
2>/dev/null
· chown -R bind.bind
var/cache/bind/*
· chgrp bind var/cache/bind/
L'importance est que les fichiers dans la nouvelle
arborescence appartiennent à bind. Il faut maintenant prendre
en compte la nouvelle configuration. De plus, comme le changement est long
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
54
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
et fastidieux, nous utiliserons une configuration de BIND sans
RNDC ni la configuration en serveur secondaire de la zone
virtualiut.lan.
Figure 59 : nouvelle configuration du fichier
virtualiut.lan
La modification essentielle passe par l'ajout du nouveau
démon bind dans le fichier de configuration par défaut
/etc/default/bind9 : OPTIONS ='-u bind -t /var/lib/bind'
Nous disposons maintenant d'un DNS sécurisé propre
à réagir aux situations d'entreprise les courantes. Notre
degré de sécurité est optimal mais no maximal. Il y a
encore d'autres réglages plus poussés à faire comme la
possibilité d'interdire les spoofers d'IP par la directive nospoofcn
dans le fichier /etc/host.conf
III.9. Le chiffrement des échanges
Naturellement, le besoin de sécurité des
échanges impose le cryptage des données. On devrait selon la
langue française parler plutôt de chiffrement des
données... et de décryptage si l'on ne possède pas la
clé du code. Précision linguistique ou pas, l'administrateur
réseau se doit d'utiliser une méthode assurant un minimum de
confidentialité sur son réseau.
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
OpenSSL se compose d'un ensemble de fonctions
organisées en librairies implémentant des protocoles de
sécurité : les protocoles SSL (Secure Sockets Layer) et TLS
(Transport Layer Security). SSL constitue une surcouche indépendance du
protocole utilisé. Cela se traduit entre la couche APPLICATION et la
couche TRANSPORT du modèle OSI. Depuis 1994 tous les navigateurs Web
l'intègre, cela est vérifié par la présence du
`s' et avec un cadenas en bas de page (https://).
Le protocole TLS/SSL utilise des certificats sur le serveur,
un certificat contenant une clé publique et un certain nombre de
renseignements sur le serveur :
- le nom de l'autorité de certification ;
- le nom de l'entité propriétaire du certificat
;
- la date de fin de validité du certificat ;
- l'algorithme de chiffrement utilisé ;
- la signature de l'autorité de certification.
Figure 60 : gestionnaire de certificats de
FireFox
III.9.1. L'activité
Nous allons installer la librairie OpenSSL et ses utilitaires
sur SVRDMZ afin de pouvoir sécuriser différents services ; dans
cette partir on s'intéressera sur le service Apache. Le schéma de
réalisation se présente sous la forme (en réalité
les deux serveurs autorité de certification et serveur Web sont
physiquement confondus)
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
55
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
56
Figure 61 : Schéma OpenSSL dans le cas d'un
serveur Apache III.9.1.1. Création du CA (Autorité de
Certification)
On parle d'arbre de confiance de certification ou de chemin de
certification, avec au départ une certification racine (CA racine). Dans
notre cas de certification privée, il nous faut créer un
certificat auto-signé comme pour tous les certificats CA. Pour effectue
ceci, le paquetage apporte deux scripts
CA.pl et
CA.sh
équivalents.
- Initialisons le certificat
Figure 62 : initialisation du certificat
Ce qui permet de se positionner dans le bon répertoire et
de créer la structure (sous-répertoires, fichiers) propre
à une autorité de certification.
Voici en retour un extrait de la création du certificat
racine
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
57
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 63 : extrait de la création du certificat
racine
III.9.1.2. Configuration du module, création
des clés et certificats
- Utilisation d'OpenSSL sur Apache
Pour l'Apache 2, le fichier de configuration du module
ssl_conf se trouve dans
/etc/apache2/mode-enabled/ cinq étapes sont
cruciaux
? 1ère étape : création de notre
clé de serveur
[root]# openssl req -new -nodes -keyout web.key -out
web.csr -days 365 Nous disposons maintenant d'un fichier
web.key
Et aussi d'un certificat non signé web.csr
Figure 64 : contenu du web.csr
? 2ème étape : création de notre
demande de signature
[root]# openssl ca -out web.crt -in web.crs -days
365
Le retour est:
- La signature du certificat: réponse y;
- L'écriture du certificat certifié dans la base de
données SSL : réponse y.
? 3ème étape : configuration d'Apache
Réduisons les permissions sur la clé, et copions la
clé et le certificat dans le bon répertoire
Ajouter juste la directive <ifModule>
(dernière ligne) du fichier
/etc/apache2/mods-enabled/ssl.conf
? 4ème étape : configuration de notre
hébergement virtuel basé sur sur l'IP
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
58
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Apache et SSL ne s'utilisent qu'avec des hôtes virtuels
basés sur l'IP, jamais sur le nom ! Pourquoi ? Parce qu'Apache ne peut
pas lire l'en-tête http host avant l'établissement de la
connexion chiffrée.
Figure 65 : configuration d'hébergement
virrtuelsur IP ? 5ème étape : Test du serveur
Web sur un client
Le lancement dans un navigateur dur le client Windows de l'URL
https:// secu.virtualiut.fr
provoque la demande d'acceptation du certificat car le navigateur ne trouve pas
une autorité de certification reconnue
III.9.1.3. Utilisation d'openSSL avec LDAP
Nous pouvons maintenant utiliser le protocole TLS/SSL pour un
serveur LDAP même si cela s'avère d'une logique un peu trop
paranoïaque dans la situation de l'entreprise VIRTUALIUT car les
authentifications LDAP ne sont demandées que sur le réseau
interne.
Nous nous basons cette fois sur le serveur SVRLAN
et nous voulons aussi déclarer ce serveur comme serveur
d'autorité racine (CA).
Créons selon le même principe que
précédemment un certificat d'autorité, remplaçons
le hostname bien sûr par svrlan et l'adresse mail
du root par root@virtualiut.lan. Nous devons créer une
clé publique et une clé privée valide pour un an pour le
serveur LDAP
Figure 66 :création d'un certificat
d'autorité (CA)
Nous devons faire signer notre certificat par l'autorité
de certification et limitons les accès à la clé
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
59
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 67 : limitation de droit d'accès sur la cl
é generée Modifions les fichiers de configuration LDAP,
commençons par : - /etc/ldap/ldap.conf
BASE dc=virtualiut,dc=lan URL ldaps://192.168.3.1:636
TLS_CACERT /etc/ldap/ldap.crt TLS_REQCERT demand
- /etc/default/slapd
SLAPD_SERVICES='ldap://127.0.0.1 :389/
ldaps://192.168.3.1 :636/' - /etc/ldap/slapd.conf
TLSCerttificatefile /etc/ldap/ldap.crt
TLSCerttificateKeyfile /etc/ldap/ldap.key TLSCACertificatFile
/etc/ldap/cacert.pem
Enfin faisons un transfert du serveur par scp le
certificat cacert.pem
[root]# cd /etc/ldap
[root]# scp
root@19.168.3.1:/etc/ldap/cacert.pem
Voici une première approche des mécanismes
d'utilisation de bibliothèques et d'utilitaires de chiffrement. Nous
devons bien comprendre que cette pratique est une pratique appliquée sur
un service, différente suivant ceux-ci mais équivalente dans la
démarche.
III.10. Utilisation d'un réseau privé
virtuel
Un réseau privé virtuel repose sur un protocole,
appelé protocole de tunnellisation (tunneling), c'est-à-dire un
protocole permettant aux données passant d'une extrémité
à l'autre du VPN d'être sécurisées par des
algorithmes de cryptographie. VPN s'utilise essentiellement dans deux cas de
figures :
- Le type `routed' pour mettre en relation des machines
distantes (par Internet et par le protocole PPP)
- Le type `briged' pour mettre en relation des réseaux
différents.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
60
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
OpenVPN nécessite une authentification et une
vérification mutuelle d'un certificat par une clé (principe de
SSL). Voici pour une bonne compréhension le déroulement de cette
opération pour un client :
1. L'autorité de certificat de certification (CA) envoie
son certificat au client
2. Le client génère sa clé et une demande
(CSR) à partir du certificat.
3. Le client envoie cette demande au CA.
4. Le CA génère le certificat du client (CRT) et
le lui envoie.
Dans le cadre de notre réseau il est difficile de
mettre en place un VPN du premier type, aussi nous verrons la deuxième
et, évidemment toujours dans le cadre de l'utilisation du logiciel
VMware, entre le système hôte et le réseau interne de
l'entreprise. Cette technique présente un avantage certain : avant pour
accéder au réseau VIRTUALIUT (par exemple avec l'utilitaire
WinScp) depuis le système hôte, il faut ajouter des routes
statiques au système Windows. Avec une connexion VPN, tout ceci est
transparent.
Nous allons installer un VPN de type `bridged' entre le
système hôte sous Windows et le réseau local 192.168.3.0
via un serveur VPN ou passerelle qui sera SVRFWL. Nous nous basons sur le
serveur SVRFWL et nous allons aussi déclarer ce serveur comme serveur
d'autorité racine (CA). Après avoir installé le paquet qui
est apt-get install openvpn,
Figure 68 : installation du paquet openvpn pour le
VPN
Il faut définir quelque élément de base
pour la compréhension du fonctionnement du paquet openvpn
- Clean-all : création et/ou effacement des
clés existantes ; - build-ca : création de la
certification d'autorité ;
- build-key-server : création de la clé et
d'un certificat serveur - build-key : création de la clé
et d'un certificat client
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
61
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
III.10.1. Génération des certificats et
clés d'authentification
Lorsque nous créons les certificats, divers
renseignements sont demandés. Une bonne partie d'entre eux peut
être renseignée dans le fichier vars, éditons le,
et changeons le renseignement et faisons prendre en compte les exportations des
variables pour le système.
[root]# vim vars [root]#. ./vars
Les variables à initialiser sont :
Figure 69 : initialisation des variables du fichier
easy-rsa
Enfin, on exécute enfin le script afin d'initialiser
les variables : source vars. Pour générer ce master CA et la
clé correspondante, il faut exécuter les scripts suivants
à partir du dossier /etc/openvpn/easy-rsa :
./clean-all> ./build-ca. Ainsi l'exécution du script build-ca (La
commande permet de générer les certificats d'authentification
(./build-ca) pour n'ai pas avoir de problème lors de l'éxecution
il faut renseigner obligatoirement les champs importants qui sont (rappel dans
le ficher « vars » la partie importante est `Export KEY_ORG = `tstri'
gardons -le à l'esprit))entraîne la création du certificat
ca.crt et de la clé ca.key dans le répertoire
/etc/openvpn/easy-rsa/keys.
Nous devons faire parait pour le générer le
certificat du server juste après pour les différents clients
(client1, client2,..., client n) respectivement par les commandes
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
62
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
III.10.1.1. Génération des certificats
et clés pour les clients
De la même façon, ils sont
générés par l'exécution du script build-key
à partir du dossier /etc/openvpn/easy-rsa/ : .
/build-key nom_du_client1. Pour le paramètre « Commun-name »,
saisissez le même nom que nom_du_client1 que vous avez utilisé
dans la commande ! Répétez cette opération autant de fois
que vous voulez pour générer plusieurs certficats et clés
si vous avez plusieurs clients. N'oubliez pas cependant de changer de
nom_du_client à chaque fois !!! Ce script entraine la création
des fichiers nom_du_client1.crt et nom_du_client1.key dans le dossier
/etc/opnevpn/easy-rsa/keys.
- Génération des paramètres de
Diffie-Hellman
Le protocole Diffie-Hellman est un protocole de cryptographie
utilisé dans les échanges de clés. Les paramètres
de Diffie-Hellman sont générés par l'exécution du
script build-dh à partir du dossier /etc/openvpn/easy-rsa
: ./build-dh
Figure 70 : génération des
paramètres de Diffie Hellman
Après la génération des clés il faut
copier les clés dans le répertoire /etc/openvpn # cp keys/*
/etc/openvpn
Maintenant nous pouvons configurer le fichier du serveur dans
lequel, il y a le protocole l'adresse et bien autre chose. Pour cela copie le
fichier zippé (server.conf.gz)
#cp /usr/share/doc/openvpn/examples/sample- conf
-files /server.conf.gz /etc/openvpn III.10.1.2. Configuration du client VPN cas
client-linux1
Pour un client les fichiers importants à copier de la
machine serveur vers la machine cliente sont (client1.crt, client2.crt...,
client1.key,client2.key, ... ;ca.crt, ca.key pour les différentes
machines clients vers le répertoire /etc/openvpn). Lors de la
configuration du serveur VPN nous avons généré les
différents clés et certifications du server et des clients, nous
avons donc plusieurs moyens configurer les clients
1. Soit par SSH : on se connecte de la machine
client par SSH à la machine server
2. Soit par Filezilla : en installant
filezilla et proftpd (voir doc pour les différentes configurations)
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
63
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
3. Soit par simple copie sur le terminal en
créant les fichiers équivalent sur la machine cliente
(retirer certain droit d'accès sur tous les fichiers créés
par la commande `chmod -R 600 ')
Figure 71 : copie des fichiers generés du serveur
au client_linux par SSH Procédons comme dans la configuration
du server
#cp /usr/share/doc/openvpn/examples/sample- conf -files
/client.conf. /etc/openvpn Après cette copie editons le fichier
client.conf
Figure 72 : configuration du fichier
server.conf
Cette adresse est l'adresse IP du serveur distante donc l'on doit
se connecte et le protocole Modifions la clé et le certificat du client1
par les fichiers copiés du server vers le client
Figure 73 : configuration du fichier
client.conf
III.10.1.3. Test de connectivité du VPN sur le
serveur SVRFWL et un CLIENT
Ce lancement aboutit à la création d'une interface
réseau virtuelle pour le service 10.8.0.1 (commande
ifconfig)
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 74 : aperçu du tunnel créer par le
VPN
A l'aide de la commande ping nous pouvons voir la réponse
renvoyer
Figure 74 : test de connexion entre le serveur et le
client VPN
III.11. Installation d'une politique de
sécurité
Nous pensons que le moment est venu d'installer une
véritable politique de sécurité par un contrôle
direct sur les paquets émis et reçus au travers du réseau.
La pièce maîtresse de l'ensemble est le serveur SVRFWL dont c'est
rôle essentiel, en plus de la fonction de routage. Là encore, la
difficulté réside plus dans la compréhension des
mécanismes que dans leur mise en oeuvre. Pour comprendre le
problème de la sécurité, elle se fait par le biais de la
connexion d'un serveur à un réseau le rend accessible, donc
vulnérable. La grandeur du réseau multiple les risques
d'où un risque maximal en étant connecté à
l'Internet.
- Types de menaces
Globalement les menaces possibles se classent en trois
catégories :
? Menaces sur la confidentialité des
données : accès à des données
privées (fraudes bancaires)
? Menaces sur l'intégrité des
données : modifications de données privées
(malveillance, terrorisme)
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
64
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
65
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
· Menaces sur la disponibilité des
données : blocage à l'accès des données
(déni de service, chantage)
- Type de pirates
· Le carder est impliqué dans la
réalisation de fausses cartes bancaires.
· Le phreaker, est
spécialisé dans le vol d'unités
téléphoniques dans les autocommutateurs.
· Le hacker est un expert des
systèmes d'exploitation. Il cherche à mettre en évidence
les points faibles des systèmes mais s'interdit leur exploitation
malveillante.
· crackers n'hésitent pas
à utiliser les points faibles des systèmes à des fins
nuisibles.
· script kiddies (Dépourvus de
compétences) ou plus simplement les kiddies utilisent,
sans les comprendre, des scripts qui leur permettent de prendre le
contrôle de leur cible.
Pour mettre en place de mesure de sécurité, nous
avons le choix entre : utiliser une distribution Linux entièrement
axée sur la sécurité, ou créer un script (Bash)
avec IPTABLES.
III.11.1. les mesures de sécurité
Pour nous, la première chose à faire, c'est de
vérifier les portes ouvertes dans notre système et de fermer
celles non utiles. En utilisant la commande netstat -ntl nous pouvons
afficher des ports ouverts sur notre serveur SVRDMZ par exemple. La fermeture
des ports est liée au système d'exploitation, en règle
générale elle consiste à fermer le service associé.
L'outil nmap, il permet de scanner les ports ouverts sur une machine
distante. Son utilisation est des plus simples. Par exemple si nous voulons
scanner l'interface de 192.18.2.2 sur SVRDMZ à partir
de SVRFWL il faut taper la commande : nmap -v -sU -sT 192.168.2.2
- Le pare-feu (firewall)
Les paquets IP sont rotés en fonction de leur adresse
de destination et de leur adresse d'émission. Ils utilisent un protocole
de transport (UDP ou TCP). La session est identifiée par un port source
et par un port de destination. Une connexion (session au sens OSI du terme)
entre processus client et un processus serveur est matérialisé
par un couple de triplets :
(@JP-source, TCP/UDP, port sources), (@JP-dest.,
TCP/UDP, port dest.) - Netfilter et IPtables
Distinguons deux fonctions différentes : le
routage et le filtrage. Le filtrage va consister à appliquer
des règles particulières aux paquets qui sont routés. Ces
deux fonctions sont prises en charge pour le noyau Linux de la série 2.6
par Netfilter. La mise en place des règles qui
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
66
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
seront appliquées aux paquets se fait par la commande
IPtables. Pour cela nous devons connaitre quelques règles de base :
? Les chaînes sont des ensembles de règles qui
sont appliquées séquentiellement aux paquets jusqu'à ce
que l'une d'entre elle soit applicable.
? Il y a toujours au moins une chaîne par défaut. ?
Ces chaînes sont placées dans des tables
Netfilter peut intervenir en cinq endroits du système
de gestion de la pile IP. Pour chacune de ces étapes (que l'on appelle
des `hookÇ pour `crochet' en français),
Netfilter peut :
- Imposer au noyau de supprimer le paquet
(`drop') auquel cas, il est jeté à la poubelle, et c'est
comme si le paquet n'avait existé.
- Indiquer au noyau que le paquet est accepté
(`accept') dans ce cas-là le noyau peut continuer
à travailler dessus
- Modifier le paquet, puis le rendre au noyau
Figure 75 : fonctionnnement de netfilter
III.11.2. l'activité
Nous allons construire un ensemble de règles initiales
d'un pare-feu (firewall) dans un script BASH (Shell ou langage de commande) sur
le serveur SVRFWL. La procédure décrite ici se rapporte à
notre réseau, c'est-à-dire :
- Une interface réseau publique (eth0)
;
- Une interface connectée au réseau
privé (eth1) ; - Une interface connectée
à la DMZ (eth2).
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
67
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
La difficulté n'est pas grande, il suffit d'avoir de la
méthode. Nous verrons dans un premier script les règles de base
avant de voir dans le paragraphe suivant des règles de filtrage un peu
plus fines. Rappelons-nous, nous devons commenter les lignes pour le routage et
le Nat dans le fichier /etc/rc.lan.
Figure 76 : debut du script pour l'initialisation des
variables
Après avoir écrire ce bout de script, nous
devons l'enregistrer et en lui donnant les droits en exécution avec la
commande chmod 755. Nous poursuivons notre script par le vidage de
toutes les règles existantes et verrouillage
Figure 77 : vidage de toutes les régles existantes
et verroullage
Pour que le script initialise la table FILTER pour qu'il
accepte sur ses trois chaînes il faut ajoute la fonction TableFILTER
au début du script
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
68
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 78 : ajout de la fonction TableFILTER() au
script
A ce niveau du script et parce qu'il faut toujours se laisser
une porte de sortie honorable, il vaut mieux ajouter au script une demande sur
la poursuite de celui-ci ou son arrêt éventuel. Cela permet de
remettre en état le serveur comme s'il n'y avait pas de pare-feu. Nous
remarquerons l'apparition de la remise en vigueur de la fonction routage et de
l'ancienne règle pour le NAT.
Figure 79 : activation du routage
Ensuite la règle consiste à fermer
toutes les portes pour ensuite les ouvrir une par une. Par contre,
là aussi, il faut mieux laisser les règles des tables NAT et
MANGLE positionnées par défaut à accepter tout car :
- Le script sera plus court ;
- Des règles FORWARD bien écrites suffisent pour la
sécurité ; - La table FILTER nous intéresse
Nous pouvons écrire les règles par défaut
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
69
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 80 : fermeture de toutes portes pour ensuite les
ouvrir une par une
A ce stage là nous pouvons déjà effectuer
à un test initial du pare-feu par le biais de la commande /
parefeu.sh.
La première remarque que l'on tirer est que le
ping ne fonctionne ni sur SVRLAN et ni SVRDMZ. Pour remédier
à cela, nous devons tester le serveur et le remettre à son
état normal en relançant le script et en l'interrompant
à la demande vue plus haut.
III.11.2.1. Règles concernant les chaînes
INPUT/OUTPUT
Le travail qui suit se fait sur la table FILTER et nous
pouvons omettre -t filter car en cas
d'absence, cela s'applique sur cette table par défaut. La pratique
générale consiste à ouvrir petit à petit les
communications qui nous intéressent. Le but ici rechercher est
d'autoriser tout type de communication sur l'interface de loopback
pour les communications réseau en local sur la passerelle. Pour ce
partir de script ci-dessous
- Pour la connexion local
Nous chercher à autoriser l'interface du réseau
privé, parlant du principe que ce qui vient de chez nous ne comporte pas
de risque (en théorie ou peut être à tort)
- Pour la connexion avec le réseau
interne
Là un ping sur 127.0.0.1 fonctionne, ainsi que sur
SVRLAN soit 192.168.3.1 mais pas sur 192.168.2.2 SVRDMZ ni vers
l'extérieur (par exemple
google.com). Ici nous voulons autoriser
les communications (paquets IP) pour les connexions sortantes et entrantes
déjà établies, c'est-à-dire des flux IP que le
serveur SVRFWL aura lui-même demandés.
- Pour la connexion avec l'extérieur
Ce bout de script nous ouvre les portes vers
l'extérieur dans notre réseau (le ping sur
google.com fonctionne normalement)
Figure 81 : ouverture de la connexion avec
l'extérieur
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
70
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Pour toute nouvelle connexion sortante de SVRFWL, Netfilter
garder en mémoire la demande et attribue à la réponse un
état correspondant (ESTABLISHED), pour les autres l'état sera
invalide (INVALID). L'état RELATED correspond aux communications avec
des protocoles qui ne répondent pas sur le même port (exemple :
FTP). En sortie, tout ce qui n'est pas invalide est accepté.
III.11.2.2. Règles concernant les flux IP de la
chaîne FORWARD
Nous entrons cette fois dans le vif du sujet et un petit
schéma s'impose car les règles s'établissent tour à
tour suivant la position des serveurs/clients dans le réseau de
l'entreprise
6
3
4
SVRDMZ
SVRFWL
EXTERIEUR
5
2
SVRLAN/ CLIENT
1
Figure 82 : Schéma de circulation des flux pour la
chaîne FORWARD
(1) SVRLAN/CLIENT vers SVRDMZ
Le but est d'autoriser les communications pour le routage des
demandes de la part du réseau internes. Suivant les services, nous avons
le DNS, http (en fait le proxy squid) et HTTPS, SMTP, POP3, IMAP et FTP :
Figure 83 : autorisation de la communication pour le
routage des demandes pour le LAN
(2) SVRLAN/CLIENTS vers Internet
Son but est d'interdire toutes les communications vers
l'extérieur donc obliger le passage vers SVRDMZ.
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
71
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 84 : interdiction de la communication vers
l'exterieur
(3) SVRDMZ vers SVRLAN/CLIENTS
Son but est d'autoriser les communications initiées par
le réseau interne
(4) SVRDMZ vers Internet
Le but c'est d'autoriser les communications utiles pour notre
réseau comme le DNS, http ...
Figure 85 : autorisation de la communication pour la
DMZ
(5) Internet vers SVRDMZ
Le but est d'autorisé les communications en relation avec
les services publics de la DMZ
Figure 86 : autorisation de la communication avec les
services publics de la DMZ
(6) Internet vers SVRLAN/CLIENTS
Le rôle est d'interdire les communications venant de
l'extérieur, considérées comme suspectes :
Rédiger par NGOUCHEME MBOUOMBOUO A. Page
72
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
Figure 87 : blocage des paquets suspect venant de
l'extérieur
Nous pouvons effectuer des tests à partir du CLIENT, les
communications Internet pour vérifier la bomme tenue de notre pare-feu.
Il nous reste règle deux problèmes celui du VPN et la
vérification par l'extérieur, en ajoutant la fin script
Figure 88 : autorisation du trafic dans le réseau
d'entreprise
Nous disposons désormais d'une ébauche de pare-feu
efficace, stable et il faut le reconnaitre peu ouvert. Nous n'autorisons pas
par exemple les ports pour les flux vidéo... Tout est question de
politique de sécurité : laisser trop de libertés conduit
parfois à l'utilisation de ports de logiciels de peer to peer. Mais il
est encore possible d'ajouter au script
CONCLUSION ET PERSPECTIVES
Rédiger et soutenu par NGOUCHEME MBOUOMBOUO A.
Page 73
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
CONCLUSION ET PERSPECTIVES
Arrivé au terme de ce travail ou il était
question pour nous de proposer une architecture réseau, qui pourra
faciliter l'accessibilité aux services et informations offerts par l'IUT
de Ngaoundéré à travers une conception et
déploiement d'une architecture réseau sécurisée.
A la fin de ce stage, nous avons pu déployer la plupart
de services énumérés comme par exemple le DNS, le DHCP, la
messagerie, le proxy etc. L'architecture réseau mise sur pied
intègre également un pare-feu pour le filtrage du trafic. De ce
fait nous pouvons dire que les objectifs de notre stage ont été
atteints, en ce sens qu'il nous a permis non seulement de mettre en pratique
nos acquis, mais aussi nos compétences. Toutefois, il serait
intéressant de penser à l'installation de l'annuaire Active
directory afin de centraliser la gestion des ressources et la mise en place des
règles de sécurité en local.
BIBIOGRAPHIE
Rédiger et soutenu par NGOUCHEME MBOUOMBOUO A.
Page 74
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
BIBLIOGRAPHIE
Mémoires de fin d'études
[1]- Angeline KONE.
«Conception et déploiement d'une architecture
réseau sécurisée : cas de SUPEMIR».
Mémoire de fin d'étude Ingénieur,
2011.
Sites Internet consultés
[2]-
http://fr.wikipedia.org
encyclopédie libre en ligne ; dernière visite 25/09 /2013
[3]-
http://www.siteduzero.com
support de cours libre après inscription ; dernière visite
03/08/2013
Livre et support de cours
[4]- Jean-Christophe GALLARD (octobre 2005).
Sécurité et Réseaux, 131 pages ;
[5]- Jean-François CHALLE
.Administration et sécurité des réseaux
? Editions : Solvay, 178 pages.
[6]- NAT Markevitch. Linux Sécuriser
un réseau Editions : Eyrolles, 282 pages.
ANNEXES
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
ANNEXES
ANNEXES 1 : Organigramme
Hiérarchique
DIRECTEUR ADJOINT
DIRECTEUR
CHEF DE SERVICE DE L'INTENDANCE
CHEF DE SERVICE DE LA
DOCUMENTATION ET DE
LA
REPROGRAPHIE
CHEF DE LA DIVISION
ET DE
LA
FORMATION
INITIALE
CHEF DE LA DIVISION DES STAGES
CHEF DE SERVICE
DE LA SCOLARITE
ET
DE
L'ORIENTATION
PROFESSIONNELLE
CHEF DE SERVICE
DES
AFFAIRES
GENERALES
CHEFS DE
DEPARTEMENTS
CHEF DE SERVICE DES STAGES
Figure 1A : Organigramme de l'IUT
Rédiger et soutenu par NGOUCHEME MBOUOMBOUO A.
Page 75
Rédiger et soutenu par NGOUCHEME MBOUOMBOUO A.
Page 76
Concevoir et déployer d'une architecture de
réseau sécurisée à l'IUT
ANNEXES 2 : Plan de Localisation
Guérite De L'Université
Ici IUT
Carrefour Cité U.
CMS
Venant de Ngaoundéré ville
Figure 1B : Plan de localisation de l'IUT de
Ngaoundéré
| 
