Boky Finale
Boky Finale
Boky Finale
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 :
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 à :
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.
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.
2
CURRICULUM VITAE
ANDRIANTAVISON Dina
21 Juin 1989 à Fianarantsoa
Malagasy
Célibataire
dina.andriantavison@gmail.com
Formations et Diplômes
Baccalauréat Série ES
3
Expériences professionnelles
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 »
Stage ayant pour thème: « Mise en place et sécurisation d’un serveur de journalisation
informatique avec ‘SYSLOG-NG’. »
Réalisation d’un projet ayant pour thème : « Conception et Mise en place d’un réseau local avec
stratégies de communication. »
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»
Formation « Leadership »
Réalisation d’un projet ayant pour thème « Installation et configuration d’un réseau sans fil en
mode Ad hoc »
4
Compétences linguistiques
Compétences informatiques
Disciplines Niveau
Administration Réseaux 3
Administration Systèmes 3
Centres d’intérêts
Divers
5
SOMMAIRE
REMERCIEMENTS ................................................................................................................................. 1
SOMMAIRE ........................................................................................................................................... 6
INTRODUCTION .................................................................................................................................. 17
I.6 Partenariat.............................................................................................................................. 24
6
II.2.1 Mission et responsabilité de TELMA ............................................................................ 28
II.3.1 Effectifs......................................................................................................................... 33
I.1 Étymologie.............................................................................................................................. 37
I.5.1 Définition...................................................................................................................... 40
7
II.2.2 La nécessité d’un WAF au sein d’une entreprise ......................................................... 46
8
II.1 Installations ............................................................................................................................ 62
CONCLUSION ...................................................................................................................................... 87
GLOSSAIRE .......................................................................................................................................... 97
9
Annexe 5 : Code source de la page « test.php ».............................................................................. 114
10
LISTE DES ACRONYMES
11
24- IDS : Intrusion Detection System
12
49- VSAT: Very Small Aperture Terminal
13
LISTE DES FIGURES
Figure 7: Classement des 5 attaques les plus fréquentes sur le Web ............................................... 45
14
Figure 24: Capture d'écran du résultat de l'attaque avec ModSecurity actif .................................... 75
Figure 32: Capture d'écran du résultat de l'attaque FILE_INJECTION sans ModSecurity ................. 83
15
LISTE DES TABLEAUX
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 :
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
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.
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.
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 voyages d’études sont effectués par les étudiants nouvellement inscrits et ayant passé
une année d’études à 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.
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 :
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.
23
I.6 Partenariat
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).
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.
Création à l’Ecole d’une Unité de Production Multimédia, d’un club de logiciel libre.
25
II. PRESENTATION DU GROUPE TELMA
1971 : L’Etat malgache et France Câble Radio créent Stimad pour gérer les appels
internationaux
1995 : Création de la société DTS par TELMA et France Câble Radio (FCR) :
Avènement de l’internet à Madagascar
26
2007 : Lancement du GPRS/EDGE : TELMA met en place les infrastructures pour le
SDSL
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.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.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.
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 :
Le GSM fixe
Les SMS/MMS
L’internet mobile
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 :
OUTILS DESCRIPTION
30
RBS Billings Internet
31
TAG IP[26] Véhicule tracking (géo localisation)
Par une politique de baisse des prix adaptée aux besoins de la population.
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
Amélioration de l'efficacité de la prise de décision permise par une veille stratégique plus
performante.
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.
La Direction Générale
Le pôle technique
34
II.3.3 Organigramme de la direction d’accueil
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.
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.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 :
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
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) :
EN-TETE : Valeur<crlf>
...
EN-TETE : Valeur<crlf>
Ligne vide<crlf>
CORPS DE LA REQUETE
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 ».
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).
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.
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.
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.
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
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)
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
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.
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.
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.
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.
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.
46
II.3.2.1 Modsecurity (Trustwave labs)
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.
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
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
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
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.
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
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.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.
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
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.
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.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 :
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.
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.
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.
Violations des règles du protocole HTTP (ex : encodage d’une requête forgée) ;
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.) ;
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 ;
Interception de messages d’erreur trop explicites renvoyés par le serveur (ex : erreurs SQL
ou PHP);
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.
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.
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.1 Machine A
Type : Serveur
I.3.1.2 Machine B
Type : Serveur
58
I.3.1.3 Machine C
Type : Proxy
I.3.1.4 Machine D
Type : Desktop
59
Machine C : Firewall d’Application Web
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.
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.
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.
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 :
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 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.
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 :
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
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:
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.
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:
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
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 :
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 :
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
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.
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
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.
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 :
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.
73
Serveur DNS
Ligne de commande :
# curl -i http://www.url.com –A Nessus 2
3
1
Client Serveur d’application
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
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.
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.
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 :
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.
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 :
http://www.python.org/ftp/python/2.7/python-2.7.amd64.msi
76
Après l’installation on obtient les fichiers ci-dessous :
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 :
77
Nous pouvons observer l’exécutable de sqlmap qui est un fichier python possédant
l’extension.py.
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 :
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.
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 :
Enfin, il ne nous reste plus qu’à cliquer sur le bouton « Exploit ! » et voir les résultats
ensuite.
III.1.3.2 Résultats
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:
79
III.1.3.2.2 Avec modsecurity
Nous pouvons voir ci-dessous une ligne de log, résultante d’une attaque effectuée par
sqlmap :
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.1 Exemple
Pour illustrer la chose, prenons en exemple un fichier PHP simple nommé test.php :
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
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.
Sur le navigateur :
http://stgdina.test.mg/ 2
test.php?secret_file=/etc/passwd 3
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.
http://stgdina.test.mg/ test.php?secret_file=/etc/passwd
82
III.1.4.3 Résultats
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.
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.
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
85
DOSPageCount 2
DOSPageInterval 1
DOSSiteCount 150
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSLogDir "/var/lock/mod_evasive"
</IfModule>
# mkdir -p /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
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.
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
« 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
« 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
« Optimiser et sécuriser son trafic IP » - Edition EYROLLES - Francis IA & Olivier MENAGER
(2004).
Référence: DEUXIEME PARTIE: ETUDE THEORIQUE DU PROJET -> II. LES FIREWALLS
D’APPLICATIONS WEB (WAF) -> A. OWASP – p.43
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
89
REFERENCES WEBOGRAPHIQUE
https://fr.wikipedia.org/wiki/Liste_de_pare-feu
http://ftp.traduc.org/doc-vf/HOWTO/telechargement/pdf/
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
http://samsclass.info/124/proj11/p16-mod-security.html
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
http://www.akamai.fr/enfr/html/solutions/waf.html
http://www.citrix.com/products/netscaler-application-firewall/overview.html
http://www.cyberciti.biz/faq/rhel-fedora-centos-httpd-mod_security-configuration/
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/
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/
http://www.imperva.com/products/wsc_web-application-firewall.html
http://www.isalo.org/wiki.debian-fr/S%C3%A9curiser_Apache2
91
http://www.linuxquestions.org/questions/linux-security-4/mod_security-with-crs-
adjustments-to-capture-php-post-sql-injection-attempts-821531/
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
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
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
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
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
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
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…
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.
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.
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
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.
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.
101
Annexe 2 : Contenu du fichier de
configuration de ModSecurity
# -- Ruleengineinitialization ----------------------------------------------
# disruption.
SecRuleEngineOn
SecRequestBodyAccess On
102
SecRuleREQUEST_HEADERS:Content-Type "text/xml" \
"id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
# 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
SecRequestBodyInMemoryLimit 131072
# disruptionswheninitiallydeployingModSecurity.
SecRequestBodyLimitActionReject
103
# Verifythatwe'vecorrectlyprocessed the request body.
status:400,msg:'Failed to parserequest
body.',logdata:'%{reqbody_error_msg}',severity:2"
# _not_ to removeitaltogether.
"id:'200002',phase:2,t:none,log,deny,status:400, \
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?
# PCRE Tuning
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000
"id:'200004',phase:2,t:none,deny,msg:'ModSecurity internalerrorflagged:
%{MATCHED_VAR_NAME}'"
105
# You should have this directive enabled in order to identifyerrors
SecResponseBodyAccess On
SecResponseBodyLimit 524288
SecResponseBodyLimitActionProcessPartial
106
# The location whereModSecurity stores temporary files (for example, when
SecTmpDir /tmp/
# tooshouldbeupdated to a placethatotheruserscan'taccess.
SecDataDir /tmp/
#SecUploadDir /opt/modsecurity/var/upload/
107
#
#SecUploadKeepFilesRelevantOnly
#SecUploadFileMode 0600
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3
# levelresponsestatus codes).
SecAuditEngineRelevantOnly
108
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
# Use a single file for logging. This ismucheasier to look at, but
SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log
#SecAuditLogType Concurrent
#SecAuditLogStorageDir /opt/modsecurity/var/audit/
# -- Miscellaneous -----------------------------------------------------------
SecArgumentSeparator&
109
# Settle on version 0 (zero) cookies, as thatiswhatmost applications
SecCookieFormat 0
#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
SecFilter /tmp/
SecFilter /etc/passwd
SecFilter /bin/ls
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...):
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:
Exiger une longueur exacte du corps du message pour chaque requête POST:
SecFilterSelectiveHTTP_Content-Length ^$
SecFilter "\.\./"
112
Annexe 4 : Code source de la page
« sql_inj.php »
<? php
if (isset($_GET['id'])) {
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 {
?>
113
Annexe 5 : Code source de la page
« test.php »
<? php
include( $secret_file);
?>
114
Annexe 6 : Code source de la page
« Index.html » personnalisée
<html>
<body bgcolor="F0CC33">
<imgsrc="logo_telma.gif">
<p>The web server software is running but no content has been added, yet.</p></font>
</body>
</html>
115
RESUME
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é.
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