Projet de Fin d’Etudes

Pour l’Obtention Du Diplôme D’Ingénieur D’Etat

Spécialité : Sécurité réseaux

Réalisé au sein de : Intelcom Satec Groupe

Période de stage   : Du 20/02/2012 Au 20/06/2012

Présenté le   30 /06/2012  Devant le Jury composé de :

Mr Y. Mehdaoui

Mr S. Bennani

Mr M. Alfidi

Année Universitaire : 2011/ 2012

SUJET

Mise en place d’une maquette de test à base d’un WAF OpenSource et deux applications WEB(PHP,J2EE)

Réalisé

par :Nasredi

ne Boujmil

Encadré

par :

Mr

Hass

an

Chai

b

Mr

Youn

ess

Université Sidi Mohammed Ben AbdellahEcole Nationale des Sciences Appliquées – Fès

Filière : Réseaux et télécoms

U.S.M.B.A

Dédicaces

Je dédie ce modeste travail :

A mes très chers parents

Rien ne pourra exprimer ma gratitude, mon respect, et mon amour éternel pour tous les sacrifices que vous avez consenti

pour mon éducation et pour mon bien être. Trouvez en ce travail l’expression de mon profond amour.

A mon frère et à ma sœur

A toute ma grande famille ….

Je vous aime tous

Nasredine Boujmil

Remerciements

e tiens à remercier toute personne m’ayant aidé à illuminer le chemin au cours de ma période de formation et surtout mon présent Projet de Fin d’Etudes. Et bien que ça ne soit l’évidence qui le dicte, je tiens à

rendre grâce au corps professoral de l’Ecole Nationale des Sciences Appliquées de Fès pour les efforts fournis afin de garantir le bon déroulement de la formation.

JBien plus, j’adresse avec tout le respect et l’estime que cela se doit

de requérir, mes remerciements au personnel de la société Intelcom, et à leur tête évidemment Mr. Bahaa-dine Tagmouti qui m’a fournis la possibilité d’intégrer cette société et de réaliser ce projet de fin d’études. Encore, faudrait-il que je remercie sincèrement Mr. Najib Bazza pour son apport et son assistance, ses conseils précieux avant qu’il céda sa place à Mr. Hassan Chaib qui n’a épargné aucun effort à m’aider tout au long la période du stage et qui, grâce à sa cordialité et à son esprit ouvert m’a permis de m’intégrer pleinement dans les spécificités du cahier de charges demandé, sans pour autant me sentir dépaysé. Je tiens à remercier également Mme Elammari , M.Wadie Haddad , M. Wafae essafar et tout le personnel d’Intelcom pour leur sympathie , leur hypergentiellesse et leur aide .

Mon Professeur Mr Youness Mehdaoui de m’avoir encadré tout le long de l’élaboration du présent projet.

Je tiens à exprimer ma gratitude au directeur de L’Ecole Nationale des Sciences Appliquées de Fès et Monsieur le Vice-président, et les professeurs qui ont accepté d’être présents pour m’avoir honoré en acceptant de juger mon travail. Veuillez trouver ici le témoignage de mon respect le plus profond.

Enfin, je remercie l’ensemble des stagiaires pour la bonne ambiance qu’ils ont établie tout au long la période du stage

Résumé

a 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 aller à affirmer que la gestion de sécurité est désormais un souci majeur et quotidien du gestionnaire du réseau de l’entreprise et parmi les projets qui préoccupent un gérant d’une telle société.

LDe nombreuses études publiques, comme celle de la communauté OWASP2, 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 « frameworks3» 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)1 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’un 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 d’une entreprise sur une maquette de test basée sur le développement et l’implémentation de deux applications Web ( à 3 tiers) avec deux langages différents(PHP5,J2EE à savoir la technologie JSP mariée avec le modèle MVC) pour l’évaluation du produit.

1 WAF : Web Application Firewall 2 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.3 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)

4 Un test d'intrusion, pentesting est une méthode d'évaluation de la sécurité d'un système informatique ou réseau en simulant une attaque de l'extérieur

Abstract

anagement of information security in any company whatever its size has become essential as well as managing its own network. We can even go to say that security management is now a major

and daily concern of each network’s manager. Many public studies, such as the community OWASP2 show that the vast majority of vulnerabilities rely on the applications used in development. Also, these vulnerabilities are caused mostly by the specific code applications, more than "frameworks3" 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, Web Application Firewalls (WAF)1 has emerged, with the ambition to meet these new challenges.

M

The primary objective of this work is to study and make a platform for an open source firewall against application intrusions in order to detect in real time any attack threatening the numeric heritage of a company and it will be by the development of two applications with two different languages (PHP5, J2EE by implementing JSP technology in MVC model) and to establish a model for the pentesting4

1 WAF : Web Application Firewall 2 OWASP (Open Web Application Security Project) is a community working on web application

security. His philosophy is to be both free and open to all.3 Framework is a set of software components, structural, used to create the foundations and

outlines of all or part of a software (architecture)

4 Pentesting is a method for evaluating the security of a computer system or network by simulating an attack from outside

ملخص

شبكتها مرتبة بنفس ضروريا حجمها كان مهما شركة أي في المعلومات أمن إدارة أصبحتالخاصة.

شبكة مدير عند يوميا كبير قلق مصدر أصبحت األمن إدارة بأن القول حتى نذهب أن يمكننامثل. العامة، الدراسات من العديد ابرزت نقاط OWASP2الشركة من العظمى الغالبية أن

. الخاصة، البرمجية بالتطبيقات خاصة التطبيقات هاته تكون ما ايضا للتطبيق أوامر هي الضعفمن .frameworks3أكثر لتطويرها المستخدمة

هذه ضد جدا فعالة ليست لألسف النارية الجدران مثل التقليدية التكنولوجيات اصبحتالتطبيق مستوى على النارية الهجمات الجدران من جديد جيل ب فظهر ،(WAF)1مسمى

. الجديدة التحديات هذه لمواجهة طموح ينتابه

للمصادر ينتمي حماية جدار الختبار مثال وتقديم دراسة هو العمل هذا من الرئيسي الهدفالحقيقي الوقت في للكشف الخبيثة التطبيقات ضد التراث المفتوحة يهدد هجوم أي على

وسوف لالمعلوماتي ) الشركة تطبيقين بتطوير العمل هذا خالل من من( PHP5,J2EEنقومالختبار نموذج ووضع ، مخلفتين pentesting4لغتين

1 WAF : Web Application Firewall ويب حماية تطبيق جدار2 OWASP (Open Web Application Security Project) على مجتمع هو الويب أمن يعمل تطبيقات .يكون فلسفته أن لل مجاني كالهما هو جميعومفتوح .

3 Framework جزء او لبرنامج العريضة والخطوط األسس لخلق وتستخدم والهيكلية، البرمجية المكونات من مجموعة هيمنه

4 Pentesting الخارج من ومحاكاته عام هجوم خالل من شبكة أو كمبيوتر نظام أمن لتقييم وسيلة هو

TABLE DES MATIÈRES

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

1. Problématique....................................................................................12. Cahier de charges..............................................................................13. Organisation du projet.......................................................................2

4. Conclusion........................................................................................3

II. PRESENTATION DE L’ORGANISME D’ACCUEIL.......................4

1.1. Présentation....................................................................................4

1.2. Mission, valeurs et stratégies.........................................................4

1.3. Les secteurs d’activité....................................................................5

1.4. Organigramme d’Intelcom..............................................................5

Chapitre 1 : Description technique du projet

I. LES FIREWALLS APPLICATIFS..............................................8

1. Préliminaires......................................................................................81.1. Qu’est une application Web ?.........................................................8

1.2. Le protocole http/https...................................................................9

1.3. Le protocole DNS..........................................................................11

1.4. Bilan de la première partie...........................................................11

1.5. Qu’est-ce qu’un firewall ?.............................................................12

2. Les firewalls applicatifs (Web Application Firewall)..........................122.1. Qu’est-ce qu’un firewall applicatif................................................13

2.2. Les solutions Open-source existantes...........................................13

2.3. Fiche technique sur Modsecurity..................................................18

II. FICHE TECHNIQUE SUR LES APPLICATIONS WEB.................20

1. Environnement du travail.................................................................201.1. Fiche technique sur le serveur Web..............................................20

1.2. Le site Web intranet......................................................................22

1.3. L’application de gestion des utilisateurs du site en JEE................22

2. Les attaques Web les plus courantes...............................................242.1. SQL injection.................................................................................26

2.2. Attaque XSS..................................................................................26

2.3. Violation de contrôle d’accès........................................................26

2.4. Traitements inappropriés d’erreurs..............................................26

2.5. Directory Traversal.......................................................................27

2.6. Dénis de service (DoS)..................................................................27

3. Conclusion.......................................................................................27III. LA JOURNALISATION.........................................................28

1. Les fichiers logs de Modsecurity......................................................282. Fiche technique sur La console d’audit............................................283. Conclusion.......................................................................................30

IV. L’AUDIT SECURITE............................................................31

1. Qu’est-ce que W3AF ?......................................................................312. Origine du projet..............................................................................32

2.1. Samurai........................................................................................32

3. W3AF et ses possibilités...................................................................334. Conclusion.......................................................................................35

Chapitre 2 : Mise en place de la maquette de test

I. MISE EN PLACE DE LA MAQUETTE DE TEST.........................37

1. Environnement du travail.................................................................371.1. Mise en place du site intranet.......................................................37

1.2. Le site Web...................................................................................40

1.3. L’application JEE...........................................................................42

1.4. Mise en place de Modsecurity.......................................................44

2. Simulation d’attaques en présence et en absence du WAF.............472.1.Injection SQL....................................................................................472.2.Attaques XSS...................................................................................512.3.File Uploading..................................................................................522.4.Directory Traversal..........................................................................533. La console d’audit............................................................................554. L’audit sécurité................................................................................61

CONCLUSION GENERALE...................................................67

Perspectives.............................................................................68

Références et bibliographie.......................................................69

Annexes..........................................................................70

Annexe A :................................................................................70

Annexe B:.................................................................................70

Annexe C:.................................................................................71

Annexe D:.................................................................................72

TABLE DES FIGURES

FIGURE II-1 DIAGRAMME DE GANTT PAR MICROSOFT PROJECT SERVER 2010........................................................2FIGURE II-2 PLANIFICATION DES TACHES PAR MICROSOFT PROJECT SERVER 2010...................................................2FIGURE I-1 SECTEURS D’ACTIVITÉ POUR LE GROUPE SATEC..................................................................................5FIGURE I-2 ORGANIGRAMME D’INTELCOM....................................................................................................6FIGURE III-1 APPLICATION WEB À ARCHITECTURE 3 TIERS....................................................................................8FIGURE III-2 LA COMMUNICATION ENTRE LE CLIENT ET LE SERVEUR.......................................................................9FIGURE III-3 LES ATTAQUES AU NIVEAU APPLICATIF NE SONT PAS BLOQUÉES PAR UN FIREWALL CONVENTIONNEL..........12FIGURE III-4 SITE OFFICIEL DE MODSECURITY.................................................................................................14FIGURE III-5 SITE OFFICIEL DE WEBKNIGHT.....................................................................................................14FIGURE III-6 SITE OFFICIEL DE ESAPIWAF.....................................................................................................15FIGURE III-7 SITE OFFICIEL DE WEBCASTELLUM...............................................................................................15FIGURE III-8 SITE OFFICIEL DE GUARDIAN@JUMPERZ.NET.............................................................................16FIGURE III-9 SITE OFFICIEL DE QUALYS IRONBEE..............................................................................................16FIGURE III-10 SITE OFFICIEL DE NAXSI...........................................................................................................16FIGURE IV-1 CARACTÉRISTIQUES DU SERVEUR WEB..........................................................................................20FIGURE IV-2 L’ARBORESCENCE DU SITE WEB INTRANET.....................................................................................22FIGURE V-1 LES FICHIERS LOGS DE MODSECURITY............................................................................................28FIGURE V-2 FONCTIONNEMENT DE L’AUDIT CONSOLE.......................................................................................29FIGURE VI-1 CARACTÉRISTIQUES DE LA MACHINE D’AUDIT.................................................................................32FIGURE VI-2 L’INTERFACE DE W3AF.............................................................................................................33FIGURE VI-3 W3AF EN LIGNE DE COMMANDE................................................................................................33FIGURE VII-1 L’ENVIRONNEMENT DU TEST......................................................................................................37FIGURE VII-2 L’ARBORESCENCE DU SITE.........................................................................................................40FIGURE VII-3 RENOMMER LE NOM DE DOMAINE DU SERVEUR WEB....................................................................40FIGURE VII-4 CRÉATION DE LA BASE DE DONNÉES DES UTILISATEURS....................................................................41FIGURE VII-5CRÉATION DE 3 CHAMPS POUR LA TABLE USERS.............................................................................41FIGURE VII-6 REMPLISSAGE DE LA BASE DE DONNÉES.......................................................................................41FIGURE VII-7 PORTAIL INTRANET DE L’ENTREPRISE...........................................................................................42FIGURE VII-8 CRÉATION D’UNE PAGE DE TEST « SECRET.HTML ».........................................................................46FIGURE VII-9 ACTIVER MODSECURITY...........................................................................................................46FIGURE VII-10AJOUT DE LA PREMIÈRE RÈGLE DE FILTRAGE.................................................................................47FIGURE VII-11 LA PAGE « SECRET.HTML « APRÈS LA RÈGLE DE FILTRAGE..............................................................47FIGURE VII-12 L’UTILISATEUR AURA ACCÈS AU SITE PARCE QU’IL EST DÉJÀ INSCRIT.................................................48FIGURE VII-13 RÉPONSE DU SITE POUR UNE PERSONNE N’EST PAS ENREGISTRÉE DANS LA BASE DES UTILISATEURS........48FIGURE VII-14 RÉPONSE DU SITE POUR LA DERNIÈRE REQUÊTE...........................................................................48FIGURE VII-15 LE FICHIER MODSECURITY_CRS_10_CONFIG.CONF.......................................................................49FIGURE VII-16L’ENSEMBLE DES FICHIERS DE CONFIGURATION DE MODSECURITY....................................................50FIGURE VII-17 LA LISTE NOIRE À AJOUTER POUR L’INJECTION SQL......................................................................50

FIGURE VII-18 L’AGISSEMENT DE MODSECURITY SUITE À L’INJECTION SQL..........................................................51FIGURE VII-19 LA PAGE INDEX_XSS.PHP AVANT L’INJECTION..............................................................................51FIGURE VII-20 LA PAGE INDEX_XSS.PHP APRÈS L’INJECTION...............................................................................51FIGURE VII-21 LA LISTE NOIRE À AJOUTER POUR L’INJECTION XSS.......................................................................52FIGURE VII-22 L’AGISSEMENT DE MODSECURITY SUITE À UNE ATTAQUE XSS........................................................52FIGURE VII-23 LA RÉACTION DE MODSECURITY SUITE AU TRANSFERT D’UN FICHIER EXÉCUTABLE...............................52FIGURE VII-24 LA RÉACTION DE MODSECURITY SUITE À UNE ATTAQUE DIRECTORY TRAVERSAL ( PREMIER SCÉNARIO)...53FIGURE VII-25 LA RÉACTION DE MODSECURITY SUITE À UNE ATTAQUE DIRECTORY TRAVERSAL (DEUXIÈME SCÉNARIO)..53FIGURE VII-26 LA TRACE DE LA PREMIÈRE ATTAQUE SUR LE FICHIER LOG MODSEC_DEBUG.LOG.................................54FIGURE VII-27 LA TRACE DES ATTAQUES FILE UPLOADING ET DIRECTORY TRAVERSAL..............................................54FIGURE VII-28 LA TRACE DE L’ATTAQUE SQL INJECTION...................................................................................54FIGURE VII-29 LA TRACE DE L’ATTAQUE XSS..................................................................................................54FIGURE VII-30 PAGE D’ACCUEIL D’APACHE.....................................................................................................56FIGURE VII-31 PAGE D’ACCUEIL DE JWALL AUDIT CONSOLE..............................................................................56FIGURE VII-32 TÉLÉCHARGEMENT DE LA DERNIÈRE VERSION DE LA CONSOLE SOUS FORMAT (.WAR)..........................56FIGURE VII-33 L’INTERFACE DE L’AUTHENTIFICATION........................................................................................57FIGURE VII-34 PAGE D’ACCUEIL DE L’AUDIT CONSOLE.......................................................................................57FIGURE VII-35 TRANSFERT DU FICHIER LOG....................................................................................................58FIGURE VII-36 LE TABLEAU DE BORD(DASHBOARD) DE LA CONSOLE....................................................................59FIGURE VII-37 LA SECTION EVENTS...............................................................................................................59FIGURE VII-38 LA SECTION REPORTS.............................................................................................................60FIGURE VII-39 LA RÉPONSE DE MODSECURITY POUR CHAQUE HÔTE....................................................................60FIGURE VII-40 LE DEGRÉ DE SÉVÉRITÉ DES ATTAQUES POUR CHAQUE HÔTE...........................................................61FIGURE VII-41 LA DISTRIBUTION SAMURAI.....................................................................................................62FIGURE VII-42 L’UTILITAIRE W3AF..............................................................................................................62FIGURE VII-43 SAISIE DE L’ADRESSE URL.......................................................................................................63FIGURE VII-44 SCAN DU SITE WEB...............................................................................................................63FIGURE VII-45 RÉSULTAT DU TEST................................................................................................................64FIGURE VII-46 L’ARBORESCENCE DU SITE WEB SCANNÉ....................................................................................64FIGURE VII-47 LA SECTION LOGS DE W3AF...................................................................................................65FIGURE VII-48 EXEMPLE D’ATTAQUE SQL INJECTION POUR L’AUDIT SÉCURITÉ.......................................................65FIGURE VII-49 LES PLUGINS RESPONSABLES DE LA DÉTECTION DES INJECTIONS SQL................................................66

Liste des tableaux

TABLEAU III-1 MATRICE COMPARATIVE ENTRE LES SOLUTIONS OPENSOURCE WAF....................................................................18TABLEAU IV-1 LE CLASSEMENT DES 10 VULNÉRABILITÉS LES PLUS RENCONTRÉES DANS LES APPLICATIONS WEB [9]..........................25

Liste des acronymes

WAF :Web Application Firewall

OWASP :Open Web Application Security Project

SQL : Structured Query Language

XSS : cross-site scripting

RFI : Remote file inclusion

DOS : Deny of Service

BOF : Buffer Over Flow

SSO : Single Sign On

HTML : HyperText Markup Language

CSS : Cascading style Sheet

PHP : Hypertext Preprocessor

JEE : Java Entreprise Edition

JSP : Java Server Page

MVC : Model View Controller

W3AF : Web Application Attack and Audit Framework

1

I. INTRODUCTION GENERALE

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.

1.Problématique

Devant ce nombre important d’attaques quotidiennes Il existe de nos jours, de nombreux outils permettant de se prémunir contre des attaques mais ne fournissent pas d’informations suffisantes expliquant pourquoi une requête a été considérée comme une attaque et comment elle a été classifiée.

Et c’est pour cela que j’ai choisis comme sujet de traiter cette problématique-là, créer un ensemble d’outils, se rapprochant d’un pare-feu applicatif, qui évaluera une requête reçue par un serveur. Si elle s’avère être une attaque alors un ensemble d’informations seront retournées à l’issu de cette dernière (niveau et type par exemple) par le biais d’une journalisation, facilitant ainsi la tâche d’un administrateur de sécurité.

A travers ce stage de fin d’études je suis amené à répondre à certaines questions primordiales et ça serait l’objet du paragraphe suivant.

2.Cahier de charges

Au cours de ce stage je suis amené à établir un rapport détaillé concernant les points suivants :

1. La définition d’un WAF, son rôle, ses différentes fonctions et applications, une étude et évaluation des principales solutions et des plates-formes WAF (OpenSource) disponibles sur le marché. Vérifier leur pertinence en ce qui concerne la résistance aux attaques réseaux.

2. Concevoir et développer des applications Web avec deux langages différents, une application par le langage PHP et une application en J2EE (technologie JSP

2

basée sur le modèle de normalisation MVC) pour tester les fonctionnalités du pare-feu et sa résistance envers les attaques Web courantes

3. Une partie pour l’audit sécurité pour chercher les différentes failles de sécurité à distance et de préparer pour l’administrateur sécurité un ensemble d’informations afin de prendre des mesures convenables, En fait les outils de l’audit seront Open Source basés sur des distributions Unix par exemple Backtrack 5 ou Samurai.

4. Développement d’un banc de test permettant de mettre en évidence les stratégies et les mécanismes de défense contre les attaques WEB. Ce banc sera basé sur le déploiement du WAF en questions de la machine d’attaquant et finalement de la machine responsable pour la partie Audit.

3.Organisation du projet

Figure I-1 Diagramme de Gantt par Microsoft Project Server 2010

Le déroulement de stage sera comme la suite :

Figure I-2 Planification des taches par Microsoft Project Server 2010

3

Le Macroplaning de mon projet de fin d’études se divise en trois phases principales :

La première phase (22/02/12~03/03/2012)  : est une étape introductive serait une phase pour déterminer l’ensemble des attaques WEB qui peuvent menacer un SI et particulièrement se concentrer sur les différentes espèces de vulnérabilités qui peuvent altérer une application WEB , avoir un premier contact avec la notion du WAF ,déterminer son rôle et enfin ses différentes applications .

La deuxième phase(03/03/12~17/05/2012)   : est la phase maquette, 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 .Cette dernière étape aura comme mission pour une mise en place de la solution choisie premièrement sur une plateforme virtuelle ( VirtualBox par exemple ) pour tester les fonctionnalités du WAF concerné .

La troisième phase(17/05/12~21/06/2012)    : c’est l’étape finale et aurait comme but de réaliser un test pratique de notre produit open source à travers la génération d’une série d’attaques intentionnelles à travers une distribution linux spécifique ( Backtrack ou Samurai …) sur des applications Web développes par deux technologies Web a savoir en PHP et J2EE (JSP marié avec MVC), le but est de valoriser le travail et tracer un bilan objectif sur l’efficacité de notre produit ainsi sur les différentes améliorations qui peuvent être accompagnées au cours du test . Une partie d’audit sécurité est indispensable pour montrer à l’administrateur l’ensemble des failles sécurité présentes.

5. Conclusion

Nous avons présenté les différents axes de ce projet de fin d’études .Il reste de connaitre l’organisme d’accueil ses activités ainsi que les différentes solutions IT sur lesquelles il travaille avec les différents collaborateurs.

4

II.PRESENTATION DE L’ORGANISME D’ACCUEIL

La présentation du contexte général du projet a pour but de situer le projet dans son environnement organisationnel et contextuel. Ce chapitre commence par une présentation de l‘organisme d‘accueil.

1.1. Présentation

INTELCOM appartient au groupe SATEC (Sistemas Avanzados de Tecnologia, SA) une société multinationale espagnole d‘intégration de solutions technologiques, spécialisée dans les services avancés liés aux nouvelles Technologies de l‘Information.

Elle a privilégié depuis 1987 la collaboration avec ses clients à travers l‘innovation dans les processus, les ressources et les technologies, contribuant ainsi au changement, à la productivité et à la compétitivité dans leur activité.

Les principes qui régissent ses actions sont les suivants : une base technologique solide et la haute qualification de son personnel, combinées à une gestion experte des fournisseurs, en veillant constamment à la qualité du produit ou du service, à une innovation permanente, à une longue expérience dans la mise en place de solutions chez plus d‘un millier de clients et à une relation privilégiée avec les partenaires technologiques, toujours tournés vers le client et avec l‘engagement ferme d‘offrir des solutions et des services innovateurs adaptés à ses besoins spécifiques.

Société anonyme, INTELCOM est aujourd‘hui une grande entreprise activement présente dans trois grandes villes du royaume: Rabat, Casablanca et Tanger. Elle a un capital social de 15.000.000,00 DH avec un effectif de plus de 300 personnes dont 70% ont des compétences techniques éprouvées et 50% sont des cadres supérieurs.

1.2. Mission, valeurs et stratégies

Créer de la valeur et générer de la croissance au moyen de solutions et de services innovateurs dans le domaine des technologies de l‘information et communication

5

, en contribuant à l‘évolution, à l‘efficacité et à la productivité de ces clients, en promouvant le talent, l‘intégrité et le travail en équipe, pour être la référence de son secteur et de sa communauté.

La stratégie d‘INTELCOM vise à améliorer les Systèmes d‘Information et de Télécommunications actuels de ces clients, grâce à un éventail complet de Services et de Solutions d‘Ingénierie. Elle se différencie par l‘expertise démontrée lors de la réalisation de projets d‘une grande complexité technique dans des secteurs à grande répercussion sociale, tels que la Santé, l‘Environnement, la e-Éducation et la e-Administration Publique, grâce à la haute qualification et au grand professionnalisme de ces équipes techniques.

1.3. Les secteurs d’activité

La société dispose d‘une grande gamme de Solutions et de Services TIC qui couvrent les besoins de ses clients, recueillent et analysent leurs exigences pour leur développement, leur mise en place et leur maintenance. Son expérience a également servi à offrir des solutions et des services spécifiques à plusieurs secteurs d‘activité, tel que:

Les administrations publiques, Les opérateurs de télécommunication, la santé, l‘industrie, les banques, les assurances.

Gamme de Services d’INTELCOM

Les services d‘INTELCOM sont basés sur une architecture modulaire, extensible et ouverte qui permet de s‘adapter aux divers besoins de ses clients. L‘éventail de services d‘INTELCOM comprend différents modules qui permettent d‘adapter l‘offre de la société aux besoins réels de ses clients. L‘illustration suivante résume l‘éventail de services d‘INTELCOM:

Figure II-3 Secteurs d’activité pour le Groupe Satec

6

1.4. Organigramme d’Intelcom

L‘organigramme de la société repose sur une structure hiérarchique et se compose des niveaux suivants :

Niveau 1 : Direction générale et assistance à la direction générale;

Niveau 2 : Directions spécialisées (Technique, Administrative et financière, Commerciale, etc.) ;

Niveau 3 : Chefs d‘entités.

Mon stage s‘est déroulé au sein de l‘entité « sécurité » qui appartient à la direction technique de rabat (colorée en rose dans la figure de l‘organigramme).

Pour son évolution interne, INTELCOM applique la théorie de l‘agence en engageant des agents pour exécuter en son nom quelques activités spécifiques dans d‘autres régions du royaume. Ce qui implique une délégation d'un certain pouvoir à l'agent. L‘agence de Tanger illustre une première expérience de ce genre.

La figure ci-dessus présente l‘organigramme de la société :

7

Figure II-4 Organigramme d’INTELCOM

Chapitre 1 Description Technique Du Projet

8

I. LES FIREWALLS APPLICATIFS

Le mot « firewall applicatif » ou la nomination anglo-saxonne « Web Application Firewall » regroupe deux termes : premièrement le terme firewall ensuite le terme application, pour assimiler le secret qui se trouve derrière ce mot-clé, il faudrait décortiquer chaque entité qui fait partie du mot, comprendre sa mission, digérer la relation entre les deux , puis saisir ce que veut dire l’ensemble .

1.Préliminaires

1.1. Qu’est 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 [1].

Une application Web 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 serveur de bases de données.

Figure I-5 Application Web à 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 [2].

9

Cela nous emmènera à poser la question c’est quoi le protocole http , quel est son rôle et comment il travaille ?

Quels sont les différents mécanismes qui interviennent lors d’une requête/réponse http.

La réponse est dans le paragraphe suivant .

1.2. Le protocole http/https

Le protocole http

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

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

Figure I-6 La communication entre le client et le serveur

Le navigateur effectue une requête HTTP Le serveur traite la requête puis envoie une réponse http

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'URL3

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

10

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

1 Couche application : La couche Application est la dernière couche du modèle OSI (Niveau 7). Elle regroupe les services qui traitent des aspects sémantiques de l'Application dans un système réparti.

2 Couche de transport : Le rôle de la couche transport est d'assurer un transfert fiable des données entre deux applications en s'appuyant sur la couche réseau. La couche transport doit assurer: la détection des erreurs de transmission, la correction des erreurs de transmission, la récupération des paquets perdus, la gestion de la duplication de paquets, le contrôle de flux dynamique.

3 URL : Le sigle URL (de l'anglais Uniform Resource Locator, littéralement « localisateur uniforme de ressource »), auquel se substitue informellement le terme adresse web, désigne une chaîne de caractères utilisée pour adresser les ressources du World Wide Web

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.

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

METHODE URL VERSION<crlf>EN-TETE : Valeur<crlf>...EN-TETE : Valeur<crlf>Ligne vide<crlf>CORPS DE LA REQUETE

Le protocole https

Quand vous naviguez sur internet, vous surfez sur des pages dont le titre commence toujours par « http ». Or ce protocole de communication n’est pas sécurisé et votre connexion comporte de nombreuses données personnelles. C’est pourquoi, vous observerez 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 vous laissez vos données.

Le protocole « http » n’est soumis à aucun chiffrement. C’est pourquoi le protocole « https » pour « http » ‘secured’ a été inventé. Quand vous surfez sur un site ou certaines pages de sites, notamment les pages de transaction des sites marchands ou sur les sites bancaires, vous observerez que la racine de la page commence par « https »[4].

Les modes de chiffrement Https

11

Le protocole « https » signifie que la communication entre vous 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 vos mots de passe ou autres informations personnelles voire confidentielles [4].

Mais lorsque vous saisissez l’adresse http://www.intelcom.ma ou https://www.intelcom.ma comment le navigateur sache l’emplacement de votre destinataire ? C’est ce que nous allons essayer de répondre dans la section suivante.

1.3. Le protocole DNS

Quand vous voulez téléphoner à quelqu'un, vous devez 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 votre ordinateur, tapez ping www.intelcom.ma (en ligne de commande, dans une fenêtre MS-DOS): vous verrez l'adresse IP de ce site.

Ça veut dire quoi, DNS ?

D.N.S. signifie 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.

1.4. Bilan de la première partie

12

Il se passe quoi quand je tape http://intelcom.ma   ?

1. Le serveur DHCP de votre fournisseur d'accès (qui vous attribué votre adresse IP) vous a aussi attribué des adresses de DNS.

2. Votre ordinateur se connecte à ces serveurs DNS pour obtenir l'adresse IP de la machine www.intelcom.ma.

3. La requête qu’on a envoyé est transférée par le biais du protocole http ou https.

4. Si le serveur DNS de votre fournisseur d'accès n'a pas la réponse, il va questionner d'autres serveurs DNS.(Ce scénario n'est pas toujours vrai: Votre système d'exploitation garde un petit cache DNS.)

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, passons à notre deuxième partie « le FIREWALL »

1.5. Qu’est-ce qu’un firewall ?

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é 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 [3].

Un firewall classique conventionnel permet de filtrer au niveau de la couche réseau (IP)1 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 2(flags), l’interface d’entrée et de sortie du firewall, etc...

Comme le suggère la figure 3-3 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 [4].

Figure I-7 les attaques au niveau applicatif ne sont pas bloquées par un firewall conventionnel

13

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.

2.Les firewalls applicatifs (Web Application Firewall)

 «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. On constate donc un véritable intérêt pour les pare-feu applicatifs chez nos clients», explique Frédéric Renaud, chef de projet sécurité réseau chez Thales Secure Solutions.

1 Couche réseau : la troisième couche construit une voie de communication de bout à bout à partir de voies de communication avec ses voisins directs

2 L’état de connexion si elle est active ou non

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)

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[5].

2.1. Qu’est-ce qu’un firewall applicatif

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

J’ai déjà un Firewall réseau. Quelles sont les différences entre un Firewall réseau et un 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 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.

Pourquoi un WAF est maintenant un élément indispensable dans mon infrastructure ?

14

Selon une étude du Gartner, 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, 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 [6].

2.2. Les solutions Open-source existantes 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 [3].

Quels sont les avantages par rapport aux solutions classiques ?

exécuter le programme librement, pour tous les usages et sans conditions étudier 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.

Les WAF open source

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.6.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.

Figure I-8 Site officiel de Modsecurity

15

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.

Figure I-9 Site officiel de Webknight

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.

Figure I-10 Site officiel de ESAPIWAF

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

16

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.

Figure I-11 Site officiel de WebCastellum

Guardian@JUMPERZ.NET

Guardian@JUMPERZ.NET est un 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.

Figure I-12 Site officiel de Guardian@JUMPERZ.NET

Qualys 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.

17

Figure I-13 Site officiel de Qualys Ironbee

NAXSI

Au contraire 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 est trop élevé, le client est redirigé sur une page de type 503.NAXSI reste un projet jeune, et en tant que tel, nécessite plus de tests.

Figure I-14 Site officiel de Naxsi

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.

Les critères de comparaison seront les suivants :

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.

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

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

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

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 :

18

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.

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 .

P Produit Licence Fonctionnement

White list

Fonctionnement

Black list

Bloquage

Selon

GET

Bloquage

Selon

POST

Bloquage

Selon

les entêtes

http

URL

Rewriting

FAQ

Assistance+

Mailing list

ServeurWEB

MODSECURITY

OpenSource

X x X X x X Mise à jour Complète

avec un développement

assisté et qui suit les

dernières informations surles attaques les

plus récentes

Apache

AQTRONIXWEB

KNIGHT

OpenSource

X x X X x X - IIS

ESAPIWAFOpen

source- - X X x X - Version

pour apache et pour IIS

WEBCASTELLUM

Opensource

X x X X x A l’aide d’un

programme externe

La langueallemande

+une mise à journ’est périodique

comme Modsecurity

Guardian@

JUMPERZ.NET

Opensource

- - X X X - Une mise àjour

n’est pas périodique

elle s’est arrétée en 2009

Apache+

IIS

QualysIron bee

Opensource

X X X X X X Une mise àjour

basée sur modsecurity .l’archi

tecte Ivan Rystic a conçu ce deuxième

WAF suite au succés

qu’a connu le Modsecurity

Naxsi

Opensource

X X X X - - Naxsi est basésur la solution

Nginx OpenSource quipermet le

loadbalancing

Apache

Tableau I-1 Matrice comparative entre les solutions Opensource WAF.

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

19

présenter comme un produit optimal pour les tests à venir .La solution 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 d’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 mise à jour 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.

2.3. Fiche technique sur Modsecurity

ModSecurity est un projet issu du monde open source qui a débuté en 2002. Aujourd’hui disponible en version 2.6.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. Ces fonctionnalités sont :

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 en jour juste à temps

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

Fonctionnement global 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.

Phase 1 : Traitement des en-têtes de la requêteCette 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 UserAgent.

Phase 2 : Traitement du corps de la requêteL’analyse de corps de la requête permet d’inspecter les arguments dans le cas d’une requête en POST

Phase 3 : Traitement des en-têtes de la réponseLes 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.

Phase 4 : Traitement du corps de la réponseCette 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.

20

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.

Nous détaillerons la configuration et l’installation de ModSecurity dans le chapitre Mise en place de la maquette de test.

II. FICHE TECHNIQUE SUR LES APPLICATIONS WEB

Le chapitre précédent nous a donné comme fruit le produit final à exploiter, c’est le WAF ModSecurity, l’objet de ce chapitre est de présenter les différentes applications pour le Pentesting. Ensuite, s’arrêter devant un paragraphe considéré comme « état de l’art »  présentant les différentes vulnérabilités qui menacent la majorité des applications Web.

1.Environnement du travail

Cette étape est cruciale au niveau du projet, elle consiste à élaborer un site WEB interne à l’entreprise pour permettre les utilisateurs à accéder aux différents services par exemple le service mail, le service de base de données. Notre plateforme de test est un environnement virtuel basé sur la solution Open Source Virtual BOX d’Oracle.

21

1.1. Fiche technique sur le serveur Web

Fiche technique   :

OS : Debian lenny

Mémoire vive :384 Mo

Disque Dur :8 Go

Pourquoi utiliser Debian ?

J’ai choisi la distribution Debian pour plusieurs raisons :

Ses qualités techniques : Debian est réputée pour sa stabilité, pour son très bon système d'installation de mise à jour des composants logiciels et pour sa rapidité à réparer les failles de sécurité

Debian GNU/Linux est utilisé par la plupart des fournisseurs d'accès à Internet, comme Free.

Debian est reconnu pour son sérieux et ses fortes prises de positions dans le monde libre. Debian garantit la liberté des logiciels qu'elle propose !

Ce qui distingue Debian par rapport aux autres distributions est son attachement très fort à la philosophie du logiciel libre. Cet attachement est forgé dans son Contrat Social et dans Les principes du logiciel libre selon Debian .

Qu'est-ce qu'un serveur web ?

Un serveur web est un logiciel 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.

Un serveur web est donc un « simple » logiciel capable d'interpréter les requêtes HTTP arrivant sur le port associé au protocole HTTP (par défaut le port 80), et de fournir une réponse avec ce même protocole.

Les principaux serveurs web sur le marché sont entre autres :

Virtual Box est un logiciel de virtualisation de systèmes d'exploitation. En utilisant les ressources matérielles de l'ordinateur (système hôte), Virtual Box permet la création d'un ou de plusieurs ordinateurs virtuels dans lesquels s'installent d'autres systèmes d'exploitation (systèmes invités) [7].

Figure II-15 Caractéristiques du serveur Web

22

ApacheMicrosoft IIS (Internet Information Server)

Pourquoi Apache ?

Apache (www.apache.org) est le serveur le plus répandu sur Internet. 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. Le pack PHPdev (désormais EasyPHP) est ainsi téléchargeable, il regroupe les applications suivantes :

le serveur web Apache le serveur de bases de données MySQL le serveur d'application PHP l'outil phpMyAdmin permettant de gérer des bases MySQL

PHP 

Le PHP: Hypertext Preprocessor, plus connu sous son sigle PHP, 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ète. En raison de la richesse de sa bibliothèque, on désigne parfois PHP comme une plate-forme plus qu'un simple langage.

Mysql 

MySQL est un système de gestion de base de données (SGBD). Selon le type d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle et Microsoft SQL Server.

Phpmyadmin

Il s'agit de l'une des plus célèbres interfaces pour gérer une base de données MySQL sur un serveur PHP. De nombreux hébergeurs, qu'ils soient gratuits ou payants, le proposent ce qui permet à l'utilisateur de ne pas avoir à l'installer.

Cette interface pratique permet d'exécuter, très facilement et sans grandes connaissances dans le domaine des bases de données, de nombreuses requêtes comme les créations de table de données, les insertions, les mises à jour, les suppressions, les modifications de structure de la base de données.

1.2. Le site Web intranet

23

Le site intranet sera une vitrine pour accéder aux différents services à savoir le service mail , service de base de données , service LDAP etc…au sein d’un réseau local .

La technologie utilisée pour réaliser des pages statiques est « html » et pour aborder le coté dynamique nous aurons à utiliser le langage PHP. L’arborescence du site sera de la forme suivante :

Figure II-16 L’arborescence du site Web intranet

Nous allons détailler la mise en place du site ainsi que son déploiement dans le chapitre Mise en place de la maquette de test .

Jusqu’à présent nous possédons un site Web Intranet qui n’est pas protégé contre les attaques Web , il est vulnérable , faisons connaissance avec les attaques les plus connues dans la couche applicative.

1.3. L’application de gestion des utilisateurs du site en JEE

Cette Application a pour but de stocker les nouveaux utilisateurs dans une base de données indépendante du site intranet et en assurant en même temps une gestion d’authentification .afin d’instaurer un niveau de sécurité intéressant vu que le contact des utilisateurs sera avec l’application et loin du site principal les menaces d’intrusions seront pas assez dangereuses.

L’application doit être développée en respectant la séparation des couches données, métier et de présentation.

La couche de données est représentée par une base de données relationnelle Mysql (on la nomme Person).

La couche métier sera développée en utilisant : Une classe Operation .java pour implémenter les

différentes méthodes à savoir (Ajouter , afficher , s’authentifier )

Une classe Person.java qui contient les attributs à définir de chaque nouvel utilisateur

La couche basée sur les servlets et JSP en respectant l’architecture MVC contient :

24

La classe Personbeans .java aura comme mission de transporter les paramètres principaux entre le contrôleur à savoir la classe Personservlet.java et la vue qui sont les classes de présentation ( ajouter.jsp , supprimer.jsp etc…)

PersonServlet.java : est une classe java responsable de recevoir les requêtes http de la part de la vue les pages d’accueil)et de créer deux objets (req,resp) qui seront transmis par le Modèle ( Personbeans.java) vers la vue ( les pages d’accueil) Voir partie mise en place de l’application J2EE

L’environnement du travail

Eclipse est un projet de la Fondation Eclipse visant à développer tout un environnement de développement libre, extensible, universel et polyvalent.Son objectif est de produire et fournir divers outils gravitant autour de la réalisation de logiciel, englobant les activités de codage logiciel proprement dites (avec notamment un environnement de développement intégré) mais aussi de modélisation, de conception, de test,, etc. Son environnement de développement notamment vise à la généricité pour lui permettre de supporter n'importe quel langage de programmation. Notre IDE sera Java EE Indigo .

Figure II-3 Diagramme UML par AgroUML

25

Figure II-4 Quelques prises d’écran de l’application

Rendez-vous à la partie 3 pour la mise en place et les différentes démarches élaborées pour mettre en place l’application JEE de l’authentification.

2.Les attaques Web les plus courantes

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 :

26

TOP 10 des vulnérabilités dans les applications WEB

Rang Vulnérabilité Description

1 Paramètres non validés Les informations transmises avec la requête ne sont pas validées

avant d’être utilisées par l’application Web.2Faille dans le contrôle d’accèsLes restrictions sur ce que les utilisateurs authentifiés ont le

droitde faire ne sont assez solides. Un attaquant peut utiliser ces

faillespour accéder aux comptes d’autres utilisateurs, voir de

fichiers sensibles ou utiliser des fonctions non-autorisées.3 Vol de sessionLe mécanisme de maintien de la session n’est pas assez sûr :

l’attaquant qui peut compromettre une clé de session ou un cookie

peut accéder aux privilèges d’un autre utilisateur4 Cross-Site-Scripting (XSS)L’application Web peut être utilisée comme intermédiaire pour

attaquer l’un de ses utilisateurs et exécuter du code à son insudans le contexte de l’application Web , par exemple, voler sa

clé de session.5 Buffer Overflow (BOF) L’application ne contrôle pas la dimension des paramètres

reçus avant de les écrire en mémoire. Cette faille peut êtreutilisée pour aller y écrire du code exécutable et modifier le

comportement de l’application.6 Injection de commandes L’application utilise lors de l’accès à des commandes

externes ou au système d’exploitation des paramètresnon-validés qui peuvent être utilisés par l’attaquant pour

exécuter des commandes malicieuses.7Mauvaise gestion des erreurs La gestion des erreurs n’est pas réalisée correctement.

L’attaquant peut déclencher des erreurs qui ne sont pas gérées par l’application Web et ainsi obtenir des informations

détaillées sur le système, ou compromettre le serveur.8 Mauvaise utilisation de la

CryptographieLes applications Web font fréquemment appel à des fonctions

de cryptographie pour assurer l’intégrité et la confidentialitédes données. Certains de ses algorithmes ou leurs

implémentations peuvent comporter des failles de sécurité.9 Faille dans l’administration

distanteBeaucoup d’applications Web comportent un système

d’administration à distance, qui s’il n’est pas correctement protégé, peut permettre à un attaquant de gagner les

privilèges de l’administrateur.10 Mauvaise configuration du

serveur Web ou d’applicationLa sécurité de l’application Web repose sur celle du serveur

Web,du serveur d’application et du système d’exploitation. Ceux-ci ne sont généralement pas sécurisés avec la configuration par

défaut.

Tableau II-2 le classement des 10 vulnérabilités les plus rencontrées dans les applications Web [9]

27

2.1. SQL injection

SQL est un langage structuré de requêtes, destinées à interroger ou à manipuler une base de données relationnelle. Le principe des injections SQL consiste à envoyer une requête SQL non prévue par le système. Cela permet à un utilisateur malveillant d’accéder, modifier ou supprimer des informations de la base de données. Par exemple si le site utilise la requête suivante pour identifier un utilisateur :

« SELECT user id WHERE user name = ’nasredine’ AND user password =’457b3a2af6879c4ff17f8d1174760f62’. »

Dans ce cas, si il n’y a aucune vérification sur la saisie de l’utilisateur, alors il suffit d’entrer : « nasredine’--» comme nom d’utilisateur pour s’identifier comme l’utilisateur nasredine.En effet en SQL « -- » signifie que ce qui va suivre est un commentaire, par conséquent la suite de la requête :

« AND user password = ’457b3a2af6879c4ff17f8d1174760f62’ » va être considérée comme un commentaire d’où l’inutilité du mot de passe pour se connecter. voir le test sur les injections SQL de la partie 3

2.2. Attaque XSS

La technique consiste à envoyer du code malicieux sur un site Web vulnérable, ce code sera interprété et exécuté par le navigateur des autres utilisateurs. Par exemple sur un forum présentant aucune sécurité pour ces attaques, si l’on envoie ce type de message « <script>alert(’bonjour’)</script> » , alors les utilisateurs qui souhaiteront lire les messages verront apparaitre une fenêtre contenant le message « bonjour » ,au lieu d’un simple message texte. Il existe plusieurs solutions pour contrer ces attaques notamment en interdisant les scripts à certains endroits du code, en vérifiant le format des données saisies par l’utilisateur ou encore en encodant les données entrées par l’utilisateur. voir le test sur les injections XSS de la partie 3

2.3. Violation de contrôle d’accès

Cette technique consiste à exploiter une faiblesse de restriction des droits utilisateur, ce qui donne l’accès à d’autres comptes utilisateur avec leurs droits associés. Un paramétrage correct des droits utilisateur suffit à éviter ce genre d’attaque.

2.4. Traitements inappropriés d’erreurs

Comme tout programme informatique, les applications Web peuvent connaitre des dysfonctionnements tels que l’inaccessibilité d’une ressource ou des problèmes liés à la mémoire.

28

La plupart du temps ces dysfonctionnements génèrent des codes d’erreur permettant leur identification par les concepteurs de l’application. Cependant il n’est pas rare que ces codes soient directement fournis à l’utilisateur via l’affichage d’une page Internet, ce qui représente une mine d’informations pour l’utilisateur malveillant, car cela l’informe sur la structure de l’application et sur ses vulnérabilités.

Exemple :

Connaitre l’OS du serveur Web

2.5. Directory Traversal

L’utilisateur malicieux va structurer sa requête de sorte à obtenir une branche du système de fichiers au lieu d’un fichier. L’utilisateur peut ainsi accéder à des informations sensibles.

Par exemple il suffit d’utiliser la chaine « ../ » qui permet de remonter dans l’arborescence du système de fichiers et ainsi accéder à des informations non autorisées. Voir test Partie 3 du projet . voir le test sur les injections DT de la partie 3

2.6. Dénis de service (DoS)

Une attaque est considérée comme un déni de service si un utilisateur bloque délibérément l’accès à un serveur, privant ainsi les autres utilisateurs de l’accès à celui-ci. Une technique possible consiste à saturer le serveur en lui envoyant des données inutiles. Il existe un dérivé de cette attaque qui repose sur une parallélisassions d’attaque DoS, simultanément menées par plusieurs systèmes contre un seul. Pour éviter de telles perturbations, il est possible d’utiliser une liste noire contenant les adresses IP des machines hostiles. Lorsque le serveur recevra une requête provenant d’une machine contenue dans sa liste noire, la requête sera rejetée [8].

3.Conclusion

Comme nous l’avons vu, il y’en a pas mal d’attaques Web 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 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.

29

III. LA JOURNALISATION

Afin de pouvoir communiquer à son administrateur les derniers résultats des attaques sur un serveur Web bien donné, Modsecurity détaille dans des fichiers de log ses activités. Nous avons indiqué dans le chapitre précédent que ces logs sont issus de notre WAF mais il faut signaler qu’ils sont illisibles et par la suite difficilement exploitables par un administrateur sans outils adapté. Voyons comment résoudre ce problème.

1.Les fichiers logs de Modsecurity

Il ne faut mentionner que les attaques qu’on va les lancer pour tester Modsecurity ne passent jamais inaperçues, en effet Modsecurity offre une possibilité de journalisation à travers des fichiers logs, nous avons créé au début un répertoire réservé pour les rassembler, on la nommé logs il se trouve dans etc/modsecurity2/ voir l’installation de Modsecurity dans la partie 3.

Figure III-17 Les fichiers logs de Modsecurity

Comme nous allons le voir au niveau de la partie 3 la journalisation marche correctement mais pour un administrateur réseaux et sécurité, il ne doit pas revenir chaque fois vers ces fichiers et de chercher entre les lignes les attaques et leurs dates, c’est pour cela qu’il faut penser à la mise en œuvre d’une console qui facilite son travail d’une manière plus détaillée et plus signifiante et ça sera l’objet de notre prochain paragraphe

2.Fiche technique sur La console d’audit

Le but de cette partie est de mettre en valeur les fichiers logs issus de ModSecurity et de constituer pour un utilisateur qui ne maitrise pas les aspects techniques une interface conviviale qui montre le degré de risque pour chaque vulnérabilité, les statistiques des attaques web contournées par notre WAF

30

ainsi de donner quelques autres informations nécessaires pour démystifier chaque attaque.

Avant d’attaquer le vif du sujet ça serait plus instructif de définir qu’est-ce qu’un système multi-agents quel est son rôle et comment on va mettre en œuvre notre console.

Un système à agents intelligents est un système composé d'un ensemble d'agents, situés dans un certain environnement et interagissant selon certaines relations. Un agent est une entité caractérisée par le fait qu'elle est, au moins partiellement, autonome. Ce peut-être un processus, un robot, un être humain, etc.

Objet de longue date de recherches en intelligence artificielle distribuée, les systèmes multi-agents forment un type intéressant de modélisation de sociétés, et ont à ce titre des champs d'application larges, allant jusqu'aux sciences humaines [3].

Figure III-18 Fonctionnement de l’audit console

La société JWALL a développé une application JEE qui travaille avec un conteneur de servlets pour notre cas je vais choisir «  TOMCAT » et elle est capable de recevoir des audit-events de la part de ModSecurity en temps réel .

A quoi va nous servira Tomcat ?

Tomcat est un produit Open Source sous licence "Apache" développé et maintenu par le groupe de travail Apache Jakarta Project.

En simplifiant, dans le monde des serveurs Java, il existe 3 catégories :

Les serveurs de Servlets : Tomcat, ServletExec, JRun. Ils implémentent les spécifications SERVLET et JSP (Java Server Page).

31

Les serveurs d'EJB : Jboss, Jonas. Ils implémentent les spécifications EJB. Les serveurs d'applications : WebSphere, BEA, WebLogic. Ces derniers sont

pour la plupart des produits commerciaux et fournissent une implémentation des spécifications SERVLET, EJB dans le même produit. Ils proposent également des services supplémentaires, des connecteurs applicatifs et des interfaces de gestion.

Quels sont les avantages de Tomcat ?

Conformité : En parfaite conformité avec les spécifications de SUN pour les SERVLET et JSP.

Fiabilité : Plusieurs années d'évolutions et d'améliorations par les meilleurs développeurs se concentrant sur l'essentiel.

Gratuité : Même si il existe toujours des coûts cachés, nous sommes loin du prix d'achat des produits commerciaux concurrents.

Modularité : La conception de Tomcat permet d'intégrer des développements spécifiques sans remettre en cause la structure d'origine.

Maintenabilité : Les dernières versions de Tomcat fournissent des interfaces d'administrations Intranet très réussies et évolutives.

Support : Les listes de diffusion et les newsgroups fournissent un support très convenable compte-tenu de leur coût.

La Console JWALL audit-ModSecurity en quelques mots

Au cours des dernières années, l’utilisation est devenue excessive de Modsecurity. La société JWALL a commencé à développer un ensemble d'outils pour Modsecurity. La plupart de ces outils sont disponibles gratuitement sur la page d'accueil www.jwall.org.

Jadis l'inconvénient de Modsecurity a toujours été son manque d'utilisation pratique. L'un des seuls outils fournis pour Modsecurity a longtemps été la console de communauté Modsecurity. Cette console a été développée par Ivan Ristic et fournit une interface web pour gérer Modsecurity liés à la vérification des événements.

Depuis que la console de Modsecurity a fermé son projet open source, il n'y avait aucun moyen de le prolonger. Basé sur une idée de Ralf Spenneberg, qu’il l’a mentionnée lors d'un atelier Modsecurity allemand, JWALL a commencé à mettre en œuvre sa console de gestion propre Modsecurity. Voir la partie pratique de la console JWALL

3.Conclusion

La fiche technique de l’application Audit-Console est terminée, nous allons détailler son installation ainsi que son déploiement au niveau de la partie 3, Le chapitre suivant sera consacré à la partie audit sécurité de notre serveur Web.

32

IV. L’AUDIT SECURITE

Les failles web permettent des actions de plus en plus importantes de la part des pirates informatique. Il est fini le temps ou le piratage d’un site Web de se contenter d’afficher une simple fenêtre sur la page de l’utilisateur ou bien le vol d’un cookie.

De nos jours, le piratage d’une application Web est nettement plus dangereux que cela, ce qui fait que chaque administrateur sécurité devrait en être conscient. Et devrait effectuer le maximum possibles des opérations d’audit pour trouver les failles Web existantes et d’essayer de les corriger.

Je vais vous présenter un outil est un outil d’audit sécurité à distance Open source :W3AF

1.Qu’est-ce que W3AF ?

W3af ou bien encore Web Application Attack and Audit Framework est, comme son nom l’indique, un framework permettant d’automatiser l’audit ainsi que les attaques à l’encontre des applications web. Pour ceux d’entre vous connaissant Métasploit, w3af peut être comparé à ce dernier en matière de pen-test sur les applications web.

W3af est un framework très complet placé sous licence GPL (General Public License) entièrement écrit en Python avec un code extrêmement bien commenté permettant ainsi à n’importe quel développeur potentiel de créer ses propres modules/exploits. Grossièrement, w3af peut se décomposer en trois catégories :

Découverte Audit Attaque

Les plugins de « découverte » ont pour but de rechercher des formulaires, des urls ou plus généralement tout point potentiel d’injection de code malveillant. Un exemple classique de plugin de découverte est web spider. Ce plugin prend une URL en entrée et retourne un ou plusieurs points d'injection.

33

Les plugins d’« audit » attendent les points d'injection découverts par les plugins de découverte et envoient des données construites spécifiquement à tous ces derniers afin de trouver des vulnérabilités. Un exemple classique de plugin audit est un plugin qui recherche des vulnérabilités d'injection SQL.

Les plugins d’ « attaque » ont pour but d'exploiter les vulnérabilités trouvées par les plugins d’audit et de découverte. Ils retournent en général un Shell sur le serveur distant, ou un dump des tables distantes dans le cas des exploits d'injections SQL.

2.Origine du projet

Le projet w3af a vu le jour au début de l’année 2007 (Fin janvier, début février) grâce aux travaux de son unique développeur Andrés Riancho. Andrés est un chercheur connu et reconnu dans le monde de la sécurité informatique notamment dans le domaine des applications web.W3af est actuellement à sa version 1.0-rc1

Son principal objectif est de rendre le web le plus sécuritaire possible vu les enjeux qui sont maintenant en train de transiter dessus.

Le Framework w3af est très portable et peut s’utiliser sur n’importe quelle plateforme tant que cette dernière supporte le Python (Linux, WinXP, Vista, OpenBSD, etc.)

A partir du moment où l’environnement Python est présent sur la machine accueillant w3af, il existe trois moyens afin de s’en servir :

Téléchargement et installation des paquets (Solution sous linux) Téléchargement et exécution des binaires (Solution sous Windows) Utilisation de w3af contenu dans le LiveCD Samurai

Pour notre cas nous allons utiliser la distribution Samurai sur VirtualBox.

2.1. Samurai

C’est quoi Samurai ?

Samurai Test Web est un environnement Linux live qui a été préconfiguré pour fonctionner comme un environnement de pen-testing web. Le CD contient le meilleur de l'open source et d'outils gratuits qui se concentrent sur l’audit et attaques Web.

On aurait utilisé la distribution Backtrack5.0, Ça revient au même .Mais la distribution Samurai est une Framework orienté audit Web, tandis que Backtrack est une distribution qui regroupe une panoplie d’outils pour les attaques pour la couche 3,4 ainsi que la couche 7 du modèle OSI.

Fiche technique sur Samurai

34

Fiche technique

OS : Samurai

Mémoire vive :256 Mo

Disque Dur :8 Go

Adresse IP :192.168.0.7

3.W3AF et ses possibilités

Avant de rentrer dans les détails techniques que propose w3af, il est important de préciser qu’il est possible d’utiliser w3af de deux manières différentes :

Via son interface graphique Via sa ligne de commande

Figure IV-20 L’interface de W3AF

.Il est également possible d’utiliser la ligne de commande pour se servir de w3af. Il est possible, via la ligne de commande, d’exécuter exactement les mêmes commandes que grâce à l’interface graphique.

35

Figure IV-21 W3AF en ligne de commande

Maintenant, nous allons tenter de découvrir w3af un peu plus en profondeur en dévoilant les 8 catégories distinctes que ce dernier possède :

Découverte Audit Attaques Grep Modificateurs de requête Evasion Brute Force Affichage

Comme nous avons pu le dire précédemment, les plugins de « découverte » ont pour objectif de rechercher des points d’injection dans un site web (url, formulaire, page d’authentification).

Les plugins d’« audit » récupèrent les points d’injection trouvés précédemment par les plugins de découverte et tentent de trouver des vulnérabilités spécifiques à toutes les possibilités.

Les plugins d’« attaque » exploitent les vulnérabilités trouvées par les plugins d’audit. Ils retournent en général un Shell sur le serveur distant, ou un dump des tables distantes dans le cas des exploits d'injections SQL.

Les plugins de type « grep » analysent le contenu de l’ensemble des pages et tentent de trouver des vulnérabilités sur les pages interrogées. Certains plugins vont, par exemple, tenter de récupérer des commentaires dans les pages HTML possédant certains mots clé comme « password », « admin » etc.

Les plugins « modificateurs de requête » permettent comme leurs noms l’indique de modifier les requêtes ainsi que les réponses du serveur avant de les réacheminer. Il est important de comprendre que grâce à ce genre d’outils, les contrôles mis en place coté client par du JavaScript par exemple peuvent facilement être contournés comme la gestion des longueurs maximale d’un champ grâce à l’attribut « maxlength ».

Les plugins d’ « évasion » tentent de contourner l’ensemble des règles mises en place par des IDS (Intrusion Detection System) ou IPS (Intrusion Prevention System) afin d’être le plus furtif possible.

36

Les plugins de « bruteforce » permettent de réaliser des attaques par force brute contre les formulaires d’indentifications par exemple.

Dernièrement, les plugins d’« affichage » quant à eux représentent la manière via laquelle les plugins vont communiquer avec l'utilisateur. Les plugins d’affichage enregistrent les données dans un fichier texte ou HTML.

Avant de vous exposer un cas concret, nous allons faire une liste non exhaustive de quelques plugins rangés par catégories.

Audit

SQL injection detection XSS detection SSI detection Local file include detection Remote file include detection Buffer Overflow detection OS Commanding detection Response Splitting detection

Découverte

Pykto Hmap fingerGoogle googleSpider webSpider

Grep

collectCookies directoryIndexing findComments pathDisclosure strangeHeaders

Affichage

console htmlFile textFile

Modificateur de requête

sed, un éditeur de requête http

Evasion

reversedSlashes rndCase rndHexEncode

Attaque

37

davShell fileUploadShell googleProxy mysqlWebShell [10]

4.Conclusion

La démarche de l’audit sécurité est primordiale pour un administrateur sécurité, ça reste une étape incontournable pour démarquer les failles Web sur un site Web bien donné. La partie suivante constitue le volet pratique de notre projet et il va contenir l’ensemble des tests qu’on a effectués ainsi que les résultats issus de chaque test. voir la partie audit sécurité au niveau de la maquette

Chapitre 2 Mise en place de la maquette de test

38

I. MISE EN PLACE DE LA MAQUETTE DE TEST

Ce chapitre définit l’architecture globale du banc d’essai déployé dans le cadre de ce projet. De plus, il soulève les problèmes d’implémentation du WAF, propose les modifications à y apporter et explique comment celles-ci ont été effectuées. Ensuite, la configuration et la mise en place de la totalité de l’architecture finale.

1.Environnement du travail

Figure I-22 L’environnement du test

1.1. Mise en place du site intranet

Installation de Apache/PHP/MYSQL & PHPMYADMIN sous Debian

Installation d’apache2 et PHP4

Ces paquets installent apache 2.2, php4  :

# aptitude install apache2 php4 libapache2-mod-php4

Cette installation, doit installer par dépendance les paquets suivants :

39

apache2-mpm-prefork apache2-utils apache2.2-common libapache2-mod-php4 libapr1 libaprutil1 php4-common

Avec Apache vers 2.3, les modules disponibles sont dans le dossier « /etc/apache2/mods-available/ » et les modules activés sont dans le dossier « /etc/apache2/mods-enabled/ ».

Si le module php4 n’est pas chargé, il faut le charger avec la commande suivante :

# a2enmod php4

Après chaque modification de la configuration, il faut redémarrer (ou reloader) Apache :

# /etc/init.d/apache2 restart

Pour valider qu’Apache fonctionne correctement, il faut saisir l’adresse suivante dans un navigateur :

http://localhost // On doit avoir comme résultat « it works »

Installation de Mysql

Voici la procédure basique pour créer une base vide et protéger l’accès root par un mot de passe.C’est une base obligatoire pour installer d’autres logiciels qui utilisent MySQL, qu’ils soient ou non « packagés » Debian.

Le principe est simple :

apt-get install mysql-server mysql-client

En fin de manipulation, vous pourrez vous connecter à la base MySQL pour contrôler que tout est ok :

intelcom:~# mysql -u root

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 5 to server version: 4.1.14-Debian_6-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show databases;

+----------+

| Database |

+----------+

40

| mysql |

| test |

+----------+

2 rows in set (0.00 sec)

mysql> quit

Bye

Afin de protéger votre base de données, on crée un password au compte root. Notez que le compte root de la base n’a rien à voir avec le compte root de votre Linux :

mysql -u root

puis :

SET PASSWORD FOR 'root@localhost' = PASSWORD('mon_mot_de_passe_en_clair');

FLUSH PRIVILEGES;

quit;

Ensuite, pour vous connecter à la base, comme le « root@localhost » possède maintenant un mot de passe, il vous faudra préciser « -p » sur la ligne de commande pour qu’il demande ce mot de passe.

Installation de PHPMYADMIN

Cet outil développé en PHP vous sera très utile pour administrer et gérer vos bases de données.

apt-get install phpmyadmin

Taille totale : 9486 ko.

Ensuite vous aurez accès à phpMyAdmin en tapant dans la barre d'adresse http://127.0.0.1/phpmyadmin/ après avoir redémarré le serveur Apache.

Connectez-vous en tant que root.

41

Vous avez alors la possibilité de créer des bases de données, de gérer les privilèges, donc de créer des utilisateurs et de leur donner des droits sur ces bases... amusez-vous bien.

Après la vérification du bon déroulement de l’installation, nous aurons à mettre en place notre site Web, nous n’aurons pas besoin à des outils très complexes , juste un éditeur de texte de type Notepad plus d’un navigateur web simple suffisent pour le créer .Au travail !

1.2. Le site Web

Le site intranet www.intelcom.ma. sera une vitrine pour accéder aux différents services à savoir le service mail , service de base de données , service LDAP etc…La technologie utilisée pour réaliser des pages statiques est « html » et pour aborder le coté dynamique nous aurons à utiliser le langage PHP.

L’arborescence du site sera de la forme suivante :

Figure I-23 L’arborescence du site

Remarque

Pour renommer le nom de domaine de la machine de « localhost » vers www.intelcom.ma

42

Figure I-24 Renommer le nom de domaine du serveur Web

Pour le backend nous allons créer une base de données mysql de tous les utilisateurs ayant accès à notre site.

On accède à l’interface PHPMYADMIN par le biais de l’URL http://www.intelcom.ma/phpmyadmin On crée notre base de données appelée « test »

Figure I-25 Création de la base de données des utilisateurs

On crée par la suite une table d’utilisateurs qui comporte 3 champs :

Figure I-26Création de 3 champs pour la table Users

Le Id, le login , et le password.

On la remplie avec quelques exemples :

43

Figure I-27 Remplissage de la base de données

Maintenant notre portail intranet est prêt et voilà son interface :

Figure I-28 Portail Intranet de l’entreprise

Un nouveau visiteur sera invité à trancher entre deux choix :

Soit à entrer directement sur le site mais il doit d’abord s’authentifier auprès du serveur.

Soit s’inscrire comme nouvel utilisateur à travers un formulaire d’inscription.

1.3. L’application JEE

Base de données

44

Nous allons créer la base de données et saisir quelques exemples d’utilisateurs au niveau de PHPmyadmin

Figure I-8 Table Persons

Page index.html

Page Ajouter.jsp

45

Page Authentifier.jsp

1.4. Mise en place de ModsecurityInstallation

Toutes les commandes données nécessitent d’être super utilisateur « root ».

Avant de pouvoir récupérer le service ModSecurity, un certain nombre de paquets doivent être installé pour permettre à ModSecurity de s’exécuter. Leur installation se lance à l’aide de la commande suivante :

aptitude install libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev build-essential

Une fois installé, on télécharge la dernière version de ModSecurity directement sur le site. Pour accéder aux téléchargements, vous devez créer un compte gratuitement.

Pour le télécharger directement sur le serveur dans le répertoire temporaire, vous pouvez utiliser les commandes suivantes, en ayant récupérer au préalable l’url sur l’archive :

cd /tmp

wget https://bsn.breach.com/downloads/t=92bc195870d2caf0bacd6e6e8c5aa76f/modsecurity-

apache/modsecurity-apache_2.5.7.tar.gz

Une fois ModSecurity récupéré, il faut de le désarchiver à l’aide de la commande suivante

tar zxvf modsecurity-apache_2.5.x.tar.gz

46

On se place à l’intérieur du répertoire créé lors de l’extraction :

cd modsecurity-apache_2.5.x/apache2/

On lance le processus de compilation de ModSecurity et on demande que les fichiers soient installés automatiquement :

./configure && make && make install

Configuration

Il faut maintenant configurer apache pour permettre au module ModSecurity d’être chargé. On crée donc un fichier de chargement :

nano /etc/apache2/mods-available/mod-security2.load

Dans le fichier, on ajoute les lignes suivantes afin d’indiquer à Apache où se trouve les bibliothèques requises par ModSecurity

LoadFile /usr/lib/libxml2.so

LoadFile /usr/lib/liblua5.1.so.0

LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

On quitte le fichier et on active les modules ModSecurity et unique_id :

a2enmod mod-security2

a2enmod unique_id

On spécifie dans la configuration du module ModSecurity où se trouve les fichiers ses propres fichiers de configuration

nano /etc/apache2/conf.d/mod-security2.conf

On ajoute cette ligne puis on quitte :

Include /etc/modsecurity2/*.conf

Il faut maintenant créer les répertoires qui contiendront les fichiers journaux de ModSecurity

mkdir /etc/modsecurity2

mkdir /etc/modsecurity2/logs

touch /etc/modsecurity2/logs/modsec_audit.log

touch /etc/modsecurity2/logs/modsec_debug.log

On copie les règles de ModSecurity et ses fichiers de configurations dans le répertoire dédié :

47

cp /tmp/modsecurity-apache_2.5.x/rules/*.conf /etc/modsecurity2

On indique l’emplacement pour les fichiers journaux dans le fichier de configuration de ModSecurity

nano /etc/modsecurity2/modsecurity_crs_10_config.conf

Trouver la ligne SecDebugLog logs/modsec_debug.log

Remplacer par SecDebugLog /etc/modsecurity2/logs/modsec_debug.log

Trouver la ligne SecAuditLog logs/modsec_audit.log

Remplacer par SecAuditLog /etc/modsecurity2/logs/modsec_audit.log

Une fois la configuration terminée, quittez le fichier de configuration et lancez l’utilitaire de validation de configuration Apache pour vérifier les éventuelles erreurs :

apache2ctl configtest

Cette commande doit vous retourner « Syntax OK ». On peut maintenant redémarrer le serveur Apache pour activer les modifications que nous venons d’effectuer.

/etc/init.d/apache2 restart

Pour vérifier que ModSecurity est lancé vous pouvez taper la commande suivante :

cat /var/log/apache2/error.log | grep ModSecurity

[Sat Dec 20 17:38:12 2008] [notice] ModSecurity for Apache/2.5.7 (http://www.modsecurity.org/)

configured.

Tester Modsecurity

La première étape pour tester le bon fonctionnement de notre WAF est de créer une petite page html au niveau du /var/www appelée «  secret.html »[11]

La page marche parfaitement au niveau du site.

Figure I-29 Création d’une page de test « secret.html »

48

Rendez-vous sur notre fichier de configuration de Modsecurity :

1) Activons le Modsecurity comme le va montrer cette figure 2) Ajoutons la règle suivante

Figure I-30 Activer Modsecurity

Figure I-31Ajout de la première règle de filtrage

Redémarrons Apache :

Le résultat :

Figure I-32 La page « secret.html « après la règle de filtrage

La règle veut dire tout simplement d’interdire n’importe quel accès à une page dont l’URL comporte le mot «  secret »

49

2.Simulation d’attaques en présence et en absence du WAF

2.1. Injection SQL

Supposons que notre visiteur n’est pas du genre visiteur gentil mais son ultime but est de trouver une faille susceptible de le donner un accès root à notre base de données. C’est au niveau du formulaire d’authentification qu’il va jouer sa malice à savoir des requêtes malveillantes intentionnelles, parce que grâce à la comparaison entre le login et le password transmis par la méthode POST qu’il va essayer de leurrer notre code PHP. Justement la requête sera tout à fait juste mais d’une manière illégitime.

Sans Modsecurity

Rendez-vous à notre page d’authentification et abordons notre première attaque WEB .Essayons de s’authentifier par un utilisateur qui existe déjà sur la base de données de notre site :

Exemple   :nasredine et password   :1111

Figure I-33 L’utilisateur aura accès au site parce qu’il est déjà inscrit 

Si l’utilisateur n’est pas inscrit sur le site comme le cas de :

Exemple   : anonyme et password   :anonyme

Alors il aura comme réponse :

Figure I-34 Réponse du site pour une personne n’est pas enregistrée dans la base des utilisateurs

50

Essayons d’écrire la requête suivante : Login= « ‘ OR 1=1 ; --test »  et écrivons ce que nous voulons au niveau du password :Le résultat magique est le suivant :

Figure I-35 Réponse du site pour la dernière requête

Le login n’est pas enregistré au niveau de la base de données et pourtant nous avons pu nous logger auprès du site.Ce n’est pas sorcier et en fait la science ne croit jamais à la sorcellerie.Revenons à notre fameux code « auth.php »Essayons de zoomer un petit peu cette phrase parce qu’elle est si importante :

Elle veut dire tout simplement : On choisit tous les champs de la table users à condition que le nom soit déjà dans la database , la même chose pour le password

Injectons notre dernière formule magique sur cette requête alors on aura comme résultat :

Donc la requête est toujours juste et la personne malveillante a le droit d’accéder à votre site d’un point de vue scientifique mais illicitement.

Avec Modsecurity

Nous allons fouiller un petit peu au niveau du fichier de configuration de Modsecurity pour activer ce module et le tester.

Rendez-vous au fichier modsecurity_crs_10_config.conf qui se trouve au niveau de /etc/modsecurity2

Un petit gedit et voilà :

51

Figure I-36 Le fichier modsecurity_crs_10_config.conf

On active Modsecurity :

SecRuleEngine On

Revenons à notre fameuse requête méchante «  SQL injection », heureusement que notre garde-corps est assez puissant pour annuler ses dégâts imprévus, en fait ce n’est pas que le fichier « modsecurity_crs_10_config.conf » qui existe pour configurer notre WAF :

On trouve aussi :

Figure I-37L’ensemble des fichiers de configuration de Modsecurity

On ouvre le fichier modsecurity_crs_40_generic_attacks.conf

Et on va ajouter une liste noire de toutes les saisies bannies et élues pour être des attaques SQL Comme ceci :

52

Figure I-38 LA liste noire à ajouter pour l’injection SQL

En fait cette dernière saisie n’est que le fruit du Core Rule Set (CRS) les mises à jour des dernières règles de Modsecurity et ce n’est que parmi les avantages qu’on a décrit et qui favorise l’utilisation de Modsecurity par rapport aux autres produits.

Rendez-vous à la page d’authentification et testons notre nouvelle configuration :

Figure I-39 L’agissement de ModSecurity suite à l’injection SQL

“ YOU DON’T HAVE PERMISSION TO ACCESS   /auth.php “

C’est finis l’histoire de ces petites bestioles d’injections SQL. Notre WAF marche parfaitement bien et on est sur de bloquer ces types d’attaques.

Deuxième bataille avec les attaques XSS.

2.2. Attaques XSS

Sans Modsecurity

Rendez-vous à la page index_xss.php et testons notre attaque :

53

Figure I-40 LA page index_xss.php avant l’injection

Testons le script java <script> alert(‘injection JS’)</script> et Regardons le résultat :

Figure I-41 La page index_xss.php après l’injection

C’est un code javascript saisis à partir d’une case présumée de contenir juste des mots simples pour la recherche .C’est un exemple simple mais en cas d’exécuter des scripts malveillants qui peuvent installer des logiciels ou des modules douteux comme c’est le cas des fenêtres POPUP , ça deviendra très dangereux et peuvent déstabiliser votre machine et son bon fonctionnement .

Avec Modsecurity

On active modsecurity :

SecRuleEngine On

Revenons à notre fameux fichier modsecurity_crs_40_generic_attacks.conf et ajoutons une liste noire de toutes les chaines de caractères y compris des scripts qui peuvent présenter pour Modsecurity une véritable menace.

Figure I-42 La liste noire à ajouter pour l’injection XSS

54

Revenez à la page index_xss.php Ressaisissez le même script Le résultat :

Figure I-43 L’agissement de Modsecurity suite à une attaque XSS

Le résultat est clair c’est interdit d’accéder au site par le biais de cette attaque.

2.3. File Uploading

Figure I-44 La réaction de Modsecurity suite au transfert d’un fichier exécutable

Sans Modsecurity le site vérifie juste la présence ou l’absence du fichier exécutable (qui peut présenter un grand degré de dangerosité surtout avec l’envahissement de la toile Internet par des virus et des trojans de plusieurs types). Mais en sa présence Notre WAF considère que le transfert de ce fichier est interdit et ne peut pas l’implémenter.

2.4. Directory Traversal

Premier scénario

Supposons que l’attaquant veut découvrir l’ensemble des mots de passe dans un serveur Web alors il cherchera sans doute le fichier passwd contenu dans le répertoire etc, c’est ce qu’on appelle attaque «  Directory Traversal » ou attaque «  traversée des répertoires »

Figure I-45 La réaction de Modsecurity suite à une attaque Directory Traversal ( premier scénario)

55

Deuxième scénario

Supposons que l’attaquant a su que le backend du site est basé sur PHPMYADMIN à travers l’ingénierie sociale ou par une méthode quelque part alors il consultera la base de données pour chercher l’ensemble des admins et leurs passwords et peut par conséquent la détruire ou la supprimer. Comparons les résultats en présence et en absence de notre WAF :

Figure I-46 La réaction de Modsecurity suite à une attaque Directory Traversal (deuxième scénario)

On remarque que notre WAF bloque les attaques les plus connues, mais ça n’empêche pas de le mettre à jour chaque fois par des règles issues du Core Rule Set récent.

Il faut mentionner aussi une chose que les attaques qu’on avait lancées ne se sont passées inaperçues, en effet Modsecurity offre une possibilité comme la majorité des produits de sécurité commerciaux d’archivation à travers des fichiers logs , nous avons créé au début un répertoire réservé pour les rassembler , on la nommé log il se trouve dans etc/modsecurity2/

Rendez-vous sur le répertoire logs et identifions les traces des différentes attaques Ouvrons le fichier modsec_debug.log :Nous allons identifier les différentes tentatives d’attaques :La première règle qu’on a définie :

Figure I-47 La trace de la première attaque sur le fichier log modsec_debug.log

Les accès interdits par Directory traversal et file uploading

56

Figure I-48 La trace des attaques File uploading et Directory Traversal

Le Tag « Protocol_Violation » veut dire que nous avons essayé de transférer un fichier ou passer sur un répertoire par le biais du protocole http d’une façon illicite.

Les traces des différentes attaques

L’injection SQL

Figure I-49 La trace de l’attaque SQL injection

C’est une attaque Web : SQL injection avec degré de sévérité critique

Remarque

Le champ [data « OR 1= »] est l’information sur laquelle s’est basée Modsecurity pour savoir s’il s’agit d’une attaque SQL en consultant sa base de données interne.

L’attaque XSS

Figure I-50 La trace de l’attaque XSS

Remarque

Le champ [data « <script »] est l’information sur laquelle s’est basée Modsecurity pour savoir s’il s’agit d’une attaque SQL en consultant sa base de données interne .

La journalisation log marche correctement mais pour un administrateur réseaux et sécurité, C’est difficile de revenir chaque fois vers ces fichiers et de chercher entre les lignes les attaques et leurs dates, c’est pour cela qu’il faut penser à la mise en œuvre d’une console qui facilite son travail d’une manière plus détaillée et plus signifiante et ça sera l’objet de notre prochain paragraphe.

3.La console d’audit

Installation de tomcat sous Debian

57

# Nous partirons du principe que vous installez Tomcat dans /usr/local/jakarta-tomcat-4.1.29

# Décompressez le binaire téléchargé :

[root@linux /]$ tar -xzvf jakarta-tomcat-4.1.29.tar.gz -C /usr/local

# Créez un lien symbolique :

[root@linux /]$ cd /usr/local

[root@linux /]$ ln -s jakarta-tomcat-4.1.29 tomcat

# Créez un compte utilisateur pour l'exécution de Tomcat (avec shell et home) :

[root@linux /]$ useradd tomcat

# Placez les variables d'environnements nécessaires à Tomcat :

[root@linux /]$ echo 'export JAVA_HOME=/usr/java' >> /home/tomcat/.bash_profile

[root@linux /]$ echo 'export PATH=$PATH:$JAVA_HOME/bin' >> /home/tomcat/.bash_profile

[root@linux /]$ echo 'export CATALINA_HOME=/usr/local/tomcat' >> /home/tomcat/.bash_profile

# Cette option est utilisé pour forcer java à utiliser l'ISO-8859-1 lors de compilation de pages JSP

[root@linux /]$ echo 'export JAVA_OPTS=-Dfile.encoding=ISO-8859-1' >> /home/tomcat/.bash_profile

# Contrôlez le bon fonctionnement de l'environnement de l'utilisateur tomcat :

[root@linux /]$ su - tomcat -c 'java -version'

[root@linux /]$ su - tomcat -c 'echo $CATALINA_HOME

# Modifiez les droits des répertoires et fichiers de Tomcat :

[root@linux /]$ cd /usr/local/tomcat

[root@linux /]$ chown tomcat.tomcat -R work temp logs conf

Lançons Tomcat depuis le navigateur:

Tapez : http://localhost:8080

58

Figure I-51 Page d’accueil d’apache

Une fois Tomcat installé et bien configuré, nous allons donc importer notre application JEE (.war) qui va effectuer l’audit des fichiers logs issus de Modsecurity.

Rendez-vous sur la page officielle de JWALL :

http://jwall.org/web/audit/console/index.jsp

Figure I-52 Page d’accueil de JWALL audit console

Figure I-53 Téléchargement de la dernière version de la console sous format (.war)

Déploiement

On choisit /opt pour le fichier téléchargé :

# cd /opt

# unzip /path/to/AuditConsole-0.4.1.zip

# cd AuditConsole

59

Et on va déplacer notre application vers le répertoire Webapps pour qu’elle soit déployée

# mv AuditConsole.war /usr/local/tomcat/webapps

Tapons l’URL suivant http://localhost:8080/AuditConsole/

Figure I-54 L’interface de l’authentification

Le login et le password par défaut sont : admin & admin

Et voilà comme page d’accueil de l’audit console :

Figure I-55 Page d’accueil de l’audit console

Allons sur Events=>upload

Figure I-56 Transfert du fichier log

60

Après le transfert du fichier log :

Une interface contenant plusieurs paramètres et plusieurs informations est affichée :

Date de l’attaque Un numéro ID pour l’attaque Degré de sévérité Catégorie de l’attaque Le nom de la règle appliquée

Les différents graphes à droite du tableau montrent la représentation graphique et en temps réel du nombre et du type d’attaques en fonction du temps.

L’ID de chaque attaque est unique pour démystifier le type et la date de l’attaque en cas de présence de plusieurs attaques de même type.

Le degré de sévérité diffère selon les types d’informations cibles et la fréquence d’attaque.

Modsecurity applique pour chaque attaque une règle bien définie en consultant sa base de données CRS .

61

Figure I-57 Le tableau de bord(Dashboard) de la console

La section events affiche plus d’informations sur les attaques par exemple leur degré de sévérité.

Figure I-58 La section events

62

La section reports concerne les rapports : on peut choisir un rapport soit sous format html ou pdf comme le montre cette figure :

Figure I-59 La section reports

Les différents résultats seront comme la suite :

Figure I-60 La réponse de Modsecurity pour chaque hôte

63

Figure I-61 le degré de sévérité des attaques pour chaque hôte

Conclusion de cette partie

Cette partie était pleine de tests, de résultats, ce qui nécessite de donner une conclusion globale de ce que nous avons réalisés ainsi de ce qui nous attend.

Grace à notre WAF nous avons pu bloquer quelques attaques typiques comme les injections SQL , les attaques XSS , le File Uploading etc . Les archives (logs) avec un déploiement de la console (AuditConsole) nous ont fournis la possibilité de concevoir un bilan riche qui contient des informations importantes qui concerne l’attaquant ainsi que l’attaque à travers des graphes et des tableaux significatifs.

4.L’audit sécurité

L'audit de la sécurité informatique a pour but de donner au management une assurance raisonnable du niveau de risque de l'entreprise lié à des défauts de sécurité informatique. Pour ce projet il s’agit d’auditer une application Web à distance afin de compenser les failles Web existantes à travers une démarche proactive.

64

Figure I-62 La distribution Samurai

Après la configuration de notre machine qui va auditer notre site réseau sur l’adresse IP :192.168.0.7

On lance l’utilitaire W3AF :Applications => Samurai => Discovery => W3AF GUI

Figure I-63 L’utilitaire W3AF

Nous choisissons full_audit :On fait entrer l’URL de notre site intranet dans le target :

65

Figure I-64 Saisie de l’adresse URL

Afin d’avoir les résultats les plus précis possible, il est important de bien choisir les options ainsi que les plugins que nous voulons utiliser. Dans notre cas, nous allons utiliser des profils préconfigurés pour réaliser notre scan.

W3af dispose de quatre profils par défaut : - OWASP Top 10 intégrant les plugins d’audit, de découverte et de grep - Fast Scan intégrant les plugins d’audit et de découverte - Full Audit intégrant les plugins d’audit, brute force, découverte et grep - Full audit manual disc intégrant les plugins d’audit, brute force, découverte et grep Afin d’avoir un résultat clair et précis, nous allons commencer par un « Full Audit » Il est donc simplement nécessaire de cliquer sur « Full Audit » dans le menu « Profiles », de préciser l’adresse du site web cible et de lancer l’analyse en cliquant sur « Start »

66

Figure I-65 Scan du site Web

Le travail du testeur sera d’analyser le site Web par des attaques Web, et de vérifier le succès ou l’échec de chacune.

A présent, l’ensemble des plugins se trouvant dans les diverses catégories sélectionné vont s’exécuter un à un pour avoir le plus de résultat possible.

Il est possible grâce à l’onglet « Results » de visualiser rapidement tout ce que w3af a trouvé comme informations, erreurs ou vulnérabilités.

Figure I-66 Résultat du test

W3AF permet aussi d’analyser et d’afficher l’arborescence du site concerné comme le montre cette figure :

67

Figure I-67 L’arborescence du site Web scanné

Dans la section « logs » ,il est également possible d’avoir une interprétation graphique des analyses en cours comme il est possible de le voir ci-dessous. Ce graphique nous montre de nombreux détails comme par exemple le temps (en seconde) de l’analyse réalisé par w3af ou bien encore les modules qui sont exécutés en temps réel.

Figure I-68 La section logs de W3AF

Après quelques minutes, l’analyse du site cible se termine et il est enfin possible d’analyser les résultats que nous propose w3af. Grâce à la barre principale, il est possible de faire un premier filtre très rapide mais tout aussi simpliste sur le type d’information qu’a relevé w3af. Il est possible de sélectionner « Vulnérabilités » et/ou « Information » et/ou « Erreur »

Il est également possible de faire des recherches plus précises grâce à la partie ci-dessous permettant de rechercher des mots ou des bouts de mots dans l’ensemble des informations disponible.

68

Après qu’on terminerait le scan , il faudrait analyser les résultats de l’audit Rendez-vous sur la case « Results » Après « Blind SQL » pour chercher les

failles les failles SQL injections qui se trouvent au niveau du site :

Figure I-69 Exemple d’attaque SQL injection pour l’audit sécurité

Il est possible via cette interface de résumer l’ensemble des informations que w3af a réussi à trouver sur l’ensemble du site cible.

Il est par exemple très facile grâce à cette interface d’identifier des vulnérabilités de type Injection XSS, injection SQL. Tout comme pour les logs, il est possible de filtrer les résultats en fonctions de leur type (Vulnérabilités, informations et problème de configuration) afin d’avoir la possibilité d’effectuer un rapide coup d’œil sur les problèmes potentiels.

Des informations plus précises sont présentes dans la partie de droite permettant de comprendre quelle page est vulnérable et à quel type d’attaque. Il nous est également possible de voir les requêtes envoyées au serveur ainsi que les réponses de ce dernier pour des possibles modifications via les plugins prévus à cet effet.

Dernièrement, l’onglet « Exploit », nous permet simplement de savoir quel plugin a réussi à trouver la vulnérabilité que nous allons tenter d’exploiter.

Figure I-70 Les plugins responsables de la détection des injections SQL

69

Conclusion

En conclusion, Web Application Attack and Audit Framework est un framework d’audit et d’exploitation des vulnérabilités des applications web extrêmement complet, pratique et simple d’utilisation.

Tant son interface graphique que sa ligne de commande sont réellement complet et permettent aux professionnels de la sécurité des systèmes d’informations des audits de qualités et extrêmement précis.

A noter également que w3af est présent dans l’excellente distribution entièrement consacrée au test de pénétration des applications web : Samurai Web Testing Framework.

CONCLUSION GENERALE

Le présent document est un reflet du travail que j’ai réalisé au cours de mon stage de fin d’études effectué à Intelcom Groupe Satec à Tmara une société qui s’intègre principalement dans le domaine d’intégration des technologies d’information .

En effet j’ai choisis un volet très sensible du l’informatique à savoir la sécurité applicative. La majorité des objectifs mis en avant ont été atteint. En effet, le produit résultant de mes études ainsi de mon approche comparative est un produit OpenSource 100% gratuit .Néanmoins les fichiers logs en résultant restent illisibles et manquent de clarté et de précision ce qui a nécessité d’importer une application J2EE pour la lecture et l’interprétation des fichiers logs .

La partie plateforme s’est basée sur le logiciel « VIRTUALBOX », un logiciel de virtualisation des systèmes d’exploitation.

Tout au long de ce stage, j’ai pu approfondir aussi mes connaissances technologiques, principalement au niveau développement PHP avec un site dynamique pour l’enregistrement et l’authentification des utilisateurs ainsi d’une application JEE (basée sur le modèle MVC marié avec JSP) , administration linux avec les distributions «  DEBIAN » et « SAMURAI ». 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 son stage. Spécialement une intégration totale ainsi qu’un esprit de communication m’ont été indispensables surtout avec la présence de mon maitre de stage Monsieur Hassan Chaib que je le remercie profondément pour ses différents conseils et

70

directives ainsi mon encadrant de l’Ecole Mr Youness Mehdaoui pour ses retouches professionnelles sur mon travail.

Perspectives

Comme perspectives je propose d’adapter la solution WAF à un reverse proxy qui offre à la fois un firewall applicatif, puis une interface intégrée pour lire directement les fichiers logs issus de ModSecurity et 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 avoir recours à des solutions commerciales et payantes.

Je veux aussi proposer l’ajout d’autres modules visant l’automatisationd’autres processus métiers de l’application JEE que j’ai conçue comme l’interfaçage avec le WAF concerné. Et de fournir une mise à jour périodique des résultats auprès du firewall applicatif.

71

Références et bibliographie

[1] http://www.creation-site-toulouse.net/ Article « Qu’est-ce qu’une application Web ? » Mardi, 15 Mars 2011

[2] http://www.ouah.org/chambet.html/ Firewalls et applications Web :architecture et sécurisation Pourquoi les firewalls sont impuissants face aux attaques Web Auteur :Patrick CHAMBET

[3] www.wikepedia.org

[4] http://www.lab.celeste.fr Surfez en toute sécurité ou du moins en toute connaissance Auteur : Thomas Lopez

[5] http://www.securityvibes.fr Bien choisir son WAF Auteur : Jérôme Saiz le 14 août 2008 

[6] http://johanne.ulloa.org/ Le blog de Johanne Ulloa Article « Pourquoi un WAF ? » le 01 Septembre 2009

[7] http://doc.ubuntu-fr.org/virtualbox

[8] Rapport TER Détection d'attaques HTTP coté serveur Auteur : Mathieu BOISSIER, Julien ROUQUETTE, Benoit MILLION, Olivier VERGES 9 Janvier - 18 Mai 2007

72

[9] Travail de semestre sécurité des applications Web Auteur :Sylvain Tissot le 27 juillet 2003

[10] Introduction à W3AF Auteur :Regis Senet

[11] «  Modsecurity 2.5 User Guide » by Ivan Rystic le 3 Février 2010

Annexes

Annexe A :

mod_security peut être utilisé en tant que relais inverse plutôt que intégré à chaque serveur à protéger. Ceci permet ainsi de protéger plusieurs serveurs Web même si ces derniers ne sont pas des Apache.

Ceci peut être fait en couplant un ensemble de modules tels qu mod_security, mod_proxy, mod_rewrite, mod_dosevasive ou mod_headers.

Dans le cas de l'utilisation de mod_security en relais inverse, l'architecture ci-dessous peut très bien être envisageable:

mod_security Serveur Web + (IIS, Apache, Iplanet) Pare-feu mod_proxy _____ ____ __ 443 | | | | | |Client <--------->| |<-------->| |<---------->| | Web 80 |_____| |____| |__|

Annexe B:

La configuration de mod_security peut s'effectuer par l'intermédiaire du fichier modsecurity.conf. Une directive doit alors être rajoutée dans le fichier de configuration httpd.conf de Apache:

Include conf/modsecurity.conf

73

L'activation de mod_security afin de normaliser les requêtes effectuées sur le serveur Web se fait grâce à la variable SecFilterEngine dans le fichier modsecurity.conf:

SecFilterEngine On

L'activation des fonctionnalités de mod_security peut également être faite uniquement pour le contenu dynamique: SecFilterEngine DynamicOnly

Une fois activé, mod_security interceptera et vérifira toutes les requêtes entrantes sur le serveur Web. Les requêtes seront ensuite passées aux filtres définis par l'utilisateur et seront soit acceptées, soit refusées.

Les lignes suivantes sont à rajouter dans le fichier modsecurity.conf afin d'effectuer certaines actions:

- Interception des requêtes POST: SecFilterScanPOST On

- Changer l'identité du serveur Web Apache: SecServerSignature "Apache/1.3.33 (Darwin)"

- Pour les applications web, seuls les encodages application/x-www-form-urlencoded et multipart/form-data sont utilisés. Il est possible de spécifier que seules les requêtes avec ces deux encodages soient acceptées: SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)"

- Prévention contre le chunked transfer encoding: SecFilterSelective HTTP_Transfer-Encoding "!^$"

- Prévention contre les URL mal encodées (typiquement pour ne pas violer le système de numérotation hexadécimale, ou pour vérifier qu'une chaîne Unicode est valide): SecFilterCheckURLEncoding On SecFilterCheckUnicodeEncoding On

- Prévention contre les attaques par débordement de tampon en limitant la quantité d'octets autorisés dans les chaînes de requêtes (par exemple, si le langage utilisé dans les applications est l'anglais, limiter le byte range à 32-126): SecFilterForceByteRange 32 126

- Interdire les requêtes invalides avec un statut erreur 400 et journaliser cette action: SecFilterDefaultAction "deny,log,status:400"

- Journaliser les actions et les requêtes suspectes: SecAuditEngine RelevantOnly SecAuditLog /var/www/logs/audit_log

Annexe C:

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,

74

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 (REMOTE_ADDR, QUERY_STRING, COOKIES_VALUES, etc...): SecFilterSelective QUERY_STRING MOT_RECHERCHE

Les exemples suivants sont intéressants pour se faire une idée sur l'écriture des règles:

- 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 SecFilterSelective HTTP_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:

75

SecFilterSelective REMOTE_ADDR 12\.148\.163\.152

Annexe D:

Les codes sources de l’application JSP :

Page index.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

<title>Gestion des utilisateurs</title><link rel="stylesheet" href="css/style.css" type="text/css"

media="all" /><script src="js/jquery-1.4.1.min.js"

type="text/javascript"></script><script src="js/jquery.jcarousel.pack.js"

type="text/javascript"></script><script src="js/jquery-func.js"

type="text/javascript"></script></head><body><div id="page" class="shell">

<!-- Logo + Search + Navigation --><div id="top">

<div class="cl">&nbsp;</div><h1 id="logo"><a href="#">Intelcom</a></h1><form action="" method="post" id="search">

<input type="submit" class="button" value="Search" />

<div class="cl">&nbsp;</div></form><div class="cl">&nbsp;</div><div id="navigation">

<ul> <li><a href="index.html"

class="active"><span>Acceuil</span></a></li> <li><a href="ajouter.jsp"><span>Add a new user

</span></a></li> <li><a href="supprimer.jsp"><span>

Authentication</span></a></li> <li><a href="propos.html"><span>By Nasredine

Boujmil</span></a></li></ul>

</div></div>

<!-- Main --><div id="main">

<!-- Three Column Content --><div class="cols three-cols">

<div class="cl">&nbsp;</div><div class="col">

76

<h2>Veuillez s'enregistrer sur le site</h2><h3 class="notext txt-monday-again">INTELCOM

Group SATEC</h3><p></p><p><a href="ajouter.jsp"

class="more">S'enregistrer </a></p></div><div class="col">

<h2>Intelcom Services</h2><h3 class="notext txt-wedothis">WE DO THIS

AND THAT....</h3><p>SATEC has a wide range of solutions that

focus on technological excellence, contributing to the development of the core business of its customers.</p>

<p><a href="#" class="more">Learn more</a></p>

</div><div class="col col-last">

<h2>Intelcom Support</h2><h3 class="notext txt-247">24/7 YES

REALLY...</h3><p>The Social Responsibility policy SATEC,

was born of our vocation and our effort to be a respected and valued member of the Communities that surround us. It is the focus of our mission-oriented value creation and hence sustainable development and the creation and distribution of wealth that will flow from, social commitment, respect for people and protection of environment.</p>

<p><a href="#" class="more">Learn more</a></p>

</div><div class="cl">&nbsp;</div>

</div><!-- END Three Column Content --><!-- Two Column Content --><div class="cols two-cols">

<div class="cl">&nbsp;</div><div class="col">

<h2>Developped by :</h2><p><b>Nasredine Boujmil </b> a Networks,

security Engineer from The National School of Applied Sciences. Trainee in Intelcom Groupe Satec</p>

<p><a href="#" class="more">Learn more</a></p>

</div><div class="col col-last">

<h2>Supervised by </h2><p> thanks to<b> Hassan Chaib </b>: Security

Engineer in Intelcom Groupe Satec</p><p><a href="#" class="more">Learn

more</a></p></div><div class="cl">&nbsp;</div>

</div><!-- END Two Column Content -->

</div><!-- END Main --><!-- Footer --><div id="footer">

<p class="right">&copy; 2012 - Intelcom Satec Groupe &nbsp; Design by Nasredine Boujmil Networks and Telecom Engineer</p>

<div class="cl">&nbsp;</div>

77

</div><!-- END Footer --><br />

</div></body></html>

Couche métier

Person.java

package metier;

public class Person {private long id ;private String nom,age,adresse,password;public Person() {super();// TODO Auto-generated constructor stub}public Person(long id, String nom, String age, String adresse, String password) {super();this.id = id;this.nom = nom;this.age = age;this.adresse = adresse;this.password = password;}public long getId() {return id;}public void setId(long id) {this.id = id;}public String getNom() {return nom;}public void setNom(String nom) {this.nom = nom;}public String getAge() {return age;}public void setAge(String age) {this.age = age;}public String getAdresse() {return adresse;}public void setAdresse(String adresse) {this.adresse = adresse;}public String getPassword() {return password;}public void setPassword(String password) {

78

this.password = password;}

}

Operation.java

package metier;

import java.sql.DriverManager;import java.sql.ResultSet;import java.util.ArrayList;import com.mysql.jdbc.Connection;import com.mysql.jdbc.PreparedStatement;

public class Operation {

public Operation() {super();

}private ArrayList<Person> persons = new ArrayList<Person>();

public ArrayList<Person> getPersons() {return persons;

}

public void setPersons(ArrayList<Person> persons) {this.persons = persons;

}public void add (Person p )

{

try {Class.forName("com.mysql.jdbc.Driver");

java.sql.Connection cn = DriverManager.getConnection("jdbc:mysql://localhost:3306/gestionperson" ,"root","" );

java.sql.PreparedStatement pr = cn.prepareStatement("INSERT INTO person VALUES (NULL,?,?,?,?)");

pr.setString(1, p.getNom());pr.setString(2, p.getAge());pr.setString(3, p.getAdresse());pr.setString(4, p.getPassword());

79

pr.execute();}

catch (Exception e) {// TODO Auto-generated catch blocke.printStackTrace();

}}public void remove (Long id){

try {//1Class.forName("com.mysql.jdbc.Driver");//2

java.sql.Connection cn = DriverManager.getConnection("jdbc:mysql://localhost:3306/GestionPerson" ,"root","" );

//3 java.sql.PreparedStatement pr = cn.prepareStatement("DELETE

FROM person where id=?"); pr.setLong(1,id); //4 pr.execute();

} catch (Exception e) {// TODO Auto-generated catch blocke.printStackTrace();

}}public ArrayList<Person> getAll(){

ArrayList<Person> list = new ArrayList<Person>();try {

//1Class.forName("com.mysql.jdbc.Driver");//2

java.sql.Connection cn = DriverManager.getConnection("jdbc:mysql://localhost:3306/gestionperson" ,"root","" ); //3 java.sql.PreparedStatement pr = cn.prepareStatement("SELECT * FROM person"); //4 ResultSet rs = pr.executeQuery(); //5 while (rs.next()) {Person p = new Person();

80

p.setId(rs.getLong("id")); p.setNom(rs.getString("nom")); p.setAge(rs.getString("age")); p.setAdresse(rs.getString("adresse")); p.setPassword(rs.getString("password")); list.add(p); } } catch (Exception e) {

// TODO Auto-generated catch blocke.printStackTrace();}

return list;}

public String auth(String nom , String password)

{String Message="";try {

Class.forName("com.mysql.jdbc.Driver");java.sql.Connection cn =

DriverManager.getConnection("jdbc:mysql://localhost:3306/GestionProduit" ,"root","" );

java.sql.PreparedStatement pr = cn.prepareStatement("SELECT * FROM person WHERE '"+nom+"' and password='"+password+"'");

ResultSet rs = pr.executeQuery();int count=0;

while(rs.next()) { count++; } if(count>0) { Message= "welcome"+nom; } else { Message= "invalide user ou mot de passe ressayez"; }

} catch (Exception e) {e.printStackTrace();

}return Message; }}

Couche Web

PersonBeans.java

package web;

81

import java.util.ArrayList;

import metier.Person;

public class Personbeans {

public Personbeans() {

super();

}

private Person person = new Person();

private ArrayList<Person> liste = new ArrayList<Person>();

public Person getPerson() {

return person;

}

public void setPerson(Person person) {

this.person = person;

}

public ArrayList<Person> getListe() {

return liste;

}

public void setListe(ArrayList<Person> arrayList) {

this.liste = arrayList;

}

}

PersonServlet.java

package web;import java.io.IOException;import javax.servlet.ServletException;import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;

import metier.Operation;import metier.Person;import web.Personbeans;

82

public class PersonServlet extends HttpServlet{

private Operation op;

public void init() throws ServletException {op =new Operation();super.init();

}protected void doPost(HttpServletRequest req, HttpServletResponse

resp)throws ServletException, IOException {

//Récupérer les données String nom=req.getParameter("nom");String age=req.getParameter("age");String adresse=req.getParameter("adresse");String password=req.getParameter("password");

Person p = new Person(1L, nom, age, adresse, password);op.add(p);Personbeans pb = new Personbeans();pb.setListe(op.getAll());req.setAttribute("modele", pb);req.getRequestDispatcher("ajouter.jsp").forward(req, resp);}}

Le fichier Web.xml

<?xml version="1.0" encoding="UTF-8"?><web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0"> <display-name>Intelcom</display-name> <servlet>

<servlet-name>sp</servlet-name><servlet-class>web.PersonServlet</servlet-class>

</servlet><servlet-mapping>

<servlet-name>sp</servlet-name><url-pattern>/prodserv</url-pattern>

</servlet-mapping></web-app>