Universit´e Montpellier II D´epartement Informatique
Responsables du projet : Master Informatique
Abdelkader Goua¨ıch, Premi`ere Ann´ee
Marc Plantevit, Chedy Ra¨ıssi
Rapport TER
D´ etection d’attaques HTTP (cˆ ot´ e serveur)
9 Janvier - 18 Mai 2007
Mathieu BOISSIER Benoˆıt MILLON
Julien ROUQUETTE Olivier VERGES
Table des mati`eres
1 Introduction 6
1.1 Pr´esentation g´en´erale . . . 6
1.2 Probl´ematique . . . 6
1.3 Contraintes . . . 7
2 Organisation du projet 8 2.1 Environnement de d´eveloppement . . . 8
2.1.1 Jeu de donn´ees . . . 8
2.1.2 Langages et outils de d´eveloppement . . . 8
2.2 Planification des tˆaches . . . 10
2.3 R´epartition des tˆaches . . . 10
3 Pr´erequis 11 3.1 Concepts importants . . . 11
3.1.1 Notions sur les ontologies . . . 11
3.1.2 Notions li´ees `a la partie analyseur . . . 13
3.1.3 Notions de classification et d’apprentissage . . . 13
4 Etat de l’art 16 4.1 Les attaques Web les plus courantes . . . 16
4.1.1 Modifications d’URLs . . . 16
4.1.2 Injections de commandes . . . 16
4.1.3 Injections SQL . . . 16
4.1.4 Cross-Site Scripting (XSS, CSS) . . . 17
4.1.5 Violations de contrˆole d’acc`es . . . 17
4.1.6 Buffer Overflow . . . 17
4.1.7 Traitements inappropri´es des erreurs . . . 17
4.1.8 Directory Traversal . . . 18
4.1.9 D´enis de service (DoS) . . . 18
4.1.10 Exploitations de vuln´erabilit´es encore inconnues . . . 18
4.2 Les diff´erentes techniques de protection . . . 18
4.2.1 Utilisation de listes blanches/noires d’URLs (s´ecurit´e positive) . . . 18
4.2.2 L’apprentissage . . . 19
4.2.3 Les pare-feux . . . 20
4.2.4 Les syst`emes de d´etection d’intrusion (IDS) . . . 20
4.2.5 Les syst`emes de pr´evention d’intrusion (IPS) . . . 20
4.2.6 L’authentification forte . . . 21
4.2.7 Les pots de miel (honeypots) . . . 21
TABLE DES MATI `ERES
4.3 Les logiciels de protection . . . 21
4.3.1 SG800 . . . 21
4.3.2 Deny All . . . 21
4.3.3 Mod Security . . . 21
4.3.4 SNORT . . . 22
4.4 Les limites des moyens de d´etection . . . 22
4.4.1 Limites des Pare-feu applicatifs . . . 22
4.4.2 Limites des IDS . . . 22
4.4.3 Limites des IPS . . . 23
4.5 Ontologies et s´ecurit´e . . . 23
4.5.1 NRL Security Ontologie . . . 23
4.5.2 Les dif´erentes ontologies . . . 23
4.6 Conclusion de l’´etat de l’art . . . 24
5 Notre contribution 25 5.1 Vision globale de l’application . . . 25
5.1.1 Diagramme de s´equence de l’application . . . 25
5.2 Le module ontologie . . . 26
5.2.1 Rappel . . . 26
5.2.2 Mod´elisation typ´ee Syst`eme d’Exploitation . . . 26
5.2.3 Mod´elisation avec des ´etiquettes simples . . . 28
5.2.4 Mod´elisation avec des ´etiquettes composites . . . 30
5.3 Analyseur . . . 32
5.3.1 Analyseur . . . 33
5.3.2 Post-traitement . . . 34
5.3.3 Etiqueteur . . . 35
5.4 Classifieur . . . 38
5.4.1 Arbre de d´ecision g´en´er´e par algorithme C4.5 . . . 38
5.4.2 Le classifieur na¨ıf de Bayes . . . 38
5.4.3 Classification d’une requˆete apr`es apprentissage . . . 38
5.5 Int´eraction entre les composantes . . . 40
5.5.1 Interaction Analyseur-Etiqueteur . . . 40
5.5.2 Tableau de signature conceptuelle . . . 41
6 Exp´erimentations 42 6.1 Plateforme d’exp´erimentations . . . 42
6.2 Tests globaux sur l’application . . . 42
6.2.1 Dur´ee de classification . . . 42
6.3 R´esultats des tests d’apprentissage . . . 43
6.3.1 Variation du nombre de r`egles de CYK . . . 43
6.3.2 Variation du nombre de donn´ees . . . 43
6.3.3 variation du type des donn´ees . . . 43
6.4 Conclusion des tests . . . 44
7 Conclusion 45 7.1 Bilan du groupe . . . 45
7.2 Perspectives . . . 45
7.2.1 Am´elioration des composantes de l’application . . . 46
7.2.2 Am´elioration de l’application en g´en´eral . . . 46
A Glossaire 47
Table des figures
2.1 Diagramme de Gantt . . . 10
3.1 Exemple de mod´elisation RDF . . . 12
3.2 Validation crois´ee `a 10 plis sur un jeu de donn´ees . . . 15
4.1 Illustration de diverses attaques connues . . . 19
4.2 Installation d’un IDS . . . 20
5.1 Diagramme de s´equence g´en´eral de la classification d’une requˆete HTTP . . . 25
5.2 premi`ere approche de l’ontologie . . . 28
5.3 deuxi`eme approche de l’ontologie . . . 29
5.4 troisi`eme approche de l’ontologie . . . 31
5.5 Diagramme de s´equence de l’analyseur . . . 32
5.6 Arbre syntaxique . . . 34
5.7 Arbre syntaxique segment´e et d´ecod´e . . . 34
5.8 Arbre de d´ecision . . . 38
6.1 Graphe de la dur´ee de classification en fonction du nombre de sous-mots . . . 43
6.2 Comparaison des taux de classification . . . 44
Remerciements
Nous souhaitons tout d’abord remercier nos tuteurs Messieurs GOUAICH, PLANTEVIT et RAISSI pour l’aide qu’ils nous ont apport´ee tout au long du projet, aussi bien au niveau de la compr´ehension que de la programmation ou lors de difficult´es rencontr´ees.
Merci `a l’entreprise Beware pour nous avoir fourni un jeu de donn´ees, fruit de nombreuses ann´ees de travail.
Nous tenons ´egalement `a remercier l’´equipe de recherche TATOO.
Enfin, tous ceux qui ont particip´e de pr`es ou de loin au bon d´eroulement du projet trouvent ici l’expression de notre profonde gratitude.
Fiche de projet
P´eriode du projet : du 09/01/07 au 18/06/07
Le groupe : Mathieu BOISSIER (MB), Benoˆıt MILLON (BM), Julien ROUQUETTE (JR), Olivier VERGES (OV)
Niveau d’´etude : Master I Math´ematique Informatique Statistique
Institut : Universit´e Montpellier II
Sujet : D´etection d’attaques par requˆetes HTTP (cot´e serveur)
Contacts : MBmathieu.boissier@free.fr, BMbenoit-millon@hotmail.fr, JRjulienrouquette@hotmail.com, OVolivier.verges@gmail.com
Domaine d’application : S´ecurit´e r´eseau
Tuteurs : Abdelkader GOU AICH, M arc P LAN T EV IT, Chedy RA¨ ISSI¨
Chapitre 1
Introduction
1.1 Pr´ esentation g´ en´ erale
Internet est devenu avec le temps, un outil de travail innovant et en perp´etuelle ´evolution. Il permet de s’affranchir des barri`eres de l’espace et du temps en transmettant toute information num´erique de mani`ere instantan´ee dans le monde entier.
Les organisations, aussi bien publiques que priv´ees, poss`edent toutes ou presque une vitrine accessible au monde ext´erieur.
Les serveurs ont ´egalement ´evolu´e et ne sont plus de simples machines se limitant au stockage d’informations.
En effet, ils sont utilis´es, entre-autres, pour ex´ecuter des programmes en ligne, h´eberger des sites ou encore des bases de donn´ees pouvant contenir des informations importantes.
Les serveurs sont r´eguli`erement victimes d’attaques visant soit `a les rendre d´efaillants (DoS), soit `a acc´eder aux donn´ees sensibles qu’ils contiennent. Il est devenu primordial de les prot´eger contre des actes malveillants.
1.2 Probl´ ematique
Les attaques que nous avons ´etudi´ees sont celles r´ealis´ees par le biais de requˆetes HTTP, envoy´ees aux serveurs par l’utilisation de divers vecteurs comme un navigateur web, un shell ou encore un programme malicieux.
Cependant, comment d´eterminer si une requˆete est « normale » ou pas, et qu’est-ce qu’une requˆete normale ?
Les r´eponses `a ces questions ne sont pas si ´evidentes.
Prenons par exemple le site du lirmm, la requˆete« http ://www.lirmm.fr», permet de consulter la page d’accueil du site.
Comment d´eterminer la nature de n’importe quelle requˆete entrant sur le serveur h´ebergant ce site comme la requˆete« http ://www.lirmm.fr/../../etc/passwd »?
Est-elle tr`es, peu, ou pas dangereuse pour ce serveur et les donn´ees auxquelles ce dernier a acc`es ? Qu’a-t-elle essay´e de faire ?
En effet, une attaque peut avoir ´et´e lanc´ee de mani`ere al´eatoire et ne pas ˆetre nuisible pour le syst`eme sur lequel on est (tentative d´acc`es `a un fichier windows sur un serveur sous linux par exemple). Elle peut n´eanmoins avoir ´et´e compl`etement dirig´ee par une personne ou un pro- gramme poss´edant des connaissances sensibles sur le serveur (comme le syst`eme d’exploitation, le type de serveur web ou l’emplacement de certains fichiers particuliers), par cons´equent cette requˆete peut ˆetre consid´er´ee comme tr`es dangereuse.
Il existe de nos jours, de nombreux outils permettant de se pr´emunir contre des attaques mais
CHAPITRE 1. INTRODUCTION
ne fournissent pas d’informations suffisantes expliquant pourquoi une requˆete a ´et´e consid´er´ee comme une attaque et comment elle a ´et´e classifi´ee.
Notre projet s’inscrit dans cette probl´ematique, i.e. cr´eer un ensemble d’outils, se rapprochant d’un pare-feu applicatif, qui ´evaluera une requˆete re¸cue par un serveur. Si elle s’av`ere ˆetre une attaque de plus amples informations seront retourn´ees sur cette derni`ere (niveau et type par exemple), facilitant ainsi la tˆache de l’administrateur.
1.3 Contraintes
Cet ensemble doit r´epondre `a certaines contraintes :
– Rapidit´e : Etant donn´e qu’un serveur re¸coˆıt ´enorm´ement de requˆetes par seconde, et qu’il doit ˆetre tr`es r´eactif, nous devons r´eduire le plus possible le temps de traitement d’une requˆete.
– Portabilit´e : il doit pouvoir reconnaˆıtre et diff´erencier une attaque sur n’importe quel syst`eme d’exploitation (Windows, MacOS, Linux).
– Intuitivit´e et modularit´e : Devant reconnaˆıtre le maximum d’attaques possibles et suivant l’´evolution rapide d’internet, nos outils doivent ˆetre facilement modifiable afin de pouvoir reconnaˆıtre de nouvelles attaques sans que la structure du programme en soit affect´ee.
Chapitre 2
Organisation du projet
Danc cette partie nous pr´esentons les outils de travail qui nous ont permis de mener `a bien ce projet.
2.1 Environnement de d´ eveloppement
2.1.1 Jeu de donn´ees
Nous avons `a notre disposition un jeu de donn´ees r´eelles au format XML, fourni par l’entre- prise Beware. Ce jeu de donn´ees contient 50.116 requˆetes HTTP. Environs 13.000 de ces requˆetes sont des attaques, les autres ´etant des requˆetes valides. Apr`es l’avoir ins´er´e dans une base de donn´ees pour plus de lisibilit´e, nous avons pu en tirer de nombreuses informations telles que des concepts `a ins´erer dans l’ontologie ainsi que des r`egles sur la structure syntaxique des requˆetes.
Ces requˆetes servent ´egalement `a l’apprentissage du classifieur de notre projet.
2.1.2 Langages et outils de d´eveloppement
A l’origine, comme cit´e dans le cahier des charges, nous devions d´evelopper l’application en C++. Cependant, nous avons finalement opt´e pour une conception enti´erement faite enJAVA, car :
– il s’agit d’un langage open source sous licence GNU GPL, donc cela n’entraˆıne pas de coˆut pour la r´ealisation de notre projet,
– il pr´esente la particularit´e d’ˆetre portbale sur plusieurs syst`emes d’exploitation tels que Unix, Microsoft Windows, Mac OS...,
– il permet une conception plus ais´ee des interfaces graphiques.
Bien que nous y perdions en rapidit´e d’ex´ecution, nous y gagnions en efficacit´e de d´eveloppement et en rendement, mais ces raisons seules n’expliquent pas tout. En effet, l’impl´ementation d’un classifieur viable sans aucune connaissance nous menait droit `a l’´echec, or WEKA, qui permet d’utiliser ses classifieurs cod´es enJAVAdirectement dans notre application, nous ´etait n´ecessaire.
La plateforme de d´eveloppementJAVAutilis´ee est Eclipse que l’on a choisie pour sa simpli- cit´e et ses performances.
La programmation de l’ontologie s’est faite avec le langage OWL. Nous n’avons cependant pas directement programmm´e en OWL, mais avons utilis´e le logiciel Prot´eg´e, qui simplifie nettement la cr´eation d’ontologies `a l’aide d’une interface graphique intuitive. Par contre, l’exploitation de l’ontologie par l’application est impl´ement´e enJAVA, `a l’aide de la librairie JENA.
CHAPITRE 2. ORGANISATION DU PROJET
La partie concernant l’analyse syntaxique a quant `a elle ´et´e developp´ee en«JAVACC»(JAVA Compiler Compiler) qui est un compilateur de compilateurs ou un g´en´erateur d’analyseur lexical et syntaxique. Il sagit donc dun outil qui lit les sp´ecifications d’une grammaire et qui les convertit en un programme JAVA. Ce programme peut ensuite analyser du code suivant la grammaire d´efinie. De plus ce programme est gratuit, ce qui n’entraine pas de coˆut pour cette partie de l’application.
La grammaire que nous utilisons pour effectuer l’analyse syntaxique d’une URL HTTP est issue du rfc 1738 (rfc de l’url). En ce qui concerne l’analyse morpho-syntaque nous avons uti- lis´e l’algorithme de Cocke Younger Kasami (CYK) issue du cours de M.CHAUCHE (enseignant chercheur `a Montpellier).
Le classifieur a ´et´e impl´ement´e grˆace aux algorithmes tir´es du logicielWEKA, sp´ecialis´e dans la classification, et ´ecrits en JAVA´egalement. Certains graphiques affich´es dans le rapport sont aussi tir´e de WEKA.
CHAPITRE 2. ORGANISATION DU PROJET
2.2 Planification des tˆ aches
Selon le temps imparti au projet, nous avons fait une plannification des tˆaches telle qu’on peut la voir sur la figure 2.1.
Fig. 2.1 – Diagramme de Gantt
2.3 R´ epartition des tˆ aches
Nous pr´esentons ici bri`evement la contribution de chacun dans ce projet.
D`es le d´ebut, un coordinateur a ´et´e d´esign´e et nous nous sommes r´epartis les diff´erentes composantes du projet de la fa¸con suivante :
Mathieu BOISSIER
– R´ealisation de la composante de classification.
– Cr´eation de la composante de signature conceptuelle.
Benoˆıt MILLON – Coordinateur
– Mod´elisation de l’ontologie.
– Programmation de la partie exploitation de l’ontologie.
– R´ealisation de l’interface graphique.
Julien ROUQUETTE
– R´ealisation de la composante analyseur.
– Recherches et ajouts des r`egles de grammaire.
Olivier VERGES
– Mod´elisation de l’ontologie.
– Ajout des concepts `a l’ontologie.
Chapitre 3
Pr´erequis
Une grande partie du projet ´etait d´edi´ee `a la compr´ehension des concepts qui entraient en jeu dans ce sujet. Les notions d’ontologie, de classification par exemple ´etaient nouvelles, et nous avons dˆu, `a travers de nombreuses lectures de documents, de recherches, franchir le pas de la d´ecouverte et de la nouveaut´e pour parvenir `a raisonner et proposer des solutions aux probl`emes qui nous ´etaient pos´es.
Nous allons maintenant nous int´eresser aux concepts n´ecessaires `a la compr´ehension du fonctionnement de chacune de ces composantes.
3.1 Concepts importants
Ce chapˆıtre va rendre compte des notions cl´es de ce projet suivant ses diff´erentes composantes.
3.1.1 Notions sur les ontologies
D´efinition
Le mot ontologie vient de ontos (ˆetre) et de logos (langage + raison), ce qui signifie repr´e- senter et expliquer ce qui existe.
En informatique une des d´efinitions qui fait autorit´e est :
Une ontologie est la sp´ecification d’une conceptualisation d’un domaine de connais- sance, Thomas R. Gruber .
Ce terme d´esigne l’ensemble des connaissances servant `a d´ecrire et hi´erarchiser un domaine.
A la diff´` erence d’un vocabulaire, une ontologie cherche donc `a repr´esenter le sens des concepts et des relations qui les lient `a l’aide des :
– Classesrepr´esentant les nombreux domaines d’int´erˆets, – Relationspouvant exister entres ces domaines,
– Instances (ou les attributs) associ´ees `a ces domaines.
Formellement, une ontologie O est d´efinie comme un tuple (C, R) o`u C ={c1, c2, ...cn} est l’ensemble des classes et o`u R = {r1, r2, ..rm} regroupe l’ensemble des relations entre classes (R1) et les propri´et´es des classes (R2).
Une relation r1∈R1 associe deux noms de classes, (∀ r1 (t1,t2)⇒C, t2∈ C), et une propri´et´e r2∈R2 relie un nom de classe `a un litt´eral (∀r2 (t1, t2)⇒ t1∈C, t2∈λo`u λest un litt´eral).
CHAPITRE 3. PR ´EREQUIS Mod´elisation
Le World Wide Web Consortium(W3C), a developp´e dans le cadre de l’activit´e web s´eman- tique, deux composants permettant de mod´eliser des ontologies.
RDF(Resource Description Framework)
Ce composant est un mod`ele de graphe destin´e `a d´ecrire de fa¸con formelle les ressources Web et leurs m´etadonn´ees, de fa¸con `a permettre le traitement automatique de telles descriptions.
Il est bas´e sur le triplet {sujet, pr´edicat, objet} repr´esentant respectivement la ressource `a d´ecrire, le type de propri´et´e que l’on peut lui appliquer et une donn´ee la concernant.
Chaque membre de ce triplet est repr´esent´e par une URI.
Fig. 3.1 – Exemple de mod´elisation RDF – RDF/XML
RDF ´etant un mod`ele de graphe il peut ˆetre facilement ´ecrit sous format XML.
RDF/XML est la normalisation syntaxique pour repr´esenter ce mod`ele propos´e par le W3C.
La figure 3.1 sera transcrite en RDF/XML de la sorte :
<rdf :RDF xmlns :rdf=”http ://www.w3.org/1999/02/22-rdf-syntax-ns# ” xmlns :exterms=”http ://www.example.org/terms/”>
<rdf :Description rdf :about=”http ://www.example.org/index.html”>
<exterms :creation-date>August 16, 1999</exterms :creation-date>
</rdf :Description>
</rdf :RDF>
– RDFS (Resource Description Framework Schema)
Ce composant est une«extension»de RDFS dans le sens o`u il fournit un vocabulaire plus
´etendu. Il permet de d´ecrire les ressources sous formes de concepts au lieu d’URI.
OWL (Web Ontology Language)
Ce composant a ´et´e con¸cu comme une«extension»de RDF. En effet, son vocabulaire permet de d´ecrire des classes, des propri´et´es et leurs instances de mani`ere plus structur´ee.
Avec OWL, la figure 3.1 pourra ˆetre retranscrite de la sorte :
<rdf :RDF xmlns=”http ://www.owl-ontologies.com/Ontology1179498392.owl#”
xml :base=”http ://www.owl-ontologies.com/Ontology1179498392.owl”
xmlns :xsd=”http ://www.w3.org/2001/XMLSchema#”
xmlns :rdfs=”http ://www.w3.org/2000/01/rdf-schema#”
xmlns :rdf=”http ://www.w3.org/1999/02/22-rdf-syntax-ns#”
CHAPITRE 3. PR ´EREQUIS
xmlns :owl=”http ://www.w3.org/2002/07/owl#”>
<owl :Ontology rdf :about=””/>
<owl :Class rdf :ID=”Ressource”/>
<owl :DatatypeProperty rdf :ID=”creation-date”>
<rdfs :domain rdf :resource=”#Ressource”/>
<rdfs :range rdf :resource=”&xsd ;string”/>
</owl :DatatypeProperty>
<Ressource rdf :ID=”index.html”>
<creation-date rdf :datatype=”&xsd ;string”>August 16, 1999</creation-date>
</Ressource>
</rdf :RDF>
OWL est d´efini en trois sous-langages offrant une expressivit´e diff´erente.
– OWL LITECe langage est utilis´e principalement pour une ontologie ayant des contraintes simples dans une classification de type hi´erarchique.
– OWL DL(Direct Logical)
Celui-ci offre une expressivit´e maximum. Il comprend toute les structures du langage OWL avec des restrictions comme la s´eparation des types (une classe est soit un individu soit une propri´et´e).
– OWL FULL
Ce dernier langage offre une expressivit´e maximum avec la libert´e syntaxique de RDF, mais sacrifie la garantie de r´esultat d’un syst`eme de raisonnement.
3.1.2 Notions li´ees `a la partie analyseur
Dans notre projet, l’analyseur a pour rˆole la transformation d’une suite de caract`eres en une structure riche (abre), facilement exploitable. Pour cela il se d´ecompose principalement en trois parties : l’analyse lexicale, l’analyse syntaxique et l’etiquetage morpho-syntaxique.
– L’analyse lexicale a pour tˆache principale de lire les caract`eres d’entr´ee et de produire comme r´esultat une suite d’unit´es lexicales que l’analyseur syntaxique aura `a traiter.
En plus, l’analyseur lexical r´ealise certaines tˆaches secondaires comme l’´elimination de caract`eres superflus (commentaires, tabulations, fin de lignes,...).
– L’analyseur syntaxique re¸coit une suite d’unit´es lexicales de la part de l’analyseur lexical et doit verifier que cette suite peut ˆetre engendr´ee par la grammaire du langage. Cette grammaire d´ecrit comment les unit´es lexicales doivent ˆetre agenc´ees. Le principe de l’analyseur syntaxique est d’essayer de construire un arbre de d´erivation qui est une repr´esentation de la structure de la suite d’unit´es lexicales re¸cus.
– L’´etiquetage morpho-syntaxique consiste `a associer une ´etiquette `a chaque unit´es lexi- cales issus de l’analyse lexicale.
3.1.3 Notions de classification et d’apprentissage
Le classifieur est un agent qui permet de regrouper des objets en groupes ou classes de telles sorte que :
– Deux objets d’une mˆeme classe se ressemblent le plus possible, – Deux objets de deux classes distinctes diff`erent le plus possible.
On distingue deux types d’apprentissage possibles, l’apprentissage supervis´e et l’appren- tissage non supervis´e. L’apprentissage supervis´e est une technique d’apprentissage auto-
CHAPITRE 3. PR ´EREQUIS
matique qui consiste `a produire automatiquement des r`egles `a partir d’un jeu de donn´ees contenant des exemples de cas d´ej`a trait´es. Le jeu de donn´ees ´etant p´ealablement ordonn´e en classes par un expert, le classifieur qui en d´ecoule peut tirer des r`egles qui permettront de classer des instances ne faisant pas partie du jeu de donn´ees.
L’apprentissage non supervis´e, lui, apprend sur un jeu de donn´ees non organis´e en classes et doit essayer de minimiser la similarit´e intra-groupe et de maximiser la similarit´e inter- groupes. Nous nous interesserons ici `a l’apprentissage supervis´e, le jeu de donn´ees mis
`
a notre disposition ´etant ordonn´e de telle sorte que pour chaque requˆete r´epertori´ee on connaisse son type. Voici les deux types d’apprentissage retenus :
Apprentissage par arbres de d´ecision :
Les arbres de d´ecisions permettent de mod´eliser un raisonnement r´egit par une succession de conditions qui permettent, `a partir d’un attribut discriminant dans le jeu de donn´ees et via d’autres attributs jouant le rˆole de noeuds, d’arriver `a un r´esultat ais´ement interpr´etable pour une personne. Chaque noeud de l’arbre est un attribut et chaque feuille, une valeur de la classe. L’attribut le plus discriminant doit ˆetre la racine de l’arbre permettant le meilleur apprentissage possible. L’apprentissage par arbre de d´ecision ne doit pas ˆetre un apprentissage par coeur car il serait quasiment impossible de classifier dans cet arbre une nouvelle requˆete sans faire d’erreur. Par ailleurs, une validation crois´ee (d´ecrite ci- apr`es) sur un apprentissage par-coeur montre que le taux d’erreurs de classification est extr`emement ´elev´e. Afin d’´eviter le sur-apprentissage (overfitting), on utlise un algorithme d’´elagage pr´e ou post apprentissage. Ce type d’algorithme permet de couper des parties de l’arbre consid´er´ees comme non n´ecessaires afin de le g´en´eraliser davantage, en d’autres termes, de diminuer sa forte sp´ecialisation. Le choix d’un apprentissage `a l’aide d’un arbre de d´ecision permet de suivre le chemin menant `a la pr´ediction de la classe `a laquelle appartient l’instance test´ee. Cette proc´edure de classification est compr´ehensible par un utilisateur averti et permet de savoir si le classifieur donne une r´eponse correcte ou non.
Apprentissage par r´eseaux de Bayes :
Le r´eseau bay´esien tire son nom de Thomas Bayes qui est `a l’origine de la th´eorie du mˆeme nom, qui sert de base au calcul de probabilit´es. Il s’agit d’un mod`ele de repr´esentation pro- babiliste des connaissances que l’on reproduit sous la forme d’un graphe orient´e acyclique.
Le graphe en lui-mˆeme est appel´e la structure du mod`ele et les tables de probabilit´es de chacun des sommets, ses param`etres. Ceux-ci peuvent ˆetre fournis par un expert, mais en r`egle g´en´erale, ce qui sera la cas ici, seule la structure sera d´efinie, les param`etres ´etant calcul´es `a partir de donn´ees exp´erimentales. Son utilisation permet d’inf´erer, c’est-`a-dire calculer la probabilit´e des donn´ees non observ´ees en fonctions des informations observ´ees pr´elablement.
Les types d’apprentissage expliqu´es pr´ec´edemment ne donnent pas forc´ement de bons r´esultats et il nous faut donc une m´ethode capable de donner une id´ee de la fiabilit´e de la classification. Cette m´ethode est la validation crois´ee.
Validation crois´ee sur l’apprentissage
Afin de v´erifier si l’apprentissage est bon, sans jeu de test, une validation crois´ee s’impose.
Elle consiste `a choisir al´eatoirement une partie du jeu de donn´ees pour en faire un jeu de test et ensuite, `a lancer l’apprentissage sur le jeu de donn´ees restant. Une validation crois´ee
`
a 10 plis, comme le montre la figure 3.2, consiste `a prendre 10% du jeu de donn´ees qui sera
CHAPITRE 3. PR ´EREQUIS
Fig.3.2 – Validation crois´ee `a 10 plis sur un jeu de donn´ees
le jeu de tests, de faire l’apprentissage sur les 90% restants et enfin tester le taux d’erreur avec le jeu de 10% r´ecup´er´e auparavant, et ce, sur 10 apprentissages successifs. Au final, on fait la somme du taux d’erreurs et on le divise par le nombre de plis, en l’occurence 10 afin d’obtenir le taux d’erreur moyen du classifieur.
Une petite pr´ecision s’impose. La s´election du jeu de test est al´eatoire par cons´equent les requ`etes retenues pour faire partie de lui ne sont pas forc´ement cˆotes `a cˆotes contrairement
`
a ce que nous montre le sch´ema 3.2.
Lors de la validation crois´ee, comme on peut le voir ici avec 10 plis, 10 apprentissages sont lanc´es ce qui fait que 10 arbres de d´ecision sont cr´e´es. Plus ces arbres ont de similitudes entre eux et plus l’apprentissage a un taux d’erreur stable. Si le delta d’erreur en validation crois´ee est peu ´elev´ee, on pourra consid´erer que l’apprentissage est bon.
Chapitre 4
Etat de l’art
Ce chapitre rend compte de nos recherches sur l’´etat de l’art. Tout d’abord, nous allons donc ´etudier dans le d´etail, quelles sont les principales attaques HTTP. Ensuite suivra une
´etude des diff´erentes techniques de protection existantes. Nous continuerons par l’´etude des limites des logiciels dits pare-feux applicatifs. Enfin, nous terminerons par une partie concernant les ontologies orient´ees s´ecurit´e informatique.
4.1 Les attaques Web les plus courantes
Jour apr`es jour, les hackers redoublent d’ingeniosit´e pour cr´eer de nouvelles attaques. Voici quelques types d’attaques parmi les plus courants.
4.1.1 Modifications d’URLs
Ce type d’attaque consiste en la modification des param`etres utilis´es dans les URLs, ce qui peut entrainer l’acc`es `a des donn´ees confidentielles. Une solution possible pour parer `a ce type d’attaque, peut ˆetre l’utilisation de la m´ethode POST au lieu de la m´ethode GET, qui assure une transmission des param`etres non visibles par l’utilisateur.
Les donn´ees contenues dans une URL sont la plupart du temps cr´e´ees dynamiquement par la navigation des utilisateurs `a travers le site Internet, ainsi il n’est pas rare d’avoir une URL de la forme suivante :
«http ://monsite/blog/index.php3 ?cat=4»
Dans ce cas, si l’utilisateur modifie manuellement la valeur des param`etres de l’URL, dans notre exemple«cat=4»par«cat=8», si le concepteur du site n’a pas pris en consid´eration cette ´eventualit´e, l’utilisateur peut potentiellement acc´eder `a des donn´ees«prot´eg´ees».
4.1.2 Injections de commandes
Cette attaque s’appuie sur l’envoi de commandes (shell par exemple) `a l’application. Elle donne ainsi acc`es au syst`eme d’exploitation ou `a des donn´ees sensibles situ´ees sur le ser- veur. Le filtrage des donn´ees re¸cues par le serveur permet de contrer ces attaques.
4.1.3 Injections SQL
SQL est un langage structur´e de requˆetes, destin´ees `a interroger ou `a manipuler une base de donn´ees relationnelle. Le principe des injections SQL consiste `a envoyer une requˆete
CHAPITRE 4. ETAT DE L’ART
SQL non pr´evue par le syst`eme. Cela permet `a un utilisateur malveillant d’acc´eder, mo- difier ou supprimer des informations de la base de donn´ees. Une solution possible consiste
`
a utiliser les proc´edures stock´ees, `a la place du SQL dynamique ou filtrer les saisies de l’utilisateur. Par exemple si le site utilise la requˆete suivante pour identifier un utilisateur :
«SELECT user id WHERE user name = ’dupont’ AND user password =
’457b3a2af6879c4ff17f8d1174760f62’.»
Dans ce cas, si il n’y a aucune v´erification sur la saisie de l’utilisateur, alors il suffit d’en- trer :«durant’–» comme nom d’utilisateur pour s’identifier comme l’utilisateur Durant.
En effet en SQL«–» signifie que ce qui va suivre est un commentaire, par cons´equent la suite de la requˆete :
«AND user password = ’457b3a2af6879c4ff17f8d1174760f62’» va ˆetre consid´er´ee comme un commentaire d’o`u l’inutilit´e du mot de passe pour se connecter.
4.1.4 Cross-Site Scripting (XSS, CSS)
La technique consiste `a envoyer du code malicieux sur un site Web vuln´erable, ce code sera interpret´e et execut´e par le navigateur des autres utilisateurs.
Par exemple sur un forum pr´esentant aucune s´ecurit´e pour ces attaques, si l’on envoie ce type de message«<script>alert(’bonjour’)</script>», alors les utilisateurs qui souhai- teront lire les messages verront apparaˆıtre une fenˆetre contenant le message«bonjour», au lieu d’un simple message texte. Il existe plusieurs solutions pour contrer ces attaques notamment en interdisant les scripts `a certains endroits du code, en v´erifiant le format des donn´ees saisies par l’utilisateur ou encore en encodant les donn´ees entr´ees par l’utilisateur.
4.1.5 Violations de contrˆole d’acc`es
Cette technique consiste `a exploiter une faiblesse de restriction des droits utilisateur, ce qui donne l’acc`es `a d’autres comptes utilisateur avec leurs droits associ´es. Un param´etrage correct des droits utilisateur suffit `a ´eviter ce genre d’attaque.
4.1.6 Buffer Overflow
Cette attaque consiste `a saturer le buffer de l’application, qui poss`ede une taille limit´ee.
Elle permet le crash ou la prise de contrˆole du syst`eme. Pour faire face `a ces attaques, l’application doit v´erifier la taille des donn´ees saisies par l’utilisateur.
4.1.7 Traitements inappropri´es des erreurs
Comme tout programme informatique, les applications Web peuvent connaˆıtre des dysfonc- tionnements tels que l’inaccessibilit´e d’une ressource ou des probl`emes li´es `a la m´emoire.
La plupart du temps ces dysfonctionnements g´en`erent 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 `a l’utilisateur via l’affichage d’une page Internet, ce qui repr´esente une mine d’informations pour l’utilisateur malveillant, car cela l’informe sur la structure de l’application et sur ses vuln´erabilit´es.
CHAPITRE 4. ETAT DE L’ART 4.1.8 Directory Traversal
L’utilisateur malicieux va structurer sa requˆete de sorte `a obtenir une branche du syst`eme de fichiers au lieu d’un fichier. L’utilisateur peut ainsi acc´eder `a des informations sensibles.
Pour parer `a cela, l’utilisation d’une page par d´efaut `a chaque noeud de l’arborescence de fichier ainsi qu’une bonne configuration du serveur suffisent.
Par exemple il suffit d’utiliser la chaine«../» qui permet de remonter dans l’arborescence du syst`eme de fichiers et ainsi acc´eder `a des informations non autoris´ees.
Remarque : une ´evolution possible consiste `a encoder le caract`ere « /» par «%2F» (Hexad´ecimal) ou encore«%u2216» (Unicode).
4.1.9 D´enis de service (DoS)
Une attaque est consid´er´ee comme un d´eni de service si un utilisateur bloque d´elib´er´ement l’acc`es `a un serveur, privant ainsi les autres utilisateurs de l’acc`es `a celui-ci. Une technique possible consiste `a saturer le serveur en lui envoyant des donn´ees inutiles. Il existe un d´eriv´e de cette attaque qui repose sur une parall´elisation d’attaque DoS, simultan´ement men´ees par plusieurs syst`emes contre un seul. Pour ´eviter de telles pertubations, il est possible d’utiliser une liste noire contenant les adresses IP des machines hostiles. Lorsque le serveur recevra une requˆete provenant d’une machine contenue dans sa liste noire, la requˆete sera rejet´ee.
Remarque : Le fait de d´ebrancher un serveur avec l’intention de nuire est consid´er´e comme un d´eni de service.
4.1.10 Exploitations de vuln´erabilit´es encore inconnues
Les utilisateurs malicieux ou plus couramment appel´es hackers sont sans cesse `a la re- cherche de nouvelles failles de s´ecurit´e. Ces failles pr´esentent un double int´erˆet pour eux.
D’une part cela leur permet de passer `a travers les protections existantes et ainsi acc´eder
`
a des donn´ees «prot´eg´ees». D’autre part ils peuvent d´ecouvrir de nouvelles techniques d’attaques, ce qui est une forme de reconnaissance pour eux. Par cons´equent ces attaques sont fortement redout´ees par les r´eponsables de la s´ecurit´e, car elles leurs sont actuellement inconnues.
La figure 4.1 illustre certaines des attaques pr´esent´ees pr´ec´edemment, contre un serveur Web reli´e `a une base de Donn´ees. On peut y voir une attaque par Cross-Site Scripting, une injection SQL, un DoS, et un Directory Traversal.
4.2 Les diff´ erentes techniques de protection
Pour faire face aux multiples types d’attaques existants , il est indispensable de poss´e- der une parade efficace `a chacune d’elle. Cela entraˆıne naturellement la multiplication des techniques et outils de protection que nous avons regroup´es ci-apr`es.
4.2.1 Utilisation de listes blanches/noires d’URLs (s´ecurit´e positive) Les listes blanches et les listes noires sont deux techniques, qui permettent un filtrage des URLs ; le principe repose sur l’utilisation d’une biblioth`eque d’URLs. Dans le cas des
CHAPITRE 4. ETAT DE L’ART
Fig. 4.1 – Illustration de diverses attaques connues
listes blanches, la biblioth`eque contient les URLs autoris´ees, tandis que, dans le cas des listes noires la biblioth`eque contient les URLs interdites qui seront bloqu´ees par le syst`eme.
– Listes blanchesdynamiques
Certains outils ne se basent pas sur une liste g´en´erale des attaques connues, mais sur une liste construite en fonction du contenu qu’ils prot`egent. Les listes dynamiques sont un bon exemple. L`a o`u la m´ethode dynamique diff`ere d’une m´ethode statique (liste fixe), c’est que la liste est construite au fur et `a mesure des interactionsapplication <->
utilisateur. Prenons par exemple un serveur qui h´eberge des sites Web :
Lorsqu’un utilisateur navigue sur un site du serveur, le syst`eme de d´etection analyse chaque page demand´ee par l’utilisateur, et v´erifie la conformit´e avec l’application de chaque donn´ee que ce dernier renvoie (les types de donn´ees, les valeurs possibles et autres).
– Listes blanchesproactive
Les listes blanches proactive sont construites suite `a une phase d’apprentissage. Contrai- rement aux listes dynamiques, elles sont construites avant toute interaction avec un utili- sateur quelconque. Elles sont constitu´ees de l’ensemble de toutes les interactions possibles entre un utilisateur et l’application. Ainsi, toute requˆete sortant de cette liste sera im- m´ediatement bloqu´ee. Cette phase d’apprentissage permet un gain de temps pr´ecieux, car la cr´eation de la liste ne se fait pas pendant, mais avant le dialogue application <->
utilisateur, avant mˆeme la mise `a disposition des informations sur Internet.
4.2.2 L’apprentissage
En science cognitive l’apprentissage se d´efinit ainsi :«Capacit´e `a am´eliorer les performances au fur et `a mesure de l’exercice d’une activit´e». Dans le cadre de la s´ecurit´e informatique cette technique peut permettre `a l’aide d’une accumulation de connaissances de tirer des r`egles, qui doivent s’appliquer `a des situations non encore rencontr´ees. Par exemple dans le cas des listes noires, l’apprentissage doit permettre au fur et `a mesure de son exp´erience, un enrichissement de sa biblioth´eque d’entit´es non autoris´ees.
CHAPITRE 4. ETAT DE L’ART 4.2.3 Les pare-feux
Un pare-feu est un ´el´ement du r´eseau informatique, logiciel et/ou mat´eriel, qui a pour fonction de faire respecter la politique de s´ecurit´e du r´eseau, celle-ci d´efinissant quels sont les types de communication autoris´es ou interdits. Il existe differentes cat´egories de pare-feu :
1. Pare-feu sans ´etat : Il regarde chaque paquet ind´ependamment des autres et le compare `a une liste de r`egles pr´econfigur´ees.
2. Pare-feu `a ´etat : Il doit v´erifier l’ordonnancement des donn´ees qui circulent sur le r´eseau pour une connexion.
3. Pare-feu applicatif : Il v´erifie la compl`ete conformit´e du paquet `a un protocole attendu.
Par exemple, ce type de pare-feu permet de v´erifier que seul du HTTP passe par le port TCP 80.
4. Pare-feu identifiant : Il v´erifie les addresses IP des paquets lui arrivant et les rejette si il les consid´ere commme suspectes.
4.2.4 Les syst`emes de d´etection d’intrusion (IDS)
Cette cat´egorie de syst`emes de protection se d´ecompose en deux familles :
1. Les N-IDS (Network Based Intrusion Detection System), qui surveillent l’´etat de la s´ecurit´e au niveau du r´eseau. Pour cela ils utilisent une liste noire qui recense les signatures des attaques connues. Cependant, face `a une attaque inconnue ce syst`eme est inefficace.
2. Les H-IDS (HostBased Intrusion Detection System), qui surveillent l’´etat de la s´ecurit´e au niveau des hˆotes. Ce syst`eme repose sur une analyse comportementale et d´efinit ainsi une norme. Si une activit´e s’´eloigne de la norme, une alerte est g´en´er´ee.
La figure 4.2 repr´esente une fa¸con d’installer un IDS afin de prot´eger un r´eseau.
Fig.4.2 – Installation d’un IDS 4.2.5 Les syst`emes de pr´evention d’intrusion (IPS)
Les IPS permettent la protection contre les intrusions. D’une part ils les identifient et les signalent. D’autre part ils ont la possibilit´e de les bloquer contrairement `a la plupart des IDS qui se contentent d’afficher un message d’alerte.
CHAPITRE 4. ETAT DE L’ART 4.2.6 L’authentification forte
De plus en plus de donn´ees et d’informations circulent sur les r´eseaux. Ces donn´ees peuvent ˆ
etre vitales pour les organisations (comme leurs informations bancaires par exemple), c’est pour- quoi il est indispensable de s´ecuriser les ´echanges entre les machines. Pour assuser cette s´ecurit´e il existe des protocoles d’authentification, qui reposent sur l’´echange d’un secret entre le client et le serveur. Par la suite ce secret peut ˆetre utilis´e pour chiffrer les donn´ees ´echang´ees, permetant d’en garantir l’int´egrit´e et la confidentialit´e.
4.2.7 Les pots de miel (honeypots)
Ce n’est pas un outil de protection au sens strict du terme, mais plutˆot une technique per- mettant la recolte d’information. Le principe consiste `a mettre en place un syst`eme informatique pr´esentant volontairement des failles de s´ecurit´e, et analyser les strat´egies utilis´ees par les hackers pour exploiter ces failles.
4.3 Les logiciels de protection
Nous d´ecrivons ci-apr`es les sp´ecificit´es de plusieurs logiciels de protection d´edi´es `a la sur- veillance du traffic HTTP.
4.3.1 SG800
Cr´e´e par la soci´et´e Blue Coat Systems, SG800 est un pare-feu applicatif d´edi´e exclusivement
`
a la surveillance du trafic HTTP. Il se charge d’analyser le contenu des messages du trafic HTTP que le serveur re¸coˆıt. Il contient un module qui se charge d’analyser et filtrer les URLs.
Ce pare-feu est dˆot´e une capacit´e d’apprentissage et d’un moteur de r`egles `a partir desquels seront formalis´ees des interdictions ou des acceptations. Il est ´egalement capable de modifier des messages ou les rediriger selon des param`etres pr´e-´etablis.
4.3.2 Deny All
C’est un pare-feu tr`es ´evolu´e, et qui propose de nombreuses techniques de d´etection com- bin´ees, pour un maximum d’efficacit´e, ceci est appel´e le filtrage applicatif multiple. Parmi ces diff´erentes techniques, nous pouvons citer :
– Le Reverse Proxy, qui se charge de filter les requˆetes HTTP ou HTTPS entrantes, en
´eliminant celles qui pr´esentent des ´el´ements non-conformes au protocole HTTP(S) et en les transmettant ensuite `a une liste noire.
– Le suivi des utilisateurs (User Tracking), qui est bas´e sur un syst`eme d’authentification forte dont nous avons d´ej`a parl´e auparavant.
– Le mod`ele de s´ecurit´e positive, qui contient une liste blanche dynamique ainsi qu’une liste blanche proactive.
4.3.3 Mod Security
Mod Security est un module pour Apache. Il a la capacit´e d’analyser tr`es pr´ecis´ement toute requˆete envoy´ee au serveur HTTP ou HTTPS et de la bloquer si elle peut repr´esenter un danger pour l’applicatif WEB. Bas´e sur un syst`eme de r`egles relativement simples, le filtre de Mod Security s’applique sur toute requˆete en fonction de patterns pr´ed´efinis ou d´efinis par l’utilisateur.
CHAPITRE 4. ETAT DE L’ART 4.3.4 SNORT
SNORT est un IDS ou encore plus commun´ement appel´e«sniffer» sous licence GPL capable d’effectuer des analyses de trafic et d’identifier les paquets sur un r´eseau IP en temps r´eel. Il est capable de d´etecter les d´epassements de tampons, les scans des ports, et est capable d’analyser les trames HTTP.
4.4 Les limites des moyens de d´ etection
Ces solutions, aussi efficaces soient-elles, pr´esentent des limites que nous explicitons ci-apr`es.
4.4.1 Limites des Pare-feu applicatifs
Filtrage par liste noire
Les listes noires sp´ecifiques de donn´ees demandent des mise-`a-jours extrˆemement fr´equentes afin de maintenir un haut niveau de s´ecurit´e tout en ´etant capable de traiter les requˆetes dites
«normales»afin de ne pas perturber les communications entre le client et le serveur HTTP.
Certaines solutions manipulent des listes noires trop g´en´erales et de ce fait, entraˆınent des faux positifs, c’est-`a-dire, que certaines requˆetes HTTP tout `a fait normales seront trait´ees comme des attaques.
Filtrage par liste blanche
La s´ecurit´e positive est certes efficace, mais assez lourde `a mettre en oeuvre et `a garder `a jour. Si le mod`ele de toutes les possibilit´es d’int´eractions entre les utilisateurs et l’application n’est pas exhaustif, certaines requˆetes sans danger pour la s´ecurit´e pourraient ˆetre consid´er´ees comme non conformes et trait´ees comme des attaques potentielles. S’il y a une modification de l’application et des requˆetes qu’elle engendre, il faudra modifier cette liste blanche afin de ne pas perturber les communications et le bon fonctionnement de cette mise `a jour d’application.
Les pare-feux se basent sur ce syst`eme de liste noire, liste blanche et n’offrent, dans la majorit´e des cas, une protection valable uniquement apr`es qu’une attaque ait ´et´e perp´etr´ee et r´epertori´ee.
4.4.2 Limites des IDS
N-IDS
Ils sont bas´es sur une biblioth`eque de signatures d’attaques connues, biblioth`eques qui de- vront ˆetre mises `a jour d`es lors qu’une nouvelle attaque sera r´epertori´ee. Si celle-ci ne contient pas la signature d’une attaque sp´ecifique et r´ecente, cette derni`ere passera au travers des mailles du filet et la s´ecurit´e des donn´ees ainsi que du r´eseau en g´en´eral sera menac´ee.
H-IDS
Ils sont bas´es sur l’analyse de l’activit´e sur un hˆote qui g´en`ere une alerte si une activit´e s’´eloigne de la norme, mais si dans un cas exceptionnel une affluence de requˆete justifi´ee mais non pr´evue par le syst`eme venaient `a arriver en masse, cette m´ethode de protection risquerait de g´en´erer des alertes infond´ees.
Les H-IDS ne sont pas fiables car ils ne font que g´en´erer des alertes, et ce sera `a un adminis- trateur en charge de la s´ecurit´e du r´eseau de dire si telle ou telle requˆete est valable ou pas. En terme de temps, cela coˆute cher, et en terme de fiabilit´e, cela est perfectible.
CHAPITRE 4. ETAT DE L’ART 4.4.3 Limites des IPS
Ils sont une am´elioration des IDS avec en plus la possibilit´e de bloquer la tentative d’in- trusion. Si ils d´etectent une attaque ou une activit´e suspecte alors qu’elle n’a pas lieu d’ˆetre, ils provoqueront des perturbations sur le r´eseau. Comme pour les N-IDS, si la signature d’une attaque n’est pas r´epertori´ee, la s´ecurit´e y perdra en efficacit´e.
Toutes ces solutions pr´esentent le d´esavantage de ne d´etecter une attaque seulement quand elle a d´ej`a ´et´e perp´etr´ee, ce qui limite sensiblement leur efficacit´e et oblige `a de multiples mises `a jour d`es lors qu’une nouvelle attaque est r´epertori´ee. Ceci ´etant, elles permettent de se pr´emunir contre des attaques d´ej`a existantes et de ce fait, ne laissent la porte entrouverte qu’au v´eritables pirates qui recherchent la moindre faille.
4.5 Ontologies et s´ ecurit´ e
Cette section traite de l’existant sur une partie du sujet : l’ontologie. Si l’on peut dire que les parties «classifieur»et «analyseur» seront trait´ees `a l’aide d’algorithmes pr´e-existants et efficients, il n’en est pas de mˆeme pour la partie ontologie.
Sur le domaine qui nous int´eresse nous conceptualiserons, entre autres, les dossiers et les fichiers pr´esents sur le syst`eme d’exploitation du serveur. Nous leur ajouterons des propri´etes comme
«un fichier se trouve dans un dossier»,«un fichier est sensible». Mais la question qui se pose
`
a ce niveau du projet est :
Existe-t’il des ontologies traitant de la s´ecurit´e web ?
4.5.1 NRL Security Ontologie
De nos jours les donn´ees rapport´ees par des ´el´ements de s´ecurit´e sont nombreuses et vari´ees (notamment ceux des pare-feux et des IDS comme SNORT). L’administrateur se retrouve noy´e dans ce flot de donn´ees qu’il va essayer de d´ecortiquer afin d’obtenir des informations utiles.
Le NRL (Navy Research Laboratory) a propos´e un ensemble de 7 ontologies, bas´e sur un ancien ensemble DAML Security Ontology, afin de d´ecrire les informations concernant la s´ecurit´e de n’importe quelle ressource. Il donne, ainsi, la possibilit´e de cr´eer une ontologie facilement exten- sible et qui facilite la liaison informative entre les ´equipements de s´ecurit´e de bas et haut niveau.
4.5.2 Les dif´erentes ontologies Security Main Ontology
Le noyau de la NRL Security Ontology se compose d’une classe SecurityConcept partag´ee en 3 sous-classes :
– «SecurityProtocol»: regroupe les diff´erents protocoles offrant un niveau de s´ecurit´e comme les protocoles d’identification(SAML, Kerberos), Internet(SSH,TTL).
– «SecurityMechanism»: regroupe les diff´erents m´ecanismes sur les hˆotes(safehost), sur les r´eseaux (VPM), et les applications.
– «SecurityPolicy»: regroupe les diff´erentes politiques de s´ecurit´e mises en place.
La classe SecurityObjective permet de d´eterminer quel niveau tel protocole ou tel m´ecanisme g`ere.
Elle permettra de r´epondre `a la question :
CHAPITRE 4. ETAT DE L’ART
«Quelles sont les instances qui ont pour propri´et´e laconfidentialit´e ?»
Certaines de ces classes ont pour propri´et´es «hasAlgorithm», «hasAssurancy», «reqCreden- tial».
Ces propri´et´es relient des instances de la classe principale aux ontologies suivantes :
SecurityAlgorithms : regroupe les diff´erents types d’algorithmes existants (comme cryp- tage et contrˆole).
Cette classe permet de sp´ecifier quels algorithmes sont utilis´es par les protocoles mis en place.
Security Assurance : regroupe les diff´erents types d’assurances propos´es par les algo- rithmes, protocoles et m´ecanismes.
Standard, Accr´editation, Evaluation et Certification sont les 4 sous-classes.
Security Credential: regroupe les diff´erents moyens d’authentification aussi bien physique, que biom´etrique et ´electronique. Cˆot´e ´electronique, ont ´et´e regroup´es les adresses IP, cookies, mots de passes, certificats.
Service Security : Cette ontologie permet de sp´ecifier que les classes du Security Main Ontology, SecurityConcept et SecurityObjective, sont des sous-classes de OWL-S1
Service Agent : repr´esente un service local cherchant `a communiquer avec une application ext´erieure. Peut contenir les valeurs des classes SecurityConcept et SecurityObjective.
Information Object: sert `a r´ecup´erer des informations crypt´ees ou sign´ees.
4.6 Conclusion de l’´ etat de l’art
Comme nous l’avons vu, l’existant est assez riche en solutions logicielles ou mat´erielles, mais plutˆot pauvre en solutions efficaces et vraiment fiables. Ceci ´etant, elles sont les seules existantes pour le moment, et permettent de se pr´emunir contre des attaques d´ej`a r´epertori´ees.
Ces solutions, par contre, ne suffisent pas `a se prot´eger efficacement contre les nouvelles attaques, inconnues jusqu’alors.
Notre TER s’inscrit dans l’optique de se pr´emunir contre des attaques de toutes sortes qu’elles soient connues ou non et ainsi d’anticiper leurs agissements.
1OWL-S est une ontologie propos´ee par le Consortium W3C afin d’apporter un vocabulaire standard compr´e- hensible pour des agents cherchants `a acc´eder `a certains services web.
Chapitre 5
Notre contribution
Dans cette partie, nous allons pr´esenter les diff´erentes composantes de notre application ainsi que le travail effectu´e. Dans un premier temps, nous donnerons un aper¸cu g´en´eral du fonctionnement de cette derni`ere. Par la suite, nous d´etaillerons les parties dont elle est compos´ee.
5.1 Vision globale de l’application
La fonction principale de l’application, c’est `a dire le traitement de requˆetes HTTP est constitu´e de plusieurs composantes bien distinctes. Dans le but d’une conceptualisation simple et claire nous l’avons divis´ee en trois parties principales :
– L’ontologie.
– L’analyseur.
– Le classifieur.
5.1.1 Diagramme de s´equence de l’application
Fig. 5.1 – Diagramme de s´equence g´en´eral de la classification d’une requˆete HTTP Sur la figure 5.1, on peut observer facilement le parcours que suit une requˆete lors de l’ex´e- cution de l’application. La prod´edure principale fournit la requˆete en entr´ee `a l’analyseur. Ce dernier utilise ensuite le contenu de l’ontologie pour transformer ce qui lui a ´et´e transmis. Apr`es ce traitement interne, il renvoie une nouvelle forme de la requˆete `a la proc´edure principale. La proc´ecdure principale transmet ce qu’elle a re¸cue pr´ec´edemment de l’analyseur au classifieur, qui se charge de classer la requˆete dans une certaine cat´egorie, en fonction de ce qu’il a appris.
C’est cette derni`ere ´etape qui d´efinit si oui ou non la chaˆıne de caract`eres initiale correspond `a une attaque.
CHAPITRE 5. NOTRE CONTRIBUTION
5.2 Le module ontologie
Ce module est celui qui a subi le plus de transformations tout au long du projet. En effet, les trois modules ´etant interconnect´es, de nouvelles contraintes sont apparues en mˆeme temps que l’´etude de l’analyseur et du classifieur s’effectuait.
Nous allons pr´esenter les 3 grandes mod´elisations de l’existant que nous avons effectu´ees au cours de ce projet.
5.2.1 Rappel
L’ontologie est la mod´elisation de l’existant.
Ici l’existant concerne d’une part tout ce qui est laiss´e volontairement, ou involontairement, accessible sur un serveur par Internet et d’autre part les moyens d’acc`es `a cette information.
Dans ce projet, l’ontologie sert `a apporter une«coloration» `a un«mot» envoy´e par l’analyseur i.e.lui retourner des ´etiquettes le d´ecrivant `a un plus haut niveau. L’´etude faite sur les diff´erents types d’attaques, le jeu de donn´ees fourni ainsi que notre expertise nous ont permis de faire une liste de ce que nous devions conceptualiser.
Information
Sur Internet, la grande majorit´e de l’Information se trouve sous forme defichiers situ´es dans desdossiers. Elle se trouve sur dessyst`emes d’exploitation et peut ˆetre utilis´ee par des serveurs web.
Note : Ici nous ne consid´erons que deux familles de syst`emes d’exploitation :
– unix : comprenant aussi bien les distributions Linux que celles de MacOs car elles poss`edent des commandes syst`emes, fichiers et r´epertoires communs.
– windows : comprenant toutes les versions de ce syt`eme M´ethodes d’acc`es
Qu’elles soient sensibles ou non sensibles, les m´ethodes d’acc`es `a l’information sont desins- tructions de langage qui correspondent `a un langage ou descommandes syst`emes.
5.2.2 Mod´elisation typ´ee Syst`eme d’Exploitation
Cette mod´elisation a ´et´e la premi`ere que nous ayons faite et a servi de base aux autres.
Pour commencer nous avons formalis´e le domaine afin de le conceptualiser et de le hi´erarchiser.
Formalisation Dossier
Dossier regroupe tous les dossiers existants sur le serveur sur une configuration normale d’un serveur suivant n’importe quel syst`eme d’exploitation.
Un Dossier se trouve dans un syst`eme d’exploitation.
Un Dossier contient 0, 1 ou plusieurs Dossiers.
Un Dossier contient 0, 1 ou plusieurs Fichiers.
Un Dossier est contenu dans 0 ou un Dossier.
Un Dossier est un Dossier sensible ou non sensible.
CHAPITRE 5. NOTRE CONTRIBUTION Fichier
Fichier regroupe tous les fichiers existants.
Un Fichier se trouve dans un Dossier.
Un Fichier est sensible ou non sensible. Un Fichier poss`ede 0 ou 1 extension.
S´eparateur
Ce concept sert `a rassembler les caract`eres sp´eciaux comme «.» ou «/» qui s´eparent les chaˆınes de caract`eres. Ces instances seront envoy´ees `a l’analyseur qui les utilisera afin de s´eparer les diff´erents tokens.
Commande
Ce concept regroupe les commandes syst`emes. En effet, certains pirates tentent d’envoyer des commandes syst`emes au serveur, enfin d’obtenir un acc`es, en lecture ou en ecriture, sur les informations du syst`eme.
Une Commande est associ´ee `a 1 ou plusieurs OS.
Une Commande peut ˆetre sensible ou non sensible.
Langage
Ce concept rassemble les diff´erents langages pouvant ˆetre utilis´es dans des requˆetes adress´ees au serveur comme xml etjavascript.
Un Langage poss`ede plusieurs Instructions de Langage.
Instruction de Langage
Toutes les instructions de langages existants commeif, then, else.
Une Instruction correspond `a ou plusieurs Langages.
Une instruction fonctionne sur 0 ou 1 Serveur Serveur
Serveur regroupant les serveurs web comme Apache.
CHAPITRE 5. NOTRE CONTRIBUTION Ce qui donne le sch´ema suivant :
Fig. 5.2 – premi`ere approche de l’ontologie
Bilan
Cette mod´elisation, suivant la figure 5.2, permet d’avoir une vision globale de tout ce qui peut ˆ
etre trouv´e sur le serveur aussi bien au niveau de l’information que de la mani`ere de l’obtenir et de la modifier.
Les propri´et´es permettent de trouver les relations entres les diff´erences ressources. Les instances, mises `a titre d’information, sont les«mots» envoy´es par l’analyseur.
Cependant, cette mod´elisation ne correspond pas r´eellement `a notre domaine d’´etude dans la mesure o`u nous nous sommes trop concentr´es sur les noms des classes, et des instances alors que ces derni`eres sont les identifiants des concepts.
En effet, conceptualiser des instances de la classe Fichier par des noms de fichiers est trop r´e- ducteur. Un fichier peut ˆetre caract´eris´e aussi par son inode, son utilisateur et son groupe. Or nous ne n´ecessitons que du nom.
Pour finir, chaque instance correspondant au «mot» envoy´e par l’analyseur poss`ede des pro- pri´et´es diff´erentes ce qui complexifie la recherche des ´etiquettes.
5.2.3 Mod´elisation avec des ´etiquettes simples
Il fallait donc revenir vers l’optique du sujet et simplifier l’acc`es aux diff´erentes donn´ees.
Le but ce module ´etant de donner des ´etiquettes au «mot», ou token, envoy´e par le le module analyseur, nous avons d´ecid´e de transfomer notre ontologie en la basant sur ces deux concepts- cl´es.
CHAPITRE 5. NOTRE CONTRIBUTION Changement au niveau des classes
La classe Token va regroupertous les mots reconnaissables par notre application.
La classe Etiquette regroupera, elle, les diff´erentes ´etiquettes que l’on retournera `a l’Analy- seur.
Changement au niveau des propri´et´es
On a besoin de cr´eer une propri´et´e entre les classes Token etEtiquette.
Cette propri´et´e est a pour etiquette qui a pour domaineToken et pour codomaineEtiquette.
Il est donc inutile maintenant de garder les propri´et´es de la premi`ere mod´elisation.
Formalisme : Un Token a pour etiquette 1 ou plusieurs Etiquette.
Fig. 5.3 – deuxi`eme approche de l’ontologie
Bilan
Cette mod´elisation est plus proche du sujet que la premi`ere. L’avantage principal de cette version est le gain de temps r´ealis´e lors de la recherche d’un token.
Dans la premi`ere, nous devions le chercher parmi toutes les instances de toutes les classes. A chaque occurence trouv´ee, nous devions r´ecup´erer sa classe et par ses propri´et´es certaines ins- tances auxquelles elle ´etait li´ee. Maintenant, la recherche se fait uniquement parmi les instances de laclasse Token. Chacune d’entre elles ´etant reli´e `a toutes les ´etiquettes possibles le caract´e- risant par la propri´et´ea pour etiquette.
Cependant nous sommes confront´es aux probl`emes suivants :
CHAPITRE 5. NOTRE CONTRIBUTION
– Comment faire la diff´erence entre plusieurs groupes d’´etiquettes ? En effet, un Token peut avoir plusieurs significations diff´erentes.
Exemple : «/» est un{dossier AND sensible AND unix}OU {s´eparateur}.
Dans l’´etat actuel, nous obtenons{dossier AND sensible AND unix AND separateur}sans savoir comment les s´eparer.
– Comment g´erer le probl`eme des doublons ?
Si cr´eer le conceptToken a permis de ne garder qu’une occurence d’un mot recherch´e, les
´etiquettes posent encore ce probl`eme. Il y a par exemple l’instance de la classeOS windows et l’instance de Token windows, or il ne peut y avoir d’identifiant similaire. Un autre exemple : la notion sensible, se trouve aussi bien dans Dossier, Fichier, Commande que d’autres. Le probl`eme est que si nous d´esirons supprimer par la suite la notion de sensibilit´e de notre ontologie, il faudrait supprimer toutes les instances utiliser pour repr´esenter cette notion.
5.2.4 Mod´elisation avec des ´etiquettes composites
Cette 3e mod´elisation est la derni`ere `a ce jour et donc celle que nous utilisons dans l’appli- cation.
Changement au niveau des classes
Pour pallier au probl`eme de la diff´erenciation entre groupes d’´etiquettes, nous cr´eons la classe EtiquetteComposite.
Cette derni`ere va servir de lien entre le token et chaque groupe d’´etiquettes ce qui va permettre d’obtenir simplement les groupes d’´etiquettes.
Un autre changement majeur est la cr´eation des classesNature etPropri´et´e.
En effet un token est soit une Instruction, soit un Dossier, soit un Fichier... cela est sa nature premi`ere. La classeNature rassemble donc ces anciennes classes.
De plus celui-ci concerne un Langage ou un OS, et peut ˆetre sensible ou pas, executable...La classe Propri´et´e rassemble ces termes et les regroupe.
Propri´et´e se retrouve aussi surclasse de OS,Langage et Serveur. Elle a pour instance les pro- pri´et´essensible,executable,multimedia.
Changement au niveau des propri´et´es
De part la cr´eation de la classe EtiquetteComposite rempla¸cant la classe Etiquette, il faut donc aussi remplacer la propri´et´e a pour etiquette par :
– a pour etiquette composite : qui lie une instance deToken `a une ou plusieurs instances de EtiquetteComposite faire le d´etail : fonctionnel, relationnel...
– est composee : qui lie une instance de EtiquetteComposite avec au moins 1 Etiquette, la sous-classeNature.
En ce qui concerne probl`eme sur les doublons, nous avons cr´e´e une «datatype property» qui lie une chaˆıne de caract`eres aux instances de la classeToken par la propri´et´eTokenValue. Ainsi le token sera cherch´e parmis ces chaˆınes de caract`eres. Elles ne poseront aucun probl`eme avec les identifiants n´ecessaires `a la cr´eation de l’ontologie .
Formalisme : Un Token a pour etiquetteComposite au moins une EtiquetteComposite.
UneEtiquetteComposite est compos´ee de au moins une Etiquette.
CHAPITRE 5. NOTRE CONTRIBUTION
Fig. 5.4 – troisi`eme approche de l’ontologie
CHAPITRE 5. NOTRE CONTRIBUTION
5.3 Analyseur
Lors de l’arriv´ee d’une url sur le serveur, celle-ci est une simple chaˆıne de caract`eres i.e une structure contenant peu d’informations. Le but de l’analyseur est de la transformer en une struc- ture enrichie. Dans notre cas nous utiliserons un arbre. L’analyseur se compose de trois parties compl´ementaires :
– Analyseur : d´ecoupage en jetons de l’url.
– Post-traitement : segmentation de chaque jeton en fonction des s´eparateurs fournis par l’ontologie.
– Etiqueteur : association d’une ´etiquette `a chaque sous-mot composant l’url et g´en´eralisa- tion de l’url.
Dans le but d’avoir une vision globale de cette composante du programme voici un diagramme de s´equence repr´esentant ses trois parties avec leurs interactions.
Fig. 5.5 – Diagramme de s´equence de l’analyseur
CHAPITRE 5. NOTRE CONTRIBUTION 5.3.1 Analyseur
Dans cette partie l’analyseur va prendre en entr´ee une l’url sous forme d’une chaˆıne de caract`eres et construire l’abre syntaxique de cette url selon la grammaire de l’url definie dans le rfc 1738. Ce qui suit est une description de style BNF de la syntaxe d’une url HTTP. Le caract`ere
’|’ sert `a d´esigner les alternatives, et les crochets [ ] entourent les ´el´ements facultatifs ou r´ep´et´es.
Les ´el´ements sont repr´esent´es par un carat`ere ou un intervalle (a-z), les ´el´ements facultatifs sont eux entre [crochets], et des ´el´ements peuvent ˆetre pr´ec´ed´es de <n>* pour d´esigner n ou plus r´ep´etitions de l’´el´ement suivant (par d´efaut n `a pour valeur 0).
httpurl = http :// hostport [ / hpath [ ? search ]]
hpath = hsegment [ / hsegment ]*
hsegment = [ uchar|;|:|@|&|= ]*
search = [ uchar|;|:|@|&|= ]*
uchar = unreserved |escape unreserved = alpha|digit|safe |extra alpha = lowalpha|hialpha
escape = % hex hex hex = digit|A-F |a-f lowalpha = a-z
hialpha = A-Z
digit = 0-9
safe = $|- | |.|+ extra = !|* |’|( |)|,
Remarque : Etant donn´e que notre application se situe sur un serveur, nous nous int´eressons uniquement `a cette partie de l’url : [ / hpath [ ? search ]] , car tout ce qui la pr´ec`ede correspond
`
a l’adresse du serveur.
CHAPITRE 5. NOTRE CONTRIBUTION
Voici un exemple d’arbre syntaxique engendr´e par la grammaire pr´ec´edente :
Fig.5.6 – Arbre syntaxique
Comme on peut le voir, cet arbre se d´ecompose en 2 parties : hpath et hsegment, avec pour chacune d’elles leurs feuilles associ´ees. Les feuilles de cet arbre repr´esentent chaque partie de l’url. L’´etape suivante consiste `a d´ecouper chacune de ces feuilles selon les s´eparateurs contenus dans l’ontologie.
5.3.2 Post-traitement
Dans un premier temps il va y avoir un d´ecodage de chaque feuille. Dans notre exemple, seule la feuille du search«4e=%27%3B+++++drop+++table++admin»n´ecessite un d´ecodage.
Voici le r´esultat apr`es ce d´ecodage :«4e=’ ; drop table admin».
Ensuite la fonction post-traitement va r´ecup´erer dans l’ontologie tout ce qui est class´e comme s´eparateur et va effectuer une segmentation de chaque feuille selon ces s´eparateurs. Si par exemple l’ontologie renvoie les s´eparateurs suivants : ( ” . space < > ( ) ’ ; = : @), l’arbre pr´ec´edent va ˆ
etre transform´e de la fa¸con suivante :
Fig. 5.7 – Arbre syntaxique segment´e et d´ecod´e
CHAPITRE 5. NOTRE CONTRIBUTION
Comme on peut le voir, chaque feuille compos´ee de s´eparateurs a ´et´e segment´ee, ainsi la feuille «rpdpMrcW3@EO.jpg»a ´et´e segment´ee en «rpdpMrcW3 - @ - EO - . - jpg».
Remarque : La segmentation de chaque feuille est d´ependante des s´eparateurs contenus dans l’ontologie. En effet, si l’ontologie ne contient aucun s´eparateur alors cette ´etape n’effectura aucune modification par rapport `a l’´etape pr´ec´edente.
5.3.3 Etiqueteur
Cette ´etape se d´ecompose en deux parties, la premi´ere consiste `a prendre chaque feuille de l’arbre et pour chacune d’elles leur affecter une ´etiquette issue de l’ontologie. Voici le d´eroulement de cette ´etape :
– l’analyseur va passer `a l’ontologie chaque ´el´ement de chaque feuille, sous forme d’une chaˆıne de caract`eres
– l’ontologie va chercher si elle connaˆıt cette chaˆıne de caract`eres et retourner son ou ses r´esultats `a l’analyseur
– l’analyseur va affecter `a chaque partie de chaque feuille l’´etiquette retourn´ee par l’ontologie Exemple d’´etiquetage :
eAtmenn : string
itL : string
iperloOMGFx : string
. : dot, s´eparateur
O : string
. : dot, s´eparateur
R : string
. : dot, s´eparateur
rpdpMrcW3 : string
@ : arrobas, s´eparateur
EO : string
. : dot, s´eparateur
jpg : jpg, extension multimedia
4e : string
= : eq, s´eparateur
’ : quote, s´eparateur
; : semicolon, s´eparateur drop : instruction sql sensible
«space» : space, s´eparateur table : instruction sql
«space» : space, s´eparateur
admin : string
Cet exemple nous montre l’association de chaque partie de l’url avec son ´etiquette issue de l’on- tologie. Si une entit´e n’est pas pr´esente dans l’ontologie par d´efaut, son ´etiquette sera«string». Une fois cette op´eration termin´ee chaque composante de l’url aura une ou plusieurs ´etiquettes associ´ees. La partie suivante va permettre de faire un tri parmi elles, ce qui a pour but une g´en´eralisation de l’url.
CHAPITRE 5. NOTRE CONTRIBUTION
Cette partie de l’´etiquetage consiste `a s´electionner uniquement les concepts qui permettent cette g´en´eralisation. Pour cela nous utilisons l’algorithme de Cocke Younger Kasami (CYK) qui permet de d´eterminer si un mot appartient `a un langage hors contexte et fournir toutes les structures syntaxiques de ce mot.
Voici l’algorithme de CYK :
Routine CYK( grammaire G = (V,N,S,P) et phrase a1..an) :entr´ee reconnue D´ebut
Pour j variantDe 1 `a n Faire M1,j ←{ A | A → aj ∈ P } FinPour
Pour l variantDe 2 `a n Faire
Pour j variantDe 1 `a n−l+ 1 Faire Ml,j ← ∅
Pour i variantDe 1 `a l−1 Faire i0 ← l−1
j0 ← j+i
Ml,j ← Ml,j ∪ { A | A → BC ∈ P, B ∈ Mi,j, C ∈ Mi0,j0 } FinPour
FinPour FinPour
Retourner S ∈ M1,n Fin
Algorithme de CYK
Principe de l’algoritme de CYK
Cet algorithme construit les d´ecoupages possibles en«remontant», c’est-`a-dire en calculant les d´ecoupages de longueur 1, 2...n si n est la longueur de l’entr´ee w = a1. Ces d´ecoupages sont calcul´es dans une matrice triangulaire n×n (appel´ee ´egalement table de reconnaissance) dans laquelle l’´elementMi,j est l’ensemble des non-terminaux produisantaj..aj+i−1. L’entr´ee est reconnue siMn,1 contient l’axiome S (symbole initial).
La grammaire utilis´ee par l’algorithme de CYK doit ˆetre en forme normale de Chomsky (CNF), c’est-`a-dire n’avoir que des productions de la forme A → a ou A → BC (elle est donc sans productions vides, et elle ne produit pas de cycles).
Remarque : cet algorithme peut ˆetre adapt´e pour fonctionner sur une grammaire qui n’est pas en CNF. Cependant cela rend l’algorithme plus compliqu´e notamment par la possibilit´e d’avoir des r`egles g´en´erant des cycles.
Dans notre application la grammaire G = (V,N,S,P) se compose de la fa¸con suivante : – V : ensemble non vide de symboles terminaux, correspondent au jeton issu de l’url apr`es
segmentation.
– N : ensemble de symboles non-terminaux, correspondant aux etiquettes fournit par l’on- tologie.
– S : symbole initial (concepte g´en´eralisant une url«requete ).
– P : ensemble de r`egles de productions. (d´ecrite ci-dessous)
