Mémoire TABE Phot-Antou Léocady Prosper - Compressed

RÉPUBLIQUE DU BÉNIN
¤¤¤¤¤¤¤¤¤¤
M I NI ST ERE DE L’ ENSEI G NEM ENT SUP ERI EUR

ET DE LA RECHERC HE SCI ENTI FI Q UE
¤¤¤¤¤¤¤¤¤¤
UNI VERSIT É D’ ABO MEY -CAL AVI (U AC)

¤¤¤¤¤¤¤¤¤¤
ECOLE POLYT ECHNIQUE D’ ABO MEY -CAL AVI (EPAC)

¤¤¤¤¤¤¤¤¤¤¤¤¤¤
DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATION (GIT)
Option : Réseaux Informatiques et Internet (RII)

MEMOIRE DE FIN DE FORMATION
POUR L’OBTENTION DU
DIPLOME D’INGENIEUR DE CONCEPTION
AMELIORATION DE LA QUALITE DES

POLITIQUES DE SECURITE AU SEIN DES
FIREWALLS DYNAMIQUES
Présenté par :
TABE Phot-Antou Léocady Prosper
Tuteur de stage : Supervisé par :

Ir. Franck KOUYAMI M. Léonard MONTEIRO
Année Académique : 2010-2011
4ème promotion
Sommaire
SOMMAIRE
SOMMAIRE .................................................................................................................... I
DEDICACES .................................................................................................................. III
REMERCIEMENTS ........................................................................................................IV
LISTE DES SIGLES ET ACRONYMES ...............................................................................VI
LISTE DES FIGURES ....................................................................................................... IX
LISTE DES TABLEAUX ................................................................................................... XI
RESUME ...................................................................................................................... XII
ABSTRACT .................................................................................................................. XIII
INTRODUCTION GENERALE .......................................................................................... 1
PARTIE 1 : POLITIQUE DE SECURITE DANS LE RESEAU .................................................. 6
CHAPITRE 1 : LA SECURITE INFORMATIQUE ................................................................. 7
CHAPITRE 2 : GESTION DE LA POLITIQUE DE SECURITE AU SEIN D’UN RESEAU .......... 20
CHAPITRE 3 : ETAT DE L’ART SUR LES FIREWALLS ....................................................... 31
PARTIE 2 : APPROCHE METHODOLOGIQUE ................................................................ 66
CHAPITRE 4 : APPROCHE D’ANALYSE DES FIREWALLS A ETATS .................................. 67
CHAPITRE 5 : ARCHITECTURE RESEAU ........................................................................ 77
CHAPITRE 6 : SPECIFICATION DES BESOINS DU SYSTEME ET ETUDE CONCEPTUELLE . 91
PARTIE 3 : RESULTATS ET DISCUSSIONS ................................................................... 105
CHAPITRE 7 : RESULTATS .......................................................................................... 106
CHAPITRE 8 : DISCUSSIONS ...................................................................................... 125
CONCLUSION ET PERSPECTIVES ................................................................................ 129
REFERENCES BIBLIOGRAPHIQUES ............................................................................. 131
ANNEXES .................................................................................................................. 135
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page i
Sommaire
GLOSSAIRE................................................................................................................ 160
SUMMARY ................................................................................................................ 163
TABLE DES MATIERES ............................................................................................... 170
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page ii
Dédicaces
Dédicaces
Je dédie ce travail :
 A mon feu père Patrice TABE DANGOU. Regarde de là où tu es

ce que tes enseignements ont porté comme fruit ;
 A ma mère Justine SOSSOU. Merci maman pour tous les

sacrifices consentis à mon égard.
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page iii
Remerciements
Remerciements
Je rends grâce à Dieu, Eternel Miséricordieux, pour toutes les

grâces qu’il m’a données tout au long de ces années.
Je remercie également tous ceux qui de près ou de loin ont

contribué à la réalisation de ce travail, notamment :
 Pr. Félicien AVLESSI et Dr. BONOU Clément respectivement

Directeur et Directeur Adjoint de l’Ecole Polytechnique
d’Abomey-Calavi et à toute l’administration de l’EPAC ;
 Dr Sèmiyou A. ADEDJOUMA notre chef département ;
 Notre maître de mémoire M. Léonard MONTEIRO pour avoir

accepté supervisé notre travail ;
 Tous nos professeurs qui n’ont ménagé aucun effort pour nous
inculquer un enseignement de qualité ;
 Tous les enseignants des départements GE et GIT ;
 M. Franck KOUYAMI responsable technique du Campus

Numérique Francophone de Cotonou (CNFC) pour avoir
activement contribué à l’aboutissement de ce projet malgré ses
nombreuses occupations. Ses observations et conseils m’ont
été très précieux et je ne le remercierai jamais assez ;
 M. Aurel GUIDI, M. Vivien ASSANGBE, pour m’avoir accepté

au sein de leurs services à Bénin Télécoms SA ;
 A mon frère Phtanite, son épouse Brigitte, et à mon adorable

nièce Tiffany Foumilayo Déo-Gratias Bonan ;
 A ma sœur Jysmine ;
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page iv
Remerciements
 A ma bien-aimée Bérénice ASSOGBA pour tout l’amour,

l’attention, le soutien et le réconfort qu’elle a su m’apporter
pendant toutes ces années ;
 Mes aînés Boris et Victor pour leurs précieux conseils ;
 Toute ma famille : mes tantes, oncles, cousins et cousines ;
 Mes meilleurs amis que je considère comme mes frères Anne,

Eder Roméo, Anicet, Gatien, Candide Brice, Didier, pour le
soutien et leur confiance à mon égard ;
 Nissa pour avoir toujours cru en moi et pour avoir toujours été là
quand le besoin se faisait sentir ;
 Cathia, Dorine, Brice, John, Wilfried et Armel ASSOGBA, pour

l’aide précieuse et le soutien qu’ils m’ont apportés ;
 Les membres fondateurs de la Technology Business

Corporation S.A.R.L à qui je souhaite longue vie ;
 Mes promotionnaires pour les bons moments passés ensemble.

Une pensée particulière à : Appolinaire, Cosme, Géraud,
Roméo, Nabil, Nasirou, Déo-Gratias, Dehove, David, Paterne,
Gamaliel, Ross et Mahafouz.
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page v
Liste des sigles et acronymes
ACL: Access Control List
AES: Advanced Encryption Standard
ARP: Address Resolution Protocol
BGP: Border Gateway Protocol
BIOS: Basic Input Output System
DDoS: Distributed Denial of Service
DES: Data Encryption Standard
DMZ: DeMilitarize Zone
DNS: Domain Name Service
DoS: Denial of Service
FTP: File Transfer Protocol
GRE: Generic Routing Encapsulation
HIDS: Host Intrusion Detection System
HTTP: HyperText Transfer Protocol
ICMP: Internet Control Message Protocol
IDEA: International Data Encryption Algorithm
IDS: Intrusion Detection System
IEEE: Institute of Electrical and Electronics Engineers
IETF: Internet Engineering Task Force
IMAP: Internet Mail Access Protocol
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page vi
IP: Internet Protocol
IPS: Intrusion Prevention System
IPSec: Internet Protocol Security
ISO: International Standardization Organization
LDAP: Lightweight Directory Access Protocol
L2TP: Layer 2 Tunneling Protocol
MAC: Medium Access Control
MIME: Multi Purpose International Extension
NAT: Network Address Translation
NAPT: Network Address and Port Translation
NFS: Network File System
NIDS: Network Intrusion Detection System
NNIDS: Network Node Intrusion Detection System
OSI: Open Systems Interconnection
PAT: Port Address Translation
PDCA: Plan Do Check Act
PPP: Point-to-Point Protocol
PPTP: Point-to-Point Tunneling Protocol
RC2: Rivest Code #2
RC4: Rivest Code #4
RFC: Request For Comments
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page vii
RSA: Rivest Shamir Adleman
SI: Système d’Information
SMTP: Simple Mail Transfer Protocol
SNMP: Simple Network Management Protocol
SSH: Secure Shell
SSL/TLS: Secure Sockets Layer/Transport Layer Security
STP: Shielded Twisted Pair
SQL: Structured Query Language
TCP: Transmission Control Protocol
TOS: Type Of Service
TTL: Time To Live
UDP: User Datagram Protocol
UML: Unified Modeling Language
VLAN: Virtual Local Area Network
VPN: Virtual Private Network
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page viii
Liste des figures
Liste des figures
Figure 1 : Hiérarchie des politiques de sécurité .......................................................... 23

Figure 2 : Cycle de Deming définissant la méthode PDCA .......................................... 25
Figure 3 : Elaboration de stratégie réseau sur la base de la politique de sécurité
réseau définie (source : Bloch, Wolfhugel, 2007) .............................................. 29
Figure 4 : Exemple de positionnement de firewall ..................................................... 34
Figure 5 : Algorithme de filtrage des paquets d’un pare-feu ...................................... 36
Figure 6 : Architecture de type filtre simple ............................................................... 47
Figure 7 : Architecture de type filtre simple avec un serveur ..................................... 48
Figure 8 : Architecture en DMZ avec un firewall à trois interfaces ............................. 49
Figure 9 : Architecture en DMZ avec des firewalls à deux interfaces ......................... 50
Figure 10 : Architecture en DMZ avec un routeur filtrant à la place du firewall externe
.......................................................................................................................... 50
Figure 11 : Architecture de type proxy ....................................................................... 51
Figure 12 : Architecture mixte en proxy et DMZ......................................................... 51
Figure 13 : Différents types de relations existant entre des règles de filtrage ........... 56
Figure 14 : Architecture réseau présentant les anomalies intra-firewall .................... 57
Figure 15 : Architecture réseau distribuée présentant les anomalies inter-firewall... 61
Figure 16 : Diagramme de traitement des paquets dans Iptables .............................. 72
Figure 17 : Modèle d’architecture proposée .............................................................. 79
Figure 18 : Architecture réseau complète retenue pour la modélisation ................... 83
Figure 19 : Cas d’utilisation de l’Administrateur ........................................................ 95
Figure 20 : Diagramme de séquence « créer les objets zone » ................................. 101
Figure 21 : Diagramme de séquence « créer les objets firewall » ............................ 102
Figure 22 : Diagramme de séquence « spécifier les chemins » ................................. 103
Figure 23 : Diagramme de classes du système ......................................................... 104
Figure 24 : Fonction ensembleadresse ..................................................................... 109
Figure 25 : Fonction ensemble.................................................................................. 110
Figure 26 : Fonction testegalite ................................................................................ 111
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page ix
Liste des figures
Figure 27 : Fonction testinclusion ............................................................................. 112

Figure 28 : Fonction testcontenance ........................................................................ 113
Figure 29 : Fonction compare ................................................................................... 114
Figure 30 : Fonction comparer .................................................................................. 116
Figure 31 : Algorithme intra-firewall ........................................................................ 119
Figure 32 : Algorithme inter-firewall ........................................................................ 121
Figure 33 : Test d’audit intra-firewall du firewall fw1 ............................................... 122
Figure 34 : Test d’audit intra-firewall du firewall fw2 ............................................... 123
Figure 35 : Test d’audit inter-firewall ....................................................................... 124
Figure 36 : Interface de connexion ........................................................................... 153
Figure 37 : Page d’accueil du système ...................................................................... 153
Figure 38 : Création d’un nouveau réseau ................................................................ 154
Figure 39 : Création de zones dans l’architecture ..................................................... 154
Figure 40 : Liste des zones créées ............................................................................. 155
Figure 41 : Modification des attributs des zones créées ........................................... 156
Figure 42 : Création de firewalls dans l’architecture ................................................ 156
Figure 43 : Liste des firewalls créés .......................................................................... 157
Figure 44 : Modification des attributs des firewalls créés ........................................ 158
Figure 45 : Edition des chemins dans le réseau ........................................................ 159
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page x
Liste des tableaux
Liste des tableaux
Tableau I : Configuration des listes de contrôles d’accès ........................................... 38

Tableau II : Tableau comparatif des types de firewalls .............................................. 44
Tableau III : Règles de filtrage du firewall fw0 ............................................................ 58
Tableau IV : Règles de filtrage du firewall fw0 ............................................................ 61
Tableau V : Règles de filtrage du firewall fw1 ............................................................. 62
Tableau VI : Règles de filtrage du firewall fw2 ............................................................ 62
Tableau VII : Tableau récapitulatif des technologies à utiliser ................................... 76
Tableau VIII : Priorité des cas d’utilisation ................................................................. 96
Tableau IX : Description textuelle du cas d’utilisation « créer les objets zones »....... 97
Tableau X : Description textuelle du cas d’utilisation « créer les objets firewall »..... 98
Tableau XI : Description textuelle du cas d’utilisation « spécifier les chemins entre les
différents éléments du réseau » ....................................................................... 99
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page xi
Résumé
Résumé
La sécurité des Systèmes d’Information (SI) est devenue un enjeu

majeur au cœur des réseaux informatiques. Il est devenu absolument
important de se prémunir des attaques provenant tant d’Internet, que du
réseau local à protéger. Les firewalls, outils de sécurité les plus répandus
et les plus utilisés, sont des dispositifs filtrant les trafics entre différents
systèmes. Malgré leurs nombreuses fonctionnalités, il n’est pas rare de
retrouver des anomalies au sein de leurs configurations, ce qui peut nuire
à l’intégrité du système. C’est dans cet ordre d’idées que s’inscrit notre
projet de fin d’études intitulé « Amélioration de la qualité des politiques de
sécurité au sein des firewalls dynamiques », qui tente de répondre
efficacement à cette problématique. L’objectif général visé par ce projet
est de garantir un niveau de sécurité optimal au sein d’un réseau, en
s’assurant que la configuration des firewalls soit exempte d’erreurs, et
traduise la politique de sécurité spécifiée. Pour y arriver, en premier lieu,
nous utilisons la méthode ascendante pour analyser les règles de filtrage
configurées au sein de l’architecture réseau proposée pour la
circonstance. Ensuite, nous proposons des algorithmes d’audit
permettant de détecter les différentes anomalies entre les règles de
filtrage, dans un environnement distribué ou non. Implémentés au sein
d’un système, ces algorithmes nous ont permis, de déceler les anomalies
de configurations et de pouvoir les corriger. Ce projet ouvre ainsi de
nouvelles perspectives pour étendre notre étude aux autres
fonctionnalités des firewalls, de même qu’aux différentes catégories de
composants de sécurité réseau.
Mots clés : firewall à états, politique de sécurité, Iptables,

approche ascendante, anomalie inter-firewall, anomalie intra-firewall.
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page xii
Abstract
Abstract
Security of Information System has grown into a major problem in

computing network. It is nowadays absolutely important to protect
networks against attacks coming not only from Internet, but also from the
inside of networks. Firewalls, the most used and wide-spread security
tools, are tools which filter traffics flowing different systems. Despite their
large functionalities, anomalies, which could be critical for the system
integrity, can sometimes be found in their configurations. On this basis,
our project entitled Improvement of security policy quality within stateful
firewalls, will attempt to find a solution to this issue. The main objective of
this project is guarantee an optimal security level within a network,
making sure that firewalls configurations are faultless and actually reflect
the specified policy security. To achieve this objective, we first use the
upward approach to analyze filtering rule set configured for the occasion
within designed network architecture. Afterwards, we propose some audit
algorithms to detect anomalies in the rule set, either in a centralized or in
a distributed firewall setup. Implemented in a software tool, these
algorithms let us detect and remove any anomalies, while we are trying
optimizing audit process. This project opens up new horizons for some
new extensions of our study scope to other firewalls functionalities, just as
different network security devices groups.
Key words: stateful firewall, security policy, Iptables, upward

approach, intra-firewall anomaly, inter-firewall anomaly.
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page xiii
Introduction générale
De nos jours, le concept de la communication s’est démocratisé,

mettant ainsi l’accent sur l’importance et les principes de la notion de
réseau. Un réseau, par définition est une interconnexion entre des entités
ou des objets dans le but d’échanger et de partager des informations en
respectant des règles et protocoles de communication bien définis. Avec
l’avènement de l’informatique et d’Internet, le nombre de réseaux à
travers le monde a connu une forte croissance. Aujourd’hui par exemple,
chaque entreprise possède son propre réseau local informatique,
constitué d’ordinateurs et de périphériques reliés entre eux. Cette
interconnexion permet d'échanger plus facilement des données entre les
divers collaborateurs internes à l'entreprise, et ainsi de travailler en
équipe sur des projets communs. Par ailleurs, le besoin de communiquer
se faisant ressentir, chaque réseau a dû s’ouvrir vers le monde extérieur.
Il est par exemple nécessaire de pouvoir partager des informations avec
les clients de l'entreprise. C’est cette interconnexion de tous les réseaux
qui introduit le concept de l’Internet. Ce dernier est un ensemble de
réseaux informatiques interconnectés, qui transmettent des données par
le biais du protocole IP (Internet Protocol). L’inconvénient majeur résidant
dans Internet est le problème de sécurité. Certaines des menaces qui lui
sont inhérentes incluent :
 l’absence ou la légèreté d’une politique d’authentification ;

 les logiciels malveillants ;
 etc.
Amélioration de la qualité des politiques de sécurité au sein des firewalls dynamiques Page 1
1. Contexte, justification et problématique
1.1. Contexte et justification
La sécurité informatique suscite un engouement particulier dans les

communautés industrielles et de recherches, du fait de la démocratisation
de l’Internet et de la menace grandissante des trafics non autorisés dans
les réseaux. Pour parer à ces attaques, une architecture réseau
sécurisée est nécessaire. Plusieurs types de dispositifs tels que les pare-
feu, sont à cet effet utilisés pour assurer la protection du système. Un
firewall est un dispositif physique (matériel) ou logique (logiciel) qui sert
d’intermédiaire pour l’accès à un réseau (interne), permettant ou
interdisant certains types d’accès en accord avec une politique de
sécurité définie par l’administrateur du réseau. Pour ce faire, il est
important de savoir ce qu’on veut autoriser et ce qu’on veut bloquer. Il est
alors nécessaire de définir une politique de sécurité. En raison de la taille
des réseaux et de la multiplicité des attaques, la mise en œuvre d’une
politique de sécurité, est une tâche qui est devenue de plus en plus
complexe. Or une politique mal spécifiée peut générer des anomalies de
configuration pouvant porter atteinte à l’intégrité du système. Il importe
alors de pouvoir faire une analyse des configurations des règles de
sécurité afin de préserver la sécurité du système.
Les firewalls sont des équipements qui constituent les éléments

fondamentaux dans la sécurité d’un réseau (Richardson, 2008). Ils
autorisent ou bloquent le trafic en se basant sur :
 les informations de la couche réseau : adresses IP source et

destination, protocoles (ICMP (Internet Control Message
Protocol), UDP (User Datagram Protocol), TCP (Transmission
Control Protocol), ...) ;
 les informations de la couche transport : port source, port
destination, etc.
Plusieurs types de firewalls permettent d’assurer la fonction de filtrage :
 les firewalls sans état (stateless) ;

 les firewalls à états (stateful) ;
 les firewalls applicatifs.
1.2. Problématique
Pour être conforme à la politique de sécurité définie, des règles de

filtrage sont mises en place au niveau des firewalls. Avec la multiplicité
des attaques informatiques, la taille des réseaux, le nombre de services
réseau fournis au sein d’un système, l’ordre et le nombre des règles de
filtrage, il est devenu plus difficile de pouvoir mettre convenablement en
œuvre toutes les règles de filtrage. Une mauvaise définition des
exigences en matière de sécurité conduit à l’implémentation de règles
inadéquates, qui peut faire apparaître des anomalies de configuration
dans les firewalls. Une anomalie de configuration remet en cause
l’efficacité de la politique de sécurité et rend le réseau vulnérable, parce
qu’elle peut autoriser un trafic à l’origine bloqué, ou bloquer un trafic à
l’origine autorisé. Il est donc important de pouvoir déceler ces anomalies
qui sont généralement de deux ordres : les anomalies intra-firewall et
celles inter-firewall.
Selon Al-Shaer et Hamed (2004), une anomalie intra-firewall se

définit comme étant, soit l’existence d’au moins deux règles de filtrage qui
risquent de s’appliquer au même paquet, soit l’existence d’une règle de
filtrage ne pouvant jamais s’appliquer à un paquet traversant un firewall.
Par contre, une anomalie inter-firewall existe si deux ou plusieurs
firewalls quelconques, sur un chemin du réseau, appliquent différentes
règles de filtrage pour un même trafic (Al-Shaer et al. 2005). La détection
de ces dysfonctionnements est basée sur un ensemble de relations
existant entre toutes les règles. Elle peut être rendue difficile avec le
nombre de firewalls et de règles, définis au sein du réseau. La
vulnérabilité d’un système, de par la présence d’anomalies, tient du fait

que :
 des règles ne peuvent jamais être appliquées parce qu’elles

sont masquées ;
 la redondance de certaines règles augmente le temps de
réponse et l’espace mémoire nécessaire au processus de
filtrage.
Afin de s’assurer de la fiabilité et de l’intégrité du système, et ce en

permanence, des algorithmes ont été développés. Chacun de ces
algorithmes repose sur une approche d’analyse de politique spécifique.
Al-Shaer et Hamed (2004) proposent par exemple, en se basant sur
l’approche descendante, un algorithme de détection d’anomalies (inter-
firewall et intra-firewall) qui prend en compte les relations entre les règles
de sécurité et la représentation des règles, sous forme d’arbre. Alfaro,
Boulahia-Cuppens et Cuppens (2006) s’appuient par contre sur
l’approche ascendante pour proposer une solution. Voilà autant de
raisons qui nous amènent à nous intéresser à la détection d’anomalies
dans les configurations de firewalls à états. Dans le cadre de ce projet,
nous nous focalisons sur l’approche ascendante comme méthode
d’analyse, afin de proposer des algorithmes de détection d’anomalies
pour les fonctions de filtrage à états.
2. Objectifs
L’objectif général visé par ce projet est de garantir un niveau de

sécurité optimal au sein d’un réseau, en s’assurant que la configuration
des firewalls soit exempte d’erreurs, et traduise la politique de sécurité
spécifiée. Pour atteindre cet objectif général, trois objectifs spécifiques
ont été identifiés :
 faire l’état de l’art en matière de sécurité de réseau informatique;
 étudier et modéliser des firewalls ;

 développer et implémenter des algorithmes d’analyse de
configuration des firewalls.
Partie 1
PARTIE 1
POLITIQUE DE SECURITE
DANS LE RESEAU
Chapitre 1 : La sécurité informatique
CHAPITRE 1
LA SECURITE INFORMATIQUE
Le contexte d’étude de notre projet étant cerné, nous allons pouvoir

entrer dans le ‘’vif du sujet’’. Mais avant, nous abordons la sécurité
informatique, afin de mieux nous imprégner du concept. A travers ce
chapitre, nous démontrons l’importance de la sécurité dans un système,
avant de passer en revue la plupart des menaces inhérentes à l’intégrité
d’un système. Pour finir, nous présentons quelques outils et techniques
permettant de sécuriser un réseau.
1.1. Définition de la sécurité informatique
La vulgarisation d’Internet a aujourd’hui conduit à la croissance de

réseaux informatiques plus restreints, permettant ainsi une
interconnexion plus facile entre lesdits réseaux. Parallèlement, les
risques liés à l’utilisation d’Internet se sont aussi rapidement accrus. Les
menaces informatiques ont en effet connu une forte croissance ces
dernières décennies, laissant transparaître l’environnement peu sécurisé
que constituent les réseaux informatiques. Cette situation a fait prendre
conscience à la communauté informatique, du danger que pouvait avoir
une attaque sur un réseau. De nombreux facteurs ont donc conduit au
déploiement de la sécurité informatique. Au nombre de ces derniers, on
peut citer :
- la préservation du patrimoine de l’entreprise ;
- l’existence d’une menace extérieure, même potentielle ;
- les failles des systèmes.
Dès lors, il apparaît indispensable d’établir une stratégie pour se

prémunir des dommages d’une possible attaque. C’est pour répondre à
ce besoin qu’est apparu le concept de sécurité. La sécurité informatique
est l’ensemble des moyens mis en œuvre, pour réduire la vulnérabilité
d’un système contre les menaces accidentelles ou intentionnelles. Ces
moyens doivent prendre en compte :
 les éléments à protéger : matériels, données, utilisateurs ;
 leur vulnérabilité ;
 leur sensibilité ;
 les menaces et risques qui pèsent sur eux ;
 les moyens d’y faire face (préventifs et curatifs).
Les objets de la sécurité (les informations, le système, le réseau)

étant d’une importance capitale dans un Système d’Information (SI), il est
donc primordial de ne pas attendre qu’ils soient attaqués avant de
chercher à les protéger.
1.2. Objectifs de la sécurité
L’application de la sécurité au sein d’un SI vise huit (8) objectifs

spécifiques à savoir (Llorens, Levier et Valois, 2006) :
L’identification : c’est l’information permettant d’indiquer qui vous

prétendez être. Une identification élémentaire est le nom d’utilisateur que
l’on saisit dans un système informatique. Une identification plus évoluée
peut être fournie par un relevé d’empreinte digitale, une analyse faciale
ou rétinienne, etc. ;
L’authentification : elle permet de valider l’identité pour vérifier que

l’utilisateur est bien celui qu’il prétend être. Elle permet ainsi de se
prémunir de l'usurpation d'identité par une tierce personne. Une
authentification élémentaire est le mot de passe entré dans le système
informatique. Une authentification forte combine une chose que possède
l’utilisateur, et une chose qu’il connait (numéro de carte bancaire et code
personnel, par exemple) ;
L’autorisation : c’est l’information permettant de déterminer les

ressources de l’entreprise auxquelles l’utilisateur, identifié et authentifié, a
accès, ainsi que les actions autorisées sur ces ressources. L’autorisation
couvre toutes les ressources de l’entreprise ;
La confidentialité : c’est l’ensemble des mécanismes permettant

qu’une communication de données reste privée entre un émetteur et un
destinataire. La cryptographie ou le chiffrement des données est une des
solutions fiables pour assurer la confidentialité des données ;
L’intégrité : elle est l’ensemble des mécanismes garantissant

qu’une information n’a pas été modifiée. Elle fait référence à la prévention
d'une modification de l'information par un utilisateur non autorisé ;
La disponibilité : c’est l’ensemble des mécanismes garantissant

que les ressources de l’entreprise sont accessibles, que ces dernières
concernent l’architecture réseau, la bande passante, le plan de
sauvegarde, etc. ;
La non-répudiation : il s’agit d’un processus permettant de garantir

qu’un message a bien été envoyé par un émetteur et reçu par un
destinataire. Le message ne peut donc plus ensuite être dénié par son
émetteur ;
La traçabilité : c’est l’ensemble des techniques permettant de

retrouver les opérations réalisées sur les ressources de l’entreprise. Cela
suppose que tout événement applicatif soit archivé pour une investigation
ultérieure.
1.3. Principales menaces à la sécurité informatique
Les menaces à la sécurité d’un système sont aujourd’hui si

nombreuses que nous ne saurions toutes les développer dans cette
section. Néanmoins, nous aborderons les plus couramment exploitées
par les pirates.
De façon générale, la plupart des attaques exploitent les failles et

faiblesses au sein des systèmes ; ces dernières peuvent être de
diverses natures (Llorens et al. 2006):
 faiblesses des protocoles : certains protocoles tels que

SNMP (Simple Network Management Protocol) ou BGP
(Border Gateway Protocol) n’implémentent pas une véritable
couche de sécurité et s’exposent à diverses attaques,
comme les attaques par fragmentation, les dénis de services,

etc. ;
 faiblesses d’authentification : les protocoles réseau n’ont

prévu aucun mécanisme d’authentification véritable et
subissent des attaques qui s’appuient sur ce type de
faiblesses, comme les attaques de type spoofing, man-in-
the-middle, etc. ;
 faiblesses d’implémentation ou bogues : le développement

des logiciels et des piles réseau se fait de plus en plus
rapidement et sans règles strictes, ouvrant des failles
qu’utilisent certaines attaques telles que le ping-of-death ;
 faiblesses de configuration : il s’agit principalement des

mauvaises configurations d’un équipement réseau en
général, ou d’un firewall en particulier, laissant passer du
trafic non autorisé par la politique de sécurité.
Ces vulnérabilités constituent en effet, un moyen efficace pour

collecter le maximum d’informations sur le système cible afin de pouvoir
lancer une attaque. Il existe plusieurs types d’attaques dont les plus
connues sont :
IP spoofing : ce type d’attaque consiste à usurper des adresses

du réseau cible afin de pouvoir passer les barrières de filtrage. Elle utilise
en effet, le fait que l’authentification entre deux nœuds ne s’effectue en
général que sur la base de l’adresse IP. Le pirate commence en général
par choisir le système qu’il veut attaquer. Après avoir obtenu le maximum
de détails sur ce système cible, il détermine les adresses IP autorisées à
s’y connecter. Ensuite, le pirate modifie l’en-tête du paquet en remplaçant
son adresse IP par l’adresse IP d’une machine du réseau. Il envoie alors
le paquet falsifié au serveur cible, et analyse l’algorithme d’incrémentation
du numéro de séquence des paquets de ce dernier. Après avoir rendu la

machine réelle inopérante (généralement par déni de service), il envoie
une demande de connexion au serveur cible avec un numéro de
séquence. Ce dernier répond en envoyant une trame SYN|ACK à la
machine qu’il pense être l’émettrice avec des numéros de séquence et
d’acquittement. Le pirate n’établira ainsi une connexion avec le serveur,
en acquittant par une trame ACK, que si le numéro de séquence envoyé
est valide. Cette attaque reste assez difficile à réaliser parce que le pirate
peut difficilement prévoir les numéros de séquence des paquets en
provenance du serveur. Il faut une très bonne maîtrise des protocoles
pour savoir ce qu’attend le serveur à tout moment (Llorens et al., 2006).
ARP (Address Resolution Protocol) spoofing : encore connue

sous le nom de ARP-Poisoning ou ARP Redirect, elle est l’une des
techniques de détournement de flux, et de ce fait reste similaire au IP
spoofing. L’adresse MAC (Medium Access Control) permet à un
ordinateur situé dans un réseau local de pouvoir réceptionner les paquets
qui lui sont destinés. Pour qu’un nœud établisse une connexion avec un
autre nœud dans un même réseau, il envoie des requêtes ARP avec
l’adresse IP destination, associé à un champ vide, afin de connaître son
adresse MAC. La réponse ARP envoyée est ensuite conservée dans la
table de correspondance (adresse IP/adresse MAC) contenue dans le
cache ARP. Cette faiblesse d’authentification du protocole ARP peut
permettre à un pirate de s’infiltrer dans le réseau. Si ce dernier envoie
une réponse ARP indiquant son adresse MAC correspondant à l’adresse
IP destination, il pourra ainsi recevoir tous les paquets de la machine
usurpée. Le pirate a alors la possibilité de modifier les paquets avant de
les rerouter vers leur véritable destination. Cette technique qui consiste à
renvoyer le message vers son destinataire après l’avoir intercepté est
plus connue sous le nom de ‘’man-in-the-middle’’.
Man-in-the-middle : cette attaque consiste à établir un pont - sous

le contrôle d’un pirate - entre deux systèmes (généralement un serveur
cible et un poste client), dans le but d'intercepter ou même de modifier
des données. Le but visé est, de se faire passer pour le client auprès du
serveur d'une part, et pour le serveur au près du client d'autre part. Pour
y arriver, le pirate change en général le chemin du trafic afin que ce
dernier passe par lui au moyen du ARP spoofing.
Dénis de Service (DoS : Denial of Service): ces attaques ne

permettent pas en elles-mêmes d'accéder aux données du réseau. Il ne
s’agit ni d’altérer les données, ni de voler les informations transitant sur le
réseau, mais plutôt de rendre indisponible un service, un système ou un
réseau. Il existe deux types de DoS : les DoS par saturation et les DoS
par exploitation de vulnérabilités. Les DoS par saturation ont pour objectif
de submerger une machine d’un grand nombre de requêtes, afin qu’elle
ne puisse plus répondre aux demandes des clients. Les DoS par
exploitation de vulnérabilités quant à eux exploitent généralement une
faiblesse d’implémentation, ou une faiblesse d’un protocole du système
dans le but de le rendre inutilisable. Il existe plusieurs manières de mettre
un système en déni de service. Les plus connues sont:
 SYN flood : le pirate procède par envoi répété d'une

multitude de paquets SYN d’ouverture de connexion vers un
serveur. Ce dernier répond à toutes ces demandes de
connexion avec des paquets SYN|ACK. Mais le pirate ne
répond jamais par un paquet d'acquittement (ACK), ce qui
laisse le serveur dans un état intermédiaire où aucune
connexion n’existe vraiment, vu que toutes les demandes de
connexion sont en cours d'établissement. De ce fait, les
ressources (processeur, mémoire, bande passante)
nécessaires au traitement de ces connexions ne peuvent
être mises à disposition du système d’exploitation. Le
serveur continue alors à réserver inutilement ces ressources

jusqu’à saturation. Le système est alors paralysé, puisqu’il ne
peut effectuer aucune opération.
 UDP flood : Dans ce cas, il s’agit de requêtes UDP (User

Datagram Protocol). Le trafic UDP étant prioritaire sur le
trafic TCP (Transmission Control Protocol), ces requêtes
vont finir par monopoliser la bande passante et rendre
indisponibles les connexions TCP. Un exemple d’attaque
UDP flood est le ‘’Chargen Denial of Service’’. Un pirate
envoie une requête sur le port echo (port 7 : service qui
répète la chaîne de caractères reçue) d’une machine A
indiquant comme port source celui du port chargen (port
19 de service de génération de caractères) d’une machine B.
Le service chargen de la machine B renvoie alors un
caractère sur le port echo de la machine A. Ensuite le service
echo de A renvoie ce caractère sur chargen. Chargen le
reçoit, en ajoute un autre et les renvoie sur le port echo de A
qui les renvoient à son tour sur chargen ; et le procédé se
répète jusqu’à saturation de la bande passante.
 Smurf : c’est une méthode qui consiste à inonder un réseau

de paquets ping ICMP request en utilisant que des adresses
de broadcast. Le pirate envoie un ping en broadcast sur le
réseau en utilisant l’adresse IP de la machine cible. Toutes
les machines appartenant au réseau couvert par le broadcast
répondent par un paquet ICMP reply ; ce qui augmente la
saturation du réseau. Toutes les machines du réseau devront
en effet répondre à chacun des paquets ping envoyés par le
pirate, submergeant ainsi la bande passante de la machine
cible. Les conséquences de l’attaque de type Smurf sont
souvent : la perte de la bande passante, le ralentissement

voire le blocage du réseau.
DDoS (Distributed Denial of Service): le principe est de perpétrer

une attaque en utilisant un très grand nombre de machines déjà
corrompues. Le pirate a alors plus de chances de pouvoir mettre en déni
de service le système cible. Il existe deux façons d’exécuter un DDoS :
soit le pirate mène l’attaque en complicité avec un groupe de personnes,
soit il se sert de plusieurs machines corrompues appelées zombies qu’il
est capable de contrôler. Cette dernière méthode, qui est la plus
exploitée, utilise deux types de machines pour lancer une attaque : les
maîtres appelés aussi généraux et les zombies encore appelés daemons.
Les premiers sont sous le contrôle direct du pirate, tandis que les
seconds sont sous le contrôle des maîtres. Sans ces derniers, le pirate
serait amené à se connecter à chaque zombie pour leur donner l’ordre
d’attaque, ce qui serait bien plus long et plus facilement repérable.
Les virus : ils s’introduisent généralement dans des programmes

ou des fichiers. Les répercussions de la présence d’un virus sur une
machine sont très variées : consommation inutile des ressources
mémoire et de calcul du système, saturation de l’espace disque,
effacement de données, formatage des disques durs, modification du
BIOS (Basic Input Output System), propagation sur d’autres machines
par l’intermédiaire du partage de fichiers, etc.
Les chevaux de Troie : ils permettent au pirate de pouvoir prendre
le contrôle de la machine d’un utilisateur bien souvent à son insu. Grâce
à une application, en apparence banale, le pirate intègre un programme
ou un code malveillant. Il s’en sert ensuite comme appât pour attirer
l’utilisateur. Lorsque ce dernier l’installe sur sa machine et l’exécute, le
bout de code malveillant pourra s’exécuter de façon transparente pour
l’utilisateur.
1.4. Principaux outils de sécurité
Afin de se prémunir contre la plupart des attaques, il existe certains

moyens permettant d’établir un niveau de sécurité minimum au sein du
réseau. A défaut d’aborder toutes ces techniques, nous ne présentons
que les plus utilisées.
Chiffrement : cette technique apporte une solution au problème

d'établissement d'une relation de confiance entre deux entités souhaitant
échanger des informations entre elles. L'art du chiffrement-déchiffrement
est de plus en plus utilisé pour sécuriser le flux de données entre
différents systèmes. Le chiffrement consiste à faire subir à une
information claire, grâce à une clé, une transformation plus ou moins
complexe pour en déduire une information inintelligible, dite chiffrée
(cryptogramme). Le déchiffrement est l'opération inverse qui consiste à
ramener l'information chiffrée à son état initial, en connaissant la clé de
chiffrement. L'utilisation du chiffrement vise des objectifs précis en
matière de sécurisation des communications. Il s'agit entre autres
d'assurer : l'authentification, la non-répudiation, la confidentialité et
l’intégrité des données.
Les technologies de chiffrement et déchiffrement sont mises en

œuvre grâce à des algorithmes cryptographiques qui reposent
généralement sur des problèmes mathématiques complexes. Il existe
deux méthodes de chiffrement en cryptographie à savoir : le chiffrement
symétrique et le chiffrement asymétrique.
Le chiffrement symétrique, encore appelé chiffrement à clé secrète,

utilise une unique clé aussi bien pour le chiffrement que pour le
déchiffrement. De ce fait, cette clé doit être tenue secrète puisque la
sécurité des données repose sur sa non-divulgation de même que sur sa
capacité à résister aux attaques de cryptanalyse. Les algorithmes de
chiffrement symétrique les plus connus aujourd'hui sont : DES (Data
Encryption Standard), IDEA (International Data Encryption Algorithm),

RC2 (Rivest Code #2), RC4 (Rivest Code #4), AES (Advanced
Encryption Standard), etc.
Le chiffrement asymétrique ou chiffrement à clé publique quant à

lui, utilise deux clés pour chiffrer un message : la première appelée clé
publique pour chiffrer le message et la seconde appelée clé privée pour
déchiffrer le message. Les systèmes de chiffrement asymétrique les plus
courants sont : RSA (Rivest Shamir Adleman), les algorithmes de Diffie-
Hellman, les algorithmes de El Gamal.
IDS (Intrusion Detection System): en sécurité réseau, une seule

technologie ne peut pas toujours répondre à tous les besoins ; une
défense à plusieurs niveaux peut s'avérer plus efficace et plus fiable avec
de meilleurs résultats. C'est dans cette optique que s'inscrivent les IDS.
C'est un ensemble de logiciels et/ou de matériels qui a la charge de
surveiller tous les paquets transitant sur un système, dans le but de
détecter tout comportement anormal, et de générer des alertes le cas
échéant. Ils ont donc la contrainte de fonctionner en temps réel, ce qui
n'est pas sans conséquences sur la consommation des ressources
(processeur et bande passante). Lorsqu'une activité non autorisée est
détectée, un système IDS peut envoyer, à une console de gestion, des
alertes accompagnées d'informations détaillées concernant l'activité
suspecte. Les IDS utilisent plusieurs techniques de détection d'anomalies
au nombre desquelles : la détection par seuil, la détection par
comportements anormaux, la détection par scénario.
Les fonctionnalités des IDS sont abordées en détails en annexe B

du présent document. AAFID, ASAX, GASSATA, Tripwire, WATCH,
DragonSquire, Tiger sont des exemples de HIDS.
IPS (Intrusion Prevention System) : contrairement aux IDS qui ne

font que détecter les intrusions, les IPS sont des équipements qui sont
conçus pour arrêter toute activité suspecte. En plus des fonctionnalités

d’un IDS, un IPS assure les fonctions d’automatisation d'analyse des
logs, d’analyse des contextes de connexion et de coupure des
connexions suspectes.
VPN (Virtual Private Network): l'ère des réseaux informatiques

distribués a fait naître une problématique : comment deux différents
réseaux géographiquement distants peuvent-ils échanger de façon
sécurisée des données en temps réel via Internet? La technologie des
VPN semble apporter les éléments nécessaires pour résoudre ce
problème. Un VPN est un réseau privé construit au sein d'une
infrastructure publique (tel qu'Internet) reliant deux réseaux distincts. Il
s’agit en fait de mettre en place un canal chiffré, ou tunnel, entre les
différents réseaux en bout de ligne par Internet. C’est ce qui fait de cette
interconnexion un réseau d’une part privé ; parce que les échanges qui y
transitent sont confidentiels pour les autres utilisateurs du réseau public ;
et virtuel d’autre part, parce que la liaison ainsi obtenue n’est pas
matérialisée par des liens physiques. Le principe des VPN est, tout en
mettant l’accent sur le contrôle d’accès, de satisfaire aux critères
suivants : l’authentification, la confidentialité et l’intégrité des données. Il
existe plusieurs protocoles permettant de mettre en place une solution
VPN, dont les plus connus sont : IPSec (Internet Protocol Security), SSH
(Secure Shell), PPP (Point-to-Point Protocol), L2TP (Layer 2 Tunneling
Protocol), PPTP (Point-to-Point Tunneling Protocol), GRE (Generic
Routing Encapsulation), SSL/TLS (Secure Sockets Layer/Transport Layer
Security).
Conclusion partielle
Ce chapitre a permis de définir le concept de sécurité des

systèmes informatiques, et d’en cerner les objectifs et enjeux dans un
environnement peu sécurisé. Pour atteindre ces objectifs, il est important
de définir une politique de sécurité, de même que les stratégies à mettre

en œuvre pour protéger un système des différentes attaques présentées
dans ce chapitre.
Chapitre 2 : Gestion de la politique de sécurité au sein d’un réseau
CHAPITRE 2
GESTION DE LA POLITIQUE DE SECURITE

AU SEIN D’UN RESEAU
Après avoir présenté au chapitre précédent les objectifs de la

sécurité de même que les menaces qui pèsent sur un réseau
d’entreprise, nous décrivons dans ce chapitre comment définir une
politique de sécurité réseau et élaborer des stratégies de sécurité autour
de cette politique. L’objectif de ce chapitre est de faire ressortir qu’une
sécurité bien comprise passe par la connaissance de l’entreprise, de son
périmètre et de son organisation afin d’en déduire des besoins puis une
politique de sécurité réseau.
2.1. La politique de sécurité au sein d’un réseau
Mettre en place la sécurité au sein d’un système est une tâche qui
requiert beaucoup de précautions et réflexions. A cet effet, Bloch et
Wolfhugel (2007) ont écrit : «… déployer les derniers outils de sécurité
disponibles sur le marché sans réflexion préalable sur les besoins de
l’entreprise, ne peut traiter que des problèmes de sécurité à un instant
donné et n’assurer qu’une partie de la sécurité des éléments critiques de
l’entreprise.». Afin de protéger les ressources critiques d’un réseau, il est
donc indispensable de pouvoir définir une politique de sécurité. Ensuite, il
faut choisir une architecture, les outils et procédures de sécurité à
déployer dans le réseau.
2.1.1 Définition
Une politique de sécurité est un document dans lequel se trouvent

(s’il est bien élaboré) toutes les réponses aux questions qu’un ingénieur
en charge d’une étude se pose lorsqu’il aborde le volet sécurité d’un
projet informatique dont la réussite dépend entre autres de la prise en
compte dès le début des contraintes de sécurité (Remazeilles, 2009). La
politique de sécurité d’un SI est donc un document confidentiel,
indépendant de tout produit ou technologie. Ce dernier fournit une suite
de règles et de principes, classés par thèmes, répondant aux besoins de
sécurité de l’entreprise. La thématique réseau dans la politique de
sécurité englobe les recommandations pour l’exploitation des liens
réseaux et des équipements (Remazeilles, 2009). Les domaines abordés
évoluent avec les intérêts économiques de l’entreprise et concernent
notamment :
 la gestion des accès au réseau et aux ressources (en relation

avec la gestion des identités et des droits) ;
 la cryptographie ;
 la sécurité des équipements et des configurations ;

 la sécurité des systèmes terminaux.
De façon générale, la politique de sécurité réseau est un document

à caractère non technique auquel sont associés des documents
supplémentaires tels que (Llorens et al. 2006) :
 les guides : il s’agit de documents détaillant la manière

d’implémenter les politiques de sécurité. Ils sont considérés
comme des documents complémentaires aux politiques ;
 les standards : ce sont des documents de standardisation de
normes et méthodes émanant d’organismes internationaux tels
que l’ISO (International Standardization Organization), l’IETF
(Internet Engineering Task Force), l’IEEE (Institute of Electrical
and Electronics Engineers), etc. ;
 les procédures : il s’agit de documents à caractère opérationnel
et technique, qui décrivent de manière claire et précise les
étapes à suivre pour atteindre un objectif de sécurité donné qui
est conforme à une exigence en matière de sécurité.
Un document de politique de sécurité réseau peut être écrit de

plusieurs manières, allant d’un texte unique à un ensemble de politiques
de sécurité. Le choix d’écrire un ou plusieurs documents est le plus
souvent dicté par la taille de l’entreprise. Plus l’entreprise est importante,
plus il est nécessaire de créer des documents séparés, chaque niveau
faisant référence au niveau supérieur. Toutefois, décliner une politique de
sécurité réseau en sous-niveaux n’est pas chose facile. Cela demande en
effet une parfaite connaissance du domaine étudié. Généralement,
l’expérience de l’entreprise et son historique permettent d’éviter les
pièges et surtout de ne retenir que les éléments critiques. Ainsi, la figure
1 illustre une classification de la politique de sécurité en niveaux. La
politique de sécurité générale est décomposée en différentes politiques
dont la politique de sécurité réseau. Cette dernière se subdivise selon les

différents sous-réseaux en politiques de sécurité Intranet et Internet.
Chacune d’elles définit des procédures qui découlent des standards,
guides et recommandations.
Politque générale de sécurité
Politique de sécurité réseau
Politique de sécurité Politique de sécurité

réseau Intranet réseau Internet
Standards/guides/recommandations Standards/guides/recommandations
Intranet Internet
Procédures Intranet Procédures Internet

messagerie
compte d'accès
etc.
Figure 1 : Hiérarchie des politiques de sécurité
2.1.2 Objectifs
Une politique de sécurité a pour cible la protection des éléments

critiques de l’entreprise, afin d’en assurer la pérennité en cas d’incident. Il
devient alors indispensable de remettre en cause sa qualité et son
efficacité quand le besoin se fait ressentir. En effet, l'un des principes de

base de la qualité est la prévention et l'amélioration permanente. Cela
signifie que la qualité est un projet sans fin dont le but est de prendre en
compte les dysfonctionnements le plus en amont que possible. La
politique de sécurité est alors une démarche dont l’évolution dans le
temps suit un cycle défini par la démarche PDCA (Plan-Do-Check-Act de
l’anglais ou encore Planifier-Développer-Contrôler-Ajuster) ou cycle de
DEMING représenté à la figure 2. Il s’agit d’un modèle d’amélioration
continue de la qualité, structuré comme suit (Remazeilles, 2009) :
Plan ou Planifier : la planification commence avec la décision

d’organiser formellement la sécurité. Elle consiste en un inventaire
exhaustif des ressources à protéger et à la rédaction de directives pour
chaque domaine concerné. À la fin de cette phase de planification, la
politique de sécurité sera rédigée par le groupe de travail avec
l’assistance éventuelle d’un consultant ayant une vue extérieure sur
l’entreprise.
Do ou Développer : la mise en œuvre de la politique de sécurité

ne correspond point pour point à ce que nous venons de décrire
précédemment. L’adhésion de tous au respect des règles décrites est le
fondement d’une bonne prise en compte de la sécurité.
Check ou Contrôler : le suivi de la politique de sécurité consiste à

s’assurer que les contraintes imposées par le texte sont prises en compte
par les équipes en charge des projets et celles en charge de
l’exploitation. Cela implique une présence systématique d’un représentant
ou responsable de la sécurité aux réunions de suivi et un contrôle des
processus d’exploitation en vigueur.
Act ou Agir : lorsque le besoin se fait sentir ou lorsque la date

planifiée de révision approche, il s’agit après analyse de modifier la
politique de sécurité dans le but de l’adapter aux menaces qui pèsent sur
les services qu’elle couvre ou sur de nouveaux services.
Figure 2 : Cycle de Deming définissant la méthode PDCA
Cette démarche basée sur une approche préventive et corrective

s’inscrit dans le respect des principes de sécurité réseau abordés au
chapitre 1. Toutefois, pour pérenniser une politique de sécurité, il faut
avant toute chose la définir et l’appliquer. Quelle que soit l’entreprise
concernée et la politique de sécurité réseau définie, son application est
confrontée aux deux contraintes majeures qui sont (Bloch, Wolfhugel,
2007) :
 contrainte technique : toutes les technologies, même les plus

évoluées, ont des limites. Il faut donc veiller à ce que la solution
technique choisie réponde efficacement aux exigences en
matière de sécurité ;
 contrainte économique : pour une solution technique donnée,
une contrainte d’ordre économique peut surgir, si bien qu’il faut
parfois choisir une solution moins onéreuse, même si elle ne
répond pas exactement aux besoins de sécurité. Un tel
compromis n’est acceptable qu’à un seuil défini par l’entreprise.
La définition d’une politique de sécurité réseau est une tâche qui

s’effectue en plusieurs étapes, dont la première est la délimitation des
frontières du réseau.
2.2. Périmètre de sécurité
C’est la première notion à établir lors d’une conception de politique

de sécurité réseau. Il est inutile de se préoccuper de sécurité sans avoir
défini ce qui était à protéger (Bloch, Wolfhugel, 2007). Le périmètre de
sécurité délimite l’intérieur et l’extérieur du réseau. Il permet ainsi de
pouvoir identifier de façon unique toutes les entités, tant matérielles
qu’immatérielles se trouvant au cœur du réseau. Le principe est de
regrouper les entités ou les fonctions afin de mettre en place des niveaux
de sécurité à la fois imbriqués et séparés. Dans la plupart des cas, ces
entités englobent les ordinateurs et périphériques, les équipements
d’interconnexion réseau, les logiciels et les systèmes d’exploitation. Le
responsable en charge de la sécurité peut alors recenser toutes les
ressources du réseau, définir et attribuer les droits d’accès sur chacune
d’elles. Ensuite, il faut également définir des périmètres de sécurité pour
chacun des sous-réseaux dans le réseau Intranet ; l’objectif étant de
rendre plus difficile une éventuelle pénétration. Cette stratégie de
périmètre de sécurité doit être couplée avec celle des goulets
d’étranglement, qui vise à mettre en place un nombre limité de points de
contrôles d’accès de ces périmètres. Toute organisation désireuse de
protéger ses systèmes et son réseau doit donc déterminer son périmètre
de sécurité. Une fois ce périmètre établi, il faut ensuite définir les risques
pouvant nuire à l’intégrité des ressources internes au réseau.
2.3. Analyse des risques
La politique de sécurité d’un réseau se fonde avant tout sur une

gestion des risques décrivant les ressources critiques du réseau, les
objectifs de sécurité, les vulnérabilités, les probabilités d’occurrence de
menaces sur ces ressources vitales, ainsi que leurs conséquences sur le
système. Il est donc fondamental d’établir de façon claire et précise,
toutes les ressources ou les biens vitaux du système. Bien souvent, il
s’agit d’une tâche qui prête à discussion, chaque entité se considérant

comme un secteur clé. Dans un réseau, les ressources peuvent être de
plusieurs ordres. Ainsi, on peut avoir :
 le matériel : équipements réseau, ordinateurs, etc. ;

 les données : base de données, sauvegardes, informations
diverses, etc. ;
 les logiciels : sources des programmes, applications
spécifiques, etc.
Une fois ces éléments identifiés, et les objectifs spécifiques de

sécurité cernés (confère chapitre 1), il convient d’associer, pour chacun
d’eux, l’analyse des risques proprement dite qui se décompose en trois
facteurs (Bloch, Wolfhugel, 2007) :
 la vulnérabilité : il s’agit d’une faiblesse de sécurité qui peut être

de nature logique, physique, etc. Une vulnérabilité peut
découler, par exemple, d’une erreur d’implémentation dans le
développement d’une application, erreur susceptible d’être
exploitée pour nuire à l’application (pénétration, refus de
service, etc.). Elle peut également provenir d’une erreur de
configuration. Elle peut enfin avoir pour origine une insuffisance
de moyens de protection des biens critiques, comme l’utilisation
de flux non chiffrés, l’absence de protection par filtrage de
paquets, etc. ;
 la menace : elle désigne l’exploitation d’une faiblesse de
sécurité par un pirate, qu’il soit interne ou externe au réseau. La
probabilité qu’un événement exploite une faiblesse de sécurité
est généralement évaluée par des études statistiques, même si
ces dernières sont difficiles à réaliser ;
 les conséquences : il s’agit de l’impact (perte financière,
dommages sur l’image de marque, indisponibilité des
infrastructures et des données, etc.) sur l’entreprise de

l’exploitation d’une faiblesse de sécurité. Estimer une
conséquence d’une faiblesse de sécurité nécessite
généralement une connaissance approfondie de l’entreprise et
requiert la participation de l’ensemble des experts de cette
dernière.
La connaissance des faiblesses de sécurité n’est possible que par

des audits réguliers de sécurité, effectués soit par l’équipe en charge de
la sécurité, soit par des consultants externes. Bien que la sécurité
absolue n’existe pas en soi, l’entreprise détermine le niveau de risque
qu’elle est prête à accepter sur ses ressources en comparaison avec le
coût induit par les menaces qu’elle encourt (Bloch, Wolfhugel, 2007).
Le rapprochement entre les ressources critiques de l’entreprise, les

objectifs de sécurité et les risques de sécurité associés permet de définir
les exigences de sécurité qui constituent l’essence de la politique de
sécurité réseau. Elles ont pour but de garantir les objectifs de sécurité, de
protéger les éléments critiques et de mitiger les risques (Bloch,
Wolfhugel, 2007). Une fois cette étape franchie, il faut ensuite choisir la
stratégie à adopter pour sécuriser le système.
2.4. Stratégie de sécurité
Elle permet, après avoir déterminé les exigences de sécurité, de

sélectionner et d’implémenter les contrôles de sécurité afin de protéger le
système concerné. La figure 3 présente toutes les étapes à mettre en
œuvre lors de la définition d’une politique de sécurité.
Figure 3 : Elaboration de stratégie réseau sur la base de la politique de

sécurité réseau définie (source : Bloch, Wolfhugel, 2007)
La stratégie de sécurité détermine de façon générale les deux

dernières étapes que sont la procédure de sécurité ou le choix des
équipements à utiliser, et la mise en œuvre des règles de sécurité au sein
des équipements choisis. Une fois cette étape définie, il faut ensuite
élaborer des stratégies de défense supplémentaires dans le seul objectif
de se protéger autant que possible des attaques. Ces stratégies ont été
développées en annexe C du document.
Toute politique de sécurité réseau s’accompagne d’un ensemble de

stratégies ayant non seulement pour objectif d’établir un premier niveau
de règles de sécurité, mais aussi de mettre en œuvre des solutions
techniques dans une seconde étape. Les architectures réseau et les
services offerts deviennent de plus en plus complexes. Cette complexité
est susceptible de remettre en cause les mécanismes de sécurité
préalablement définis. L’entreprise doit donc être à la fois adaptable et

réactive dans ses choix stratégiques afin de protéger ses périmètres de
sécurité. Après avoir défini les politiques et stratégies de sécurité réseau,
nous allons détailler au chapitre 3 un cas particulier de solutions
techniques qu’il est possible de mettre en œuvre afin de protéger le
réseau et ses services des attaques : les firewalls.
Chapitre 3 : Etat de l’art sur les firewalls
CHAPITRE 3
ETAT DE L’ART SUR LES FIREWALLS
Garantir la sécurité au sein d’un réseau est devenu un objectif

primordial pour tout administrateur réseau. Cet objectif reste toutefois
difficile à atteindre en raison de la multiplicité des risques provenant tant
de l’intérieur du réseau que du monde extérieur. Cependant, de
nombreux dispositifs permettent de protéger un réseau privé de diverses
menaces pouvant nuire à son fonctionnement. Ce chapitre présente un
des principaux outils qui constituent la première ligne de défense au sein
d’un réseau : les firewalls.
3.1. Historique et terminologie sur les firewalls
La technologie des firewalls est apparue dans les années 80 pour

palier à un nouveau problème de sécurité lié à l’émergence de l’Internet.
En 1988, un employé de la « NASA Ames Research Center » en
Californie a envoyé un mémorandum par courrier électronique à son
collègue qui a pu lire « Nous sommes actuellement attaqués par un virus
Internet appelé Morris Worm » (M’Bata et Persent, 2006). Ce virus était la
première attaque à grande échelle sur Internet. La communauté
d’Internet a collaboré à la recherche de nouveaux moyens de protection
contre ces nouvelles menaces. A la suite de cela sont apparus de
nouveaux produits de protection contre ces attaques comme les anti-virus
et les pare-feu.
D’un point de vue historique, l’industrie du firewall est jeune mais

est rapidement arrivée à maturité. La première génération de firewall a
été développée vers 1985 par la Cisco’s IOS software division. Ce type
de firewall est dit à filtrage de paquets. Le premier rapport concernant
ceux-ci n’est pas paru avant 1988, quand Jeff Mogul publia ses études
pour Digital Equiment Corporation (M’Bata et Persent, 2006).
Durant les années 1989-1990, Dave Presotto et Howard Trickey

d’AT&T Bell furent les pionniers de la seconde génération de firewall avec
leurs recherches sur les relais de circuit (M’Bata et Persent, 2006). Ils ont
aussi implémenté le premier modèle de la troisième génération de
firewall, connu sous le nom de firewall de niveau application. Malgré tout,
ils n’ont jamais publié d’article sur leur travail, ni vendu de produit basé
sur leur travail.
Comme souvent dans le monde de l’informatique, les recherches

sur la troisième génération de firewall ont été faites indépendamment par
un grand nombre d’américains au début des années 90. Les premières
parutions à ce sujet furent publiées en 1990 et 1991. Les travaux de
Marcus Ranum en 1991 ont rapidement évolué pour devenir le premier

produit commercial utilisant les services proxy (M’Bata et Persent, 2006).
En 1991, Bill Cheswick et Steve Bellovin commencèrent leurs

recherches sur le filtrage dynamique de paquets, et aidèrent à développer
un produit interne pour Bell, bien que ce produit ne fût jamais vendu
(M’Bata et Persent, 2006). En 1992, Bob Braden et Annette DeSchon
commencèrent indépendamment des recherches sur le firewall de
quatrième génération, pour développer un produit nommé Visa qui sera
mis sur le marché en 1994 (M’Bata et Persent, 2006).
Les firewalls étaient des dispositifs initialement conçus pour

empêcher le piratage. C’est de cette finalité que vient l'origine du terme
employé. Un firewall, ou pare-feu, est en effet une barrière qui empêche
la propagation d'un incendie. Il s'agit en général d'un système de portes
ou de cloisons fixes ou amovibles, ignifugées et complètement étanches,
placées aux endroits stratégiques d'un bâtiment. Leur fermeture en cas
d'incendie permet de contenir le feu dans des zones réduites, d'où il ne
se propagera pas. De la même façon, un firewall était à l'origine placé en
un point stratégique d'un réseau, afin d'éviter que l'incendie que
représentait la compromission d'un ou plusieurs terminaux ne se
répande, compromettant la sécurité de l’ensemble du système.
3.2. Définition et rôle des firewalls
Parmi la grande variété d’outils ayant pour rôle d’assurer la sécurité

au sein d’un réseau, on retrouve notamment les firewalls. Un firewall est
un dispositif physique (matériel) ou logique (logiciel) placé entre des
systèmes (ou groupes de systèmes) distincts. Ce dispositif permet de
contrôler le trafic de données entre les systèmes qu’il interconnecte, en
permettant ou en interdisant certains types d’accès en accord avec une
politique de sécurité définie par l’administrateur. De façon générale, il se
situe à la frontière d’un réseau dans le but de le protéger des trafics
malicieux et non-autorisés. Dans le cas de la figure 4, nous avons un

réseau local relié à Internet via un firewall, ce dernier se trouvant à la
frontière du réseau à protéger. Un pare-feu possède au moins deux
interfaces. Par exemple, dans le cas d’un firewall de bord dans une
entreprise :
 une interface pour le réseau interne à protéger ;

 une interface pour le réseau externe, le plus souvent Internet.
Réseau local
Firewall
Internet
Figure 4 : Exemple de positionnement de firewall
Cet outil a pour but de sécuriser au maximum le réseau local de

l'entreprise, de détecter les tentatives d'intrusion et d'y parer le mieux
possible. Cela représente une sécurité supplémentaire rendant l’accès à
Internet beaucoup plus sûr. Le firewall propose donc un véritable contrôle
sur le trafic réseau de l'entreprise. Il permet de maintenir la confidentialité,
l’intégrité et la disponibilité des données et ressources au sein du réseau.
Des règles de filtrage sont définies au sein des firewalls, pour leur
permettre de jouer pleinement leurs fonctions. Celles-ci régissent le
traitement des paquets traversant le pare-feu. Le processus de filtrage
est un processus séquentiel au cours duquel, les propriétés des paquets

transitant par le firewall sont comparées aux règles de ce dernier. Lors de
la création des règles de filtrage, il est d’usage de choisir la politique de
sécurité par défaut. Il existe deux grandes façons de configurer un
firewall : soit on utilise la politique du ‘’mostly-opened’’ où « tout ce qui
n'est pas explicitement interdit est autorisé », soit celle du ‘’mostly-
closed’’ où « tout ce qui n'est pas explicitement autorisé est interdit ». Le
‘’mostly-opened’’ repose sur le principe qu’on laisse tout passer par
défaut, et qu’on va ensuite restreindre pas à pas les accès et les services
qu’on ne souhaite pas gérer. La politique du ‘’mostly-closed’’ quant à elle
effectue l’inverse : on commence d’abord par tout interdire par défaut,
puis on ne laisse passer ensuite que les services ou adresses désirés ou
indispensables. Cette dernière politique est la plus adaptée aux firewalls
parce que la sécurité est plus renforcée.
Un paquet, qu’il soit de type IP, TCP ou UDP, renferme des

informations importantes telles que son adresse d’émission, l’adresse de
sa destination, son TTL (Time To Live), les ports d’expédition et de
destination, etc. Lorsqu’un paquet arrive au niveau du firewall, les
informations contenues dans son en-tête sont évaluées par rapport à
chacun des champs de la première règle de filtrage. Si une
correspondance est établie, l’action associée à la règle est exécutée ;
dans le cas contraire, le traitement se poursuit sur la règle suivante
jusqu’à ce qu’une règle soit conforme avec les informations du paquet. Si
toutefois aucune règle n’est trouvée, alors l’action définie par défaut est
exécutée. Considérons un firewall ayant ‘’n’’ règles de filtrages,
chacune désignée par un numéro ‘’num’’ (allant de 1 à n). L’algorithme de
filtrage d’un paquet traversant ce firewall est décrit à la figure 5.
Début
num = 1
num < n
Correspondance établie avec les

informations d'en-tête du paquet ?
Effectuer action de
filtrage
num = num + 1 correspondant à la
règle numéro ''num''
Effectuer action de
filtrage par défaut
Fin
Figure 5 : Algorithme de filtrage des paquets d’un pare-feu
3.3. Fonctionnalités spécifiques des firewalls
Le choix d’un type de firewall est déterminé par les besoins en

matière de sécurité de l’entreprise. La définition d’une politique de
sécurité vient toujours en premier lieu, et l’analyse des produits répondant
aux besoins exprimés en second. Quel que soit le choix opéré, il faut tenir
compte de trois paramètres importants à savoir : la performance, le coût
et l’intégration de l’outil dans le système d’information en place dans

l’entreprise. Les firewalls intègrent de plus en plus de nombreuses
fonctionnalités, des plus simples aux plus complexes parmi lesquelles on
peut citer :
 le filtrage des entrées de la carte réseau ;

 le filtrage applicatif ;
 le filtrage statique et dynamique ;
 la traduction ou translation d’adresses, etc.
La plupart de ces fonctionnalités sont développées en annexe D de

notre document.
3.4. Catégories de firewalls
Il existe différentes catégories de firewalls, chacune possédant des

fonctionnalités particulières. Le choix d’un type de firewall dépendra de
l’utilisation que l’on souhaite en faire, mais aussi des différentes
contraintes imposées par le réseau à protéger. Ainsi, on distingue les
firewalls grâce à des critères bien précis. Au nombre de ces critères, on
peut citer notamment selon Niederberger et al., (2006) :
 la prise en charge du suivi de l’état de la communication;

 le nombre d’hôtes ou de réseaux connectés au firewall ;
 le niveau d’interception de la communication (niveau réseau ou
niveau application du modèle OSI (Open Systems
Interconnection).
3.4.1 Les firewalls sans états ou stateless

Ce sont les firewalls les plus élémentaires dans la grande famille
des pare-feu. Leur principe repose sur le filtrage de paquets ou filtrage
statique.
A l’origine, c’est l’une des premières technologies mises en œuvre

au niveau des pare-feu ; ils constituent en effet la première génération
des firewalls. Le filtrage de paquets n’est utilisée que sur les couches
réseau et transport du modèle OSI. De ce point de vue, les firewalls
statiques sont similaires aux routeurs. Les routeurs assurent en effet les
fonctions de base de filtrage du trafic. Ils font un contrôle de chaque
paquet indépendamment les uns des autres, en se basant sur un
ensemble de règles prédéfinies par l’administrateur appelées listes de
contrôles d’accès (ACL : Access Control List). Aucune information n’est
donc conservée de l’analyse de chaque paquet, et aucune corrélation
entre les paquets n’est effectuée par le pare-feu (Llorens et al., 2006).
Une ACL est composée de critères ou champs de filtrage tels que :

le type de protocole (TCP, UDP, IP, ICMP), les adresses IP source et
destination, les numéros de port source et destination, et le champ action
de filtrage qui spécifie si le paquet doit être accepté, rejeté, détruit ou
ignoré. Le tableau I illustre des occurrences de critères qu’on peut avoir
dans une ACL, sans toutefois en spécifier la syntaxe.
Tableau I : Configuration des listes de contrôles d’accès
N° Action IP source IP dest Protocole Port Port

source dest
1 Accept 192.168.10.20 194.154.192.3 tcp any 25
2 Accept any 192.168.10.3 tcp any 80
3 Accept 192.168.10.0/24 any tcp any 80
4 Deny any any any any any

Toutefois, ces firewalls présentent des limites. Il n'est en effet pas
possible de se préserver des attaques de type IP-spoofing ou SYN
Flood. Les règles de filtrage de ces firewalls ne sont basées que sur les
adresses IP et les ports. Une solution pour se protéger des attaques de
type IP-spoofing est de mettre en place une règle interdisant les paquets
provenant du réseau extérieur, dont l'adresse IP source correspond soit à
une adresse valide du réseau local, soit à l’adresse de ‘’loopback’’.
La technologie de filtrage de paquets est une technique assez

répandue dans la plupart des routeurs.
3.4.2 Les firewalls à états ou stateful
La technologie des firewalls à états a été inventée par

Checkpoint en 1993 (Bloch et Wolfhugel, 2007); elle constitue une
évolution des firewalls sans états. Dans un réseau, les applications
utilisent des ports sources dont on ne peut connaître à l’avance la valeur.
Les firewalls à états prennent en compte la validité des paquets qui
transitent par rapport aux paquets précédemment reçus. Ils incluent
toutes les fonctionnalités d’un filtrage de paquets, auxquelles ils ajoutent
la capacité de garder en mémoire dans une table d’états des connexions,
les différents attributs de chaque session, de leur commencement jusqu’à
leur fin : c’est le mécanisme du ‘’stateful inspection’’.
La technique de filtrage des firewalls stateful permet de filtrer les

paquets en se basant sur la couche transport du modèle OSI (filtrage au
niveau des ports de communication TCP-UDP). De plus, elle permet de
suivre l’état des sessions et de laisser passer ou de rejeter les paquets
en fonction de leurs états (Llorens et al., 2006). Une connexion se définit
comme étant la procédure permettant à un utilisateur de se mettre en
relation avec un système informatique et, si nécessaire, de se faire
reconnaître de celui-ci. Tous les paquets appartenant à une connexion
établie entre un hôte et une autre machine se verront attribuer un ‘’tag’’
par la machine d’état. C’est ce tag ou attribut qui permettra, en plus de
l’action de filtrage, d’accepter, de rejeter, de détruire ou d’ignorer tout
paquet transitant entre les deux hôtes. En d’autres termes, le firewall
vérifie que chaque paquet d’une connexion est bien la suite du précédent,
et la réponse à un paquet dans l’autre sens. Les différents attributs que

peut prendre une connexion sont :
 NEW : le client envoie le premier paquet d’un flux de données.

Cette action initialise la machine d’état qui marque cette
nouvelle activité comme correspondant à une nouvelle
connexion (NEW) ;
 ESTABLISHED : suite à ce premier paquet, si le firewall est
configuré pour l’accepter, alors la machine répond en envoyant
un paquet de réponse. A l’occurrence de cette réponse, la
machine d’état change le statut de la connexion de NEW à
ESTABLISHED ;
 RELATED : une connexion est considérée comme RELATED
quand elle est liée à une autre connexion déjà établie, donc
dans l'état ESTABLISHED. Ainsi, pour qu'une connexion soit
identifiée comme RELATED, on doit tout d'abord disposer d'une
autre connexion dans l'état ESTABLISHED et que cette
connexion crée alors une connexion extérieure à la connexion
principale ;
 INVALID : le paquet ne peut être identifié ou lié à aucune autre
connexion connue et valide ;
 UNTRACKED : cet état est particulier car il correspond aux
paquets (et pas à une connexion) qui ne doivent pas être pris en
charge par la machine d’état.
Cette technique est la mieux adaptée aux protocoles de type

connecté ou « à états » comme TCP, qui introduisent une notion de
connexion ou session. Pour d’autres protocoles par contre, tels que ICMP
et UDP, auxquels n’est associée aucune notion de connexion, le firewall
est amené à examiner les paquets, et peut seulement gérer des timeout,
souvent de l’ordre d’une minute.
Cette technologie reste malgré tout limitée. En effet, si les

paramètres de connexion ne sont pas supprimés de la table d’états dès
que la communication s’est achevée, des connexions indésirables
pourraient être autorisées. Des utilisateurs mal intentionnés pourraient
ainsi accéder au réseau malgré la barrière de filtrage.
3.4.3 Firewall applicatif
Encore connu sous diverses appellations (proxy, relais applicatif,

passerelle applicative, etc.), ce type de pare-feu fonctionne
essentiellement au niveau de la couche application du modèle OSI. Pour
ce faire, il est nécessaire de pouvoir extraire les informations du protocole
de niveau application afin de les étudier. Chaque protocole dispose d’un
module qui lui est spécifique, parce qu’il faut interpréter les messages de
façon différente pour chaque application. Par exemple, le protocole HTTP
(HyperText Transfer Protocol) sera filtré par un processus proxy HTTP.
En général, un firewall applicatif se comporte comme un interpréteur et se
substitue soit au client, soit au serveur. Plutôt que d’autoriser une
connexion directe, toutes les communications des clients internes vers
Internet passent par le proxy qui joue le rôle de serveur final pour les
clients. Le serveur proxy décide ensuite de la légalité de la requête en se
basant sur une liste de règles propres au service en question. En retour,
lorsqu’une réponse à une requête parvient au réseau, le firewall se
comporte comme s’il en était le destinataire final : il devient alors le client
proxy. Il achemine ensuite la réponse au client réel.
Les firewalls applicatifs offrent la possibilité d’effectuer une analyse

minutieuse du trafic. Ils permettent entre autres, de filtrer les URLs
(Uniform Resource Locator), de masquer les ressources internes du
réseau à l’aide du NAT (Network Address Translation), de maintenir l’état
et l’historique de la connexion, et offrent des informations de
journalisation d’événements très détaillées. Par ailleurs, on distingue

d’autres types de filtrage en fonction du protocole utilisé tels que :
 le filtrage de commande ;
 le filtrage MIME (Multipurpose Internet Mail Extension);
 le filtrage FTP (File Transfer Protocol).
La première limitation de ces firewalls, réside dans le fait qu'ils

doivent impérativement connaître toutes les règles des protocoles qu'ils
doivent filtrer. Il faut en effet, que le module permettant le filtrage de ces
protocoles soit disponible. Si une nouvelle application est créée, il faudrait
créer ou mettre à jour le module correspondant au niveau du pare-feu
(Schmidt, 2009).
De nombreux firewalls de ce type sont disponibles sur le marché

comme Raptor de Axent, Gauntlet de NAI, racheté par Secure
Computing, Sidewinder de Secure Computing et M-Wall de Matranet, la
gamme ASA 5500 de CISCO, pour ne citer que ceux-là.
3.4.4 Firewall réseau applicatif
Cette catégorie de pare-feu est en réalité la combinaison des trois

types de firewalls abordés précédemment : on parle de firewall « full
inspection ». Ils contrôlent les paquets au niveau des couches réseau,
session et application. Contrairement aux firewalls applicatifs, ils
autorisent les connexions directes entre les clients et les réseaux
externes, et utilisent des algorithmes qui réduisent les ressources
nécessaires au filtrage d’application.
Ils contrôlent d’abord minutieusement les paquets pour supprimer

et consigner les mauvais paquets. Le pare-feu ouvre et examine ensuite
les paquets de protocole de couche d’application. Ces paquets sont
vérifiés pour garantir la conformité aux commandes valables. Une fois de
plus, les mauvais paquets sont éliminés et consignés. Si les paquets sont
basés sur les protocoles HTTP, la technologie de filtrage de contenu

compare l’adresse IP source avec une liste de sites web interdits. Le
contenu interdit est supprimé et consigné. Si les paquets sont basés sur
les protocoles HTTP, FTP et SMTP (Simple Mail Transfer Protocol), les
fichiers et les pièces jointes sont envoyés à l’analyseur antivirus de
référence. Celui-ci bloque également de manière active les courriers
électroniques selon l’objet, le texte, le nom de fichier, le type de la pièce
jointe et la taille du message. Si un virus est détecté, le fichier est réparé
ou supprimé. Tous les virus sont consignés et un message est ajouté aux
courriers électroniques, indiquant qu’un virus a été détecté et que la pièce
jointe a été supprimée. Si tous ces contrôles sont passés avec succès, le
boîtier autorise le paquet à entrer ou quitter le réseau. Cette combinaison
unique de technologies de sécurité permet de bloquer les virus, les
attaques malveillantes et les menaces combinées au niveau du réseau.
Ce mécanisme d’inspection de paquets se fait à travers des outils de
filtrage dont une liste non exhaustive est :
- une liste noire ;
- une interface basée sur le filtrage de paquets ;
- validation des datagrammes IP ;
- inspection dynamique d’application.
Dans le tableau II, nous avons un récapitulatif des différentes

catégories de firewalls abordés, avec leurs atouts et faiblesses.
Tableau II : Tableau comparatif des types de firewalls
Catégories Atouts Faiblesses
-N’agit qu’aux niveaux 3 et 4 du modèle OSI.

-Nécessite peu de ressources CPU
-Certains protocoles sont particulièrement délicats à gérer
Firewall -Mise en œuvre aisée à l’aide de règles simples comme FTP ou TCP
stateless
-Performant si règles limitées et leur -Ne prend pas en compte l’authentification des utilisateurs
enchaînement optimisé
-Ne prend pas en compte les états des connexions
-Complexe à configurer (nombre important d’options)
-Dynamique : prend en compte les états des -Authentification limitée à l’adresse IP
Firewall sessions -Non prise en compte des protocoles supérieurs à la couche

stateful -Gestion de la translation d’adresses (NAT) et de transport (Telnet, FTP, ...)
ports (PAT, Port Address Translation) -Demande plus de ressources processeur et de mémoire.
-Ne peut restreindre l’accès que pour le protocole TCP
-Service d’authentification plus puissant que

l’adresse IP
-Cache le plan d’adressage interne -Nécessite d’énormes ressources et des temps de traitement
-Journalisation très détaillée des événements assez longs
Firewall
-N’autorise pas les communications directes -Mise en œuvre assez complexe
applicatif
-Fournit des informations sur les états des -Chaque protocole doit être associé à un module du proxy
communications au risque d’être rejeté
-Possibilité de traiter les informations d’un paquet

et de les modifier
-Très onéreux
Firewall -Fournit le plus haut niveau de sécurité -Nécessite beaucoup de ressources pour être configuré, les
réseau règles étant assez compliquées à mettre en œuvre
applicatif -Offre de très bonnes performances
-Requiert des compétences précises de la part de
l’administrateur
3.5. Architecture des firewalls
Comme nous l’avons décrit précédemment, il existe une multitude

de firewalls accomplissant diverses fonctionnalités plus ou moins
évoluées. Toutefois, il est important de mettre l’accent sur le fait que la
performance d’un firewall dépend non seulement de ses fonctionnalités,
mais aussi de l’environnement dans lequel il se situe. A cet effet, il existe
plusieurs manières d’organisation de réseau, afin d’obtenir un niveau de
sécurité optimal.
3.5.1 Firewall avec routeur de filtrage
C’est l’architecture la plus simple et la plus courante, où un seul

firewall assure la séparation de deux réseaux : le réseau interne et
Internet. En réalité, le firewall est obtenu en configurant des ACL sur un
routeur pour assurer la fonctionnalité de filtrage de paquets. Dans cette
configuration, une seule politique de sécurité couvrant toutes les
machines du réseau est appliquée au firewall. Cela n’est possible que si
toutes les machines assurent la même fonction (en termes de services
fournis), tout comme les machines des utilisateurs appartenant au réseau
interne. Si le réseau est essentiellement composé d’ordinateurs par
exemple, alors le firewall appliquera une seule politique de sécurité à tous
les ordinateurs. La figure 6 présente un exemple d’architecture de type
simple filtre où le réseau interne n’est composé que d’ordinateurs
directement reliés au routeur, lequel est connecté à Internet.
Firewall
Internet
Figure 6 : Architecture de type filtre simple
Certains réseaux par contre, comportent en plus des ordinateurs,

d’autres types de machines tels que les serveurs. Ces derniers ont la
possibilité d’être placés au cœur du réseau, dans le même
environnement que les clients internes. Les serveurs ne fournissant pas
les mêmes services que les machines internes, une seule politique de
sécurité ne peut donc plus être appliquée. Il est préférable de définir
différentes politiques pour différents types d’ordinateurs. Le choix
d’installer les serveurs dans le réseau reste toutefois très risqué. Si la
barrière que constitue le routeur est franchie, et que lesdits serveurs sont
corrompus, il n’y aura aucun moyen d’empêcher, ne serait-ce que
temporairement, la propagation de l’attaque aux autres machines
voisines. Cela s’explique par le fait que la plupart des attaques se
déroulent en plusieurs étapes. Autrement dit, la première cible atteinte
n’est pas toujours la cible ou l’objectif réel de l’attaque. La plupart d’entre
elles exploite en général une machine pour en compromettre d’autres. Il
est donc préférable, lorsqu’on est dans un même réseau, d’isoler les
machines, des services (Fulp, 2009).
3.5.2 Architecture en DMZ
La Zone Démilitarisée (DMZ : DeMilitarized Zone) est un réseau à

part avec des caractéristiques spécifiques : c’est un sous-réseau situé
entre le réseau local et le réseau externe, qui est accessible de l’intérieur

du réseau, comme de l’extérieur. Il abrite certains serveurs tels que le
serveur web (HTTP), le serveur de messagerie (SMTP), le serveur DNS
(Domain Name Service), le serveur de fichiers (FTP) dont l’intérêt est
d’être accessibles de l’extérieur. Les connexions à la DMZ sont
autorisées de n’importe où, tandis que les connexions à partir de la DMZ
ne sont autorisées que vers l’extérieur. La DMZ limite l’accès des
utilisateurs externes aux ressources du réseau local. Les machines
placées dans la DMZ sont appelées les bastions.
Ce type d’organisation apporte une solution de sécurité à

l’architecture précédente. Ainsi les serveurs peuvent désormais rester
dans un sous-réseau différent de celui des machines locales. Pour ce
faire, le serveur (serveur web par exemple) est intercalé entre le pare-feu
et Internet comme illustré à la figure 7.
Serveur web
Firewall
Internet
Réseau interne
Figure 7 : Architecture de type filtre simple avec un serveur
Cette organisation du firewall reste néanmoins peu sécurisée, car

le serveur reste sans défense. A défaut de le laisser sans aucune barrière
de défense, on peut relier le bastion de la DMZ à un firewall. Ainsi, en
utilisant un firewall à trois interfaces comme l’indique la figure 8, on peut
mettre en place une architecture en DMZ sécurisée. Les utilisateurs
externes n’ont donc plus la possibilité d’accéder directement aux
ressources du réseau interne. Pour les firewalls ne disposant que de
deux interfaces, cette architecture s’avère plus efficace parce qu’elle offre
différents degrés de protection grâce à la combinaison de deux firewalls.
En effet, le premier firewall est placé entre Internet et la DMZ qui abrite
le(s) serveur(s) ; tandis que le second connecte la DMZ au réseau local
(figure 9). Cette combinaison est établie de façon à ce que le firewall en
aval soit moins restrictif que celui en amont. Ainsi, grâce aux
fonctionnalités de NAT et d’analyse de contenu utilisées, on peut
appliquer différentes politiques de sécurité sur chaque firewall ; ce qui
donne différents niveaux de protection en fonction du périmètre dans
lequel on se situe. Il est recommandé de préférence d’utiliser la stratégie
de défense en profondeur qui consiste à mettre en place deux firewalls
provenant de différents fournisseurs (Vacca, 2009). Cela réduit en effet
les risques que les deux composants aient été conçus avec les mêmes
vulnérabilités, parce que provenant d’un même constructeur. Une
mauvaise configuration ou une compromission qui rend un firewall non
opérationnel n’entraînera donc pas une défaillance en cascade sur le
réseau. Une autre variante de cette architecture consiste à utiliser en lieu
et place du premier firewall, un routeur filtrant (figure 10).
Serveur FTP Serveur web Serveur mail
DMZ
Internet
Firewall
Réseau interne
Figure 8 : Architecture en DMZ avec un firewall à trois interfaces
DMZ
Internet
Firewall Firewall
en amont en aval ou
ou interne externe et
et plus moins
restrictif restrictif
Réseau interne
Figure 9 : Architecture en DMZ avec des firewalls à deux interfaces
Quelle que soit l’architecture utilisée, la technique de protection par

DMZ répond à la règle d’or du moindre privilège. Ce principe établit que
la DMZ ne doit laisser aucune zone initialiser des communications avec
une zone dont le niveau de sécurité est supérieur au sien.
DMZ
Internet
Routeur
Firewall filtrant
Réseau interne
Figure 10 : Architecture en DMZ avec un routeur filtrant à la place du

firewall externe
3.5.3 Architecture de type proxy
Cette architecture comprend un routeur externe, une machine

bastion, un routeur interne puis le réseau local (figure 11). La machine
bastion est en règle générale un proxy (HTTP, ou FTP, etc.); tandis que
les routeurs ne font que du simple filtrage de paquets.
Firewall Proxy
Internet
Routeur Routeur
filtrant filtrant
Réseau interne
Figure 11 : Architecture de type proxy
3.5.4 Architecture mixte en proxy et DMZ
C’est une variante de l’architecture précédente en ce sens que si le

réseau dispose de serveurs, ils peuvent être disposés dans une DMZ
créant ainsi une nouvelle connexion au niveau du proxy (figure 12).
DMZ
Internet
Routeur Routeur
filtrant filtrant
Firewall Proxy
Réseau interne
Figure 12 : Architecture mixte en proxy et DMZ
Il existe plusieurs possibilités de pouvoir disposer les firewalls dans

un réseau de façon à obtenir un niveau de sécurité optimal.
3.6. Atouts et faiblesses des firewalls
Les firewalls ont de nombreux atouts à savoir :
 ils peuvent bloquer ou autoriser un trafic en se basant sur

l’adresse source et/ou destination, ou en se basant sur le
contenu du paquet. Cette fonction s’avère utile lors de la
réception de messages contenant des virus dissimulés sous
forme de fichiers joints. Le firewall rejette alors dans ce cas
de figure le trafic ou supprime le fichier joint et achemine le
message vers le(s) destinataire(s) ;
 ils consignent et enregistrent tous les trafics rejetés. La
création de registres permet d’avoir une idée précise sur
l’état du firewall, et de déterminer un fonctionnement anormal
à travers l’analyse des informations enregistrées. Les
rapports établis peuvent en effet s’avérer très efficaces
lorsque l’administrateur voudra comprendre comment un
intrus a pu accéder aux ressources du réseau ;
 ils peuvent dissimuler le plan d’adressage interne d’un
réseau. C’est un moyen supplémentaire utilisé pour
empêcher un intrus d’accéder aux machines du réseau par le
biais de leurs adresses IP. Ce système de traduction
d’adresses, plus connu sous le nom de NAT est apparu en
1994 dans la RFC (Request For Comments) 1631
(remplacée aujourd’hui par la RFC 3022). Il se révèle utile
pour palier au problème de pénurie d’adresses IP publiques.
Son principe repose sur l’association soit de N adresses
privées à N adresses publiques ; soit de N adresses privées
à une seule adresse publique.
Toutefois, les firewalls ne sont pas la panacée en matière de

sécurité informatique. Un pare-feu :
 ne peut bloquer les trafics qui ne passent pas lui. Un firewall

est conçu pour filtrer les paquets le traversant ;
 ne peut empêcher la propagation des codes malicieux. Un
virus introduit dans le réseau par un utilisateur mal
intentionné ou maladroit, se répandra sans que le firewall ne
puisse protéger les machines restantes ;
 ne peut protéger contre le vol de données ou le piratage
d’informations gardées secrètes. Il revient à une entreprise
de protéger efficacement ses données du vol et de la
falsification. Un firewall ne dispose absolument d’aucun
moyen pour protéger les données sensibles. Il revient à
l’administrateur de restreindre cet accès et d’établir une
politique d’authentification des utilisateurs ;
 ne peut surveiller les activités suspectes sur le réseau.
N’étant pas conçu pour remplir cette fonction, il revient le
plus souvent aux IDS de superviser et signaler les activités
douteuses sur le réseau. Toutefois, les rapports établis par le
firewall peuvent servir d’indices à la détection d’activités
ambigües.
3.7. Anomalies liées à la configuration des firewalls
Une fois la politique de sécurité spécifiée par l’administrateur ou le

responsable de la sécurité, cette dernière doit être mise en vigueur au
cœur du SI à protéger, et plus particulièrement au niveau des
équipements de sécurité déployés. L’application effective de la politique
de sécurité au sein d’un firewall à travers les règles de filtrage est une
tâche délicate. En effet, ces règles doivent être définies de façon claire et
concise. Cela implique qu’il y ait de la logique et de la cohérence entre
toutes les règles au niveau du firewall. En effet, plus le nombre de règles
augmente, plus il est difficile de garantir la logique et la cohérence entre
l’ensemble des règles définies au niveau du pare-feu. Par ailleurs, la

probabilité d’avoir des erreurs de configuration est aussi fonction du
niveau de compétences du responsable en charge de la sécurité, mais
également de la nature de l’architecture où est déployé le firewall. Ainsi,
de nombreuses anomalies peuvent apparaître lors de la configuration des
firewalls. Elles sont généralement de deux ordres à savoir : les anomalies
intra-firewall et les anomalies inter-firewall. Pour mieux comprendre ces
types d’erreurs, il est nécessaire de modéliser les relations existant entre
les règles de filtrage.
3.7.1 Relations entre les règles de filtrage
La détermination d’anomalies entre des règles de filtrage repose

essentiellement sur les relations qui lient ces dernières. Une règle est
composée d’une part de plusieurs champs encore appelés paramètres
spécifiant les conditions telles que le protocole utilisé, les adresses
source et destination, les ports utilisés ; et d’autre part la cible qui diffère
selon la table qui est utilisée. Ainsi, la cible peut être une action de filtrage
selon qu’on utilise la table filter, une action de marquage du paquet s’il
s’agit de la table mangle, ou de la traduction d’adresse s’il s’agit de la
table nat. Nous ne nous intéresserons qu’à la table filter puisque nous
effectuons le filtrage des paquets. Les relations entre deux règles sont
identifiées en comparant les champs correspondants de celles-ci. Soit
deux règles Rx et Ry avec des conditions telles que :
Rx : Rx[i] action
Ry : Ry[i] action
où i {prot, @_src, @_dst, port_src, port_dst, …} et action {deny,

accept} ; prot, @_src, @_dst, port_src, port_dst, … représentant
respectivement le protocole utilisé, l’adresse source, l’adresse
destination, le port source et le port destination, et éventuellement
d’autres paramètres additionnels. Nous définissons ainsi toutes les

relations pouvant exister entre deux règles de filtrage.
Relation 1 : deux règles Rx et Ry sont exactement égales si

chaque paramètre de Rx est égal au paramètre correspondant de Ry. De
façon formelle, Rx RE Ry (Rx et Ry sont liées par une relation d’égalité) si
et seulement si :
i : Rx[i] = Ry[i] où i {prot, @_src, @_dst, port_src, port_dst, …}.
Relation 2 : une règle Rx est incluse dans une autre Ry, si d’une
part aucune relation d’égalité n’existe entre les deux règles, et si d’autre
part chaque paramètre de R x est un sous-ensemble ou est égal au
paramètre correspondant Ry. De façon formelle, Rx RI Ry (Rx et Ry sont
liées par une relation d’inclusion) si et seulement si :
i : Rx[i] Ry[i] et j / Rx[j] Ry[j] où i, j {prot, @_src, @_dst, port_src,

port_dst, …}.
Relation 3 : deux règles Rx et Ry sont totalement disjointes si

chaque paramètre de Rx n’est ni un sous-ensemble, ni une extension, ni
égal au paramètre correspondant de R y. De façon formelle, Rx RD Ry (R x
est différente de Ry) si et seulement si :
i : Rx[i] Ry[i] où ~ { } et i {prot, @_src, @_dst, port_src,

port_dst, …}.
Relation 4 : deux règles Rx et Ry sont partiellement disjointes s’il

existe d’une part au moins un paramètre de R x qui soit un sous-ensemble
ou une extension ou égal au paramètre correspondant de Ry ; et d’autre
part au moins un paramètre de R x qui ne soit ni une extension, ni un
sous-ensemble, ni égal au paramètre correspondant de R y.
Formellement, Rx RDP Ry (Rx et Ry sont liées par une relation de différence
partielle) si et seulement si :
i, j / Rx[i] ~ Ry[i] et Rx[j] Ry[j] et où ~ { } et i, j {prot, @_src,

@_dst, port_src, port_dst, …}.
Relation 5 : deux règles Rx et Ry sont corrélées ou en corrélation si

certains paramètres de Rx sont des sous-ensembles ou sont égaux aux
paramètres correspondants de R y d’une part ; et le reste des paramètres
de Rx sont des extensions des paramètres correspondants de R y d’autre
part. Formellement, Rx RC Ry (Rx et Ry sont liées par une relation de
corrélation) si et seulement si :
i : Rx[i] ~ Ry[i] & i, j / Rx[i] Ry[i] et Rx[j] Ry[j]
où ~ { } et i, j {prot, @_src, @_dst, port_src, port_dst, …}.
La figure 13 illustre ces différentes relations.
Rx Ry Rx Ry
Rx RPD Ry Rx RD Ry Rx Ry
Ry Rx RE Ry
Rx Ry Rx Ry
Rx
Rx RI Ry Rx RC Ry
Figure 13 : Différents types de relations existant entre des règles de

filtrage
3.7.2 Anomalies intra-firewall
Une anomalie est dite intra-firewall si elle survient au niveau d’un

même et unique composant. Elle se définit comme étant, soit l’existence
de deux ou plusieurs règles de filtrage qui s’appliquent à un même
paquet, soit l’existence d’une règle qui ne s’applique à aucun paquet
traversant le firewall.
La figure 14 représente l’architecture d’un réseau avec deux sous-

réseaux internes D1 et D2. Le firewall fw0, dont les règles sont décrites au
tableau III, relie ces deux zones à Internet.
Internet
Fw0
D1 D2
140.192.37.0 161.120.33.0
Figure 14 : Architecture réseau présentant les anomalies intra-firewall
Tableau III : Règles de filtrage du firewall fw0
N° Protocole Adresse Port Adresses Port Action

source source destination destination
1 tcp 140.192.37.20 any *.*.*.* 80 Deny
2 tcp 140.192.37.* any *.*.*.* 80 Accept
3 tcp *.*.*.* any 161.120.33.40 80 Accept
4 tcp 140.192.37.* any 161.120.33.40 80 Deny
5 tcp 140.192.37.30 any *.*.*.* 21 Deny
6 tcp 140.192.37.* any *.*.*.* 21 Accept
7 tcp 140.192.37.* any 161.120.33.40 21 Accept
8 tcp *.*.*.* any *.*.*.* any Deny
9 udp 140.192.37.* any 161.120.33.40 53 Accept
10 udp *.*.*.* any 161.120.33.40 53 Accept
11 udp 140.192.38.* any 161.120.35.* any Accept
12 udp *.*.*.* any *.*.*.* any Deny
Il existe plusieurs anomalies intra-firewall énumérées comme suit :
Anomalie de masquage : une règle Ri est masquée par une

règle Rj de priorité supérieure, lorsque Rj s’applique déjà à un paquet de
telle sorte que Ri ne puisse jamais être évaluée. De plus, R i et Rj
effectuent différentes actions sur les paquets. Ce type d’anomalie est
critique du fait qu’elle rend inapplicable une règle de sécurité. Ainsi, un
trafic à l’origine bloqué pourra être autorisé et vice-versa. Formellement,
Ry est masquée par Rx si :
Rx[ordre] < Ry[ordre]; Rx RE Ry ; Rx[action] Ry[action]
ou
Rx[ordre] < Ry[ordre]; Ry RI Rx ; Rx[action] Ry[action]
La règle de filtrage n°4 est masquée par la règle 3 (tableau III).
Anomalie de redondance : une règle Ri est dite redondante, si

elle effectue sur un paquet, la même action qu’une règle de priorité
supérieure Rj ; de telle sorte que sa suppression n’affecte en rien la
politique de sécurité au niveau du firewall. En général, la redondance est
considérée comme une erreur banale de configuration qu’on peut ignorer.
Toutefois, il est préférable de la signaler à l’administrateur puisqu’elle
augmente inutilement la taille de la table des règles de filtrage d’une part,
et qu’elle augmente le temps nécessaire au processus de filtrage d’autre
part. Une règle Ry est redondante par rapport à une autre Rx si :
Rx[ordre] < Ry[ordre]; Rx RE Ry ; Rx[action] = Ry[action]
ou
Rx[ordre] < Ry[ordre]; Ry RI Rx ; Rx[action] = Ry[action]
Le tableau III montre que les règles 6 et 7 d’une part, et les règles 9
et 10 d’autre part sont redondantes.
Anomalie de pertinence : une règle de filtrage est non-pertinente

si une des conditions ci-dessous est remplie :
 les adresses source et destination se retrouvent dans la même

zone ;
 le firewall ne se trouve pas sur le chemin reliant les zones
indiquées par les adresses source et destination.
La règle 11 du firewall fw0 est une règle non-pertinente (tableau III).
Anomalie de généralisation : une règle Ri est une généralisation

d’une seconde Rj, si Ri s’applique à tous les paquets de Rj, mais pas
l’inverse. Les actions exécutées par les deux règles en conflit sont de
plus différentes. De façon formelle, Ry est une généralisation de Rx si :
Rx[ordre] < Ry[ordre]; Rx RI Ry ; Rx[action] Ry[action]
La règle 2 est une généralisation de la règle 1 (tableau III).
Anomalie de corrélation : deux règles Ri et Rj sont en corrélation

si elles effectuent différentes actions et si Ri s’applique à certains paquets
auxquels s’applique Rj et vice-versa. Formellement Rx et Ry sont
corrélées si :
Rx RC Ry ; Rx[action] Ry[action]
La règle 1 du tableau III est en corrélation avec la règle 3.
3.7.3 Anomalie inter-firewall
Une anomalie est dite inter-firewall si elle met en jeu deux ou

plusieurs firewalls qui effectuent différentes actions de filtrage sur un
même trafic.
Le réseau de la figure 15 représente une architecture distribuée où

nous avons trois firewalls qui interconnectent quatre sous-réseaux (D1,
D2, D3 et D4) à Internet. Les règles de filtrage définies sur chacun de ces
firewalls sont respectivement illustrées par les tableaux IV, V et VI.
Internet
Fw0
Fw1 Fw2
D1 D2 D3 D4
140.192.22.0 140.192.37.0 161.120.24.0 161.120.33.0
Figure 15 : Architecture réseau distribuée présentant les anomalies inter-

firewall
Tableau IV : Règles de filtrage du firewall fw0

1 tcp 161.120.*.* any *.*.*.* 80 Accept
2 tcp 140.192.*.* any *.*.*.* 25 Accept
3 tcp *.*.*.* any 140.192.*.* 25 Accept
4 tcp 140.192.*.* any 161.120.*.* 80 Deny
5 tcp 161.120.33.* any 140.192.37.1 23 Deny
6 tcp 161.120.*.* any 140.192.*.* 22 Deny
7 tcp 161.120.*.* any 140.192.*.* any Accept
8 tcp 140.192.*.* any 161.120.*.* any Accept
9 tcp *.*.*.* any *.*.*.* any Deny
Tableau V : Règles de filtrage du firewall fw1
Protocole Adresse Port Adresses Port Action

N° source source destination destination
1 tcp 161.120.*.* any 140.192.*.* 80 Accept
2 tcp 140.192.*.* any 161.120.*.* 80 Accept
3 tcp 161.120.*.* any 140.192.22.5 21 Accept
4 tcp 161.120.33.* any 140.192.37.* 23 Deny
5 tcp 161.120.*.* any 140.192.*.* 23 Accept
6 tcp 161.120.24.* any 140.192.37.3 25 Deny
7 tcp 161.120.24.* any 140.192.*.* 25 Accept
8 tcp *.*.*.* any *.*.*.* any Deny
Tableau VI : Règles de filtrage du firewall fw2

1 tcp 161.120.*.* any 140.192.*.* 80 Accept
2 tcp 161.120.*.* any 140.192.22.5 21 Deny
3 tcp 161.120.*.* any 140.192.*.* 21 Accept
4 tcp 140.192.*.* any 161.120.33.* 23 Accept
5 tcp 161.120.33.* any 140.192.*.* 23 Accept
6 tcp 161.120.24.* any 140.192.37.3 25 Deny
7 tcp 161.120.24.* any 140.192.22.5 25 Deny
8 tcp 161.120.*.* any 140.192.37.* 25 Accept
9 tcp *.*.*.* any *.*.*.* any Deny
Diverses erreurs sont classées au sein de cette catégorie

d’anomalies. Il s’agit notamment de :
Anomalie de masquage : ce type d’anomalie survient si un firewall

proche de la source (en amont) bloque un trafic accepté par un firewall
proche de la destination (en aval). De façon formelle, une règle Rd du
firewall en aval est masquée par une règle Ru du firewall en amont si :
Rd RE Ru , Ru[action] = deny, Rd[action] = accept
ou
Rd RI Ru , Ru[action] = deny, Rd[action] = accept
ou
Ru RI Rd , Ru[action] = deny, Rd[action] = accept
D’après notre architecture, la règle 3 de fw1 est masquée par la

règle 2 de fw2 (tableaux V et VI).
Anomalie de redondance : si le pare-feu en aval rejette un trafic

déjà bloqué par celui en amont, alors il y a redondance entre les règles
concernées au niveau des deux pare-feu. Cette anomalie se traduit par :
Rd RE Ru , Ru[action] = deny, Rd[action] = deny
ou
Rd RI Ru , Ru[action] = deny, Rd[action] = deny
Rd et Ru étant respectivement des règles du firewall en aval et du firewall

en amont.
Les règles 6 de fw2 et 6 de fw1 d’une part, et les règles 9 de fw2 et 6

de fw0 d’autre part sont redondantes.
Anomalie de connexion : dans ce cas de figure, le firewall en

amont autorise un trafic pourtant bloqué par le firewall en aval.
Rd RE Ru , Ru[action] = accept, Rd[action] = deny
ou
Rd RI Ru , Ru[action] = accept, Rd[action] = deny
ou
Ru RI Rd , Ru[action] = accept, Rd[action] = deny
Rd et Ru étant respectivement des règles du firewall en aval et du firewall

en amont.
La règle 2 de fw1 et la règle 4 de fw0 décrivent une anomalie de

connexion, tout comme la règle 2 de fw1 et la règle 9 de fw2.
Le choix d’un pare-feu n’est donc pas simple si l’on n’a pas identifié
avec soin les besoins de sécurité de l’entreprise. La définition d’une
politique de sécurité vient toujours en premier, et l’analyse des produits
répondant aux besoins exprimés en second. Par ailleurs, il faut savoir
qu’un pare-feu, parmi ses fonctionnalités, peut :
 être un guichet de sécurité: un point central de contrôle de
sécurité plutôt que de multiples contrôles dans différents
logiciels clients ou serveurs ;
 appliquer une politique de contrôle d’accès ;
 enregistrer le trafic: construire des journaux de sécurité ;
 appliquer une défense en profondeur (multiples pare-feu).
Un firewall reste cependant limité. En effet, il ne peut :
 protéger contre les utilisateurs internes (selon leurs droits) ;
 protéger un réseau d’un trafic qui ne passe pas par lui ;
 protéger contre les virus ;
 protéger contre des menaces imprévues (hors politique) ;
 être configuré tout seul.
Partie 2
PARTIE 2
APPROCHE
METHODOLOGIQUE
Chapitre 4 : Approche d’analyse des firewalls à états
CHAPITRE 4
APPROCHE D’ANALYSE DES FIREWALLS A

ETATS
Dans ce chapitre, nous exposons la méthodologie suivie pour

étudier les firewalls. De prime abord, nous expliquons le fonctionnement
d’Iptables. Ensuite, nous retenons une approche pour étudier les
configurations des règles de filtrage au niveau des firewalls à états. Nous
choisissons enfin les outils qui nous ont permis de mener à bien ce projet.
4.1. Présentation du cadre de stage
Notre stage a été effectué au sein de Bénin Télécoms S.A qui a

bien voulu nous accueillir dans ses locaux. L’annexe A présente de façon
succincte notre environnement de stage.
4.2. Modèle d’étude des firewalls : cas d’Iptables
Il est important de comprendre comment fonctionnent les firewalls à

états. Les travaux de Gouda et Liu (2005) viennent à point nommé, dans
un domaine encore peu exploré, fournir les informations permettant de
mieux cerner le fonctionnement des firewalls à états. Ils proposent en
effet des propriétés, de même qu’un modèle d’étude pour ces pare-feu.
Bien que ces derniers soient une évolution des pare-feu sans état,
leurs comportements ne sont cependant pas différents. En effet, leurs
principes de fonctionnement sont les mêmes, et reposent essentiellement
sur la façon dont les paquets sont filtrés. Lorsqu’un pare-feu décide du
sort d’un paquet en n’examinant que ce dernier, alors il est dit sans état
ou ‘’stateless’’. Si par contre, la décision de filtrage dépend non
seulement de l’examen du paquet en cours, mais aussi de l’examen de
paquets précédemment autorisés, alors ce pare-feu est dit à états ou
‘’stateful’’. Il existe plusieurs firewalls qui intègrent la fonctionnalité de
suivi d’état des connexions dont Iptables.
4.1.1 Description
Sous Linux, le traitement des paquets est effectué au niveau noyau

par le sous-système réseau. On ajoute en réalité une fonctionnalité au
niveau noyau à ce sous-système avec une interface utilisateur permettant
de paramétrer le filtrage désiré. A l’origine, le plus populaire des pare-feu
sur Linux était ipchains, qui était disponible sur la version 2.3 du noyau.
Très vite, il a laissé place à Netfilter qui a vu le jour sous la version 2.4 du
noyau Linux. Ce dernier apportait en effet certaines améliorations telles

que :
 une meilleure intégration avec le noyau Linux conçue pour

améliorer la rapidité et la fiabilité de traitement ;
 l’inspection par état : cela signifie que le pare-feu garde la

trace de chaque connexion qui le traverse ;
 le filtrage de paquets sur la base des adresses MAC et des

valeurs de champs (flags) dans l’en-tête TCP ;
 une meilleure traduction des adresses réseau (NAT) ;
 une fonctionnalité de limitation de flux.
La fonctionnalité de filtrage est donc implémentée par Netfilter au

niveau du noyau qui se charge d’intercepter et de manipuler les paquets
avant et après le routage ; mais l’interface utilisateur en lignes de
commande pour configurer Netfilter est Iptables.
Tous les paquets inspectés par Netfilter passent à travers des

tables prédéfinies. Chacune d’elles est dédiée à un type particulier
d’activité et est contrôlée par une chaîne associée, qui a pour rôle de
transformer ou de filtrer le paquet. Il existe trois tables à savoir :
 la table mangle : son rôle est de marquer les paquets pour

une utilisation ultérieure. Elle permet de changer certains
champs d’en-tête d’un paquet. Il s’agit souvent des champs
TOS (Type Of Service) et TTL. Les opérations de filtrage et
de traductions d’adresses ne fonctionnent pas dans cette
table.
 la table nat : elle permet d’effectuer la traduction d’adresses.

Elle ne sert donc qu’à traduire le champ de l’adresse source
d’un paquet ou celui de l’adresse destination.
 la table filter : elle s’utilise essentiellement pour le filtrage de

paquets sur la base d’adresses, de numéro de ports,
d’adresses MAC, etc. C’est la table par défaut qui est définie
lorsqu’aucune table n’a été spécifiée.
Chacune de ces tables est composée de chaînes qui renferment

les règles destinées soit au marquage des paquets, soit au filtrage des
paquets. Il existe cinq chaînes prédéfinies indiquées comme suit :
 chaîne FORWARD : elle filtre les paquets à destination

d’équipements réseau situés derrière le pare-feu. Ces
paquets doivent donc traverser le pare-feu ;
 chaîne INPUT : elle filtre les paquets destinés au pare-feu ;
 chaîne OUTPUT : elle filtre les paquets qui ont pour origine
le firewall ;
 chaîne PREROUTING (pré-routage) : elle est utilisée pour

faire de la traduction d’adresses de destination (DNAT :
Destination Network Address Translation). Elle permet de
traiter les paquets avant leur routage ;
 chaîne POSTROUTING (post-routage) : elle traduit les

paquets quand l’adresse source doit être changée (SNAT :
Source Network Address Translation).
La figure 16 illustre le diagramme de traitement des paquets

dans Iptables. Dans cette figure, un paquet TCP arrive sur l’interface
réseau du pare-feu en provenance du réseau A pour créer une
connexion. Le paquet est d’abord examiné par les règles de la chaîne
PREROUTING de la table mangle. Il est ensuite inspecté par les règles
de la chaîne PREROUTING de la table nat pour voir si l’adresse de
destination du paquet nécessite d’être traduite (DNAT). Il est ensuite
routé. Si le paquet est destiné à un autre réseau (réseau B sur le

schéma), il est alors analysé par les règles de la chaîne FORWARD de la
table filter, et, si nécessaire, l’adresse IP source est traduite (SNAT) dans
la chaîne POSTROUTING avant d’arriver dans le réseau B. Lorsque le
service de destination décide de répondre, le paquet subit la même
séquence de traitement. Les chaînes FORWARD et POSTROUTING
peuvent être configurées pour mettre en œuvre des fonctionnalités de
qualité de service dans la table mangle. Si le paquet est destiné au pare-
feu lui-même, il passe alors à travers la chaîne INPUT de la table
mangle, si elle est configurée, avant d’être filtrée par les règles de la
chaîne INPUT de la table filter. Si le paquet passe avec succès ces tests,
il est alors traité par l’application concernée.
A cette étape, le pare-feu doit émettre une réponse. Cette réponse

est routée et inspectée par les règles de la chaîne OUTPUT de la table
mangle. Ensuite, les règles de la chaîne OUTPUT de la table nat
déterminent si un SNAT est requis et les règles de la chaîne OUTPUT de
la table filter sont ensuite appelées pour pouvoir bloquer les paquets non
autorisés. Enfin, avant que le paquet ne quitte l’interface du pare-feu, il
traverse la chaîne POSTROUTING des tables mangle et nat.
Réseau A
Entrée du paquet
Table mangle
Chaîne PREROUTING
Table nat
Chaîne PREROUTING
Routage
La donnée est-elle à
destination du pare-feu?
Oui Non
Table mangle Table mangle

Chaîne INPUT Chaîne FORWARD
Table filter Table nat

Chaîne INPUT Chaîne FORWARD
Traitement local de la donnée et Table mangle

réponse du pare-feu Chaîne POSTROUTING
Routage
Table nat
Table mangle Chaîne POSTROUTING
Chaîne OUTPUT
Table nat
Chaîne OUTPUT
Sortie du paquet
Table filter
Chaîne OUTPUT
Table mangle
Chaîne POSTROUTING
Réseau B
Table nat Sortie du paquet
Chaîne POSTROUTING
Figure 16 : Diagramme de traitement des paquets dans Iptables
4.1.2 Machine d’état
La machine d'état correspond à une partie spéciale à l'intérieur

d'Iptables. En fait, elle porte très mal son nom puisqu'il s'agit en réalité
d'une machine de traçage de connexion. Le traçage de connexion est
effectué afin que l'architecture de Netfilter puisse connaître l'état d'une
connexion spécifique. Dans Iptables, les paquets peuvent être reliés aux
connexions tracées dans quatre états différents, qui sont connus sous les
noms de NEW, ESTABLISHED, RELATED et INVALID. Avec la
correspondance --state, il est facile de contrôler qui, ou ce qui, est
autorisé à démarrer de nouvelles sessions.
L'intégralité du traçage de connexion est effectuée par une

structure particulière à l'intérieur du noyau appelée conntrack. La
structure conntrack peut soit être chargée comme un module, soit être
interne au noyau. La plupart du temps, on a besoin de fonctions
supplémentaires de traçage de connexion autres que celles proposées
par défaut dans le moteur conntrack. De ce fait, des parties spécifiques
de conntrack prennent en charge les protocoles TCP, UDP et ICMP. Ces
modules capturent des informations spécifiques et uniques sur les
paquets, afin de pouvoir tracer chaque flux de données. L'information
récupérée par conntrack lui permet de connaître l'état dans lequel se
trouve chaque flux. Par exemple, un flux UDP est, en général, identifié
uniquement par son adresse IP destination, son adresse IP source, son
port destination et son port source.
Le traçage de connexion est entièrement pris en charge dans la

chaîne PREROUTING, sauf pour les paquets générés en local, qui sont
pris en charge dans la chaîne OUTPUT. Ceci signifie qu'Iptables effectue
tous les calculs d'état dans la chaîne PREROUTING. Si on envoie le
premier paquet d'un flux, l'état est défini comme NEW dans la chaîne
OUTPUT, et quand on reçoit un paquet de réponse, l'état passe à
ESTABLISHED, et ainsi de suite. Si le premier paquet n'est pas envoyé

par nous-mêmes, l'état NEW est naturellement défini dans la chaîne
PREROUTING. Ainsi, tous les changements d'état et calculs sont réalisés
dans les chaînes PREROUTING et OUTPUT de la table nat.
4.3. Méthode d’analyse des firewalls
Pour s’assurer de la cohérence d’une politique de sécurité réseau,

il est important de pouvoir analyser les configurations des composants de
sécurité déployés. Ceci permet en effet de vérifier que les configurations
réalisées sont bien conformes aux exigences de la politique spécifiée.
Deux approches ou méthodes d’analyse permettent de pouvoir atteindre
cet objectif : l’approche descendante et celle ascendante.
4.2.1 Approche descendante
Cette approche permet, à partir de la spécification d’une politique

de sécurité, de générer la politique de contrôle d’accès dans un langage
de haut niveau, souvent en XML (eXtended Markup Language), par le
biais de modèles de contrôle d’accès. Une fois cette étape franchie, il faut
traduire la politique de contrôle d’accès générée en règles de sécurité au
sein des différents composants de sécurité. Cette méthode a donc
l’avantage de pouvoir spécifier dans un langage simple la politique de
sécurité réseau. La difficulté qui réside dans ce processus de translation
est qu’il doit absolument maîtriser tous les langages utilisés au niveau
des pare-feu, ce qui n’est pas toujours évident. Cette approche constitue
alors une méthode de déploiement automatique de la politique de
sécurité au sein des composants assurant la protection du réseau. Le
principal avantage d’une telle approche est l’assurance qu’elle apporte en
termes de conformité de la politique formelle ainsi définie et générée sous
forme de règles de filtrage. Il existe de nombreux modèles répondant à
cette méthode d’analyse, dont les plus connus sont RBAC (Role-Based
Access Control) (Preda et al., 2007), OrBAC (Organization Based Access

Control) (Cuppens et al., 2004).
4.2.2 Approche ascendante
Cette approche est en réalité une approche analytique, car elle

permet d’analyser les configurations existantes au niveau des
composants de sécurité (firewalls, IDS, IPS, etc). Elle permet de
déterminer les relations entre les règles de sécurité dans le but de
détecter d’éventuelles anomalies. Cette méthode met généralement en
œuvre des algorithmes permettant de réécrire les règles de sécurité en
éliminant les incohérences relevées. Ces algorithmes s’appuient pour la
plupart du temps sur la modélisation du réseau tout en faisant ressortir
les notions de zones, de composants, de route. L’approche ascendante
est donc propice à un environnement où une politique de sécurité existe
déjà, les composants sont configurés, et le besoin de vérifier la
cohérence des configurations se fait ressentir.
4.4. Outils de développement et de modélisation
Nous présentons ici tous les outils dont nous aurons besoin pour
mettre en place notre système, depuis la conception jusqu’à sa
réalisation. Le tableau VII récapitule les outils choisis pour la réalisation
du système.
Pour mettre en œuvre un environnement de firewall, nous

choisissons d’utiliser Iptables qui a la fonctionnalité de suivi de l’état des
connexions. En fonction des exigences de la politique de sécurité de
l’architecture réseau à mettre en place, les règles de filtrage sont écrites
en suivant rigoureusement les syntaxes définies dans Iptables. Ensuite,
pour analyser les configurations des composants déployés, nous
choisissons d’utiliser l’approche ascendante qui s’inscrit dans la logique
du système. De cette analyse, sortiront les algorithmes à mettre en
œuvre pour auditer les firewalls. Ils seront implémentés en Java où

l’utilisateur pourra y effectuer les opérations d’insertion et de modification
des règles de filtrage. Mais avant cette étape, nous devrons modéliser le
comportement du système grâce à UML (Unified Modeling Language) à
travers quelques exemples de diagrammes.
Tableau VII : Tableau récapitulatif des technologies à utiliser
Besoins Technologie choisie
Firewall Iptables
Approche d’analyse Approche ascendante
Modélisation du système UML
Réalisation des interfaces du Java

système
Pour mieux cerner le comportement des firewalls stateful, nous

avons utilisé Iptables comme firewall. Ensuite, nous avons présenté les
méthodes qui permettent d’analyser les configurations des firewalls, et
avons retenu comme méthode l’approche ascendante. A présent, nous
pouvons donc définir l’architecture réseau que nous aurons à utiliser.
Chapitre 5 : Architecture réseau
CHAPITRE 5
ARCHITECTURE RESEAU
Dans le chapitre précédent, nous avons présenté la modélisation et

la méthode d’analyse choisies pour étudier les configurations des
firewalls. Le modèle de firewall étant également fixé, il ne nous reste qu’à
l’implémenter dans un environnement réel. Nous présentons donc dans
ce chapitre, le réseau mis en place pour la circonstance. Il prend en
compte les services offerts, l’architecture et le plan d’adressage choisis,
l’étude des flux au sein du réseau et la configuration des équipements de
sécurité.
5.1. Services réseau disponibles
L’architecture que nous proposons reflète autant que possible

l’environnement réel d’une entreprise avec un minimum de services
disponibles. Ainsi, nous avons retenu une liste succincte des services
réseau accessibles dans notre système. Pour pouvoir distinguer ces
services de façon unique, nous choisissons d’implémenter chacun d’eux
sur une machine dédiée. Il s’agit entre autre des serveurs HTTP, FTP,
IMAP (Internet Message Access Protocol), LDAP (Lightweight Directory
Access Protocol), NFS (Network File System), SQL (Structure Query
Language), SMTP, DNS (Domain Name Service) et d’impression.
5.2. Architecture choisie
La liste des services spécifiée, nous pouvons présenter

l’architecture générale de notre réseau. Cette architecture est composée
de deux groupes de machines à savoir: les serveurs, et les postes clients
destinés aux utilisateurs. L’architecture que nous proposons à la figure
17, prend en compte certaines considérations que nous présentons en
détail.
5.2.1 Topologie du réseau
Notre modèle d’architecture met évidence quatre zones à savoir : le

réseau local, le réseau des serveurs internes, la DMZ et Internet. Les
zones concernées par notre réseau sont les trois premières
précédemment citées. Elles sont reliées entre elles par une liaison filaire
de type Ethernet. La paire torsadée utilisée pour réaliser le câblage est le
STP (Shielded Twisted Pair), parce qu’elle offre une meilleure résistance
aux bruits électriques et aux interférences externes.
Figure 17 : Modèle d’architecture proposée
Suivant le principe de « diviser pour mieux régner », notre système

est donc compartimenté en trois sous-réseaux distincts pour des raisons
de sécurité. En effet :
 l’absence de segmentation physique dans notre réseau

donne un accès illimité à la totalité de nos ressources
informatiques à d’éventuels pirates. Une fois les barrières de
sécurité franchies, ils pourront donc écouter l’ensemble des
communications, même dans les zones les plus sensibles ;
 le cloisonnement permet de regrouper les machines ayant
les fonctions similaires au sein d’un même sous-réseau.
Ainsi, les machines des utilisateurs appartiennent au réseau
local, tandis que les serveurs appartiennent à d’autres sous-
réseaux distincts ;
 la création de ces différents sous-réseaux permet d’effectuer
un contrôle d’accès suivant les rôles de chaque équipement,
grâce à des filtres qui seront déployés ;
 c’est un moyen de se prémunir de la propagation d’une
compromission. Cela évite effectivement que la corruption
d’un serveur web par exemple ait pour conséquence la
compromission complète du réseau.
Le réseau local est constitué des machines des utilisateurs

internes. Différents sous-réseaux peuvent y être créés, formant ainsi un
agrégat dont la topologie est définie par l’administrateur. Toutes ces
machines ont accès aux services disponibles dans la zone des serveurs
internes et la DMZ.
Certains serveurs sont considérés comme étant à vocation interne,

et ont été regroupés dans la zone des serveurs internes. Il s’agit des
serveurs NFS, SQL, LDAP, et d’impression. Ils ne doivent en effet pas
être directement accessibles depuis l’extérieur de notre réseau. Les
utilisateurs externes pourront toutefois y accéder via les serveurs de la
DMZ. Ces derniers quant à eux sont accessibles aussi bien de l’intérieur
que de l’extérieur du réseau. De ce fait, le risque qu’ils soient un jour
compromis est non-négligeable. C’est donc pour cette raison qu’ils sont
installés dans la DMZ afin de limiter les conséquences d’une telle

éventualité, et éviter une propagation vers l’ensemble du réseau. Les
machines dédiées aux différents serveurs fonctionnent sous le système
d’exploitation Linux.
Ces trois différentes zones sont reliées au moyen de

routeurs/firewalls qui réalisent le filtrage. Puisque nous gérons trois sous-
réseaux internes et Internet, on pourrait choisir de déployer un seul pare-
feu à quatre interfaces, chacune reliée à une zone du réseau. Quand bien
même ce choix a l’avantage de présenter une facilité d’administration et
un coût réduit, il n’offre cependant qu’une seule barrière de protection. Si
cette barrière venait à être franchie, la probabilité que tout le réseau soit
compromis, malgré le cloisonnement, serait grande. Nous optons donc
pour une architecture à double barrière, c’est-à-dire à deux pare-feu. Elle
offre un avantage indéniable en cas d’attaque réussie : il subsistera
encore une protection des machines et des serveurs internes, même en
cas de compromission de tous les éléments de la DMZ.
5.2.2 Politique de sécurité et plan d’adressage
La connaissance des différents flux ou trafics dans le réseau est

également un facteur déterminant dans le choix de notre architecture.
Elle vient renforcer la notion de segmentation physique réalisée, et
débouche sur un choix du plan d’adressage. Pour chaque zone, nous
définissons alors une politique de sécurité qui traduit les trafics autorisés
ou interdits entre différentes zones.
Zone 1 : réseau local
Les postes de travail destinés au personnel n’offrent pas et ne

doivent pas offrir de service. Par conséquent, ces machines doivent être
invisibles depuis l’extérieur du réseau. L’activité quotidienne du personnel
nécessite que ces postes n’aient pas de restriction d’accès vers

l’extérieur.
Aucun accès n’est nécessaire depuis l’extérieur de cette zone, que

ce soit depuis la zone des serveurs internes ou depuis celle des serveurs
publics. Ces machines doivent en revanche avoir accès sans restriction
au monde extérieur, à tous les services possibles, y compris FTP en
mode actif.
Zone 2 : serveurs internes
Les serveurs à usage interne (SQL pour les bases de données par
exemple) sont isolés du monde extérieur. Ils ne seront accessibles que
par les postes de travail du personnel ou par l’intermédiaire des machines
offrant les services publics.
Zone 3 : DMZ
Les services de la DMZ sont accessibles depuis l’extérieur et

l’intérieur. Ils doivent cependant être séparés du monde extérieur par une
barrière de filtrage. Cette zone, plus ouverte que les deux premières et
orientée vers l’extérieur, est plus vulnérable. Elle sera soumise à une
surveillance accrue de la part des administrateurs.
Cette politique de sécurité nous amène donc à choisir des

adresses privées pour le réseau local et les serveurs internes, qui sont
respectivement 192.168.135.0/24 et 192.168.134.0/24. Nous attribuons à
la DMZ, une adresse publique puisqu’elle doit être accessible de
l’extérieur. L’architecture complète que nous proposons est représentée à
la figure 18.
Réseau local
Serveurs internes
192.168.135.0/24
192.168.134.0/24
IMAP LDAP
192.168.134.10 192.168.134.20
NFS PRINT
Firewall fw2 192.168.134.50 192.168.134.40
SQL
eth2 eth1
192.168.134.30
eth0
HTTP FTP
197.12.100.36 197.12.100.35
eth2
Firewall fw1
SMTP DNS
eth1 197.12.100.38 197.12.100.37
eth0
DMZ
197.12.100.32/27
Internet
Figure 18 : Architecture réseau complète retenue pour la modélisation
5.3. Configuration des équipements
En nous basant sur les considérations précédemment énumérées,

nous sommes alors en mesure de pouvoir définir les règles de filtrage sur
chaque firewall. Pour chaque règle, nous précisons le contexte dans
lequel elle s’applique.
Firewall 1
# Autoriser les connexions du réseau local vers la DMZ
iptables -A fw1 -s 192.168.135.0/24 -d 197.12.100.35 - 197.12.100.38 -m

state --state NEW -j ACCEPT
iptables -A fw1 -s 192.168.135.0/24 -d 197.12.100.35 - 197.12.100.38 -m

state --state ESTABLISHED -j ACCEPT
iptables -A fw1 -s 192.168.135.0/24 -d 197.12.100.35 - 197.12.100.38 -m

state --state RELATED -j ACCEPT
# Autoriser les connexions du réseau local vers l’extérieur
iptables -A fw1 -s 192.168.135.0/24 -m state --state NEW -j ACCEPT
iptables -A fw1 -s 192.168.135.0/24 -m state --state ESTABLISHED -j

ACCEPT
iptables -A fw1 -s 192.168.135.0/24 -m state --state RELATED -j

ACCEPT
# Bloquer les connexions de la DMZ vers le réseau local
iptables -A fw1 -s 197.12.100.32/27 -d 192.168.135.0/24 -m state --state

NEW -j REJECT
# Autoriser les connexions de la DMZ vers les serveurs internes
iptables -A fw1 -s 197.12.100.32/27 -d 192.168.134.0/24 -j ACCEPT
# Autoriser les connexions des serveurs internes vers la DMZ
iptables -A fw1 -s 192.168.134.0/24 -d 197.12.100.32/27 -j ACCEPT
# Bloquer les connexions des serveurs internes vers l’extérieur
iptables -A fw1 -s 192.168.134.0/24 -j REJECT
# Bloquer les connexions de l’extérieur vers les serveurs internes
iptables -A fw1 -d 192.168.134.0/24 -j REJECT
# Autoriser les connexions de la DMZ vers l’extérieur
iptables -A fw1 -s 197.12.100.32/27 --out -interface eth0 -j ACCEPT
# Autoriser les connexions de l’extérieur vers la DMZ
iptables -A fw1 -d 197.12.100.32/27 --in -interface eth0 -j ACCEPT
# Refuse les paquets en provenance de l’extérieur pour lesquels

l’adresse source est définie dans notre réseau (lutte contre IP spoofing).
iptables -A fw1 --in-interface eth0 -s 197.12.100.32/27 -j DROP

l’adresse source est définie dans les réseaux privés de classe A.

l’adresse source est définie dans les réseaux privés de classe B.
iptables -A fw1 --in-interface eth0 --s 172.16.0.0/12 -j DROP

l’adresse source est définie dans les réseaux privés de classe C.

l’adresse source est définie dans le réseau de loopback.
# Refuse les paquets dont l’adresse source est une adresse de

broadcast.
iptables -A fw1 --in-interface eth0 -s 255.255.255.255 -j DROP
# Refuse les paquets dont l’adresse de destination est une adresse

de broadcast.
iptables -A fw1 --in-interface eth0 -d 0.0.0.0 -j DROP
# Refuse les paquets dont l’adresse de destination est l’adresse de

broadcast ou l’adresse de notre réseau.
# Refuse les paquets dont l’adresse source est une adresse de

classe D (multicast).
# Accepte les connexions ESTABLISHED et RELATED
iptables -A fw1 -m state --state ESTABLISHED, RELATED -j ACCEPT
# Accepte les ouvertures de connexion depuis la DMZ

197.12.100.32/27 vers l’extérieur
iptables -A fw1 -m state --state NEW -s 197.12.100.32/27 -j ACCEPT
# Accepte les ouvertures de connexion vers le serveur Web port 80

situé en DMZ
iptables -A fw1 -m state --state NEW -d 197.12.100.36 -p TCP --dport 80 -

j ACCEPT
# Accepte les ouvertures de connexion vers le serveur SMTP port

25 situé en DMZ
iptables -A fw1 -m state --state NEW --destination 193.48.97.68 -p TCP --

dport 25 -j ACCEPT
# Accepte les ouvertures de connexion vers le serveur FTP port 21
iptables -A fwA -m state --state NEW --destination 193.48.97.69 -p TCP --

dport 21 -j ACCEPT
# Accepte les ouvertures de connexion vers les serveurs DNS port

53
iptables -A fw1 -m state --state NEW -d 197.12.100.37 -p UDP --dport 53

-j ACCEPT
iptables -A fwA -m state --state NEW -d 197.12.100.37 -p TCP --dport 53

-j ACCEPT
# Accepte les icmp
iptables -A fw1 -p icmp -j ACCEPT
# Cette règle étant la dernière, elle donne la politique par défaut qui
consiste à tout rejeter sauf, ce qui a été accepté précédemment.
iptables -A fw1 -j REJECT
Firewall 2
# Autoriser les connexions du réseau local vers les serveurs
internes

NEW -j ACCEPT

ESTABLISHED -j ACCEPT

RELATED -j ACCEPT
# Autoriser les connexions du réseau local vers la DMZ
iptables –A fw2 -s 192.168.135.0/24 -d 197.12.100.32/27 -m state --state

NEW -j ACCEPT

ESTABLISHED -j ACCEPT

RELATED -j ACCEPT
# Bloquer les connexions de la DMZ vers le réseau local

NEW -j REJECT
# Bloquer les connexions des serveurs internes vers le réseau local

NEW -j REJECT
# Bloquer les connexions des serveurs internes vers l’extérieur
iptables -A fw2 -s 192.168.134.0/24 -j REJECT
# Bloquer les connexions de l’extérieur vers les serveurs internes
iptables -A fw2 -d 192.168.134.0/24 -j REJECT
# Bloquer les ouvertures de connexions de la DMZ vers le réseau

local

NEW -j REJECT
# Nate les adresses sources avec 3 adresses réelles :

197.12.100.60-61-62
iptables -t nat -A POSTROUTING -i eth1 -j SNAT --to-source

197.12.100.60-197.12.100.62
# Accepte les connexions ESTABLISHED et RELATED
iptables -A fw2 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Accepte les ouvertures de connexion de smtp1 vers imap sur le

port SMTP
iptables -A fw2 -m state --state NEW -s 197.12.100.38 -d 192.168.154.10

-p TCP --dport 25 -j ACCEPT
# Accepte les ouvertures de connexion vers toutes les machines

pour les réseaux internes
iptables -A fw2 -m state --state NEW -s 192.168.134.0/24 -d 0/0 -j

ACCEPT
iptables -A fw2 -m state --state NEW -s 192.168.135.0/24 -d 0/0 -p TCP -j

ACCEPT
# Accepte les icmp
iptables -A fw2 -p icmp -j ACCEPT
# Rejette les autres connexions avec une erreur ICMP, port

unreachable
iptables -A fw2 -j REJECT
# Rejette les demandes de connexion provenant de l'extérieur
iptables -A INPUT -m state --state NEW -j REJECT
Pour pouvoir étudier les configurations des règles de filtrage au

sein de pare-feu à états, nous avons mis en place une architecture
réseau qui intègre les services disponibles, le plan d’adressage de même
que la configuration des firewalls déployés. Les réflexions qui ont dicté
ces choix ont été présentées dans ce chapitre. Il ne reste donc plus qu’à
proposer les algorithmes d’audit des règles de filtrage proposées. Mais
avant, nous devons spécifier le cadre conceptuel du système.
Chapitre 6 : Spécification des besoins du système et analyse
conceptuelle
CHAPITRE 6
SPECIFICATION DES BESOINS DU

SYSTEME ET ETUDE CONCEPTUELLE
Après avoir retenu l’approche d’analyse des configurations des

firewalls, puis choisi l’architecture de notre réseau, nous déterminons à
présent les spécifications du système. Ces spécifications prennent en
compte les fonctionnalités du système à mettre en place. Ensuite, à l’aide
d’UML et de ses diagrammes, nous modélisons le système suivant les
trois grands axes de modélisation à savoir : l’axe fonctionnel (diagramme
de cas d’utilisation), l’axe dynamique (diagramme de séquence) et l’axe
statique (diagramme de classes).
conceptuelle
L’étude conceptuelle du système nous a amené à choisir trois

diagrammes pour modéliser notre système. Suivant chacun des trois
axes de modélisation, nous identifions un diagramme que nous
exploitons. Les trois diagrammes retenus pour notre étude conceptuelle
sont : diagramme de cas d’utilisation, diagramme de séquence,
diagramme de classe.
6.1. Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation est celui qui décrit le modèle

fonctionnel, ou le point de vue fonctionnel de la modélisation d’un
système logiciel. Ce modèle permet en effet de représenter les services
rendus par le système (Roques, 2002). Pour représenter donc ce
diagramme, nous identifions les acteurs en interaction avec le système
de même que les spécifications des besoins.
6.1.1 Acteurs
UML définit la notion d’acteur comme étant un rôle joué par une
entité externe (utilisateur humain, dispositif matériel ou autre système) qui
interagit directement avec le système étudié (Roques, 2006). De cette
définition, nous n’avons retenu qu’un seul acteur : l’Administrateur.
L’Administrateur est celui qui s’occupe de la bonne exécution des

opérations d’audit que réalise le système. Il gère également d’autres
tâches qui concourent à l’effectivité de l’audit des règles de filtrage des
firewalls : qu’il s’agisse de renseigner les informations sur l’architecture
du réseau, que de corriger les éventuelles anomalies relevées.
6.1.2 Spécification des besoins
Le système à mettre en place s’appuie essentiellement sur les

algorithmes de détection d’anomalies que nous avons développés. Mais
conceptuelle
pour pouvoir jouer pleinement cette fonction, d’autres fonctionnalités

doivent être remplies. L’étude des exigences du système nous a permis
de dégager les besoins fonctionnels et ceux non-fonctionnels.
6.1.2.1. Spécifications fonctionnelles
Le système à mettre en place devra fournir les fonctionnalités ci-

après :
 L’administrateur doit pouvoir créer des zones de son architecture

réseau. Il doit pour cela définir le nombre de zones ; puis pour
chacune d’elles, il devra spécifier un nom, l’adresse réseau
associée, de même que l’adresse de la passerelle.
 L’administrateur doit pouvoir créer des firewalls de son architecture
réseau. Il doit pour cela définir le nombre de firewalls. Par ailleurs
pour chacun d’eux, il devra spécifier un nom, les réseaux voisins,
les firewalls voisins (s’ils existent), de même que les règles de
filtrage.
 L’administrateur doit pouvoir spécifier les chemins entre les
éléments du réseau.
 L’administrateur pourra, sur la base des informations du réseau,
effectuer l’analyse intra-firewall pour chaque firewall. Cette analyse,
une fois exécutée, devra mentionner les éventuelles anomalies
figurant dans les règles de filtrage du firewall analysé.
 Une fois l’analyse intra-firewall réalisée, et ce de façon distincte

pour tous les firewalls, l’administrateur pourra, toujours sur la base
des informations du réseau, effectuer l’analyse inter-firewall. Cette
analyse, une fois exécutée, devra faire ressortir les éventuelles
anomalies figurant entre les règles de filtrage de tous les firewalls.
L’administrateur, après avoir effectué chaque analyse, doit pouvoir

corriger les anomalies si le système en fait cas.
conceptuelle
6.1.2.2. Spécifications non-fonctionnelles
Au-delà des spécifications fonctionnelles abordées, il est important

de mentionner les exigences ou paramètres supplémentaires à prendre
en compte lors de la conception du système. Les spécifications non-
fonctionnelles qui ont été retenues à cet effet sont :
- la disponibilité du système ;
- la fiabilité du système ;
- l’ergonomie sobre et efficace du système. Ses interfaces
devront être claires, conviviales et intuitives ;
- la sécurité su système.
Les spécifications du système étant définies, nous élaborons

ensuite les différents diagrammes concernant la modélisation du
système.
6.1.3 Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation permet de recenser les grandes

fonctionnalités du système. Il représente les différentes possibilités selon
lesquelles les entités à l’extérieur du système (les acteurs) interagissent
avec ce dernier. Il est utilisé dans l’activité de spécification des besoins.
Le diagramme de cas d’utilisation de l’Administrateur de notre système
est défini à la figure 19.
conceptuelle
Figure 19 : Cas d’utilisation de l’Administrateur
Après tout ce travail d’identification des cas d’utilisation, nous

pouvons maintenant les classer en tenant compte de leur priorité. Le
tableau VIII nous donne les différents cas d’utilisation en fonction de leur
priorité. Pour les cas d’utilisation de même priorité, c’est leur ordre
d’apparition qui définit leur priorité. Ainsi, « créer un objet firewall » a une
priorité inférieure à celle de « créer un objet zone », quand bien même
ces deux cas d’utilisation soient tous de haute priorité.
conceptuelle
Tableau VIII : Priorité des cas d’utilisation
Cas d’utilisation Priorité
Créer les objets zone Haute
Créer les objets firewall Haute

Spécifier les chemins entre les éléments du réseau Haute
Effectuer l’analyse intra-firewall Moyenne
Effectuer l’analyse inter-firewall Moyenne
Pour documenter et mieux comprendre les cas d’utilisation, une

description textuelle est indispensable, car elle seule permet de
communiquer facilement avec les utilisateurs et de s’entendre sur la
terminologie métier employée. Dans le cas de notre système, nous
n’effectuons que les descriptions textuelles des cas d’utilisation de haute
priorité.
Les descriptions textuelles respectivement associées aux cas

d’utilisation « créer les objets zone », « créer les objets firewall » et
« spécifier les chemins entre les différents éléments du réseau » sont
illustrées par les tableaux IX, X et XI.
conceptuelle
Tableau IX : Description textuelle du cas d’utilisation « créer les objets

zones »
Titre Créer les objets zone
Définir les objets zone du réseau de même que les
Objectifs
propriétés qui leur sont associées.
Acteurs Administrateur
 L’administrateur s’est déjà authentifié.
Pré conditions
 La page d’accueil du système est affichée.
1. L’administrateur choisit dans le menu l’option pour
définir un nouveau réseau.
2. Le système affiche la page correspondante avec un
message indiquant que l’action a été effectuée avec
succès.
3. L’administrateur valide le message.
4. Le système demande alors le nombre de zones dans le
réseau. Ce nombre inclut Internet qui est la zone externe
au réseau.
Scénario nominal
5. L’administrateur indique le nombre de sous-réseaux.
6. Le système vérifie la validité du nombre saisit.
7. Le système invite l’Administrateur à éditer les propriétés
de chaque objet zone.
8. L’administrateur saisit pour chaque zone : le nom,
l’adresse du réseau, l’adresse de la passerelle.
9. Le système vérifie pour chaque zone, les informations
saisies.
10. Les informations saisies sont enregistrées.
a. Nombre de zones incorrect
Cet enchaînement démarre au point 6 du scénario nominal
7. le système demande de saisir un entier supérieur ou
égal à 2.
Le scénario nominal reprend au point 4.
Scénario
b. Propriétés saisies incorrectes
alternatif
Cet enchaînement démarre au point 9 du scénario
nominal.
10. Le système demande de saisir des informations
valides.
 Chaque objet zone est défini avec ses propriétés.
Post conditions
 L’administrateur peut définir les objets firewall.
conceptuelle
Tableau X : Description textuelle du cas d’utilisation « créer les objets

firewall »
Définir les objets firewall du réseau de même que les
Objectifs
propriétés qui leur sont associées.
Pré conditions  Toutes les zones du réseau sont déjà définies.
1. L’administrateur choisit l’option pour définir les firewalls.
2. Le système affiche une page et informe l’Administrateur
qu’il peut définir les firewalls du réseau à travers un
message.
3. L’administrateur valide le message.
4. Le système demande le nombre de firewalls dans le
réseau.
5. L’administrateur saisit le nombre de firewalls.
6. Le système vérifie la validité du nombre saisi.
Scénario nominal
7. Le système invite l’Administrateur à saisir les propriétés
des firewalls.
8. L’administrateur saisit pour chaque firewall ses
propriétés : son nom, le nombre d’interfaces, l’adresse
pour chaque interface, les zones voisines, les firewalls
voisins, les règles de filtrage.
9. Le système vérifie pour chaque firewall les informations
saisies.
10. Les informations saisies sont enregistrées.
a. Nombre de firewalls incorrect
nominal
6. Le système demande de saisir un entier non-nul et
inférieur au nombre de zones.
Scénario Le scénario nominal reprend au point 3.
alternatif b. Propriétés saisies incorrectes
nominal.
9. Le système demande de saisir des informations
valides.
 Chaque objet firewall est défini avec ses propriétés.
Post conditions  L’administrateur peut ensuite définir les chemins entre
chacun des éléments du réseau.
conceptuelle
Tableau XI : Description textuelle du cas d’utilisation « spécifier les

chemins entre les différents éléments du réseau »
Définir tous les chemins existant entre les différentes
Objectifs
entités du réseau.
 Toutes les zones du réseau sont déjà définies.
Pré conditions
 Tous les firewalls du réseau sont déjà définis.
1. L’administrateur choisit l’option pour définir les chemins
entre les éléments du réseau
2. Le système demande de choisir la zone source parmi
la liste des zones préalablement définies.
3. L’administrateur choisit une zone.
4. Le système demande de choisir toujours parmi la liste
des zones, la zone destination.
5. L’administrateur choisit une zone.
6. Le système demande le nombre de chemins pouvant
relier les deux zones.
7. L’administrateur saisit le nombre de chemins.
Scénario nominal
8. Le système vérifie la validité du nombre entré.
9. Le système demande pour chaque chemin d’énumérer
les zones appartenant au chemin reliant les deux zones.
10. L’administrateur mentionne ces zones.
11. Le système demande pour chaque chemin
d’énumérer les firewalls appartenant au chemin reliant
les deux zones.
12. L’administrateur indique les firewalls se trouvant sur le
chemin.
13. Le système connaît alors l’itinéraire entre toutes les
zones et enregistre les informations fournies.
a. Absence de lien entre un firewall et une zone
nominal
13. Le système demande de respecter le principe de
voisinage entre les firewalls et les zones.
Scénario Le scénario nominal reprend au point 11.
alternatif b. Firewall isolé
nominal.
13. Le système envoie un message d’erreur et indique
qu’il y a un firewall isolé.
conceptuelle
c. Zone isolée
nominal.
13. Le système envoie un message d’erreur et indique
qu’il y a un firewall isolé.
Post conditions  Tous les éléments du réseau sont définis.
 Les routes entre les éléments du réseau sont connues.
 L’administrateur peut ensuite exécuter l’analyse intra-
firewall.
6.2. Diagramme de séquence
Avec les diagrammes d’états, d’activités et de collaboration, le

diagramme de séquence fait partie des diagrammes qui définissent l’axe
dynamique d’une modélisation en UML. Ce mode de représentation
effectue la description du fonctionnement dynamique du système ; c’est-
à-dire la description des changements d’états du système en réaction aux
événements ayant un impact sur celui-ci.
Le diagramme de séquence permet de représenter les interactions

entre objets en indiquant la chronologie des échanges. Cette
représentation peut se réaliser par cas d’utilisation en considérant les
différents scénarios associés. Pour chaque description textuelle des cas
d’utilisation abordés précédemment, nous élaborons le diagramme de
séquence correspondant (figures 20, 21, 22).
conceptuelle
Figure 20 : Diagramme de séquence « créer les objets zone »
conceptuelle
Figure 21 : Diagramme de séquence « créer les objets firewall »
conceptuelle
Figure 22 : Diagramme de séquence « spécifier les chemins »
6.3. Diagramme de classes
Ce diagramme est utilisé pour modéliser un système d’un point de

vue statique. Dans une modélisation, la représentation statique décrit les
acteurs et les concepts qui structurent le système.
Le diagramme de classes est le point central dans un

développement orienté objet. En analyse, il a pour objet de décrire la
structure des entités manipulées par les utilisateurs. En conception, le
diagramme de classes représente la structure d’un code orienté objet ou,
conceptuelle
à un niveau de détail plus important, les modules du langage de

développement (Roques, 2002). La figure 23 présente le diagramme de
classes de notre système.
Figure 23 : Diagramme de classes du système
Dans ce chapitre, nous avons présenté le cadre conceptuel de

notre système. Pour ce faire, nous avons défini les spécifications des
besoins du système, puis nous les avons représentées à l’aide des
diagrammes des cas d’utilisation et de séquence. Ensuite, nous avons
représenté, à l’aide du diagramme de classes la structure interne du
système.
Partie 3
PARTIE 3
RESULTATS ET
DISCUSSIONS
Chapitre 7 : Résultats
CHAPITRE 7
RESULTATS
Ce chapitre expose les principaux résultats auxquels nous avons

abouti. Il s’agit des algorithmes de détection d’anomalies qui nous
permettent de vérifier la cohérence au sein des configurations des règles
de filtrage.
Les algorithmes que nous proposons effectuent les opérations

d’audit dans le but de détecter d’éventuelles anomalies. Ils prennent en
entrées toutes les informations concernant l’architecture réseau à auditer,
que l’administrateur a soigneusement saisies dans le système. Ces
informations concernent plus précisément :
 les objets zones ou sous-réseaux : on définit le nombre de
zones, puis pour chacune d’elles on spécifie un nom, l’adresse réseau
associée, de même que l’adresse de la passerelle ;
 les objets firewalls : on définit le nombre de firewalls, puis pour
chacun d’eux on spécifie un nom, les zones voisines, les firewalls
voisins (s’ils existent) et les règles de filtrage ;
 les routes ou chemins entre les éléments du réseau : pour
chaque paire de zones, on spécifie tous les firewalls et tous les sous-
réseaux intermédiaires ;
 ensuite, on supprime, des règles de filtrage, les tables nat et
mangle qui n’interviennent pas dans le filtrage.
Les algorithmes proposés effectuent aussi bien l’analyse intra-

firewall que l’analyse inter-firewall. Des fonctions auxiliaires ont été
définies lors des traitements. Les figures suivantes exposent de façon
détaillée toutes ces fonctions de même que les algorithmes intra-firewall
et inter-firewall.
La détermination des anomalies entre les règles de filtrage dépend

aussi bien du type de relations entre lesdites règles que de leurs cibles.
Des conditions spécifiques doivent donc être réunies afin d’identifier tous
les cas d’anomalies. Dans le but de pouvoir déterminer ces conditions,
nous établissons les considérations suivantes : Rx et Ry sont deux règles
de filtrage telles que Rx soit prioritaire par rapport à Ry. Les relations
existant entre ces règles sont : l’égalité, l’inclusion, la différence. Par
ailleurs, nous considérons « p » comme étant le nombre total de
propriétés au niveau des règles de filtrage. Nous définissons ainsi les
variables a, b, c et d comme suit :
 a : indique une relation d’égalité entre une propriété de Rx et

la propriété correspondante de Ry ;
 b : indique qu’une propriété de Rx est incluse dans la
propriété correspondante de Ry ;
 c : indique qu’une propriété de Ry est incluse dans la
propriété correspondante de Rx ;
 d : indique les propriétés de Rx et de Ry sont différentes.
Pour déterminer le type de relation entre R x et Ry, leurs propriétés

doivent être comparées deux à deux. Chacune des variables garde une
valeur après la comparaison de deux règles. Ainsi, la valeur :
- 0 signifie qu’aucune propriété ne vérifie la relation pour laquelle la

variable est définie ;
- 1 signifie qu’un nombre non-nul de propriétés « n » tel que n < p
vérifie la relation pour laquelle la variable est définie ;
- 4 signifie que toutes les propriétés vérifient la relation pour laquelle
la variable est définie.
 Fonction ensembleadresse(a)
Cette fonction vérifie si la valeur de la propriété a est un ensemble

ou une plage d’adresse IP, et renvoie vrai si c’est le cas (figure 24).
Variables :
ch1, ch2 chaîne ;
Début
ocuurence de ''.'' et
''/'' dans a
ch1=sous-chaîne return false

avant ''/''
ch2=sous-chaîne
avant ''/''
ch1 & ch2
return true return false
Fin
Figure 24 : Fonction ensembleadresse
 Fonction ensemble(a)
Cette fonction vérifie si la valeur de la propriété a est un ensemble

ou une plage de valeurs, et renvoie vrai si c’est le cas (figure 25).
Variables :
ch1, ch2 chaîne ;
Début
ocuurence de ''-'' ou
'','' ou '':'' dans a
ensembleadresse(a)
return true
Fin
Figure 25 : Fonction ensemble
 Fonction testegalite(a,b)
Cette fonction vérifie si la valeur de la propriété a est égale à la

valeur de la propriété b et renvoie vrai si c’est le cas (figure 26).
Variables :
a, b chaîne ;
Début
a = b
return true return false
Fin
Figure 26 : Fonction testegalite
 Fonction testinclusion(a,b)
Cette fonction vérifie si la valeur de la propriété a est incluse dans

celle de la propriété b et renvoie vrai si c’est le cas (figure 27).
Variables :
a chaîne ;
b chaîne ;
Fonctions :
ensemble(chaîne b) : booléen
Début
a et b = 
a et b  et
ensemble(b)
return true
ab
return false
return true
Fin
Figure 27 : Fonction testinclusion
 Fonction testcontenance
Cette fonction vérifie si la valeur de la propriété a contient celle de

la valeur b ou si la valeur de la propriété b est incluse dans celle de la
propriété a et renvoie si c’est le cas (figure 28).
Variables : identificateur, type
a chaîne ;
b chaîne ;
Fonctions : ensemble(chaîne a) : booléen
Début
b et a = 
a et b  et
ensemble(a)
return true
ba
return false
return true
Fin
Figure 28 : Fonction testcontenance
 Fonction compare
Cette fonction compare deux règles de filtrage entre elles pour

déterminer le type de relations qui les lie, via un tableau de quatre entiers
qu’elle renvoie (figure 29).
Variables :
a chaîne ;
b chaîne ;
tab[] chaîne (est un tableau de chaînes) ;
Fonctions :
testégalité(chaîne a, chaîne b) : booléen
testinclusion(chaîne a, chaîne b) : booléen
testcontenance(chaîne a, chaîne b) : booléen
Début
tab[]  {0;0;0;0}
testégalité(a,b)
testinclusion(a,b)
tab[1] = tab[1] + 1
testcontenance(a,b)
tab[2] = tab[2] + 1
tab[3] = tab[3] + 1
tab[4] = tab[4] + 1
Fin
Figure 29 : Fonction compare
 Fonction comparer
Cette fonction analyse les firewalls a et b pour savoir quel type

d’anomalies y figurent (figure 30).
Variables :
i, j, k entier ; (variables compteur)
n entier ; (nombre de règles de filtrage du le firewall a)
m entier ; (nombre de règles de filtrage du le firewall b)
l entier ; (nombre total de propriétés définies de façon unique

sur l’ensemble des règles de filtrage des firewalls a et b analysés)
temp[], tab[] entier ; (tableau d’entiers de taille 4)
Ri[pk] chaîne ; (représente les k différentes propriétés

définies sur la règle de filtrage Ri)
rslt chaîne ;
Fonctions
compare(chaîne a, chaîne b) : entier ;
Figure 30 : Fonction comparer
 Algorithme intra-firewall
Cet algorithme détermine les éventuelles anomalies au sein d’un

même et unique firewall (figure 31).
Variables :
i, j, k entier ; (variables compteur)
n entier ; (nombre de règles de filtrage dans le firewall

analysé)
m entier ; (nombre total de propriétés définies de façon

unique sur l’ensemble des règles de filtrage du firewall analysé)
temp[], tab[] entier ; (tableau d’entiers de taille 4)
Ri[pk] chaîne ; (représente les k différentes propriétés

définies sur la règle de filtrage Ri)
Fonctions
compare(chaîne a, chaîne b) : entier ;
Figure 31 : Algorithme intra-firewall
 Algorithme inter-firewall
Cet algorithme détermine les éventuelles anomalies au sein de

tous les firewalls du réseau (figure 32).
Variables : identificateur, type
i, j, k, l, m entier ; (variables compteur)
n entier ; (nombre total de zones défini dans l’architecture

réseau)
h entier ; (détermine le nombre de chemins entre deux

zones)
f entier ; (détermine le nombre de firewalls entre deux zones)
tab[] chaîne ; (tableau qui reçoit la liste des firewalls)
anomalie chaîne ; (décrit toutes les anomalies détectées)
Fonctions
comparer(firewall a, firewall b) : chaîne ;
Figure 32 : Algorithme inter-firewall
Afin de nous assurer de la cohérence de nos algorithmes, nous

avons effectué des tests de chaque type d’audit. Ainsi, en nous basant
sur les règles de filtrage proposées (confère chapitre 5), nous avons
recensé les anomalies suivantes en ce qui concerne l’analyse intra-
firewall des firewalls fw1 (figure 33) et fw2 (figure 34).
Figure 33 : Test d’audit intra-firewall du firewall fw1
Figure 34 : Test d’audit intra-firewall du firewall fw2
L’analyse inter-firewall effectuée sur les deux firewalls fw1 et fw2 a

révélé les anomalies présentées à la figure 35.
Figure 35 : Test d’audit inter-firewall
Pour corriger ces différentes anomalies, l’utilisateur peut modifier

les propriétés des règles de filtrage, les tester à nouveau avant de valider
les modifications apportées. Un guide à l’utilisation de la plateforme est
présenté en annexe E du document, avec les informations détaillées
concernant les processus d’audit des firewalls.
Chapitre 8 : Discussions
CHAPITRE 8
DISCUSSIONS
Ce chapitre effectue une analyse critique des principaux résultats

obtenus.
La réalisation de ce projet nous a permis de mettre en œuvre des

algorithmes de détection d’anomalies au sein des configurations de
firewalls. A l’instar des travaux effectués par Alfaro et al. (2008), nos
algorithmes ont l’avantage de pouvoir prendre en compte l’architecture du
réseau étudié. Ainsi grâce au système développé, l’administrateur saisit
toutes les informations concernant son réseau. Il peut donc renseigner le
nombre de sous-réseaux, de même que leurs propriétés, le nombre et les
propriétés des firewalls. Grâce à l’implémentation de l’algorithme de
Djikstra, la liste des chemins reliant toutes les zones est proposée.
L’utilisateur peut ensuite choisir parmi cette liste les chemins qu’il
souhaite conserver. Cette fonction permet donc d’obtenir
automatiquement tous les chemins possibles dans le réseau. Elle évite
ainsi à l’utilisateur de devoir spécifier tous les chemins, c’est-à-dire tous
les firewalls reliant une zone source à une zone destination donnée. Le
système n’étant pas encore dynamique, il n’est pas encore possible de
pouvoir opérer des modifications sur l’architecture du réseau. Les
fonctionnalités supplémentaires d’ajout, de modification et de suppression
de sous-réseaux et de firewalls ont été définies pour rendre la
configuration du réseau aussi aisée que possible, afin qu’elle s’adapte à
toute modification de l’architecture.
Un autre aspect non moins important est la façon dont les règles
sont analysées. Dans un souci d’optimiser le temps d’analyse des règles,
nous avons imposé la condition selon laquelle deux règles ne peuvent
être analysées que si elles ont le même protocole ou si elles ont une
probabilité d’avoir le même protocole. Ceci évite en effet de comparer des
règles devant s’appliquer à des paquets de protocoles différents.
Une fois les règles analysées, il faut ensuite identifier le type de

relation qui les lie. Pour ce faire, la fonction compare nous renvoie des
valeurs permettant de déterminer, en plus des cibles, la nature des
éventuelles anomalies. Cette fonction dans son exécution fait appel à
plusieurs autres fonctions dont notamment la fonction ensemble qui

permet de savoir si la valeur d’une propriété est un ensemble. La difficulté
qui a résidé dans la définition de cette fonction est qu’elle doit gérer
toutes les propriétés sur lesquelles il est possible de définir des
ensembles. Or pour chaque propriété, il peut y avoir différentes
possibilités dans lesquelles on peut avoir un ensemble de valeurs. Nous
avons à cet effet choisi parmi toutes ces possibilités certaines qui nous
ont permis de reconnaître les occurrences d’ensemble. A titre d’exemple,
nous n’avons pas géré le cas où la négation sur la valeur d’une propriété
peut définir un ensemble. Cette fonction devra donc être sujette à de
nouvelles réflexions, afin de rendre notre système fiable. Par ailleurs, tout
comme Al-Shaer et Hamed (2004), notre algorithme ne gère pas encore
les relations partielles. Une solution à ce problème, dont nous devrons
nous inspirer, est apportée par les travaux de Al-Shaer, Hamed et Masum
(2005) d’une part, et par ceux de Alfaro et al. (2006) d’autre part.
Pour des contraintes de temps, nous n’avons pas géré d’une part
pour les anomalies intra-firewall, l’anomalie de pertinence, et d’autre part
pour les anomalies inter-firewall, toutes les conditions possibles devant
dénoter la présence d’une anomalie. Il nous faudra donc en tenir compte
pour les recommandations à suivre en perspectives.
Le système étant conçu pour détecter les anomalies, il n’a

cependant pas été défini une stratégie de correction automatique
desdites erreurs à l’inverse des algorithmes définis par Alfaro et al.
(2005). Ce problème se pose surtout pour les anomalies inter-firewall.
Dans le cas par exemple d’une anomalie de masquage, il n’est pas
évident de pouvoir définir la cible que doit exécuter une des deux règles
pour supprimer l’anomalie. Il est en effet difficile de déterminer la cible
légitime à appliquer sans que cela ne puisse générer d’autres éventuelles
erreurs. C’est pourquoi, cette tâche est réservée à l’administrateur qui
maîtrise mieux le réseau et les trafics qui y circulent. Pour remédier à ce
problème, nous pourrions intégrer un processus de correction de façon à

ce que l’administrateur ait le choix entre une méthode automatique et une
méthode manuelle. Par ailleurs, notre méthode automatique, avant de
pouvoir rendre effectives les corrections apportées, devrait proposer un
aperçu des modifications apportées avant de les appliquer ou de les
rejeter. Outre les algorithmes de détection d’anomalies, des fonctions
supplémentaires, similaires à celles définies par Al-Shaer et Hamed
(2006), devront être proposées pour effectuer une analyse
complémentaire lors de l’ajout de nouvelles règles afin de ne pas générer
de nouvelles anomalies.
Dans le but de permettre à l’administrateur de pouvoir garder en

mémoire tous les tests effectués sur les règles des firewalls, une fonction
de journalisation détaillée devra être fournie par le système. Ainsi, le
système pourra garder en mémoire toutes les analyses qui ont été
effectuées (date, heure, etc.), les anomalies décelées de même que les
règles à la base de ces anomalies. Le système devra aussi renseigner
sur le type d’actions effectuées pour corriger les incohérences dans les
configurations.
Conclusion et perspectives
L’évaluation de la qualité des politiques de sécurité au sein des

firewalls a fait l’objet de notre étude. Cette réflexion nous a permis de
proposer des algorithmes d’audit des configurations des firewalls.
Pour ce faire, nous avons en premier lieu défini l’architecture

réseau sur laquelle nous nous sommes basés pour conduire ce projet.
Ensuite, nous avons défini l’approche ascendante comme méthodologie
d’étude. Cette méthode, à l’opposé de l’approche descendante, nous a
permis de mieux comprendre comment analyser les configurations des
pare-feu du réseau, et par conséquent la politique de sécurité sous-
jacente. Ainsi, nous avons pu proposer des algorithmes permettant
d’analyser les règles de filtrage, et de faire ressortir d’éventuelles
anomalies pouvant nuire à l’intégrité du système. Pour y arriver, un travail
préliminaire nous a amené à identifier les possibles relations existant
entre les règles de filtrage. Après avoir défini les spécifications du
système que nous avons conçu, nous y avons implémenté nos
algorithmes, tout en essayant d’optimiser le traitement des règles de
filtrage. Une fois les anomalies détectées, la plateforme propose à
l’utilisateur de corriger lesdites anomalies avant d’effectuer de nouvelles
anomalies.
La plate-forme mise sur pied a néanmoins des faiblesses qu’il

faudra corriger pour la rendre plus fiable. Elle ne gère, pour le moment,
qu’un certain nombre d’anomalies. L’idéal serait donc d’intégrer le module
de détection de toutes les anomalies abordées au chapitre 3, et de
proposer à l’utilisateur une solution pour corriger l’anomalie, soit en
supprimant une règle, soit en modifiant ses propriétés. Le système devra
également s’adapter à la diversité des composants de sécurité déployés
au sein d’un réseau. Notre travail ouvre donc des perspectives pour
étendre les fonctionnalités du système développé aux autres

équipements tels que les VLAN (Virtual Local Area Network), les VPN ;
les IDS, les IPS, etc. Par ailleurs, nous envisageons faire une extension
des fonctionnalités des firewalls aux fonctions d’analyse de contenu et de
filtrage applicatif.
Références bibliographiques
REFERENCES BIBLIOGRAPHIQUES
 Alfaro, J.G., Boulahia-Cuppens, N., Cuppens, F., 2005a : Detection

and removal of firewall misconfiguration. In proceedings of the 2005
IASTED International Conference on Communication, Network and
Information Security, 1-9.
 Alfaro, J.G., Boulahia-Cuppens, N., Cuppens, F., 2005b :
Misconfiguration Management of Network Security Components. In
proceedings of the 7th International Symposium on System and
Information Security, 1-13.
 Alfaro, J.G., Boulahia-Cuppens, N., Cuppens, F., 2006 : Towards
filtering and alerting rule rewriting on single-compoment policies. In
International Conference on Computer Safety, Reliability, and
Security, 1-14.
 Alfaro, J.G., Boulahia-Cuppens, N., Cuppens, F., 2007 : Aggregating
and deploying network access control policies. In 1st Symposium on
Frontiers in Availability, Reliability and Security (FARES), 2 nd
International Conference on Availability, Reliability and Security
(ARES2007), 1-13.
 Alfaro, J.G., Boulahia-Cuppens, N., Cuppens, F., 2008a : Analysis of
policy anomalies on distributed network security setups. Int. J. Inf.
Sec. 7(2), 1-18.
 Alfaro, J.G., Boulahia-Cuppens, N., Cuppens, F., 2008b : Complete
analysis of misconfiguration rules to guarantee reliable network
security policies. Int. J. Inf. Sec. 7(2), 1-20.
 Al-Shaer, E. S., Hamed, H. H., 2002 : Design and Implementation of
Firewall Policy Advisor Tools, DePaul CTI Technical Report, CTI-TR-
02-006, 1-21.
 Al-Shaer, E. S., Hamed, H. H., 2003 : Firewall Policy Advisor for
Anomaly Detection and Rule Editing, IEEE/IFIP Integrated
Management Conference (IM’2003), 1-14.
 Al-Shaer, E. S., Hamed, H. H., 2004 : Discovery of Policy Anomalies

in Distributed Firewalls, In Proceedings of IEEE INFOCOM’ 2004, 1-
12.
 Al-Shaer, E. S., Hamed, H. H., Boutaba, R., Hasan, M., 2005 :
Conﬂict Classiﬁcation and Analysis of Distributed Firewall Policies, In
IEEE Journal on Selected Areas in Communications, 23(10), 1-16.
 Al-Shaer, E. S., Hamed, H. H., 2006 : Taxonomy of conflicts in
networks security policies. In IEEE Journal on Selected Areas in
Communications Magazine, 44(3), 1-12.
 Bloch, L., Wolfhugel, C., 2007 : Sécurité informatique. Principes et
méthodes. Eyrolles, 276p.
 Bloch, L., Wolfhugel, C., 2009 : Sécurité informatique. Principes et
méthodes, 2ème édition. Eyrolles, 312p.
 Boutherin B., Delaunay B., 2006 : Sécuriser un réseau Linux 3 ème
édition, Cahier de l’Admin. Eyrolles, 200p.
 Cuppens, F., Boulahia-Cuppens, N., Sans, T., Miege, A. A., 2004 : A
formal approach to specify and deploy a network security policy. In 2 nd
Workshop on Formal Aspects in Security and Trust, 1-16.
 Chadwick, D.W., 2000 : Network Firewall Technologies. Proceedings
of the NATO Advanced Networking Workshop on Advanced Security
Technologies in Networking Security Portoroz, 1-19.
 Charroux, B., Osmani, A., Thierry-Mieg, Y., 2009 : UML 2 Pratique de
la modélisation, Collection Synthex, 2ème édition. Pearson, 270p.
 Gabay, J., Gabay, D., 2008 : UML 2 Analyse et conception. Dunod,
242p.
 Gouda, M. G., Liu, A. X., 2005 : A model of stateful firewalls and its
properties. In proceedings of the IEEE International Conference on
Dependable Systems and Networks, 1-10.
 Llorens, C., Levier, L., Valois, D., 2006 : Tableaux de bord de la
sécurité réseau, 2ème édition. Eyrolles, 560p.
 M’Bata, A., Persent, O., 2006 : Firewall, Pare-feux, Mur de feu. 2-18.
 Morley, C., Bia-Figueiredo, M., Gillette, Y., 2011 : Processus métiers
et systems d’information, Gouvernance, management, modélisation,
3ème édition. Dunod, 319p.
 Niederberger, R., Allcock, W., Gommans, L., Grünter, E., Metsch, T.,
Monga, I., Volpato, G.L., 2006 : Firewall Issues Overview. 4-9.
 Preda, S., Cuppens-Boulahia, N., Cuppens, F., Alfaro, J. G., Toutain,
L., 2007 : Reliable Process for Security Policy Deployment.
SECRYPT 2007: 2-8.
 Remazeilles, V., 2009 : La sécurité des réseaux avec Cisco. Editions
ENI, 140p.
 Richardson, R., 2008 : CSI Computer Crime & Security Survey
 Roques, P., 2002 : Les cahiers du programmeur UML, Modéliser un
site e-commerce, 5e Edition. Eyrolles, 152p.
 Roques, P., 2006 : UML 2 par la pratique, 5e Edition. Eyrolles, 364p.
 Roques, P., 2008 : Les cahiers du programmeur UML, UML 2
Modéliser une application web, 4ème Edition. Eyrolles, 264p.
 Schmidt, H.L., 2009: Information Assurance Technology Analysis
Center: Tools Report – Firewalls. Sixth Edition, 2-9.
 Vacca, J.R., 2009 : Computer and Information Security Handbook.
Editions Morgan Kaufmann, 382-400.
 Wool, A., 2006 : Packet Filtering and Stateful Firewalls. 2-8.
 Zalewski, M., 2009 : Menaces sur le réseau. Guide pratique des
attaques passives et indirectes. Editions Pearson, 342p.
Annexes
ANNEXES
Annexes
ANNEXE A : Présentation de Bénin Télécoms

S.A.
Historique
Créé le 1er juillet 1890, le Service des Postes et

Télécommunications du Dahomey devient Office des Postes et
Télécommunications (OPT) en 1959. Cet établissement à caractère
industriel et commercial est doté de l’autonomie financière et est passé
d’une gestion de type de droit public à une gestion reposant sur le droit
privé depuis le 17 août 1995.
Dans le but d’atteindre ses objectifs, l’OPT s’était engagé dans des
réformes structurelles et organisationnelles profondes. Elles sont
destinées à améliorer effectivement la gestion qui, pour devenir efficace
et assurer la survie de l’office dans un environnement en pleine mutation
technologique, doit prendre en compte les exigences d’une économie de
marché.
Au terme des actions engagées dans le cadre de la réforme des

postes et télécommunications depuis 1994 par les gouvernements
successifs, la scission du secteur a été effectivement réalisée en 2004
avec la création de deux entités juridiquement distinctes : la Poste du
Bénin SA et Bénin Télécoms SA (BTSA) par le décret N°2004-260 du 05
mai 2004.
Mission
Bénin Télécoms SA a pour principale mission, la fourniture à toute

la population béninoise des services de télécommunications de qualité,
de toutes natures, rapidement accessibles, fiables et compétitifs de façon
à jouir de la confiance de la clientèle et garantir la viabilité et une bonne
réputation de l’entreprise.
Annexes
Par ailleurs, quelques autres missions secondaires lui sont

assignées. Il s’agit de :
 veiller à l’entretien et à la maintenance des installations et stations

de télécommunication mises en place par l’Etat, pour une meilleure
satisfaction des citoyens ;
 céder aux citoyens et aux entreprises privées l’exploitation des

produits téléphoniques, à usage personnel ou commercial ;
 se charger d’héberger les sites des opérateurs GSM privés.
Organisation administrative de la société
Bénin Télécoms SA est une entreprise du secteur tertiaire. Elle

appartient à la branche services aux entreprises selon la classification de
l’INSAE (Institut National des Statistiques et d’Analyses Economiques), et
à la filière Poste et Télécommunications.
La société publique des télécommunications au Bénin comporte

onze (11) directions.
Il s’agit de :
 la Direction Générale (DG) ;
 la Direction Générale Adjointe (DGA) ;
 la Direction de l’Informatique et du Multimédia (DIM) ;
 la Direction de la Stratégie et du Marketing(DSM) ;
 la Direction des Réseaux (DR) ;
 la Direction Commerciale (DC) ;
 la Direction de l’Interconnexion et du Réseau International (DIRI) ;
Annexes
 la Direction de l’Administration (DA) ;
 la Direction Financière et Comptable (DFC) ;
 la Direction de l’Audit et du Contrôle Interne (DACI) ;
 la Direction de Bénin Télécom Mobile (BT- Mobile).
Ces différentes directions sont structurées en des divisions qui sont

à leur tour organisées en sections.
Présentation de la Direction de l’Informatique et du Multimédia
Sous l’autorité du Directeur général, la Direction de l’Informatique

et du Multimédia est chargée de la définition, de l’élaboration et de la
mise en œuvre de la politique informatique et du développement du
multimédia de Bénin Télécoms SA en collaboration avec les autres
directions techniques.
Les tâches découlant de ces attributions s’exécutent par :
 La Sous-Direction Multimédia ;
 La Division Développement et Application ;
 La Division des services informatiques et maintenance.
 La Sous-Direction du Multimédia
Sous l’autorité du Directeur de l’Informatique et du Multimédia, la

Sous-Direction du Multimédia est chargée de la définition de l’élaboration
et de la mise en œuvre de la politique du développement du multimédia
de Bénin Télécoms SA en collaboration avec les structures techniques
compétentes. Les tâches découlant de ses attributions s’exécutent par :
Annexes
 La Division Infrastructures, Systèmes et Réseaux
Sous l’autorité du Sous-Directeur du Multimédia, la Division

Infrastructures, Systèmes et Réseaux est chargée :
 de l’administration, de l’installation et de la maintenance des

réseaux ;
 de la gestion des parcs et des systèmes ;
 de la gestion du réseau Internet du Bénin et de la gestion technique

du domaine national « bj » ;
 de la gestion du réseau intranet de Bénin Télécoms;
 du développement de l’ensemble des technologies permettant

l’accès haut débit à Internet et favorisant le développement du
multimédia ;
 de la conception et de la mise en œuvre du réseau national ainsi

que de l’élaboration d’une stratégie de sécurisation dudit réseau ;
 de la définition, de l’aide au choix et de l’accompagnement des

évolutions des architectures techniques.
 La Division Vente et Prestations de Service
Sous l’autorité du Sous-Directeur de Multimédia, la Division Vente

et Prestations de Service est chargée :
 de l’élaboration des solutions permettant un meilleur

positionnement sur de nouveaux marchés du multimédia ;
 de la conception des solutions destinées aux entreprises et au

grand public ;
Annexes
 de l’installation et de l’administration de la plate-forme client ;
 de la proposition et de la mise en place des solutions en veillant à

optimiser les coûts d’administration ;
 de l’accompagnement du client sur tout le cycle de vie de son

projet ;
 du développement d’une capacité à s’engager sur les délais, les

coûts et la qualité de service;
 de l’organisation des activités de vente au grand public ;
 de l’organisation des travaux de collecte et d’analyse des données

de ventes et autres informations de gestion.
 La Cellule Gestion des Partenariats et Gros Comptes
Sous l’autorité du Sous-Directeur de Multimédia, la Cellule Gestion

des Partenariats et Gros Comptes est chargée :
 de la gestion des relations commerciales avec les partenaires

agréés pour la distribution des produits ADSL ;
 de l’organisation et de la gestion des forces de vente mobile et

sédentaire dédiées aux institutions et aux entreprises ;
 de la coordination des activités de vente et de services après-vente

auprès des institutions et aux entreprises ;
 de la fourniture des offres personnalisées et des services

convergents aux institutions et aux entreprises ;
 de la prise en charge des services après-vente (dérangement et

autres opérations de lignes) requis pour éviter la discontinuité des
prestations offertes par BTSA.
Annexes
 de la fourniture des offres personnalisées et des services

convergents aux entreprises ;
 de l’élaboration des projets de contrats commerciaux pour le

partenariat BTSA et distributeurs agréés des produits multimédia ;
 du suivi de l’exécution des clauses des contrats commerciaux liant

BTSA aux partenaires agréés pour la distribution des services
multimédia ;
 de l’organisation des travaux de collecte et de l’analyse des

données de ventes et autres informations de gestion ;
 de la préparation des statistiques mensuelles de la cellule.
 La Division Développement et Applications
Sous l’autorité du Directeur de l’Informatique et du Multimédia, la

Division Développement et Applications est chargée :
 des études et de la réalisation des projets informatiques de la

société (étude, conception, développement, tests de qualification,
intégration, etc.) ;
 de l’administration de toutes les bases de données de la société ;
 de la rédaction des cahiers de charges des applications

informatiques ;
 de la validation des schémas d’organisation des données de tout

projet informatique ;
 de l’exploitation quotidienne des applications informatiques ;
 de la rédaction et de la mise à jour des «guides utilisateurs».
Annexes
 La Division des Services Informatiques et Maintenance
Sous l’autorité du Directeur de l’Informatique et du Multimédia,

cette division est chargée :
 de la facturation de tous les produits de la société ;
 de l’assistance aux Services Régionaux des Télécommunications

(SRT) en cas de besoin dans les travaux d’impression des factures
et autres journaux de facturation ;
 de la fourniture aux utilisateurs de l’ensemble des services

permettant d’assurer la continuité et la qualité des équipements et
logiciels de base ;
 de la production informatique dans le respect des plannings et des

normes d’exploitation de qualité et de sécurité ;
 de l’élaboration des prévisions en consommables informatiques,

pièces de rechange, en équipements et systèmes d’exploitation ;
 de l’initiation des consultations préalables à tout achat de

consommables informatiques.
Annexes
ANNEXE B : Outils de sécurité
Les Systèmes de détection d’intrusion
Les systèmes de détection d’intrusion (ou encore IDS) permettent

de détecter de manière furtive les activités anormales ou suspectes et
permettent ainsi d'avoir une action de prévention sur les risques
d'intrusion en écoutant le trafic réseau.
Un IDS a quatre fonctions principales :
 l’analyse des journaux du système : elle permet d’identifier

des intentions dans la masse de données recueillies par
l’IDS ;
 la journalisation : il s’agit de l’enregistrement des

événements dans un fichier de log ;
 la gestion du système : le système doit être administré en

permanence afin de détecter le plus rapidement possible des
tentatives d’intrusion ;
 l’action : en cas de détection d’anomalie, l’IDS doit alerter

l’administrateur.
Il y a deux méthodes d’analyse ou de détection à savoir : l’analyse

par reconnaissance de signature ou encore l’analyse par scénario et la
détection d’anomalies encore appelée l’analyse par comportement :
- l’analyse par scénario : tout comme les antivirus qui utilisent

des bases de signature de virus pour effectuer leurs
détections, les IDS utilisent des bases de signatures
d'attaque pour détecter les intrusions. Il est aussi possible de
personnaliser cette base de signature, en rajoutant nos
propres règles. L'inconvénient de l'utilisation de signatures
Annexes
pour la détection des attaques est qu'il est nécessaire de

connaître toutes les différentes attaques possibles. Or ceci
pose problème pour les attaques nouvellement découvertes
.Il est donc important de mettre à jour ces bases de signature
très régulièrement. L'analyse par scénario peut aussi vérifier
la conformité des flux par rapport à leur utilisation normale
décrite dans les RFC (Request For Comment).
Par exemple, dans le cas d'un déni de service de type « Ping of

death », l'IDS remarque que l'on reçoit un paquet ICMP n'ayant pas une
taille conforme à la RFC et peut donc émettre une alerte. Il existe aussi
l'analyse heuristique, qui permet de générer une alarme quand le nombre
de sessions à destination d'un port donné dépasse un seuil dans un
intervalle de temps prédéfini.
- l’analyse par comportement : il existe aussi d'autres

méthodes de détections telles que l'analyse
comportementale, qui consiste à détecter les intrusions en
fonction des habitudes de l'utilisateur. Les habitudes des
utilisateurs peuvent être mesurées à l'aide de différentes
données comme la charge CPU, l'utilisation mémoire... Mais
cette technique est très contraignante car il faut enregistrer
toutes les habitudes des utilisateurs. De plus, elle n'est pas
très efficace car elle génère un grand nombre de faux positifs
dès que les utilisateurs modifient leurs habitudes d'utilisation.
Cependant, si un pirate attaque pendant la phase
d'apprentissage, son attaque ne sera alors jamais détectée
car elle sera considérée comme normale.
Annexes
Les systèmes de prévention d’intrusion
Les IPS, contrairement aux IDS classiques (sécurité passive),

constituent une sécurité active pour filtrer et bloquer les flux, ajoutant à
cela la défense proactive et la prévention des intrusions sur le
réseau/hôte. Avant toute action, une décision en temps réel est exécutée
(l’activité est comparée à un ensemble de règles). Si l'action est conforme
à l'ensemble de règles, la permission de l’exécuter sera accordée et
l'action sera exécutée. Si l'action est illégale (c'est-à-dire si le programme
demande des données ou veut les changer alors que cette action ne lui
est pas permise), une alarme est donnée. Dans la plupart des cas, les
autres détecteurs du réseau (ou une console centrale) en seront aussi
informés dans le but d’empêcher les autres ordinateurs d'ouvrir ou
d'exécuter des fichiers spécifiques.
Les IPS sont dotés des fonctionnalités ci-après:
- le comportement de l'application est analysé et noté (quelles données

sont normalement demandées, avec quels programmes elle interagit,
quelles ressources sont requises, etc.).
- lorsqu’une attaque est détectée, l’alerte peut aller d’une simple entrée
dans un journal à un blocage de ressources.
- l’interaction avec les équipements réseaux tels que : firewall, IDS, VPN,
anti-virus, anti-spam, etc.
- la surveillance du comportement d'application se rapproche des IDS

basés sur une application, c'est-à-dire que le comportement de
l'application est analysé et noté (quelles données sont normalement
demandées, avec quels programmes elle interagit, quelles ressources
sont requises, etc.).
Annexes
- la création de règles pour l'application : dérivé de la surveillance du

comportement d’application, cet ensemble de règles donne des
informations sur ce que peut faire ou non une application.
- la corrélation avec d'autres événements implique un partage

d'informations entre des senseurs coopératifs, afin de garantir une
meilleure protection contre les attaques.
Annexes
ANNEXE C : Stratégies dans une politique de

sécurité
La stratégie de sécurité détermine de façon générale les deux

dernières étapes que sont la procédure de sécurité ou le choix des
équipements à utiliser, et la mise en œuvre dès règles de sécurité au sein
des équipements choisis. Une fois cette étape définie, il faut ensuite
élaborer des stratégies de défense supplémentaires dans le seul objectif
de se protéger autant que possible des attaques. Il s’agit de la stratégie
proactive et de la stratégie réactive.
La stratégie proactive consiste à élaborer un plan de contingence,

ou Business Continuity Plan, visant à définir les actions à mettre en
œuvre en cas d’attaque réussie (Llorens et al., 2006). Ce plan définit
chaque tâche à exécuter, ainsi que le moment de son exécution et la
personne qui en a la charge. Il doit résoudre en outre le problème de la
restauration des données et peut inclure une contrainte de déplacement
du bien vers un autre lieu, en cas d’impact physique sur les locaux, par
exemple. Un tel plan doit faire l’objet d’exercices réguliers afin que le
personnel soit parfaitement préparé au moment où le plan devra être
réellement mis en œuvre (Llorens et al., 2006).
La stratégie réactive quant à elle définit les étapes à mettre

en œuvre après ou pendant un incident (Llorens et al., 2006). Elle
suppose que la stratégie proactive a échoué. Cette stratégie consiste tout
d’abord à analyser l’incident de sécurité afin de déterminer les dommages
causés, les techniques et outils d’attaque utilisés, etc. Il est primordial de
déterminer le plus vite possible l’étendue des dommages afin de décider
des actions d’urgence à entreprendre. Non moins importante est la
détermination des causes de l’incident par une analyse des traces
système (logs) et réseau laissées, par exemple, sur les pare-feu, mais
Annexes
aussi par la détection de signatures de programmes, de chevaux de Troie

ou de « rootkit », de zones utilisées comme nids par l’intrus, de virus ou
de vers, etc., sur les systèmes attaqués.
En cas d’intrusion, un test de pénétration peut être réalisé afin de

confirmer la faiblesse de sécurité exploitée par l’intrus. L’étape suivante
commence dés la fin de l’analyse post-mortem. Elle consiste à réparer les
dommages causés (Llorens et al., 2006). Elle vient nécessairement à la
fin de l’analyse de façon que la restauration des données affectées
n’écrase pas les traces de l’incident de sécurité. Cette logique est à
rapprocher de celle à l’œuvre dans les autopsies consécutives à des
affaires criminelles, lors desquelles les services de médecine médico-
légale ne sont pas autorisés à toucher au cadavre avant que les
enquêteurs aient fini l’investigation du lieu du crime (Llorens et al., 2006).
Les leçons apprises de l’incident de sécurité font l’objet d’un

rapport détaillé d’incident. Ce document détaille les aspects techniques
(dommages causés, moyens mis en œuvre, etc.) et analyse l’impact de
l’incident sur l’entreprise (baisse de productivité, fuite d’information,
données perdues, etc.). Ce rapport permet d’évaluer le coût financier de
l’incident de sécurité et d’améliorer les stratégies de réduction des
risques (Llorens et al., 2006). La mise en œuvre d’un plan de
contingence, s’il existe, peut être envisagée selon la criticité du bien
impacté. Si l’analyse post-mortem prend trop de temps, il peut être
nécessaire de démarrer un plan de contingence afin de résoudre la crise
le plus rapidement, même en mode dégradé (Llorens et al., 2006).
A ces deux stratégies, s’ajoutent d’autres stratégies de sécurité

régies par des principes définis. Ces dernières doivent être considérées
comme des briques à adapter afin de construire des stratégies
personnalisées. Il s’agit de (Llorens et al., 2006):
Annexes
 la stratégie d’authentification en profondeur : des contrôles

d’authentification doivent être mis en place afin d’authentifier
les accès aux périmètres de sécurité ;
 la stratégie du moindre privilège : chaque utilisateur ne
dispose que des privilèges dont il a besoin ;
 la stratégie de confidentialité des flux réseau : toute
communication inter-site transitant sur des réseaux publics
doit être chiffrée si elle contient des données confidentielles ;
 la stratégie de séparation des pouvoirs dont le principe est
de créer des entités séparées, chacune responsable de
zones de sécurité spécifiques du réseau d’entreprise ;
 la stratégie d’accès au réseau local : des contrôles d’accès
au sein d’un périmètre de sécurité doivent être définis afin de
contrôler les portes dérobées ;
 la stratégie d’administration sécurisée : la zone
d’administration est une zone dédiée et séparée du réseau
afin d’assurer une isolation des systèmes chargés de
l’administration de chaque périmètre de sécurité ;
 la stratégie antivirus : tout document numérique ou tout autre
vecteur de propagation de virus doit faire l’objet d’un contrôle
avant de pénétrer dans un périmètre de sécurité ;
 la stratégie de participation universelle : des campagnes
d’information et de sensibilisation à la sécurité doivent être
lancées afin de faire comprendre les risques que font peser
sur l’entreprise les menaces aussi bien extérieures
qu’intérieures ;
 la stratégie du contrôle régulier : l’application de la politique
de sécurité doit être validée par un contrôle de sécurité
régulier.
Annexes
ANNEXE D : Fonctionnalités des pare-feu
Filtrage des entrées de la carte réseau
Cette technique consiste à filtrer les paquets en fonction de leurs

adresses et ports, source et destination, de même que les protocoles
utilisés pour le trafic. Ce type de filtrage ne s’applique qu’aux trafics
entrants, et permet d’autoriser ou de rejeter les paquets conformes aux
règles de sécurité du firewall. Cependant, cette méthode offre peu de
sécurité, puisqu’un paquet apparemment normal peut avoir un contenu
malsain.
Translation d’adresses
L’augmentation exponentielle du nombre d’ordinateurs connectés à

Internet a rapidement conduit à une pénurie d’adresses IP. L’espace
d’adressage étant insuffisant, parce que chaque ordinateur connecté à
Internet devant disposer d’une adresse IP routable et unique, des
adresses dites privées ont été réservées afin de palier au problème. Ces
adresses n’étant pas routables sur Internet, elles peuvent donc être
utilisées sans problèmes par tous les réseaux privés. Cependant, au sein
d’un réseau utilisant ce type d’adressage, aucune machine ne pourra se
connecter à Internet si le besoin se fait ressentir. Pour remédier à ce
défaut, il a été établi un protocole qui effectue la translation des adresses
privées en adresses publiques : c’est le NAT. Le principe du NAT est de
modifier les adresses source ou destination selon le cas, avant de router
le paquet vers sa destination. Cette technologie offre un gain en sécurité,
puisque de l’extérieur toutes les machines du réseau sont vues
connectées derrière des adresses autres que celles qu’elles utilisent. Il
existe plusieurs variantes de NAT suivant la topologie du réseau privé, le
nombre de machines privées, le nombre d’adresses IP publiques et les
Annexes
besoins en termes de services, d’accessibilité et de visibilité de

l’extérieur. Ainsi, on distingue:
 le NAT statique : permet de faire correspondre de façon
automatique et bijective une adresse publique à une adresse
non routable. Le routeur effectuant cette opération contient
la table de correspondance des adresses. Cette translation
ne requiert aucune information liée à la connexion, et est
généralement utilisée pour les systèmes du réseau interne
qui doivent être joignables de l’extérieur (serveurs web, mail,
FTP, etc) (Llorens et al., 2006). La correspondance est alors
établie de n adresses IP privées vers n adresses publiques.
On parle également de NAT « un à un » (one-to-one).
 le NAT dynamique : le NAT statique ne résout toujours pas le
problème de la pénurie d’adresses. Il faut en effet, attribuer à
n adresses publiques n adresses privées. Le NAT
dynamique vient corriger ce défaut. Le réseau dispose de m
adresses publiques d’une part et de n adresses privées
d’autre part. La translation d’adresses est configurée de
façon à n’autoriser qu’au maximum m adresses privées à
accéder à Internet ; et ce jusqu’à un certain temps
d’inactivité. Les traductions dynamiques apparaissent
comme les traductions statiques dans la table des
traductions mais leur durée de vie est limitée.
Une autre variante du NAT dynamique, utilise juste une seule

adresse publique et s’avère très utile si le nombre d’adresses routables
est limité. Le routeur a cependant une tâche supplémentaire qui est de
pouvoir différencier les paquets destinés à chaque station du réseau ;
puisqu’elles partagent la même adresse IP (celle du routeur). Pour cela, il
devra garder en mémoire des paramètres de chacune des connexions
tels que l’adresse IP source, le protocole utilisé. Ces informations
Annexes
serviront à effectuer la correspondance dans les deux sens de la

communication et ne sont malheureusement pas assurées d’être unique
pour chaque connexion. Dans ce cas, lors de l’émission d’un paquet, la
passerelle effectue non seulement une translation d’adresses, mais aussi
une translation aléatoire de ports : on parle de NAT « un à plusieurs »
(one-to-many). Le routeur conserve alors dans une table, le couple
unique {adresse, port} pour effectuer la traduction (Bloch et Wolfhugel,
2007). Cette technique de translation est en fait le NAPT (Network
Address and Port Translation) encore appelé PAT (Port Address
Translation).
Annexes
ANNEXE E : Présentation de l’application
Au démarrage de l’application, apparaît un écran de connexion

(figure 36).
Figure 36 : Interface de connexion
Lorsque les informations d’authentification saisies sont correctes,

l’utilisateur accède à la page d’accueil (figure 37).
Figure 37 : Page
d’accueil du système
Cette page permet d’avoir une vue globale des fonctionnalités

qu’offre la plateforme. Elle est constituée, d’une barre de menu qui
spécifie l’ensemble des menus accessibles, de même qu’une zone de
travail. En choisissant de créer un nouveau réseau dans le menu
Annexes
‘’Fichier’’, on obtient un message indiquant que le réseau a été créé avec

succès (figure 38).
Figure 38 : Création d’un nouveau réseau
Ensuite, on peut passer à la configuration du réseau créé en

ajoutant les éléments qui le composent. Le système nous invite à
renseigner le nombre de sous-réseaux disponibles dans notre
architecture (figure 39).
Figure 39 : Création de zones dans l’architecture
Une fois ce nombre saisit, le système effectue une vérification pour

s’assurer de la validité du nombre ainsi saisi. Une nouvelle interface
apparaît et présente la liste des zones créés (figure 40) avec la possibilité
de modifier leurs attributs (figure 41).
Annexes
Figure 40 : Liste des zones créées
Annexes
Figure 41 : Modification des attributs des zones créées
Une fois les sous-réseaux ou zones créés, il faut ensuite définir la

liste des firewalls séparant ces différentes zones. Tout comme pour les
zones définies, le système demande le nombre de firewalls et effectue les
vérifications nécessaires sur le nombre saisi par l’utilisateur (figure 42).
Figure 42 : Création de firewalls dans l’architecture
Annexes
L’interface ensuite présentée (figure 43), liste tous les firewalls

créés. Elle permet d’éditer chacun des firewalls. L’utilisateur peut donc
renseigner pour chaque firewall : son nom, les zones qu’il interconnecte,
les firewalls auxquels il est relié de même que les règles de filtrage qu’il
définit (figure 44).
Figure 43 : Liste des firewalls créés
Annexes
Figure 44 : Modification des attributs des firewalls créés
Une fois tous les attributs des firewalls définis, le système

détermine automatiquement la liste de tous les chemins reliant les zones.
L’utilisateur n’a donc qu’à choisir ceux qui l’intéressent en supprimant les
chemins qu’il ne souhaite pas garder (figure 45).
Annexes
Figure 45 : Edition des chemins dans le réseau
Le réseau créé est alors complètement configuré et l’utilisateur

peut ensuite procéder aux audits des différents firewalls. Pour ce faire,
l’utilisateur sélectionne le type d’audit (intra-firewall ou inter-firewall) dans
le menu ‘’Audit’’. Ensuite, il choisit le(s) firewall(s) à analyser, et procède
à l’audit. Les résultats sont ensuite présentés et suivant l’anomalie
détectée, le système fait des suggestions à l’utilisateur pour les corriger
ou les supprimer.
Glossaire
Glossaire
ACK : Paquet d’acquittement envoyé à la suite d’un paquet SYN dans

une négociation TCP.
Chiffre : utilisation de la substitution au niveau des mots ou des phrases

pour coder.
Chiffrement : transformation à l'aide d'une clé d'un message en clair (dit

texte clair) en un message incompréhensible (dit texte chiffré) pour celui
qui ne dispose pas de la clé de déchiffrement (en anglais encryption).
Code : utilisation de la substitution au niveau des lettres pour coder.
Coder : action réalisé sur un texte lorsqu'on remplace un mot ou une

phrase par un autre mot, un nombre ou un symbole.
Cryptanalyse : science analysant les cryptogrammes en vue de les

décrypter.
Cryptogramme : message chiffré.
Cryptographie : étymologiquement « écriture secrète », devenue par

extension l'étude de cet art (donc aujourd'hui la science visant à créer
des cryptogrammes, c'est-à-dire à chiffrer).
Cryptolecte : jargon réservé à un groupe restreint de personnes désirant

dissimuler leur communication.
Cryptologie : science regroupant la cryptographie et la cryptanalyse.
Cryptosystème : algorithme de chiffrement.
Glossaire
Datagramme : unité de transmission de la couche réseau (par exemple

IP). Un datagramme peut être ensuite encapsulé dans un ou plusieurs
paquets transmis.
Décrypter : retrouver le message clair correspondant à un message

chiffré sans posséder la clé de déchiffrement (terme que ne possèdent
pas les anglophones, qui eux « cassent » des codes secrets)
Faux positif: se dit d’une alerte qui est générée par un IDS alors qu’il n’y
a réellement aucune tentative d’intrusion.
Faux négatif: se dit lorsque lorsqu’aucune alerte n’est générée en

présence d’une tentative d’intrusion.
Fichier logs: fichier destiné à contenir l’enregistrement séquentiel de

tous les événements affectant un processus particulier (application,
activité d’un réseau informatique). Il est généralement daté et classé par
ordre chronologique et permet d’analyser pas à pas l’activité interne du
processus et ses interactions avec son environnement.
Guides de sécurité : Il s’agit de documents détaillant comment

implémenter les politiques de sécurité. Ils sont considérés comme des
documents complémentaires aux politiques.
Port: les ports permettent habituellement d’identifier un certain processus

ou service sur un ordinateur. Lorsqu’un périphérique distant doit accéder
à un service spécifique sur un serveur, par exemple, il dirige ces données
vers un certain port qui identifie le type de service que le périphérique doit
utiliser.
Politiques de sécurité : Il s’agit de documents décrivant de manière

formelle des principes ou règles auxquelles se conforment les personnes
qui reçoivent un droit d’accès au capital technologique et informatif de
Glossaire
l’entreprise. Ces documents à caractère non technique donnent aux

responsables de l’entreprise les axes à suivre.
Procédures de sécurité : Il s’agit de documents à caractère opérationnel

et technique, qui décrivent de manière claire et précise les étapes à
suivre pour atteindre un objectif de sécurité donné.
Serveur : Système informatique, matériel ou logiciel, destiné à fournir

des services à des utilisateurs qui lui sont connectés.
Standards de sécurité : Il s’agit de documents de standardisation de

normes et méthodes émanant d’organismes internationaux tels que l’ISO
(International Standardization Organization), l’IETF (Internet Engineering
Task Force), l’IEEE (Institute of Electrical and Electronics Engineers), etc.
SYN : état de départ de l’établissement d’une connexion TCP.
Summary
SUMMARY
Topic
Evaluation of security policy quality

within stateful firewalls
Summary
Introduction
Security of Information System has grown into a major problem in

computing network. It is nowadays absolutely important to protect
networks against attacks coming not only from Internet, but also from the
inside of networks. This situation shows vulnerabilities of an Information
System. Formerly considered as a luxury strategy, systems security
seems to become an adequate means to restore trust inside computing
networks.
In order to fill this requirement, firewalls nowadays constitute the

main tools as far as systems security is concerned. Despite their variety,
they got the same objective: protect intrinsic network resources against
external attacks as well as attacks coming from ill-disposed internal
users. To this end, the security policy is translated into filtering rules
which are configured on the firewall. Until recently, most of routers
provide routing functionalities as well as filtering undesired traffics.
Nowadays, a new generation of firewalls seems to be indispensable by
virtue of connection tracking concept they induce. Despite this innovation,
it is sometimes frequent that stateful firewalls configurations induce
inconsistencies which inevitably affect the policy security quality and
efficiency. System integrity only relying on its policy security, it is
therefore essential to ensure that firewalls configurations are free of any
anomalies. On this basis, our project entitled Evaluation of policy security
quality within stateful firewall will attempt to find a solution to this issue.
In order to effectively solve this problematic, our document is

organized as follows: the first part mentions some generalities about
network security. Then, the second part focuses on the methodology we
use; and finally the third part presents the main results we strike on.
Summary
1. Project overview
1.1. Context
Firewalls are equipments which constitute core elements in network

security. They filter traffics based on:
 Informations of OSI network level;
 Informations of OSI transport level.
In order to be in accordance with the determined policy security,

sets of filtering rules are defined within firewalls. With the multiplicity of
attacks, the size of networks, the number of installed services, the order
of filtering rules, it is more difficult to suitably implement rules sets. A
mismanagement of security needs leads to an inappropriate
implementation of rules sets, which can generate anomalies. An anomaly
on the one hand reopens the question about the policy security efficiency
and on the other hand makes the system vulnerable because it can allow
traffic originally blocked, or block traffic originally allowed. It is therefore
crucial to detect these anomalies which are intra-firewall and inter-firewall
anomalies.
An intra-firewall policy anomaly is defined as the existence of two or

more filtering rules that may match the same packet or the existence of a
rule that can never match any packet on the network paths that cross the
firewall. An inter firewall policy anomaly on the contrary, may exist if any
two firewalls on a network path take different filtering actions on the same
traffic. The detection of those malfunctioning is based on a set of relations
existing among filtering rules. The vulnerability of a system, by virtue of
anomalies presence, stick of the fact that:
 Some rules can never match packets because they are

shadowed;
Summary
 Redundant rules add unnecessary overhead to the filtering

process.
In order to make sure about the system integrity and reliability, and
this permanently, some algorithms have been developed. Each of them is
based on a specific policy analysis approach. Al-Shaer and Hamed
(2004) proposed for instance, basing on a downward approach, an
anomaly detection algorithm which takes into account rules
representation in the form of tree and relations among filtering rules.
Alfaro, Boulahia-Cuppens and Cuppens (2007) lean on the other hand on
the upward approach to propose a solution. Within the context of our
project, we focus on the downward approach as analysis method, in order
to propose anomalies detection algorithms for state filtering functionality.
1.2. Objectives
The main objective of this project is guarantee an optimal security

level within a network, making sure that firewalls configurations are
faultless and actually reflect the specified policy security. To reach this
objective, we determine three specific objectives which are:
 Make the state of art as far as computing network security is

concerned ;
 Study and model stateful firewalls ;
 Develop and implement analysis algorithms for firewalls
configurations.
2. Network security policy
Setting up security within a system is a task which requires

precautions. Deploying last security tools without any preliminary thought
cannot neither solve security issues nor secure the entire critical elements
inside the enterprise. It is therefore essential to define a policy before
Summary
choosing architecture, security tools and procedures to be deployed in

order to protect critical resources.
Information system security policy is a confidential document, of a

non-technical nature, which provide a set of rules and principles put in
thematic order in accordance with enterprise security needs. The network
theme in a security policy includes requirements for equipments and
network link exploitation. The definition of a security policy is performed in
four steps which are listed as follows:
 The delimitation of a security perimeter;

 The determination of the critical resources;
 The identification of specific objectives referred to the system
security;
 The risks analysis and management.
There is a step after the security policy elaboration step which is

the selection of the security strategy or procedure. This step aimed to
implement security controls intended for the system protection. There are
many ways to enforce security inside a network. Firewalls are indeed the
most used solution to date. A firewall is a physical or logical device which
is used as intermediary for a network access, allowing or blocking traffics
referred to a security policy defined by the network administrator. They
are different classes of firewalls which are stateless firewall, stateful
firewall, and application gateway firewall. The effectiveness of security
policy on a firewall is made through filtering rules. However, it is a
complex and error prone task in so far as anomalies will fit into the rules
configurations if they are not properly defined. Those anomalies question
about logic among filtering rules and undermine system integrity. Many
anomalies can be detected such as shadowing, redundancy, irrelevance,
generalization, correlation and misconnection anomalies.
Summary
3. Materials and methods
On Linux, packet processing is performed by the network

subsystem at core level. Actually, functionality at core level is added to
this subsystem with a user interface to parametrize the desired filtering
process. This functionality is implemented by Netfilter, but the user
interface used to configure (in Command Lines Interface) Netfilter is
Iptables.
Every packet analyzed by Netfilter pass through predefined tables.

Each of them is dedicated to a particular type of activity and is controlled
by an associated chain which role is to transform or filter packet.
3.1. Upward approach
In fact, this approach is an analytical one because it enables

analysis of existing configurations on security components such as
firewalls, Intrusion Detection System (IDS), Intrusion Prevention System
(IPS). This approach also enables determination of relations among
filtering rules in the aim of detecting possible configurations anomalies.
This method generally implements algorithms for filtering rules rewriting
by the removal of noticed inconsistencies. These algorithms, most of the
time, are based on the network modeling, bringing out zones,
components and paths concepts. The upward approach is therefore
propitious to surroundings where a security policy already exists,
components are configured, and configurations audit is in great request.
3.2. Technical choices
To implement firewall surroundings, we use Iptables, whose one of

large functionalities is state tracking. According to security policy
requirements, filtering rules are written strictly using the syntax of
Iptables. Afterwards, in order to analyze the configurations of security
components, we use the upward approach. From this analysis, we will
Summary
implement algorithms to audit firewalls rules set. These algorithms will

then be implemented in a system to detect and remove any anomalies.
But before this step, we will model the system thanks to UML (Unified
Modeling Language) flowcharts.
Conclusion and outlook
Evaluation of security policy quality within stateful firewalls has

been the subject of our study. This topic allows us to propose audit
algorithms for stateful firewalls rules set.
For this purpose, we first define specific network architecture.

Afterwards, we use upward approach as methodology for firewall rules
set analysis. This approach, unlike the downward approach, allows us to
better understand the process of security policy analysis. Thus, we
propose algorithms to detect and remove different types of anomalies
which can harm the system integrity. A preliminary work leads us to
identify possible relationships among filtering rules. After defining the
requirements of the system, we then implement our algorithms.
The system we designed brings out some weaknesses which

should be taken into account to improve the system efficiency. Our
system should fit the diversity of security components deployed in a
network. Our project opens up new horizons for some new extensions of
our study scope to other firewalls functionalities, just as different network
security devices groups.
Table des matières
Table des matières

SOMMAIRE .................................................................................................................... I
DEDICACES .................................................................................................................. III
REMERCIEMENTS ........................................................................................................IV
LISTE DES SIGLES ET ACRONYMES ...............................................................................VI
LISTE DES FIGURES ....................................................................................................... IX
LISTE DES TABLEAUX ................................................................................................... XI
RESUME ...................................................................................................................... XII
ABSTRACT .................................................................................................................. XIII
INTRODUCTION GENERALE .......................................................................................... 1
1. CONTEXTE, JUSTIFICATION ET PROBLEMATIQUE.................................................................. 2

1.1. Contexte et justification .............................................................................. 2
1.2. Problématique ............................................................................................ 3
2. OBJECTIFS ................................................................................................................ 4
PARTIE 1 ....................................................................................................................... 6
CHAPITRE 1 ................................................................................................................... 7
LA SECURITE INFORMATIQUE ....................................................................................... 7
1.1. Définition de la sécurité informatique ......................................................... 8

1.2. Objectifs de la sécurité ................................................................................ 9
1.3. Principales menaces à la sécurité informatique ......................................... 10
1.4. Principaux outils de sécurité ..................................................................... 16
CHAPITRE 2 ................................................................................................................. 20
GESTION DE LA POLITIQUE DE SECURITE AU SEIN D’UN RESEAU ............................... 20
2.1. La politique de sécurité au sein d’un réseau .............................................. 21

2.1.1 Définition................................................................................................... 21
2.1.2 Objectifs .................................................................................................... 23
Table des matières
2.2. Périmètre de sécurité................................................................................ 26

2.3. Analyse des risques ................................................................................... 26
2.4. Stratégie de sécurité ................................................................................. 28
CHAPITRE 3 ................................................................................................................. 31
ETAT DE L’ART SUR LES FIREWALLS ............................................................................ 31
3.1. Historique et terminologie sur les firewalls ............................................... 32

3.2. Définition et rôle des firewalls .................................................................. 33
3.3. Fonctionnalités spécifiques des firewalls ................................................... 36
3.4. Catégories de firewalls .............................................................................. 37
3.4.1 Les firewalls sans états ou stateless ........................................................... 37
3.4.2 Les firewalls à états ou stateful .................................................................. 39
3.4.3 Firewall applicatif ...................................................................................... 41
3.4.4 Firewall réseau applicatif ........................................................................... 42
3.5. Architecture des firewalls.......................................................................... 46
3.5.1 Firewall avec routeur de filtrage ................................................................ 46
3.5.2 Architecture en DMZ ................................................................................. 47
3.5.3 Architecture de type proxy ........................................................................ 50
3.5.4 Architecture mixte en proxy et DMZ .......................................................... 51
3.6. Atouts et faiblesses des firewalls ............................................................... 52
3.7. Anomalies liées à la configuration des firewalls......................................... 53
3.7.1 Relations entre les règles de filtrage .......................................................... 54
3.7.2 Anomalies intra-firewall ............................................................................. 57
3.7.3 Anomalie inter-firewall .............................................................................. 60
PARTIE 2 ..................................................................................................................... 66
APPROCHE METHODOLOGIQUE ................................................................................. 66
CHAPITRE 4 ................................................................................................................. 67
APPROCHE D’ANALYSE DES FIREWALLS A ETATS........................................................ 67
4.1. Présentation du cadre de stage ................................................................. 68

4.2. Modèle d’étude des firewalls : cas d’Iptables ............................................ 68
4.1.1 Description ................................................................................................ 68
Table des matières
4.1.2 Machine d’état .......................................................................................... 73

4.3. Méthode d’analyse des firewalls ............................................................... 74
4.2.1 Approche descendante .............................................................................. 74
4.2.2 Approche ascendante ................................................................................ 75
4.4. Outils de développement et de modélisation ............................................ 75
CHAPITRE 5 ................................................................................................................. 77
ARCHITECTURE RESEAU .............................................................................................. 77
5.1. Services réseau disponibles ....................................................................... 78

5.2. Architecture choisie .................................................................................. 78
5.2.1 Topologie du réseau .................................................................................. 78
5.2.2 Politique de sécurité et plan d’adressage ................................................... 81
5.3. Configuration des équipements ................................................................ 84
CHAPITRE 6 ................................................................................................................. 91
SPECIFICATION DES BESOINS DU SYSTEME ET ETUDE CONCEPTUELLE ....................... 91
6.1. Diagramme de cas d’utilisation ................................................................. 92

6.1.1 Acteurs ...................................................................................................... 92
6.1.2 Spécification des besoins ........................................................................... 92
6.1.2.1. Spécifications fonctionnelles ................................................................. 93
6.1.2.2. Spécifications non-fonctionnelles .......................................................... 94
6.1.3 Diagramme de cas d’utilisation .................................................................. 94
6.2. Diagramme de séquence ......................................................................... 100
6.3. Diagramme de classes ............................................................................. 103
PARTIE 3 ................................................................................................................... 105
RESULTATS ET DISCUSSIONS .................................................................................... 105
CHAPITRE 7 ............................................................................................................... 106
RESULTATS ............................................................................................................... 106
CHAPITRE 8 ............................................................................................................... 125
DISCUSSIONS ............................................................................................................ 125
Table des matières
CONCLUSION ET PERSPECTIVES ................................................................................ 129
REFERENCES BIBLIOGRAPHIQUES ............................................................................. 131
ANNEXES .................................................................................................................. 135
GLOSSAIRE................................................................................................................ 160
SUMMARY ................................................................................................................ 163
1. PROJECT OVERVIEW ................................................................................................ 165

1.1. Context ................................................................................................... 165
1.2. Objectives ............................................................................................... 166
2. NETWORK SECURITY POLICY ...................................................................................... 166
3. MATERIALS AND METHODS....................................................................................... 168
3.1. Upward approach ................................................................................... 168
3.2. Technical choices .................................................................................... 168
TABLE DES MATIERES ............................................................................................... 170

Mémoire TABE Phot-Antou Léocady Prosper - Compressed

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mémoire TABE Phot-Antou Léocady Prosper - Compressed

Transféré par

Droits d'auteur :

Formats disponibles

RÉPUBLIQUE DU BÉNIN

M I NI ST ERE DE L’ ENSEI G NEM ENT SUP ERI EUR

UNI VERSIT É D’ ABO MEY -CAL AVI (U AC)

ECOLE POLYT ECHNIQUE D’ ABO MEY -CAL AVI (EPAC)

Option : Réseaux Informatiques et Internet (RII)

AMELIORATION DE LA QUALITE DES

Tuteur de stage : Supervisé par :

Année Académique : 2010-2011

DEDICACES .................................................................................................................. III

LISTE DES SIGLES ET ACRONYMES ...............................................................................VI

LISTE DES FIGURES ....................................................................................................... IX

LISTE DES TABLEAUX ................................................................................................... XI

RESUME ...................................................................................................................... XII

ABSTRACT .................................................................................................................. XIII

INTRODUCTION GENERALE .......................................................................................... 1

PARTIE 1 : POLITIQUE DE SECURITE DANS LE RESEAU .................................................. 6

CHAPITRE 1 : LA SECURITE INFORMATIQUE ................................................................. 7

CHAPITRE 2 : GESTION DE LA POLITIQUE DE SECURITE AU SEIN D’UN RESEAU .......... 20

CHAPITRE 3 : ETAT DE L’ART SUR LES FIREWALLS ....................................................... 31

PARTIE 2 : APPROCHE METHODOLOGIQUE ................................................................ 66

CHAPITRE 4 : APPROCHE D’ANALYSE DES FIREWALLS A ETATS .................................. 67

CHAPITRE 5 : ARCHITECTURE RESEAU ........................................................................ 77

CHAPITRE 6 : SPECIFICATION DES BESOINS DU SYSTEME ET ETUDE CONCEPTUELLE . 91

PARTIE 3 : RESULTATS ET DISCUSSIONS ................................................................... 105

CHAPITRE 7 : RESULTATS .......................................................................................... 106

CHAPITRE 8 : DISCUSSIONS ...................................................................................... 125

CONCLUSION ET PERSPECTIVES ................................................................................ 129

REFERENCES BIBLIOGRAPHIQUES ............................................................................. 131

ANNEXES .................................................................................................................. 135

SUMMARY ................................................................................................................ 163

TABLE DES MATIERES ............................................................................................... 170

 A mon feu père Patrice TABE DANGOU. Regarde de là où tu es

 A ma mère Justine SOSSOU. Merci maman pour tous les

Je rends grâce à Dieu, Eternel Miséricordieux, pour toutes les

Je remercie également tous ceux qui de près ou de loin ont

 Pr. Félicien AVLESSI et Dr. BONOU Clément respectivement

 Dr Sèmiyou A. ADEDJOUMA notre chef département ;

 Notre maître de mémoire M. Léonard MONTEIRO pour avoir

 Tous les enseignants des départements GE et GIT ;

 M. Franck KOUYAMI responsable technique du Campus

 M. Aurel GUIDI, M. Vivien ASSANGBE, pour m’avoir accepté

 A mon frère Phtanite, son épouse Brigitte, et à mon adorable

 A ma bien-aimée Bérénice ASSOGBA pour tout l’amour,

 Mes aînés Boris et Victor pour leurs précieux conseils ;

 Toute ma famille : mes tantes, oncles, cousins et cousines ;

 Mes meilleurs amis que je considère comme mes frères Anne,

 Cathia, Dorine, Brice, John, Wilfried et Armel ASSOGBA, pour

 Les membres fondateurs de la Technology Business

 Mes promotionnaires pour les bons moments passés ensemble.

Liste des sigles et acronymes

ACL: Access Control List

AES: Advanced Encryption Standard

ARP: Address Resolution Protocol

BGP: Border Gateway Protocol

BIOS: Basic Input Output System

DDoS: Distributed Denial of Service

DES: Data Encryption Standard

DMZ: DeMilitarize Zone

DNS: Domain Name Service

DoS: Denial of Service

FTP: File Transfer Protocol

GRE: Generic Routing Encapsulation

HIDS: Host Intrusion Detection System