Projet de Dipl Ome: SIMS - Security Intrusion Management System (Orient e Web)

Projet de Diplôme
SIMS - Security Intrusion Management System (orienté Web)
Auteur : Joël Winteregg

Professeur : Stefano Ventura
Assistant : Cyril Friche
École : École d’ingénieurs du Canton de Vaud
Date : 16 décembre 2004
Table des matières
1 Introduction 4
1.1 Résumé du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Introduction au projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Snort VS Prelude 8
2.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Méthodes de détection d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Architecture distribuée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Outils d’analyse et de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Prelude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Composants et architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Comparatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Moteur d’analyse et banque de signatures . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 La console de l’analyste (frontends) . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Étude et comparatif de reverse-proxys 17

3.1 Squid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.5 Réécriture d’URL et HTTP redirect . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 DansGuardian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Architecture retenue et mise en place 31
1
Projet de Diplôme 2004 - Joël Winteregg
SIMS - Security Intrusion Manager System orienté Web
4.1 Définition de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Modification du code source de Dansguardian pour le contrôle des donnée POSTée . . . 35
4.2.1 Installation et configuration de DansguardianSims . . . . . . . . . . . . . . . . 38
4.3 Installation des NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Mise en place du reverse-proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.1 Installation de l’HIDS sur le reverse-proxy . . . . . . . . . . . . . . . . . . . . 40
4.4.2 Création d’une blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3 Pattern matching de Prelude-lml pour DansguardianSims . . . . . . . . . . . . . 42
4.5 Mise en place de la sonde HIDS de IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.1 Configuration du client Windows Snare et d’IIS . . . . . . . . . . . . . . . . . . 43
4.5.2 Configuration du serveur syslog Linux . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.3 Pattern matching de Prelude-lml pour les logs de IIS . . . . . . . . . . . . . . . 45
4.6 Mise en place d’un firewall Iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6.1 Récupération des logs du firewall . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6.2 Gestion des logs syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Corrélation 50
5.1 Définition et principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2.1 Mais qu’apportera concrètement la corrélation ? . . . . . . . . . . . . . . . . . . 51
5.2.2 Événements déclencheurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Corrélation temps réel VS corrélation à postériori . . . . . . . . . . . . . . . . . . . . . 53
5.4 Mise en place des contextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4.1 Contextes de sessions TCP communes . . . . . . . . . . . . . . . . . . . . . . . 56
5.5 Scénarii d’investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5.1 Possibilités et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5.2 Diminution des faux positifs par analyse des requêtes - réponses et du status du
serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5.3 Traçabilité des comportements à risque . . . . . . . . . . . . . . . . . . . . . . 64
5.6 Mise en place de NTP (Network Time Protocol) . . . . . . . . . . . . . . . . . . . . . . 64
5.6.1 Installation Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6.2 Installation Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 Implémentation, installation et tests 68

6.1 Watchdog de contrôle d’état du/des serveur(s) Web . . . . . . . . . . . . . . . . . . . . 68
6.1.1 Détermination de l’état du service Web . . . . . . . . . . . . . . . . . . . . . . 68
6.1.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Algorithme de corrélation et site Web (frontend) . . . . . . . . . . . . . . . . . . . . . . 70
6.2.1 Choix du langage et du frontend hôte . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.2 Étude de l’interfaçage avec SEC . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.3 Architecture logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2
6.2.4 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.5 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2.6 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3 Tests du moteur de corrélation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7 Descriptif et utilisation de SEC 79

7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2 Fonctionnement par l’exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8 Panorama de l’offre actuelle 83

8.1 Open Source Security Information Management (OSSIM) . . . . . . . . . . . . . . . . 83
8.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.1.2 Méthodes d’analyses utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.2 Open security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
9 Conclusion 88
10 Remerciements et références 90
10.1 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
10.2 Références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A Annexes 93
A.1 Planning et coût horaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A.2 Fichiers de configuration des sondes du reverse-proxy . . . . . . . . . . . . . . . . . . . 94
A.2.1 Configuration du sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.2.2 Configuration de la sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.2.3 NIDS pre-reverse-proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.3 Configuration de la sonde post-reverse-proxy . . . . . . . . . . . . . . . . . . . . . . . 104
A.3.1 Configuration de la sonde NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . 105
A.4 Configuration du firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
A.4.1 Script d’établissement des règles du firewall . . . . . . . . . . . . . . . . . . . . 109
A.4.2 Configuration du sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.4.3 Configuration de la sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.4.4 Configuration des règles à utiliser . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.4.5 Configuration de la rotation des logs . . . . . . . . . . . . . . . . . . . . . . . . 114
A.5 Configuration de Piwi et du moteur de corrélation . . . . . . . . . . . . . . . . . . . . . 115
3
Chapitre 1
Introduction
SIMS Security Management System
Proposé par : EIVD - institut TCOM - et l’EIG (projet CCTI)
1.1 Résumé du problème
La gestion de la sécurité est devenue indispensable au même titre que la gestion du réseau lui-même.
On peut même prétendre que la gestion de la sécurité est désormais le souci majeur du gestionnaire du
réseau de l’entreprise. Ce projet va se focaliser sur le développement d’un gestionnaire (Manager) de
sécurité appelé SIMS (Security Intrusion Management System) disposant d’agents intelligents ouverts
avec des interfaces SNMPv.31 ou IDMEF22 .
SIMS est spécialisé dans le domaine de l’analyse des tentatives d’intrusions détectées par des plates-
formes de type Firewall et IDS (Intrusion Detection System).
L’objectif premier de ce travail est d’étudier et de réaliser une plate-forme de gestion des intrusions basée
sur une corrélation de différents événements et logs et permettant de détecter des attaques en temps réel.
1.2 Cahier des charges
I. Établissement d’un rapport détaillé concernant les points suivants :

1
Simple Network Management Protocol version 3
2
Intrusion Detection Message Exchange Format
4
– Définition des principaux domaines de la gestion de la sécurité et brève présentation des prin-
cipaux standards existant dans ce domaine. Une attention particulière sera portée sur l’Intrusion
Management.
– Étude approfondie des différentes intrusions réseau et attaques WEB. Il s’agit de rédiger un docu-
ment ”state of the art” présentant les principales attaques au niveau 2, 3 et 3 du modèle OSI, ainsi
que les attaques de niveau applicatif. Les serveurs WEB, ainsi que les applications s’exécutant sur
ces dernier, feront l’objet d’une attention particulière.
– Développement d’un laboratoire et banc de test permettant de mettre en évidence les stratégies
et mécanismes de défense contre les attaques WEB. Ce laboratoire sera basé sur le déploiement
d’un reverse-proxy dont le choix fera l’objet d’une justification (Squidguard pour le filtrage d’url,
DansGuardian pour le filtrage de contenu http, développement de Tissot, etc...).
– Étude et évaluation des principales solutions et plates-formes d’Intrusion Management (Open-
Source et produits propriétaires) disponibles sur le marché.
– Évaluation des applications (aggregation, data fusion et corrélation) d’analyse des intrusions dis-
ponibles sur les systèmes retenus.
II. Étude et proposition d’une application de gestion des intrusions basée sur une corrélation de différents
événements et logs permettant de détecter et prévenir des attaques.
Étude et réalisation d’une plate-forme SIMS basée sur des sondes http (evtl. https) et différents agents
SIMS (reverse-proxy). Dans le cadre de cette étude, il s’agit aussi de définir un format général des mes-
sages (IDMEF) et logs générés par cette plate-forme.
La plate-forme SIMS sera capable de collecter, stocker et traiter des logs depuis plusieurs sources
comme, par exemple, des Reverse-proxy d’Apache, des Firewall Linux (Iptables) et éventuellement des
logs depuis SSLsniffer qui lui serait capable d’envoyer un mode non crypté des logs vers SIMS.
III. Réalisation d’un démonstrateur (applicatif SIMS) permettant d’illustrer les études et réalisations se-
lon le point II.
Il s’agit de mettre sur pied un environnement de détection d’intrusions et de gestion de logs avec les
outils étudiés et développés au point II.
Les attaques pourraient être simulées par les innombrables plugins que contient le scanner de vulnérabilité
Nessus.
SIMS pourrait intégrer des scénarii similaires à ceux implémentés par le travail de diplôme 2003 de M.
Saladino.
5
Directives : Lors de l’évaluation finale du travail de diplôme, une importance toute particulière sera
donnée au respect des directives générales de l’EIVD ainsi qu’aux directives spécifiques à ce travail.
1.3 Introduction au projet
La sécurité des serveurs Web est critique car ceux-ci sont généralement accessibles publiquement sur
Internet. La moindre vulnérabilité à ce niveau peut être exploitée par n’importe quel cracker dans le
monde.
Aujourd’hui, de plus en plus de sociétés assurent leur image de marque via un portail Web. Celui-ci de-
vient alors la colonne vertébrale du marketing et des ventes de plus en plus d’entreprises. Ceci explique
donc la montée en flèche des attaques Web.
Ce projet proposera une architecture d’entreprise sécurisée permettant l’intégration d’un serveur Web.
Toute l’attention sera portée sur celui-ci puisque ce projet a pour souhait de proposer des solutions pour
le management de la sécurité des serveurs Web.
Différentes étapes ont été nécessaires :

– Petit comparatif Snort3 - Prelude-IDS4
– Recherche d’un reverse-proxy (première protection du serveur Web)
– Mise en place d’une architecture sécurisée
3
Sonde réseau Open Source
4
IDS hybride (HIDS et NIDS) centralisé
6
– Déployement d’IDS
– Analyse et proposition de méthodes de corrélation permettant une bonne gestion de la sécurité
– Implémentation d’un moteur de corrélation
7
Chapitre 2
Snort VS Prelude
Ce chapitre abordera les outils disponibles avec Snort ainsi que les fonctionnalités offertes par Prelude,
afin d’en faire le comparatif et la distinction. Le projet de semestre SIMS orienté Web contenait une
introduction aux IDS qui détaillait les modes de fonctionnements et les fonctions offertes par la sonde
réseau Snort, alors que les outils d’analyses disponibles avec celle-ci n’y étaient pas décrits.
2.1 Snort
De simple outil de gestion de réseau, Snort est devenu un système de détection d’intrusion open source
distribué dans les entreprises du monde entier. Son investigateur, Marty Roesch, avait initialement conçu
Snort comme un outil personnel d’aide à l’analyse du trafic réseau.
Snort peut être utilisé comme mouchard (sniffer), enregistreur de paquets ou système de détection d’in-
trusion réseau. Les NIDS1 , semblent au premier abord, particulièrement intéressants, mais il ne s’agit,
en réalité, que d’une version améliorée des sniffers. En mode détecteur d’intrusion, il permet d’écouter
le trafic réseau sur lequel il est connecté (sniffer) et de l’analyer, afin d’identifier des informations poten-
tiellement dangereuses (tentatives d’attaques).
2.1.1 Méthodes de détection d’attaques
Snort offre la possibilité de travailler selon deux méthodes d’analyse du trafic :

1. Par signature (via la syntaxe2 des signatures Snort)
2. Par l’heuristique (via le module SPADE3 )
1
Network Intrusion Detection System, détecteur d’intrusion réseau
2
Syntaxe décrite dans le rapport de travail de semestre
3
Statistical Packet Anomaly Detection Engine
8
Détection par signature
Il s’agit du moyen le plus efficace aujourd’hui. Cette détection repose sur le principe que le trafic réseau
anormal ou malveillant reproduit un modèle spécifique, ce qui n’est pas le cas du trafic normal ou bénin.
Le trafic malveillant se distingue au niveau de sa structure et de son contenu, c’est pourquoi il est possible
de créer une signature d’attaque à partir de laquelle il pourra être reconnu.
Dans Snort, une signature de trafic malveillant permet de créer une règle que l’on peut charger dans le
moteur de détection du détecteur.
Détection par l’heuristique
La détection par signature est très efficace pour identifier du trafic suspect, mais ce type de détection n’est
malheureusement pas efficace à 100%. Dans certains cas, le trafic peut se révéler dangereux sans expo-
ser de signature particulière. La communauté Snort a donc développé le module SPADE pour détecter
le trafic suspect ne correspondant à aucune signature. SPADE observe le trafic réseau et construit une
table qui reflète le trafic normal. La table contient des données sur les types de paquets et les adresses de
source et de destination. Une fois que la table a atteint une taille significative, chaque paquet récupéré
par SPADE se voit attribuer un numéro basé sur la fréquence à laquelle il apparaı̂t dans la table. Plus le
paquet est rare, plus son numéro est grand. Lorsqu’un seuil configuré est atteint, une alerte est générée.
Supposons que vous vouliez configurer SPADE pour qu’il protège un serveur Web. Vous déployez Snort
avec SPADE activé sur un segment réseau connecté à Internet. SPADE construit une table pour modéliser
le trafic entrant (principalement des connexions TCP vers les ports 80 et 443). Une fois que la table
est construite, les requêtes TCP sur les ports 80 et 443 sont considérées comme du ”trafic normal” et
reçoivent un petit numéro. Si un attaquant tente de sonder le serveur Web pour trouver des services sur
des ports différents, SPADE attribuera un numéro élevé à ce trafic puisqu’il est rare et inhabituel sur
ce serveur particulier. Si des tentatives sont réalisées sur des ports inhabituels au-delà d’un certain seuil
prédéfini, SPADE générera une alerte.
Cette technique est efficace pour détecter les opérations réalisées par des crackers qui espèrent se fondre
dans la masses du trafic normal.
2.1.2 Architecture distribuée
Snort propose ensuite une architecture distribuée permettant aux sondes d’envoyer leurs alarmes dans une
base de donnée commune qui sera ensuite analysée par une application Web. Ceci permettra à l’ingénieur
système de monitorer l’évolution des attaques via un browser Web.
L’architecture 3-tiers décrite ci-dessus est présentée sur la figure 2.1.
9
F IG . 2.1 – Architecture distribuée de Snort
Premier tiers - le tiers détecteur
L’application Snort, à proprement parler, s’exécute sur le détecteur. Elle est chargée d’interpréter la na-
ture des paquets ”reniflés” et de transmettre les alertes à la base de donnée. Les détecteurs doivent être
placés sur les segments de réseau à protéger, c’est pourquoi la sécurité est primordiale. Sur le détecteur,
seul Snort et les applications associées doivent être exécutés. Cette configuration se justifie pour des
raisons liées, à la fois aux performances et à la sécurité. Les IDS sont des cibles très tentantes pour les
crackers et il est préférable d’éviter d’exécuter sur le détecteur des applications susceptibles d’ouvrir une
brèche dans la sécurité.
Le détecteur doit être équipé de deux cartes réseau : la première pour l’interface de la fonction sniffer et
l’autre pour l’interface de gestion. L’idée consiste à avoir un réseau séparé pour la gestion et de traiter tous
les paquets entrant (surveillés) avec une interface et toutes les alertes sortantes avec l’autre. L’interface
de la fonction sniffer ne doit pas posséder d’adresse IP afin que le trafic ne puisse circuler que dans un
sens4 .
L’interface de gestion doit, quant à elle, être en mesure de communiquer avec les autres éléments de
4
Une interface est incapable d’émettre des paquets lorsqu’elle n’a pas d’adresse IP (0.0.0.0)
10
l’architecture de Snort. C’est donc pour cela qu’une adresse IP lui sera assigné. Elle nous permettra,
entre autre, de régler Snort en ajoutant, en soustrayant ou en modifiant les règles et la configuration des
préprocesseurs.
Deuxième tiers - le tiers serveur
Le deuxième tiers, le tiers serveur, récupère les données d’alertes auprès des détecteurs et les présente
dans un format exploitable par l’utilisateur. Ces données sont enregistrées par Snort dans une base de
données relationnelle. Cette base de données n’est pas obligatoire : les alertes peuvent être enregistrées
par d’autres moyens, tel que syslog.
Le tiers serveur prend aussi en charge une interface graphique qui présente les données dans un for-
mat exploitable par l’utilisateur. Plusieurs interfaces graphiques sont dipsonibles avec Snort, y compris
demarc, snortsnar, snortdb et l’application ACID5 .
Troisième tiers - la console de l’analyste
C’est dans le troisième tiers que sont présentées les données à l’analyste. La console exige uniquement
une machine dédiée, équipée d’un navigateur Web compatible SSL. ACID fonctionnne bien avec Internet
Explorer, Mozilla, Netscape et la plupart des autres navigateurs. Il est préférable de dédier une machine
à la console pour en contrôler l’accès physique et pour empêcher les autres applications d’interférer avec
le système de détection d’intrusion.
2.1.3 Outils d’analyse et de gestion
Snort offre ensuite plusieurs outils de gestion pour son architecture distribuée, dont :
– ACID (Analysis Console for Intrusin Database), application serveur permettant à l’ingénieur
système d’interroger et d’analyser la base de données contenant la liste des attaques détectées par
les différentes sondes.
– IDS Policy Manager, application Windows 2000/XP servant à gérer à distance les différents
détecteurs Snort.
ACID
ACID est le principal outil pour exploiter et pour gérer les données d’intrusion rassemblées par Snort.
Il présente les données d’alerte et d’intrusion de manière à clarifier les données brutes émises par Snort.
Les données sont organisées de façon logique pour simplifier la prise rapide de décision. De plus, chaque
signature d’attaque est associée à un lien Internet qui permettra à l’analyste de trouver les causes de
l’intrusion.
5
application décirte dans la section 2.1.3
11
IDS Policy Manager
Cette application6 permet de modifier les paramètres des fichiers de configuration et les règles (ajout,
supression, modification) des différentes sondes du réseau. Elle est capable d’atteindre les paramètres
suivants d’une sonde :
– variable réseau
– classifications des règles
– réglage des préprocesseurs
– modules de sortie
– paramètre du système de règles
Ces paramètres sont stockés dans ce que l’on appelle une ”politique”. Ces politiques peuvent être différentes
en fonction de l’emplacement de la sonde. Il est donc facile, à l’aide de cette notion de politique, de chan-
ger la configuration globale des sondes.
Tous les échanges d’informations entre cette application et les sondes sont crpytés à l’aide du paquetage
SCP inclus dans Putty.
2.2 Prelude
Prelude-IDS est un système de détection d’intrusions et d’anomalies distribué sous licence GPL7 . La
détection d’intrusion est réalisée par l’analyse du trafic réseau et l’utilisation de signatures d’évènements
hostiles (NIDS) ou par l’analyse, en continu, de fichiers de journalisation (HIDS).
L’architecture de Prelude est modulaire8 , distribuée9 et sécurisée10 . Les sondes (réseaux comme locales)
n’effectuent que les opérations de surveillance et de génération d’alertes, alors que les managers prennent
en charge la gestion des sondes et la journalisation des alertes.
2.2.1 Composants et architecture
La figure 2.2 présente l’architecture distribuée envisageable à l’aide de Prelude.
Libprelude (la bibliothèque Prelude)
La bibliothèque libprelude a été créée dans le but de fournir une interface unique et standard de commu-
nication entre les différents éléments du système de détection. Cette bibliothèque est, bien sûr, utilisée par
6
Disponible uniquement pour Windows 2000/XP sur : http ://activeworx.com/download/index.htm
7
General Public License
8
Il est possible d’intégrer ou développer de nouvelles fonctionnalités grâce à des plugins
9
Prelude est une suite de composants autonomes et interactifs (les sondes et les managers par exemple)
10
Utilisation du support SSL pour l’authentification et le chiffrement des communications
12
F IG . 2.2 – Architecture distribuée de Prelude (source : Projet SIMS 2003, Patrick Saladino)
tous les modules de Prelude et peut aussi être intégrée à d’autres produits, afin de leur assurer une com-
patibilité avec ce système de détection d’intrusions. Pour des raisons de compatibilité et d’évolutivité, le
format de messages IDMEF a été retenu. C’est cette bibliothèque qui offre, entre autres, les possibilités
d’authentification mutuelle et de chiffrement de la communication.
Prelude-Nids (la sonde réseau)
Cette sonde prend en charge l’analyse en temps réel du trafic réseau. Elle est construite au-dessus de la
bibliothèque libprelude et fournit :
– Un moteur de gestion de signatures générique, actuellement compatible avec les signatures Snort
mais pouvant être étendu par l’ajout de nouveaux parsers (analyseurs syntaxiques) de règles.
– Des modules spécialisés par protocole. Par exemple, un plugin est dédié aux protocoles RPC et
permet l’analyse fine de ce type de connexions.
13
– Des modules spécialisés dans la détection non basée sur les signatures, comme la reconnaissance
des scans et la normalisation des chaı̂nes de caractères de requêtes HTTP.
– Les sondes réseaux peuvent aussi prendre en charge la défragmentation IP et le réassemblage des
flux TCP de façon à rendre une sonde réseau Prelude moins vulnérable aux attaques de type Stick
ou Snot11 .
Prelude-LML (la sonde locale)
Cette sonde prend en charge la remontée d’alertes détectées localement sur l’hôte. Cette détection est
basée sur l’application de règles construites autour d’expressions régulières compatibles Perl (PCRE) à
des objets12 . Une sonde hôte Prelude peut aussi recevoir les logs de machines distantes, de routeurs et
de firewalls grâce à son serveur Syslog intégré.
Prelude-Manager (le contrôleur)
Prelude-manager centralise les messages des sondes réseaux et locales et les traduit en alertes. Il est
responsable de la centralisation et de la journalisation à travers deux fonctions :
– Celle de relais : un contrôleur relais va assurer le routage vers un contrôleur maı̂tre des alertes
provenant des sondes qui lui sont rattachées.
– Celle de maı̂tre : un tel contrôleur va assurer la réception des messages et des alertes provenant
des sondes ainsi que leur journalisation dans un format lisible par l’analyste : en mode texte (dans
les fichiers), XML-IDMEF ou SQL dans le cas de l’utilisation d’un SGBD13 (MySQL ou Post-
greSQL).
Il est possible d’étendre les capacités d’un contrôleur à l’aide de plugins, en autorisant, par exemple, le
traitement de messages en provenance de composants autres que Prelude. Un contrôleur Prelude peut
ainsi centraliser la remontée d’alarmes en provenance de sondes Snort.
Prelude-Frontend (l’interface web)
Prelude-Frontend est l’interface de visualisation des alertes. Il est actuellement proposé deux interfaces,
l’une développée en PHP et l’autre en Perl :
1. Prelude-PHP-Frontend est l’interface proposée sur le site officiel de Prelude-IDS14 . Elle est com-
posée de scripts PHP et destinée à être installée sur un serveur web indépendamment des autres
composants Prelude. Cela signifie que l’installation préalable de la librairie libprelude est inutile,
mais que par contre celle d’un serveur web supportant PHP4 l’est.
11
Ces deux techniques sont utilisées pour tromper le moteur de l’IDS en fragmentant l’attaque dans plusieurs paquets, ceci
en espérant que la reconstruction se fera après qu’ils aient traversés l’IDS
12
fichiers de journalisation et/ou d’application (logs)
13
Système de gestion de base de données
14
http ://www.prelude-ids.org
14
2. Prelude-Perl-Frontend est une interface issue d’un projet intitulé ”Le Routier15 ”. Elle nécessite,
bien évidemment, l’installation d’un serveur web supportant Perl.
2.3 Comparatif
Dans le cadre du projet, ces deux outils sont très proches. Ce sont tous les deux des outils libres. Les
projets dont ils sont les résultats sont très actifs, aussi bien dans le développement que dans la mise à
jour des attaques. Quelques avantages de Snort sur Prelude-IDS sont sa popularité et sa disponibilité
sur de nombreuses plateformes. Prelude-IDS se restreint aux plateformes Linux, FreeBSD, OpenBSD,
NetBSD, Sun/Solaris et MacOsX, alors que nous pouvons retrouver Snort sur toutes ces plateformes
et d’autres16 comme Windows. L’importance de la base de données des signatures d’attaque de Snort,
explique peut être sa plus grande popularité.
Prelude-IDS est de plus en plus connu dans le monde des professionnels de la sécurité et a l’avantage
sur Snort de ne pas être un NIDS pur puisqu’il intègre des fonctionnalités NIDS et HIDS17 . De plus, il
est capable de récupérer les fichiers de logs (syslog) d’un bon nombre d’équipement réseaux actifs18 afin
de les analyser sur la sonde spécialisée à cet effet (Prelude-LML) et d’envoyer les alertes à sa base de
donnée centralisée pour que l’analyste réseau puisse en tirer des informations pertinantes. Il est donc un
IDS hybride.
Dans ce qui suivra, nous ne comparerons que ce qui est comparable, c’est-à-dire la partie NIDS de
Prelude-IDS et Snort.
2.3.1 Moteur d’analyse et banque de signatures
Prelude comme Snort font des analyses par recherche de similitudes (à l’aide des signatures). Le mode de
fonctionnement est alors similaire. Autant pour Prelude-IDS que pour Snort, les solutions sont stables.
Prelude-IDS a un soucis de suivi des standards (pour pouvoir utiliser les signatures d’autres moteurs,
échange des messages en XML, IDMEF). En regroupant les alertes de même type, nous nous retrouvons
alors avec aproximativement le même nombre d’alertes (Prelude ayant ses propres règles, il est normal
qu’il en trouve un peu plus que Snort). Prelude-NIDS comme Snort offrent la possibilité d’archiver les
payloads.
Prelude-IDS a l’avantage d’être très modulaire de par son architecture client-serveur. Un manager peut
gérer plusieurs sondes et une sonde peut envoyer ses alertes à plusieurs managers. Le filtrage au ni-
veau de la sonde pour savoir à quel manager est envoyée telle alerte ou telle autre n’est pas encore
15
http ://www.leroutier.net/Projects/PreludeIDS
16
La liste complète des plateformes compatibles est disponible sur : http ://www.snort.org/about.html
17
Host Intrusion Detection System, intégré dans Preldue comme une fonction de récupération des logs Syslog et de leur
analyse
18
Routeurs, Firewall, etc..
15
opérationnel. De plus, Prelude-IDS n’offre aucune sonde réseau permettant la détection d’attaques par
l’heuristique comme le permet Snort via le module SPADE. Grâce à l’architecture modulaire et standar-
disée de Prelude-IDS, il suffirait d’inclure une sonde Snort dans l’architecture de Prelude afin d’obtenir
une détection par l’heuristique sur le ou les segments voulus.
Les deux produits nous fournissent des alertes bien détaillées qui permettent de connaı̂tre la source
et la destination d’une attaque, le type d’attaque, un classement de sévérité de l’alerte ou encore un
lien vers un bulletin d’alerte officiel. Dans les deux outils, il est intéressant de constater la présence
de niveaux d’alertes permettant d’en déduire du premier coup d’oeil la dangerosité. Il est à noter que
Prelude-IDS archive aussi les charges utiles des trames suspectes. Cela permettra ensuite, dans certains
cas, à l’administrateur d’analyser le contenu afin d’écarter plus facilement les faux-positifs.
2.3.2 La console de l’analyste (frontends)
Les plus grandes différences entres les 2 outils se trouvent au niveau des frontends. Sous Prelude, il n’y
a pas vraiment de frontends officiel. Le premier fut développé en PHP, puis quelques semaines après sa
parution, un nouveau frontend en perl arrivait à maturité pour le remplacer. Il y en a encore d’autres,
mais c’est le frontend perl qui est en ce moment le plus abouti et le plus riche. C’est donc lui que nous
allons comparer avec le frontend dédié à Snort : ACID.
Snort compte lui aussi plusieurs interfaces et sa popularité fait qu’il est maintenant intégré dans des ou-
tils comme webmin. Cependant, la référence reste ACID. Le classement et regroupement des alertes sont
dans les deux cas possibles suivant des critères communs basiques pour les deux IDS (même adresse IP
source, même type d’attaque, même niveau d’alerte, ...). Pour des filtrages plus détaillés, la logique est
différente dans les deux outils.
Le frontend-perl de Prelude-IDS propose une rubrique Filter Factory qui permet de créer des filtres, de
les modifier ou de les supprimer.
Au niveau de l’interface graphique, autant Prelude-IDS que Snort proposent des graphiques et statistiques
permettant d’avoir une vue globale des attaques sur le réseau.
2.4 Conclusion
Dans le cadre de ce projet, nous préférerons donc Prelude-IDS à Snort, puisque celui-ci intègre direc-
tement deux fonctionnalités (NIDS et HIDS), très intéressantes pour la suite de cette étude. De plus, la
première partie de ce projet effectuée par Monsieur Saladino avait déjà mené à la conclusion de l’utili-
sation de ce produit Open Source déjà bien abouti.
16
Chapitre 3
Étude et comparatif de reverse-proxys
Afin de déterminer quel reverse-proxy utiliser dans l’architecture de SIMS orientée Web, nous allons en
étudier plusieurs. Nous dresserons un petit comparatif entre différents produits afin de sélectionner le
produit correspondant à nos attentes. Nous nous pencherons tout particulièrement sur les possibilités de
configuration offertes ainsi que sur les informations (logs, etc...) des tentatives d’attaques bloquées. Ces
dernières sont un point crucial dans le projet puisque nous recherchons un produit qui nous fournisse un
grand nombre d’informations pertinantes, permettant une corrélation avec celles d’une sonde réseau.
3.1 Squid
Squid est un proxy/reverse-proxy Open Source, servant en premier lieu d’accélérateur Web (cache).
Configuré en proxy (dans une entreprise par exemple), il a pour but de réduire l’utilisation d’une connexion
à Internet. En effet, lorsqu’un grand réseau LAN1 est connecté sur Internet et qu’un grand nombre de
personnes surfent sur le Web, il y a de fortes chances que plusieurs accès sur un même site se fassent dans
un court intervalle de temps. Le proxy va donc enregistrer tout ce qui n’est pas susceptible de changer
entre deux accès à un même site. Il s’agira donc de tout contenu non dynamique comme des pages html,
des images, etc... Il va ensuite fournir aux clients voulant accéder à des pages déjà visitées, ce qu’il a
enregistré en cache plutôt que d’envoyer une requête au serveur Web distant.
Squid configuré en reverse-proxy a pour but de réduire la charge d’un serveur Web. Il se place donc entre
Internet et le serveur Web et se charge de fournir à tous les clients les contenus statiques du serveur afin
de le laisser libre pour les tâches de génération de pages html (pages dynamiques du serveur). L’ajout
d’un reverse-proxy dans une architecture réseau permettra donc de réduire le nombre de serveurs puis-
qu’une partie de leurs tâches seront prise en charge par le reverse-proxy.
Des fonctions de filtrage et de contrôles d’accès sont également disponibles, ce qui permettra dans le cas
d’un proxy de contrôler et restreindre l’accès à certains sites et dans le cas d’un reverse-proxy, d’accroı̂tre
1
Local Area Network, réseau d’entreprise
17
la sécurité. C’est donc dans cette optique que nous allons analyser le fonctionnement de ce produit.
3.1.1 Fonctionnement
Plusieurs modes de fonctionnements sont envisageables :

Standard Proxy Cache Un proxy standard est utilisé pour mettre en cache des pages Web statiques
sur un réseau local. Comme expliqué précédemment lorsqu’une page est réclamée une seconde
fois par un client Web (browser2 ), celui-ci recevra les données du proxy local plutôt que celle du
serveur Web d’origine. Le browser du client devra explicitement envoyer ses requêtes au proxy
plutôt qu’au serveur Web cible. C’est ensuite le proxy qui, lui même, établira cette connexion ou
alors servira le client avec des données enregistrées dans son cache.
Transparent Cache Un cache transparent a le même but qu’un proxy standard mais opère de manière
transparente. Le browser n’a pas besoin d’être explicitement configuré pour passer par le proxy.
Dans ce mode, le proxy intercepte le trafic réseau et retire le trafic HTTP (sur le port 80) du réseau.
Si le contenu demandé ne se trouve pas dans le cache du proxy, celui-ci relaiera (comme le ferait
un routeur) la requête effectuée par le browser du client. Ce mode d’utilisation est surtout utilisé
par les ISP3 , puisqu’il ne requiert aucune configuration spécifique du browser client.
Reverse Proxy Cache Un reverse-proxy diffère des deux autres modes d’utilisation. Il se place dans
l’architecture du serveur et non plus dans celle du client. Comme susmentionné, il a pour but de
soulager les serveurs Web ainsi que de répartir la charge. De plus à l’aide du filtrage de contenu,
il permettra d’accroı̂tre la sécurité sur les serveurs Web. Les architectures envisageables ont été
discutées dans le chapitre 4.1 (page 12) du projet de semestre, que je vous laisserai consulter pour
plus d’informations.
3.1.2 Caractéristiques
Squid offre les fonctionnalités suivantes :

– Cache HTTP et FTP
– Prend en charge les connexions sécurisées HTTPS (très utile en configuration reverse-proxy)
– Hiérarchie de cache (à l’aide d’échanges d’informations entre proxys)
– Contrôle d’accès
– Agent SNMP intégré
– Cache pour les DNS lookups
La fonctionnalité la plus intéressante dans le cadre de ce projet et celle de contrôle d’accès, puisqu’elle
nous permettrait d’établir des règles afin de filtrer les requêtes considérées dangereuses.
2
au sens navigateur Web
3
Internet Service Provider, fournisseurs d’accès Internet
18
3.1.3 Installation
Pour ce faire, nous téléchargeons les sources sur l’un des nombreux miroir :
ftp ://sunsite.cnlab-switch.ch/mirror/squid/squid-2/STABLE/squid-2.5.STABLE6.tar.gz
Nous décompressons l’archive dans un répertoire (/usr/local/src) :
jo:/usr/local/src# tar -xvvzf squid-2.5.STABLE6.tar.gz
Et nous nous plaçons maintenant dans le répertoire des sources pour passer à la configuration de la
compilation :
jo:/usr/local/src/squid-2.5.STABLE6# ./configure --prefix=/usr/local/squid \

--enable-err-language=French
Nous précisons le répertoire de destination de l’application ainsi que la langue utilisée par les pages
d’erreurs retournées par Squid.
Voici une liste non exhaustive des options de compilation utilisables lors de la configuration :
– Choix de la méthode d’allocation de la mémoire pour le cache, activation des librairies écrites pas
Doug Lea (–enable-dl-malloc)
– Compilation interne de la librairie des expression régulières (–enable-gnuregex).
– Activation d’un agent SNMP (–enable-snmp).
– Activation du contrôle d’accès sur les adresses MAC (–enable-arp-acl)
– Choix du protocole d’échange de cache entre les proxys (–enable-cache-digests ou –enable-htcp)
– Enregistrement de l’adresse source de chaque requête (–enable-forw-via-db)
Pour plus de détails sur les options de compilation disponibles, consultez :
http ://squid-docs.sourceforge.net/latest/book-full.html#AEN250
Nous pouvons maintenant passer à la compilation et à l’installation :
jo:/usr/local/src/squid-2.5.STABLE6# make
jo:/usr/local/src/squid-2.5.STABLE6# make install
3.1.4 Configuration
Maintenant que Squid est installé, nous pouvons passer à sa configuration. Pour ce faire nous éditons le
fichier squid.conf (/usr/local/squid/etc/squid.conf). Un grand nombre de valeurs par défauts sont com-
mentées (à l’aide du caractère #). Nous devons donc décommenter tous les tags4 utiles et changer leurs
valeurs si nécessaire. Voici donc ce que nous avons modifier :
4
directives de configuration
19
http_port 80
cache_dir ufs /usr/local/squid/var/cache 100 16 256
cache_effective_user proxy
cache_effective_group proxy
visible_hostname proxyJo
#Section de configuration du reverse-proxy (httpd accelerator)

httpd_accel_port 80
httpd_accel_host 192.168.1.4
httpd_accel_single_host on
httpd_accel_with_proxy off
http port Nous permet de préciser sur quel port Squid agira.
cache dir Nous permet d’indiquer la mémoire maximale du cache ainsi que son emplacement sur le
disque. Il nous permet ensuite de donner le nombre maximal de répertoires et sous répertoires que
Squid pourra créer pour l’indexation des pages web.
cache effective user et cache effective group Nous permettent de préciser sous quel user Squid s’exécutera.
visible hostname Précise le nom du proxy (qui sera donné dans les pages d’erreurs).
httpd accel port Nous permet de préciser sur quel port le reverse-proxy agira.
httpd accel host Nous permet de préciser l’adresse du serveur pour lequel le reverse-proxy travaille.
httpd accel single host Indique si le reverse-proxy travaille pour un ou plusieurs serveurs (1 seul dans
notre cas).
httpd accel with proxy Permet de faire travailler Squid en proxy et reverse-proxy (en même temps).
Il faut ensuite prendre garde à mettre les droits suffisants sur le répertoire de logs, afin que l’utilisateur
sous lequel s’exécute Squid puisse y accéder en lecture et en écriture. Nous pouvons ensuite lancer la
création du cache swap qui permettra à Squid d’enregistrer les fichiers statiques :
jo:/usr/local/squid/sbin# ./squid -z
Nous pouvons maintenant lancer le reverse-proxy à l’aide de la commande suivante :
jo:/usr/local/squid/sbin# ./squid -d 1 -N
Filtrage
Quel que soit le mode de fonctionnement de Squid, la syntaxe de filtrage est identique. Afin de s’adapter
au domaine d’application de Squid à notre projet, les exemples et explications ci-dessous considèrent un
mode de fonctionnement en reverse-proxy.
20
Le filtrage HTTP nous est offert par le biais du tag http access et http reply access qui sont des opérateurs
ACL5 . Le premier permet d’effectuer le filtrage de la requête d’un client, alors que le second permet le
filtrage de la réponse du serveur. Le filtrage est possible sur les paramètres suivants (type ACL) :
– Adresse IP source / destination
– Domaine source / destination
– Expression régulière :
– Sur une URL entière (url regex)
– Sur le chemin de l’URL sans tenir compte du type et du nom du serveur (urlpath regex)
– Sur le nom de domaine source et destination (srcdom regex et dstdom regex)
– Jour courant et heure
– Port de destination
– Protocole (FTP, HTTP, SSL)
– Méthode (POST, GET)
– Le type du browser client
– Username / password lors de procédure d’authentification
– Communauté SNMP
Il suffit de définir un ACL, (s’apparentant à la déclaration d’un type dans un langage de programmation)
en précisant sur quel paramètre ci-dessus s’applique la déclaration (donc le type de l’ACL). Ensuite
nous pouvons définir si l’ACL est autorisé ou non via un opérateur (ici le tag http access) . En voici un
exemple :
acl ClientOK src 10.192.73.0/23

http_acces allow ClientOk
Tous les client faisant partie du sous réseau TCOM6 auront le droit d’accéder le serveur Web, alors que
tous les autres seront rejetés. Il est bien de noter que Squid fonctionne en whitelist par défaut et que la
ligne ”http acces deny all” est implicite à la fin de la configuration des règles d’accès. Celle-ci indique
bien un fonctionnement en whitelist puisque tous les accès sont refusés, sauf ceux explicitement précisé
à l’aide d’une règle ”allow”. Il est tout de même judicieux de l’ajouter à la fin de la définition des règles,
afin que l’administrateur non averti ne se trompe pas.
Il est aussi possible de travailler en blacklist en ajoutant simplement la règle suivante à la fin de la confi-
guration des accès : http acces allow all. Celle-ci changera donc le fonctionnement par défaut et des
règles ”deny” devront être définies afin de créer la blacklist.
Un ACL permet la définition de plusieurs conditions d’un même paramètre sur une même ligne. Il est
alors possible de condenser l’écriture des conditions en séparant celles-ci par un espace, qui sera in-
terprété comme un OU. En voici un petit exemple :
5
Access Control List
6
Réseau du département de télécommunication de l’EIVD
21
acl ClientsOK src 10.192.73.0/23 10.192.63.0/16

http_acces allow ClientsOk
Ceci signifie donc que les deux sous réseaux définis ci-dessus auront accès au serveur Web. Squid
contrôlera que la source de la requête appartienne au sous-réseau 10.192.73.0/23 ou 10.192.63.0/16.
Afin de simplifier la lecture du fichier de configuration il est possible de définir les conditions dans un
fichier externe. Si dans l’exemple ci-dessus, la liste des adresses autorisée à se connecter au serveur Web
est définie dans le fichier /usr/local/squid/conditions/clientsOk (une condition par ligne), il suffira de
charger la règle de la façon suivante :
acl ClientsOK src "/usr/local/squid/conditions/clientsOk"

http_acces allow ClientsOk
De la même manière que pour les conditions, il est possible de condenser l’écriture avec les opérateurs
ACL (tag http access dans ce cas) et de créer une logique combinatoire afin de définir une règle com-
plexe. Il suffira de les séparer par un espace, qui signifiera que les deux conditions (ACL) doivent être
valides afin que la règle s’applique. Nous obtenons donc un ET logique entre les conditions. En voici un
exemple :
acl monNet src 168.209.2.0/255.255.255.0

acl heureTravail time 08:00-17:00
http_access deny monNet heureTravail

http_access allow all
Si une machine de monNet tente d’accéder le serveur Web pendant les heures de travail, la connexion
sera refusée puisque les deux conditions ACL s’appliqueront. Si par contre une machine de monNet
tente d’accéder le serveur hors des heures de travail, la condition ”heureTravail” ne sera plus valide.
Comme un ET logique est opéré entre les différentes conditions, la règle ne sera pas appliquée puisque
l’une d’elle n’est pas valide. C’est ensuite les règles suivantes qui définiront si un filtrage est opéré. Dans
l’exemple ci-dessus le serveur Web sera accessible par les machines de monNet uniquement hors des
heures de travail.
Il est maintenant possible à l’aide de ces deux fonctionnements (ET et OU) de définir des conditions
complexes pour opérer un filtrage précis.
Pour plus de détails sur les différents paramètres utilisables pour la déclaration d’ACL (types ACL),
consultez la page Web suivante : http ://squid-docs.sourceforge.net/latest/book-full.html#AEN1493
Jusqu’à maintenant, nous avons uniquement travaillé avec l’opérateur ACL ”http access”, mais il existe
différents types d’opérateurs permettant la gestion des actions en fonction de la requête. Le lecteur
intéressé pour se référer à la page suivante : http ://squid-docs.sourceforge.net/latest/book-full.html#AEN1831
pour de plus amples informations à ce sujet.
22
Filtrage des requêtes (http access)
Cette opérateur déjà grandement illustrée dans les exemples ci-dessus ne sera pas plus détaillé ici. Nous
allons par contre illustrer la configuration qu’il faudrait mettre en place afin que Squid agisse comme
reverse-proxy spécifique à un site Web (comme le fait ProxyFilter7 ) :
acl bonneUrlAccueil url_regex -i securitystore/$ securitystore$

acl bonneUrlLogin url_regex -i login\.php$
acl imagesOk url_regex -i images/.*\.jpg$ images/.*\.gif$
acl cssOk url_regex -i .*\.css$
http_access allow bonneUrlAccueil

http_access allow bonneUrlLogin
http_access allow imagesOk
http_access allow cssOk
#deny all implicite !!!
Grâce à cette configuration, il sera possible d’accéder à la page d’accueil du securitystore (avec les
images et feuilles de style) ainsi qu’à la page d’authentification (login.php). Malheureusement, nous
remarquons que Squid ne permet pas un filtrage de contenu (paramètres contenus dans un POST par
exemple), ce qui ne nous permettra pas de filtrer les cas de SQLinjection, XSS, etc... ou toutes autres
attaques effectuées via un paramètre non contenu dans l’URL (GET).
Filtrage des réponses (http reply access)
Cet opérateur s’utilise exactement comme l’opérateur de filtrage des requêtes mais ne s’occupe que du
filtrage des réponses fournies au client.
3.1.5 Réécriture d’URL et HTTP redirect
Il est possible, à l’aide d’un programme externe, de réécrire les URL à l’aide d’expressions régulières.
Apache offre aussi cette opportunité comme la plupart des serveurs Web. Il est donc nécessaire de choi-
sir si la réécriture se fera plutôt sur le serveur Web ou le reverse-proxy. Elle permettra ainsi de cacher
l’arborescence crée sur le serveur ou de rediriger des requêtes en fonction de la page demandée. Nous
avons testé Squirm (redirector Open Source pour Squid) disponible sur : http ://squirm.foote.com.au/
Il permet la réécriture des requêtes émises par les browser Web à l’aide d’expressions régulières.
Il n’est malheureusement pas possible à l’aide de ce module externe de réécrire les réponses du serveur
Web. Il sera ainsi impossible de réécrire les réponses HTTP redirect8 émises par le serveur Web. Celle-ci
contiendra donc l’adresse IP du serveur Web lui-même, ce qui forcera le client à essayer de se connecter
7
Reverse-proxy développé par Sylvain Tissot dans le cadre de son travail de diplôme 2003 et étudié dans le cadre du travail
de semestre
8
Réponse indiquant au client la nouvelle page à charger
23
directement sur le serveur Web (sans passer par le reverse-proxy). Il faudra donc plutôt réécrire l’entête
HTTP directement sur le serveur Web afin d’opérer un remplacement de l’adresse IP du serveur par celle
du reverse-proxy. Ainsi, le client se fera rediriger sur le reverse-proxy, ce qui ne posera aucun problèmes.
3.2 DansGuardian
DansGuardian est un produit Open Source offrant des possibilités de filtrage de contenu. Il fonctionne
sur les systèmes d’exploitation suivants : Linux, FreeBSD, OpenBSD, NetBSD, Mac OS X, HP-UX, et
Solaris. Il permet d’explorer le corps de contenu HTTP (donc des pages html ou autre). A l’instar de
Squid, il n’implémente aucune fonction de cache et n’est donc pas utilisé comme accélérateur de serveur
Web. Son but premier est de protéger des utilisateurs (souvent des enfants) contre des contenus litigieux.
Il s’agit donc plutôt d’une utilisation en proxy et non en reverse-proxy.
Étant donné qu’aucune documentation précise sur Dansgusrdian n’est disponible sur Internet, nous avons
décidé de le tester afin d’observer l’effet de la configuration sur les contenus traités ainsi que les possi-
bilités offertes pour une configuration en reverse-proxy.
3.2.1 Caractéristiques
– Filtre (remplacement de mots) le contenu de la réponse du serveur (fichiers texte et HTML) à

l’aide d’expressions régulières
– Possibilité d’assigner un popoids des mots afin de définir si un filtrage à lieu en fonction de leur
nombre d’apparition dans un contenu HTML ou texte
– Bloquage de réponse HTTP offert selon les type MIME retourné par le serveur
– Bloquage de réponse HTTP offert selon l’URL demandée par un client à l’aide d’expressions
régulières
– Syntaxe de la blacklist d’URL compatible avec celle de Squid
– Filtrage d’URL sur des requêtes HTTPS
– Log facile à lire et configurable dans différents formats
– Possibilité de logger les usernames lors d’authentification HTTP
– Possibilité de bloquer les uploads (uniquement suivant la taille d’un POST)
– Possibilité de journaliser les sites qui auraient été bloqués sans pour autant les bloquer
– Les caractères Big5, Unicode et les caractères peuvent être utilisés pour des recherches dans des
contenu HTML
– Supporte les fichiers compressés
24
3.2.2 Installation
Pour ce faire, nous téléchargeons les sources sur : http ://mirror2.dansguardian.org/downloads/2/Stable/DansGuardian-

2.6.1-9.source.tar.gz
Nous décompressons l’archive dans un répertoire (/usr/local/src) :
jo:/usr/local/src# tar -xvvzf DansGuardian-2.6.1-9.source.tar.gz
Et nous nous plaçons maintenant dans le répertoire des sources pour passer à la configuration de la
compilation :
jo:/usr/local/src/DansGuardian-2.6.1-9.source# ./configure --runas_grp root --runas_usr root
Nous procédons à une configuration par défaut en ce qui concerne l’emplacement de tous les répertoires
utiles à Dansguardian. Nous précisons simplement sous quel utilisateur et quel groupe s’exécutera Dans-
guardian (root dans notre cas, afin que l’application aie accès au port 80 de la machine).
Pour plus de précisions sur les options de configuration vous pourrez consulter :
http ://dansguardian.org/downloads/detailedinstallation2.html#installation
La configuration ainsi faite placera les différents fichiers de Dansguardian dans les répertoires suivants :
Description des fichiers Emplacement

Les binaires /etc/dansguardian
Les fichiers de configuration /etc/dansguardian/
Les scripts de démarrage /etc/rc.d/init.d/
Les fichiers perl permettant l’administration via un browser Web /home/httpd/cgi-bin/
Les fichier de manuels /usr/man/
Les journaux (logs) /var/log/dansguardian/
Le fichier indiquant le pid (Process ID, numéro du processus Dansguardian) /var/run/
Nous pouvons maintenant passer à la compilation et à l’installation :
jo:/usr/local/src/DansGuardian-2.6.1-9.source# make
jo:/usr/local/src/DansGuardian-2.6.1-9.source# make install
3.2.3 Architecture
Après bien des essais et analyses à l’aide d’Ethereal9 , nous nous sommes rendus compte qu’il n’était
pas possible d’utiliser Dansguardian comme pièce unique dans l’architecture d’un reverse-proxy (Figure
3.1).
En effet, les pages Web reçues par les browser (clients) ne contenaient pas toutes les informations
nécessaires pour leur affichage, ce qui provoquait une erreur dans le browser. Dansguardian travaille
9
analyseur réseau Open Source
25
F IG . 3.1 – Architecture de Test (non-fonctionnelle)
d’une manière différente qu’un serveur Web. La figure 3.2 illustre son fonctionnement qui implique l’ad-
jonction d’un proxy comme Squid.
F IG . 3.2 – Principe de fonctionnement de Dansguardian
Notre reverse-proxy se compose maintenant d’un cache (Squid) et d’un analyseur de contenu (Dansguar-
dian), comme l’illustre la figure 3.3. Ces deux applicatifs s’exécutent sur la même machine et utilisent la
loopback pour communiquer.
F IG . 3.3 – Architecture retenue
3.2.4 Configuration
Maintenant que Dansguardian est installé, et que son architecture est définie, nous pouvons passer à sa
configuration. Pour ce faire nous éditons le fichier dansguardian.conf (/etc/dansguardian/dansguardian.conf).
Les principales lignes de configuration figures donc ci-dessous :
26
# Adresse IP sur laquelle Dansguardian attend les requêtes

filterip = 192.168.1.2
#Port sur lequel Dansguardiant attend les requêtes

filterport = 80
# L’adresse IP du proxy à qui il transmettra les requêtes (après filtrage)

proxyip = 127.0.0.1
# Port sur lequel atteindre le proxy

proxyport = 3128
Cette configuration se rapporte à l’architecture de la figure 3.3. Nous remarquons que Dansguardian
transmet ses requêtes sur le port 3128 de sa loopback, qui correspond au port d’écoute de Squid, qui les
transmettra au serveur Web.
Il est donc indispensable de modifer la configuration de Squid que nous avions présenté à la section
3.1.4. Nous changeons simplement la directive suivante afin que Squid écoute sur l’adresse et le port par
lequel Dansguardian transmet ses requêtes :
http_port 127.0.0.1:3128
Il est maintenant possible de démarrer Dansguardian à l’aide de la commande suivante :
jo:/#dansguardian
Il est bien de noter que Squid doit être démarré avant Dansguardian, puisque celui-ci ne démarrera pas
tant qu’il ne pourra pas atteindre (connexion TCP) le proxy auquel il transmettra ses requêtes.
Filtrage
Les termes bloquage et filtrage utilisés dans la suite de ce document on une signification particulière. Le
terme bloquage indique un refus de transmission d’une requête client10 ou d’une réponse du serveur par
Dansguardian. Le terme filtrage, indique quant à lui que le corps11 de la réponse émise par le serveur
(faisant suite à la requête d’un client) est contrôlée et modifiée si nécessaire (selon le fichier de configu-
ration contentregexplist mentionné ci-dessous).
Paramètres configurables pour le filtrage dans le sens aller (requête vers le serveur) :
– Sites entier interdits (bloqués) (fichier : bannedsitelist)
– URL12 de sites interdits (bloqués) (fichier : bannedurllist, bannedregexpurllist)
– Sites entier non filtrés et non bloqués (dont le contenu aller-retour n’est pas contrôlé) (fichier :
exceptionsitelist)
10
Indiqué au client par une page HTML ”AccAccèsfusé”
11
Document HTML ou TXT
12
”Sites entier interdits” bloque les accès au site entier alors que ce fichier de configuration offre la possibilité de bloquer
une partie d’un site.
27
– URL13 de sites non bloqués et non filtrés (fichier : exceptionurllist)

– Utilisateurs interdits (bloqués lors d’authentification HTTP) (fichier : banneduserlist)
– Utilisateurs non filtrés et non bloqués (lors d’authentification HTTP) (fichier :exceptionuserlist)
– Adresses IP source (client Web) non autorisées (requête bloquée) (fichier : bannediplist)
– Adresses IP source (client Web) dont les paquets (aller-retour) ne sont pas filtrés ni bloqués (fi-
chier : exceptioniplist)
Paramètres configurables pour le filtrage dans le sens retour (réponse du serveur) en fonction des entêtes
HTTP :
– Bloquage de la réponse suivant le type MIME retourné par le serveur (fichier : bannedmimetype-
list)
– Bloquage de la réponse suivant l’extension du fichier demandé par la requête (fichier : bannedex-
tensionlist)
Paramètres configurables pour le filtrage dans le sens retour (réponse du serveur) en fonction du corps
des réponse HTTP :
– Filtrage du corps de la réponse (remplacement de mots) à l’aide d’expressions régulières (fichier :
contentregexplist)
– Non bloquage des réponses contenant un des mots figurant dans le fichier exceptionphraselist
(filtrage par remplacement de mots toujours actif)
– Bloquage de réponses contenant un des mots figurant dans ce fichier (fichier : bannedphraselist)
– PICS14 , permettant d’établir des règles de bloquage en fonction du contenu de l’entête html (http-
equiv=”PICS-Label”) , permettant de décrire le contenu de la page d’une manière standardisée
(fichier : pics)
– Fichier permettant d’assigner un poids aux mots permettant ainsi d’établir des règles de filtrage en
fonction de leur nombre d’apparition dans les réponses HTTP (fichier : weightedphraselist)
L’utilisation d’expressions régulières pour le filtrage de contenu, nous semble un grand atout pour ce
produit, c’est donc pour cette raison que nous allons détailler la syntaxe de configuration et la plage
d’application du fichier correspondant (contentregexplist).
Le fichier contentregexplist
Celui-ci contient une liste de mots qui seront recherchés dans les pages retournées aux clients et rem-
placés par le mot de remplacement correspondant à celui trouvé dans le corps de la page HTTP. Dans
l’exemple ci-dessous, tous les popups javascript (alert) envoyés aux clients seront retirés et remplacés
par un commentaire HTML :
13
”Sites entier non filtré” autorise des accès au site entier alors que ce fichier de configuration offre la possibilité de ne pas
filtrer et bloquer une partie d’un site.
14
http ://www.w3.org/PICS/
28
"<script.*>.*alert.*</script>"->""
Il est important de noter que les règles introduites dans ce fichier ne contrôle et remplacent en aucun
cas des mots dans les entêtes HTTP ou des paramètres POSTés par le clients. Ce type de filtrage n’a
donc pas une grande utilité dans une configuration en reverse-proxy puisque ce que l’on ne cherche pas
à protéger un utilisateur mais le serveur Web et l’application serveur elle-même. Il peut tout de même
avoir sa raison d’être dans une telle architecture si l’on pense à filtrer des scripts malveillants comme des
”document.cookie()” permettant les attaques de type XSS15 .
3.3 Conclusion
Synthèse des différents produits étudiés :

Open Fonctionnement Fonctionnement Syntaxe Filtrage de contenu Bloquage Bloquage Bloquage selon les URL
Source Whitelist Blacklist des règles HTML (réponses) selon GET selon entêtes HTTP rewriting
POST
ProxyFilter X X X XML X X X X
Squid X X X Expressions X selon certaines à l’aide
régulières d’un pro-
gramme
externe
Dansguardian X X Expression X X
régulières
AppShield X Par in- X X X X X
terface
graphique
ProxyFilter Ce produit étudié durant le travail de semestre et développée par Sylvain Tissot dans le
cadre de son projet de Diplôme (2004) repose sur l’architecture d’Apache. Il est donc le module
d’un serveur Apache dédié à l’exécution de celui-ci. La configuration en whitelist est très pointue
et très ccoûteuseen temps mais offre une protection optimale puisque seul les paramètres non
dangereux sont autorisés à être relayé au serveur Web. De même, il sera possible d’éditer une
whitelist ou blacklist des entêtes HTTP pouvant être retournées aux clients.
AppShield Ce produit étudié par Sylvain Tissot durant son travail de diplôme16 est un outil propriétaire
(donc cher) offrant une configuration de type whitelist. Il permet l’utilisation de niveaux de sécurité
prédéfinis ainsi que l’affinement de ceux-ci par différentes règles pouvant être définies à l’aide
d’une interface graphique. La création de nouvelles règles est facilitées à l’aide de l’analyse des
logs qui permettra la création de règles en fonction de ceux-ci en un simple clic. Un support SSL
est disponible, ce qui permet la sécurisation de sites HTTPS.
Squid (Proxy Open Source) Configuré en reverse-proxy, celui-ci joue le rôle d’accélérateur de serveur
Web plutôt que de moyen de protection contre les attaques Web. En effet il offre un service de
cache permettant de fournir les pages statiques et les images aux clients à la place du serveur Web.
Cependant, il permet à l’aide de règles d’accès (ACL) de définir le bloquage de requêtes clientes.
Ce genre de contrôle d’accès est toute fois limité aux types ACL défini par Squid (section 3.1.4)
15
Cross site scripting
16
étude disponible sur http ://proxyfilter.sourceforge.net/documents/rapport websecurity diplome.pdf
29
et limitera le champ d’action de celui-ci. Squid offre un filtrage17 dans le sens aller (requête vers
le serveur) ainsi que dans le sens retour (réponse du serveur).
Dansguardian Ce proxy Open Source permet un filtrage pointu sur les contenu HTML ainsi qu’un
bloquage des URLs dangereuses demandées par les clients Web. Configuré en reverse-proxy, il
permettra la protection du serveur via des expressions régulières offrant la validation des requêtes
HTTP. De plus il permettra la protection des clients en contrôlant le contenu des pages HTML
transmises à ceux-ci à l’aide d’expressions régulières.
17
Au sens, bloquage de messages
30
Chapitre 4
Architecture retenue et mise en place
Ce chapitre définit l’architecture globale du banc d’essai déployé dans le cadre de ce projet. De plus, il
soulève les problèmes d’implémentation du reverse-proxy (Dansguardian), propose les modification à y
apporter et explique comment celles-ci ont été effectuées. Ensuite, la configuration et la mise en place de
la totalité de l’architecture définie sur la figure 4.3 y sont expliqués.
4.1 Définition de l’architecture
Après l’étude de ces différents reverse-proxys (ProxyFilter, AppShield, Squid et Dansguardian), il en est
ressorti que deux utilisations étaient envisageables :
1. Reverse-proxy générique, nécessitant peu de configuration.
2. Reverese-proxy spécifique à l’application à protéger, nécessitant une configuration pour chaque
formulaire présent dans les pages HTML fournies par le serveur (exemple : ProxyFilter).
Le premier principe cité repose sur l’utilisation d’une blacklist, alors que le second repose sur une whi-
telist.
Il est évident qu’une whitelist sera toujours plus efficace qu’une blacklist puisqu’elle bloquera tout ce
qui n’est pas spécifiquement autorisé. Cette méthode de travail permet de bloquer un grand nombre d’at-
taques puisqu’elle ne nécessite pas de signatures. Elle stoppera donc simplement tout ce qui n’est pas
considéré comme normal pour l’application Web. L’inconvénient majeur de ce fonctionnement vient de
la configuration des règles de filtrage. En effet, il faudra, comme dans le cas de ProxyFilter, définir pour
chaque document HTML ce qu’il est possible de fournir en paramètres dans l’URL, dans les données
POSTées et dans les entêtes HTTP.
Un fonctionnement en blacklist devra, quant à lui, définir toutes les signatures des attaques que l’on
désire stopper, sans ”aucune” configuration en fonction de l’application à protéger. Il sera donc aisé de
protéger son serveur Web en plaçant simplement le reverse-proxy devant celui-ci. La sécurité du serveur
Web dépendra ainsi des signatures disponibles sur le reverse-proxy, ce qui impliquera des mises à jour
31
régulières de la liste des signatures.
Dans le cadre de ce projet, nous avons privilégié une mise en place facilitée (sans configuration spécifique
à l’application Web à protéger) plutôt que l’efficacité d’un principe de fonctionnement en whitelist. Ceci
permettra de proposer un produit simple d’installation et efficace puisque l’inconvénient du fonction-
nement en blacklist du reverse-proxy est ”contré” à l’aide de l’ajout de sondes NIDS et HIDS (comme
proposé lors du travail de semestre) dans l’architecture globale. Celles-ci permettront, à l’aide d’une
console d’administration des sondes (Prelude-NIDS et Prelude-HIDS) et d’une corrélation des alarmes
générées par celles-ci, d’obtenir des informations pertinentes relatives à la sécurité des serveurs Web.
Ceci permettra à l’administrateur en charge de la sécurité du réseau, d’ajouter ou corriger les règles de
filtrages définies sur le reverse-proxy.
Notre choix s’est porté sur Dansguardian, puisque celui-ci travaille en blacklist (proxy générique) et
offre les mêmes caractéristiques que Squid, avec la capacité supplémentaire non négligeable permettant
de filtrer les corps des documents HTML et TXT. Comme expliqué lors des tests, Dansguardian est
uniquement utilisable avec l’adjonction d’un proxy. Nous utiliserons donc Squid comme cache pour
Dansguardian. La figure 4.1 illustre le fonctionnement de Dansguardian en reverse-proxy installé sur
une machine disposant d’une seule interface réseau.
L’utilisation de Dansguardian implique quelques petites modifications de son code source, puisque celui-
ci n’est pas prévu pour fonctionner en reverse-proxy. Nous lui avons alors ajouté la possibilité de
contrôler des données POSTées par les clients. Nous avons ensuite testé son fonctionnement et l’avons
adapté (le code source) aux besoins d’un reverse-proxy. Ces modifications sont relatées dans la section
4.2.
La figure 4.1 illustre l’architecture retenue pour le reverse-proxy fonctionnant à l’aide de signatures
d’attaques (blacklist), alors que la figure 4.2 illustre l’architecture globale de SIMS orienté Web. Cette
architecture a été ébauchée lors du travail de semestre.
Pour le travail de corrélation qui suivra, nous pensons que l’adjonction d’un HIDS sur le firewall en
plus des sondes NIDS avant et après le reverse-proxy et de la sonde HIDS du reverse-proxy est un atout
supplémentaire. En effet, une attaque commence très souvent par une étape de découverte du réseau cible
et des services s’exécutant sur les machines accessibles. Le HIDS du firewall nous permettra de détecter
très facilement les scans de ports qui précédent une attaque. Une sonde NIDS ne pourrait pas suffire à la
détection de scans de ports puisque celles-ci n’ont pas une capacité d’analyse permettant la corrélation
d’événements indépendants et n’ont aucune possibilité d’établir des règles permettant de lever des alertes
affirmant qu’il y a eu un scan de ports. Il faudrait établir des règles permettant d’alerter l’accès à chaque
port d’une machine pour qu’un corrélateur externe puisse analyser ces alertes et en conclure à un scan de
ports. Le HIDS du firewall nous offre donc la possibilité de récupérer facilement des informations sur les
paquets refusés par le firewall et sur les ports auxquels ceux-ci s’adressaient. Une fois ces informations
transmises par le HIDS du firewall vers le Manager, il sera aisé de les analyser afin de mettre en évidence
les scans de ports et autres manipluations avant-coureuses d’une attaques.
32
F IG . 4.1 – Fonctionnement du reverse-proxy de SIMS orienté Web
Nous avons ensuite placé différentes sondes réseaux (NIDS) et host (HIDS permettant l’analyse de logs).
Afin de pouvoir en tirer les meilleures conclusions pour l’élaboration de la stratégie de corrélation, nous
avons placé un maximum de sondes. Nous disposons donc d’une sonde réseau à chaque niveau (pre-
reverse-proxy et post-reverse-proxy). La première permettra de relever des alertes avant l’éventuel blo-
quage du reverse-proxy (sonde pre-reverse-proxy) alors que la seconde permettra de relever les attaques
ayant tout de même passé le filtrage imposé par le reverse-proxy (sonde post-reverse-proxy).
De plus, nous avons disposé les sondes HIDS sur le firewall (comme expliqué ci-dessus), sur le reverse-
proxy ainsi que sur le serveur Web. Il nous sera possible, à l’aide de la sonde HIDS du reverse-proxy
d’observer les bloquages effectués par celui-ci. La sonde placée sur le serveur Web, nous permettra quant
à elle d’observer les accès effectués sur le serveur Web.
A l’aide des toutes ces informations, il nous sera possible de retracer l’activité d’un client et d’en déduire
précisément ses intentions (Cracker ou simple client Web). Le travail de corrélation qui suivra nous
amènera peut-être à retirer l’une ou l’autre des sondes NIDS ou HIDS puisque seule l’analyse des
différentes attaques et des informaitons recueillies par les sondes pourra nous prouver l’utilité de celles-
ci.
33
F IG . 4.2 – Architecture globale de SIMS orienté Web
Vous constaterez, à l’aide de la figure présentant l’architecture physique 4.3, que l’Intranet a été sup-
primé pour les tests, puisque celui-ci n’apporte rien de plus pour la corrélation des événements. Nous
avons donc créé une DMZ1 comprenant le reverse-proxy, le serveur Web, le SGBD du serveur Web ainsi
que le manager Prelude. Ce dernier devrait, pour des raisons de sécurité, se trouver dans le réseau local
de l’entreprise (comme illustré sur l’architecture logique globale), mais pour des raisons de facilité de
mise en place, nous avons préféré le garder dans la DMZ. La machine officiant en SGBD permettra, en
plus, d’interroger le manager des différentes sondes (Prelude manager) à l’aide d’un client Web (console
d’administration). Cette console d’administration devrait en principe se trouver dans le réseau d’entre-
prise afin d’éviter la mise en place d’une machine supplémentaire dans la DMZ. Pour des raisons de
facilité de mise en place, nous avons préféré la laisser dans la DMZ. Afin de ne pas dédier des machines
à chaque NIDS, nous en avons placé un sur la machine Prelude Manager et nous la connectons sur le
même segment que le serveur Web. Ce NIDS nous servira donc de sonde post-reverse-proxy alors que
la sonde pre-reverse-proxy se situera directement sur celui-ci. Il est évident que cette dernière capturera
le trafic post-reverse-proxy et pre-reverse-proxy, puisque le reverse proxy ne dispose que d’une seule
interface réseau. Afin d’isoler le trafic pre-reverse-proxy, il suffira, lors de la visualisation des alertes, de
mettre en place une règle de filtrage en fonction de l’adresse IP de destination.
1
Zone démilitarisée
34
F IG . 4.3 – Architecture physique de SIMS orienté Web
4.2 Modification du code source de Dansguardian pour le contrôle des

donnée POSTée
Après avoir obtenu des informations sur le forum de Dansguardian (http ://groups.yahoo.com/group/dansguardian/),
il s’est avéré très facile de modifier le code source pour que les données contenues dans un POST (requête
d’un client) soient contrôlées. Il faut donc ajouter le code ci-dessous dans le fichier ConnectionHand-
ler.cpp après le contrôle de la taille des paramètres du POST dans la méthode suivante ”handleConnec-
tion(Socket peerconn)” :
//si la requete n’est pas encore été refusée on contrôle le POST}

if (!checkme.isItNaughty){
#ifdef DGDEBUG
std::cout << "Check des data dans le POST" << std::endl;
#endif
//controle le buffer passé en paramètre avec les fichiers de configuration
//bannedphraselist et exceptionphraselist
checkme.checkme(&header.postdata);
//check pour le filtrage contentregexlist
35
header.postdata.contentRegExp();
}
L’inconvénient majeur de cette modification vient du fait que les fichiers de configurations utilisés pour
déterminer s’ il y a filtrage ou bloquage sont les mêmes pour les données émises au client (réponse du
serveur Web) et celles transmises par celui-ci (POST). De ce fait, si nous définissons des règles de filtrage
du POST afin d’éviter des attaques de SQLinjection, nous établirons une règle recherchant le pattern ’
OR 1=1. Si maintenant celui-ci se retrouve dans une phrase d’une page Web, celui-ci sera aussi filtrée.
Ce fonctionnement posera des problèmes puisque le filtrage opéré sur une requête HTTP ou une réponse
HTTP n’est pas le même. En effet, les attaques possibles du côté client et du côté serveur ne sont stricte-
ment pas identiques.
Améliorations
Dans l’architecture d’un reverse-proxy, il est préférable de bloquer les requêtes d’un client Web trans-
portant un contenu suspect, plutôt que de les filtrer (remplacement de mots). Cette conclusion est très
facilement justifiée lors du couplage du serveur Web avec une base de donnée. En effet, il serait très peu
souhaitable pour un client Web, de recevoir des données ne correspondant pas à sa requête (venant de la
substitution de mots opérée par le reverse-proxy). Dans tous les cas, il est préférable de l’avertir par une
page html de refus d’exécution du serveur plutôt que de filtrer le contenu de la requête HTTP à son insu.
De plus, il peu recommandable d’offrir la possibilité de bloquer la réponse du serveur Web (en envoyant
une page html similaire à celle d’un refus d’exécution), puisque l’on pourrait imaginer de simples déni de
services en insérant des mots bien précis dans un forum. La seule opération envisageable sur une réponse
HTTP est le filtrage de contenu (remplacement de mots) afin d’éviter la présence de scripts malveillants
tout en évitant des bloquages indésirables.
Après ces différentes observations, il nous est possible de définir les modifications que nous devrons
apporter à Dansguardian afin que celui-ci fonctionne en reverse-proxy.
Le filtrage du GET ne pose aucun problème puisqu’il est déjà disponible à l’aide d’expressions régulières
via le fichier de configuration bannedregexpurllist. Pour le filtrage du POST, il est indispensable d’utili-
ser des expression régulières. Il est flagrant, que pour l’exemple de SQLinjection donné ci-dessus, qu’il
est impossible d’établir une règle sans utiliser une expression régulière, puisque les ”1” utilisé dans l’at-
taques peuvent être remplacés par n’importe quel nombre.
Les trois principaux fichiers de configuration existants pour le filtrage de contenu (dans les deux sens)
sont : exceptionphraselist, bannedphraselist, contentregexplist. Nous garderons donc uniquement le fi-
chier contentregexplist pour opérer le filtrage de contenu (remplacement de mots) des réponses HTTP
émises par le serveur Web. Il nous faut alors retirer : bannedphraselist afin d’éviter le bloquage des
réponses du serveur HTTP et exceptionphraselist puisque celui-ci n’a plus aucun sens si bannedphra-
selist n’existe plus. En effet, il offrait la possibilité de relayer la réponse HTTP si un des mots qu’il
contenait apparaissaient dans la page Web, même si des mots bannis (contenu dans bannedphraselist
36
étaient présents). Il nous faudra ensuite définir un fichier de configuration (bannedregexpostdata) per-
mettant d’établir des expressions régulières définissant si un refus de la requête à lieu en fonction du
contenu du POST.
Après ces quelques modifications Dansguardian fonctionnera comme un parfait reverse-proxy.
Nouvelles modifications du code source (partie technique)
Puisque les données transitant par Dansguardian sont encapsulées dans une structure de données nommée
Databuffer (Databuffer.cpp), nous ajoutons une méthode dans cette classe qui nous permettra de contrôler
les données fournies par le client (POST). Celle-ci se nomme PostDataRegExOk() et retourne un boo-
lean qui indique si les données postées sont autorisées ou non. Pour ce faire, nous nous appuyons sur
l’implémentation de contentRegExp() qui, elle, contrôle le contenu du corps des réponses HTTP et rem-
place les mots trouvés.
Nous sommes ensuite obligé de modifier la classe OptionContainer (OptionContainer.cpp) qui offre les
méthodes de lecture des fichiers de configuration. Nous ajoutons donc une méthode qui nous permettra de
lire le fichier de configuration propre au filtrage des données POSTées (bannedregexpostdata). Celle-ci
se nomme readPostRegexfile(const char* filename) et sera appelée dans la même classe (dans la méthode
read(std : :string filename)). Nous nous appuyons sur la méthode readbreufile(const char* filename) qui,
elle, s’occupe de lire les expression régulières du fichier bannedregexpurllist pour l’implémentation de
notre méthode. Comme le fichier de configuration global (dansguardian.conf) contient tous les chemins
des différents fichiers de configuration pour le filtrage, nous ajoutons la lecture d’une balise dans cette
même méthode read(std : :string filename) permettant de déterminer l’emplacement du nouveau fichier
de configuration.
Il nous faut maintenant appeler la méthode de contrôle des donnés POSTées précédemment créées dans la
partie du code qui s’occupe de prendre en charge la connexion client/proxy. Il s’agit donc d’ajouter Post-
DataRegExOk() dans la méthode handleConnection(Socket peerconn) et, suivant le résultat retourné par
celle-ci, de mettre à jour la variable indiquant si la requête sera bloquée ou non (checkme.isItNaughty).
Comme l’utilisation de PostDataRegExOk() n’a aucun sens s’il n’y a pas de data POSTée, nous décidons
d’utiliser la méthode (header.isPostUpload()) fournie par la classe Header permettant de déterminer s’il
y a ou non des données à destination du serveur. Après quelques essais, nous remarquons que celle-ci ne
fonctionne pas puisqu’elle nous indique dans tous les cas qu’il n’y a pas de données POSTées. Peut-être
que son fonctionnement est dépendant de la configuration du contrôle de la taille des données POSTées
(configuration faisant partie des fonctionnalités de bases de Dansguardian). Nous décidons donc de créer
une nouvelle méthode dans la classe Header afin de savoir si des données sont transmises au serveur. Il
s’agit donc d’une méthode (bool void isPostData()) qui retournera un boolean (postDataInHeader) à true
lorsque la méthode in(Socket sock) détecte une entête POST.
Nous retirons ensuite la lecture des fichiers de configuration plus utiles dans une architecture en reverse-
proxy (comme expliqué dans le paragraphe améliorations). Il s’agit donc des fichiers bannedphraselist,
37
exceptionphraselist, bannedurllist et bannedsitelist et leurs méthodes de lecture de configuration corres-

pondante dans la classe OptionContainer :
– readbplfile, pour les fichiers bannedphraselist, exceptionphraselist
– readbsfile, pour le fichier bannedsitelist
– readbulfile, pour le fichier bannedurllist
Nous laissons les fichiers de configurations exceptionsitelist et exceptionurllist permettant de ne pas

opérer de filtrage ni de bloquage pour les sites mentionnées dans ces fichier de configurations. Ainsi
configuré, le reverse-proxy n’a aucun effet sur les sites ou URL inscrits dans ces fichiers. Le reverse-
proxy agira alors comme simple relai ou tunnel pour ces sites et URLs. Cette fonction nous permettra
d’opérer des tests de mise au point des fichiers de configurations et d’observer la différence entre le site
filtré et non filtré sans pour autant retirer le reverse-proxy de l’architecture.
Nous allons maintenant retirer les appels aux méthodes testant les requêtes et réponses en fonction des
fichiers de configurations non désirés. Celles-ci seront retirées de la classe ConnectionHandler (dans la
méthode de gestion de la connexion handleConnection(Socket peerconn)). Il s’agit donc de la méthode
checkme.checkme(&docbody) qui bloque tout réponse au client lorsque des mots contenu dans banned-
phraselist y figurent, o.banned url list(temp) qui bloque la requête si l’URL fournie figure dans banned-
sitelist et o.inBannedSiteList(temp) qui bloque la requête si le site indiqué dans la requête figure dans
bannedsitelist.
Il est important de noter que toutes les modification apportées dans les fichiers d’entêtes (*.hpp) et
d’implémentation (*.cpp) on été indiquées par un commentaire commençant par 4 étoiles (/****) il est
ainsi facile de les retrouver.
Dès lors, chaque fois que nous parlerons de DansguardianSims, nous nous référerons à l’application
Dansguardian modifiée (comme expliqué ci-dessus).
4.2.1 Installation et configuration de DansguardianSims
Installation
La configuration de la compilation de DansguardianSims se passe exactement comme dans le cadre

de Dansguardian (section 3.2.2). Il en est de même pour la compilation (make). Ensuite, lorsque vous
exécuterez le make install, il se peut que différentes erreurs surviennent puisqu’il cherchera à copier des
fichiers de configuration qui n’ont plus lieu d’être dans le cadre de l’application DansguardianSims. Afin
de passer outre, il vous suffira d’éditer le fichier Makefile que le ./configure aura créer afin de commenter
(# en début de ligne) les lignes interrompants l’installation.
Une modification du script de configuration aurait été nécessaire afin d’éviter l’intégration gênante de
38
ces lignes lors de la génération du Makefile. Comme la modification de Dansguardian n’est pas le but
premier de ce projet de diplôme, nous décidons d’en rester là afin de ne pas ”perdre” trop de temps sur
la mise en place de l’architecture.
Afin de pouvoir exécuter DansguardianSims, il faudra encore ajouter le chemin du fichier de configu-
ration du contrôle des données émises par les clients (POST). Il vous suffira donc d’ajouter la lignes
suivante à la suite des chemins d’accès pour les différents fichiers de configurations :
bannedregexpostdata = ’/chemin/fichier/conf/reglesPost’
Configuration
Dans cette section, nous allons passer en revue tous les fichiers de définition des règles utilisés dans le
cadre de DansguardianSims :
bannediplist Ce fichier permet de donner une liste d’adresses IP (une par ligne) qui seront interdites
d’accès au site web protégé par le reverse-proxy. Celui-ci renverra une page html indiquant que
l’accès est refusé.
exceptioniplist Ce fichier permet de donner une liste d’adresses IP (une par ligne) dont les requêtes et les
réponses qui en découlent ne seront jamais contrôlées (filtrées2 ou bloquées) par le reverse-proxy.
banneduserlist Lorsque l’accès à un répertoire requiert une authentification HTTP, ce fichier de confi-
guration permet de bloquer les utilisateurs dont le nom (username) est présent dans ce fichier (un
username par ligne).
exceptionuserlist Lorsque l’accès à un répertoire requiert une authentification HTTP, ce fichier de
configuration permet de ne pas contrôler (filtrer ou bloquer) les requêtes (et les réponses qui en
découlent) des utilisateurs présent dans cette liste.
exceptionsitelist Ce fichier permet de préciser des sites pour lesquels il n’y a aucun filtrage ou bloquage
à opérer (sur les requêtes ainsi que sur les réponses). Il faudra y placer un nom de domaine par
ligne en retirant l’entête ”http ://www.”.
exceptionurllist Ce fichier permet de préciser des URLs (pas un site entier, mais une sous arborescence
ou un répertoire) pour lesquels il n’y aura aucun filtrage ou bloquage (des requêtes et des réponses).
Il faudra donc y placer une URL par ligne en retirant l’entête ”http ://www.”.
bannedextensionlist Fichier définissant toutes les extensions de fichiers à bloquer (à ne pas transmettre
au client). Le contrôle s’opère sur la fin de l’URL (qui contient le nom de fichier transmis, donc son
extension) que le client demande. Il faudra placer une extension par ligne dans le format suivant :
.¡extension¿
bannedregexpurllist Ce fichier permet de définir des expressions régulières afin de contrôler l’URL que
le client transmet (requête). Si une de ces expression s’applique, la requête du client sera bloquée.
Il faudra donc entrer une expression régulière par ligne.
2
Au sens remplacement de mots dans le corps d’un document html ou text
39
bannedregexpostlist Ce fichier permet de définir des expression régulières afin de contrôler les pa-
ramètre POSTé au serveur (dans la requête du client). Il faut prendre garde au codage, puisque
l’analyse des données POSTées ce fait sans décodage préalable de celles-ci. Il faudra donc, dans
les expressions régulières, coder les caractères spéciaux en UTF8.
bannedmimetypelist Ce fichier permet de définir les types MIME (un par ligne) que DansguardianSims
bloquera. Il ne transmettra pas les réponses au client contenant un des types MIME mentionné dans
ce fichier.
messages Ce fichier permet de définir les messages qui seront affichés dans la page html retournée au
client en cas de bloquage de sa requête par DansguardianSims.
contentregexplist Ce fichier de configuration permet de définir des règles de filtrage (remplacement
de mots) des réponses émises par le serveur Web. Il est donc possible de définir des expressions
régulières afin de rechercher des mots dans un document html ou txt (retourné par le serveur)
afin de les remplacer par le ou les mots indiqués dans ce fichier. La syntaxe de configuration est
illustrée dans la section 3.2.4.
Les fichiers de configuration ”exception....” sont conservé pour une architecture en reverse-proxy pour
une question de facilité de test et non pas pour leur utilité dans l’exploitation du reverse-proxy. En ef-
fet, lors de la mise sur pied de règles de filtrage, il est très intéressant d’observer l’effet du filtrage ou
du bloquage. Il sera ainsi très facile de changer la configuration afin d’observer des requêtes sans fil-
trage/bloquage plutôt que ”d’attaquer” directement le serveur Web.
4.3 Installation des NIDS
Pour la compilation, l’installation et la configuration de Prelude-nids, nous nous sommes reporté au tra-
vail de diplôme de Patrick Saladino annexe C.4.3 page 93 et C5 page 96. Nous avons ensuite suivi la
procédure d’enregistrement de la sonde sur le manager comme décrit dans cette annexe. La configura-
tions de celles-ci (indication de l’IP du manager et choix des règles à utiliser) est disponnible dans les
annexes (chapitre A, section A.2.3 page 100 pour le NIDS pre-reverse-proxy et section A.3 page 104
pour le NIDS post-reverse-proxy ).
4.4 Mise en place du reverse-proxy
4.4.1 Installation de l’HIDS sur le reverse-proxy
Pour la compilation, l’installation et la configuration de Prelude-lml, nous nous sommes reporté au travail
de diplôme de Patrick Saladino annexe C.4.4 page 95 et C5 96. Nous avons ensuite suivi la procédure
d’enregistrement de la sonde sur le manager comme décrit dans cette annexe. Vous pourrez consulter les
fichiers de configurations correspondant dans les Annexes (chapitre A, section A.2 page 94).
40
4.4.2 Création d’une blacklist
Pour ce faire, nous scannons à l’aide de Nessus3 le serveur Web (sans passer par le reverse-proxy) afin
d’en ddéterminerses vulnérabilités. A l’aide du rapport de sécurité établi par Nessus, il nous est possible
de connaı̂tre le CVE4 des différentes attaques réussies et d’en rechercher le pattern dans les codes NASL5
des attaques fournies par Nessus. Pour ce faire, nous téléchargeons (sur : http ://www.nessus.org/scripts.php)
les codes NASL des attaques Nessus que nous décompressons dans un répertoire. Maintenant nous nous
servons de la commande Linux grep afin de retrouver le script correspondant au CVE que nous connais-
sons. Si par exemple nous recherchons le CAN-2003-0822, nous nous plaçons dans le répertoire conte-
nant la liste des scripts et nous entrons :
jwintere@debian:˜/EIVD/ProjetDiplome/reglesNessus$ grep CAN-2003-0822 *.nasl

frontpage_chunked_overflow.nasl: script_cve_id("CAN-2003-0822", "CAN-2003-0824");
Nous remarquons que le CAN-2003-0822 que nous fournissait le rapport de vulnérabilité correspond au
fichier rontpage chunked overflow.nasl.
Il nous est ainsi possible à l’aide du code, d’observer les data émises, vers la machine cible, qui ca-
ractérisent l’attaque afin d’en établir la règle qui la bloquera.
De plus, nous isolons l’attaque dont nous voulons créer la règle correspondante (à l’aide de la sélection
de scripts sous Nessus) et nous analysons les paquets émis à l’aide d’Ethereal. Il nous est ainsi possible
d’observer la construction exacte et les caractéristiques de la trame ou des trames constituant l’attaque.
Les règles permettant de bloquer les attaques sont définies dans les fichiers de configuration (étudié dans
la section 4.2.1) de DansguardianSims à l’aide d’expression régulières.
Une fois la black liste établie sur le reverse-proxy (section 4.4.2), nous lançons quelques attaques afin
d’en observer les logs correspondant sur DansguardianSims. Il nous sera ainsi possible d’observer la
construction de ses logs afin d’établir les règles de récupération de ceux-ci sur le HIDS (section 4.4.3).
Blacklist pour DansguardianSims
A l’aide de la méthodologie décrite précédemment nous établissons les différentes règles permettant de
bloquer plusieurs vulnérabilités découvertes à l’aide de Nessus. Il nous est alors possible de définir le
fichier de configuration bannedregexpurllist permettant de bloquer l’accès au serveur Web lorsqu’un des
pattern contenu dans ce fichier est trouvé dans l’URL.
#Empêcher le SQL injection sur des paramètre émis via GET

.*?.*=.*’.*OR.*=.*
.*?.*=.*’.*UNION.*SELECT.*FROM.*
#CVE: CAN-2003-0822 Buffer overflow sur la DLL fp30reg.dll

.*/_vti_bin/_vti_aut/fp30reg.dll
3
Scanner de vulnérabilités Open Source
4
Common Vulnerabilites and Exposures
5
Nessus Attack Scripting Language, langage de script permettant de coder des attaques qui permettrons d’établir si une
machine est vulnérable
41
#CVE: CAN-2000-0884 exécution de commande à distance à l’aide d’une représentation unicode

#du slash permettant la remontée à cmd.exe (les points doivent etres échapés
#dans les expressions régulières)
.*/msadc/\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\./
#CVE: CVE-2001-0333 exécution de commande à distance à l’aide d’une représentation unicode

#du slash permettant la remontée à cmd.exe (les points doivent etres échapés
#dans les expressions régulières)
.*/msadc/\.\.%255c\.\.%255c\.\.%255c\.\.%255c\.\.%255c\.\./
#CVE: CAN-1999-0739 visualisation des codes sources via un script ASP de démo
.*/iissamples/sdk/asp/docs/codebrws?
#CVE: CAN-1999-1011 Possibilité de bufferoverflow sur une DLL accessible via IIS
.*/msadc/msadcs\.dll
#CVE: CAN-2002-0071 bufferoverflow via un fichier .htr

.*\.htr
Le fichier contentregexplist permettant de remplacer des mots dans les pages HTML et TXT retournées
par le serveur Web, nous servira pour le moment uniquement à la protection des clients contre le cross
site scripting. Nous remplaçons tous les scripts permettant l’affichage d’un cookie par un commentaire,
à l’aide de la syntaxe de configuration ci-dessous :
"document.cookie"->""
Le fichier bannedregexpostdata permettant de bloquer l’accès au serveur à des requêtes comportant des
données POSTées dangereuses sera pour le moment uniquement utilisé pour un bloquage des tentatives
de SQL injection sur des paramètres émis via la méthode HTTP POST. Étant donné que les paramètres
émis via un post sont codés en x-www-form-urlencoded et qu’aucune conversion n’est effectuée avant
le filtrage, nous avons été obligé d’écrire les différentes règles en transformant les caractères spéciaux en
leur représentation x-www-form-urlencoded :
#empêcher le SQL injection (%27 représente ’ et %32 représente =)

%27.*OR.*%3d
.*union.*select.*from
4.4.3 Pattern matching de Prelude-lml pour DansguardianSims
Après avoir établi les différentes règles de bloquage et de filtrage de DansguardianSims, nous avons ef-
fectué les attaques susceptibles d’être bloqués par DansguardianSims. Il nous a ensuite suffit d’observer
le fichier de log de dansguardianSims (/var/log/dansguardian/access.log) afin de déterminer la construc-
tion des logs et les différentes informations fournies par ceux-ci. Ces observations nous ont ensuite
permi la création des règles de récupération des logs par l’intermédiaire des alarmes IDMEF qu’offre
prelude-lml. Nous avons donc créé un fichier de règle pour le HIDS du reverse-proxy (/etc/prelude-
lml/rulset/dansguardian.rules) que nous avons placé avec les règles déjà disponible dans prelude-lml.
Nous avons ensuite activé son utilisation dans le fichier de configuration des règles de l’HIDS (/etc/prelude-
lml/rulset/simple.rules) et nous avons précisé quel était le nouveau fichier de log à analyser (à l’aide du
42
fichier de configuration /etc/prelude-lml/prelude-lml.conf) .Tous ces fichiers de configurations sont di-

ponibles en annexes (section A.2, page 94)
4.5 Mise en place de la sonde HIDS de IIS
Étant donné qu’aucunes sondes Prelude n’est ddiponiblessur Windows, nous sommes dans l’obligation
de récupérer les logs produit par IIS6 et de les envoyer à un serveur syslog (Linux) distant. Pour ce faire,
nous utiliserons l’outils open source ”SnareIIS” développé par InterSect Alliance7 . Nous utiliserons la
machine officiant en reverse-proxy pour la récupération des ces logs puisqu’une sonde Prelude-lml y
est déjà disponible. Sur celle-ci, il suffira de créer de nouvelles règles (pattern matching des logs) afin
que les alarmes voulues soient rapatriées vers le Manager (Prelude Manager). La figure 4.4 illustre ce
principe de fonctionnement.
F IG . 4.4 – Principe de rapatriement des logs d’IIS vers la sonde HIDS du reverse-proxy
4.5.1 Configuration du client Windows Snare et d’IIS
La figure 4.5 illustre la configuration du client Snare effectuée, afin que la station 192.168.1.2 (reverse-
proxy) reçoive les logs contenu dans le fichier C :\WINNT\System32\LogFiles du serveur IIS.
L’utilisation de Snare implique une configuration rigoureuse du format des logs d’IIS. En effet, il est
indispensable de configurer une rotation des logs journalière ainsi qu’un format étendu (W3C extended
6
Internet Information Services, Serveur Web de Microsoft
7
disponible sur : http ://intersectalliance.com/projects/SnareIIS/index.html
43
F IG . 4.5 – Configuration de l’utilitaire de récupération des logs d’IIS
Log File Format) afin que Snare soit capable de les lire. Cette configuration est accessible dans le menu
de configuration de IIS, dans l’onglet Web Site. En cliquant sur le bouton Properties..., il sera possible
de définir la période de rotation des logs ainsi que leur format.
4.5.2 Configuration du serveur syslog Linux
Syslogd est le daemon s’occupant de la récupération de log d’une machine Linux. Par défaut celui-ci
travaille uniquement en local. Lors de son lancement (commande syslogd), via l’argument ”-r”, il est
possible de lui indiquer d’ouvrir le port 514 UDP pour la récupération de logs distants. Nous modifions
donc son script de lancement ”sysklogd” placé dans /etc/ini.d/. Il suffira donc d’ajouter le ”-r” dans la
variable SYSLOGD déjà présente dans ce fichier, comme illustré ci-dessous :
# Options for start/restart the daemons

# For remote UDP logging use SYSLOGD="-r"
SYSLOGD="-r"
Nous pouvons ensuite relancer le daemon qui attendra maintenant des messages syslog sur le port 514 :
jo:/etc/init.d# ./sysklogd restart
Il est important de préciser que le protocole de transfert de logs basé sur UDP n’est pas sécurisé. Les
trames circulent ”en clair” sur le réseau. De plus l’utilisation d’UDP implique une éventuelle possibilité
de perte des paquets sans qu’aucun des deux partenaires ne s’en rende compte (principe même d’UDP).
44
4.5.3 Pattern matching de Prelude-lml pour les logs de IIS
Les logs de IIS se trouvent maintenant dans le fichier /var/log/syslog du reverse-proxy. Nous obser-
vons leur structure afin d’établir l’expression régulière qui permettra de relever (donc d’envoyer des
alarmes IDMEF à Prelude Manager) les logs d’accès d’IIS qui ont un code de status indiquant une er-
reur de la requête HTTP effectuée par le client (4xx). En effet, il sera iintéressantlors de la phase de
corrélation, de connaı̂tre les requêtes n’ayant pas abouti. Nous créons un fichier de règles (/etc/prelude-
lml/rulset/iis.rules) dans lequel nous définissons le pattern à rechercher et le message IDMEF à retourner
au Manager. Ce fichier est disponibles dans les annexes(chapitre A, section A.2.2 page 99)
4.6 Mise en place d’un firewall Iptables
Le firewall/NAT présenté dans l’architecture globale a une fonction de routage, puisqu’il comprend deux
interfaces réseaux (la première ayant une adresse IP publique8 et la seconde ayant une adresse IP privée,
du réseau 192.168.1.0/24). Il permet ainsi la communication entre la DMZ contenant nos serveurs et le
monde extérieur.
Pour ce faire, nous avons utilisé une machine Linux à deux interfaces réseaux dédiée à la fonction de
firewall. Nous avons activé Iptables, logiciel directement intégré au Kernel Linux, permettant de filtrer et
modifier les paquets arrivant et partant des cartes réseau de la machine en question. Pour son activation,
il suffit, dans le répertoire des sources de votre kernel, d’éditer le menu de configuration de celui-ci, à
l’aide de la commande suivante :
eduPc002:/usr/src/linux-2.4.27# make menuconfig
Puis, dans l’interface ”graphique” qui vous sera proposée, vous devrez naviguer dans le menu Networ-
king Option et activer le module Network packet filtering. Vous pourrez ensuite configurer Iptables dans
le sous-menu Netfilter configuration. Vous devrez alors activer tous les modules nécessaires au NAT,
MASQUERADING, ainsi qu’au filtrage. Pour notre part, nous avons activé les modules suivants :
– Connection tracking (required for masq/NAT)
– IP tables support (required for filtering/masq/NAT)
– Packet type match support
– netfilter MARK match support
– Multiple port match support
– Connection state match support
– Connection tracking match support
– Packet filtering
– REJECT target support
8
Publique au sens du réseau TCOM, donc en 10.192.72.0/23
45
– Full NAT
– MASQUERADE target support
– REDIRECT target support
– LOG target support
– ULOG target support
Les deux derniers modules nous permettrons de logger via syslogd9 des paquets selon les critères que
nous définirons.
Maintenant que la configuration d’Iptables dans le kernel est terminée, vous devez le compiler et l’ins-
taller.
La configuration d’un NAT10 statique11 est indispensable afin que le reverse-proxy soit atteignable de-
puis l’extérieur (réseau TCOM). A l’aide de cette configuration, nous pouvons définir que toutes les
adresses IP de destination des paquets arrivant sur l’interface publique du firewall, avec comme adresse
IP de destination 10.192.72.83 (l’adresse publique du firewall) et comme port de destination 80, se fe-
ront substituer par l’adresse IP du proxy (192.168.1.2) avant le routage. Ces paquets seront relayés vers
le reverse-proxy par le firewall. Iptables applique implicitement la règle inverse sur tous paquets ayant
l’adresse IP du proxy comme adresse source et le port source 80. Il substituera donc l’adresse IP source
d’un paquet ayant ces caractéristiques par sa propre adresse IP publique. De cette façon, tous les clients
Web extérieurs penserons directement atteindre le serveur Web via l’adresse IP 10.192.72.83.
Nous devons ensuite configurer les règles permettant de bloquer le trafic indésirable. Lors de l’utilisa-
tion du filtrage avec une fonction de NAT activée, il suffira, pour l’établissement des règles de filtrage
d’ignorer les changements d’adresses opéré par le NAT. Lors de la mise en place d’un firewall/NAT il
est donc préférable de mettre au point la fonction de translation d’adresses (NAT) avant la fonction de
filtrage afin de ne pas mélanger les problèmes lors des tests.
Les règles de filtrages sont à l’instar des règles de translation d’adresses unidirectionnelles. Il faudra à
chaque fois créer une règle pour le flux entrant et le flux sortant. Voici un extrait du script d’établissement
des règles de filtrage que nous avons établi pour l’accès au serveur Web :
#############################################################
#NAT statique pour l’accès au reverse-proxy depuis l’extérieur
#############################################################
iptables -t nat -A PREROUTING -p tcp --dport 80 -d 10.192.72.83
-i eth0 -j DNAT --to-dest 192.168.1.2
###########################################################
#Authorise le trafic Web avec le reverse-proxy 192.168.1.2
###########################################################
iptables -A FORWARD -i eth0 -p tcp -d 192.168.1.2 --dport 80 -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp -s 192.168.1.2 --sport 80 -j ACCEPT
9
daemon de récupération des logs Linux
10
Network Address Translation
11
Changement d’adresses avant le routage opéré par le stack IP de la machine (PREROUTING)
46
######################################################################
#Autorisation des requêtes DNS pour tout le réseau (Squid en a besoin)
######################################################################
iptables -A FORWARD -i eth1 -p udp -s 192.168.1.0/24 --dport 53 -j ACCEPT
iptables -A FORWARD -i eth0 -p udp -d 192.168.1.0/24 --sport 53 -j ACCEPT
De plus, il est préférable d’établir les polices par défaut des différentes chaı̂nes12 à l’état ACCEPT
et d’établir une règle finale (la dernière du script) qui refusera tous les paquets. Étant donné que les
paquets traversent les différentes chaı̂nes de filtrage dans l’ordre de déclaration des règles, la règle finale
interviendra uniquement sur les paquets auxquels aucune règle ACCPET ne s’applique. Cette méthode
de travail permettra une réinitialisation aisée lors des tests. En effet l’utilisation de la commande iptables
-F a pour effet d’effacer toutes les règles de filtrage des différentes chaı̂nes sans pour autant effacer
les polices par défaut. Lors de son utilisation, et d’une police par défaut au refus de toute connexions
(DROP), le firewall ne sera malheureusement plus atteignable et bloquera absolument tout. Une police
par défaut à ACCEPT permettra par exemple, lors de la réinitialisation du firewall (iptables -F) effectué
par un shell SSH13 de garder la connexion active après son exécution.
############################################
#Polices par défaut des différentes chaı̂nes
############################################
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
.... règles de filtrages ....
##########################
#règles de refus finales
##########################
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
4.6.1 Récupération des logs du firewall
Pour ce faire, nous créons une nouvelle chaı̂ne de filtrage utilisateur que nous nommons LOG DROP.
Cette nouvelle chaı̂ne aura pour effet de ”jeter” le paquet et de le logger. Nous ajoutons la règle LOG et
DROP à cette nouvelle chaı̂ne (comme illustré ci-dessous) :
#création de la chaı̂ne
iptables -N LOG_DROP
#ajout des règles

iptables -A LOG_DROP -j LOG --log-prefix "Drop "
iptables -A LOG_DROP -j DROP
12
Une chaı̂ne représente un groupe de règles pour une fonctionnalité. Les différentes chaı̂nes présentent de base sont : INPUT
(paquet entrant), OUTPUT (paquet sortant), FORWARD (paquet devant être routé)
13
Shell distant reposant sur une connexion TCP cryptée (port 22)
47
L’ajout du préfixe ”Drop ” aux logs ainsi crées est indispensable au bon fonctionnement de Prelude-
LML (sonde HIDS de Prelude), puisque la recherche de pattern préétabli pour Netfilter (/etc/prelude-
lml/rulset/netfilter.rules) recherche un tel préfixe afin de déterminer si le logs doit être apatrié au Manager
Prelude.
La totalité du script de configuration du firewall est disponible dans les annexes (chapitre A, section A.4
page 109).
4.6.2 Gestion des logs syslog
Étant donné qu’un grand nombre de paquets sont refusé par le firewall (le seul port ouvert étant le port
80), les fichiers de logs ont la fâcheuse tendance à prendre rapidement un grand espace disque. Nous uti-
lisons l’utilitaire logrotate de Linux afin de limiter la taille de ces fichiers de logs. Par défaut cet utilitaire
est exécuté journalièrement par CRON14 afin de contrôler si les critères de rotation des logs sont atteints.
Le fichier de configuration crontab définit plusieurs répertoires ccomportantles scripts étant exécutés :
chaque heure pour le répertoire cron.hourly, chaque jour pour le répertoire cron.daily, chaque semaine
pour le répertoire cron.weekly ou chaque mois pour le répertoire cron.monthly. Logrotate figure donc
dans le répertoire /etc/cron.daily.
Lorsque CRON exécutera cet utilitaire, il contrôlera suivant les critères défini dans /etc/logrotate quels
sont les fichier de logs à ”roter”. Suivant la configuration, cette rotation aura pour effet de compres-
ser le fichier de log et de le stocker dans le répertoire voulu. Lorsque le nombre maximum d’archives de
fichiers de logs compressé sera atteint, logrotate remplacera les plus anciennes archives par les nouvelles.
La configuration ci-dessous illustre la partie du fichier /etc/logrotate, concernant la rotation des syslog :
#Global configuration
compress
# System logs (firewall)

/var/log/syslog {
rotate 3
size=4M
olddir /var/log/oldLog
postrotate
killall syslogd -HUP
endscript
}
compress Indique que les archives seront compressées (*.tar.gz).

rotate 3 Indique que 3 archives compressées seront gardée (les anciennes étant remplacées par les nou-
velles).
size=4M Indique que lorsque la taille du fichier /var/log/syslog atteindra 4M, celui-ci sera ”roté”.
14
daemon exécutant des commandes suivant un calendrié pré-programmé (/etc/crontab)
48
olddir Permet de préciser dans quel répertoire seront placé les archives compressées.
postrotate - endscript Englobe une commande qui sera directement exécutée après la rotation des logs.
Dans notre cas, killall syslogd -HUP relance le daemon syslog en lui demandant de relire sa confi-
guration (/etc/syslog.conf) et de recréer les fichiers de logs supprimés.
Lors de l’utilisation de la directive size, et suivant la vitesse de d’accroı̂ssement des logs, il sera nécessaire
de déplacer le script de rotation des logs se trouvant dans /etc/cron.daily/ vers le répertoire /etc/cron.hourly/.
En effet, il se peut que la taille limite définie dans le fichier de configration ci-dessus soit rapidement at-
teinte en un jour. Un contrôle horraire peut donc s’avérer indispensable.
49
Chapitre 5
Corrélation
Ce chapitre commencera par poser les bases de la corrélation, son utilisation et pour finir son application
au banc d’essai du projet. Différents scénarii d’attaques seront envisagés afin d’illustrer au mieux les
mesures introduites par la corrélation.
5.1 Définition et principe
La corrélation est définie comme une relation entre deux ou plusieurs variables.
Imaginons maintenant que ces variables soient les alarmes de différents IDS répartis sur un réseau. Un
mécanisme de corrélation1 capable de trouver une relation entre plusieurs alarmes de différents IDS nous
permettra ensuite de déduire plus facilement la dangerosité d’une alarme puisque celle-ci ne se trouvera
plus noyée dans un flot d’alarmes mais associée à un contexte ou à une action bien précise.
Le lieutenant Colombo2 est donc un exemple ”concret” de moteur de corrélation puisqu’il sera toujours
capable de reconstruire le puzzle d’un crime. Après l’interrogation des suspects et de longues investiga-
tions dans les alentours du lieu du crime, il est capable de dresser un bilan et d’en déduire le coupable.
Il s’agit donc d’un comportement totalement analogue à un moteur de corrélation pour des alarmes de
détecteurs d’intrusions. En effet, les alarmes d’une source (IDS) bien précise pourraient être définies
comme le crime potentiel, alors que les alarmes des autres sources (IDS) comme les suspects. Notre mo-
teur de corrélation se chargera donc de les analyser (équivalent à l’interrogation d’un suspect) et fournira
un bilan sur chaque alarme.
1
Mécanisme mis en place par un moteur de corrélation (software s’occupant de la corrélation)
2
Lieutenant bien connu d’une série américaine du même nom (crée en 1968 )
50
5.2 Application
L’architecture réseau à disposition (figure 4.3 page 35) et les nombreuses sondes disposées dans celle-
ci nous permettrons de défnir plusieurs stratégies d’investigations. En effet, l’événement déclencheur
(appelé crime potentiel dans la section 5.1) de l’investigation pourrait provenir de différentes sources
d’alarmes (IDS). Nous sommes donc dans l’obligation de définir plusieurs scénarii d’investigation (un
pour chaque déclencheur).
A ce stade de la corrélation, il est important de faire la distinction entre les scénarii d’investigation et ceux
d’attaques. En effet, le projet de diplôme SIMS 2003 de Patrick Saladino était orienté sur la création de
scénarii caractéristiques d’une attaque. Ces scénarii étaient recherchés dans le flot des alarmes d’un IDS
par le moteur de corrélation mis au point dans le cadre de ce projet. Il s’agissait donc d’une recherche de
suite d’alarmes dans une fenêtre temporelle prédéfinie. Étant donné que les alarmes ne provenaient que
d’une seule source, une stratégie d’investigation était impossible. Grâce à l’architecture déployée dans
la première partie de ce projet, nous sommes capable de définir des scénarii d’investigation à l’aide des
différentes alarmes émises par les sondes NIDS et HIDS puis récoltées par Prelude-Manager3 .
Le principal avantage des scénarii d’investigations sur ceux d’attaques vient du fait qu’il sont génériques
et très souvent indépendants du type d’attaques, puisqu’ils ne dépendent plus de l’attaque mais de l’ar-
chitecture mise en place (des différentes sondes et de leurs positions dans le réseau).
5.2.1 Mais qu’apportera concrètement la corrélation ?
L’image entre l’insepecteur Colombo et notre moteur de corrélation est bonne jusqu’à un certain point
seulement. En effet, l’inspecteur Colombo n’enquêtera jamais pour un crime inexistant, alors que dans
notre cas, chaque événement (alarme) déclencheur d’un scénarii de corrélation doit être considéré comme
un ”crime potentiel”, puisqu’il est impossible en analysant uniquement cet événement de savoir s’il
s’agit d’une alarme dangeureuse pour notre architecture ou d’une alarme levée pour aucun4 événement
dangereux dans notre cas. Ce problème provient uniquement du mode de fonctionnement en blacklist
des sondes réseaux (NIDS) et des sondes analysant les logs (HIDS). En effet, dès qu’un pattern sera
détecté par l’une ou l’autre de ces sondes, une alarme sera levée même si l’élément à protéger n’est pas
vulnérable à ce genre d’attaques (Script vulnérable non présent sur le serveur).
Il sera donc très intéressant d’éliminer une grande partie des faux positifs à l’aide d’une étape de filtrage
dans chaques scénarii de corrélation.
De plus, lors d’une corrélation d’alarmes d’IDS, nous sommes en présence d’une multitude d’attaques
quasi simultanées. Il devient donc très difficile d’identifier les alarmes appartenant à la même attaque. Il
est alors nécessaire de regrouper les alarmes suivant des critères5 prédéterminés afin de pouvoir identifier
plus facilement les alarmes provenant de la même attaque.
Il sera intéressant de mettre en place différents scénarii de corrélation permettant d’améliorer le sta-
3
Manager des sondes (comportement décrit dans la section 2.2.1 page 14)
4
Faux positif
5
Critères regroupé sous la forme de contextes (défini dans la section 5.4)
51
tus de dangerosité d’une alarme en l’associant avec différentes alarmes générées par la même tentative
d’attaque. La figure 5.1 représente donc le processus de corrélation élaboré. La phase de mise en place
de contextes établi concrètement le regroupement des alarmes suivant des critères prédéfinis, comme
expliqué ci-dessus.
F IG . 5.1 – Principe de corrélation
Par la suite, il serait intéressant de pouvoir retracer l’activité totale d’un client sur notre architecture
réseau. L’analyste réseau pourrait ainsi, après consultations des alarmes très critiques, suivre l’activité
des adresses IP ayant déclenché ces alarmes.
5.2.2 Événements déclencheurs
Jusqu’à présent nous avons beaucoup parlé d’événements déclencheurs de scénarii d’investigation, mais
à quoi servent-ils et où se situent-ils exactement dans l’architecture réseau ?
Un événement déclencheur est le point de départ du diagramme d’état représentant le scénario d’investi-
gation. Sans cet élément de base (groupe d’alarme ou alarme spécifique), il sera impossible de démarrer
le processus de corrélation du scénario défini. Cet événement est donc la source d’informations de départ
de la corrélation.
Lors de l’établissement d’un scénario d’investigation, deux stratégies pour la détermination de l’événement
déclencheur sont applicables. En effet, il est possible de définir l’action avant-coureuse d’une attaque
comme déclencheur ou alors, la détection de l’attaque elle-même. L’utilisation d’une action avant-
coureuse entrera plutôt dans une stratégie de prévention6 , alors qu’une corrélation déclenchée par l’at-
taque elle même permettra plutôt une analyse de la cause et apporte une façon d’y remédier rapidement.
Géographiquement, ces deux types d’événements déclencheurs se situent à l’opposé de l’architecture
6
Recherche des actions effectuées par un client déterminé comme potentiellement dangereux
52
réseau. Un événement avant-coureur sera généralement défini comme un scan de ports sur le firewall
ou un trop grand nombre de requêtes bloquées par le reverse-proxy, alors que l’attaque elle-même sera
détectée par la sonde post-reverse-proxy ou le HIDS du serveur Web. Les événements avant-coureurs
se situent donc proches du réseau publique (proche du firewall), alors que les informations d’attaque
proviendront des sources les plus proches possibles du serveur Web (élément à protéger).
Il serait donc très intéressant de mettre sur pied ces deux principes puisqu’ils ne paraissent pas concur-
rents mais complémentaires. Malheureusement, dans le cadre de ce travail de diplôme, il ne sera pas
possible d’établir plusieurs scénarii de corrélation pour une question de temps à disposition. Pour com-
mencer, nous choisirons une approche permettant de réduire au maximum les faux positifs. Nous utilise-
rons donc un déclencheur proche du serveur Web afin d’analyser les attaques détectées et d’en déterminer
la gravité (faux positifs ou non et niveau de gravité).
5.3 Corrélation temps réel VS corrélation à postériori
Une méthode de travail en temps réel permettrait un monitoring permanent et une remontée en temps
réel des alarmes critiques vers le gestionnaire de réseau (personne physique). Ceci aurait pour effet
d’améliorer le temps de réaction entre une attaque et la mise en place des dispositions pour la prévenir.
Malheureusement le modèle 3-tiers employé par Piwi7 auquel nous désirons ajouter notre moteur de
corrélation ne permet pas un fonctionnement en temps réel. La figure 5.2 illustre cette architecture.
F IG . 5.2 – Architecture 3-tiers du frontend Prelude (Piwi)
En effet, il est impossible d’exécuter continuellement du code serveur8 puisque son exécution doit obli-
gatoirement se terminer pour permettre l’envoi des informations demandées par le client Web. De plus,
le fonctionnement client-serveur d’un serveur Web implique qu’une requête doit être émise par un client
(gestionnaire réseau dans notre cas) pour qu’une réponse puisse être reçue. Il faudrait donc qu’un script
client invoque continuellement le programme serveur de corrélation. Cette méthode de travail (utilisée
7
Frontend de Prelude permettant l’interrogation de la base de donnée stockant les alarmes
8
Programme situé sur le serveur Web
53
par M. Saladino dans le cadre de SIMS 2003) serait envisageable mais poserait quelques problèmes au
niveau du temps d’exécution du programme serveur. En effet, celui-ci devrait continuellement recons-
truire toutes les associations entre les différentes alarmes (interrogation du SGBD de Prelude, parcours
de toutes les alarmes, tri, mise en place dans des structures de données et corrélation) ce qui s’avère
extrêmement long pour un grand nombre d’alarmes. Nous serions donc dans l’obligation de stocker
les structures de données et les résultats de chaque corrélation dans une nouvelle base de données ou
dans une structure de fichiers afin de ne pas relancer, à chaque invocation du programme serveur, une
corrélation sur la totalité des alarmes contenues dans le SGBD de Prelude.
La solution idéale (illustrée par la figure 5.3), pour une corrélation en temps réel, serait de développer
un daemon9 qui s’occuperait de la récupération des alarmes du SGBD de Prelude et qui stockerait les
résultats intermédiaires (structure de données, etc..) dans une structure de fichiers ou une base de données
intermédiaire afin d’uniquement récupérer les dernières alarmes auprès du SGBD et non pas l’historique
complet. Il faudrait ensuite définir un protocole d’interrogation de ce deamon qui permettrait à un pro-
gramme serveur de l’interroger et d’afficher sous forme de page Web les informations désirées par le
gestionnaire de réseau. De cette manière, l’affichage des informations serait totalement indépendant de
l’exécution du moteur de corrélation et l’exécution d’un daemon permettrait, en plus, l’envoi spontané
d’alarmes critiques au gestionnaire du réseau.
F IG . 5.3 – Architecture 3-tiers, fonctionnement en temps réel
Pour des contraintes de planning, ne nous pourrons pas, dans le cadre de ce projet de diplôme, développer
un moteur de corrélation sous la forme d’un daemon. Nous allons donc ajouter un module au frontend
existant (Piwi, figure 5.2). Le moteur de corrélation s’exécutera pour une fenêtre temporelle d’alarmes et
ne pourra en aucun cas interagir spontanément avec le gestionnaire de réseau (envoi d’alarmes critiques
via e-mail, popup, etc..). Il faudra donc, à chaque lancement du moteur de corrélation, préciser le nombre
de jours ou d’heures passées qu’il faudra analyser.
Afin d’améliorer la réactivité de notre application (sans pour autant prétendre atteindre celle d’un système
temps réel), nous développerons un petit daemon qui contrôlera en permanence (toutes les 10 minutes
par défaut) le fonctionnement du ou des serveurs Web. Il permettra ainsi d’avertir l’administrateur réseau
9
Programme s’exécutant en permanence
54
(via e-mail) lorsqu’un des serveurs sera hors service. Les détails de cette implémentation sont disponibles
dans le chapitre 6 section 6.1.
5.4 Mise en place des contextes
Comme illustré sur la figure 5.1, l’étape de création de contextes est indispensable pour une bonne
corrélation. Cette étape a comme objectif de regrouper les alarmes par caractéristiques ou critères com-
muns. En effet, il est particulièrement difficile d’opérer une corrélation lorsqu’ aucun tri préalable des
alarmes n’a été effectué.
Ces contextes permettrons d’envisager des scénarii d’investigations en fonction de leurs caractéristiques.
Un contexte regroupant les alertes ayant la même adresse IP source permettra, par exemple, d’identifier
un hacker alors qu’un contexte regroupant les alarmes de même type permettra de trouver quelles sont
les types d’attaques effectuées et les pages Web attaquées (donc potentiellement vulnérables).
Nous remarquons donc que les contextes sont complémentaires et qu’ils permettent une vue plus globale
des attaques effectuées.
A l’aide de l’architecture réseau et des différentes sondes mises en place dans le chapitre précédent, nous
sommes capables de définir les contextes suivants :
– Source commune
– URL de destination commune
– URL de destination commune et source commune
– Session TCP commune (post-reverse-proxy ou pre-reverse-proxy)
– Source commune et même classe d’alarme
– URL de destination commune et même classe d’alarme
De par l’architecture réseau définie (dans le chapitre 4), la plupart de ces contextes ne sont pas direc-
tement extractables du SGBD de Prelude (par une simple requête SQL). En effet, les champs retirés
du SGBD devront subir un traitement (recherche de pattern) préalable pour qu’une décision d’associa-
tion à un contexte soit possible. De plus, l’utilisation du reverse proxy implique une corrélation entre
les alarmes post-reverse-proxy et pre-reverse-proxy afin de retrouver l’adresse IP source de l’attaquant.
L’utilisation d’un reverse-proxy a pour effet de couper la connexion TCP et d’éliminer l’accès directe du
client Web au serveur. Le NIDS post-reverse-proxy ainsi que les logs du serveur Web indiquerons donc
toujours l’adresse IP du reverse-proxy comme source de l’attaque ou de la requête refusée.
L’idée est de s’appuyer sur le type de l’alarme générée afin d’effectuer une recherche de type dans une
fenêtre temporelle réduite pour les alarmes pre-reverse-proxy et post-reverse-proxy (NIDS uniquement).
En effet, les alarmes pre-reverse-proxy contiendront l’adresse réelle du client ayant tenté l’attaque. Il
nous sera donc possible de rechercher les alarmes communes aux sondes pre et post-reverse-proxy afin
de retrouver l’adresse IP source d’une alarme post-reverse-proxy. Il est important de noter que, pour
qu’une telle stratégie soit applicable, il est nécessaire que les deux sondes NIDS possèdent exactement
55
les mêmes règles afin que les mêmes alarmes soient identifiables. En effet, si la sonde post-reverse-
proxy lève une alarme, il est nécessaire que la même alarme ait été précédemment levée par la sonde
pre-reverse-proxy afin que l’adresse IP source (celle de l’attaquant) soit connue. Il est donc indispen-
sable de synchroniser temporellement les différentes sondes afin que la fenêtre temporelle de recherche
puisse être appliquée. Nous décidons alors d’intégrer un client NTP10 sur les machines de notre DMZ,
afin de permettre l’obtention d’une horloge système synchronisée. La section 5.6 vous expliquera en
détail l’installation du client NTP sur les systèmes d’exploitations utilisés (Windows Server et Linux
Debian). La méthode décrite ci-dessus implique malheureusement que plusieurs mêmes types d’alarmes
peuvent correspondre à la recherche effectuée. Dans certains cas, il ne sera donc pas possible d’obtenir
une seule adresse IP source puisque, lors d’un grand nombre de mêmes attaques provenant de différentes
sources durant un court intervalle de temps, la recherche effectuée fournira plusieurs adresses sources
possibles.
Une approche basée sur la comparaison des payloads11 des sondes post et pre-reverse-proxy a dû être
écartée. En effet, Prelude-IDS n’archive qu’une courte partie de ceux-ci (le début) qui se compose bien
souvent de l’entête HTTP qui sera modifiée par le reverse-proxy. Il devient alors impossible de retrouver
la même alarme par la comparaison des payloads.
5.4.1 Contextes de sessions TCP communes
Ce contexte de regroupement des alarmes en fonction des sessions TCP nous permettra une corrélation
subtile du genre attaque-réponse. En effet, les attaques menées par des crackers mènent souvent à une
réponse immédiate puisque le protocole HTTP fonctionne comme tel (chaque requête implique une
réponse). Il est alors très intéressant de relever les alarmes appartenant à la même paire requête-réponse
afin de permettre un diagnostique rapide de la réussite de l’attaque (faux positif ou non).
Comme toutes méthodes de travail, celle-ci comporte ses limites puisque, par exemple, dans le cas
d’un buffer overflow, nous aurons à faire à deux connexions TCP pour la même attaque. Effectivement,
l’alarme levée par la détection d’un shell code contenu dans une attaque de type buffer overflow ainsi
que celle levée par la détection des commandes exécutées par le cracker ayant lancé ce buffer overflow
se composent de deux connexions TCP. Le buffer overflow contenant le shell code ouvrant un serveur
Telnet sur sa cible constituera une session TCP, alors que la connexion du cracker sur le port de ce ser-
veur Telnet indésirable constituera une seconde session.
Il sera donc impossible, à l’aide de ce contexte, de reconstituer directement ce genre d’attaque parmi le
flot des alarmes levées.
Par la topologie mise en place, nous sommes capables de définir deux contextes de session TCP :
1. Les sessions post-reverse-proxy
2. Les sessions pre-reverse-proxy
L’obligation de définir deux contextes de session provient uniquement de l’utilisation d’un reverse-proxy
10
Network Time Protocol
11
Contenu utile des segments TCP
56
qui, comme précisé ci-dessus, a pour effet de ”casser” la connexion client-serveur. Nous sommes donc
en présence de deux connexions TCP pour une unique requête.
Dans le cadre de ce projet, nous utiliserons uniquement les contextes post-reverse-proxy puisque, comme
expliqué dans la section 5.2.2, les alarmes proches du serveur Web nous serviront de déclencheur du
scénario d’investigation.
Algorithme de définition des sessions TCP post-reverse-proxy
Afin de déterminer l’appartenance d’une alarme à une session TCP, nous nous basons en premier lieu
sur les adresses IP sources et destinations du paquet incriminé puis sur le numéro du port utilisé par le
client. Lors de l’application à notre architecture, nous remarquons que la différenciation des sessions sur
les adresses IP n’apporte rien puisque celles-ci sont identiques (seul le reverse-proxy interroge le serveur
Web). Ces deux seuls paramètres ne sont de loin pas suffisants au classement des alarmes par sessions
TCP. Il est donc impératif d’intégrer un troisième paramètre. Deux solutions ont alors été envisagées :
– Utilisation des numéros de séquences TCP.
– Utilisation d’un intervalle de temps pour l’utilisation d’un même port source.
Numéros de séquences TCP Les numéros de séquences sont codés sur 4 bytes et offrent donc 4,29
milliards de possibilités et permettent la régulation de flux du niveau 412 . A chaque début de connexion
TCP ces numéros de séquences sont initialisés par un algorithme aléatoire. L’idée est donc de définir un
écart maximum entre les numéros de séquences de deux alarmes de même session et de contrôler pour
chaque nouvelle alarme si celle-ci entre dans les critères d’une session existante. Si ce n’est pas le cas,
il faudra créer une nouvelle session. Cette solution se base sur le fait que les numéros de séquences sont
initialisés de manière totalement aléatoires et qu’aucune connexion TCP simultanée n’utilise la même
plage de numéros de séquences. Malheureusement, une notion de temps sera indispensable puisqu’il est
fort probable d’avoir deux sessions TCP grandement écartées dans le temps utilisant les mêmes plages
de numéros de séquences. Sans cette notion de temps, il serait donc impossible de différencier ces deux
sessions TCP temporellement très écartées mais très proches au niveau de leurs numéros de séquences.
Intervalle de temps entre deux même ports source Cette méthode de différenciation des sessions
TCP s’appuie sur le fait que, sur une même machine cliente, le même port source dynamique ne peut être
employé pour deux connexions TCP simultanées. Cette stratégie sera donc uniquement applicable dans
le cadre de notre architecture réseau, puisqu’une seule machine (reverse-proxy) interroge le serveur Web.
D’une certaine manière, cela signifie que le serveur Web ne voit qu’un seul client (le reverse-proxy), qui
parcourera la liste de ses ports source dynamiques afin d’établir les connexions TCP vers le serveur Web.
Ceci implique donc qu’il n’y aura jamais deux mêmes ports source utilisés simultanément.
En effet, le stack TCP de chaque machine comporte une plage de ports allouable dynamiquement (pour
les sockets du niveau applicatif) qui seront utilisés comme port source des connexions TCP. Ceux-ci sont
parcouru les uns après les autres selon l’algorithme défini dans les sources du kernel (Linux 2.4.27 dans
notre cas) implémentant le stack TCP. La fonction static int tcp v4 get port(struct sock *sk, unsigned
short snum) du fichier linux-2.4.27/net/iv4/tcp ipv4.c correspond à cette allocation.
12
Niveau de transport du modèle OSI
57
Nous remarquons que la variable sysctl local port range contient la plage de ports source allouables et
qu’il est possible de la modifier à l’aide de la commande système sysctl permettant de configurer certains
paramètres du noyau durant son exécution. Sa valeur par défaut est :
net.ipv4.ip_local_port_range = 32768 61000
Il faudrait donc être capable de connaı̂tre le taux d’utilisation des ports source (intervalle de temps entre
l’utilisation du même port source) du stack TCP du reverse-proxy pour une charge maximum du serveur
Web. Ceci permettrait de déterminer l’intervalle temporel limite, permettant de différencier l’utilisation
d’un même port source pour deux sessions (ou connexions) TCP différentes. Il nous serait ainsi possible,
à l’aide de l’heure de l’alarme ainsi que du port source du reverse-proxy, de déterminer l’appartenance
d’une alarme à une session TCP existante ou non.
Après réflexions, nous en avons déduit que l’utilisation des numéros de séquence pour l’identification
des sessions TCP repose sur une approche trop comportementale (dépendante de la masse des données
téléchargées). En effet, les alarmes peuvent être levées à n’importe quel moment de la transaction
HTTP et être espacées d’un grand nombre de bytes de payload13 pouvant ainsi donner de grands pas
d’incrémentation des numéros de séquence entre deux alarmes. Il serait alors possible que les compteurs
(numéros de séquence) de deux sessions TCP simultanées soient très proches et que le classement opéré
pour le contexte de session TCP communes soit erroné.
Nous avons donc opté pour l’approche de tri de session en fonction de l’intervalle de temps entre l’uti-
lisation du même port source. Nous devrons donc être capables d’évaluer le temps de réutilisation d’un
même port source afin d’avoir un minimum d’errreurs de classement.
Détermination de l’intervalle de temps pour l’utilisation du même port source
Le schéma de la figure 5.4 illustre le nombre maximum de requêtes acceptées par différents serveurs
Web Microsoft. A l’aide de ces statistiques, il nous est possible de connaı̂tre le nombre de ports par
seconde utilisés par le reverse-proxy pour une charge maximale du serveur Web. Nous relevons qu’un
petit serveur de production est capable de traiter 755 requêtes par seconde (soit l’utilisation de 755 ports
sources par seconde) et 2507 requêtes par seconde pour un gros serveur de production. A l’aide de ce
chiffre ainsi que de la plage de ports dynamiques disponibles (de 32768 à 61000) sur le reverse-proxy,
nous sommes capables de calculer l’intervalle de temps de réutilisation des ports sources :
Ports source dynamiques par défaut :
61000 − 32768 = 28232
Période de réutilisation des ports source du reverse-proxy pour un petit serveur de production :
13
Contenu des segments TCP
58
F IG . 5.4 – Statistiques de charge de IIS mesurée à l’aide de 240 Mb de données (80% de pages statiques
et 20% de pages dynamiques, source Microsoft)
28232
755 = 37.4secondes
Période de réutilisation des ports source du reverse-proxy pour un gros serveur de production :
28232
2507 = 11.3secondes
Maintenant, il serait intéressant d’observer la rapidité d’utilisation de la plage des ports source sur le
reverse-proxy. En effet, l’état Time wait du protocole TCP implique un temps d’attente du côté de la
station demandant la fermeture du socket (reverse-proxy dans notre cas) avant le restitution de celui-ci.
Étant donné que TCP s’appuie la plupart du temps sur IP (protocole de niveau 3 ne garantissant en au-
cun cas l’arrivée des paquets dans l’ordre d’émission), l’état Time wait permet d’attendre les éventuels
paquets égarés sur le réseau IP.
A l’aide de cette mesure nous pourrions nous assurer que le reverse-proxy n’est pas capable de parcou-
rir tous ses ports sources en moins de 37.4 secondes ou 11.3 secondes (suivant le type de serveur Web
installé), ce qui nous assurerait que deux segments TCP de deux sessions différentes ne peuvent pas
être physiquement émis sur le réseau avec le même port source dans cet intervalle de temps. En effet,
le serveur Web traitera au maximum 2507 requêtes par seconde mais rien n’empêche d’en envoyer plus.
Le supplément serait donc stocké dans un buffer et traité ultérieurement. Ce cas de figure implique que
le NIDS placé entre le reverse-proxy et le serveur Web détecterait deux segments TCP ayant le même
port source mais appartenant à deux sessions TCP différentes dans un intervalle de temps plus petit que
le maximum calculé précédemment à l’aide des caractéristiques du serveur Web.
Idéalement, ce test devrait être effectué à l’aide d’un programme en C ou C++ puisque le reverse-proxy
59
est lui-même écrit en C (Squid) et C++ (Dansguardian). Il serait ensuite nécessaire de créer un maxi-
mum de thread14 effectuant des connexions TCP au serveur Web ainsi qu’une requête HTTP afin qu’un
nombre considérable de connexions TCP soient effecutées et que le test reflète le fonctionnement normal
du reverse-proxy. Il faudrait ensuite que chacun de ces thread contrôle que le port dynamique source qu’il
s’est fait allouer n’a pas déjà été attribué précédemment à un autre thread. Si ce cas de figure survient, il
faudrait que le thread concerné mette fin à l’exécution du programme. En relevant le temps d’exécution de
ce programme (à l’aide de la commande time de Linux), il nous serait possible de connaı̂tre précisément
le temps nécessaire au reverse-proxy pour le parcours de tous ses ports sources allouables. Nous pour-
rions ainsi le comparer aux résultats trouvés pour une charge maximum (en requête par seconde) cal-
culée précédemment. Nous serions ensuite dans l’obligation de nous accorder à l’élément le plus rapide
(reverse-proxy ou serveur Web) afin que notre classement par sessions reste en tout temps sans erreur.
En effet, si le reverse-proxy est capable d’envoyer plus de requêtes que le serveur Web peut traiter, cela
signifierait que les calculs effectués ci-dessus ne peuvent être pris en considération. Ceci signifierait que
le reverse-proxy serait plus rapide que le serveur Web et serait capable d’émettre plusieurs segments TCP
de deux connexions différentes avec le même port source dans l’intervalle de temps défini par la rapidité
du serveur Web (calculé ci-dessus).
Malheureusement, pour une question de temps à disposition, nous ne pourrons pas écrire un tel pro-
gramme de test. Nous créons donc un petit script perl appelant le programme netcat permettant d’ouvrir
des connexion TCP sur un port. A l’aide d’une boucle nous parcourons 2200 ports afin d’avoir une idée
du temps d’exécution. Cette méthode de test effectuera malheureusement des connexions de manière
séquentielle...
Le résultat nous fournit un temps de 3 minutes et 24 secondes pour effectuer séquentiellement une requête
HTTP vers le serveur Web pour attendre sa réponse et pour recommencer avec un nouveau port source.
Nous remarquons donc que nous sommes bien loin des 11.3 secondes nécessaires au serveur Web pour
accepter un nombre de connexions égales au nombre de ports sources dynamiques du reverse-proxy.
Suite à cette mesure TRÈS approximative15 , nous opterons pour un temps de 15 secondes pour l’inter-
valle de temps entre l’utilisation du même port source.
5.5 Scénarii d’investigation
5.5.1 Possibilités et limites
Avant de définir précisément une méthode de corrélation (diagramme d’états permettant la description
de celle-ci), il est intéressant, en fonction de l’architecture à disposition, de définir les possibilités et les
limites de la corrélation :
Comme mentionné dans Vocabulaire et avant propos du tutorial d’intrusions réseaux et d’attaques Web
rédigé lors du travail de semestre, les attaques Web sont scindées en deux familles bien distinctes :
14
”Tache” vivant dans l’espace mémoire d’un autre processus (le programme principal)
15
Provenant du principe de test séquentiel
60
1. Attaques visant le programme serveur offrant le service Web (typiquement Apache ou IIS)
2. Attaques visant les applications hébergées par le serveur Web :
– Script serveur ou répertoire connu pour être vulnérable (typiquement les scripts de démo
deployés à chaque installation du serveur)
– Outre-passage de l’authentification mise en place sur un site Web ou modification de l’intégrité
du site (base de donnée ou pages HTML)
La première sous-catégorie des attaques visant les applications serveurs se présente comme facilement
détectable à l’aide d’un NIDS puisque ces scripts ou répertoires sont répertoriés dans les listes d’alarmes
du détecteur d’intrusions réseau. Cette détection lèvera malheureusement un grand nombre de faux posi-
tifs puisqu’il sera impossible, pour le NIDS, de savoir précisément si le serveur contient ou non le script
vulnérable détecté par le NIDS.
La seconde sous-catégorie pose quant à elle certains problèmes de détection puisqu’il est extrêmement
difficile de faire la distinction entre un comportement à risque et un comportement normal pour des ten-
tatives de SQL injection ou de Cross site scripting par exemple. En effet, le serveur Web n’y verra que
du ”feu” (la requête s’exécutera sans problème) et des règles génériques sur un NIDS généreraient un
grand nombre de faux positifs lors d’uploads vers le serveur Web par exemple.
Deux stratégies d’investigation complémentaires permettent de mettre en évidence ces deux sous-catégories :
1. La première sous-catégorie (Script serveur ou répertoire connu pour être vulnérable), pourra fa-
cilement être détectée à l’aide d’un NIDS (comme expliqué ci-dessus). L’élimination des faux
positifs pourra alors s’effectuer à l’aide de la récupération du status d’exécution des pages désirées
par les clients ou crackers. Cette méthodologie a été implémentée dans le cadre de ce projet de
diplôme. Celle-ci est décrite dans la section suivante (section 5.5.2).
2. La seconde sous-catégorie ( Outre-passage de l’authentification...) impliquera une analyse plus
comportementale. En effet l’utilisation des logs du reverse-proxy comme source d’informations
peut s’avérer utile pour ce genre d’attaques. Comme les NIDS ne peuvent être d’une grande utilités
pour ces cas de figure, il sera intéressant de détecter le dépassement d’un seuil de requêtes bloquées
sur le reverse-proxy afin d’effectuer une investigation approfondie pour l’adresse IP source désirée.
Cette stratégie se base donc sur le fait qu’une attaque visant l’outre-passage de l’authentification
ou des tentatives de modifcation de la base de données via les champs de saisies offerts par la
page Web implique souvent un grand nombre de tentatives avant une réussite. Cette méthode d’in-
vestigation ne pourra malheureusement pas être implémentée dans le cadre ce projet de diplôme
puisque le temps à disposition ne le permettra pas. Néanmoins, la section 5.5.3 Traçabilité des
comportements à risque ébauchera une solution envisageable.
La famille des attaques visant l’application serveur elle-même pourra être détectée à l’aide d’une sonde
NIDS (détection de buffer overflow par exemple). Une investigation plus étendue pourra ensuite être
effectuée sur les alarmes levées par la même source (adresse IP identique) afin de rechercher un compor-
tement indiquant la réussite d’un buffer overflow (exécution de commandes, par exemple).
61
5.5.2 Diminution des faux positifs par analyse des requêtes - réponses et du status du
serveur Web
Le principe est donc de fournir le meilleur status de réussite ou d’échec de l’attaque possible. Pour ce
faire nous allons nous appuyer sur le NIDS post-reverse-proxy et le HIDS récupérant les logs de refus
du serveur Web (erreurs 4xx). A l’aide du contexte de session TCP communes précédemment décrit,
il nous sera possible de distinguer la réponse à une requête. Nous serons donc capable d’observer si la
requête (définie comme dangeureuse par une alarme du NIDS post-reverse-proxy) a entraı̂né une réponse
dangereuse (levée par la même sonde NIDS). De plus, il nous sera possible d’affiner la dangerosité de
l’alarme et consultant les logs du serveur Web. En effet, si l’URL demandée par la requête ayant levé une
alarme sur le NIDS post-reverse-proxy n’est pas présente dans la liste des alarmes informant des refus du
serveur Web (erreur 4xx), l’alarme sera considérée comme encore plus critique puisque cela signifiera
que le serveur Web contient la page cible de l’attaque et qu’il a bien retourné une information au client.
Il nous a donc été possible de dresser un scénario générique16 illustré par la figure 5.5.
Description du diagramme d’état de la figure 5.5
Comme mentionné dans la section 5.2.2, le principe de corrélation mis en place dans le cadre de ce
projet de diplôme s’appuie sur les alarmes proches du serveur Web. Le déclencheur sera les alarmes
regroupées dans le contexte de session TCP communes post-reverse-proxy. Pour commencer, celles-ci
seront analysées une à une afin de définir si des alarmes IN17 et/ou des alarmes OUT18 sont présentes
dans la session. Plusieurs cas sont dès lors répertoriables :
1. Uniquement des alarmes OUT sont présentes dans la session TCP (point A du diagramme d’états)
Aucune investigation plus approfondie sur le serveur Web ne pourra être effectuée sur ce type de
session TCP puisqu’aucune URL ne sera présente dans celles-ci. En effet, les alarmes n’indiquent
aucune activité entrante suspecte alors qu’une activité sortante suspecte a été relevée. Le classe-
ment de ces sessions peut dès lors être effectué et être considéré comme très dangereux. Celles-ci
pourraient correspondre à une attaque pas encore répertoriée (pattern non existant dans le NIDS)
ou nécessitant plusieurs connexions TCP, alors que la réponse à cette attaque est typiquement
connue pour être dangereuse. Il s’agit d’une ”opportunité” de découvrir de nouvelles attaques sur
le serveur Web à protéger. Il sera donc impératif que le gestionnaire de réseau19 prenne le temps
d’analyser plus profondément ce type d’alarmes afin d’en définir sa dangerosité réelle.
2. Uniquement des alarmes IN sont présentes dans la session TCP (point 2 du diagramme d’états)
Une investigation plus approfondie est possible puisque la récupération des URLs de ces alarmes
est possible.
16
Générique : Car il ne s’appuie pas sur la connaissance d’un scénario d’attaque mais plutot sur une méthodologie de contrôle
des alarmes
17
En direction du serveur Web
18
En direction du client Web
19
Personne physique
62
3. Présence d’alarmes IN et OUT (point 3 du diagramme d’états) Une investigation plus approfon-
die est aussi possible puisque la récupération des URLs des alarmes IN présentes est envisageable.
L’investigation faisant suite aux points 2 et 3 du diagramme d’états sera exactement pareille, à la différence
près, que la dangerosité de la session définie à la suite de cette investigation plus poussée sera ajustée
en fonction de la présence d’alarmes OUT (différenciant le point 2 du point 3). En effet, la présence
d’alarmes OUT dans la session TCP implique souvent la réussite de l’attaque, ce qui amènera à clas-
sifier la session comme plus dangereuse. L’analyse d’investigation effectuée pour les points 2 et 3 se
différenciera donc par une dangerosité plus élevée pour les sessions composées d’alarmes IN et OUT
(point 3).
Celle-ci se présente sous la forme d’un contrôle d’exécution de la requête sur le serveur Web. En effet,
le protocole HTTP définit pour chaque requête un status de retour (retourné au client). Celui-ci est donc
enregistré dans les fichiers de logs du serveur Web avec l’URL demandée. A l’aide de la sonde HIDS
disposée sur celui-ci, il nous est possible de récupérer toutes les lignes de logs à des URLs non existantes
(status code 404) ou non atteintes par le client pour différentes raisons (status code 400, 401, 402, 403,
etc..). Pour de plus amples informations sur les status code de retour HTTP, nous vous laisserons consul-
ter l’URL suivante : http ://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Pour plus d’informations sur la mise en place de la sonde HIDS du serveur Web ainsi que sur l’établissement
des règles de rapatriement des logs (génération d’alarmes IDMEF) vous êtes libres de consulter la section
4.5 page 43 de ce rapport.
L’algorithme d’investigation fonctionne de la manière suivante :

Chaque alarme IN est contrôlée afin de définir si la requête la composant contient bien une URL. Si c’est
le cas, une recherche de la même URL est effectuée sur les alarmes du serveur Web afin de définir si la
requête a été exécutée ou non. Ceci correspond à la présence de l’URL dans les alarmes pour une requête
non exécutée et à son absence pour une requête exécutée. En fonction de l’exécution ou non de la requête
du client, une décision de classement de la session TCP est prise, comme l’illustre le diagramme d’état
de la figure 5.5.
La classification des sessions est ensuite définie comme suit :

– Alarmes OUT présentes :
– Exécution de la requête (point E) : La session est considérée comme extrêmement critique
puisque la requête a levé une alarme (alarme IN) et que sa réponse aussi (alarme OUT). Cet
état est représenté par Maximum Risk dans l’application de corrélation.
– Non exécution de la requête (point D) : La session est considérée comme très critique puis-
qu’une alarme OUT est présente. En effet, le serveur Web pourrait très bien avoir refusé
l’accès à l’URL demandée et avoir tout de même été compromis lors du traitement de la
requête (buffer overflow par exemple).
Un contrôle supplémentaire (effectué par le gestionnaire de réseau) est donc nécessaire afin d’af-
finer au maximum les résultats critiques fournis par cette analyse. Le cas de non exécution de la
requête nécessite une attention particulière afin de déterminer s’il s’agit d’un faux positif ou non.
63
Le contenu d’une requête (alarme IN) désignée comme dangereuse par le NIDS pourrait, en effet,
être répétée dans la page d’erreur du serveur Web (alarme OUT), ce qui aménerait le classement
d’une session non dangereuse dans cette catégorie.
– Alarmes OUT absentes :
– Exécution de la requête (point C) : La session est considérée comme très critique puisque la
requête ayant levé une alarme (alarme IN) a été exécutée par le serveur Web. Il se peut que la
réponse à cette requête ne paraisse pas dangereuse ou qu’aucun pattern ne la répertorie, ce qui
expliquerait l’absence d’alarmes OUT. La possibilité de faux positif ne doit pas être écartée
puisqu’il pourrait s’agir d’une requête considérée dangereuse pour une ancienne version du
serveur Web en question et non dangereuse pour la version patchée utilisée.
– Non exécution de la requête (point B) : La session est considérée comme peu critique (faux
positif) puisque le serveur Web ne contient pas ou refuse de fournir l’URL demandée par la
requête considérée comme dangereuse. La possibilité d’attaque réelle ne doit cependant pas
être écartée puisqu’il pourrait s’agir d’attaques du genre buffer overflow ne nécessitant pas
le retour de l’URL demandée mais uniquement une partie du traitement de la requête par le
serveur Web.
Nous remarquons qu’un contrôle supplémentaire (effectué par le gestionnaire) reste toujours judi-
cieux afin de vérifier les conclusions fournies par l’algorithme d’investigation.
5.5.3 Traçabilité des comportements à risque
Cette méthode d’analyse permettra de repérer un comportement à risque sur l’une ou l’autre des sondes
et de mener une investigation approfondie sur les différentes alarmes afin de repérer un comportement
dangereux. Cette stratégie s’applique donc lors d’une attaque réfléchie et poussée (tentatives successives)
et non pas lors de l’essai d’un script trouvé au hasard sur le Web. Le signe avant coureur qui nous per-
mettrait de déclencher l’investigation approfondie nous parviendrait de l’HIDS du reverse-proxy (trop
grand nombre de requêtes d’une seule source bloquée par DansguardianSims), du serveur Web (grand
nombre de status de refus ou d’erreurs levées par la même source) ou encore du firewall (scan de ports).
Il sera nécessaire de définir un seuil sur les différents déclencheurs afin de pouvoir décider si une in-
vestigation aura lieu. Cette stratégie serait typiquement applicable pour la détection d’outre-passage de
l’authentification abordée dans la section 5.5.1
5.6 Mise en place de NTP (Network Time Protocol)
Ce protocole permet la synchronisation des horloges systèmes des machines. Son fonctionnement s’ap-
puie sur une hiérarchie d’horloges synchronisées. Il est donc indispensable de lui indiquer un serveur sur
lequel il pourra s’appuyer (ntp01.eivd.ch dans notre cas). Ensuite, chaque station synchronisée à l’aide
de NTP pourrait jouer le rôle de serveur pour d’autres stations en demande de synchronisation.
NTP nous permettra d’obtenir un timestamp synchronisé de toutes les alertes présentes dans la base de
64
données de Prelude Manager. Il est alors indispensable d’installer un applicatif s’occupant de la gestion
de la synchronisation de l’heure sur toutes les machines générant des alertes.
5.6.1 Installation Linux
Pour ce faire, nous utiliserons la commande apt-get install afin de récupérer les applications nécessaires :
– ntp, permettant de réguler en permanance l’horloge système (daemon).
– ntpdate, permettant de forcer la mise à jour de l’heure du système (exécuté au démarrage).
Installation du daemon du contrôle de l’heure via NTP :
:/# apt-get install ntp
Installation de l’utilitaire de mise à jour de l’heure :
:/# apt-get install ntpdate
Son démarrage se fera ensuite automatiquement via un script de lancement situé dans /etc/init.d/
Configuration
Celle-ci s’opère via le fichier /etc/ntp.conf. Il suffira donc de préciser l’adresse du serveur maı̂tre (four-
nissant la synchronisation) en fin de fichier, comme illustré ci-dessous (ntp01.eivd.ch)
# /etc/ntp.conf, configuration for ntpd

.... .... .....
server ntp01.eivd.ch
Monitoring
A l’aide de la commande suivante, il nous est possible d’observer l’état du protocole NTP et d’observer
si la synchronisation de l’horloge a eu lieu. Si c’est le cas, une étoile apparaı̂t sur l’extrême gauche de
l’affichage (comme illustré ci-dessous) :
eduPc002:/etc/init.d# ntpq -p
remote refid st t when poll reach delay offset jitter
===============================================================================
*mail2.eivd.ch swiyv2.eivd.ch 5 u 227 256 377 0.446 0.122 0.316
5.6.2 Installation Windows
Une implémentation de NTP est nativement disponible sur Windows 2000. Deux outils sont utilisables
(Net Time et W32tm) mais seul Net Time permet une configuration sauvegardable, puisque W32tm permet
un diagnostique du service et une configuration non permanente.
65
Configuration
La configuration du serveur NTP s’opère de la façon suivante à l’aide d’un shell dos :
net time /setsntp:ntp01.eivd.ch
Il est ensuite indispensable de démarrer le service à l’aide de l’interface graphique de la manière suivante :
1. Dans le menu démarrer, cliquez sur Settings puis Control Panel
2. Double-cliquez sur Administrative Tools puis sur Services
3. Sélectionnez Windows Time dans la liste de service
4. Dans le menu d’action cliquez sur Start pour démarrer le service
Pour de plus amples informations sur ces deux outils de configuration et sur l’implémentation de NTP
pour windows 2000, consultez : http ://www.microsoft.com/windows2000/docs/wintimeserv.doc
66
F IG . 5.5 – Méthode de corrélation requête-réponse (session TCP)
67
Chapitre 6
Implémentation, installation et tests
Ce chapitre présente la partie logiciel de ce projet. Il définit les principes d’implémentation utilisés ainsi
que la configuration et l’installation du watchdog et du moteur de corrélation.
De plus, des tests sur le moteur de corrélation permettront d’observer les capacités et les limites du
scénario d’investigation mis en oeuvre.
6.1 Watchdog de contrôle d’état du/des serveur(s) Web
Comme expliqué dans la section 5.3 du chapitre 5, ce watchdog permettra le contrôle du bon fonction-
nement de serveurs Web (plusieurs à la fois) à intervalle de temps régulier. Il sera capable d’avertir
l’administrateur réseau (via e-mail) en cas de disfonctionnements et de lui fournir un petit diagnostique.
Le watchdog commencera, à l’aide d’un ping, par déterminer si la machine officiant en tant que serveur
Web est toujours en fonction. Si ce premier test est concluant, il contrôlera cette fois-ci le service HTTP.
En effet, suite à une attaque, le service Web peut être inopérant alors que le stack IP du système d’ex-
ploitation du serveur fonctionne toujours (réponse aux pings).
Deux types de mails (émis à l’administrateur réseau) sont envisageables :
1. Alerte indiquant que le serveur est hors service (ne répond pas aux pings)
2. Alerte indiquant que le service Web est inopérant
Un fichier de log contenant l’historique des tests effectués et les erreurs d’exécutions du watchdog (er-
reurs lors de l’envoi du mail) est conservé dans le répertoire indiqué dans le fichier de configuration.
6.1.1 Détermination de l’état du service Web
Afin de définir si le serveur Web est opérationnel, il est indispensable, dans le fichier de configuration
du watchdog, de fournir non pas l’adresse du serveur mais l’URL complète d’une page Web existante
et accessible. Il est évidemment préférable, si nous avons à faire à un site Web non statique, de fournir
68
l’URL d’une page dynamique afin de contrôler en plus, le bon fonctionnement de l’interpréteur1 ou de
la machine virtuelle2 du serveur Web .
Le watchdog enverra une requête HTTP à l’URL contenue dans le fichier de configuration afin de tester
le service Web. En cas de disfonctionnement, le message d’erreur HTTP contenu dans la réponse du
serveur sera récupéré est ajouté à l’e-mail d’alarme envoyé à l’administrateur réseau. Un diagnostique
succint sera ainsi directement possible après lecture du mail.
6.1.2 Installation
Étant écrit en Perl, son installation requiert les modules suivants :

LWP : :UserAgent Pour les requêtes HTTP.
HTTP : :Response Pour le contrôle de l’état des réponses HTTP.
Net : :SMTP auth Pour l’authentification au serveur de mail.
Net : :Ping Pour l’exécution des pings.
Net : :DNS Pour les requêtes DNS avant l’exécution d’un ping.
Leurs installations sous Linux peut être facilement effectuée à l’aide d’un outil du CPAN3 comparable à
l’apt-get de Debian. Il suffira de taper la commande perl -MCPAN -e shell dans un shell afin d’obtenir
un second shell permettant l’installation des modules.
L’installation de modules s’effectue ensuite à l’aide de la commande install ¡nomModule¿ comme illustré
ci-dessous :
edu-pc114:/usr/local/watchDog# perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.59_54)

ReadLine support available (try ’install Bundle::CPAN’)
cpan>install Net::SMTP_auth
Le téléchargement et la compilation du module se fera automatiquement après le lancement de la com-

mande install.
Nous avons ensuite placé le watchdog sur le Manager Prelude (/usr/local/watchdog/) et configuré son
lancement en tâche de fond lors du démarrage de celui-ci (dans le script /etc/init.d/local) :
echo "Demarrage du watchdog"

/usr/local/watchDog/watchdog.pl &
6.1.3 Configuration
Celle-ci s’opère à l’aide du fichier Perl confWatchDog.pl. Les première directives permettent la configu-
ration du serveur mail, le chemin du fichier de log ainsi que l’intervalle de temps entre deux contrôles.
Quant à la dernière directive, elle permet d’indiquer les sites Web à contrôler (comme illustré ci-dessous) :
1
Software interprétant les scripts serveurs (PHP, Perl, etc...)
2
Pour des sites Web écrits en Java (Servlets ou JSP)
3
Comprehensive Perl Archive Network
69
$conf{’webSites’}=["192.168.1.4/securitystore/index.php", "192.168.1.3",
"www.monSite.ch/index.jsp"];
6.2 Algorithme de corrélation et site Web (frontend)
Comme mentionné dans le chapitre 5, il ne nous a pas été possible, dans le cadre de se travail de diplôme,
d’implémenter plusieurs scénarii de corrélation. Cette section définira uniquement l’implémentation du
scénario de corrélation basé sur les sessions TCP post-reverse-proxy communes (défini dans la section
5.5.2 du chapitre 5.
6.2.1 Choix du langage et du frontend hôte
Comme mentionné dans la section 5.3 du chapitre 5, l’implémentation d’une application temps réelle n’a
pas été possible dans le cadre de ce travail de diplôme. Nous avons donc décidé d’ajouter un module à
l’interface Web 4 existante avec Prelude. Nous avons préféré ajouter notre module de corrélation à Piwi
plutôt qu’à l’interface PHP développée par Patrick Saladino (durant son travail de diplôme 2003) puisque
nous avions comme première idée d’effectuer la corrélation à proprement parlé à l’aide de SEC5 , logiciel
également écrit en Perl. Le langage de programmation commun ne fut pas le seul point déterminant de
l’intégration a Piwi. En effet, après avoir exploré les différents Frontend, il s’est avéré que Piwi offrait
une grande souplesse dans le tri des alarmes que l’interface développée par M. Saladino ne permettait
pas. Piwi offre la possibilité de créer ses propres filtres et permettra de différencier facilement les alarmes
en fonction leurs sonde source. Il sera ainsi aisé d’observer les alarmes en fonction de leur emplacement
sur le réseau.
Il a alors été nécessaire d’investir un peu de temps dans l’apprentissage du langage Perl puisque mes
connaissances en la matière étaient inexistantes.
6.2.2 Étude de l’interfaçage avec SEC
Ce logiciel de corrélation étudié dans le chapitre 7, permet de définir un scénario de corrélation d’événements
extraits de fichiers (typiquement de fichiers de logs). Dans un premier temps, l’idée est de créer un pro-
gramme effectuant les recherches dans la base de données, le rassemblement des sessions TCP commune
et le stockage de celles-ci sous forme d’un fichier texte. SEC récupérera ce fichier afin d’appliquer la
corrélation définie dans son fichier de configuration. le résultat retourné sera ensuite stocké dans un se-
cond fichier texte que l’application récupérera pour un affichage sous forme de page Web dynamique.
Après une phase de tests, cette méthode de travail (par échange de fichiers) pourra être améliorée puisque
comme mentionné plus haut, le langage de programmation est identique (Perl). Il sera intéressant de di-
rectement passer une structure de donnée (stockée en RAM6 ) à SEC afin d’éviter une lecture de fichiers
4
Frontend écrit en Perl et nommé Piwi, http ://www.leroutier.net/Projects/PreludeIDS/
5
Simple Event Correlator, Logiciel open source permettant la définition de scénarii de corrélation d’événements
http ://sixshooter.v6.thrupoint.net/SEC-examples/article.html
6
Mémoire vive de l’ordinateur (Random Access Memory)
70
coûteuse en temps processeur.
Après une étude plus approfondie de SEC (relatée dans le chapitre 7), il s’est avéré quasiment impossible
de l’intégrer dans l’application envisagée (comme expliqué ci-dessus). En effet, nous avonc remarqué que
cette application était vraiment vouée à une utilisation temps réel puisque presque la totalité des règles
à disposition utilisent une notion de temps. Étant donné que notre application se voue à une analyse
(corrélation) à postériori, il ne sera pas possible d’intégrer SEC dans le cadre ce projet. Le chapitre 7
traitant de SEC offrira néanmoins des exemples d’utilisation pratique, afin d’offrir un petit aperçu de la
capcité de cet outil de corrélation.
6.2.3 Architecture logiciel
Le paradigme de programmation utilisé est procédural puisque l’apprentissage de la programmation

orientée objets en Perl aurait été trop couteuse en temps. Il est évident que si l’application venait à être
améliorée par l’ajout de nouveaux scénarii de corrélation, il serait avantageux de reprendre celle-ci afin
de la faire migrer vers un paradigme orienté objets. En effet, un tel paradigme offre une réutilisation faci-
litée des objets déjà défini. Il serait ainsi beaucoup plus aisé, pour les personnes désireuses d’ajouter une
nouvelle fonctionnalité au moteur de corrélation, de le faire en implémentant simplement un nouvel objet.
L’application de corrélation peut tout de même être découpée en plusieurs fichiers correspondant à
différents niveaux. La figure 6.1 illustre l’architecture élaborée.
F IG . 6.1 – Structure du logiciel de corrélation développé
71
– Communication avec la base de donnée, dataBasee.pl

– Recherche des sessions TCP, contextes.pl
– Correlation par l’algorithme définit dans la section 5.5 du chapitre 5, correlation.pl
– Interface graphique (CGI), showCorrelation.pl
Le fichier dataBase.pl offre les fonctions d’interrogatinde la base de données. Celles-ci retourneront des
structures de données décrites dans les entêtes du code source (tables de hash ou tableaux). Il est impor-
tant de noter que les procédures setConf() et setTime() font offices de ”constructeurs”. En effet, il serait
abérant de récupérer toutes les alarmes de la base de donnée pour effectuer la corrélation des alarmes de
la journée. La procédure setTime(), permet de figer l’heure afin que les différentes fonctions d’accès à la
base de donnée utilisent une heure commune. Le hash $conf’fenetreCorrelation’ contenu dans le fichier
de configuration permettra ensuite de définir la fenêtre de corrélation à appliquer.
Certaines fonction (définies dans la deuxième partie du code) ne nécessitent aucune initalisation tempo-
relle (setTime()), puisque elles effectuent une recherche spécifique dans la base de données.
Le fichier contextes.pl implémente l’algorithme de recherche des sessions TCP post-reverse-proxy com-
munes. Il nécessite les fonctions d’accès à la base de donnée afin que l’algorithme définit dans la section
5.4.1 du chapitre 5 soit applicable. Son utilisation est similaire à dataBase.pl puisqu’il sera nécessaire
de l’initialiser à l’aide des procédure init() et setConf(). Celles-ci on pour effet d’effectuer toutes les
requête nécessaires à la base de données afin de pouvoir fournir rapidement les structures de données
nécessaire à l’algoritme de reconstitution des session TCP. De plus, les structures de données nécessaire
à l’algorithme de corrélation et à l’affichage des informations d’une sessions TCP seront disponibles via
les fonctions définies dans ce fichier. De cette manière un seul accès à la base de donnée (effectué via
l’appel à init()) sera nécessaire.
Le fichier correlation.pl implémente le diagramme d’état d’investigation présenté dans la section 5.5 du
chapitre 5. Il fournit une fonction retournant un tableau indiquant la dangerosité de chaque sesison TCP.
Son pseudo code est présenté ci-dessus :
/* analyse de chaque session TCP post-reverse-proxy */

Pour chaque session TCP, boucler {
/* recherche du sens des alarms de la session courante */
Pour chaque alarmes de la session, boucler{
Est-ce une alarme IN ou OUT
}
Si il y a que des alarmes OUT dans la session{
dangerosite de la session = A
fin de la correlation pour cette session
}
/* recherche d’exécution sur le serveur Web */
Pour chaque alarmes IN de la session, boucler{
Si l’alarme courant contient une URL{
Si l’URL de l’alarme courante a été refusée par le serveur{
/* afin de garder la dangerosité la plus élevée de la session */
72
Si la dangerosité de la session courante n’est pas plus élevée{

la dangerosité de la session vaut: peu critique
}
}
sinon{
la dangerosité de la session vaut: très critique
}
}
sinon{
la dangerosité de la session vaut: indéterminé (pas d’URL disponnibles)
}
}
/* ajustement de la dangerosité en fonction du sens des alarmes */
Si il y a que des alarmes IN{
Si la dangerosité de la session a été déterminée comme très critique{
dangerosité de la session = C
}
sinon{
dangerosité de la session = B
}
}
/* il y a alors des alarmes IN et OUT */
sinon{
Si la dangerosité de la session a été déterminée comme peu critique{
dangerosité de la session = D
}
sinon{
dangerosité de la session = E
}
}
}
Le fichier showCorrelation.pl implémente l’interface graphique permettant l’interaction du gestionnaire

de réseau avec le moteur de corrélation. Celui-ci nécessite l’inclusion du module CGI permettant l’interfaçage
avec le serveur Web.
Pour de plus amples informations sur l’implémentations et les structures de données utilisées, le lecteur
averti pourra se plonger dans le code source disponnibles sur le CD du projet.
6.2.4 Installation
Le moteur de corrélation et son interface graphique sont prévu pour s’exécuter du côté serveur. Il est
donc nécessaire de disposer d’un serveur Web supportant Perl. L’installation du moteur de corrélation
doit impérativement être effectuée dans le répertoire de l’interface Web de Piwi puisqu’il nécessite un
fichier de configuration communs et certaines librairies d’accès au SGBD. L’installation de Piwi est
détaillée à l’adresse suivante :
http ://www.leroutier.net/Projects/PreludeIDS/Demo/Docs/INSTALL.txt
73
Pour l’installation du moteur de corrélation, il vous suffira d’ajouter le répertoire correlation, le fichier
showCorrelation.pl ainsi que la feuille de style commonCorrelation.css à la racine de Piwi. Le fichier
racinePiwi/Templates/Links devra ensuite être remplacé par celui fournit avec le moteur de corrélation
afin qu’un lien vers celui-ci soit disponnible dans l’interface existante de Piwi.
Étant donné que le fichier de configuration du moteur de corrélation est défini dans celui de Piwi racine-
Piwi/Functions/config.pl, il est indispensable de le remplacer par celui fournit avec les sources du moteur
de corrélation.
6.2.5 Configuration
La première partie du fichier de configuration contenue dans racinePiwi/Functions/config.pl permet le

réglage de Piwi, alors que la seconde permet la configuration du moteur de corrélation développé dans
le cadre de ce travail de diplôme. Comme Perl est un langage interprété7 , la configuration du moteur de
corrélation se présente sous la forme d’une table de hash. Les modifications apportée à ce fichier seront
ainsi directement prise en compte lors de l’utilisation du programme.
La première partie de la configuration du moteur de corrélation nécessite les identificateurs des différentes
sondes. Ceux-ci sont disponnibles dans le fichier /etc/prelude-sensors/sensors.ident de chaques sondes.
Les directives suivantes sont expliquées ci-dessous :
$conf’TcpSessionDuration’ Permet la configuration de la durée d’une session TCP post-reverse-proxy.
Celle-ci sera utilisée pour la recherche des sessions communes et la création du contexte de session
TCP communes.
$conf’portServeur’ Permet de préciser le port d’écoute du serveur Web à protéger.
$conf’ipServeur’ Permet de préciser l’adresse IP du serveur Web.
$conf’ipProxy’ Permet de préciser l’adresse IP du reverse-proxy.
$conf’fenetreCorrelation’ Permet de préciser la fenêtre de corrélation à utiliser. Il s’agira du nombre
de secondes à analyser depuis le lancement du moteur de corrélation.
$conf’timeIntervalHidsNids’ Permet de préciser le temps de recherche de l’URL des alarmes du NIDS
post-reverse-proxy sur les logs du serveur Web.
$conf’timeIntervalFindingIP’ Permet de préciser le temps de recherche du même type d’alarme entre
le NIDS post-reverse-proxy et pre-reverse-proxy afin de déterminer l’adresse IP réelle de l’atta-
quant.
Le fichier de configuration utilisé dans le cadre de ce projet est disponnible dans les Annexes, section
A.5.
7
Nécessitant aucune compilation
74
6.2.6 Utilisation
Aucun manuel d’utilisation du moteur de corrélation n’a été rédigé, puisque son interface Web se présente
sous forme didactique. En effet le diagramme d’états du scénario d’investigation mis en place est dis-
ponnible via cette interface. L’utilisateur désireux d’obtenir des informations détaillées sur les niveaux
de dangerosité utilisés, aura la possibilité de les obtenirs directement sur le site Web en question (comme
l’illustre la figure 6.4).
La figure 6.2 illustre l’interface d’accueil permettant de visualiser les alarmes des différents sondes
présentes.
F IG . 6.2 – Interface Web d’accueil du management de l’architecture Web (permettant de démarrer la

corrélation)
La figure 6.3 illustre l’affichage des résultats d’une corrélation.
75
F IG . 6.3 – Interface Web affichant les résultats de la corrélation
6.3 Tests du moteur de corrélation
Cette partie relate les différents essais effectués sur le moteur de corrélation. En effet, nous avons procédé
en deux phases :
1. Tests d’attaques spécifiques
2. Tests à l’aide de scans Nessus8
Le test d’attaque spécifique nous a permis d’observer le comportement du moteur de corrélation aux
attaques prévues et d’en corriger son fonctionnement si besoin était.
Le test à l’aide d’un scan Nessus nous a permis de déterminer l’efficacité du moteur de corrélation à
l’élimination des faux positifs.
La figure 6.5 illustre bien l’élimination d’un grand nombre de faux positifs puisque toutes les sessions
représentées par une dangerosité de couleur verte représente un faux positif. Nous avons alors ana-
lysé (manuellement) la majorité de ces alarmes afin de contrôler l’efficacité de l’applicatif développé.
La figure 6.6 illustre quant à elle la détection d’une session TCP post-reverse-proxy très dangereuse
(exécution de commandes sur le serveur Web via cmd.exe). Nous remarquons bien la détection de la
totalité de la session puisqu’il est possible d’observer via différentes alarmes : L’accès au fichier cmd.exe
8
Scanner de vulnérabilités open source
76
F IG . 6.4 – Interface Web permettant de visualiser l’algorithme de corrélation utilisé
ainsi que le retour de l’exécution de la commande (listage d’un répertoire).

D’autres tests ont ensuite été effectués afin de vérifier le bon fonctionnment du moteur de corrélation.
Ceux-ci ne seront pas illustrés dans cette section puisqu’ils seront présentés lors de la défense du projet
le 19 janvier 2005, à l’EIVD (B01b à 10h).
77
F IG . 6.5 – Résultat de la corrélation permettant d’éliminer un grand nombre de faux positifs
F IG . 6.6 – Résultat de la corrélation retrouvant une session TCP dangereuse
78
Chapitre 7
Descriptif et utilisation de SEC
7.1 Description
SEC est un logiciel Open Source récupérant le flux d’entrée d’un fichier texte ou d’un pipe1 afin d’y
appliquer une détection de pattern selon des règles décrites dans un fichier de configuration. SEC dis-
pose de différents directives de configuration permettant une utilisation variée (analyse de logs, machine
d’états, logique, etc...). Ces directives de configuration fonctionnent principalement à l’aide de fenêtres
temporelle. Il sera facile de le configurer pour un traitement en temps réel. En effet, nous avons tenté dans
le cadre de ce projet, de le configurer pour une corrélation de logs à postériori. Ceci c’est très rapidement
averré impossible puisque la gestion de conditions sans aucune notion de temps n’est vraiment pas aisée.
Nous allons maintenant étudier quelques petits exemples permettant d’illustrer le fonctionnement temps
réel d’une corrélation à l’aide de SEC.
7.2 Fonctionnement par l’exemple

# Reconnaı̂tre un pattern et le journaliser
# essai.conf
# source: http://sixshooter.v6.thrupoint.net/SEC-examples/article.html
#
type=Single
ptype=RegExp
pattern=foo\s+
desc=$0
action=logonly
L’exemple ci-dessus illustre la recherche d’un pattern dans le flux d’entrée. Voici le descriptif de cette
configuration :
1
Récupération d’un flux de sortie d’une commande
79
type Permet de préciser le genre de règles à utiliser. Nous somme ici en présence d’une simple règle de
recherche de pattern.
ptype Permet de préciser le pattern type utilisé pour la recherche d’une suite de caractères (dans notre
cas à l’aide d’expressions régulières).
pattern Indique le pattern à rechercher (à l’aide du ptype mentionné précédemment). Dans ce cas, une
expression régulière.
desc Permet la description de l’événement. $0 représente le pattern total détecté à l’aide de l’expression
régulière de la directive pattern.
action Indique l’action à entreprendre lorsque la règle s’applique. Dans ce cas, la description sera en-
voyée dans un fichier de log (si un fichier est mentionné au lancement) sinon la sortie standard (le
shell).
Son exécution s’opère ensuite de cette manière :
% perl sec.pl -conf=essai.conf -input=-
La directive input=- indique que le flux d’entrée n’est rien d’autre que le shell courant (entrée standard).
Après son lancement, nous remarquons que dès que nous entrons le mot foo suivi d’un espace (dans le
shell), la totalité de la ligne entrée est répétée sur la sortie standard.
Le principe de lecture du fichier de configuration par SEC est similaire à celui d’un firewall puisqu’il
prendra les directives les unes après les autres en regardant si celles-ci s’appliquent au pattern courant. Il
sera ainsi possible de chaı̂ner plusieurs groupe de règles dans le même fichier.
L’exemple ci-dessous illustre un fonctionnement un peu plus complexe :
# essai2.conf
# source: http://sixshooter.v6.thrupoint.net/SEC-examples/article.html
#
type=Single
ptype=RegExp
pattern=foo
desc=$0
action=event 5 baz is now matched. ; \
write - foo matched baz event in 5 seconds...
# simple règle
type=Single
ptype=RegExp
pattern=bar
desc=$0
action=write - $0 is matched.
# Cette règle récupère le pattern écrit (baz) par la règle 1

type=Single
ptype=RegExp
80
pattern=baz
desc=$0
action=write - %s matched
Trois règles sont maintenant définies. La première utilise l’action event permettant la création d’événements
internes à SEC (après un temps déterminé ici 5 secondes), récupérables par les autres règles. Nous re-
marquons qu’il est possible de cumuler différents événements à l’aide d’un point virgule. L’action write
- aura pour effet d’écrire le texte qui suivra sur la sortie standard (le shell dans ce cas). La seconde règle
fonctionne de la même manière que l’exemple précédent. C’est donc pour cette raison que nous n’allons
pas plus la détailer.
La troisième règle détectera l’événement contenant le pattern baz (généré par la première règle) qui sera
ensuite écrit sur la sortie standard (%s indiquant la récupération de la description).
Après ces petits exemples d’utilisation il est intéressant d’observer les différents types de règles dispo-
nibles avec SEC :
Single Lorsque l’événement défini par pattern est détecté, une action est exécutée.
SingleWithScript Lorsque l’événement défini par pattern est détecté et qu’un script externe retourne
une certaine valeur de retour, une action est exécutée.
SingleWithSuppress Lorsque l’événement défini par pattern est détecté, une action est exécutée et les
prochains événements sont ignorés pendant t secondes.
Pair Lorsque l’événement défini par pattern est détecté, une action est immédiatement exécutée. Pen-
dant les t prochaines secondes les événement entrants seront ignorés, jusqu’à l’arrivée d’un second
événement qui exécutera une seconde action.
PairWithWindow Lorsque l’événement défini par pattern est détecté un time out est déclenché dans
l’attente d’un second événement. Si ce second événement arrive (dans la fenêtre définie par le time
out) une action est exécutée. Si le second événement n’arrive pas dans la fenêtre mentionnée, une
seconde action sera exécutée.
SingleWithThreshold Compte le nombre d’événements défini par la directive pattern durant t secondes.
Lorsqu’un nombre suffisant d’événements est détecté, une action est effectuée et le compteur
d’événements est remis à zéro.
SingleWith2Thresholds Compte le nombre d’événements défini par la directive pattern durant t se-
condes. Lorsqu’un nombre suffisant d’événements est détecté, une action est effectuée. Le comp-
teur d’événements n’est pas remis à zéro et lorsqu’un nouveau seuil est atteint en moins de t’
secondes une seconde action est exécutée.
Suppress Supprime des événement entrant.
Calendar Exécute une action à une date spécifiée.
A l’aide des deux exemples ci-dessus, ainsi que de la description des différents types de règles dispo-
nibles, ll nous est déjà possibles d’entrevoir les possiblités offertes par SEC.
81
Imaginez maintenant que les logs d’accès à un serveur Web soient rapatriés (via syslog de Linux) dans le
même fichiers que les logs d’une sonde Snort. Il serait alors possible d’établir le même genre de scénario
d’investigation mis en place dans le cadre de ce projet (contrôle du status d’exécution de chaque requête
critique sur le serveur Web) en fonctionnement temps réel.
7.3 Conclusion
Grâce à l’étude de l’association de SEC avec notre moteur de corrélation, il nous a été possible d’en-
trevoir les capacités d’analyse temps réel qu’offre cet outil. Son utilisation pourrait tout de même être
envisagée dans l’architecture proposée afin de permettre une analyse temps réel d’événement très cri-
tiques offrant un système d’alerte rapide en cas de gros problèmes.
82
Chapitre 8
Panorama de l’offre actuelle
Ce chapitre présente quelques solutions existantes d’IDS offrant une corrélation des informations récoltées.
Il sera ainsi possible d’observer et comparer quelques solutions existantes sur le marché.
8.1 Open Source Security Information Management (OSSIM)
OSSIM1 est, comme son nom l’indique, un projet open source utilisant plusieurs produits issus de la
même phylosophie (open source) afin d’y intégrer une infrastructure de monitoring.
Cette application a comme objectif principal, d’améliorer la visualisation de la masse d’alarmes (émises
par différentes sondes). En effet le problème principal du management d’alarmes provient :
1. Du volume de donnée émises par les différentes sondes
2. De la relation inexistante entre les différentes alarmes
8.1.1 Description
L’objectif principal d’OSSIM est de fournir un système centralisé, organisé permettant l’amélioration
de la détection d’attaques ainsi que l’affichage organisé d’événements de sécurité. OSSIM possède les
outils d’affichages suivants :
– Fenêtre de contrôle pour les alarmes de haut niveau
– Fenêtre de contrôle pour l’affichage des risques et de l’activité de niveau intermédiaire
– Fenêtre de contrôle pour l’affichage des risques réseaux de bas niveau
Ces différents outils utilisent des méthodes d’analyses améliorant la détection de relations entre les
événements. Celles-ci peuvent être décomposées en :
– Corrélation
– Mise en place de niveaux de priorité
1
disponible sur : http ://www.ossim.net/
83
– Evaluation des risques

OSSIM prévoit la récupération d’informations de différents détecteurs. En effet il est capable de récupérer
et d’utiliser les informations d’IDS, de détecteurs d’anomalies, de firewalls et d’une variété d’autres
éléments réseaux.
Finalement il fournit un outil d’administration permettant de configurer et d’organiser les modules uti-
lisés (externes et natifs). Cet outil permet la définition de la topologie utilisée, des polices de sécurité,
des règles de corrélation et fournit les liens vers une variété d’outils existants intégrés à OSSIM
F IG . 8.1 – Architecture d’OSSIM
Nous observons sur la figure 8.1, les différents composants logiciel d’OSSIM. Nous remarquons l’utili-
sation de plusieurs base de données intermédiaires, décrites ci-dessous :
EDB La base de données d’événements. Celle-ci est la plus volumineuse puisqu’elle stockera tous les
événements individuel reçu par les détecteurs.
KDB La base de données de configuration. Celle-ci stockera les polices de sécurité ainsi que les pa-
ramètres liés à l’architecture réseau.
UDB La base de données des profiles. Celle-ci stockera toutes les informations générées par le moniteur
de profile.
8.1.2 Méthodes d’analyses utilisées
Le procédés de détection d’alarmes et de récolte de celles-ci repose sur des solutions existantes. En effet,
rien de nouveau n’a été mis en place dans le domaine.
OSSIM apporte alors une nouvelle solution pour tout ce qui touche au post-processing2 .
Trois méthodes d’analyse à postériori sont appliquées :
2
Analyse des informations après leur réception
84
1. Les alarmes sont classées suivant une priorité définie par les polices de sécurités mises en place
sur l’architecture
2. La menace de chaque alarme est ensuite évaluée en fonction des éléments en dangers et de la
probabilité de risque qu’il en découle
3. Une corrélation est ensuite appliquée afin de regrouper des alarmes indépendantes entre elles en
événement hostiles
Pour l’étape de corrélation, deux méthodes ont été déployées :
Basée sur l’heuristique Cette méthode offrira une évaluation du risque comparable à un ”thermomètre”.
Il sera ainsi possible, en tous temps, d’observer la ”température” de la sécurité du réseau. Pour ce
faire, le risque a été séparé en deux catégories : Le risque que la machine soit compromise (risque
nommé C), le risque potentiel d’une attaque sur cette machine (nommé A). A l’aide de ces deux
types de risque, il sera possible à l’aide d’un algorithme (CALM3 ), de définir l’état global de
sécurité de l’architecture.
Basée sur des diagrammes d’états Cette méthode permet la création de diagrammes d’états du type :
”Si l’événement A et B sont détectés, effectuer l’action C”.
A la suite des ces différentes étapes, OSSIM propose une visualisation des risques sous forme de page
Web. Les figures suivantes illustrent l’interface proposée :
F IG . 8.2 – Console de monitoring (affiche des statistiques d’une semaine)
3
Compromise and Attack Level Monitor
85
F IG . 8.3 – Console de monitoring (affichage en temps réel du trafic Web, selon l’algorithme d’heuris-
tique)
8.2 Open security management
La société Open4 , spécialiée dans la corrélation d’alertes de sécurité en temps réel propose différents
produits de sécurité. Leur Security Threat Manager est une application de gestion de la sécurité qui met
en oeuvre une couche d’intelligence entre les équipements de sécurité et ceux qui sont en charge de leur
administration.
La figure 8.4 illustre le principe de corrélation mis en place par Open security.
Le STM5 transforme les capteurs d’événements déployés sur les équipements de sécurité en un ensemble
unifié. Pour ce faire, STM corrèle les données reçues afin de fournir un système d’alertes temps réel pour
des administrateurs réseaux.
STM combine l’intégralité des données de vulnérabilités et des événements de sécurité des équipements
et vous offre une vision globale de risques.
4
http ://www.open.com/products/security-threat-manager.jsp
5
Security Threat Manager
86
F IG . 8.4 – Principe d’analyse et de corrélation mise en place par Open security management
8.2.1 Description
La corrélation définie par STM utilise les caractéristiques suivantes :

– Associe automatiquement les attaques aux vulnérabilités et la valeur de la cible
– Rapporte les menaces sur la base du risque d’attaque et de l’impact sur les activités de l’entreprise
– Relie les événements de multiples éditeurs et capteurs
– Extensible et personnalisable :
– Modification de l’interface par utilisateur
– Sauvegarde, planification et impression de rapports de vulnérabilités pour des analyses en
temps réel ou à postériori
Le moteur de corrélation est basé sur NerveCenter, outil de corrélation utilisant une machine d’états. Les
algorithmes intégrés ne requierent aucunes maintenance des règles et utilisent des données directement
stockée en mémoire afin de tendre vers une utilisation le plus temps réel que possible.
87
Chapitre 9
Conclusion
Durant ces trois mois de travail de diplôme, il nous a été offert d’effectuer différentes tâches aussi variées
qu’intéressantes. En effet, nous avons eu le plaisir d’effectuer les travaux suivants :
– Étudier et comparer différents reverse-proxys

– Programmer en C++ (modification du code source de Dansguardian)
– Déployer une architecture réseau complète (Firewall, reverse-proxy, serveurs Web, gestion des
logs, etc...)
– Étudier et appliquer une corrélation d’événements à notre architecture réseau
– Programmer en Perl (conception d’un moteur de corrélation de démonstration)
Nous estimons avoir atteint notre but, puisque la quasi totalité du cahier des charge a été remplie. Le
lecteur attentif aura remarqué que l’étude des différentes attaques réseaux et Web (point I.b du cahier des
charges) ne figure pas dans ce rapport, puisqu’un tutorial lui a été dédié lors du travail de semestre1 .
Ce travail de diplôme ne peut en aucun cas prétendre avoir fait le tour du sujet. En effet, la corrélation
d’événements reste un domaine en pleine évolution et en recherche de solutions efficaces. Il serait
intéressant d’approfondir l’analyse et de mettre en place d’autres scenarii d’investigation permettant
d’observer le comportement de l’architecture mise en place. De plus, il serait très utile de deployer et
tester l’application de gestion d’intrusions Open Source OSSIM2 puisqu’il ne nous a pas été possible de
le faire dans le cadre de ce projet (la découverte de cet outil s’est faite trop tard). Sur un point de vue plus
logiciel et commercial, il serait souhaitable de mette sur pied une syntaxe de configuration permettant de
définir ses propres scenarii d’investigations sans être un programmeur chevronné.
D’un point de vue plus personnel, ce travail m’a permis d’élargir mes connaissances en sécurité réseau,
configuration d’éléments réseaux et gestion de la détection d’intrusions. Ces différents domaines m’ont
1
Travail fournit en annexe à ce rapport
2
Application décrite dans le chapitre 8
88
donné une forte envie d’approfondir mes connaissances en la matière. C’est pour cela que j’envisage
fortement une formation plus poussée dans le domaine....
Yverdon-les-Bains, le 17 décembre 2004
Joël Winteregg
89
Chapitre 10
Remerciements et références
10.1 Remerciements
Je tiens à remercier très chaleureusement les personnes suivantes pour leur soutien ainsi que pour leur
aide apportée à l’élaboration de ce projet :
Cyril Friche Pour les conseils, les informations sur SEC et la relecture.
Stefano Ventura Pour différents conseils et la validation des idées.
Gérald Litzistorf Pour les conseils de corrélation appliquée à l’architecture mise en place.
Christian Tettamanti Pour les coups de pouces sous Linux.
Sylvain Maret Pour les conseils d’architecture réseau.
Yann Souchon Pour les conseils sur la mise en place du reverse-proxy Squid.
Jérôme Caillet Pour différentes conseils et les échanges d’idées
Raphaël Lienhard Pour différents conseils et les échanges d’idées
Famille Winteregg Pour la relecture et la correction orthographique.
10.2 Références
– Livre Snort 2 de Jack Koziol, édité par CampusPress, ISBN : 2-7440-1624-1
– Documentation sur Prelude-IDS :
– Comparatif Prelude-Snort :
http ://lehmann.free.fr/Prelude.html
– http ://www.prelude-ids.org/
– Interface graphique Piwi et test de règles pour Prelude-lml (hids) :
http ://www.leroutier.net/Projects/PreludeIDS/
90
– Installation :
http ://entreelibre.com/scastro/prelude/preludeLML-secured-installation howto.txt
– Reverse-proxy AppShield :
Rapport de diplôme ”Securité des applications Web” de Sylvain Tissot disponible sur :
http ://proxyfilter.sourceforge.net/documents/rapport websecurity diplome.pdf
– Installation d’un firewall Iptables :
– http ://www.netfilter.org/documentation/HOWTO/fr/NAT-HOWTO-6.html
– http ://christian.caleca.free.fr/netfilter/
– http ://www.fr.linuxfromscratch.org/view/blfs-5.0-fr/postlfs/firewall.html
– http ://lea-linux.org/reseau/iptables.html
– Informations sur l’implémentation TCP du kernel Linux :
http ://www.kernelnewbies.org/documents/ipnetworking/linuxipnetworking.html
– Langage Perl :
– Introduction à Perl de O’Reilly : ISBN 2-84177-041-9
– Recherche de modules existants :
http ://search.cpan.org/
– API pour les CGI :
http ://www.enstimac.fr/Perl/ModulesFr/CGI.html
– Le HTML avec Perl :
http ://stein.cshl.org/ lstein/talks/marjorie/
– Installation de NTP :
– http ://www.eecis.udel.edu/ ntp/ntpfaq/NTP-s-config.htm
– http ://www.siliconvalleyccie.com/linux-hn/ntp.htm
– Informations sur Syslog :
– http ://www.linuxvoodoo.com/resources/howtos/syslog/
– http ://linux.cudeso.be/linuxdoc/syslog.php
– Rotation des logs :
http ://linux.about.com/od/commands/l/blcmdl8 logrota.htm
– Syslog pour Windows :
http ://intersectalliance.com/
– Execution de tâches journalières via Cron :
http ://www.commentcamarche.net/tutlinux/lincron.php3
– Dansguardian :
– Principe de fonctionnement :
http ://dansguardian.org/ ?page=dgflow
91
– Guide d’installation :
http ://dansguardian.org/downloads/detailedinstallation2.html
– Configuration :
http ://linsec.ca/bin/view/Main/DansGuardian
– Rating HTML utilisé par Dansguardian :
http ://www.w3.org/TR/REC-PICS-labels#General
– Squid :
– http ://www.squid-cache.org/
– White paper sur l’utilisation et la configuration de Squid :
http ://squid.visolve.com/squid/whitepaper.htm
– Guide de l’utilisateur :
http ://squid-docs.sourceforge.net/latest/book-full.html
– Analyseur de logs pour Squid :
http ://www.squid-cache.org/Scripts/
– Proxy Suisse :
http ://www.seclutions.com/en/ct products4 en.htm
– Principe de corrélation :
– Exemple de corrélation par SANS :
http ://www.sans.org/resources/idfaq/role.php
– Exemple d’application :
http ://www.securityfocus.com/infocus/1708
– Outil de corrélation Open :
http ://www.hermitagesolutions.com/public/pages/32092.php
– Solution open source de corrélation :
http ://www.ossim.net/whatis.php
– SEC, outil de corrélation d’événements :
http ://sixshooter.v6.thrupoint.net/SEC-examples/article.html
– Manuel d’utilisation de MySql :
http ://dev.mysql.com/doc/mysql/fr/index.html
– Status code HTTP :
http ://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
92
Annexe A
Annexes
A.1 Planning et coût horaire
Après une partie théorique de recherche d’un reverse-proxy efficace et si possible open source, nous
avons pu nous orienter sur la mise en place de l’architecture. Il a été nécessaire de configurer tous les
éléments réseaux utilisés. Après cette partie de mise en place forte intéressante, il nous a été possible
d’observer les comportements du réseau (surtout des sondes) face à différentes attaques. C’est ainsi qu’il
nous a été possible d’établir un scénario d’investigation que nous avons implémenté sous forme de site
Web dynamique en Perl.
Le tableau suivant relate en coût horaire le travail effectué :
93
Activités Durée [semaine]

Correction du travail de semestre et installation du système d’exploitation pour le reverse-proxy 0.5
Documentations sur Snort et rédaction de la comparaison avec Prelude-IDS 0.5
Étude, installation et tests de Squid 0.5
Étude, installation et tests de Dansguardian 0.5
Modification du code source de Dansguardian 0.5
Rédaction et tests de Dansguardian 0.5
Étude de l’URL rewriting à l’aide de Squid, installation HIDS du reverse-proxy 0.5
Étude sonde HIDS (Prelude-lml) et installation du serveur Web vulnérable (IIS) 0.5
Création des règles du HIDS et d’une blacklist à l’aide de Nessus et d’Ethereal 1.0
Mise en place du firewall, de l’architecture totale et rédaction du rapport 1.0
Mise en place de la rotation des logs et documentation sur la corrélation 0.5
Documentation sur la corrélation et mise en place de NTP 0.5
Étude d’une corrélation appliquée à notre architecture 0.5
Étude de SEC et de son interfaçage avec le moteur de corrélation 0.5
Apprentissage de Perl et de l’utilisation des CGI 0.5
Étude de la détection des sessions TCP communes et implémentation du moteur de corrélation 1.0
Implémentation du moteur de corrélation et rédaction du rapport 1.0
Tests du moteur de corrélation et rédaction du rapport 0.5
Rédaction du rapport 1.0
Total 12.0 semaines
A.2 Fichiers de configuration des sondes du reverse-proxy
La configuration d’une sonde s’opère en deux parties. La première consiste à configurer le sensors1 à
l’aide du fichier /etc/prelude-sensors/sensors-default.conf. Il permettra de définir l’adresse du manager,
le type de machine hébergeant le sensors ainsi que son emplacement. Il s’agit donc d’une configuration
globale d’un sensors (indépendante de son type).
La seconde consiste en la configuration de la sonde elle même (NIDS ou HIDS). Il s’agira de définir,
dans le cas d’une sonde HIDS, les fichiers de logs à analyser ainsi que les règles à utiliser. Dans le cas
d’une sonde NIDS, il sera possible de sélectionner les plugins à utiliser.
A.2.1 Configuration du sensor

Fichier de configuration global du sensor. Situé à : /etc/prelude/prelude-sensors/sensors-default.conf
# This is the default configuration for sensors that use libprelude.
# Entry in this configuration file are overriden by entry directly
# provided by the sensor configuration file.
1
configuration indépendante du type de sonde utilisée (NIDS ou HIDS)
94
# Try to connect on a Manager listening on 127.0.0.1.

#
# manager-addr = x.x.x.x:port || y.y.y.y && z.z.z.z
#
# This mean the emission should occur on x.x.x.x:port or, if it fail,
# on y.y.y.y and z.z.z.z (if one of the two host in the AND fail,
# the emission will be considered as failed involving saving the
# message locally).
manager-addr = 192.168.1.5;
#
# Optionnal data gathered with the alert.
#
node-name = reverse-proxy;
node-location = B03;
node-category = hosts;
#Liste possible pour node-category:

#
# unknown Domain unknown or not relevant
# ads Windows 2000 Advanced Directory Services
# afs Andrew File System (Transarc)
# coda Coda Distributed File System
# dfs Distributed File System (IBM)
# dns Domain Name System
# hosts Local hosts file
# kerberos Kerberos realm
# nds Novell Directory Services
# nis Network Information Services (Sun)
# nisplus Network Information Services Plus (Sun)
# nt Windows NT domain
# wfw Windows for Workgroups
# Address contained by this Node,

# You may have several address.
#
# [Node Address]
#
address = 192.168.1.2;
netmask = 255.255.255.0;
# vlan-name = Name of the Virtual LAN to which the address belongs;

# vlan-num = Number of the Virtual LAN to which the address belongs;
#
category = ipv4-addr;
A.2.2 Configuration de la sonde HIDS

Fichier de configuration (plugins et fichier de log à analyser) du HIDS (/etc/prelude-lml/prelude-lml.conf).
##############################################
# Configuration for the Prelude LML Sensor #
##############################################
[Prelude LML]
# Address where the Prelude Manager Server is listening on.

# if value is "127.0.0.1", the connection will occur throught
# an UNIX socket.
#
# This entry is disabled. The default is to use the entry
# located in sensors-default.conf... You may overwrite the
# default address for this sensor by uncommenting this entry.
#
# Configuration for the UDP message receiver.

# commented out by default since most people only want to
# monitor files.
95
#
# [Udp-Srvr]
#
# port = 514
# addr = 0.0.0.0
#
# Files to monitor
#
#Fichier de réception des logs de IIS
file = /var/log/messages
#Fichier des logs d’accès du reverse-proxy
file = /var/log/dansguardian/access.log
#
# Specifies the maximum difference, in seconds, between
# the interval of two logfiles’ rotation. If this difference
# is reached, a high severity alert will be emited
#
rotation-interval = 3600
####################################
# Here start plugins configuration #
####################################
[SimpleMod]
ruleset=/etc/prelude-lml/ruleset/simple.rules;
# [Debug]
#
# This plugin issue an alert for each packet.
# Carefull to the loging activity it generate.
Configuration des règles à utiliser
Fichier de configuration des règles (pattern matching) à utiliser. Celui-ci est précisé dans le fichier de
configuration du HIDS par la directive ruleset=¡chemin¿/fichierDesRèglesAUtiliser.rules.
Il se trouve à : /etc/prelude-lml/ruleset/simple.rules
#
# Rule format :
#
# For more information about the fields described above and their meaning,
# please have a look to the IDMEF Draft located at :
#
# http://www.silicondefense.com/idwg/draft-ietf-idwg-idmef-xml-07.txt
#
# If one of the IDMEF field you wish to add information too isn’t covered in
# the rule language, please take the 5 minutes needed to implement a simple
# parsing function to the simple.c plugin distributed with Prelude LML.
#
#
# - regex:
# A PCRE regex that should be matched to trigger the alert.
#
# - class.name:
# The name of the alert, from one of the origins listed below.
#
# - class.origin:
# The source from which the name of the alert originates.
# Possible values are: unknown, bugtraqid, cve, vendor-specific. Default is unknown.
#
# - class.url:
# A URL at which the manager (or the human
# operator of the manager) can find additional information about the
# alert. The document pointed to by the URL may include an in-depth
# description of the attack, appropriate countermeasures, or other
# information deemed relevant by the vendor.
#
# - impact.severity:
96
# An estimate of the relative severity of the event.

# Possible values are: low, medium, high.
#
# - impact.completion:
# An indication of whether the analyzer believes the attempt that
# the event describes was successful or not.
# The permitted values are: failed, succeeded.
#
# - impact.type:
# The type of attempt represented by this event, in relatively broad categories.
# The permitted values are: admin, dos, file, recon, user, other.
#
# - impact.description:
# May contain a textual description of the impact, if the analyzer
# is able to provide additional details.
#
# - source.node.address.address:
# Address that issued the attack.
# There can be more than one.
#
# - target.node.address.address:
# Address that has been attacked.
#
# - source.node.name,
# target.node.name:
# The name of the equipment. This information MUST be provided if no Address
# information is given.
#
# - source.node.category,
# target.node.category:
# The domain from which the name information was obtained.
# Possible values are: unknow, ads, afs, coda, dfs, dns, hosts, kerberos,
# nds, nis, nisplus, nt, wfw
#
# - source.node.location,
# target.node.location:
# The location of the equipment.
#
# - source.spoofed,
# target.decoy:
# An indication of wheter the source/target is a decoy.
# The permitted values are: unknown, yes, no.
#
# - source.interface,
# target.interface:
# May be used by a network-based analyzer with multiple interfaces to
# indicate which interfaces this source/target was seen on.
#
# - source.service.name,
# target.service.name:
# The name of the service. Whenever possible, the name from the IANA list
# of well-known ports SHOULD be used.
#
# - source.service.port,
# target.service.port:
# The port number being used.
#
# - source.service.protocol,
# target.service.protocol:
# The protocol being used.
#
# - source.service.portlist,
# target.service.portlist:
# A list of port numbers beeing used.
#
# - source.user.category,
# target.user.category:
# The type of user represented (unknown, application, os-device).
#
# - source.user.userid,
# target.user.userid:
# Create a new UserId inside an User object (that may contain several UserId).
#
# - source.user.userid.type,
# target.user.userid.type:
# The type of user information represented (current-user, original-user, target-user,
# user-privs, current-group, group-privs, other-privs).
#
# - source.user.userid.name,
97
# target.user.userid.name:
# A user or group name.
#
# - source.user.userid.number,
# target.user.userid.number:
# A user or group number.
#fichier de règles de récupération des logs de dansguardian

include = dansguardian.rules;
#fichier de règles de récupération des erreurs 4xx de IIS

include = iis.rules;
Règles (pattern matching) de Prelude-lml pour DansguardianSims
Ce fichier se trouve à : /etc/prelude-lml/ruleset/dansguardian.rules

#####
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING. If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
#
#####
#####################################################################
# To get When a requested URL is bloqued (comming from the
# Bannedregexpurllist file of dansguardian configuration)
#####################################################################
#LOG exemple:
#2004.10.27 15:42:51 - 10.192.72.83 http://10.192.72.95/iissamples/ *DENIED* Banned Regular Expression URL: .*/iissamples/ GET 0
regex=([\d+\.]+) http://(.*)\s\*DENIED\*\sBanned Regular Expression URL:(.*)\s(GET|POST).*; \

class.name=Dansguardian Reverse-proxy: DENIED request to Web server; \
impact.severity=high; \
impact.completion=failed; \
impact.type=other; \
impact.description=Url: $2 requested by $1 had dangerous content defined by this regular expression: $3; \
#attention, obligatoire pour un bon fonctionnement
source.node.address; \
source.node.address.address=$1; \
source.node.address.category=ipv4-addr; \
source.service.port=80; \
source.service.protocol=http; \
target.node.address; \
target.node.address.category=unknown; \
target.node.address.address=$2; \
target.service.port=80; \
target.service.protocol=http;
#####################################################################
# To get When a client Browser is bloqued (comming from the
# Bannediplist file of dansguardian configuration)
#####################################################################
#LOG exemple:
#2004.10.27 15:56:57 - 10.192.72.83 http://10.192.72.95/ *DENIED* Your IP address is not allowed to web browse: 10.192.72.83 GET 0
regex=([\d+\.]+) http://(.*)\s\*DENIED\*\sYour IP address is not allowed to web browse.*; \

class.name=Dansguardian Reverse-proxy: DENIED Client; \
98
impact.description=$1 Web client try to request $2, but his client IP is denied; \
#fournit l’URL entière demandée comme adresse de destination
#####################################################################
# To get When a client try to get a banned extension file (coming
# from the bannedextensionlist file of dansguardian configuration)
#####################################################################
#LOG exemple:
#2004.10.27 15:48:12 - 10.192.72.83 http://10.192.72.95/securitystore/index.exe *DENIED* Banned extension: .exe GET 0
regex=([\d+\.]+) http://(.*)\s\*DENIED\*\sBanned extension: (.*) (GET|POST).*; \

class.name=Dansguardian Reverse-proxy: DENIED extension file requested; \
impact.description=$1 try to access a denied file extension. URL: $2; \
#fournit l’URL entière demandée comme adresse de destination
#####################################################################
# To get When a client send banned POST data (coming from the
# bannedregexpostdata file of dansguardian configuration)
#####################################################################
#LOG exemple:
#2004.10.28 17:23:13 - 10.192.72.83 http://10.192.72.95/securitystore/login.php *DENIED* POST 0
regex=([\d+\.]+) http://(.*)\s\*DENIED\*\s\sPOST; \
class.name=Dansguardian Reverse-proxy: DENIED POST data sent to Web server; \
impact.description=Url: $2 requested by $1 had dangerous POST content; \
Règles (pattern matching) de Prelude-lml pour IIS
Ce fichier se trouve à : /etc/prelude-lml/ruleset/iis.rules
99
#####
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# EIVD, SIMS PROJECT:
# Joël Winteregg
#
#####
#####################################################
# To get When a requested URL throw a 4xx status code
#---------------------------------------------------
#
#IIS NEED TO have the following log configuration for
#a matching by these rule:
#
# - W3C Extended Log File Format
#
# - Client IP
# - Server IP
# - Server Port
# - Method
# - URI Stem
# - URI Querey
# - Protocol Status
#
#####################################################
#LOG exemple:
#Nov 8 14:48:06 192.168.1.4 edu-pc068 IISWebLogˆI3ˆI2004-11-08 13:48:03 192.168.1.2 - 192.168.1.4 80 GET /securitystore/lon.php - 404
regex=([\d+\.]+) - ([\d+\.]+) (\d+) (GET|POST) (.*) (4\d+); \

#si mot de la highsecuritywordlist ici alors sera en rouge dans interface graphique
class.name=IIS Server: DENIED request to Web server $2, error code $6; \
impact.severity=medium; \
impact.description=URL: $5 requested by $1 on the $2 web server throw a $6 error; \
target.node.address.category=ipv4-addr; \
target.service.port=$3; \
A.2.3 NIDS pre-reverse-proxy

Fichier de configuration de la sonde NIDS. Celui-ci se trouve à : /etc/prelude-nids/prelude-nids.conf
##############################################
# Configuration for the Prelude NIDS Sensor #
##############################################
[Prelude NIDS]

# an UNIX socket.
#
100

#
# Set this entry if you want Prelude NIDS to use a specific user.
#
# user = prelude;
#[Tcp-Reasm]
#
# TCP stream reassembly option
#
# Only analyse TCP packet that are part of a stream,
# this defeat stick/snot against TCP signatures.
#
# statefull-only;
#
# Only reassemble TCP data sent by the client (default).
#
# client-only;
#
# Only reassemble TCP data sent by the server.
#
# server-only;
#
# Reassemble TCP data sent by client and server.
#
# both;
#
# Only reassemble data to specific port (default is to reassemble everything).
#
# If this option is used with the statefull-only option, packet that are not
# going to theses specified port will be analyzed anyway.
#
# port-list = 1 2 3 4;
####################################
####################################
[SnortRules]
ruleset=/etc/prelude-nids/ruleset/prelude.rules;
[ScanDetect]
# Number of connection attempt to get from the same

# host and targeted on different port before the scan
# detection plugin issue an alert.
#
high-port-cnx-count = 50;
low-port-cnx-count = 5;
# Window of time without getting any activity the scan

# detection plugin should wait before issuing an alert
# for a given host.
#
cnx-ttl = 60;
# [Shellcode]
#
# This plugin allow for polymorphic shellcode detection.
# It may consume a lot of CPU time, so it’s disabled by
# default. Uncomment the section name to enable it, or
# specify --shellcode on the command line.
nops_raise_alert = 60;
101
#
# If a port-list is specified, the Shellcode plugin
# will only analyse data going to theses port (when
# the protocol used have have dst port).
#
# port-list = 1 2 3 4;
# [Debug]
#
[HttpMod]
#
# Normalize HTTP request.
# The "codepage-file" option contains the name of the file containing
# Unicode to ASCII convertion tables for WIN32 machines.
#
# The "codepage-number" option is the codepage number your WIN32 servers use.
#
#
# end-on-param:
# Stop parsing the URL when we meet a parameter.
#
# double-encode:
# Check for encoded ’%’ character.
#
# max-whitespace:
# Maximum number of whitespace allowed before URL begin.
#
# flip-backslash:
# Change ’\’ to ’/’ when parsing URL.
#
double-encode;
flip-backslash;
max-whitespace = 10;
codepage-file = /etc/prelude-nids/unitable.txt;
codepage-number = 437;
port-list = 80 8080;
[RpcMod]
#
# Decode RPC traffic, Also provide the RPC rule key.
#
port-list = 111;
[TelnetMod]
#
# Normalize telnet negotiation character
#
port-list = 23 21;
[ArpSpoof]
#
# Search anomaly in ARP request.
#
# The "directed" option will result in a warn each time an ARP
# request is sent to an address other than the broadcast address.
#
# directed;
# arpwatch=<ip> <macaddr>;
Ce fichier se trouve à : /etc/prelude-nids/ruleset/prelude.rules
102
###################################################
# Step #1: Set the network variables:
#
# You must change the following variables to reflect
# your local network. The variable is currently
# setup for an RFC 1918 address space.
#
# You can specify it explicitly as:
#
# var HOME_NET 10.1.1.0/24
#
# or use global variable $<interfacename>_ADDRESS
# which will be always initialized to IP address and
# netmask of the network interface which you run
# snort at. Under Windows, this must be specified
# as $(<interfacename>_ADDRESS), such as:
# $(\Device\Packet_{12345678-90AB-CDEF-1234567890AB}_ADDRESS)
#
# var HOME_NET $eth0_ADDRESS
#
# You can specify lists of IP addresses for HOME_NET
# by separating the IPs with commas like this:
#
# var HOME_NET [10.1.1.0/24,192.168.1.0/24]
#
# MAKE SURE YOU DON’T PLACE ANY SPACES IN YOUR LIST!
#
# or you can specify the variable to be any IP address
# like this:
var HOME_NET 192.168.1.0/24
# Set up the external network addresses as well.

# A good start may be "any"
var EXTERNAL_NET any
# Configure your server lists. This allows snort to only look for attacks
# to systems that have a service up. Why look for HTTP attacks if you are
# not running a web server? This allows quick filtering based on IP addresses
# These configurations MUST follow the same configuration scheme as defined
# above for $HOME_NET.
# List of DNS servers on your network

var DNS_SERVERS $HOME_NET
# List of SMTP servers on your network

var SMTP_SERVERS $HOME_NET
# List of web servers on your network

# The reverse-proxy is like the Web server for external IP
var HTTP_SERVERS 192.168.1.2
# List of sql servers on your network

var SQL_SERVERS $HOME_NET
# List of telnet servers on your network

var TELNET_SERVERS $HOME_NET
# Configure your service ports. This allows snort to look for attacks
# destined to a specific application only on the ports that application
# runs on. For example, if you run a web server on port 8081, set your
# HTTP_PORTS variable like this:
#
# var HTTP_PORTS 8081
#
# Port lists must either be continuous [eg 80:8080], or a single port [eg 80].
# We will adding support for a real list of ports in the future.
# Ports you run web servers on

var HTTP_PORTS 80
# Ports you want to look for SHELLCODE on.

var SHELLCODE_PORTS !80
# Ports you do oracle attacks on

var ORACLE_PORTS 1521
# other variables
#
103
# AIM servers. AOL has a habit of adding new AIM servers, so instead of
# modifying the signatures when they do, we add them to this list of
# servers.
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,
64.12.29.0/24,64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]
# Path to your rules files (this can be a relative path)

var RULE_PATH /etc/prelude-nids/ruleset
include reference.config
include classification.config
# The rules included with this distribution generate alerts based on

# Please read the included specific file for more information.
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/oracle.rules
include $RULE_PATH/mysql.rules
include $RULE_PATH/snmp.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/virus.rules
include $RULE_PATH/experimental.rules
include $RULE_PATH/local.rules
A.3 Configuration de la sonde post-reverse-proxy

Fichier de configuration global du sensor. Situé à : /etc/prelude/prelude-sensors/sensors-default.conf

#
#
# message locally).
manager-addr = 192.168.1.5 ;
#
#
node-name = NIDS post-reverse-proxy;

node-category = hosts;
104


#
# [Node Address]
#
address = 192.168.1.5;
netmask = 255.255.255.0;
category = ipv4-addr;
A.3.1 Configuration de la sonde NIDS

Fichier de configuration de la sonde NIDS. Celui-ci se trouve à : /etc/prelude-nids/prelude-nids.conf
##############################################
# Configuration for the Prelude NIDS Sensor #
##############################################
[Prelude NIDS]

# an UNIX socket.
#
#
# Set this entry if you want Prelude NIDS to use a specific user.
#
# user = prelude;
#[Tcp-Reasm]
#
# TCP stream reassembly option
#
# Only analyse TCP packet that are part of a stream,
# this defeat stick/snot against TCP signatures.
#
# statefull-only;
#
# Only reassemble TCP data sent by the client (default).
#
# client-only;
#
# Only reassemble TCP data sent by the server.
#
# server-only;
#
# Reassemble TCP data sent by client and server.
105
#
# both;
#
# Only reassemble data to specific port (default is to reassemble everything).
#
# If this option is used with the statefull-only option, packet that are not
# going to theses specified port will be analyzed anyway.
#
# port-list = 1 2 3 4;
####################################
####################################
[SnortRules]
ruleset=/etc/prelude-nids/ruleset/prelude.rules;
[ScanDetect]
# Number of connection attempt to get from the same

# host and targeted on different port before the scan
# detection plugin issue an alert.
#
high-port-cnx-count = 50;
low-port-cnx-count = 5;
# Window of time without getting any activity the scan

# detection plugin should wait before issuing an alert
# for a given host.
#
cnx-ttl = 60;
[Shellcode]
#
# This plugin allow for polymorphic shellcode detection.
# It may consume a lot of CPU time, so it’s disabled by
# default. Uncomment the section name to enable it, or
# specify --shellcode on the command line.
nops_raise_alert = 60;
#
# If a port-list is specified, the Shellcode plugin
# will only analyse data going to theses port (when
# the protocol used have have dst port).
#
# port-list = 1 2 3 4;
# [Debug]
#
[HttpMod]
#
# Normalize HTTP request.
# The "codepage-file" option contains the name of the file containing
# Unicode to ASCII convertion tables for WIN32 machines.
#
# The "codepage-number" option is the codepage number your WIN32 servers use.
#
#
# end-on-param:
# Stop parsing the URL when we meet a parameter.
#
# double-encode:
# Check for encoded ’%’ character.
#
# max-whitespace:
# Maximum number of whitespace allowed before URL begin.
106
#
# flip-backslash:
# Change ’\’ to ’/’ when parsing URL.
#
double-encode;
flip-backslash;
max-whitespace = 10;
codepage-file = /etc/prelude-nids/unitable.txt;
codepage-number = 437;
port-list = 80 8080;
[RpcMod]
#
# Decode RPC traffic, Also provide the RPC rule key.
#
port-list = 111;
[TelnetMod]
#
# Normalize telnet negotiation character
#
port-list = 23 21;
[ArpSpoof]
#
# Search anomaly in ARP request.
#
# The "directed" option will result in a warn each time an ARP
# request is sent to an address other than the broadcast address.
#
# directed;
# arpwatch=<ip> <macaddr>;
Ce fichier se trouve à : /etc/prelude-nids/ruleset/prelude.rules

###################################################
# Step #1: Set the network variables:
#
# You must change the following variables to reflect
# your local network. The variable is currently
# setup for an RFC 1918 address space.
#
# You can specify it explicitly as:
#
# var HOME_NET 10.1.1.0/24
#
# or use global variable $<interfacename>_ADDRESS
# which will be always initialized to IP address and
# netmask of the network interface which you run
# snort at. Under Windows, this must be specified
# as $(<interfacename>_ADDRESS), such as:
# $(\Device\Packet_{12345678-90AB-CDEF-1234567890AB}_ADDRESS)
#
# var HOME_NET $eth0_ADDRESS
#
# You can specify lists of IP addresses for HOME_NET
# by separating the IPs with commas like this:
#
# var HOME_NET [10.1.1.0/24,192.168.1.0/24]
#
# MAKE SURE YOU DON’T PLACE ANY SPACES IN YOUR LIST!
#
# or you can specify the variable to be any IP address
# like this:
var HOME_NET 192.168.1.0/24
107
# Set up the external network addresses as well.

# A good start may be "any"
var EXTERNAL_NET any
# Configure your server lists. This allows snort to only look for attacks
# to systems that have a service up. Why look for HTTP attacks if you are
# not running a web server? This allows quick filtering based on IP addresses
# These configurations MUST follow the same configuration scheme as defined
# above for $HOME_NET.
# List of DNS servers on your network

var DNS_SERVERS $HOME_NET
# List of SMTP servers on your network

var SMTP_SERVERS $HOME_NET
# List of web servers on your network

# Web server address
var HTTP_SERVERS 192.168.1.4
# List of sql servers on your network

var SQL_SERVERS $HOME_NET
# List of telnet servers on your network

var TELNET_SERVERS $HOME_NET
# Configure your service ports. This allows snort to look for attacks
# destined to a specific application only on the ports that application
# runs on. For example, if you run a web server on port 8081, set your
# HTTP_PORTS variable like this:
#
# var HTTP_PORTS 8081
#
# Port lists must either be continuous [eg 80:8080], or a single port [eg 80].
# We will adding support for a real list of ports in the future.
# Ports you run web servers on

var HTTP_PORTS 80
# Ports you want to look for SHELLCODE on.

var SHELLCODE_PORTS !80
# Ports you do oracle attacks on

var ORACLE_PORTS 1521
# other variables
#
# AIM servers. AOL has a habit of adding new AIM servers, so instead of
# modifying the signatures when they do, we add them to this list of
# servers.
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,
64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]
# Path to your rules files (this can be a relative path)

var RULE_PATH /etc/prelude-nids/ruleset
include reference.config
include classification.config
# The rules included with this distribution generate alerts based on

# Please read the included specific file for more information.
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/attack-responses.rules
108
include $RULE_PATH/oracle.rules
include $RULE_PATH/mysql.rules
include $RULE_PATH/snmp.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/virus.rules
include $RULE_PATH/experimental.rules
include $RULE_PATH/local.rules
A.4 Configuration du firewall
A.4.1 Script d’établissement des règles du firewall
Ce script est exécué à chaque démarrage du firewall. Il se trouve donc à : /etc/init.d/configFirewall

Il est ensuite lié aux runlevels adéquats pour une exécution automatique. La commande update-rc.d
permet la création automatiquement des liens dans les différents runlevel :
# update-rc.d configFirewall defaults 90
Script de configuration du Firewall :

#!/bin/sh
#
#Configuration du firewall
#==========================
#Projet SIMS orienté Web
#==========================
#
#Le contrôle des regles s’opère dans l’ordre de leurs declaration.
#Nous avons donc place le drop indiquant le fonctionnement whitelist
#a la fin.
#######################################
#Initialisation des chaines
#######################################
#on efface les regles
iptables -F
iptables -t nat -F
#on efface les chaines utilisateurs
iptables -X
#######################################################
#creation d’une chaine utilisateur pour droper et loger
#######################################################
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix "Drop "
iptables -A LOG_DROP -j DROP
###############################################################################
#Initialisation des polices par defauts: Tout est autorisé afin de tout
#laisser passer lors de la réinitialisation (iptables -F)
#le drop se fait à la fin, afin de fonctionner en whitelist.
###############################################################################
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
##########################################
#Accepte tout sur la loopback du firewall
##########################################
iptables -A INPUT -i lo -j ACCEPT
#Tous les outputs sont autorise, donc pas besoin de preciser ceci:
#iptables -A OUTPUT -o lo -j ACCEPT
###############################################################################
109
#Authorise le trafic Web avec le reverse-proxy 192.168.1.2

###############################################################################
iptables -A FORWARD -i eth0 -p tcp -d 192.168.1.2 --dport 80 -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp -s 192.168.1.2 --sport 80 -j ACCEPT
###############################################################################
#Synchronisation de l’heure des sondes avec le serveur NTP
###############################################################################
###############################################################################
#Autorise le trafic Web la console d’administration (car machine pour redaction
#et recherche d’informations)
###############################################################################
#pour les requêtes DNS de tout le reseau
#La console d’administration (portable) est autorisée à sortir du réseau

iptables -A FORWARD -i eth1 -p tcp -s 192.168.1.3 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp -d 192.168.1.3 -j ACCEPT
#on accepte de router tous les pings

iptables -A FORWARD -p icmp -j ACCEPT
#pour l’envoi des mails du watchdog situé sur le manager Prelude

iptables -A FORWARD -i eth1 -p tcp -s 192.168.1.5 --dport 25 -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp -d 192.168.1.5 --sport 25 -j ACCEPT
#######################################################
#Pour le management sur le firewall depuis l’interieur du reseau
#######################################################
iptables -A INPUT -i eth1 -p tcp -j ACCEPT
###############################################################################
#Tous les paquets pour lesquels aucune des regles ci-dessus ne s’appliquent
#sont loge et drope (sauf les outputs)
###############################################################################
iptables -A INPUT -j LOG_DROP
iptables -A FORWARD -j LOG_DROP
###############################################################################
#NAT statique afin d’atteindre le reverse-proxy (virtual server)
#(sens aller-retour en une seule regle, car le module le permettant est active)
###############################################################################
iptables -t nat -A PREROUTING -p tcp --dport 80 -d 10.192.72.83 -i eth0 -j DNAT --to-dest 192.168.1.2
############################################################################
#NAT statique pour atteindre le site Web de la console d’administration (port 666) depuis
#le reseau de TCOM (uniquement pour la démo)
############################################################################
iptables -t nat -A PREROUTING -p tcp --dport 666 -d 10.192.72.83 -i eth0 -j DNAT --to 192.168.1.3:80
#########################################################################
#Activation du NAT dynamique (Masquerading) pour que les machines internes autorisee
#a sortir sur le reseau TCOM puissent le faire
#########################################################################
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
###########################
#Activation du routage
###########################
echo 1 > /proc/sys/net/ipv4/ip_forward
##########################
#Lancement du HIDS
##########################
prelude-lml -d
A.4.2 Configuration du sensor

Fichier de configuration situé à : /etc/prelude-sensors/sensors-default.conf
110


#
#
# message locally).
#
#
node-name = Firewall;
node-category =unknown;
#

#
# [Node Address]
address=192.168.1.1;
netmask=255.255.255.0;
category=ipv4-addr;
A.4.3 Configuration de la sonde HIDS

Fichier de configuration situé à : /etc/prelude-lml/prelude-lml.conf
##############################################
# Configuration for the Prelude LML Sensor #
##############################################
[Prelude LML]

# an UNIX socket.
#
#
# Configuration for the UDP message receiver.

# commented out by default since most people only want to
# monitor files.
#
# [Udp-Srvr]
#
111
# port = 514
# addr = 0.0.0.0
#
# Files to monitor
#
#fichier de recuperation des logs d’iptables
file = /var/log/syslog
#
# Specifies the maximum difference, in seconds, between
# the interval of two logfiles’ rotation. If this difference
# is reached, a high severity alert will be emited
#
rotation-interval = 3600
####################################
####################################
[SimpleMod]
ruleset=/etc/prelude-lml/ruleset/simple.rules;
# [Debug]
#
A.4.4 Configuration des règles à utiliser

Ce fichier se situe à : /etc/prelude-lml/ruleset/simple.rules
#
# Rule format :
#
# For more information about the fields described above and their meaning,
# please have a look to the IDMEF Draft located at :
#
# http://www.silicondefense.com/idwg/draft-ietf-idwg-idmef-xml-07.txt
#
# If one of the IDMEF field you wish to add information too isn’t covered in
# the rule language, please take the 5 minutes needed to implement a simple
# parsing function to the simple.c plugin distributed with Prelude LML.
#
#
# - regex:
# A PCRE regex that should be matched to trigger the alert.
#
# - class.name:
# The name of the alert, from one of the origins listed below.
#
# - class.origin:
# The source from which the name of the alert originates.
# Possible values are: unknown, bugtraqid, cve, vendor-specific. Default is unknown.
#
# - class.url:
# A URL at which the manager (or the human
# operator of the manager) can find additional information about the
# alert. The document pointed to by the URL may include an in-depth
# description of the attack, appropriate countermeasures, or other
# information deemed relevant by the vendor.
#
# - impact.severity:
# An estimate of the relative severity of the event.
# Possible values are: low, medium, high.
#
# - impact.completion:
# An indication of whether the analyzer believes the attempt that
# the event describes was successful or not.
112
# The permitted values are: failed, succeeded.

#
# - impact.type:
# The type of attempt represented by this event, in relatively broad categories.
# The permitted values are: admin, dos, file, recon, user, other.
#
# - impact.description:
# May contain a textual description of the impact, if the analyzer
# is able to provide additional details.
#
# - source.node.address.address:
# Address that issued the attack.
#
# - target.node.address.address:
# Address that has been attacked.
#
# - source.node.name,
# target.node.name:
# The name of the equipment. This information MUST be provided if no Address
# information is given.
#
# - source.node.category,
# target.node.category:
# The domain from which the name information was obtained.
# Possible values are: unknow, ads, afs, coda, dfs, dns, hosts, kerberos,
# nds, nis, nisplus, nt, wfw
#
# - source.node.location,
# target.node.location:
# The location of the equipment.
#
# - source.spoofed,
# target.decoy:
# An indication of wheter the source/target is a decoy.
# The permitted values are: unknown, yes, no.
#
# - source.interface,
# target.interface:
# May be used by a network-based analyzer with multiple interfaces to
# indicate which interfaces this source/target was seen on.
#
# - source.service.name,
# target.service.name:
# The name of the service. Whenever possible, the name from the IANA list
# of well-known ports SHOULD be used.
#
# - source.service.port,
# target.service.port:
# The port number being used.
#
# - source.service.protocol,
# target.service.protocol:
# The protocol being used.
#
# - source.service.portlist,
# target.service.portlist:
# A list of port numbers beeing used.
#
# - source.user.category,
# target.user.category:
# The type of user represented (unknown, application, os-device).
#
# - source.user.userid,
# target.user.userid:
# Create a new UserId inside an User object (that may contain several UserId).
#
# - source.user.userid.type,
# target.user.userid.type:
# The type of user information represented (current-user, original-user, target-user,
# user-privs, current-group, group-privs, other-privs).
#
# - source.user.userid.name,
# target.user.userid.name:
# A user or group name.
#
# - source.user.userid.number,
# target.user.userid.number:
# A user or group number.
113
include = netfilter.rules;
regex=session opened for user root; \

class.name=Root login; \
impact.completion = succeeded; \
impact.type = admin; \
impact.severity = medium
A.4.5 Configuration de la rotation des logs

Fichier permettant la configuration de logrotate, permettant la compression des fichiers de logs lors-
qu’une certaine taille a été atteinte. Fichier de configuration situé à : /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
#weekly
# keep 4 weeks worth of backlogs

rotate 4
# create new (empty) log files after rotating old ones

create
# uncomment this if you want your log files compressed

compress
# packages drop log rotation information into this directory

include /etc/logrotate.d
# no packages own wtmp, or btmp -- we’ll rotate them here

/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
# Log system (firewall)

/var/log/syslog {
rotate 3
size=2M
postrotate
endscript
}
/var/log/messages {
rotate 3
size=2M
postrotate
endscript
}
/var/log/kern.log {
rotate 3
size=2M
postrotate
endscript
}
/Var/log/btmp {
missingok
monthly
create 0664 root utmp
rotate 1
}
# system-specific logs may be configured here
114
A.5 Configuration de Piwi et du moteur de corrélation

# Database :
$conf{’dbtype’}=’mysql’; # mysql / Pg
$conf{’dbname’}=’prelude’;
$conf{’dbhost’}=’192.168.1.5’;
$conf{’dbport’}=3306; # default mysql port is 3306 / pgsql 5432
# $conf{’dboptions’}=’mysql_compression=1’;
$conf{’dblogin’}=’prelude’;
$conf{’dbpasswd’}=’prelude’;
# Other :
$conf{’debug’}=0; # Debug perl code onscreen (0 or 1)
$conf{’extension’}=’.pl’; # scripts file extension (.pl)
$conf{’refresh’}=600; # AlertList refresh in seconds (600)
$conf{’ettercap_fp_db’}=’./generated/DB/etter.passive.os.fp’;
$conf{’ettercap_mac_db’}=’./generated/DB/mac-fingerprints’;
$conf{’HostName_Lookup’}=1; # Host Name Resolution (0 or 1)
$conf{’GD_transparent’}=0; # Are graphs transparent ?
$conf{’GMTdiff’}=+1;
# default element number by page in Alert List

$conf{’nb_resbypage’}=30;
# default alert number by group in Alert List when grouping (0 to hide)
$conf{’nb_resbygroup’}=5;
# default elements listed in TopAttack*s pages
$conf{’nb_topattack*s’}=20;
$conf{’gs_path’}=’/usr/bin/gs’;
$conf{’default_backend’}=’PS’;
######################################################
# Configuration de la corrélation (SIMS orienté Web)
######################################################
#Sonde post-reverse-proxy
$conf{’postReverseProxyProbe’}= ’385765816040650089’;
#Sonde pre-reverse-proxy
$conf{’preReverseProxyProbe’}= ’944782906595286827’;
#Sonde hids Firewall

$conf{’fireWallHIDS’}= ’33683050190593131’;
#Sonde hids Reverse-proxy

$conf{’ReverseProxyHIDS’}= ’851681720858307043’;
#temps en seconde d’une durée max d’une session TCP: pour la création du contexte session TCP (en secondes)
$conf{’TcpSessionDuration’}= 10;
#port d’écoute du serveur Web

$conf{’portServeur’}= 80;
#IP du serveur Web

$conf{’ipServeur’}= ’192.168.1.4’;
#IP du reverse-proxy
$conf{’ipProxy’}= ’192.168.1.2’;
#fênetre de corrélation (en secondes) = de maintenant à N secondes dans le passé...

$conf{’fenetreCorrelation’}= 86400; #1 jour
#intervalle de temps de recherche entre les alarmes du NIDS post-reverse-proxy et les HIDS du sereur Web
$conf{’timeIntervalHidsNids’}=10;
#intervalle de temps de recherche d’une alarme identique post et pre-reverse-proxy pour retrouver l’IP réelle de l’attaquant
$conf{’timeIntervalFindingIP’}=10;
115

Projet de Dipl Ome: SIMS - Security Intrusion Management System (Orient e Web)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Projet de Dipl Ome: SIMS - Security Intrusion Management System (Orient e Web)

Uploaded by

Copyright:

Available Formats

Projet de Diplôme

SIMS - Security Intrusion Management System (orienté Web)

Auteur : Joël Winteregg

3 Étude et comparatif de reverse-proxys 17

4 Architecture retenue et mise en place 31

4.1 Définition de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Implémentation, installation et tests 68

7 Descriptif et utilisation de SEC 79

8 Panorama de l’offre actuelle 83

SIMS Security Management System

Proposé par : EIVD - institut TCOM - et l’EIG (projet CCTI)

1.1 Résumé du problème

1.2 Cahier des charges

I. Établissement d’un rapport détaillé concernant les points suivants :

1.3 Introduction au projet

Différentes étapes ont été nécessaires :

2.1.1 Méthodes de détection d’attaques

Snort offre la possibilité de travailler selon deux méthodes d’analyse du trafic :

Détection par signature

Détection par l’heuristique

2.1.2 Architecture distribuée

F IG . 2.1 – Architecture distribuée de Snort

Premier tiers - le tiers détecteur

Deuxième tiers - le tiers serveur

Troisième tiers - la console de l’analyste

2.1.3 Outils d’analyse et de gestion

IDS Policy Manager

2.2.1 Composants et architecture

La figure 2.2 présente l’architecture distribuée envisageable à l’aide de Prelude.

Libprelude (la bibliothèque Prelude)

Prelude-Nids (la sonde réseau)

Prelude-LML (la sonde locale)

Prelude-Manager (le contrôleur)

Prelude-Frontend (l’interface web)

2.3.1 Moteur d’analyse et banque de signatures

2.3.2 La console de l’analyste (frontends)

Étude et comparatif de reverse-proxys

Plusieurs modes de fonctionnements sont envisageables :

Squid offre les fonctionnalités suivantes :

Nous décompressons l’archive dans un répertoire (/usr/local/src) :

jo:/usr/local/src# tar -xvvzf squid-2.5.STABLE6.tar.gz

jo:/usr/local/src/squid-2.5.STABLE6# ./configure --prefix=/usr/local/squid \

Nous pouvons maintenant passer à la compilation et à l’installation :

cache_dir ufs /usr/local/squid/var/cache 100 16 256

#Section de configuration du reverse-proxy (httpd accelerator)

Nous pouvons maintenant lancer le reverse-proxy à l’aide de la commande suivante :

acl ClientOK src 10.192.73.0/23

acl ClientsOK src 10.192.73.0/23 10.192.63.0/16

acl ClientsOK src "/usr/local/squid/conditions/clientsOk"

acl monNet src 168.209.2.0/255.255.255.0

http_access deny monNet heureTravail

Filtrage des requêtes (http access)

acl bonneUrlAccueil url_regex -i securitystore/$ securitystore$

http_access allow bonneUrlAccueil

#deny all implicite !!!

Filtrage des réponses (http reply access)

3.1.5 Réécriture d’URL et HTTP redirect

– Filtre (remplacement de mots) le contenu de la réponse du serveur (fichiers texte et HTML) à

Pour ce faire, nous téléchargeons les sources sur : http ://mirror2.dansguardian.org/downloads/2/Stable/DansGuardian-

jo:/usr/local/src# tar -xvvzf DansGuardian-2.6.1-9.source.tar.gz

jo:/usr/local/src/DansGuardian-2.6.1-9.source# ./configure --runas_grp root --runas_usr root

Description des fichiers Emplacement

Nous pouvons maintenant passer à la compilation et à l’installation :

"<script.>.alert.*</script>"->""