Sims-webjwinteregg

Projet de Diplˆome SIMS - Security Intrusion Management System (orient´e Web)

Auteur : Jo¨el Winteregg Professeur : Stefano Ventura Assistant : Cyril Friche ´ ´ Ecole : Ecole d’ing´enieurs du Canton de Vaud Date : 16 d´ecembre 2004

Table des mati`eres 1

Introduction 1.1 R´esum´e du probl`eme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Introduction au projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

Snort VS Prelude 2.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 M´ethodes de d´etection d’attaques . . . . 2.1.2 Architecture distribu´ee . . . . . . . . . . 2.1.3 Outils d’analyse et de gestion . . . . . . 2.2 Prelude . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Composants et architecture . . . . . . . . 2.3 Comparatif . . . . . . . . . . . . . . . . . . . . 2.3.1 Moteur d’analyse et banque de signatures 2.3.2 La console de l’analyste (frontends) . . . 2.4 Conclusion . . . . . . . . . . . . . . . . . . . .

´ 3 Etude et comparatif de reverse-proxys 3.1 Squid . . . . . . . . . . . . . . . . . . . . 3.1.1 Fonctionnement . . . . . . . . . . . 3.1.2 Caract´eristiques . . . . . . . . . . . 3.1.3 Installation . . . . . . . . . . . . . 3.1.4 Configuration . . . . . . . . . . . . 3.1.5 R´ee´ criture d’URL et HTTP redirect 3.2 DansGuardian . . . . . . . . . . . . . . . . 3.2.1 Caract´eristiques . . . . . . . . . . . 3.2.2 Installation . . . . . . . . . . . . . 3.2.3 Architecture . . . . . . . . . . . . . 3.2.4 Configuration . . . . . . . . . . . . 3.3 Conclusion . . . . . . . . . . . . . . . . . 4

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

4 4 4 6

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

8 8 8 9 11 12 12 15 15 16 16

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

17 17 18 18 19 19 23 24 24 25 25 26 29

Architecture retenue et mise en place

31

1

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

4.1 4.2

. . . . . . . . . . . . . . .

31 35 38 40 40 40 41 42 43 43 44 45 45 47 48

Corr´elation 5.1 D´efinition et principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Mais qu’apportera concr`etement la corr´elation ? . . . . . . . . . . . . . . . . . . ´ enements d´eclencheurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Ev´ 5.3 Corr´elation temps r´eel VS corr´elation a` post´eriori . . . . . . . . . . . . . . . . . . . . . 5.4 Mise en place des contextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Contextes de sessions TCP communes . . . . . . . . . . . . . . . . . . . . . . . 5.5 Sc´enarii d’investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Possibilit´es et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Diminution des faux positifs par analyse des requˆetes - r´eponses et du status du serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 Trac¸abilit´e des comportements a` risque . . . . . . . . . . . . . . . . . . . . . . 5.6 Mise en place de NTP (Network Time Protocol) . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Installation Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Installation Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50 50 51 51 52 53 55 56 60 60

Impl´ementation, installation et tests 6.1 Watchdog de contrˆole d’´etat du/des serveur(s) Web 6.1.1 D´etermination de l’´etat du service Web . . 6.1.2 Installation . . . . . . . . . . . . . . . . . 6.1.3 Configuration . . . . . . . . . . . . . . . . 6.2 Algorithme de corr´elation et site Web (frontend) . . 6.2.1 Choix du langage et du frontend hˆote . . . ´ 6.2.2 Etude de l’interfac¸age avec SEC . . . . . . 6.2.3 Architecture logiciel . . . . . . . . . . . .

68 68 68 69 69 70 70 70 71

4.3 4.4

4.5

4.6

5

6

D´efinition de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modification du code source de Dansguardian pour le contrˆole des donn´ee POST´ee 4.2.1 Installation et configuration de DansguardianSims . . . . . . . . . . . . . Installation des NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mise en place du reverse-proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Installation de l’HIDS sur le reverse-proxy . . . . . . . . . . . . . . . . . 4.4.2 Cr´eation d’une blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Pattern matching de Prelude-lml pour DansguardianSims . . . . . . . . . . Mise en place de la sonde HIDS de IIS . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Configuration du client Windows Snare et d’IIS . . . . . . . . . . . . . . . 4.5.2 Configuration du serveur syslog Linux . . . . . . . . . . . . . . . . . . . . 4.5.3 Pattern matching de Prelude-lml pour les logs de IIS . . . . . . . . . . . . Mise en place d’un firewall Iptables . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 R´ecup´eration des logs du firewall . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Gestion des logs syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

62 64 64 65 65

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

. . . .

73 74 75 76

7

Descriptif et utilisation de SEC 7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Fonctionnement par l’exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79 79 79 82

8

Panorama de l’offre actuelle 8.1 Open Source Security Information Management (OSSIM) 8.1.1 Description . . . . . . . . . . . . . . . . . . . . . 8.1.2 M´ethodes d’analyses utilis´ees . . . . . . . . . . . 8.2 Open security management . . . . . . . . . . . . . . . . . 8.2.1 Description . . . . . . . . . . . . . . . . . . . . .

83 83 83 84 86 87

6.3

9

6.2.4 Installation . . . . . . 6.2.5 Configuration . . . . . 6.2.6 Utilisation . . . . . . . Tests du moteur de corr´elation

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . . .

Conclusion

88

10 Remerciements et r´ef´erences 10.1 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 R´ef´erences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Annexes A.1 Planning et coˆut horaire . . . . . . . . . . . . . . . . A.2 Fichiers de configuration des sondes du reverse-proxy A.2.1 Configuration du sensor . . . . . . . . . . . A.2.2 Configuration de la sonde HIDS . . . . . . . A.2.3 NIDS pre-reverse-proxy . . . . . . . . . . . A.3 Configuration de la sonde post-reverse-proxy . . . . A.3.1 Configuration de la sonde NIDS . . . . . . . A.4 Configuration du firewall . . . . . . . . . . . . . . . A.4.1 Script d’´etablissement des r`egles du firewall . A.4.2 Configuration du sensor . . . . . . . . . . . A.4.3 Configuration de la sonde HIDS . . . . . . . A.4.4 Configuration des r`egles a` utiliser . . . . . . A.4.5 Configuration de la rotation des logs . . . . . A.5 Configuration de Piwi et du moteur de corr´elation . .

3

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

90 90 90 93 93 94 94 95 100 104 105 109 109 110 111 112 114 115

Chapitre 1

Introduction SIMS Security Management System Propos´e par : EIVD - institut TCOM - et l’EIG (projet CCTI)

1.1

R´esum´e du probl`eme

La gestion de la s´ecurit´e est devenue indispensable au mˆeme titre que la gestion du r´eseau lui-mˆeme. On peut mˆeme pr´etendre que la gestion de la s´ecurit´e est d´esormais le souci majeur du gestionnaire du r´eseau de l’entreprise. Ce projet va se focaliser sur le d´eveloppement d’un gestionnaire (Manager) de s´ecurit´e appel´e SIMS (Security Intrusion Management System) disposant d’agents intelligents ouverts avec des interfaces SNMPv.31 ou IDMEF22 . SIMS est sp´ecialis´e dans le domaine de l’analyse des tentatives d’intrusions d´etect´ees par des platesformes de type Firewall et IDS (Intrusion Detection System). L’objectif premier de ce travail est d’´etudier et de r´ealiser une plate-forme de gestion des intrusions bas´ee sur une corr´elation de diff´erents e´ v´enements et logs et permettant de d´etecter des attaques en temps r´eel.

1.2

Cahier des charges

´ I. Etablissement d’un rapport d´etaill´e concernant les points suivants : 1 2

Simple Network Management Protocol version 3 Intrusion Detection Message Exchange Format

4

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– D´efinition des principaux domaines de la gestion de la s´ecurit´e et br`eve pr´esentation des principaux standards existant dans ce domaine. Une attention particuli`ere sera port´ee sur l’Intrusion Management. ´ approfondie des diff´erentes intrusions r´eseau et attaques WEB. Il s’agit de r´ediger un docu– Etude ment ”state of the art” pr´esentant les principales attaques au niveau 2, 3 et 3 du mod`ele OSI, ainsi que les attaques de niveau applicatif. Les serveurs WEB, ainsi que les applications s’ex´ecutant sur ces dernier, feront l’objet d’une attention particuli`ere. – D´eveloppement d’un laboratoire et banc de test permettant de mettre en e´ vidence les strat´egies et m´ecanismes de d´efense contre les attaques WEB. Ce laboratoire sera bas´e sur le d´eploiement 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, d´eveloppement de Tissot, etc...). ´ – Etude et e´ valuation des principales solutions et plates-formes d’Intrusion Management (OpenSource et produits propri´etaires) disponibles sur le march´e. ´ – Evaluation des applications (aggregation, data fusion et corr´elation) d’analyse des intrusions disponibles sur les syst`emes retenus. ´ II. Etude et proposition d’une application de gestion des intrusions bas´ee sur une corr´elation de diff´erents e´ v´enements et logs permettant de d´etecter et pr´evenir des attaques. ´ Etude et r´ealisation d’une plate-forme SIMS bas´ee sur des sondes http (evtl. https) et diff´erents agents SIMS (reverse-proxy). Dans le cadre de cette e´ tude, il s’agit aussi de d´efinir un format g´en´eral des messages (IDMEF) et logs g´en´er´es 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 crypt´e des logs vers SIMS. III. R´ealisation d’un d´emonstrateur (applicatif SIMS) permettant d’illustrer les e´ tudes et r´ealisations selon le point II. Il s’agit de mettre sur pied un environnement de d´etection d’intrusions et de gestion de logs avec les outils e´ tudi´es et d´evelopp´es au point II. Les attaques pourraient eˆ tre simul´ees par les innombrables plugins que contient le scanner de vuln´erabilit´e Nessus. SIMS pourrait int´egrer des sc´enarii similaires a` ceux impl´ement´es par le travail de diplˆome 2003 de M. Saladino.

5

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Directives : Lors de l’´evaluation finale du travail de diplˆome, une importance toute particuli`ere sera donn´ee au respect des directives g´en´erales de l’EIVD ainsi qu’aux directives sp´ecifiques a` ce travail.

1.3

Introduction au projet

La s´ecurit´e des serveurs Web est critique car ceux-ci sont g´en´eralement accessibles publiquement sur Internet. La moindre vuln´erabilit´e a` ce niveau peut eˆ tre exploit´ee par n’importe quel cracker dans le monde. Aujourd’hui, de plus en plus de soci´et´es assurent leur image de marque via un portail Web. Celui-ci devient alors la colonne vert´ebrale du marketing et des ventes de plus en plus d’entreprises. Ceci explique donc la mont´ee en fl`eche des attaques Web. Ce projet proposera une architecture d’entreprise s´ecuris´ee permettant l’int´egration d’un serveur Web. Toute l’attention sera port´ee sur celui-ci puisque ce projet a pour souhait de proposer des solutions pour le management de la s´ecurit´e des serveurs Web. Diff´erentes e´ tapes ont e´ t´e n´ecessaires : – Petit comparatif Snort3 - Prelude-IDS4 – Recherche d’un reverse-proxy (premi`ere protection du serveur Web) – Mise en place d’une architecture s´ecuris´ee 3 4

Sonde r´eseau Open Source IDS hybride (HIDS et NIDS) centralis´e

6

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– D´eployement d’IDS – Analyse et proposition de m´ethodes de corr´elation permettant une bonne gestion de la s´ecurit´e – Impl´ementation d’un moteur de corr´elation

7

Chapitre 2

Snort VS Prelude Ce chapitre abordera les outils disponibles avec Snort ainsi que les fonctionnalit´es offertes par Prelude, afin d’en faire le comparatif et la distinction. Le projet de semestre SIMS orient´e Web contenait une introduction aux IDS qui d´etaillait les modes de fonctionnements et les fonctions offertes par la sonde r´eseau Snort, alors que les outils d’analyses disponibles avec celle-ci n’y e´ taient pas d´ecrits.

2.1

Snort

De simple outil de gestion de r´eseau, Snort est devenu un syst`eme de d´etection d’intrusion open source distribu´e 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 r´eseau. Snort peut eˆ tre utilis´e comme mouchard (sniffer), enregistreur de paquets ou syst`eme de d´etection d’intrusion r´eseau. Les NIDS1 , semblent au premier abord, particuli`erement int´eressants, mais il ne s’agit, en r´ealit´e, que d’une version am´elior´ee des sniffers. En mode d´etecteur d’intrusion, il permet d’´ecouter le trafic r´eseau sur lequel il est connect´e (sniffer) et de l’analyer, afin d’identifier des informations potentiellement dangereuses (tentatives d’attaques).

2.1.1

M´ethodes de d´etection d’attaques

Snort offre la possibilit´e de travailler selon deux m´ethodes 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, d´etecteur d’intrusion r´eseau Syntaxe d´ecrite dans le rapport de travail de semestre 3 Statistical Packet Anomaly Detection Engine 2

8

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

D´etection par signature Il s’agit du moyen le plus efficace aujourd’hui. Cette d´etection repose sur le principe que le trafic r´eseau anormal ou malveillant reproduit un mod`ele sp´ecifique, ce qui n’est pas le cas du trafic normal ou b´enin. Le trafic malveillant se distingue au niveau de sa structure et de son contenu, c’est pourquoi il est possible de cr´eer une signature d’attaque a` partir de laquelle il pourra eˆ tre reconnu. Dans Snort, une signature de trafic malveillant permet de cr´eer une r`egle que l’on peut charger dans le moteur de d´etection du d´etecteur. D´etection par l’heuristique La d´etection par signature est tr`es efficace pour identifier du trafic suspect, mais ce type de d´etection n’est malheureusement pas efficace a` 100%. Dans certains cas, le trafic peut se r´ev´eler dangereux sans exposer de signature particuli`ere. La communaut´e Snort a donc d´evelopp´e le module SPADE pour d´etecter le trafic suspect ne correspondant a` aucune signature. SPADE observe le trafic r´eseau et construit une table qui refl`ete le trafic normal. La table contient des donn´ees 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 r´ecup´er´e par SPADE se voit attribuer un num´ero bas´e sur la fr´equence a` laquelle il apparaˆıt dans la table. Plus le paquet est rare, plus son num´ero est grand. Lorsqu’un seuil configur´e est atteint, une alerte est g´en´er´ee. Supposons que vous vouliez configurer SPADE pour qu’il prot`ege un serveur Web. Vous d´eployez Snort avec SPADE activ´e sur un segment r´eseau connect´e a` Internet. SPADE construit une table pour mod´eliser le trafic entrant (principalement des connexions TCP vers les ports 80 et 443). Une fois que la table est construite, les requˆetes TCP sur les ports 80 et 443 sont consid´er´ees comme du ”trafic normal” et rec¸oivent un petit num´ero. Si un attaquant tente de sonder le serveur Web pour trouver des services sur des ports diff´erents, SPADE attribuera un num´ero e´ lev´e a` ce trafic puisqu’il est rare et inhabituel sur ce serveur particulier. Si des tentatives sont r´ealis´ees sur des ports inhabituels au-del`a d’un certain seuil pr´ed´efini, SPADE g´en´erera une alerte. Cette technique est efficace pour d´etecter les op´erations r´ealis´ees par des crackers qui esp`erent se fondre dans la masses du trafic normal.

2.1.2

Architecture distribu´ee

Snort propose ensuite une architecture distribu´ee permettant aux sondes d’envoyer leurs alarmes dans une base de donn´ee commune qui sera ensuite analys´ee par une application Web. Ceci permettra a` l’ing´enieur syst`eme de monitorer l’´evolution des attaques via un browser Web. L’architecture 3-tiers d´ecrite ci-dessus est pr´esent´ee sur la figure 2.1.

9

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 2.1 – Architecture distribu´ee de Snort Premier tiers - le tiers d´etecteur L’application Snort, a` proprement parler, s’ex´ecute sur le d´etecteur. Elle est charg´ee d’interpr´eter la nature des paquets ”renifl´es” et de transmettre les alertes a` la base de donn´ee. Les d´etecteurs doivent eˆ tre plac´es sur les segments de r´eseau a` prot´eger, c’est pourquoi la s´ecurit´e est primordiale. Sur le d´etecteur, seul Snort et les applications associ´ees doivent eˆ tre ex´ecut´es. Cette configuration se justifie pour des raisons li´ees, a` la fois aux performances et a` la s´ecurit´e. Les IDS sont des cibles tr`es tentantes pour les crackers et il est pr´ef´erable d’´eviter d’ex´ecuter sur le d´etecteur des applications susceptibles d’ouvrir une br`eche dans la s´ecurit´e. Le d´etecteur doit eˆ tre e´ quip´e de deux cartes r´eseau : la premi`ere pour l’interface de la fonction sniffer et l’autre pour l’interface de gestion. L’id´ee consiste a` avoir un r´eseau s´epar´e pour la gestion et de traiter tous les paquets entrant (surveill´es) avec une interface et toutes les alertes sortantes avec l’autre. L’interface de la fonction sniffer ne doit pas poss´eder 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´ l´ements de 4

Une interface est incapable d’´emettre des paquets lorsqu’elle n’a pas d’adresse IP (0.0.0.0)

10

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

l’architecture de Snort. C’est donc pour cela qu’une adresse IP lui sera assign´e. Elle nous permettra, entre autre, de r´egler Snort en ajoutant, en soustrayant ou en modifiant les r`egles et la configuration des pr´eprocesseurs. Deuxi`eme tiers - le tiers serveur Le deuxi`eme tiers, le tiers serveur, r´ecup`ere les donn´ees d’alertes aupr`es des d´etecteurs et les pr´esente dans un format exploitable par l’utilisateur. Ces donn´ees sont enregistr´ees par Snort dans une base de donn´ees relationnelle. Cette base de donn´ees n’est pas obligatoire : les alertes peuvent eˆ tre enregistr´ees par d’autres moyens, tel que syslog. Le tiers serveur prend aussi en charge une interface graphique qui pr´esente les donn´ees dans un format exploitable par l’utilisateur. Plusieurs interfaces graphiques sont dipsonibles avec Snort, y compris demarc, snortsnar, snortdb et l’application ACID5 . Troisi`eme tiers - la console de l’analyste C’est dans le troisi`eme tiers que sont pr´esent´ees les donn´ees a` l’analyste. La console exige uniquement une machine d´edi´ee, e´ quip´ee d’un navigateur Web compatible SSL. ACID fonctionnne bien avec Internet Explorer, Mozilla, Netscape et la plupart des autres navigateurs. Il est pr´ef´erable de d´edier une machine a` la console pour en contrˆoler l’acc`es physique et pour empˆecher les autres applications d’interf´erer avec le syst`eme de d´etection d’intrusion.

2.1.3

Outils d’analyse et de gestion

Snort offre ensuite plusieurs outils de gestion pour son architecture distribu´ee, dont : – ACID (Analysis Console for Intrusin Database), application serveur permettant a` l’ing´enieur syst`eme d’interroger et d’analyser la base de donn´ees contenant la liste des attaques d´etect´ees par les diff´erentes sondes. – IDS Policy Manager, application Windows 2000/XP servant a` g´erer a` distance les diff´erents d´etecteurs Snort. ACID ACID est le principal outil pour exploiter et pour g´erer les donn´ees d’intrusion rassembl´ees par Snort. Il pr´esente les donn´ees d’alerte et d’intrusion de mani`ere a` clarifier les donn´ees brutes e´ mises par Snort. Les donn´ees sont organis´ees de fac¸on logique pour simplifier la prise rapide de d´ecision. De plus, chaque signature d’attaque est associ´ee a` un lien Internet qui permettra a` l’analyste de trouver les causes de l’intrusion. 5

application d´ecirte dans la section 2.1.3

11

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

IDS Policy Manager Cette application6 permet de modifier les param`etres des fichiers de configuration et les r`egles (ajout, supression, modification) des diff´erentes sondes du r´eseau. Elle est capable d’atteindre les param`etres suivants d’une sonde : – variable r´eseau – classifications des r`egles – r´eglage des pr´eprocesseurs – modules de sortie – param`etre du syst`eme de r`egles Ces param`etres sont stock´es dans ce que l’on appelle une ”politique”. Ces politiques peuvent eˆ tre diff´erentes en fonction de l’emplacement de la sonde. Il est donc facile, a` l’aide de cette notion de politique, de changer la configuration globale des sondes. Tous les e´ changes d’informations entre cette application et les sondes sont crpyt´es a` l’aide du paquetage SCP inclus dans Putty.

2.2

Prelude

Prelude-IDS est un syst`eme de d´etection d’intrusions et d’anomalies distribu´e sous licence GPL7 . La d´etection d’intrusion est r´ealis´ee par l’analyse du trafic r´eseau et l’utilisation de signatures d’´ev`enements hostiles (NIDS) ou par l’analyse, en continu, de fichiers de journalisation (HIDS). L’architecture de Prelude est modulaire8 , distribu´ee9 et s´ecuris´ee10 . Les sondes (r´eseaux comme locales) n’effectuent que les op´erations de surveillance et de g´en´eration 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 pr´esente l’architecture distribu´ee envisageable a` l’aide de Prelude. Libprelude (la biblioth`eque Prelude) La biblioth`eque libprelude a e´ t´e cr´ee´ e dans le but de fournir une interface unique et standard de communication entre les diff´erents e´ l´ements du syst`eme de d´etection. Cette biblioth`eque est, bien sˆur, utilis´ee par 6

Disponible uniquement pour Windows 2000/XP sur : http ://activeworx.com/download/index.htm General Public License 8 Il est possible d’int´egrer ou d´evelopper de nouvelles fonctionnalit´es grˆace 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 7

12

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 2.2 – Architecture distribu´ee de Prelude (source : Projet SIMS 2003, Patrick Saladino) tous les modules de Prelude et peut aussi eˆ tre int´egr´ee a` d’autres produits, afin de leur assurer une compatibilit´e avec ce syst`eme de d´etection d’intrusions. Pour des raisons de compatibilit´e et d’´evolutivit´e, le format de messages IDMEF a e´ t´e retenu. C’est cette biblioth`eque qui offre, entre autres, les possibilit´es d’authentification mutuelle et de chiffrement de la communication. Prelude-Nids (la sonde r´eseau) Cette sonde prend en charge l’analyse en temps r´eel du trafic r´eseau. Elle est construite au-dessus de la biblioth`eque libprelude et fournit : – Un moteur de gestion de signatures g´en´erique, actuellement compatible avec les signatures Snort mais pouvant eˆ tre e´ tendu par l’ajout de nouveaux parsers (analyseurs syntaxiques) de r`egles. – Des modules sp´ecialis´es par protocole. Par exemple, un plugin est d´edi´e aux protocoles RPC et permet l’analyse fine de ce type de connexions.

13

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– Des modules sp´ecialis´es dans la d´etection non bas´ee sur les signatures, comme la reconnaissance des scans et la normalisation des chaˆınes de caract`eres de requˆetes HTTP. – Les sondes r´eseaux peuvent aussi prendre en charge la d´efragmentation IP et le r´eassemblage des flux TCP de fac¸on a` rendre une sonde r´eseau Prelude moins vuln´erable aux attaques de type Stick ou Snot11 . Prelude-LML (la sonde locale) Cette sonde prend en charge la remont´ee d’alertes d´etect´ees localement sur l’hˆote. Cette d´etection est bas´ee sur l’application de r`egles construites autour d’expressions r´eguli`eres compatibles Perl (PCRE) a` des objets12 . Une sonde hˆote Prelude peut aussi recevoir les logs de machines distantes, de routeurs et de firewalls grˆace a` son serveur Syslog int´egr´e. Prelude-Manager (le contrˆoleur) Prelude-manager centralise les messages des sondes r´eseaux 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 contrˆoleur relais va assurer le routage vers un contrˆoleur maˆıtre des alertes provenant des sondes qui lui sont rattach´ees. – Celle de maˆıtre : un tel contrˆoleur va assurer la r´eception 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 PostgreSQL). Il est possible d’´etendre les capacit´es d’un contrˆoleur a` l’aide de plugins, en autorisant, par exemple, le traitement de messages en provenance de composants autres que Prelude. Un contrˆoleur Prelude peut ainsi centraliser la remont´ee d’alarmes en provenance de sondes Snort. Prelude-Frontend (l’interface web) Prelude-Frontend est l’interface de visualisation des alertes. Il est actuellement propos´e deux interfaces, l’une d´evelopp´ee en PHP et l’autre en Perl : 1. Prelude-PHP-Frontend est l’interface propos´ee sur le site officiel de Prelude-IDS14 . Elle est compos´ee de scripts PHP et destin´ee a` eˆ tre install´ee sur un serveur web ind´ependamment des autres composants Prelude. Cela signifie que l’installation pr´ealable de la librairie libprelude est inutile, mais que par contre celle d’un serveur web supportant PHP4 l’est. 11 Ces deux techniques sont utilis´ees pour tromper le moteur de l’IDS en fragmentant l’attaque dans plusieurs paquets, ceci en esp´erant que la reconstruction se fera apr`es qu’ils aient travers´es l’IDS 12 fichiers de journalisation et/ou d’application (logs) 13 Syst`eme de gestion de base de donn´ees 14 http ://www.prelude-ids.org

14

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

2. Prelude-Perl-Frontend est une interface issue d’un projet intitul´e ”Le Routier15 ”. Elle n´ecessite, bien e´ videmment, l’installation d’un serveur web supportant Perl.

2.3

Comparatif

Dans le cadre du projet, ces deux outils sont tr`es proches. Ce sont tous les deux des outils libres. Les projets dont ils sont les r´esultats sont tr`es actifs, aussi bien dans le d´eveloppement que dans la mise a` jour des attaques. Quelques avantages de Snort sur Prelude-IDS sont sa popularit´e et sa disponibilit´e 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 donn´ees des signatures d’attaque de Snort, explique peut eˆ tre sa plus grande popularit´e. Prelude-IDS est de plus en plus connu dans le monde des professionnels de la s´ecurit´e et a l’avantage sur Snort de ne pas eˆ tre un NIDS pur puisqu’il int`egre des fonctionnalit´es NIDS et HIDS17 . De plus, il est capable de r´ecup´erer les fichiers de logs (syslog) d’un bon nombre d’´equipement r´eseaux actifs18 afin de les analyser sur la sonde sp´ecialis´ee a` cet effet (Prelude-LML) et d’envoyer les alertes a` sa base de donn´ee centralis´ee pour que l’analyste r´eseau 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 mˆeme type, nous nous retrouvons alors avec aproximativement le mˆeme nombre d’alertes (Prelude ayant ses propres r`egles, il est normal qu’il en trouve un peu plus que Snort). Prelude-NIDS comme Snort offrent la possibilit´e d’archiver les payloads. Prelude-IDS a l’avantage d’ˆetre tr`es modulaire de par son architecture client-serveur. Un manager peut g´erer plusieurs sondes et une sonde peut envoyer ses alertes a` plusieurs managers. Le filtrage au niveau de la sonde pour savoir a` quel manager est envoy´ee telle alerte ou telle autre n’est pas encore 15

http ://www.leroutier.net/Projects/PreludeIDS La liste compl`ete des plateformes compatibles est disponible sur : http ://www.snort.org/about.html 17 Host Intrusion Detection System, int´egr´e dans Preldue comme une fonction de r´ecup´eration des logs Syslog et de leur analyse 18 Routeurs, Firewall, etc.. 16

15

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

op´erationnel. De plus, Prelude-IDS n’offre aucune sonde r´eseau permettant la d´etection d’attaques par l’heuristique comme le permet Snort via le module SPADE. Grˆace a` l’architecture modulaire et standardis´ee de Prelude-IDS, il suffirait d’inclure une sonde Snort dans l’architecture de Prelude afin d’obtenir une d´etection par l’heuristique sur le ou les segments voulus. Les deux produits nous fournissent des alertes bien d´etaill´ees qui permettent de connaˆıtre la source et la destination d’une attaque, le type d’attaque, un classement de s´ev´erit´e de l’alerte ou encore un lien vers un bulletin d’alerte officiel. Dans les deux outils, il est int´eressant de constater la pr´esence de niveaux d’alertes permettant d’en d´eduire du premier coup d’oeil la dangerosit´e. 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’´ecarter plus facilement les faux-positifs.

2.3.2

La console de l’analyste (frontends)

Les plus grandes diff´erences entres les 2 outils se trouvent au niveau des frontends. Sous Prelude, il n’y a pas vraiment de frontends officiel. Le premier fut d´evelopp´e en PHP, puis quelques semaines apr`es sa parution, un nouveau frontend en perl arrivait a` maturit´e 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 d´edi´e a` Snort : ACID. Snort compte lui aussi plusieurs interfaces et sa popularit´e fait qu’il est maintenant int´egr´e dans des outils comme webmin. Cependant, la r´ef´erence reste ACID. Le classement et regroupement des alertes sont dans les deux cas possibles suivant des crit`eres communs basiques pour les deux IDS (mˆeme adresse IP source, mˆeme type d’attaque, mˆeme niveau d’alerte, ...). Pour des filtrages plus d´etaill´es, la logique est diff´erente dans les deux outils. Le frontend-perl de Prelude-IDS propose une rubrique Filter Factory qui permet de cr´eer 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 r´eseau.

2.4

Conclusion

Dans le cadre de ce projet, nous pr´ef´ererons donc Prelude-IDS a` Snort, puisque celui-ci int`egre directement deux fonctionnalit´es (NIDS et HIDS), tr`es int´eressantes pour la suite de cette e´ tude. De plus, la premi`ere partie de ce projet effectu´ee par Monsieur Saladino avait d´ej`a men´e a` la conclusion de l’utilisation de ce produit Open Source d´ej`a bien abouti.

16

Chapitre 3

´ Etude et comparatif de reverse-proxys Afin de d´eterminer quel reverse-proxy utiliser dans l’architecture de SIMS orient´ee Web, nous allons en e´ tudier plusieurs. Nous dresserons un petit comparatif entre diff´erents produits afin de s´electionner le produit correspondant a` nos attentes. Nous nous pencherons tout particuli`erement sur les possibilit´es de configuration offertes ainsi que sur les informations (logs, etc...) des tentatives d’attaques bloqu´ees. Ces derni`eres sont un point crucial dans le projet puisque nous recherchons un produit qui nous fournisse un grand nombre d’informations pertinantes, permettant une corr´elation avec celles d’une sonde r´eseau.

3.1

Squid

Squid est un proxy/reverse-proxy Open Source, servant en premier lieu d’acc´el´erateur Web (cache). Configur´e en proxy (dans une entreprise par exemple), il a pour but de r´eduire l’utilisation d’une connexion a` Internet. En effet, lorsqu’un grand r´eseau LAN1 est connect´e sur Internet et qu’un grand nombre de personnes surfent sur le Web, il y a de fortes chances que plusieurs acc`es sur un mˆeme 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 acc`es a` un mˆeme site. Il s’agira donc de tout contenu non dynamique comme des pages html, des images, etc... Il va ensuite fournir aux clients voulant acc´eder a` des pages d´ej`a visit´ees, ce qu’il a enregistr´e en cache plutˆot que d’envoyer une requˆete au serveur Web distant. Squid configur´e en reverse-proxy a pour but de r´eduire 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 tˆaches de g´en´eration de pages html (pages dynamiques du serveur). L’ajout d’un reverse-proxy dans une architecture r´eseau permettra donc de r´eduire le nombre de serveurs puisqu’une partie de leurs tˆaches seront prise en charge par le reverse-proxy. Des fonctions de filtrage et de contrˆoles d’acc`es sont e´ galement disponibles, ce qui permettra dans le cas d’un proxy de contrˆoler et restreindre l’acc`es a` certains sites et dans le cas d’un reverse-proxy, d’accroˆıtre 1

Local Area Network, r´eseau d’entreprise

17

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

la s´ecurit´e. 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 utilis´e pour mettre en cache des pages Web statiques sur un r´eseau local. Comme expliqu´e pr´ec´edemment lorsqu’une page est r´eclam´ee une seconde fois par un client Web (browser2 ), celui-ci recevra les donn´ees du proxy local plutˆot que celle du serveur Web d’origine. Le browser du client devra explicitement envoyer ses requˆetes au proxy plutˆot qu’au serveur Web cible. C’est ensuite le proxy qui, lui mˆeme, e´ tablira cette connexion ou alors servira le client avec des donn´ees enregistr´ees dans son cache. Transparent Cache Un cache transparent a le mˆeme but qu’un proxy standard mais op`ere de mani`ere transparente. Le browser n’a pas besoin d’ˆetre explicitement configur´e pour passer par le proxy. Dans ce mode, le proxy intercepte le trafic r´eseau et retire le trafic HTTP (sur le port 80) du r´eseau. Si le contenu demand´e ne se trouve pas dans le cache du proxy, celui-ci relaiera (comme le ferait un routeur) la requˆete effectu´ee par le browser du client. Ce mode d’utilisation est surtout utilis´e par les ISP3 , puisqu’il ne requiert aucune configuration sp´ecifique du browser client. Reverse Proxy Cache Un reverse-proxy diff`ere des deux autres modes d’utilisation. Il se place dans l’architecture du serveur et non plus dans celle du client. Comme susmentionn´e, il a pour but de soulager les serveurs Web ainsi que de r´epartir la charge. De plus a` l’aide du filtrage de contenu, il permettra d’accroˆıtre la s´ecurit´e sur les serveurs Web. Les architectures envisageables ont e´ t´e discut´ees dans le chapitre 4.1 (page 12) du projet de semestre, que je vous laisserai consulter pour plus d’informations.

3.1.2

Caract´eristiques

Squid offre les fonctionnalit´es suivantes : – Cache HTTP et FTP – Prend en charge les connexions s´ecuris´ees HTTPS (tr`es utile en configuration reverse-proxy) – Hi´erarchie de cache (`a l’aide d’´echanges d’informations entre proxys) – Contrˆole d’acc`es – Agent SNMP int´egr´e – Cache pour les DNS lookups La fonctionnalit´e la plus int´eressante dans le cadre de ce projet et celle de contrˆole d’acc`es, puisqu’elle nous permettrait d’´etablir des r`egles afin de filtrer les requˆetes consid´er´ees dangereuses. 2 3

au sens navigateur Web Internet Service Provider, fournisseurs d’acc`es Internet

18

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

3.1.3

Installation

Pour ce faire, nous t´el´echargeons 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 d´ecompressons l’archive dans un r´epertoire (/usr/local/src) : jo:/usr/local/src# tar -xvvzf squid-2.5.STABLE6.tar.gz

Et nous nous plac¸ons maintenant dans le r´epertoire 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 pr´ecisons le r´epertoire de destination de l’application ainsi que la langue utilis´ee par les pages d’erreurs retourn´ees par Squid. Voici une liste non exhaustive des options de compilation utilisables lors de la configuration : – Choix de la m´ethode d’allocation de la m´emoire pour le cache, activation des librairies e´ crites pas Doug Lea (–enable-dl-malloc) – Compilation interne de la librairie des expression r´eguli`eres (–enable-gnuregex). – Activation d’un agent SNMP (–enable-snmp). – Activation du contrˆole d’acc`es sur les adresses MAC (–enable-arp-acl) – Choix du protocole d’´echange de cache entre les proxys (–enable-cache-digests ou –enable-htcp) – Enregistrement de l’adresse source de chaque requˆete (–enable-forw-via-db) Pour plus de d´etails 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 install´e, 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 d´efauts sont comment´ees (`a l’aide du caract`ere #). Nous devons donc d´ecommenter tous les tags4 utiles et changer leurs valeurs si n´ecessaire. Voici donc ce que nous avons modifier : 4

directives de configuration

19

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

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 pr´eciser sur quel port Squid agira. cache dir Nous permet d’indiquer la m´emoire maximale du cache ainsi que son emplacement sur le disque. Il nous permet ensuite de donner le nombre maximal de r´epertoires et sous r´epertoires que Squid pourra cr´eer pour l’indexation des pages web. cache effective user et cache effective group Nous permettent de pr´eciser sous quel user Squid s’ex´ecutera. visible hostname Pr´ecise le nom du proxy (qui sera donn´e dans les pages d’erreurs). httpd accel port Nous permet de pr´eciser sur quel port le reverse-proxy agira. httpd accel host Nous permet de pr´eciser 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 mˆeme temps). Il faut ensuite prendre garde a` mettre les droits suffisants sur le r´epertoire de logs, afin que l’utilisateur sous lequel s’ex´ecute Squid puisse y acc´eder en lecture et en e´ criture. Nous pouvons ensuite lancer la cr´eation 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 consid`erent un mode de fonctionnement en reverse-proxy.

20

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Le filtrage HTTP nous est offert par le biais du tag http access et http reply access qui sont des op´erateurs ACL5 . Le premier permet d’effectuer le filtrage de la requˆete d’un client, alors que le second permet le filtrage de la r´eponse du serveur. Le filtrage est possible sur les param`etres suivants (type ACL) : – Adresse IP source / destination – Domaine source / destination – Expression r´eguli`ere : – Sur une URL enti`ere (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) – M´ethode (POST, GET) – Le type du browser client – Username / password lors de proc´edure d’authentification – Communaut´e SNMP Il suffit de d´efinir un ACL, (s’apparentant a` la d´eclaration d’un type dans un langage de programmation) en pr´ecisant sur quel param`etre ci-dessus s’applique la d´eclaration (donc le type de l’ACL). Ensuite nous pouvons d´efinir si l’ACL est autoris´e ou non via un op´erateur (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 r´eseau TCOM6 auront le droit d’acc´eder le serveur Web, alors que tous les autres seront rejet´es. Il est bien de noter que Squid fonctionne en whitelist par d´efaut et que la ligne ”http acces deny all” est implicite a` la fin de la configuration des r`egles d’acc`es. Celle-ci indique bien un fonctionnement en whitelist puisque tous les acc`es sont refus´es, sauf ceux explicitement pr´ecis´e a` l’aide d’une r`egle ”allow”. Il est tout de mˆeme judicieux de l’ajouter a` la fin de la d´efinition des r`egles, afin que l’administrateur non averti ne se trompe pas. Il est aussi possible de travailler en blacklist en ajoutant simplement la r`egle suivante a` la fin de la configuration des acc`es : http acces allow all. Celle-ci changera donc le fonctionnement par d´efaut et des r`egles ”deny” devront eˆ tre d´efinies afin de cr´eer la blacklist. Un ACL permet la d´efinition de plusieurs conditions d’un mˆeme param`etre sur une mˆeme ligne. Il est alors possible de condenser l’´ecriture des conditions en s´eparant celles-ci par un espace, qui sera interpr´et´e comme un OU. En voici un petit exemple : 5 6

Access Control List R´eseau du d´epartement de t´el´ecommunication de l’EIVD

21

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

acl ClientsOK src 10.192.73.0/23 10.192.63.0/16 http_acces allow ClientsOk

Ceci signifie donc que les deux sous r´eseaux d´efinis ci-dessus auront acc`es au serveur Web. Squid contrˆolera que la source de la requˆete appartienne au sous-r´eseau 10.192.73.0/23 ou 10.192.63.0/16. Afin de simplifier la lecture du fichier de configuration il est possible de d´efinir les conditions dans un fichier externe. Si dans l’exemple ci-dessus, la liste des adresses autoris´ee a` se connecter au serveur Web est d´efinie dans le fichier /usr/local/squid/conditions/clientsOk (une condition par ligne), il suffira de charger la r`egle de la fac¸on suivante : acl ClientsOK src "/usr/local/squid/conditions/clientsOk" http_acces allow ClientsOk

De la mˆeme mani`ere que pour les conditions, il est possible de condenser l’´ecriture avec les op´erateurs ACL (tag http access dans ce cas) et de cr´eer une logique combinatoire afin de d´efinir une r`egle complexe. Il suffira de les s´eparer par un espace, qui signifiera que les deux conditions (ACL) doivent eˆ tre valides afin que la r`egle 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’acc´eder le serveur Web pendant les heures de travail, la connexion sera refus´ee puisque les deux conditions ACL s’appliqueront. Si par contre une machine de monNet tente d’acc´eder le serveur hors des heures de travail, la condition ”heureTravail” ne sera plus valide. Comme un ET logique est op´er´e entre les diff´erentes conditions, la r`egle ne sera pas appliqu´ee puisque l’une d’elle n’est pas valide. C’est ensuite les r`egles suivantes qui d´efiniront si un filtrage est op´er´e. 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 d´efinir des conditions complexes pour op´erer un filtrage pr´ecis. Pour plus de d´etails sur les diff´erents param`etres utilisables pour la d´eclaration 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 travaill´e avec l’op´erateur ACL ”http access”, mais il existe diff´erents types d’op´erateurs permettant la gestion des actions en fonction de la requˆete. Le lecteur int´eress´e pour se r´ef´erer a` la page suivante : http ://squid-docs.sourceforge.net/latest/book-full.html#AEN1831 pour de plus amples informations a` ce sujet.

22

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Filtrage des requˆetes (http access) Cette op´erateur d´ej`a grandement illustr´ee dans les exemples ci-dessus ne sera pas plus d´etaill´e ici. Nous allons par contre illustrer la configuration qu’il faudrait mettre en place afin que Squid agisse comme reverse-proxy sp´ecifique a` un site Web (comme le fait ProxyFilter7 ) : acl acl acl acl

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

http_access http_access http_access http_access

allow allow allow allow

bonneUrlAccueil bonneUrlLogin imagesOk cssOk

#deny all implicite !!!

Grˆace a` cette configuration, il sera possible d’acc´eder 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 (param`etres contenus dans un POST par exemple), ce qui ne nous permettra pas de filtrer les cas de SQLinjection, XSS, etc... ou toutes autres attaques effectu´ees via un param`etre non contenu dans l’URL (GET). Filtrage des r´eponses (http reply access) Cet op´erateur s’utilise exactement comme l’op´erateur de filtrage des requˆetes mais ne s’occupe que du filtrage des r´eponses fournies au client.

3.1.5

R´ee´ criture d’URL et HTTP redirect

Il est possible, a` l’aide d’un programme externe, de r´ee´ crire les URL a` l’aide d’expressions r´eguli`eres. Apache offre aussi cette opportunit´e comme la plupart des serveurs Web. Il est donc n´ecessaire de choisir si la r´ee´ criture se fera plutˆot sur le serveur Web ou le reverse-proxy. Elle permettra ainsi de cacher l’arborescence cr´ee sur le serveur ou de rediriger des requˆetes en fonction de la page demand´ee. Nous avons test´e Squirm (redirector Open Source pour Squid) disponible sur : http ://squirm.foote.com.au/ Il permet la r´ee´ criture des requˆetes e´ mises par les browser Web a` l’aide d’expressions r´eguli`eres. Il n’est malheureusement pas possible a` l’aide de ce module externe de r´ee´ crire les r´eponses du serveur Web. Il sera ainsi impossible de r´ee´ crire les r´eponses HTTP redirect8 e´ mises par le serveur Web. Celle-ci contiendra donc l’adresse IP du serveur Web lui-mˆeme, ce qui forcera le client a` essayer de se connecter 7

Reverse-proxy d´evelopp´e par Sylvain Tissot dans le cadre de son travail de diplˆome 2003 et e´ tudi´e dans le cadre du travail de semestre 8 R´eponse indiquant au client la nouvelle page a` charger

23

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

directement sur le serveur Web (sans passer par le reverse-proxy). Il faudra donc plutˆot r´ee´ crire l’entˆete HTTP directement sur le serveur Web afin d’op´erer 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 probl`emes.

3.2

DansGuardian

DansGuardian est un produit Open Source offrant des possibilit´es de filtrage de contenu. Il fonctionne sur les syst`emes 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’impl´emente aucune fonction de cache et n’est donc pas utilis´e comme acc´el´erateur de serveur Web. Son but premier est de prot´eger des utilisateurs (souvent des enfants) contre des contenus litigieux. Il s’agit donc plutˆot d’une utilisation en proxy et non en reverse-proxy. ´ Etant donn´e qu’aucune documentation pr´ecise sur Dansgusrdian n’est disponible sur Internet, nous avons d´ecid´e de le tester afin d’observer l’effet de la configuration sur les contenus trait´es ainsi que les possibilit´es offertes pour une configuration en reverse-proxy.

3.2.1

Caract´eristiques

– Filtre (remplacement de mots) le contenu de la r´eponse du serveur (fichiers texte et HTML) a` l’aide d’expressions r´eguli`eres – Possibilit´e d’assigner un popoids des mots afin de d´efinir si un filtrage a` lieu en fonction de leur nombre d’apparition dans un contenu HTML ou texte – Bloquage de r´eponse HTTP offert selon les type MIME retourn´e par le serveur – Bloquage de r´eponse HTTP offert selon l’URL demand´ee par un client a` l’aide d’expressions r´eguli`eres – Syntaxe de la blacklist d’URL compatible avec celle de Squid – Filtrage d’URL sur des requˆetes HTTPS – Log facile a` lire et configurable dans diff´erents formats – Possibilit´e de logger les usernames lors d’authentification HTTP – Possibilit´e de bloquer les uploads (uniquement suivant la taille d’un POST) – Possibilit´e de journaliser les sites qui auraient e´ t´e bloqu´es sans pour autant les bloquer – Les caract`eres Big5, Unicode et les caract`eres peuvent eˆ tre utilis´es pour des recherches dans des contenu HTML – Supporte les fichiers compress´es

24

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

3.2.2

Installation

Pour ce faire, nous t´el´echargeons les sources sur : http ://mirror2.dansguardian.org/downloads/2/Stable/DansGuardian2.6.1-9.source.tar.gz Nous d´ecompressons l’archive dans un r´epertoire (/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 r´epertoire 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 proc´edons a` une configuration par d´efaut en ce qui concerne l’emplacement de tous les r´epertoires utiles a` Dansguardian. Nous pr´ecisons simplement sous quel utilisateur et quel groupe s’ex´ecutera Dansguardian (root dans notre cas, afin que l’application aie acc`es au port 80 de la machine). Pour plus de pr´ecisions sur les options de configuration vous pourrez consulter : http ://dansguardian.org/downloads/detailedinstallation2.html#installation La configuration ainsi faite placera les diff´erents fichiers de Dansguardian dans les r´epertoires suivants : Description des fichiers Les binaires Les fichiers de configuration Les scripts de d´emarrage Les fichiers perl permettant l’administration via un browser Web Les fichier de manuels Les journaux (logs) Le fichier indiquant le pid (Process ID, num´ero du processus Dansguardian)

Emplacement /etc/dansguardian /etc/dansguardian/ /etc/rc.d/init.d/ /home/httpd/cgi-bin/ /usr/man/ /var/log/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

Apr`es bien des essais et analyses a` l’aide d’Ethereal9 , nous nous sommes rendus compte qu’il n’´etait pas possible d’utiliser Dansguardian comme pi`ece 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 n´ecessaires pour leur affichage, ce qui provoquait une erreur dans le browser. Dansguardian travaille 9

analyseur r´eseau Open Source

25

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 3.1 – Architecture de Test (non-fonctionnelle) d’une mani`ere diff´erente qu’un serveur Web. La figure 3.2 illustre son fonctionnement qui implique l’adjonction 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 (Dansguardian), comme l’illustre la figure 3.3. Ces deux applicatifs s’ex´ecutent sur la mˆeme machine et utilisent la loopback pour communiquer.

F IG . 3.3 – Architecture retenue

3.2.4

Configuration

Maintenant que Dansguardian est install´e, et que son architecture est d´efinie, 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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# Adresse IP sur laquelle Dansguardian attend les requˆ etes filterip = 192.168.1.2 #Port sur lequel Dansguardiant attend les requˆ etes filterport = 80 # L’adresse IP du proxy ` a qui il transmettra les requˆ etes (apr` es 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 requˆetes sur le port 3128 de sa loopback, qui correspond au port d’´ecoute de Squid, qui les transmettra au serveur Web. Il est donc indispensable de modifer la configuration de Squid que nous avions pr´esent´e 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 requˆetes : http_port 127.0.0.1:3128

Il est maintenant possible de d´emarrer Dansguardian a` l’aide de la commande suivante : jo:/#dansguardian

Il est bien de noter que Squid doit eˆ tre d´emarr´e avant Dansguardian, puisque celui-ci ne d´emarrera pas tant qu’il ne pourra pas atteindre (connexion TCP) le proxy auquel il transmettra ses requˆetes. Filtrage Les termes bloquage et filtrage utilis´es dans la suite de ce document on une signification particuli`ere. Le terme bloquage indique un refus de transmission d’une requˆete client10 ou d’une r´eponse du serveur par Dansguardian. Le terme filtrage, indique quant a` lui que le corps11 de la r´eponse e´ mise par le serveur (faisant suite a` la requˆete d’un client) est contrˆol´ee et modifi´ee si n´ecessaire (selon le fichier de configuration contentregexplist mentionn´e ci-dessous). Param`etres configurables pour le filtrage dans le sens aller (requˆete vers le serveur) : – Sites entier interdits (bloqu´es) (fichier : bannedsitelist) – URL12 de sites interdits (bloqu´es) (fichier : bannedurllist, bannedregexpurllist) – Sites entier non filtr´es et non bloqu´es (dont le contenu aller-retour n’est pas contrˆol´e) (fichier : exceptionsitelist) 10

Indiqu´e au client par une page HTML ”AccAcc`esfus´e” Document HTML ou TXT 12 ”Sites entier interdits” bloque les acc`es au site entier alors que ce fichier de configuration offre la possibilit´e de bloquer une partie d’un site. 11

27

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– URL13 de sites non bloqu´es et non filtr´es (fichier : exceptionurllist) – Utilisateurs interdits (bloqu´es lors d’authentification HTTP) (fichier : banneduserlist) – Utilisateurs non filtr´es et non bloqu´es (lors d’authentification HTTP) (fichier :exceptionuserlist) – Adresses IP source (client Web) non autoris´ees (requˆete bloqu´ee) (fichier : bannediplist) – Adresses IP source (client Web) dont les paquets (aller-retour) ne sont pas filtr´es ni bloqu´es (fichier : exceptioniplist) Param`etres configurables pour le filtrage dans le sens retour (r´eponse du serveur) en fonction des entˆetes HTTP : – Bloquage de la r´eponse suivant le type MIME retourn´e par le serveur (fichier : bannedmimetypelist) – Bloquage de la r´eponse suivant l’extension du fichier demand´e par la requˆete (fichier : bannedextensionlist) Param`etres configurables pour le filtrage dans le sens retour (r´eponse du serveur) en fonction du corps des r´eponse HTTP : – Filtrage du corps de la r´eponse (remplacement de mots) a` l’aide d’expressions r´eguli`eres (fichier : contentregexplist) – Non bloquage des r´eponses contenant un des mots figurant dans le fichier exceptionphraselist (filtrage par remplacement de mots toujours actif) – Bloquage de r´eponses contenant un des mots figurant dans ce fichier (fichier : bannedphraselist) – PICS14 , permettant d’´etablir des r`egles de bloquage en fonction du contenu de l’entˆete html (httpequiv=”PICS-Label”) , permettant de d´ecrire le contenu de la page d’une mani`ere standardis´ee (fichier : pics) – Fichier permettant d’assigner un poids aux mots permettant ainsi d’´etablir des r`egles de filtrage en fonction de leur nombre d’apparition dans les r´eponses HTTP (fichier : weightedphraselist) L’utilisation d’expressions r´eguli`eres pour le filtrage de contenu, nous semble un grand atout pour ce produit, c’est donc pour cette raison que nous allons d´etailler 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 recherch´es dans les pages retourn´ees aux clients et remplac´es par le mot de remplacement correspondant a` celui trouv´e dans le corps de la page HTTP. Dans l’exemple ci-dessous, tous les popups javascript (alert) envoy´es aux clients seront retir´es et remplac´es par un commentaire HTML : 13

”Sites entier non filtr´e” autorise des acc`es au site entier alors que ce fichier de configuration offre la possibilit´e de ne pas filtrer et bloquer une partie d’un site. 14 http ://www.w3.org/PICS/

28

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

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

Il est important de noter que les r`egles introduites dans ce fichier ne contrˆole et remplacent en aucun cas des mots dans les entˆetes HTTP ou des param`etres POST´es par le clients. Ce type de filtrage n’a donc pas une grande utilit´e dans une configuration en reverse-proxy puisque ce que l’on ne cherche pas a` prot´eger un utilisateur mais le serveur Web et l’application serveur elle-mˆeme. Il peut tout de mˆeme avoir sa raison d’ˆetre 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

Synth`ese des diff´erents produits e´ tudi´es : Open Source

Fonctionnement Whitelist

Fonctionnement Blacklist

Syntaxe des r`egles

ProxyFilter Squid

X X

X X

X X

XML Expressions r´eguli`eres

Dansguardian

X

X

Expression r´eguli`eres Par interface graphique

AppShield

X

Filtrage de contenu HTML (r´eponses)

Bloquage selon GET X X

X

X

X

X

Bloquage selon POST X

X

Bloquage selon entˆetes HTTP

les

URL rewriting

X selon certaines

X a` l’aide d’un programme externe

X

X

ProxyFilter Ce produit e´ tudi´e durant le travail de semestre et d´evelopp´ee par Sylvain Tissot dans le cadre de son projet de Diplˆome (2004) repose sur l’architecture d’Apache. Il est donc le module d’un serveur Apache d´edi´e a` l’ex´ecution de celui-ci. La configuration en whitelist est tr`es pointue et tr`es ccoˆuteuseen temps mais offre une protection optimale puisque seul les param`etres non dangereux sont autoris´es a` eˆ tre relay´e au serveur Web. De mˆeme, il sera possible d’´editer une whitelist ou blacklist des entˆetes HTTP pouvant eˆ tre retourn´ees aux clients. AppShield Ce produit e´ tudi´e par Sylvain Tissot durant son travail de diplˆome16 est un outil propri´etaire (donc cher) offrant une configuration de type whitelist. Il permet l’utilisation de niveaux de s´ecurit´e pr´ed´efinis ainsi que l’affinement de ceux-ci par diff´erentes r`egles pouvant eˆ tre d´efinies a` l’aide d’une interface graphique. La cr´eation de nouvelles r`egles est facilit´ees a` l’aide de l’analyse des logs qui permettra la cr´eation de r`egles en fonction de ceux-ci en un simple clic. Un support SSL est disponible, ce qui permet la s´ecurisation de sites HTTPS. Squid (Proxy Open Source) Configur´e en reverse-proxy, celui-ci joue le rˆole d’acc´el´erateur de serveur Web plutˆot 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 r`egles d’acc`es (ACL) de d´efinir le bloquage de requˆetes clientes. Ce genre de contrˆole d’acc`es est toute fois limit´e aux types ACL d´efini par Squid (section 3.1.4) 15 16

Cross site scripting e´ tude disponible sur http ://proxyfilter.sourceforge.net/documents/rapport websecurity diplome.pdf

29

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

et limitera le champ d’action de celui-ci. Squid offre un filtrage17 dans le sens aller (requˆete vers le serveur) ainsi que dans le sens retour (r´eponse du serveur). Dansguardian Ce proxy Open Source permet un filtrage pointu sur les contenu HTML ainsi qu’un bloquage des URLs dangereuses demand´ees par les clients Web. Configur´e en reverse-proxy, il permettra la protection du serveur via des expressions r´eguli`eres offrant la validation des requˆetes HTTP. De plus il permettra la protection des clients en contrˆolant le contenu des pages HTML transmises a` ceux-ci a` l’aide d’expressions r´eguli`eres.

17

Au sens, bloquage de messages

30

Chapitre 4

Architecture retenue et mise en place Ce chapitre d´efinit l’architecture globale du banc d’essai d´eploy´e dans le cadre de ce projet. De plus, il soul`eve les probl`emes d’impl´ementation du reverse-proxy (Dansguardian), propose les modification a` y apporter et explique comment celles-ci ont e´ t´e effectu´ees. Ensuite, la configuration et la mise en place de la totalit´e de l’architecture d´efinie sur la figure 4.3 y sont expliqu´es.

4.1

D´efinition de l’architecture

Apr`es l’´etude de ces diff´erents reverse-proxys (ProxyFilter, AppShield, Squid et Dansguardian), il en est ressorti que deux utilisations e´ taient envisageables : 1. Reverse-proxy g´en´erique, n´ecessitant peu de configuration. 2. Reverese-proxy sp´ecifique a` l’application a` prot´eger, n´ecessitant une configuration pour chaque formulaire pr´esent dans les pages HTML fournies par le serveur (exemple : ProxyFilter). Le premier principe cit´e repose sur l’utilisation d’une blacklist, alors que le second repose sur une whitelist. Il est e´ vident qu’une whitelist sera toujours plus efficace qu’une blacklist puisqu’elle bloquera tout ce qui n’est pas sp´ecifiquement autoris´e. Cette m´ethode de travail permet de bloquer un grand nombre d’attaques puisqu’elle ne n´ecessite pas de signatures. Elle stoppera donc simplement tout ce qui n’est pas consid´er´e comme normal pour l’application Web. L’inconv´enient majeur de ce fonctionnement vient de la configuration des r`egles de filtrage. En effet, il faudra, comme dans le cas de ProxyFilter, d´efinir pour chaque document HTML ce qu’il est possible de fournir en param`etres dans l’URL, dans les donn´ees POST´ees et dans les entˆetes HTTP. Un fonctionnement en blacklist devra, quant a` lui, d´efinir toutes les signatures des attaques que l’on d´esire stopper, sans ”aucune” configuration en fonction de l’application a` prot´eger. Il sera donc ais´e de prot´eger son serveur Web en plac¸ant simplement le reverse-proxy devant celui-ci. La s´ecurit´e du serveur Web d´ependra ainsi des signatures disponibles sur le reverse-proxy, ce qui impliquera des mises a` jour

31

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

r´eguli`eres de la liste des signatures. Dans le cadre de ce projet, nous avons privil´egi´e une mise en place facilit´ee (sans configuration sp´ecifique a` l’application Web a` prot´eger) plutˆot que l’efficacit´e d’un principe de fonctionnement en whitelist. Ceci permettra de proposer un produit simple d’installation et efficace puisque l’inconv´enient du fonctionnement en blacklist du reverse-proxy est ”contr´e” a` l’aide de l’ajout de sondes NIDS et HIDS (comme propos´e 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 corr´elation des alarmes g´en´er´ees par celles-ci, d’obtenir des informations pertinentes relatives a` la s´ecurit´e des serveurs Web. Ceci permettra a` l’administrateur en charge de la s´ecurit´e du r´eseau, d’ajouter ou corriger les r`egles de filtrages d´efinies sur le reverse-proxy. Notre choix s’est port´e sur Dansguardian, puisque celui-ci travaille en blacklist (proxy g´en´erique) et offre les mˆemes caract´eristiques que Squid, avec la capacit´e suppl´ementaire non n´egligeable permettant de filtrer les corps des documents HTML et TXT. Comme expliqu´e 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 install´e sur une machine disposant d’une seule interface r´eseau. L’utilisation de Dansguardian implique quelques petites modifications de son code source, puisque celuici n’est pas pr´evu pour fonctionner en reverse-proxy. Nous lui avons alors ajout´e la possibilit´e de contrˆoler des donn´ees POST´ees par les clients. Nous avons ensuite test´e son fonctionnement et l’avons adapt´e (le code source) aux besoins d’un reverse-proxy. Ces modifications sont relat´ees 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 orient´e Web. Cette architecture a e´ t´e e´ bauch´ee lors du travail de semestre. Pour le travail de corr´elation qui suivra, nous pensons que l’adjonction d’un HIDS sur le firewall en plus des sondes NIDS avant et apr`es le reverse-proxy et de la sonde HIDS du reverse-proxy est un atout suppl´ementaire. En effet, une attaque commence tr`es souvent par une e´ tape de d´ecouverte du r´eseau cible et des services s’ex´ecutant sur les machines accessibles. Le HIDS du firewall nous permettra de d´etecter tr`es facilement les scans de ports qui pr´ec´edent une attaque. Une sonde NIDS ne pourrait pas suffire a` la d´etection de scans de ports puisque celles-ci n’ont pas une capacit´e d’analyse permettant la corr´elation d’´ev´enements ind´ependants et n’ont aucune possibilit´e d’´etablir des r`egles permettant de lever des alertes affirmant qu’il y a eu un scan de ports. Il faudrait e´ tablir des r`egles permettant d’alerter l’acc`es a` chaque port d’une machine pour qu’un corr´elateur externe puisse analyser ces alertes et en conclure a` un scan de ports. Le HIDS du firewall nous offre donc la possibilit´e de r´ecup´erer facilement des informations sur les paquets refus´es 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 ais´e de les analyser afin de mettre en e´ vidence les scans de ports et autres manipluations avant-coureuses d’une attaques.

32

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 4.1 – Fonctionnement du reverse-proxy de SIMS orient´e Web

Nous avons ensuite plac´e diff´erentes sondes r´eseaux (NIDS) et host (HIDS permettant l’analyse de logs). Afin de pouvoir en tirer les meilleures conclusions pour l’´elaboration de la strat´egie de corr´elation, nous avons plac´e un maximum de sondes. Nous disposons donc d’une sonde r´eseau a` chaque niveau (prereverse-proxy et post-reverse-proxy). La premi`ere permettra de relever des alertes avant l’´eventuel bloquage du reverse-proxy (sonde pre-reverse-proxy) alors que la seconde permettra de relever les attaques ayant tout de mˆeme pass´e le filtrage impos´e par le reverse-proxy (sonde post-reverse-proxy). De plus, nous avons dispos´e les sondes HIDS sur le firewall (comme expliqu´e ci-dessus), sur le reverseproxy ainsi que sur le serveur Web. Il nous sera possible, a` l’aide de la sonde HIDS du reverse-proxy d’observer les bloquages effectu´es par celui-ci. La sonde plac´ee sur le serveur Web, nous permettra quant a` elle d’observer les acc`es effectu´es sur le serveur Web. A l’aide des toutes ces informations, il nous sera possible de retracer l’activit´e d’un client et d’en d´eduire pr´ecis´ement ses intentions (Cracker ou simple client Web). Le travail de corr´elation qui suivra nous am`enera peut-ˆetre a` retirer l’une ou l’autre des sondes NIDS ou HIDS puisque seule l’analyse des diff´erentes attaques et des informaitons recueillies par les sondes pourra nous prouver l’utilit´e de cellesci.

33

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 4.2 – Architecture globale de SIMS orient´e Web Vous constaterez, a` l’aide de la figure pr´esentant l’architecture physique 4.3, que l’Intranet a e´ t´e supprim´e pour les tests, puisque celui-ci n’apporte rien de plus pour la corr´elation des e´ v´enements. Nous avons donc cr´ee´ 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 s´ecurit´e, se trouver dans le r´eseau local de l’entreprise (comme illustr´e sur l’architecture logique globale), mais pour des raisons de facilit´e de mise en place, nous avons pr´ef´er´e le garder dans la DMZ. La machine officiant en SGBD permettra, en plus, d’interroger le manager des diff´erentes sondes (Prelude manager) a` l’aide d’un client Web (console d’administration). Cette console d’administration devrait en principe se trouver dans le r´eseau d’entreprise afin d’´eviter la mise en place d’une machine suppl´ementaire dans la DMZ. Pour des raisons de facilit´e de mise en place, nous avons pr´ef´er´e la laisser dans la DMZ. Afin de ne pas d´edier des machines a` chaque NIDS, nous en avons plac´e un sur la machine Prelude Manager et nous la connectons sur le mˆeme 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 derni`ere capturera le trafic post-reverse-proxy et pre-reverse-proxy, puisque le reverse proxy ne dispose que d’une seule interface r´eseau. Afin d’isoler le trafic pre-reverse-proxy, il suffira, lors de la visualisation des alertes, de mettre en place une r`egle de filtrage en fonction de l’adresse IP de destination. 1

Zone d´emilitaris´ee

34

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 4.3 – Architecture physique de SIMS orient´e Web

4.2

Modification du code source de Dansguardian pour le contrˆole des donn´ee POST´ee

Apr`es avoir obtenu des informations sur le forum de Dansguardian (http ://groups.yahoo.com/group/dansguardian/), il s’est av´er´e tr`es facile de modifier le code source pour que les donn´ees contenues dans un POST (requˆete d’un client) soient contrˆol´ees. Il faut donc ajouter le code ci-dessous dans le fichier ConnectionHandler.cpp apr`es le contrˆole de la taille des param`etres du POST dans la m´ethode suivante ”handleConnection(Socket peerconn)” : //si la requete n’est pas encore ´ et´ e refus´ ee on contrˆ ole le POST} if (!checkme.isItNaughty){ #ifdef DGDEBUG std::cout << "Check des data dans le POST" << std::endl; #endif //controle le buffer pass´ e en param` etre avec les fichiers de configuration //bannedphraselist et exceptionphraselist checkme.checkme(&header.postdata); //check pour le filtrage contentregexlist

35

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

header.postdata.contentRegExp(); }

L’inconv´enient majeur de cette modification vient du fait que les fichiers de configurations utilis´es pour d´eterminer s’ il y a filtrage ou bloquage sont les mˆemes pour les donn´ees e´ mises au client (r´eponse du serveur Web) et celles transmises par celui-ci (POST). De ce fait, si nous d´efinissons des r`egles de filtrage du POST afin d’´eviter des attaques de SQLinjection, nous e´ tablirons une r`egle recherchant le pattern ’ OR 1=1. Si maintenant celui-ci se retrouve dans une phrase d’une page Web, celui-ci sera aussi filtr´ee. Ce fonctionnement posera des probl`emes puisque le filtrage op´er´e sur une requˆete HTTP ou une r´eponse HTTP n’est pas le mˆeme. En effet, les attaques possibles du cˆot´e client et du cˆot´e serveur ne sont strictement pas identiques.

Am´eliorations Dans l’architecture d’un reverse-proxy, il est pr´ef´erable de bloquer les requˆetes d’un client Web transportant un contenu suspect, plutˆot que de les filtrer (remplacement de mots). Cette conclusion est tr`es facilement justifi´ee lors du couplage du serveur Web avec une base de donn´ee. En effet, il serait tr`es peu souhaitable pour un client Web, de recevoir des donn´ees ne correspondant pas a` sa requˆete (venant de la substitution de mots op´er´ee par le reverse-proxy). Dans tous les cas, il est pr´ef´erable de l’avertir par une page html de refus d’ex´ecution du serveur plutˆot que de filtrer le contenu de la requˆete HTTP a` son insu. De plus, il peu recommandable d’offrir la possibilit´e de bloquer la r´eponse du serveur Web (en envoyant une page html similaire a` celle d’un refus d’ex´ecution), puisque l’on pourrait imaginer de simples d´eni de services en ins´erant des mots bien pr´ecis dans un forum. La seule op´eration envisageable sur une r´eponse HTTP est le filtrage de contenu (remplacement de mots) afin d’´eviter la pr´esence de scripts malveillants tout en e´ vitant des bloquages ind´esirables. Apr`es ces diff´erentes observations, il nous est possible de d´efinir les modifications que nous devrons apporter a` Dansguardian afin que celui-ci fonctionne en reverse-proxy. Le filtrage du GET ne pose aucun probl`eme puisqu’il est d´ej`a disponible a` l’aide d’expressions r´eguli`eres via le fichier de configuration bannedregexpurllist. Pour le filtrage du POST, il est indispensable d’utiliser des expression r´eguli`eres. Il est flagrant, que pour l’exemple de SQLinjection donn´e ci-dessus, qu’il est impossible d’´etablir une r`egle sans utiliser une expression r´eguli`ere, puisque les ”1” utilis´e dans l’attaques peuvent eˆ tre remplac´es 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 fichier contentregexplist pour op´erer le filtrage de contenu (remplacement de mots) des r´eponses HTTP e´ mises par le serveur Web. Il nous faut alors retirer : bannedphraselist afin d’´eviter le bloquage des r´eponses du serveur HTTP et exceptionphraselist puisque celui-ci n’a plus aucun sens si bannedphraselist n’existe plus. En effet, il offrait la possibilit´e de relayer la r´eponse HTTP si un des mots qu’il contenait apparaissaient dans la page Web, mˆeme si des mots bannis (contenu dans bannedphraselist

36

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

e´ taient pr´esents). Il nous faudra ensuite d´efinir un fichier de configuration (bannedregexpostdata) permettant d’´etablir des expressions r´eguli`eres d´efinissant si un refus de la requˆete a` lieu en fonction du contenu du POST. Apr`es ces quelques modifications Dansguardian fonctionnera comme un parfait reverse-proxy. Nouvelles modifications du code source (partie technique) Puisque les donn´ees transitant par Dansguardian sont encapsul´ees dans une structure de donn´ees nomm´ee Databuffer (Databuffer.cpp), nous ajoutons une m´ethode dans cette classe qui nous permettra de contrˆoler les donn´ees fournies par le client (POST). Celle-ci se nomme PostDataRegExOk() et retourne un boolean qui indique si les donn´ees post´ees sont autoris´ees ou non. Pour ce faire, nous nous appuyons sur l’impl´ementation de contentRegExp() qui, elle, contrˆole le contenu du corps des r´eponses HTTP et remplace les mots trouv´es. Nous sommes ensuite oblig´e de modifier la classe OptionContainer (OptionContainer.cpp) qui offre les m´ethodes de lecture des fichiers de configuration. Nous ajoutons donc une m´ethode qui nous permettra de lire le fichier de configuration propre au filtrage des donn´ees POST´ees (bannedregexpostdata). Celle-ci se nomme readPostRegexfile(const char* filename) et sera appel´ee dans la mˆeme classe (dans la m´ethode read(std : :string filename)). Nous nous appuyons sur la m´ethode readbreufile(const char* filename) qui, elle, s’occupe de lire les expression r´eguli`eres du fichier bannedregexpurllist pour l’impl´ementation de notre m´ethode. Comme le fichier de configuration global (dansguardian.conf) contient tous les chemins des diff´erents fichiers de configuration pour le filtrage, nous ajoutons la lecture d’une balise dans cette mˆeme m´ethode read(std : :string filename) permettant de d´eterminer l’emplacement du nouveau fichier de configuration. Il nous faut maintenant appeler la m´ethode de contrˆole des donn´es POST´ees pr´ec´edemment cr´ee´ es dans la partie du code qui s’occupe de prendre en charge la connexion client/proxy. Il s’agit donc d’ajouter PostDataRegExOk() dans la m´ethode handleConnection(Socket peerconn) et, suivant le r´esultat retourn´e par celle-ci, de mettre a` jour la variable indiquant si la requˆete sera bloqu´ee ou non (checkme.isItNaughty). Comme l’utilisation de PostDataRegExOk() n’a aucun sens s’il n’y a pas de data POST´ee, nous d´ecidons d’utiliser la m´ethode (header.isPostUpload()) fournie par la classe Header permettant de d´eterminer s’il y a ou non des donn´ees a` destination du serveur. Apr`es 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 donn´ees POST´ees. Peut-ˆetre que son fonctionnement est d´ependant de la configuration du contrˆole de la taille des donn´ees POST´ees (configuration faisant partie des fonctionnalit´es de bases de Dansguardian). Nous d´ecidons donc de cr´eer une nouvelle m´ethode dans la classe Header afin de savoir si des donn´ees sont transmises au serveur. Il s’agit donc d’une m´ethode (bool void isPostData()) qui retournera un boolean (postDataInHeader) a` true lorsque la m´ethode in(Socket sock) d´etecte une entˆete POST. Nous retirons ensuite la lecture des fichiers de configuration plus utiles dans une architecture en reverseproxy (comme expliqu´e dans le paragraphe am´eliorations). Il s’agit donc des fichiers bannedphraselist,

37

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

exceptionphraselist, bannedurllist et bannedsitelist et leurs m´ethodes de lecture de configuration correspondante 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 op´erer de filtrage ni de bloquage pour les sites mentionn´ees dans ces fichier de configurations. Ainsi configur´e, le reverse-proxy n’a aucun effet sur les sites ou URL inscrits dans ces fichiers. Le reverseproxy agira alors comme simple relai ou tunnel pour ces sites et URLs. Cette fonction nous permettra d’op´erer des tests de mise au point des fichiers de configurations et d’observer la diff´erence entre le site filtr´e et non filtr´e sans pour autant retirer le reverse-proxy de l’architecture. Nous allons maintenant retirer les appels aux m´ethodes testant les requˆetes et r´eponses en fonction des fichiers de configurations non d´esir´es. Celles-ci seront retir´ees de la classe ConnectionHandler (dans la m´ethode de gestion de la connexion handleConnection(Socket peerconn)). Il s’agit donc de la m´ethode checkme.checkme(&docbody) qui bloque tout r´eponse au client lorsque des mots contenu dans bannedphraselist y figurent, o.banned url list(temp) qui bloque la requˆete si l’URL fournie figure dans bannedsitelist et o.inBannedSiteList(temp) qui bloque la requˆete si le site indiqu´e dans la requˆete figure dans bannedsitelist. Il est important de noter que toutes les modification apport´ees dans les fichiers d’entˆetes (*.hpp) et d’impl´ementation (*.cpp) on e´ t´e indiqu´ees par un commentaire commenc¸ant par 4 e´ toiles (/****) il est ainsi facile de les retrouver. D`es lors, chaque fois que nous parlerons de DansguardianSims, nous nous r´ef´ererons a` l’application Dansguardian modifi´ee (comme expliqu´e 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 mˆeme pour la compilation (make). Ensuite, lorsque vous ex´ecuterez le make install, il se peut que diff´erentes erreurs surviennent puisqu’il cherchera a` copier des fichiers de configuration qui n’ont plus lieu d’ˆetre dans le cadre de l’application DansguardianSims. Afin de passer outre, il vous suffira d’´editer le fichier Makefile que le ./configure aura cr´eer afin de commenter (# en d´ebut de ligne) les lignes interrompants l’installation. Une modification du script de configuration aurait e´ t´e n´ecessaire afin d’´eviter l’int´egration gˆenante de

38

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

ces lignes lors de la g´en´eration du Makefile. Comme la modification de Dansguardian n’est pas le but premier de ce projet de diplˆome, nous d´ecidons d’en rester l`a afin de ne pas ”perdre” trop de temps sur la mise en place de l’architecture. Afin de pouvoir ex´ecuter DansguardianSims, il faudra encore ajouter le chemin du fichier de configuration du contrˆole des donn´ees e´ mises par les clients (POST). Il vous suffira donc d’ajouter la lignes suivante a` la suite des chemins d’acc`es pour les diff´erents fichiers de configurations : bannedregexpostdata = ’/chemin/fichier/conf/reglesPost’

Configuration Dans cette section, nous allons passer en revue tous les fichiers de d´efinition des r`egles utilis´es dans le cadre de DansguardianSims : bannediplist Ce fichier permet de donner une liste d’adresses IP (une par ligne) qui seront interdites d’acc`es au site web prot´eg´e par le reverse-proxy. Celui-ci renverra une page html indiquant que l’acc`es est refus´e. exceptioniplist Ce fichier permet de donner une liste d’adresses IP (une par ligne) dont les requˆetes et les r´eponses qui en d´ecoulent ne seront jamais contrˆol´ees (filtr´ees2 ou bloqu´ees) par le reverse-proxy. banneduserlist Lorsque l’acc`es a` un r´epertoire requiert une authentification HTTP, ce fichier de configuration permet de bloquer les utilisateurs dont le nom (username) est pr´esent dans ce fichier (un username par ligne). exceptionuserlist Lorsque l’acc`es a` un r´epertoire requiert une authentification HTTP, ce fichier de configuration permet de ne pas contrˆoler (filtrer ou bloquer) les requˆetes (et les r´eponses qui en d´ecoulent) des utilisateurs pr´esent dans cette liste. exceptionsitelist Ce fichier permet de pr´eciser des sites pour lesquels il n’y a aucun filtrage ou bloquage a` op´erer (sur les requˆetes ainsi que sur les r´eponses). Il faudra y placer un nom de domaine par ligne en retirant l’entˆete ”http ://www.”. exceptionurllist Ce fichier permet de pr´eciser des URLs (pas un site entier, mais une sous arborescence ou un r´epertoire) pour lesquels il n’y aura aucun filtrage ou bloquage (des requˆetes et des r´eponses). Il faudra donc y placer une URL par ligne en retirant l’entˆete ”http ://www.”. bannedextensionlist Fichier d´efinissant toutes les extensions de fichiers a` bloquer (`a ne pas transmettre au client). Le contrˆole s’op`ere 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 d´efinir des expressions r´eguli`eres afin de contrˆoler l’URL que le client transmet (requˆete). Si une de ces expression s’applique, la requˆete du client sera bloqu´ee. Il faudra donc entrer une expression r´eguli`ere par ligne. 2

Au sens remplacement de mots dans le corps d’un document html ou text

39

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

bannedregexpostlist Ce fichier permet de d´efinir des expression r´eguli`eres afin de contrˆoler les param`etre POST´e au serveur (dans la requˆete du client). Il faut prendre garde au codage, puisque l’analyse des donn´ees POST´ees ce fait sans d´ecodage pr´ealable de celles-ci. Il faudra donc, dans les expressions r´eguli`eres, coder les caract`eres sp´eciaux en UTF8. bannedmimetypelist Ce fichier permet de d´efinir les types MIME (un par ligne) que DansguardianSims bloquera. Il ne transmettra pas les r´eponses au client contenant un des types MIME mentionn´e dans ce fichier. messages Ce fichier permet de d´efinir les messages qui seront affich´es dans la page html retourn´ee au client en cas de bloquage de sa requˆete par DansguardianSims. contentregexplist Ce fichier de configuration permet de d´efinir des r`egles de filtrage (remplacement de mots) des r´eponses e´ mises par le serveur Web. Il est donc possible de d´efinir des expressions r´eguli`eres afin de rechercher des mots dans un document html ou txt (retourn´e par le serveur) afin de les remplacer par le ou les mots indiqu´es dans ce fichier. La syntaxe de configuration est illustr´ee dans la section 3.2.4. Les fichiers de configuration ”exception....” sont conserv´e pour une architecture en reverse-proxy pour une question de facilit´e de test et non pas pour leur utilit´e dans l’exploitation du reverse-proxy. En effet, lors de la mise sur pied de r`egles de filtrage, il est tr`es int´eressant d’observer l’effet du filtrage ou du bloquage. Il sera ainsi tr`es facile de changer la configuration afin d’observer des requˆetes sans filtrage/bloquage plutˆot 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 report´e au travail de diplˆome de Patrick Saladino annexe C.4.3 page 93 et C5 page 96. Nous avons ensuite suivi la proc´edure d’enregistrement de la sonde sur le manager comme d´ecrit dans cette annexe. La configurations de celles-ci (indication de l’IP du manager et choix des r`egles 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 4.4.1

Mise en place du reverse-proxy Installation de l’HIDS sur le reverse-proxy

Pour la compilation, l’installation et la configuration de Prelude-lml, nous nous sommes report´e au travail de diplˆome de Patrick Saladino annexe C.4.4 page 95 et C5 96. Nous avons ensuite suivi la proc´edure d’enregistrement de la sonde sur le manager comme d´ecrit dans cette annexe. Vous pourrez consulter les fichiers de configurations correspondant dans les Annexes (chapitre A, section A.2 page 94).

40

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

4.4.2

Cr´eation 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 dd´eterminerses vuln´erabilit´es. A l’aide du rapport de s´ecurit´e e´ tabli par Nessus, il nous est possible de connaˆıtre le CVE4 des diff´erentes attaques r´eussies et d’en rechercher le pattern dans les codes NASL5 des attaques fournies par Nessus. Pour ce faire, nous t´el´echargeons (sur : http ://www.nessus.org/scripts.php) les codes NASL des attaques Nessus que nous d´ecompressons dans un r´epertoire. Maintenant nous nous servons de la commande Linux grep afin de retrouver le script correspondant au CVE que nous connaissons. Si par exemple nous recherchons le CAN-2003-0822, nous nous plac¸ons dans le r´epertoire contenant 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 vuln´erabilit´e 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 caract´erisent l’attaque afin d’en e´ tablir la r`egle qui la bloquera. De plus, nous isolons l’attaque dont nous voulons cr´eer la r`egle correspondante (`a l’aide de la s´election 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 caract´eristiques de la trame ou des trames constituant l’attaque. Les r`egles permettant de bloquer les attaques sont d´efinies dans les fichiers de configuration (´etudi´e dans la section 4.2.1) de DansguardianSims a` l’aide d’expression r´eguli`eres. 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’´etablir les r`egles de r´ecup´eration de ceux-ci sur le HIDS (section 4.4.3). Blacklist pour DansguardianSims A l’aide de la m´ethodologie d´ecrite pr´ec´edemment nous e´ tablissons les diff´erentes r`egles permettant de bloquer plusieurs vuln´erabilit´es d´ecouvertes a` l’aide de Nessus. Il nous est alors possible de d´efinir le fichier de configuration bannedregexpurllist permettant de bloquer l’acc`es au serveur Web lorsqu’un des pattern contenu dans ce fichier est trouv´e dans l’URL. #Empˆ echer le SQL injection sur des param` etre ´ emis 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 vuln´erabilit´es Open Source Common Vulnerabilites and Exposures 5 Nessus Attack Scripting Language, langage de script permettant de coder des attaques qui permettrons d’´etablir si une machine est vuln´erable 4

41

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

#CVE: CAN-2000-0884 ex´ ecution de commande ` a distance ` a l’aide d’une repr´ esentation unicode #du slash permettant la remont´ ee ` a cmd.exe (les points doivent etres ´ echap´ es #dans les expressions r´ eguli` eres) .*/msadc/\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\./ #CVE: CVE-2001-0333 ex´ ecution de commande ` a distance ` a l’aide d’une repr´ esentation unicode #du slash permettant la remont´ ee ` a cmd.exe (les points doivent etres ´ echap´ es #dans les expressions r´ eguli` eres) .*/msadc/\.\.%255c\.\.%255c\.\.%255c\.\.%255c\.\.%255c\.\./ #CVE: CAN-1999-0739 visualisation des codes sources via un script ASP de d´ emo .*/iissamples/sdk/asp/docs/codebrws? #CVE: CAN-1999-1011 Possibilit´ e 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 retourn´ees 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’acc`es au serveur a` des requˆetes comportant des donn´ees POST´ees dangereuses sera pour le moment uniquement utilis´e pour un bloquage des tentatives ´ de SQL injection sur des param`etres e´ mis via la m´ethode HTTP POST. Etant donn´e que les param`etres e´ mis via un post sont cod´es en x-www-form-urlencoded et qu’aucune conversion n’est effectu´ee avant le filtrage, nous avons e´ t´e oblig´e d’´ecrire les diff´erentes r`egles en transformant les caract`eres sp´eciaux en leur repr´esentation x-www-form-urlencoded : #empˆ echer le SQL injection (%27 repr´ esente ’ et %32 repr´ esente =) %27.*OR.*%3d .*union.*select.*from

4.4.3

Pattern matching de Prelude-lml pour DansguardianSims

Apr`es avoir e´ tabli les diff´erentes r`egles de bloquage et de filtrage de DansguardianSims, nous avons effectu´e les attaques susceptibles d’ˆetre bloqu´es par DansguardianSims. Il nous a ensuite suffit d’observer le fichier de log de dansguardianSims (/var/log/dansguardian/access.log) afin de d´eterminer la construction des logs et les diff´erentes informations fournies par ceux-ci. Ces observations nous ont ensuite permi la cr´eation des r`egles de r´ecup´eration des logs par l’interm´ediaire des alarmes IDMEF qu’offre prelude-lml. Nous avons donc cr´ee´ un fichier de r`egle pour le HIDS du reverse-proxy (/etc/preludelml/rulset/dansguardian.rules) que nous avons plac´e avec les r`egles d´ej`a disponible dans prelude-lml. Nous avons ensuite activ´e son utilisation dans le fichier de configuration des r`egles de l’HIDS (/etc/preludelml/rulset/simple.rules) et nous avons pr´ecis´e quel e´ tait le nouveau fichier de log a` analyser (`a l’aide du

42

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

fichier de configuration /etc/prelude-lml/prelude-lml.conf) .Tous ces fichiers de configurations sont diponibles en annexes (section A.2, page 94)

4.5

Mise en place de la sonde HIDS de IIS

´ Etant donn´e qu’aucunes sondes Prelude n’est ddiponiblessur Windows, nous sommes dans l’obligation de r´ecup´erer 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” d´evelopp´e par InterSect Alliance7 . Nous utiliserons la machine officiant en reverse-proxy pour la r´ecup´eration des ces logs puisqu’une sonde Prelude-lml y est d´ej`a disponible. Sur celle-ci, il suffira de cr´eer de nouvelles r`egles (pattern matching des logs) afin que les alarmes voulues soient rapatri´ees 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 effectu´ee, afin que la station 192.168.1.2 (reverseproxy) 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 journali`ere ainsi qu’un format e´ tendu (W3C extended 6 7

Internet Information Services, Serveur Web de Microsoft disponible sur : http ://intersectalliance.com/projects/SnareIIS/index.html

43

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 4.5 – Configuration de l’utilitaire de r´ecup´eration 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 d´efinir la p´eriode de rotation des logs ainsi que leur format.

4.5.2

Configuration du serveur syslog Linux

Syslogd est le daemon s’occupant de la r´ecup´eration de log d’une machine Linux. Par d´efaut 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 r´ecup´eration de logs distants. Nous modifions donc son script de lancement ”sysklogd” plac´e dans /etc/ini.d/. Il suffira donc d’ajouter le ”-r” dans la variable SYSLOGD d´ej`a pr´esente dans ce fichier, comme illustr´e 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 pr´eciser que le protocole de transfert de logs bas´e sur UDP n’est pas s´ecuris´e. Les trames circulent ”en clair” sur le r´eseau. De plus l’utilisation d’UDP implique une e´ ventuelle possibilit´e de perte des paquets sans qu’aucun des deux partenaires ne s’en rende compte (principe mˆeme d’UDP).

44

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

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 observons leur structure afin d’´etablir l’expression r´eguli`ere qui permettra de relever (donc d’envoyer des alarmes IDMEF a` Prelude Manager) les logs d’acc`es d’IIS qui ont un code de status indiquant une erreur de la requˆete HTTP effectu´ee par le client (4xx). En effet, il sera iint´eressantlors de la phase de corr´elation, de connaˆıtre les requˆetes n’ayant pas abouti. Nous cr´eons un fichier de r`egles (/etc/preludelml/rulset/iis.rules) dans lequel nous d´efinissons 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 pr´esent´e dans l’architecture globale a une fonction de routage, puisqu’il comprend deux interfaces r´eseaux (la premi`ere ayant une adresse IP publique8 et la seconde ayant une adresse IP priv´ee, du r´eseau 192.168.1.0/24). Il permet ainsi la communication entre la DMZ contenant nos serveurs et le monde ext´erieur. Pour ce faire, nous avons utilis´e une machine Linux a` deux interfaces r´eseaux d´edi´ee a` la fonction de firewall. Nous avons activ´e Iptables, logiciel directement int´egr´e au Kernel Linux, permettant de filtrer et modifier les paquets arrivant et partant des cartes r´eseau de la machine en question. Pour son activation, il suffit, dans le r´epertoire des sources de votre kernel, d’´editer 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 propos´ee, vous devrez naviguer dans le menu Networking 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 n´ecessaires au NAT, MASQUERADING, ainsi qu’au filtrage. Pour notre part, nous avons activ´e 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 r´eseau TCOM, donc en 10.192.72.0/23

45

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– 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 crit`eres que nous d´efinirons. Maintenant que la configuration d’Iptables dans le kernel est termin´ee, vous devez le compiler et l’installer. La configuration d’un NAT10 statique11 est indispensable afin que le reverse-proxy soit atteignable depuis l’ext´erieur (r´eseau TCOM). A l’aide de cette configuration, nous pouvons d´efinir 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 feront substituer par l’adresse IP du proxy (192.168.1.2) avant le routage. Ces paquets seront relay´es vers le reverse-proxy par le firewall. Iptables applique implicitement la r`egle 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 caract´eristiques par sa propre adresse IP publique. De cette fac¸on, tous les clients Web ext´erieurs penserons directement atteindre le serveur Web via l’adresse IP 10.192.72.83. Nous devons ensuite configurer les r`egles permettant de bloquer le trafic ind´esirable. Lors de l’utilisation du filtrage avec une fonction de NAT activ´ee, il suffira, pour l’´etablissement des r`egles de filtrage d’ignorer les changements d’adresses op´er´e par le NAT. Lors de la mise en place d’un firewall/NAT il est donc pr´ef´erable de mettre au point la fonction de translation d’adresses (NAT) avant la fonction de filtrage afin de ne pas m´elanger les probl`emes lors des tests. Les r`egles de filtrages sont a` l’instar des r`egles de translation d’adresses unidirectionnelles. Il faudra a` chaque fois cr´eer une r`egle pour le flux entrant et le flux sortant. Voici un extrait du script d’´etablissement des r`egles de filtrage que nous avons e´ tabli pour l’acc`es au serveur Web : ############################################################# #NAT statique pour l’acc` es au reverse-proxy depuis l’ext´ erieur ############################################################# 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 r´ecup´eration des logs Linux Network Address Translation 11 Changement d’adresses avant le routage op´er´e par le stack IP de la machine (PREROUTING) 10

46

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

###################################################################### #Autorisation des requˆ etes DNS pour tout le r´ eseau (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 pr´ef´erable d’´etablir les polices par d´efaut des diff´erentes chaˆınes12 a` l’´etat ACCEPT ´ et d’´etablir une r`egle finale (la derni`ere du script) qui refusera tous les paquets. Etant donn´e que les paquets traversent les diff´erentes chaˆınes de filtrage dans l’ordre de d´eclaration des r`egles, la r`egle finale interviendra uniquement sur les paquets auxquels aucune r`egle ACCPET ne s’applique. Cette m´ethode de travail permettra une r´einitialisation ais´ee lors des tests. En effet l’utilisation de la commande iptables -F a pour effet d’effacer toutes les r`egles de filtrage des diff´erentes chaˆınes sans pour autant effacer les polices par d´efaut. Lors de son utilisation, et d’une police par d´efaut au refus de toute connexions (DROP), le firewall ne sera malheureusement plus atteignable et bloquera absolument tout. Une police par d´efaut a` ACCEPT permettra par exemple, lors de la r´einitialisation du firewall (iptables -F) effectu´e par un shell SSH13 de garder la connexion active apr`es son ex´ecution. ############################################ #Polices par d´ efaut des diff´ erentes chaˆ ınes ############################################ iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT .... r` egles de filtrages .... ########################## #r` egles de refus finales ########################## iptables -A INPUT -j DROP iptables -A FORWARD -j DROP

4.6.1

R´ecup´eration des logs du firewall

Pour ce faire, nous cr´eons 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 r`egle LOG et DROP a` cette nouvelle chaˆıne (comme illustr´e ci-dessous) : #cr´ eation de la chaˆ ıne iptables -N LOG_DROP #ajout des r` egles iptables -A LOG_DROP -j LOG --log-prefix "Drop " iptables -A LOG_DROP -j DROP 12

Une chaˆıne repr´esente un groupe de r`egles pour une fonctionnalit´e. Les diff´erentes chaˆınes pr´esentent de base sont : INPUT (paquet entrant), OUTPUT (paquet sortant), FORWARD (paquet devant eˆ tre rout´e) 13 Shell distant reposant sur une connexion TCP crypt´ee (port 22)

47

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

L’ajout du pr´efixe ”Drop ” aux logs ainsi cr´ees est indispensable au bon fonctionnement de PreludeLML (sonde HIDS de Prelude), puisque la recherche de pattern pr´ee´ tabli pour Netfilter (/etc/preludelml/rulset/netfilter.rules) recherche un tel pr´efixe afin de d´eterminer si le logs doit eˆ tre apatri´e au Manager Prelude. La totalit´e 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

´ Etant donn´e qu’un grand nombre de paquets sont refus´e par le firewall (le seul port ouvert e´ tant le port 80), les fichiers de logs ont la fˆacheuse tendance a` prendre rapidement un grand espace disque. Nous utilisons l’utilitaire logrotate de Linux afin de limiter la taille de ces fichiers de logs. Par d´efaut cet utilitaire est ex´ecut´e journali`erement par CRON14 afin de contrˆoler si les crit`eres de rotation des logs sont atteints. Le fichier de configuration crontab d´efinit plusieurs r´epertoires ccomportantles scripts e´ tant ex´ecut´es : chaque heure pour le r´epertoire cron.hourly, chaque jour pour le r´epertoire cron.daily, chaque semaine pour le r´epertoire cron.weekly ou chaque mois pour le r´epertoire cron.monthly. Logrotate figure donc dans le r´epertoire /etc/cron.daily. Lorsque CRON ex´ecutera cet utilitaire, il contrˆolera suivant les crit`eres d´efini dans /etc/logrotate quels sont les fichier de logs a` ”roter”. Suivant la configuration, cette rotation aura pour effet de compresser le fichier de log et de le stocker dans le r´epertoire voulu. Lorsque le nombre maximum d’archives de fichiers de logs compress´e 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 compress´ees (*.tar.gz). rotate 3 Indique que 3 archives compress´ees seront gard´ee (les anciennes e´ tant remplac´ees par les nouvelles). size=4M Indique que lorsque la taille du fichier /var/log/syslog atteindra 4M, celui-ci sera ”rot´e”. 14

daemon ex´ecutant des commandes suivant un calendri´e pr´e-programm´e (/etc/crontab)

48

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

olddir Permet de pr´eciser dans quel r´epertoire seront plac´e les archives compress´ees. postrotate - endscript Englobe une commande qui sera directement ex´ecut´ee apr`es la rotation des logs. Dans notre cas, killall syslogd -HUP relance le daemon syslog en lui demandant de relire sa configuration (/etc/syslog.conf) et de recr´eer les fichiers de logs supprim´es. Lors de l’utilisation de la directive size, et suivant la vitesse de d’accroˆıssement des logs, il sera n´ecessaire de d´eplacer le script de rotation des logs se trouvant dans /etc/cron.daily/ vers le r´epertoire /etc/cron.hourly/. En effet, il se peut que la taille limite d´efinie dans le fichier de configration ci-dessus soit rapidement atteinte en un jour. Un contrˆole horraire peut donc s’av´erer indispensable.

49

Chapitre 5

Corr´elation Ce chapitre commencera par poser les bases de la corr´elation, son utilisation et pour finir son application au banc d’essai du projet. Diff´erents sc´enarii d’attaques seront envisag´es afin d’illustrer au mieux les mesures introduites par la corr´elation.

5.1

D´efinition et principe

La corr´elation est d´efinie comme une relation entre deux ou plusieurs variables. Imaginons maintenant que ces variables soient les alarmes de diff´erents IDS r´epartis sur un r´eseau. Un m´ecanisme de corr´elation1 capable de trouver une relation entre plusieurs alarmes de diff´erents IDS nous permettra ensuite de d´eduire plus facilement la dangerosit´e d’une alarme puisque celle-ci ne se trouvera plus noy´ee dans un flot d’alarmes mais associ´ee a` un contexte ou a` une action bien pr´ecise. Le lieutenant Colombo2 est donc un exemple ”concret” de moteur de corr´elation puisqu’il sera toujours capable de reconstruire le puzzle d’un crime. Apr`es l’interrogation des suspects et de longues investigations dans les alentours du lieu du crime, il est capable de dresser un bilan et d’en d´eduire le coupable. Il s’agit donc d’un comportement totalement analogue a` un moteur de corr´elation pour des alarmes de d´etecteurs d’intrusions. En effet, les alarmes d’une source (IDS) bien pr´ecise pourraient eˆ tre d´efinies comme le crime potentiel, alors que les alarmes des autres sources (IDS) comme les suspects. Notre moteur de corr´elation se chargera donc de les analyser (´equivalent a` l’interrogation d’un suspect) et fournira un bilan sur chaque alarme. 1 2

M´ecanisme mis en place par un moteur de corr´elation (software s’occupant de la corr´elation) Lieutenant bien connu d’une s´erie am´ericaine du mˆeme nom (cr´ee en 1968 )

50

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

5.2

Application

L’architecture r´eseau a` disposition (figure 4.3 page 35) et les nombreuses sondes dispos´ees dans celleci nous permettrons de d´efnir plusieurs strat´egies d’investigations. En effet, l’´ev´enement d´eclencheur (appel´e crime potentiel dans la section 5.1) de l’investigation pourrait provenir de diff´erentes sources d’alarmes (IDS). Nous sommes donc dans l’obligation de d´efinir plusieurs sc´enarii d’investigation (un pour chaque d´eclencheur). A ce stade de la corr´elation, il est important de faire la distinction entre les sc´enarii d’investigation et ceux d’attaques. En effet, le projet de diplˆome SIMS 2003 de Patrick Saladino e´ tait orient´e sur la cr´eation de sc´enarii caract´eristiques d’une attaque. Ces sc´enarii e´ taient recherch´es dans le flot des alarmes d’un IDS par le moteur de corr´elation mis au point dans le cadre de ce projet. Il s’agissait donc d’une recherche de ´ suite d’alarmes dans une fenˆetre temporelle pr´ed´efinie. Etant donn´e que les alarmes ne provenaient que d’une seule source, une strat´egie d’investigation e´ tait impossible. Grˆace a` l’architecture d´eploy´ee dans la premi`ere partie de ce projet, nous sommes capable de d´efinir des sc´enarii d’investigation a` l’aide des diff´erentes alarmes e´ mises par les sondes NIDS et HIDS puis r´ecolt´ees par Prelude-Manager3 . Le principal avantage des sc´enarii d’investigations sur ceux d’attaques vient du fait qu’il sont g´en´eriques et tr`es souvent ind´ependants du type d’attaques, puisqu’ils ne d´ependent plus de l’attaque mais de l’architecture mise en place (des diff´erentes sondes et de leurs positions dans le r´eseau).

5.2.1

Mais qu’apportera concr`etement la corr´elation ?

L’image entre l’insepecteur Colombo et notre moteur de corr´elation est bonne jusqu’`a un certain point seulement. En effet, l’inspecteur Colombo n’enquˆetera jamais pour un crime inexistant, alors que dans notre cas, chaque e´ v´enement (alarme) d´eclencheur d’un sc´enarii de corr´elation doit eˆ tre consid´er´e comme un ”crime potentiel”, puisqu’il est impossible en analysant uniquement cet e´ v´enement de savoir s’il s’agit d’une alarme dangeureuse pour notre architecture ou d’une alarme lev´ee pour aucun4 e´ v´enement dangereux dans notre cas. Ce probl`eme provient uniquement du mode de fonctionnement en blacklist des sondes r´eseaux (NIDS) et des sondes analysant les logs (HIDS). En effet, d`es qu’un pattern sera d´etect´e par l’une ou l’autre de ces sondes, une alarme sera lev´ee mˆeme si l’´el´ement a` prot´eger n’est pas vuln´erable a` ce genre d’attaques (Script vuln´erable non pr´esent sur le serveur). Il sera donc tr`es int´eressant d’´eliminer une grande partie des faux positifs a` l’aide d’une e´ tape de filtrage dans chaques sc´enarii de corr´elation. De plus, lors d’une corr´elation d’alarmes d’IDS, nous sommes en pr´esence d’une multitude d’attaques quasi simultan´ees. Il devient donc tr`es difficile d’identifier les alarmes appartenant a` la mˆeme attaque. Il est alors n´ecessaire de regrouper les alarmes suivant des crit`eres5 pr´ed´etermin´es afin de pouvoir identifier plus facilement les alarmes provenant de la mˆeme attaque. Il sera int´eressant de mettre en place diff´erents sc´enarii de corr´elation permettant d’am´eliorer le sta3

Manager des sondes (comportement d´ecrit dans la section 2.2.1 page 14) Faux positif 5 Crit`eres regroup´e sous la forme de contextes (d´efini dans la section 5.4) 4

51

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

tus de dangerosit´e d’une alarme en l’associant avec diff´erentes alarmes g´en´er´ees par la mˆeme tentative d’attaque. La figure 5.1 repr´esente donc le processus de corr´elation e´ labor´e. La phase de mise en place de contextes e´ tabli concr`etement le regroupement des alarmes suivant des crit`eres pr´ed´efinis, comme expliqu´e ci-dessus.

F IG . 5.1 – Principe de corr´elation Par la suite, il serait int´eressant de pouvoir retracer l’activit´e totale d’un client sur notre architecture r´eseau. L’analyste r´eseau pourrait ainsi, apr`es consultations des alarmes tr`es critiques, suivre l’activit´e des adresses IP ayant d´eclench´e ces alarmes.

´ enements d´eclencheurs 5.2.2 Ev´ Jusqu’`a pr´esent nous avons beaucoup parl´e d’´ev´enements d´eclencheurs de sc´enarii d’investigation, mais a` quoi servent-ils et o`u se situent-ils exactement dans l’architecture r´eseau ? Un e´ v´enement d´eclencheur est le point de d´epart du diagramme d’´etat repr´esentant le sc´enario d’investigation. Sans cet e´ l´ement de base (groupe d’alarme ou alarme sp´ecifique), il sera impossible de d´emarrer le processus de corr´elation du sc´enario d´efini. Cet e´ v´enement est donc la source d’informations de d´epart de la corr´elation. Lors de l’´etablissement d’un sc´enario d’investigation, deux strat´egies pour la d´etermination de l’´ev´enement d´eclencheur sont applicables. En effet, il est possible de d´efinir l’action avant-coureuse d’une attaque comme d´eclencheur ou alors, la d´etection de l’attaque elle-mˆeme. L’utilisation d’une action avantcoureuse entrera plutˆot dans une strat´egie de pr´evention6 , alors qu’une corr´elation d´eclench´ee par l’attaque elle mˆeme permettra plutˆot une analyse de la cause et apporte une fac¸on d’y rem´edier rapidement. G´eographiquement, ces deux types d’´ev´enements d´eclencheurs se situent a` l’oppos´e de l’architecture 6

Recherche des actions effectu´ees par un client d´etermin´e comme potentiellement dangereux

52

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

r´eseau. Un e´ v´enement avant-coureur sera g´en´eralement d´efini comme un scan de ports sur le firewall ou un trop grand nombre de requˆetes bloqu´ees par le reverse-proxy, alors que l’attaque elle-mˆeme sera d´etect´ee par la sonde post-reverse-proxy ou le HIDS du serveur Web. Les e´ v´enements avant-coureurs se situent donc proches du r´eseau publique (proche du firewall), alors que les informations d’attaque proviendront des sources les plus proches possibles du serveur Web (´el´ement a` prot´eger). Il serait donc tr`es int´eressant de mettre sur pied ces deux principes puisqu’ils ne paraissent pas concurrents mais compl´ementaires. Malheureusement, dans le cadre de ce travail de diplˆome, il ne sera pas possible d’´etablir plusieurs sc´enarii de corr´elation pour une question de temps a` disposition. Pour commencer, nous choisirons une approche permettant de r´eduire au maximum les faux positifs. Nous utiliserons donc un d´eclencheur proche du serveur Web afin d’analyser les attaques d´etect´ees et d’en d´eterminer la gravit´e (faux positifs ou non et niveau de gravit´e).

5.3

Corr´elation temps r´eel VS corr´elation a` post´eriori

Une m´ethode de travail en temps r´eel permettrait un monitoring permanent et une remont´ee en temps r´eel des alarmes critiques vers le gestionnaire de r´eseau (personne physique). Ceci aurait pour effet d’am´eliorer le temps de r´eaction entre une attaque et la mise en place des dispositions pour la pr´evenir. Malheureusement le mod`ele 3-tiers employ´e par Piwi7 auquel nous d´esirons ajouter notre moteur de corr´elation ne permet pas un fonctionnement en temps r´eel. La figure 5.2 illustre cette architecture.

F IG . 5.2 – Architecture 3-tiers du frontend Prelude (Piwi) En effet, il est impossible d’ex´ecuter continuellement du code serveur8 puisque son ex´ecution doit obligatoirement se terminer pour permettre l’envoi des informations demand´ees par le client Web. De plus, le fonctionnement client-serveur d’un serveur Web implique qu’une requˆete doit eˆ tre e´ mise par un client (gestionnaire r´eseau dans notre cas) pour qu’une r´eponse puisse eˆ tre rec¸ue. Il faudrait donc qu’un script client invoque continuellement le programme serveur de corr´elation. Cette m´ethode de travail (utilis´ee 7 8

Frontend de Prelude permettant l’interrogation de la base de donn´ee stockant les alarmes Programme situ´e sur le serveur Web

53

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

par M. Saladino dans le cadre de SIMS 2003) serait envisageable mais poserait quelques probl`emes au niveau du temps d’ex´ecution du programme serveur. En effet, celui-ci devrait continuellement reconstruire toutes les associations entre les diff´erentes alarmes (interrogation du SGBD de Prelude, parcours de toutes les alarmes, tri, mise en place dans des structures de donn´ees et corr´elation) ce qui s’av`ere extrˆemement long pour un grand nombre d’alarmes. Nous serions donc dans l’obligation de stocker les structures de donn´ees et les r´esultats de chaque corr´elation dans une nouvelle base de donn´ees ou dans une structure de fichiers afin de ne pas relancer, a` chaque invocation du programme serveur, une corr´elation sur la totalit´e des alarmes contenues dans le SGBD de Prelude. La solution id´eale (illustr´ee par la figure 5.3), pour une corr´elation en temps r´eel, serait de d´evelopper un daemon9 qui s’occuperait de la r´ecup´eration des alarmes du SGBD de Prelude et qui stockerait les r´esultats interm´ediaires (structure de donn´ees, etc..) dans une structure de fichiers ou une base de donn´ees interm´ediaire afin d’uniquement r´ecup´erer les derni`eres alarmes aupr`es du SGBD et non pas l’historique complet. Il faudrait ensuite d´efinir un protocole d’interrogation de ce deamon qui permettrait a` un programme serveur de l’interroger et d’afficher sous forme de page Web les informations d´esir´ees par le gestionnaire de r´eseau. De cette mani`ere, l’affichage des informations serait totalement ind´ependant de l’ex´ecution du moteur de corr´elation et l’ex´ecution d’un daemon permettrait, en plus, l’envoi spontan´e d’alarmes critiques au gestionnaire du r´eseau.

F IG . 5.3 – Architecture 3-tiers, fonctionnement en temps r´eel Pour des contraintes de planning, ne nous pourrons pas, dans le cadre de ce projet de diplˆome, d´evelopper un moteur de corr´elation sous la forme d’un daemon. Nous allons donc ajouter un module au frontend existant (Piwi, figure 5.2). Le moteur de corr´elation s’ex´ecutera pour une fenˆetre temporelle d’alarmes et ne pourra en aucun cas interagir spontan´ement avec le gestionnaire de r´eseau (envoi d’alarmes critiques via e-mail, popup, etc..). Il faudra donc, a` chaque lancement du moteur de corr´elation, pr´eciser le nombre de jours ou d’heures pass´ees qu’il faudra analyser. Afin d’am´eliorer la r´eactivit´e de notre application (sans pour autant pr´etendre atteindre celle d’un syst`eme temps r´eel), nous d´evelopperons un petit daemon qui contrˆolera en permanence (toutes les 10 minutes par d´efaut) le fonctionnement du ou des serveurs Web. Il permettra ainsi d’avertir l’administrateur r´eseau 9

Programme s’ex´ecutant en permanence

54

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

(via e-mail) lorsqu’un des serveurs sera hors service. Les d´etails de cette impl´ementation sont disponibles dans le chapitre 6 section 6.1.

5.4

Mise en place des contextes

Comme illustr´e sur la figure 5.1, l’´etape de cr´eation de contextes est indispensable pour une bonne corr´elation. Cette e´ tape a comme objectif de regrouper les alarmes par caract´eristiques ou crit`eres communs. En effet, il est particuli`erement difficile d’op´erer une corr´elation lorsqu’ aucun tri pr´ealable des alarmes n’a e´ t´e effectu´e. Ces contextes permettrons d’envisager des sc´enarii d’investigations en fonction de leurs caract´eristiques. Un contexte regroupant les alertes ayant la mˆeme adresse IP source permettra, par exemple, d’identifier un hacker alors qu’un contexte regroupant les alarmes de mˆeme type permettra de trouver quelles sont les types d’attaques effectu´ees et les pages Web attaqu´ees (donc potentiellement vuln´erables). Nous remarquons donc que les contextes sont compl´ementaires et qu’ils permettent une vue plus globale des attaques effectu´ees. A l’aide de l’architecture r´eseau et des diff´erentes sondes mises en place dans le chapitre pr´ec´edent, nous sommes capables de d´efinir 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 mˆeme classe d’alarme – URL de destination commune et mˆeme classe d’alarme De par l’architecture r´eseau d´efinie (dans le chapitre 4), la plupart de ces contextes ne sont pas directement extractables du SGBD de Prelude (par une simple requˆete SQL). En effet, les champs retir´es du SGBD devront subir un traitement (recherche de pattern) pr´ealable pour qu’une d´ecision d’association a` un contexte soit possible. De plus, l’utilisation du reverse proxy implique une corr´elation 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’´eliminer l’acc`es 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 requˆete refus´ee. L’id´ee est de s’appuyer sur le type de l’alarme g´en´er´ee afin d’effectuer une recherche de type dans une fenˆetre temporelle r´eduite pour les alarmes pre-reverse-proxy et post-reverse-proxy (NIDS uniquement). En effet, les alarmes pre-reverse-proxy contiendront l’adresse r´eelle du client ayant tent´e 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 strat´egie soit applicable, il est n´ecessaire que les deux sondes NIDS poss`edent exactement

55

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

les mˆemes r`egles afin que les mˆemes alarmes soient identifiables. En effet, si la sonde post-reverseproxy l`eve une alarme, il est n´ecessaire que la mˆeme alarme ait e´ t´e pr´ec´edemment lev´ee par la sonde pre-reverse-proxy afin que l’adresse IP source (celle de l’attaquant) soit connue. Il est donc indispensable de synchroniser temporellement les diff´erentes sondes afin que la fenˆetre temporelle de recherche puisse eˆ tre appliqu´ee. Nous d´ecidons alors d’int´egrer un client NTP10 sur les machines de notre DMZ, afin de permettre l’obtention d’une horloge syst`eme synchronis´ee. La section 5.6 vous expliquera en d´etail l’installation du client NTP sur les syst`emes d’exploitations utilis´es (Windows Server et Linux Debian). La m´ethode d´ecrite ci-dessus implique malheureusement que plusieurs mˆemes types d’alarmes peuvent correspondre a` la recherche effectu´ee. Dans certains cas, il ne sera donc pas possible d’obtenir une seule adresse IP source puisque, lors d’un grand nombre de mˆemes attaques provenant de diff´erentes sources durant un court intervalle de temps, la recherche effectu´ee fournira plusieurs adresses sources possibles. Une approche bas´ee sur la comparaison des payloads11 des sondes post et pre-reverse-proxy a dˆu eˆ tre e´ cart´ee. En effet, Prelude-IDS n’archive qu’une courte partie de ceux-ci (le d´ebut) qui se compose bien souvent de l’entˆete HTTP qui sera modifi´ee par le reverse-proxy. Il devient alors impossible de retrouver la mˆeme 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 corr´elation subtile du genre attaque-r´eponse. En effet, les attaques men´ees par des crackers m`enent souvent a` une r´eponse imm´ediate puisque le protocole HTTP fonctionne comme tel (chaque requˆete implique une r´eponse). Il est alors tr`es int´eressant de relever les alarmes appartenant a` la mˆeme paire requˆete-r´eponse afin de permettre un diagnostique rapide de la r´eussite de l’attaque (faux positif ou non). Comme toutes m´ethodes 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 mˆeme attaque. Effectivement, l’alarme lev´ee par la d´etection d’un shell code contenu dans une attaque de type buffer overflow ainsi que celle lev´ee par la d´etection des commandes ex´ecut´ees par le cracker ayant lanc´e 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 serveur Telnet ind´esirable 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 lev´ees. Par la topologie mise en place, nous sommes capables de d´efinir deux contextes de session TCP : 1. Les sessions post-reverse-proxy 2. Les sessions pre-reverse-proxy L’obligation de d´efinir deux contextes de session provient uniquement de l’utilisation d’un reverse-proxy 10 11

Network Time Protocol Contenu utile des segments TCP

56

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

qui, comme pr´ecis´e ci-dessus, a pour effet de ”casser” la connexion client-serveur. Nous sommes donc en pr´esence de deux connexions TCP pour une unique requˆete. Dans le cadre de ce projet, nous utiliserons uniquement les contextes post-reverse-proxy puisque, comme expliqu´e dans la section 5.2.2, les alarmes proches du serveur Web nous serviront de d´eclencheur du sc´enario d’investigation. Algorithme de d´efinition des sessions TCP post-reverse-proxy Afin de d´eterminer l’appartenance d’une alarme a` une session TCP, nous nous basons en premier lieu sur les adresses IP sources et destinations du paquet incrimin´e puis sur le num´ero du port utilis´e par le client. Lors de l’application a` notre architecture, nous remarquons que la diff´erenciation 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 param`etres ne sont de loin pas suffisants au classement des alarmes par sessions TCP. Il est donc imp´eratif d’int´egrer un troisi`eme param`etre. Deux solutions ont alors e´ t´e envisag´ees : – Utilisation des num´eros de s´equences TCP. – Utilisation d’un intervalle de temps pour l’utilisation d’un mˆeme port source. Num´eros de s´equences TCP Les num´eros de s´equences sont cod´es sur 4 bytes et offrent donc 4,29 milliards de possibilit´es et permettent la r´egulation de flux du niveau 412 . A chaque d´ebut de connexion TCP ces num´eros de s´equences sont initialis´es par un algorithme al´eatoire. L’id´ee est donc de d´efinir un e´ cart maximum entre les num´eros de s´equences de deux alarmes de mˆeme session et de contrˆoler pour chaque nouvelle alarme si celle-ci entre dans les crit`eres d’une session existante. Si ce n’est pas le cas, il faudra cr´eer une nouvelle session. Cette solution se base sur le fait que les num´eros de s´equences sont initialis´es de mani`ere totalement al´eatoires et qu’aucune connexion TCP simultan´ee n’utilise la mˆeme plage de num´eros de s´equences. Malheureusement, une notion de temps sera indispensable puisqu’il est fort probable d’avoir deux sessions TCP grandement e´ cart´ees dans le temps utilisant les mˆemes plages de num´eros de s´equences. Sans cette notion de temps, il serait donc impossible de diff´erencier ces deux sessions TCP temporellement tr`es e´ cart´ees mais tr`es proches au niveau de leurs num´eros de s´equences. Intervalle de temps entre deux mˆeme ports source Cette m´ethode de diff´erenciation des sessions TCP s’appuie sur le fait que, sur une mˆeme machine cliente, le mˆeme port source dynamique ne peut eˆ tre employ´e pour deux connexions TCP simultan´ees. Cette strat´egie sera donc uniquement applicable dans le cadre de notre architecture r´eseau, puisqu’une seule machine (reverse-proxy) interroge le serveur Web. D’une certaine mani`ere, 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’´etablir les connexions TCP vers le serveur Web. Ceci implique donc qu’il n’y aura jamais deux mˆemes ports source utilis´es simultan´ement. En effet, le stack TCP de chaque machine comporte une plage de ports allouable dynamiquement (pour les sockets du niveau applicatif) qui seront utilis´es comme port source des connexions TCP. Ceux-ci sont parcouru les uns apr`es les autres selon l’algorithme d´efini dans les sources du kernel (Linux 2.4.27 dans notre cas) impl´ementant 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 mod`ele OSI

57

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

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 syst`eme sysctl permettant de configurer certains param`etres du noyau durant son ex´ecution. Sa valeur par d´efaut 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 mˆeme port source) du stack TCP du reverse-proxy pour une charge maximum du serveur Web. Ceci permettrait de d´eterminer l’intervalle temporel limite, permettant de diff´erencier l’utilisation d’un mˆeme port source pour deux sessions (ou connexions) TCP diff´erentes. Il nous serait ainsi possible, a` l’aide de l’heure de l’alarme ainsi que du port source du reverse-proxy, de d´eterminer l’appartenance d’une alarme a` une session TCP existante ou non. Apr`es r´eflexions, nous en avons d´eduit que l’utilisation des num´eros de s´equence pour l’identification des sessions TCP repose sur une approche trop comportementale (d´ependante de la masse des donn´ees t´el´echarg´ees). En effet, les alarmes peuvent eˆ tre lev´ees a` n’importe quel moment de la transaction HTTP et eˆ tre espac´ees d’un grand nombre de bytes de payload13 pouvant ainsi donner de grands pas d’incr´ementation des num´eros de s´equence entre deux alarmes. Il serait alors possible que les compteurs (num´eros de s´equence) de deux sessions TCP simultan´ees soient tr`es proches et que le classement op´er´e pour le contexte de session TCP communes soit erron´e. Nous avons donc opt´e pour l’approche de tri de session en fonction de l’intervalle de temps entre l’utilisation du mˆeme port source. Nous devrons donc eˆ tre capables d’´evaluer le temps de r´eutilisation d’un mˆeme port source afin d’avoir un minimum d’errreurs de classement. D´etermination de l’intervalle de temps pour l’utilisation du mˆeme port source Le sch´ema de la figure 5.4 illustre le nombre maximum de requˆetes accept´ees par diff´erents serveurs Web Microsoft. A l’aide de ces statistiques, il nous est possible de connaˆıtre le nombre de ports par seconde utilis´es par le reverse-proxy pour une charge maximale du serveur Web. Nous relevons qu’un petit serveur de production est capable de traiter 755 requˆetes par seconde (soit l’utilisation de 755 ports sources par seconde) et 2507 requˆetes 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 r´eutilisation des ports sources : Ports source dynamiques par d´efaut :

61000 − 32768 = 28232 P´eriode de r´eutilisation des ports source du reverse-proxy pour un petit serveur de production : 13

Contenu des segments TCP

58

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 5.4 – Statistiques de charge de IIS mesur´ee a` l’aide de 240 Mb de donn´ees (80% de pages statiques et 20% de pages dynamiques, source Microsoft) 28232 755

= 37.4secondes

P´eriode de r´eutilisation des ports source du reverse-proxy pour un gros serveur de production :

28232 2507

= 11.3secondes

Maintenant, il serait int´eressant d’observer la rapidit´e d’utilisation de la plage des ports source sur le reverse-proxy. En effet, l’´etat Time wait du protocole TCP implique un temps d’attente du cˆot´e de la station demandant la fermeture du socket (reverse-proxy dans notre cas) avant le restitution de celui-ci. ´ Etant donn´e que TCP s’appuie la plupart du temps sur IP (protocole de niveau 3 ne garantissant en aucun cas l’arriv´ee des paquets dans l’ordre d’´emission), l’´etat Time wait permet d’attendre les e´ ventuels paquets e´ gar´es sur le r´eseau IP. A l’aide de cette mesure nous pourrions nous assurer que le reverse-proxy n’est pas capable de parcourir tous ses ports sources en moins de 37.4 secondes ou 11.3 secondes (suivant le type de serveur Web install´e), ce qui nous assurerait que deux segments TCP de deux sessions diff´erentes ne peuvent pas eˆ tre physiquement e´ mis sur le r´eseau avec le mˆeme port source dans cet intervalle de temps. En effet, le serveur Web traitera au maximum 2507 requˆetes par seconde mais rien n’empˆeche d’en envoyer plus. Le suppl´ement serait donc stock´e dans un buffer et trait´e ult´erieurement. Ce cas de figure implique que le NIDS plac´e entre le reverse-proxy et le serveur Web d´etecterait deux segments TCP ayant le mˆeme port source mais appartenant a` deux sessions TCP diff´erentes dans un intervalle de temps plus petit que le maximum calcul´e pr´ec´edemment a` l’aide des caract´eristiques du serveur Web. Id´ealement, ce test devrait eˆ tre effectu´e a` l’aide d’un programme en C ou C++ puisque le reverse-proxy

59

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

est lui-mˆeme e´ crit en C (Squid) et C++ (Dansguardian). Il serait ensuite n´ecessaire de cr´eer un maximum de thread14 effectuant des connexions TCP au serveur Web ainsi qu’une requˆete HTTP afin qu’un nombre consid´erable de connexions TCP soient effecut´ees et que le test refl`ete le fonctionnement normal du reverse-proxy. Il faudrait ensuite que chacun de ces thread contrˆole que le port dynamique source qu’il s’est fait allouer n’a pas d´ej`a e´ t´e attribu´e pr´ec´edemment a` un autre thread. Si ce cas de figure survient, il faudrait que le thread concern´e mette fin a` l’ex´ecution du programme. En relevant le temps d’ex´ecution de ce programme (`a l’aide de la commande time de Linux), il nous serait possible de connaˆıtre pr´ecis´ement le temps n´ecessaire au reverse-proxy pour le parcours de tous ses ports sources allouables. Nous pourrions ainsi le comparer aux r´esultats trouv´es pour une charge maximum (en requˆete par seconde) calcul´ee pr´ec´edemment. Nous serions ensuite dans l’obligation de nous accorder a` l’´el´ement 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 requˆetes que le serveur Web peut traiter, cela signifierait que les calculs effectu´es ci-dessus ne peuvent eˆ tre pris en consid´eration. Ceci signifierait que le reverse-proxy serait plus rapide que le serveur Web et serait capable d’´emettre plusieurs segments TCP de deux connexions diff´erentes avec le mˆeme port source dans l’intervalle de temps d´efini par la rapidit´e du serveur Web (calcul´e ci-dessus). Malheureusement, pour une question de temps a` disposition, nous ne pourrons pas e´ crire un tel programme de test. Nous cr´eons 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 id´ee du temps d’ex´ecution. Cette m´ethode de test effectuera malheureusement des connexions de mani`ere s´equentielle... Le r´esultat nous fournit un temps de 3 minutes et 24 secondes pour effectuer s´equentiellement une requˆete HTTP vers le serveur Web pour attendre sa r´eponse et pour recommencer avec un nouveau port source. Nous remarquons donc que nous sommes bien loin des 11.3 secondes n´ecessaires au serveur Web pour accepter un nombre de connexions e´ gales au nombre de ports sources dynamiques du reverse-proxy. ` approximative15 , nous opterons pour un temps de 15 secondes pour l’interSuite a` cette mesure TRES valle de temps entre l’utilisation du mˆeme port source.

5.5

Sc´enarii d’investigation

5.5.1

Possibilit´es et limites

Avant de d´efinir pr´ecis´ement une m´ethode de corr´elation (diagramme d’´etats permettant la description de celle-ci), il est int´eressant, en fonction de l’architecture a` disposition, de d´efinir les possibilit´es et les limites de la corr´elation : Comme mentionn´e dans Vocabulaire et avant propos du tutorial d’intrusions r´eseaux et d’attaques Web r´edig´e lors du travail de semestre, les attaques Web sont scind´ees en deux familles bien distinctes : 14 15

”Tache” vivant dans l’espace m´emoire d’un autre processus (le programme principal) Provenant du principe de test s´equentiel

60

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

1. Attaques visant le programme serveur offrant le service Web (typiquement Apache ou IIS) 2. Attaques visant les applications h´eberg´ees par le serveur Web : – Script serveur ou r´epertoire connu pour eˆ tre vuln´erable (typiquement les scripts de d´emo deploy´es a` chaque installation du serveur) – Outre-passage de l’authentification mise en place sur un site Web ou modification de l’int´egrit´e du site (base de donn´ee ou pages HTML) La premi`ere sous-cat´egorie des attaques visant les applications serveurs se pr´esente comme facilement d´etectable a` l’aide d’un NIDS puisque ces scripts ou r´epertoires sont r´epertori´es dans les listes d’alarmes du d´etecteur d’intrusions r´eseau. Cette d´etection l`evera malheureusement un grand nombre de faux positifs puisqu’il sera impossible, pour le NIDS, de savoir pr´ecis´ement si le serveur contient ou non le script vuln´erable d´etect´e par le NIDS. La seconde sous-cat´egorie pose quant a` elle certains probl`emes de d´etection puisqu’il est extrˆemement difficile de faire la distinction entre un comportement a` risque et un comportement normal pour des tentatives de SQL injection ou de Cross site scripting par exemple. En effet, le serveur Web n’y verra que du ”feu” (la requˆete s’ex´ecutera sans probl`eme) et des r`egles g´en´eriques sur un NIDS g´en´ereraient un grand nombre de faux positifs lors d’uploads vers le serveur Web par exemple. Deux strat´egies d’investigation compl´ementaires permettent de mettre en e´ vidence ces deux sous-cat´egories : 1. La premi`ere sous-cat´egorie (Script serveur ou r´epertoire connu pour eˆ tre vuln´erable), pourra facilement eˆ tre d´etect´ee a` l’aide d’un NIDS (comme expliqu´e ci-dessus). L’´elimination des faux positifs pourra alors s’effectuer a` l’aide de la r´ecup´eration du status d’ex´ecution des pages d´esir´ees par les clients ou crackers. Cette m´ethodologie a e´ t´e impl´ement´ee dans le cadre de ce projet de diplˆome. Celle-ci est d´ecrite dans la section suivante (section 5.5.2). 2. La seconde sous-cat´egorie ( 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’av´erer utile pour ce genre d’attaques. Comme les NIDS ne peuvent eˆ tre d’une grande utilit´es pour ces cas de figure, il sera int´eressant de d´etecter le d´epassement d’un seuil de requˆetes bloqu´ees sur le reverse-proxy afin d’effectuer une investigation approfondie pour l’adresse IP source d´esir´ee. Cette strat´egie 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 donn´ees via les champs de saisies offerts par la page Web implique souvent un grand nombre de tentatives avant une r´eussite. Cette m´ethode d’investigation ne pourra malheureusement pas eˆ tre impl´ement´ee dans le cadre ce projet de diplˆome puisque le temps a` disposition ne le permettra pas. N´eanmoins, la section 5.5.3 Trac¸abilit´e des comportements a` risque e´ bauchera une solution envisageable. La famille des attaques visant l’application serveur elle-mˆeme pourra eˆ tre d´etect´ee a` l’aide d’une sonde NIDS (d´etection de buffer overflow par exemple). Une investigation plus e´ tendue pourra ensuite eˆ tre effectu´ee sur les alarmes lev´ees par la mˆeme source (adresse IP identique) afin de rechercher un comportement indiquant la r´eussite d’un buffer overflow (ex´ecution de commandes, par exemple).

61

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

5.5.2

Diminution des faux positifs par analyse des requˆetes - r´eponses et du status du serveur Web

Le principe est donc de fournir le meilleur status de r´eussite ou d’´echec de l’attaque possible. Pour ce faire nous allons nous appuyer sur le NIDS post-reverse-proxy et le HIDS r´ecup´erant les logs de refus du serveur Web (erreurs 4xx). A l’aide du contexte de session TCP communes pr´ec´edemment d´ecrit, il nous sera possible de distinguer la r´eponse a` une requˆete. Nous serons donc capable d’observer si la requˆete (d´efinie comme dangeureuse par une alarme du NIDS post-reverse-proxy) a entraˆın´e une r´eponse dangereuse (lev´ee par la mˆeme sonde NIDS). De plus, il nous sera possible d’affiner la dangerosit´e de l’alarme et consultant les logs du serveur Web. En effet, si l’URL demand´ee par la requˆete ayant lev´e une alarme sur le NIDS post-reverse-proxy n’est pas pr´esente dans la liste des alarmes informant des refus du serveur Web (erreur 4xx), l’alarme sera consid´er´ee comme encore plus critique puisque cela signifiera que le serveur Web contient la page cible de l’attaque et qu’il a bien retourn´e une information au client. Il nous a donc e´ t´e possible de dresser un sc´enario g´en´erique16 illustr´e par la figure 5.5. Description du diagramme d’´etat de la figure 5.5 Comme mentionn´e dans la section 5.2.2, le principe de corr´elation mis en place dans le cadre de ce projet de diplˆome s’appuie sur les alarmes proches du serveur Web. Le d´eclencheur sera les alarmes regroup´ees dans le contexte de session TCP communes post-reverse-proxy. Pour commencer, celles-ci seront analys´ees une a` une afin de d´efinir si des alarmes IN17 et/ou des alarmes OUT18 sont pr´esentes dans la session. Plusieurs cas sont d`es lors r´epertoriables : 1. Uniquement des alarmes OUT sont pr´esentes dans la session TCP (point A du diagramme d’´etats) Aucune investigation plus approfondie sur le serveur Web ne pourra eˆ tre effectu´ee sur ce type de session TCP puisqu’aucune URL ne sera pr´esente dans celles-ci. En effet, les alarmes n’indiquent aucune activit´e entrante suspecte alors qu’une activit´e sortante suspecte a e´ t´e relev´ee. Le classement de ces sessions peut d`es lors eˆ tre effectu´e et eˆ tre consid´er´e comme tr`es dangereux. Celles-ci pourraient correspondre a` une attaque pas encore r´epertori´ee (pattern non existant dans le NIDS) ou n´ecessitant plusieurs connexions TCP, alors que la r´eponse a` cette attaque est typiquement connue pour eˆ tre dangereuse. Il s’agit d’une ”opportunit´e” de d´ecouvrir de nouvelles attaques sur le serveur Web a` prot´eger. Il sera donc imp´eratif que le gestionnaire de r´eseau19 prenne le temps d’analyser plus profond´ement ce type d’alarmes afin d’en d´efinir sa dangerosit´e r´eelle. 2. Uniquement des alarmes IN sont pr´esentes dans la session TCP (point 2 du diagramme d’´etats) Une investigation plus approfondie est possible puisque la r´ecup´eration des URLs de ces alarmes est possible. 16

G´en´erique : Car il ne s’appuie pas sur la connaissance d’un sc´enario d’attaque mais plutot sur une m´ethodologie de contrˆole des alarmes 17 En direction du serveur Web 18 En direction du client Web 19 Personne physique

62

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

3. Pr´esence d’alarmes IN et OUT (point 3 du diagramme d’´etats) Une investigation plus approfondie est aussi possible puisque la r´ecup´eration des URLs des alarmes IN pr´esentes est envisageable. L’investigation faisant suite aux points 2 et 3 du diagramme d’´etats sera exactement pareille, a` la diff´erence pr`es, que la dangerosit´e de la session d´efinie a` la suite de cette investigation plus pouss´ee sera ajust´ee en fonction de la pr´esence d’alarmes OUT (diff´erenciant le point 2 du point 3). En effet, la pr´esence d’alarmes OUT dans la session TCP implique souvent la r´eussite de l’attaque, ce qui am`enera a` classifier la session comme plus dangereuse. L’analyse d’investigation effectu´ee pour les points 2 et 3 se diff´erenciera donc par une dangerosit´e plus e´ lev´ee pour les sessions compos´ees d’alarmes IN et OUT (point 3). Celle-ci se pr´esente sous la forme d’un contrˆole d’ex´ecution de la requˆete sur le serveur Web. En effet, le protocole HTTP d´efinit pour chaque requˆete un status de retour (retourn´e au client). Celui-ci est donc enregistr´e dans les fichiers de logs du serveur Web avec l’URL demand´ee. A l’aide de la sonde HIDS dispos´ee sur celui-ci, il nous est possible de r´ecup´erer toutes les lignes de logs a` des URLs non existantes (status code 404) ou non atteintes par le client pour diff´erentes raisons (status code 400, 401, 402, 403, etc..). Pour de plus amples informations sur les status code de retour HTTP, nous vous laisserons consulter 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’´etablissement des r`egles de rapatriement des logs (g´en´eration 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 mani`ere suivante : Chaque alarme IN est contrˆol´ee afin de d´efinir si la requˆete la composant contient bien une URL. Si c’est le cas, une recherche de la mˆeme URL est effectu´ee sur les alarmes du serveur Web afin de d´efinir si la requˆete a e´ t´e ex´ecut´ee ou non. Ceci correspond a` la pr´esence de l’URL dans les alarmes pour une requˆete non ex´ecut´ee et a` son absence pour une requˆete ex´ecut´ee. En fonction de l’ex´ecution ou non de la requˆete du client, une d´ecision de classement de la session TCP est prise, comme l’illustre le diagramme d’´etat de la figure 5.5. La classification des sessions est ensuite d´efinie comme suit : – Alarmes OUT pr´esentes : – Ex´ecution de la requˆete (point E) : La session est consid´er´ee comme extrˆemement critique puisque la requˆete a lev´e une alarme (alarme IN) et que sa r´eponse aussi (alarme OUT). Cet e´ tat est repr´esent´e par Maximum Risk dans l’application de corr´elation. – Non ex´ecution de la requˆete (point D) : La session est consid´er´ee comme tr`es critique puisqu’une alarme OUT est pr´esente. En effet, le serveur Web pourrait tr`es bien avoir refus´e l’acc`es a` l’URL demand´ee et avoir tout de mˆeme e´ t´e compromis lors du traitement de la requˆete (buffer overflow par exemple). Un contrˆole suppl´ementaire (effectu´e par le gestionnaire de r´eseau) est donc n´ecessaire afin d’affiner au maximum les r´esultats critiques fournis par cette analyse. Le cas de non ex´ecution de la requˆete n´ecessite une attention particuli`ere afin de d´eterminer s’il s’agit d’un faux positif ou non.

63

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Le contenu d’une requˆete (alarme IN) d´esign´ee comme dangereuse par le NIDS pourrait, en effet, eˆ tre r´ep´et´ee dans la page d’erreur du serveur Web (alarme OUT), ce qui am´enerait le classement d’une session non dangereuse dans cette cat´egorie. – Alarmes OUT absentes : – Ex´ecution de la requˆete (point C) : La session est consid´er´ee comme tr`es critique puisque la requˆete ayant lev´e une alarme (alarme IN) a e´ t´e ex´ecut´ee par le serveur Web. Il se peut que la r´eponse a` cette requˆete ne paraisse pas dangereuse ou qu’aucun pattern ne la r´epertorie, ce qui expliquerait l’absence d’alarmes OUT. La possibilit´e de faux positif ne doit pas eˆ tre e´ cart´ee puisqu’il pourrait s’agir d’une requˆete consid´er´ee dangereuse pour une ancienne version du serveur Web en question et non dangereuse pour la version patch´ee utilis´ee. – Non ex´ecution de la requˆete (point B) : La session est consid´er´ee comme peu critique (faux positif) puisque le serveur Web ne contient pas ou refuse de fournir l’URL demand´ee par la requˆete consid´er´ee comme dangereuse. La possibilit´e d’attaque r´eelle ne doit cependant pas eˆ tre e´ cart´ee puisqu’il pourrait s’agir d’attaques du genre buffer overflow ne n´ecessitant pas le retour de l’URL demand´ee mais uniquement une partie du traitement de la requˆete par le serveur Web. Nous remarquons qu’un contrˆole suppl´ementaire (effectu´e par le gestionnaire) reste toujours judicieux afin de v´erifier les conclusions fournies par l’algorithme d’investigation.

5.5.3

Trac¸abilit´e des comportements a` risque

Cette m´ethode d’analyse permettra de rep´erer un comportement a` risque sur l’une ou l’autre des sondes et de mener une investigation approfondie sur les diff´erentes alarmes afin de rep´erer un comportement dangereux. Cette strat´egie s’applique donc lors d’une attaque r´efl´echie et pouss´ee (tentatives successives) et non pas lors de l’essai d’un script trouv´e au hasard sur le Web. Le signe avant coureur qui nous permettrait de d´eclencher l’investigation approfondie nous parviendrait de l’HIDS du reverse-proxy (trop grand nombre de requˆetes d’une seule source bloqu´ee par DansguardianSims), du serveur Web (grand nombre de status de refus ou d’erreurs lev´ees par la mˆeme source) ou encore du firewall (scan de ports). Il sera n´ecessaire de d´efinir un seuil sur les diff´erents d´eclencheurs afin de pouvoir d´ecider si une investigation aura lieu. Cette strat´egie serait typiquement applicable pour la d´etection d’outre-passage de l’authentification abord´ee dans la section 5.5.1

5.6

Mise en place de NTP (Network Time Protocol)

Ce protocole permet la synchronisation des horloges syst`emes des machines. Son fonctionnement s’appuie sur une hi´erarchie d’horloges synchronis´ees. Il est donc indispensable de lui indiquer un serveur sur lequel il pourra s’appuyer (ntp01.eivd.ch dans notre cas). Ensuite, chaque station synchronis´ee a` l’aide de NTP pourrait jouer le rˆole de serveur pour d’autres stations en demande de synchronisation. NTP nous permettra d’obtenir un timestamp synchronis´e de toutes les alertes pr´esentes dans la base de

64

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

donn´ees 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 g´en´erant des alertes.

5.6.1

Installation Linux

Pour ce faire, nous utiliserons la commande apt-get install afin de r´ecup´erer les applications n´ecessaires : – ntp, permettant de r´eguler en permanance l’horloge syst`eme (daemon). – ntpdate, permettant de forcer la mise a` jour de l’heure du syst`eme (ex´ecut´e au d´emarrage). Installation du daemon du contrˆole 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 d´emarrage se fera ensuite automatiquement via un script de lancement situ´e dans /etc/init.d/

Configuration Celle-ci s’op`ere via le fichier /etc/ntp.conf. Il suffira donc de pr´eciser l’adresse du serveur maˆıtre (fournissant la synchronisation) en fin de fichier, comme illustr´e 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’´etat 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’extrˆeme gauche de l’affichage (comme illustr´e 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 impl´ementation 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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Configuration La configuration du serveur NTP s’op`ere de la fac¸on suivante a` l’aide d’un shell dos : net time /setsntp:ntp01.eivd.ch

Il est ensuite indispensable de d´emarrer le service a` l’aide de l’interface graphique de la mani`ere suivante : 1. Dans le menu d´emarrer, cliquez sur Settings puis Control Panel 2. Double-cliquez sur Administrative Tools puis sur Services 3. S´electionnez Windows Time dans la liste de service 4. Dans le menu d’action cliquez sur Start pour d´emarrer le service Pour de plus amples informations sur ces deux outils de configuration et sur l’impl´ementation de NTP pour windows 2000, consultez : http ://www.microsoft.com/windows2000/docs/wintimeserv.doc

66

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 5.5 – M´ethode de corr´elation requˆete-r´eponse (session TCP)

67

Chapitre 6

Impl´ementation, installation et tests Ce chapitre pr´esente la partie logiciel de ce projet. Il d´efinit les principes d’impl´ementation utilis´es ainsi que la configuration et l’installation du watchdog et du moteur de corr´elation. De plus, des tests sur le moteur de corr´elation permettront d’observer les capacit´es et les limites du sc´enario d’investigation mis en oeuvre.

6.1

Watchdog de contrˆole d’´etat du/des serveur(s) Web

Comme expliqu´e dans la section 5.3 du chapitre 5, ce watchdog permettra le contrˆole du bon fonctionnement de serveurs Web (plusieurs a` la fois) a` intervalle de temps r´egulier. Il sera capable d’avertir l’administrateur r´eseau (via e-mail) en cas de disfonctionnements et de lui fournir un petit diagnostique. Le watchdog commencera, a` l’aide d’un ping, par d´eterminer si la machine officiant en tant que serveur Web est toujours en fonction. Si ce premier test est concluant, il contrˆolera cette fois-ci le service HTTP. En effet, suite a` une attaque, le service Web peut eˆ tre inop´erant alors que le stack IP du syst`eme d’exploitation du serveur fonctionne toujours (r´eponse aux pings). Deux types de mails (´emis a` l’administrateur r´eseau) sont envisageables : 1. Alerte indiquant que le serveur est hors service (ne r´epond pas aux pings) 2. Alerte indiquant que le service Web est inop´erant Un fichier de log contenant l’historique des tests effectu´es et les erreurs d’ex´ecutions du watchdog (erreurs lors de l’envoi du mail) est conserv´e dans le r´epertoire indiqu´e dans le fichier de configuration.

6.1.1

D´etermination de l’´etat du service Web

Afin de d´efinir si le serveur Web est op´erationnel, il est indispensable, dans le fichier de configuration du watchdog, de fournir non pas l’adresse du serveur mais l’URL compl`ete d’une page Web existante et accessible. Il est e´ videmment pr´ef´erable, si nous avons a` faire a` un site Web non statique, de fournir

68

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

l’URL d’une page dynamique afin de contrˆoler en plus, le bon fonctionnement de l’interpr´eteur1 ou de la machine virtuelle2 du serveur Web . Le watchdog enverra une requˆete 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 r´eponse du serveur sera r´ecup´er´e est ajout´e a` l’e-mail d’alarme envoy´e a` l’administrateur r´eseau. Un diagnostique succint sera ainsi directement possible apr`es lecture du mail.

6.1.2

Installation

´ Etant e´ crit en Perl, son installation requiert les modules suivants : LWP : :UserAgent Pour les requˆetes HTTP. HTTP : :Response Pour le contrˆole de l’´etat des r´eponses HTTP. Net : :SMTP auth Pour l’authentification au serveur de mail. Net : :Ping Pour l’ex´ecution des pings. Net : :DNS Pour les requˆetes DNS avant l’ex´ecution d’un ping. Leurs installations sous Linux peut eˆ tre facilement effectu´ee 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 illustr´e 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 t´el´echargement et la compilation du module se fera automatiquement apr`es le lancement de la commande install. Nous avons ensuite plac´e le watchdog sur le Manager Prelude (/usr/local/watchdog/) et configur´e son lancement en tˆache de fond lors du d´emarrage 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’op`ere a` l’aide du fichier Perl confWatchDog.pl. Les premi`ere directives permettent la configuration du serveur mail, le chemin du fichier de log ainsi que l’intervalle de temps entre deux contrˆoles. Quant a` la derni`ere directive, elle permet d’indiquer les sites Web a` contrˆoler (comme illustr´e ci-dessous) : 1

Software interpr´etant les scripts serveurs (PHP, Perl, etc...) Pour des sites Web e´ crits en Java (Servlets ou JSP) 3 Comprehensive Perl Archive Network 2

69

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

$conf{’webSites’}=["192.168.1.4/securitystore/index.php", "192.168.1.3", "www.monSite.ch/index.jsp"];

6.2

Algorithme de corr´elation et site Web (frontend)

Comme mentionn´e dans le chapitre 5, il ne nous a pas e´ t´e possible, dans le cadre de se travail de diplˆome, d’impl´ementer plusieurs sc´enarii de corr´elation. Cette section d´efinira uniquement l’impl´ementation du sc´enario de corr´elation bas´e sur les sessions TCP post-reverse-proxy communes (d´efini dans la section 5.5.2 du chapitre 5.

6.2.1

Choix du langage et du frontend hˆote

Comme mentionn´e dans la section 5.3 du chapitre 5, l’impl´ementation d’une application temps r´eelle n’a pas e´ t´e possible dans le cadre de ce travail de diplˆome. Nous avons donc d´ecid´e d’ajouter un module a` l’interface Web 4 existante avec Prelude. Nous avons pr´ef´er´e ajouter notre module de corr´elation a` Piwi plutˆot qu’`a l’interface PHP d´evelopp´ee par Patrick Saladino (durant son travail de diplˆome 2003) puisque nous avions comme premi`ere id´ee d’effectuer la corr´elation a` proprement parl´e a` l’aide de SEC5 , logiciel e´ galement e´ crit en Perl. Le langage de programmation commun ne fut pas le seul point d´eterminant de l’int´egration a Piwi. En effet, apr`es avoir explor´e les diff´erents Frontend, il s’est av´er´e que Piwi offrait une grande souplesse dans le tri des alarmes que l’interface d´evelopp´ee par M. Saladino ne permettait pas. Piwi offre la possibilit´e de cr´eer ses propres filtres et permettra de diff´erencier facilement les alarmes en fonction leurs sonde source. Il sera ainsi ais´e d’observer les alarmes en fonction de leur emplacement sur le r´eseau. Il a alors e´ t´e n´ecessaire d’investir un peu de temps dans l’apprentissage du langage Perl puisque mes connaissances en la mati`ere e´ taient inexistantes.

6.2.2

´ Etude de l’interfac¸age avec SEC

Ce logiciel de corr´elation e´ tudi´e dans le chapitre 7, permet de d´efinir un sc´enario de corr´elation d’´ev´enements extraits de fichiers (typiquement de fichiers de logs). Dans un premier temps, l’id´ee est de cr´eer un programme effectuant les recherches dans la base de donn´ees, le rassemblement des sessions TCP commune et le stockage de celles-ci sous forme d’un fichier texte. SEC r´ecup´erera ce fichier afin d’appliquer la corr´elation d´efinie dans son fichier de configuration. le r´esultat retourn´e sera ensuite stock´e dans un second fichier texte que l’application r´ecup´erera pour un affichage sous forme de page Web dynamique. Apr`es une phase de tests, cette m´ethode de travail (par e´ change de fichiers) pourra eˆ tre am´elior´ee puisque comme mentionn´e plus haut, le langage de programmation est identique (Perl). Il sera int´eressant de directement passer une structure de donn´ee (stock´ee en RAM6 ) a` SEC afin d’´eviter une lecture de fichiers 4

Frontend e´ crit en Perl et nomm´e Piwi, http ://www.leroutier.net/Projects/PreludeIDS/ Simple Event Correlator, Logiciel open source permettant la d´efinition de sc´enarii de corr´elation d’´ev´enements http ://sixshooter.v6.thrupoint.net/SEC-examples/article.html 6 M´emoire vive de l’ordinateur (Random Access Memory) 5

70

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

coˆuteuse en temps processeur. Apr`es une e´ tude plus approfondie de SEC (relat´ee dans le chapitre 7), il s’est av´er´e quasiment impossible de l’int´egrer dans l’application envisag´ee (comme expliqu´e ci-dessus). En effet, nous avonc remarqu´e que cette application e´ tait vraiment vou´ee a` une utilisation temps r´eel puisque presque la totalit´e des r`egles ´ a` disposition utilisent une notion de temps. Etant donn´e que notre application se voue a` une analyse (corr´elation) a` post´eriori, il ne sera pas possible d’int´egrer SEC dans le cadre ce projet. Le chapitre 7 traitant de SEC offrira n´eanmoins des exemples d’utilisation pratique, afin d’offrir un petit aperc¸u de la capcit´e de cet outil de corr´elation.

6.2.3

Architecture logiciel

Le paradigme de programmation utilis´e est proc´edural puisque l’apprentissage de la programmation orient´ee objets en Perl aurait e´ t´e trop couteuse en temps. Il est e´ vident que si l’application venait a` eˆ tre am´elior´ee par l’ajout de nouveaux sc´enarii de corr´elation, il serait avantageux de reprendre celle-ci afin de la faire migrer vers un paradigme orient´e objets. En effet, un tel paradigme offre une r´eutilisation facilit´ee des objets d´ej`a d´efini. Il serait ainsi beaucoup plus ais´e, pour les personnes d´esireuses d’ajouter une nouvelle fonctionnalit´e au moteur de corr´elation, de le faire en impl´ementant simplement un nouvel objet. L’application de corr´elation peut tout de mˆeme eˆ tre d´ecoup´ee en plusieurs fichiers correspondant a` diff´erents niveaux. La figure 6.1 illustre l’architecture e´ labor´ee.

F IG . 6.1 – Structure du logiciel de corr´elation d´evelopp´e

71

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– Communication avec la base de donn´ee, dataBasee.pl – Recherche des sessions TCP, contextes.pl – Correlation par l’algorithme d´efinit 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 donn´ees. Celles-ci retourneront des structures de donn´ees d´ecrites dans les entˆetes du code source (tables de hash ou tableaux). Il est important de noter que les proc´edures setConf() et setTime() font offices de ”constructeurs”. En effet, il serait ab´erant de r´ecup´erer toutes les alarmes de la base de donn´ee pour effectuer la corr´elation des alarmes de la journ´ee. La proc´edure setTime(), permet de figer l’heure afin que les diff´erentes fonctions d’acc`es a` la base de donn´ee utilisent une heure commune. Le hash $conf’fenetreCorrelation’ contenu dans le fichier de configuration permettra ensuite de d´efinir la fenˆetre de corr´elation a` appliquer. Certaines fonction (d´efinies dans la deuxi`eme partie du code) ne n´ecessitent aucune initalisation temporelle (setTime()), puisque elles effectuent une recherche sp´ecifique dans la base de donn´ees. Le fichier contextes.pl impl´emente l’algorithme de recherche des sessions TCP post-reverse-proxy communes. Il n´ecessite les fonctions d’acc`es a` la base de donn´ee afin que l’algorithme d´efinit dans la section 5.4.1 du chapitre 5 soit applicable. Son utilisation est similaire a` dataBase.pl puisqu’il sera n´ecessaire de l’initialiser a` l’aide des proc´edure init() et setConf(). Celles-ci on pour effet d’effectuer toutes les requˆete n´ecessaires a` la base de donn´ees afin de pouvoir fournir rapidement les structures de donn´ees n´ecessaire a` l’algoritme de reconstitution des session TCP. De plus, les structures de donn´ees n´ecessaire a` l’algorithme de corr´elation et a` l’affichage des informations d’une sessions TCP seront disponibles via les fonctions d´efinies dans ce fichier. De cette mani`ere un seul acc`es a` la base de donn´ee (effectu´e via l’appel a` init()) sera n´ecessaire. Le fichier correlation.pl impl´emente le diagramme d’´etat d’investigation pr´esent´e dans la section 5.5 du chapitre 5. Il fournit une fonction retournant un tableau indiquant la dangerosit´e de chaque sesison TCP. Son pseudo code est pr´esent´e 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’ex´ ecution 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 ´ et´ e refus´ ee par le serveur{ /* afin de garder la dangerosit´ e la plus ´ elev´ ee de la session */

72

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Si la dangerosit´ e de la session courante n’est pas plus ´ elev´ ee{ la dangerosit´ e de la session vaut: peu critique } } sinon{ la dangerosit´ e de la session vaut: tr` es critique } } sinon{ la dangerosit´ e de la session vaut: ind´ etermin´ e (pas d’URL disponnibles) } } /* ajustement de la dangerosit´ e en fonction du sens des alarmes */ Si il y a que des alarmes IN{ Si la dangerosit´ e de la session a ´ et´ e d´ etermin´ ee comme tr` es critique{ dangerosit´ e de la session = C } sinon{ dangerosit´ e de la session = B } } /* il y a alors des alarmes IN et OUT */ sinon{ Si la dangerosit´ e de la session a ´ et´ e d´ etermin´ ee comme peu critique{ dangerosit´ e de la session = D } sinon{ dangerosit´ e de la session = E } } }

Le fichier showCorrelation.pl impl´emente l’interface graphique permettant l’interaction du gestionnaire de r´eseau avec le moteur de corr´elation. Celui-ci n´ecessite l’inclusion du module CGI permettant l’interfac¸age avec le serveur Web. Pour de plus amples informations sur l’impl´ementations et les structures de donn´ees utilis´ees, le lecteur averti pourra se plonger dans le code source disponnibles sur le CD du projet.

6.2.4

Installation

Le moteur de corr´elation et son interface graphique sont pr´evu pour s’ex´ecuter du cˆot´e serveur. Il est donc n´ecessaire de disposer d’un serveur Web supportant Perl. L’installation du moteur de corr´elation doit imp´erativement eˆ tre effectu´ee dans le r´epertoire de l’interface Web de Piwi puisqu’il n´ecessite un fichier de configuration communs et certaines librairies d’acc`es au SGBD. L’installation de Piwi est d´etaill´ee a` l’adresse suivante : http ://www.leroutier.net/Projects/PreludeIDS/Demo/Docs/INSTALL.txt

73

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Pour l’installation du moteur de corr´elation, il vous suffira d’ajouter le r´epertoire 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 remplac´e par celui fournit avec le moteur de corr´elation afin qu’un lien vers celui-ci soit disponnible dans l’interface existante de Piwi. ´ Etant donn´e que le fichier de configuration du moteur de corr´elation est d´efini dans celui de Piwi racinePiwi/Functions/config.pl, il est indispensable de le remplacer par celui fournit avec les sources du moteur de corr´elation.

6.2.5

Configuration

La premi`ere partie du fichier de configuration contenue dans racinePiwi/Functions/config.pl permet le r´eglage de Piwi, alors que la seconde permet la configuration du moteur de corr´elation d´evelopp´e dans le cadre de ce travail de diplˆome. Comme Perl est un langage interpr´et´e7 , la configuration du moteur de corr´elation se pr´esente sous la forme d’une table de hash. Les modifications apport´ee a` ce fichier seront ainsi directement prise en compte lors de l’utilisation du programme. La premi`ere partie de la configuration du moteur de corr´elation n´ecessite les identificateurs des diff´erentes sondes. Ceux-ci sont disponnibles dans le fichier /etc/prelude-sensors/sensors.ident de chaques sondes. Les directives suivantes sont expliqu´ees ci-dessous : $conf’TcpSessionDuration’ Permet la configuration de la dur´ee d’une session TCP post-reverse-proxy. Celle-ci sera utilis´ee pour la recherche des sessions communes et la cr´eation du contexte de session TCP communes. $conf’portServeur’ Permet de pr´eciser le port d’´ecoute du serveur Web a` prot´eger. $conf’ipServeur’ Permet de pr´eciser l’adresse IP du serveur Web. $conf’ipProxy’ Permet de pr´eciser l’adresse IP du reverse-proxy. $conf’fenetreCorrelation’ Permet de pr´eciser la fenˆetre de corr´elation a` utiliser. Il s’agira du nombre de secondes a` analyser depuis le lancement du moteur de corr´elation. $conf’timeIntervalHidsNids’ Permet de pr´eciser le temps de recherche de l’URL des alarmes du NIDS post-reverse-proxy sur les logs du serveur Web. $conf’timeIntervalFindingIP’ Permet de pr´eciser le temps de recherche du mˆeme type d’alarme entre le NIDS post-reverse-proxy et pre-reverse-proxy afin de d´eterminer l’adresse IP r´eelle de l’attaquant. Le fichier de configuration utilis´e dans le cadre de ce projet est disponnible dans les Annexes, section A.5. 7

N´ecessitant aucune compilation

74

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

6.2.6

Utilisation

Aucun manuel d’utilisation du moteur de corr´elation n’a e´ t´e r´edig´e, puisque son interface Web se pr´esente sous forme didactique. En effet le diagramme d’´etats du sc´enario d’investigation mis en place est disponnible via cette interface. L’utilisateur d´esireux d’obtenir des informations d´etaill´ees sur les niveaux de dangerosit´e utilis´es, aura la possibilit´e 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 diff´erents sondes pr´esentes.

F IG . 6.2 – Interface Web d’accueil du management de l’architecture Web (permettant de d´emarrer la corr´elation) La figure 6.3 illustre l’affichage des r´esultats d’une corr´elation.

75

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 6.3 – Interface Web affichant les r´esultats de la corr´elation

6.3

Tests du moteur de corr´elation

Cette partie relate les diff´erents essais effectu´es sur le moteur de corr´elation. En effet, nous avons proc´ed´e en deux phases : 1. Tests d’attaques sp´ecifiques 2. Tests a` l’aide de scans Nessus8 Le test d’attaque sp´ecifique nous a permis d’observer le comportement du moteur de corr´elation aux attaques pr´evues et d’en corriger son fonctionnement si besoin e´ tait. Le test a` l’aide d’un scan Nessus nous a permis de d´eterminer l’efficacit´e du moteur de corr´elation a` l’´elimination des faux positifs. La figure 6.5 illustre bien l’´elimination d’un grand nombre de faux positifs puisque toutes les sessions repr´esent´ees par une dangerosit´e de couleur verte repr´esente un faux positif. Nous avons alors analys´e (manuellement) la majorit´e de ces alarmes afin de contrˆoler l’efficacit´e de l’applicatif d´evelopp´e. La figure 6.6 illustre quant a` elle la d´etection d’une session TCP post-reverse-proxy tr`es dangereuse (ex´ecution de commandes sur le serveur Web via cmd.exe). Nous remarquons bien la d´etection de la totalit´e de la session puisqu’il est possible d’observer via diff´erentes alarmes : L’acc`es au fichier cmd.exe 8

Scanner de vuln´erabilit´es open source

76

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 6.4 – Interface Web permettant de visualiser l’algorithme de corr´elation utilis´e ainsi que le retour de l’ex´ecution de la commande (listage d’un r´epertoire). D’autres tests ont ensuite e´ t´e effectu´es afin de v´erifier le bon fonctionnment du moteur de corr´elation. Ceux-ci ne seront pas illustr´es dans cette section puisqu’ils seront pr´esent´es lors de la d´efense du projet le 19 janvier 2005, a` l’EIVD (B01b a` 10h).

77

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 6.5 – R´esultat de la corr´elation permettant d’´eliminer un grand nombre de faux positifs

F IG . 6.6 – R´esultat de la corr´elation retrouvant une session TCP dangereuse

78

Chapitre 7

Descriptif et utilisation de SEC 7.1

Description

SEC est un logiciel Open Source r´ecup´erant le flux d’entr´ee d’un fichier texte ou d’un pipe1 afin d’y appliquer une d´etection de pattern selon des r`egles d´ecrites dans un fichier de configuration. SEC dispose de diff´erents directives de configuration permettant une utilisation vari´ee (analyse de logs, machine d’´etats, logique, etc...). Ces directives de configuration fonctionnent principalement a` l’aide de fenˆetres temporelle. Il sera facile de le configurer pour un traitement en temps r´eel. En effet, nous avons tent´e dans le cadre de ce projet, de le configurer pour une corr´elation de logs a` post´eriori. Ceci c’est tr`es rapidement averr´e impossible puisque la gestion de conditions sans aucune notion de temps n’est vraiment pas ais´ee. Nous allons maintenant e´ tudier quelques petits exemples permettant d’illustrer le fonctionnement temps r´eel d’une corr´elation 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’entr´ee. Voici le descriptif de cette configuration : 1

R´ecup´eration d’un flux de sortie d’une commande

79

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

type Permet de pr´eciser le genre de r`egles a` utiliser. Nous somme ici en pr´esence d’une simple r`egle de recherche de pattern. ptype Permet de pr´eciser le pattern type utilis´e pour la recherche d’une suite de caract`eres (dans notre cas a` l’aide d’expressions r´eguli`eres). pattern Indique le pattern a` rechercher (`a l’aide du ptype mentionn´e pr´ec´edemment). Dans ce cas, une expression r´eguli`ere. desc Permet la description de l’´ev´enement. $0 repr´esente le pattern total d´etect´e a` l’aide de l’expression r´eguli`ere de la directive pattern. action Indique l’action a` entreprendre lorsque la r`egle s’applique. Dans ce cas, la description sera envoy´ee dans un fichier de log (si un fichier est mentionn´e au lancement) sinon la sortie standard (le shell). Son ex´ecution s’op`ere ensuite de cette mani`ere : % perl sec.pl -conf=essai.conf -input=-

La directive input=- indique que le flux d’entr´ee n’est rien d’autre que le shell courant (entr´ee standard). Apr`es son lancement, nous remarquons que d`es que nous entrons le mot foo suivi d’un espace (dans le shell), la totalit´e de la ligne entr´ee est r´ep´et´ee 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 apr`es les autres en regardant si celles-ci s’appliquent au pattern courant. Il sera ainsi possible de chaˆıner plusieurs groupe de r`egles dans le mˆeme 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 r` egle type=Single ptype=RegExp pattern=bar desc=$0 action=write - $0 is matched. # Cette r` egle r´ ecup` ere le pattern ´ ecrit (baz) par la r` egle 1 type=Single ptype=RegExp

80

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

pattern=baz desc=$0 action=write - %s matched

Trois r`egles sont maintenant d´efinies. La premi`ere utilise l’action event permettant la cr´eation d’´ev´enements internes a` SEC (apr`es un temps d´etermin´e ici 5 secondes), r´ecup´erables par les autres r`egles. Nous remarquons qu’il est possible de cumuler diff´erents e´ v´enements a` l’aide d’un point virgule. L’action write - aura pour effet d’´ecrire le texte qui suivra sur la sortie standard (le shell dans ce cas). La seconde r`egle fonctionne de la mˆeme mani`ere que l’exemple pr´ec´edent. C’est donc pour cette raison que nous n’allons pas plus la d´etailer. La troisi`eme r`egle d´etectera l’´ev´enement contenant le pattern baz (g´en´er´e par la premi`ere r`egle) qui sera ensuite e´ crit sur la sortie standard (%s indiquant la r´ecup´eration de la description). Apr`es ces petits exemples d’utilisation il est int´eressant d’observer les diff´erents types de r`egles disponibles avec SEC : Single Lorsque l’´ev´enement d´efini par pattern est d´etect´e, une action est ex´ecut´ee. SingleWithScript Lorsque l’´ev´enement d´efini par pattern est d´etect´e et qu’un script externe retourne une certaine valeur de retour, une action est ex´ecut´ee. SingleWithSuppress Lorsque l’´ev´enement d´efini par pattern est d´etect´e, une action est ex´ecut´ee et les prochains e´ v´enements sont ignor´es pendant t secondes. Pair Lorsque l’´ev´enement d´efini par pattern est d´etect´e, une action est imm´ediatement ex´ecut´ee. Pendant les t prochaines secondes les e´ v´enement entrants seront ignor´es, jusqu’`a l’arriv´ee d’un second e´ v´enement qui ex´ecutera une seconde action. PairWithWindow Lorsque l’´ev´enement d´efini par pattern est d´etect´e un time out est d´eclench´e dans l’attente d’un second e´ v´enement. Si ce second e´ v´enement arrive (dans la fenˆetre d´efinie par le time out) une action est ex´ecut´ee. Si le second e´ v´enement n’arrive pas dans la fenˆetre mentionn´ee, une seconde action sera ex´ecut´ee. SingleWithThreshold Compte le nombre d’´ev´enements d´efini par la directive pattern durant t secondes. Lorsqu’un nombre suffisant d’´ev´enements est d´etect´e, une action est effectu´ee et le compteur d’´ev´enements est remis a` z´ero. SingleWith2Thresholds Compte le nombre d’´ev´enements d´efini par la directive pattern durant t secondes. Lorsqu’un nombre suffisant d’´ev´enements est d´etect´e, une action est effectu´ee. Le compteur d’´ev´enements n’est pas remis a` z´ero et lorsqu’un nouveau seuil est atteint en moins de t’ secondes une seconde action est ex´ecut´ee. Suppress Supprime des e´ v´enement entrant. Calendar Ex´ecute une action a` une date sp´ecifi´ee. A l’aide des deux exemples ci-dessus, ainsi que de la description des diff´erents types de r`egles disponibles, ll nous est d´ej`a possibles d’entrevoir les possiblit´es offertes par SEC.

81

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Imaginez maintenant que les logs d’acc`es a` un serveur Web soient rapatri´es (via syslog de Linux) dans le mˆeme fichiers que les logs d’une sonde Snort. Il serait alors possible d’´etablir le mˆeme genre de sc´enario d’investigation mis en place dans le cadre de ce projet (contrˆole du status d’ex´ecution de chaque requˆete critique sur le serveur Web) en fonctionnement temps r´eel.

7.3

Conclusion

Grˆace a` l’´etude de l’association de SEC avec notre moteur de corr´elation, il nous a e´ t´e possible d’entrevoir les capacit´es d’analyse temps r´eel qu’offre cet outil. Son utilisation pourrait tout de mˆeme eˆ tre envisag´ee dans l’architecture propos´ee afin de permettre une analyse temps r´eel d’´ev´enement tr`es critiques offrant un syst`eme d’alerte rapide en cas de gros probl`emes.

82

Chapitre 8

Panorama de l’offre actuelle Ce chapitre pr´esente quelques solutions existantes d’IDS offrant une corr´elation des informations r´ecolt´ees. Il sera ainsi possible d’observer et comparer quelques solutions existantes sur le march´e.

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 mˆeme phylosophie (open source) afin d’y int´egrer une infrastructure de monitoring. Cette application a comme objectif principal, d’am´eliorer la visualisation de la masse d’alarmes (´emises par diff´erentes sondes). En effet le probl`eme principal du management d’alarmes provient : 1. Du volume de donn´ee e´ mises par les diff´erentes sondes 2. De la relation inexistante entre les diff´erentes alarmes

8.1.1

Description

L’objectif principal d’OSSIM est de fournir un syst`eme centralis´e, organis´e permettant l’am´elioration de la d´etection d’attaques ainsi que l’affichage organis´e d’´ev´enements de s´ecurit´e. OSSIM poss`ede les outils d’affichages suivants : – Fenˆetre de contrˆole pour les alarmes de haut niveau – Fenˆetre de contrˆole pour l’affichage des risques et de l’activit´e de niveau interm´ediaire – Fenˆetre de contrˆole pour l’affichage des risques r´eseaux de bas niveau Ces diff´erents outils utilisent des m´ethodes d’analyses am´eliorant la d´etection de relations entre les e´ v´enements. Celles-ci peuvent eˆ tre d´ecompos´ees en : – Corr´elation – Mise en place de niveaux de priorit´e 1

disponible sur : http ://www.ossim.net/

83

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– Evaluation des risques OSSIM pr´evoit la r´ecup´eration d’informations de diff´erents d´etecteurs. En effet il est capable de r´ecup´erer et d’utiliser les informations d’IDS, de d´etecteurs d’anomalies, de firewalls et d’une vari´et´e d’autres e´ l´ements r´eseaux. Finalement il fournit un outil d’administration permettant de configurer et d’organiser les modules utilis´es (externes et natifs). Cet outil permet la d´efinition de la topologie utilis´ee, des polices de s´ecurit´e, des r`egles de corr´elation et fournit les liens vers une vari´et´e d’outils existants int´egr´es a` OSSIM

F IG . 8.1 – Architecture d’OSSIM Nous observons sur la figure 8.1, les diff´erents composants logiciel d’OSSIM. Nous remarquons l’utilisation de plusieurs base de donn´ees interm´ediaires, d´ecrites ci-dessous : EDB La base de donn´ees d’´ev´enements. Celle-ci est la plus volumineuse puisqu’elle stockera tous les e´ v´enements individuel rec¸u par les d´etecteurs. KDB La base de donn´ees de configuration. Celle-ci stockera les polices de s´ecurit´e ainsi que les param`etres li´es a` l’architecture r´eseau. UDB La base de donn´ees des profiles. Celle-ci stockera toutes les informations g´en´er´ees par le moniteur de profile.

8.1.2

M´ethodes d’analyses utilis´ees

Le proc´ed´es de d´etection d’alarmes et de r´ecolte de celles-ci repose sur des solutions existantes. En effet, rien de nouveau n’a e´ t´e mis en place dans le domaine. OSSIM apporte alors une nouvelle solution pour tout ce qui touche au post-processing2 . Trois m´ethodes d’analyse a` post´eriori sont appliqu´ees : 2

Analyse des informations apr`es leur r´eception

84

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

1. Les alarmes sont class´ees suivant une priorit´e d´efinie par les polices de s´ecurit´es mises en place sur l’architecture 2. La menace de chaque alarme est ensuite e´ valu´ee en fonction des e´ l´ements en dangers et de la probabilit´e de risque qu’il en d´ecoule 3. Une corr´elation est ensuite appliqu´ee afin de regrouper des alarmes ind´ependantes entre elles en e´ v´enement hostiles Pour l’´etape de corr´elation, deux m´ethodes ont e´ t´e d´eploy´ees : Bas´ee sur l’heuristique Cette m´ethode offrira une e´ valuation du risque comparable a` un ”thermom`etre”. Il sera ainsi possible, en tous temps, d’observer la ”temp´erature” de la s´ecurit´e du r´eseau. Pour ce faire, le risque a e´ t´e s´epar´e en deux cat´egories : Le risque que la machine soit compromise (risque nomm´e C), le risque potentiel d’une attaque sur cette machine (nomm´e A). A l’aide de ces deux types de risque, il sera possible a` l’aide d’un algorithme (CALM3 ), de d´efinir l’´etat global de s´ecurit´e de l’architecture. Bas´ee sur des diagrammes d’´etats Cette m´ethode permet la cr´eation de diagrammes d’´etats du type : ”Si l’´ev´enement A et B sont d´etect´es, effectuer l’action C”. A la suite des ces diff´erentes e´ tapes, OSSIM propose une visualisation des risques sous forme de page Web. Les figures suivantes illustrent l’interface propos´ee :

F IG . 8.2 – Console de monitoring (affiche des statistiques d’une semaine) 3

Compromise and Attack Level Monitor

85

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 8.3 – Console de monitoring (affichage en temps r´eel du trafic Web, selon l’algorithme d’heuristique)

8.2

Open security management

La soci´et´e Open4 , sp´eciali´ee dans la corr´elation d’alertes de s´ecurit´e en temps r´eel propose diff´erents produits de s´ecurit´e. Leur Security Threat Manager est une application de gestion de la s´ecurit´e qui met en oeuvre une couche d’intelligence entre les e´ quipements de s´ecurit´e et ceux qui sont en charge de leur administration. La figure 8.4 illustre le principe de corr´elation mis en place par Open security. Le STM5 transforme les capteurs d’´ev´enements d´eploy´es sur les e´ quipements de s´ecurit´e en un ensemble unifi´e. Pour ce faire, STM corr`ele les donn´ees rec¸ues afin de fournir un syst`eme d’alertes temps r´eel pour des administrateurs r´eseaux. STM combine l’int´egralit´e des donn´ees de vuln´erabilit´es et des e´ v´enements de s´ecurit´e des e´ quipements et vous offre une vision globale de risques. 4 5

http ://www.open.com/products/security-threat-manager.jsp Security Threat Manager

86

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

F IG . 8.4 – Principe d’analyse et de corr´elation mise en place par Open security management

8.2.1

Description

La corr´elation d´efinie par STM utilise les caract´eristiques suivantes : – Associe automatiquement les attaques aux vuln´erabilit´es et la valeur de la cible – Rapporte les menaces sur la base du risque d’attaque et de l’impact sur les activit´es de l’entreprise – Relie les e´ v´enements de multiples e´ diteurs et capteurs – Extensible et personnalisable : – Modification de l’interface par utilisateur – Sauvegarde, planification et impression de rapports de vuln´erabilit´es pour des analyses en temps r´eel ou a` post´eriori Le moteur de corr´elation est bas´e sur NerveCenter, outil de corr´elation utilisant une machine d’´etats. Les algorithmes int´egr´es ne requierent aucunes maintenance des r`egles et utilisent des donn´ees directement stock´ee en m´emoire afin de tendre vers une utilisation le plus temps r´eel que possible.

87

Chapitre 9

Conclusion Durant ces trois mois de travail de diplˆome, il nous a e´ t´e offert d’effectuer diff´erentes tˆaches aussi vari´ees qu’int´eressantes. En effet, nous avons eu le plaisir d’effectuer les travaux suivants : ´ – Etudier et comparer diff´erents reverse-proxys – Programmer en C++ (modification du code source de Dansguardian) – D´eployer une architecture r´eseau compl`ete (Firewall, reverse-proxy, serveurs Web, gestion des logs, etc...) ´ et appliquer une corr´elation d’´ev´enements a` notre architecture r´eseau – Etudier – Programmer en Perl (conception d’un moteur de corr´elation de d´emonstration) Nous estimons avoir atteint notre but, puisque la quasi totalit´e du cahier des charge a e´ t´e remplie. Le lecteur attentif aura remarqu´e que l’´etude des diff´erentes attaques r´eseaux et Web (point I.b du cahier des charges) ne figure pas dans ce rapport, puisqu’un tutorial lui a e´ t´e d´edi´e lors du travail de semestre1 . Ce travail de diplˆome ne peut en aucun cas pr´etendre avoir fait le tour du sujet. En effet, la corr´elation d’´ev´enements reste un domaine en pleine e´ volution et en recherche de solutions efficaces. Il serait int´eressant 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 tr`es utile de deployer et tester l’application de gestion d’intrusions Open Source OSSIM2 puisqu’il ne nous a pas e´ t´e possible de le faire dans le cadre de ce projet (la d´ecouverte 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 d´efinir ses propres scenarii d’investigations sans eˆ tre un programmeur chevronn´e. D’un point de vue plus personnel, ce travail m’a permis d’´elargir mes connaissances en s´ecurit´e r´eseau, configuration d’´el´ements r´eseaux et gestion de la d´etection d’intrusions. Ces diff´erents domaines m’ont 1 2

Travail fournit en annexe a` ce rapport Application d´ecrite dans le chapitre 8

88

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

donn´e une forte envie d’approfondir mes connaissances en la mati`ere. C’est pour cela que j’envisage fortement une formation plus pouss´ee dans le domaine.... Yverdon-les-Bains, le 17 d´ecembre 2004

Jo¨el Winteregg

89

Chapitre 10

Remerciements et r´ef´erences 10.1

Remerciements

Je tiens a` remercier tr`es chaleureusement les personnes suivantes pour leur soutien ainsi que pour leur aide apport´ee a` l’´elaboration de ce projet : Cyril Friche Pour les conseils, les informations sur SEC et la relecture. Stefano Ventura Pour diff´erents conseils et la validation des id´ees. G´erald Litzistorf Pour les conseils de corr´elation appliqu´ee a` l’architecture mise en place. Christian Tettamanti Pour les coups de pouces sous Linux. Sylvain Maret Pour les conseils d’architecture r´eseau. Yann Souchon Pour les conseils sur la mise en place du reverse-proxy Squid. J´erˆome Caillet Pour diff´erentes conseils et les e´ changes d’id´ees Rapha¨el Lienhard Pour diff´erents conseils et les e´ changes d’id´ees Famille Winteregg Pour la relecture et la correction orthographique.

10.2

R´ef´erences

– Livre Snort 2 de Jack Koziol, e´ dit´e 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 r`egles pour Prelude-lml (hids) : http ://www.leroutier.net/Projects/PreludeIDS/

90

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– Installation : http ://entreelibre.com/scastro/prelude/preludeLML-secured-installation howto.txt – Reverse-proxy AppShield : Rapport de diplˆome ”Securit´e 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’impl´ementation 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 tˆaches journali`eres via Cron : http ://www.commentcamarche.net/tutlinux/lincron.php3 – Dansguardian : – Principe de fonctionnement : http ://dansguardian.org/ ?page=dgflow

91

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

– Guide d’installation : http ://dansguardian.org/downloads/detailedinstallation2.html – Configuration : http ://linsec.ca/bin/view/Main/DansGuardian – Rating HTML utilis´e 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 corr´elation : – Exemple de corr´elation par SANS : http ://www.sans.org/resources/idfaq/role.php – Exemple d’application : http ://www.securityfocus.com/infocus/1708 – Outil de corr´elation Open : http ://www.hermitagesolutions.com/public/pages/32092.php – Solution open source de corr´elation : http ://www.ossim.net/whatis.php – SEC, outil de corr´elation d’´ev´enements : 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

ˆ horaire Planning et cout

Apr`es une partie th´eorique 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´ t´e n´ecessaire de configurer tous les e´ l´ements r´eseaux utilis´es. Apr`es cette partie de mise en place forte int´eressante, il nous a e´ t´e possible d’observer les comportements du r´eseau (surtout des sondes) face a` diff´erentes attaques. C’est ainsi qu’il nous a e´ t´e possible d’´etablir un sc´enario d’investigation que nous avons impl´ement´e sous forme de site Web dynamique en Perl. Le tableau suivant relate en coˆut horaire le travail effectu´e :

93

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

Activit´es Correction du travail de semestre et installation du syst`eme d’exploitation pour le reverse-proxy Documentations sur Snort et r´edaction de la comparaison avec Prelude-IDS ´ Etude, installation et tests de Squid ´ Etude, installation et tests de Dansguardian Modification du code source de Dansguardian R´edaction et tests de Dansguardian ´ Etude de l’URL rewriting a` l’aide de Squid, installation HIDS du reverse-proxy ´Etude sonde HIDS (Prelude-lml) et installation du serveur Web vuln´erable (IIS) Cr´eation des r`egles du HIDS et d’une blacklist a` l’aide de Nessus et d’Ethereal Mise en place du firewall, de l’architecture totale et r´edaction du rapport Mise en place de la rotation des logs et documentation sur la corr´elation Documentation sur la corr´elation et mise en place de NTP ´ Etude d’une corr´elation appliqu´ee a` notre architecture ´ Etude de SEC et de son interfac¸age avec le moteur de corr´elation Apprentissage de Perl et de l’utilisation des CGI ´ Etude de la d´etection des sessions TCP communes et impl´ementation du moteur de corr´elation Impl´ementation du moteur de corr´elation et r´edaction du rapport Tests du moteur de corr´elation et r´edaction du rapport R´edaction du rapport

Dur´ee [semaine] 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 1.0 1.0 0.5 0.5 0.5 0.5 0.5 1.0 1.0 0.5 1.0

Total

12.0 semaines

A.2

Fichiers de configuration des sondes du reverse-proxy

La configuration d’une sonde s’op`ere en deux parties. La premi`ere consiste a` configurer le sensors1 a` l’aide du fichier /etc/prelude-sensors/sensors-default.conf. Il permettra de d´efinir l’adresse du manager, le type de machine h´ebergeant le sensors ainsi que son emplacement. Il s’agit donc d’une configuration globale d’un sensors (ind´ependante de son type). La seconde consiste en la configuration de la sonde elle mˆeme (NIDS ou HIDS). Il s’agira de d´efinir, dans le cas d’une sonde HIDS, les fichiers de logs a` analyser ainsi que les r`egles a` utiliser. Dans le cas d’une sonde NIDS, il sera possible de s´electionner les plugins a` utiliser.

A.2.1

Configuration du sensor

Fichier de configuration global du sensor. Situ´e 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 ind´ependante du type de sonde utilis´ee (NIDS ou HIDS)

94

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # # # # # # #

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. # manager-addr = 192.168.1.5;

# Configuration for the UDP message receiver. # commented out by default since most people only want to # monitor files.

95

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # [Udp-Srvr] # # port = 514 # addr = 0.0.0.0

# # Files to monitor # #Fichier de r´ eception des logs de IIS file = /var/log/messages #Fichier des logs d’acc` es 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 r`egles a` utiliser Fichier de configuration des r`egles (pattern matching) a` utiliser. Celui-ci est pr´ecis´e dans le fichier de configuration du HIDS par la directive ruleset=¡chemin¿/fichierDesR`eglesAUtiliser.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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

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. There can be more than one. - 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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# target.user.userid.name: # A user or group name. # # - source.user.userid.number, # target.user.userid.number: # A user or group number. #fichier de r` egles de r´ ecup´ eration des logs de dansguardian include = dansguardian.rules; #fichier de r` egles de r´ ecup´ eration des erreurs 4xx de IIS include = iis.rules;

R`egles (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; \ impact.severity=high; \

98

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

impact.completion=failed; \ impact.type=other; \ impact.description=$1 Web client try to request $2, but his client IP is denied; \ #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; \ #fournit l’URL enti` ere demand´ ee comme adresse de destination target.node.address.address=$2; \ target.service.port=80; \ target.service.protocol=http;

##################################################################### # 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.severity=high; \ impact.completion=failed; \ impact.type=other; \ impact.description=$1 try to access a denied file extension. URL: $2; \ #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; \ #fournit l’URL enti` ere demand´ ee comme adresse de destination target.node.address.address=$2; \ target.service.port=80; \ target.service.protocol=http;

##################################################################### # 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*

regex=([\d+\.]+) http://(.*)\s\*DENIED\*\s\sPOST; \ class.name=Dansguardian Reverse-proxy: DENIED POST data sent to Web server; \ impact.severity=high; \ impact.completion=failed; \ impact.type=other; \ impact.description=Url: $2 requested by $1 had dangerous POST content; \ #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;

R`egles (pattern matching) de Prelude-lml pour IIS Ce fichier se trouve a` : /etc/prelude-lml/ruleset/iis.rules

99

POST 0

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

##### # # 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: # Jo¨ el 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.completion=failed; \ impact.type=other; \ impact.description=URL: $5 requested by $1 on the $2 web server throw a $6 error; \ #attention, obligatoire pour un bon fonctionnement source.node.address; \ source.node.address.address=$1; \ source.node.address.category=ipv4-addr; \ source.service.protocol=http; \ target.node.address; \ target.node.address.category=ipv4-addr; \ target.node.address.address=$2; \ target.service.port=$3; \ target.service.protocol=http;

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] # # # # # #

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

100

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# default address for this sensor by uncommenting this entry. # manager-addr = 192.168.1.5;

# 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;

#################################### # Here start plugins configuration # #################################### [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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # # # # #

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] # # This plugin issue an alert for each packet. # Carefull to the loging activity it generate.

[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= <macaddr>;

Configuration des r`egles a` utiliser Ce fichier se trouve a` : /etc/prelude-nids/ruleset/prelude.rules

102

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

################################################### # 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 $_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 $(_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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# 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 include include include include include

$RULE_PATH/bad-traffic.rules $RULE_PATH/exploit.rules $RULE_PATH/scan.rules $RULE_PATH/finger.rules $RULE_PATH/dos.rules $RULE_PATH/ddos.rules

include include include include include include include include include include include include include

$RULE_PATH/web-cgi.rules $RULE_PATH/web-coldfusion.rules $RULE_PATH/web-iis.rules $RULE_PATH/web-frontpage.rules $RULE_PATH/web-misc.rules $RULE_PATH/web-client.rules $RULE_PATH/web-php.rules $RULE_PATH/sql.rules $RULE_PATH/x11.rules $RULE_PATH/attack-responses.rules $RULE_PATH/oracle.rules $RULE_PATH/mysql.rules $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. Situ´e 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.

# # # # # # # #

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 = NIDS post-reverse-proxy; node-location = B03; node-category = hosts; #

104

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # # # # # # # # # # # #

unknown ads afs coda dfs dns hosts kerberos nds nis nisplus nt wfw

Domain unknown or not relevant Windows 2000 Advanced Directory Services Andrew File System (Transarc) Coda Distributed File System Distributed File System (IBM) Domain Name System Local hosts file Kerberos realm Novell Directory Services Network Information Services (Sun) Network Information Services Plus (Sun) Windows NT domain Windows for Workgroups

# Address contained by this Node, # You may have several address. # # [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] # 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. # manager-addr = 192.168.1.5;

# 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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # 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;

#################################### # Here start plugins configuration # #################################### [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] # # This plugin issue an alert for each packet. # Carefull to the loging activity it generate.

[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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # 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= <macaddr>;

Configuration des r`egles a` utiliser 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 $_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 $(_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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# 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 include include include include include

$RULE_PATH/bad-traffic.rules $RULE_PATH/exploit.rules $RULE_PATH/scan.rules $RULE_PATH/finger.rules $RULE_PATH/dos.rules $RULE_PATH/ddos.rules

include include include include include include include include include include

$RULE_PATH/web-cgi.rules $RULE_PATH/web-coldfusion.rules $RULE_PATH/web-iis.rules $RULE_PATH/web-frontpage.rules $RULE_PATH/web-misc.rules $RULE_PATH/web-client.rules $RULE_PATH/web-php.rules $RULE_PATH/sql.rules $RULE_PATH/x11.rules $RULE_PATH/attack-responses.rules

108

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

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’´etablissement des r`egles du firewall

Ce script est ex´ecu´e a` chaque d´emarrage du firewall. Il se trouve donc a` : /etc/init.d/configFirewall Il est ensuite li´e aux runlevels ad´equats pour une ex´ecution automatique. La commande update-rc.d permet la cr´eation automatiquement des liens dans les diff´erents runlevel : # update-rc.d configFirewall defaults 90

Script de configuration du Firewall : #!/bin/sh # #Configuration du firewall #========================== #Projet SIMS orient´ e Web #========================== # #Le contrˆ ole des regles s’op` ere 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 autoris´ e afin de tout #laisser passer lors de la r´ einitialisation (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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

#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 ############################################################################### iptables -A FORWARD -i eth0 -p udp -d 192.168.1.0/24 --sport 123 -j ACCEPT iptables -A FORWARD -i eth1 -p udp -s 192.168.1.0/24 --dport 123 -j ACCEPT ############################################################################### #Autorise le trafic Web la console d’administration (car machine pour redaction #et recherche d’informations) ############################################################################### #pour les requˆ etes DNS de tout le reseau 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 #La console d’administration (portable) est autoris´ ee ` a sortir du r´ eseau 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 situ´ e 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 d´ emo) ############################################################################ 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 situ´e a` : /etc/prelude-sensors/sensors-default.conf # This is the default configuration for sensors that use libprelude.

110

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# Entry in this configuration file are overriden by entry directly # provided by the sensor configuration file.

# # # # # # # #

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 = Firewall; node-location = B03; node-category =unknown; # # # # # # # # # # # # # #

unknown ads afs coda dfs dns hosts kerberos nds nis nisplus nt wfw

Domain unknown or not relevant Windows 2000 Advanced Directory Services Andrew File System (Transarc) Coda Distributed File System Distributed File System (IBM) Domain Name System Local hosts file Kerberos realm Novell Directory Services Network Information Services (Sun) Network Information Services Plus (Sun) Windows NT domain Windows for Workgroups

# Address contained by this Node, # You may have several address. # # [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 situ´e a` : /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. # manager-addr = 192.168.1.5;

# # # # # #

Configuration for the UDP message receiver. commented out by default since most people only want to monitor files. [Udp-Srvr]

111

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# 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

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

A.4.4

Configuration des r`egles 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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

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. There can be more than one. - 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

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

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 lorsqu’une certaine taille a e´ t´e atteinte. Fichier de configuration situ´e 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 olddir /var/log/oldLog postrotate killall syslogd -HUP endscript } /var/log/messages { rotate 3 size=2M olddir /var/log/oldLog postrotate killall syslogd -HUP endscript } /var/log/kern.log { rotate 3 size=2M olddir /var/log/oldLog postrotate killall syslogd -HUP endscript } /Var/log/btmp { missingok monthly create 0664 root utmp rotate 1 } # system-specific logs may be configured here

114

Projet de Diplˆome 2004 - Jo¨el Winteregg SIMS - Security Intrusion Manager System orient´e Web

A.5

Configuration de Piwi et du moteur de corr´elation

# 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 corr´ elation (SIMS orient´ e 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 dur´ ee max d’une session TCP: pour la cr´ eation du contexte session TCP (en secondes) $conf{’TcpSessionDuration’}= 10; #port d’´ ecoute 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’; #fˆ enetre de corr´ elation (en secondes) = de maintenant ` a N secondes dans le pass´ e... $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 r´ eelle de l’attaquant $conf{’timeIntervalFindingIP’}=10;

115