Projet de Diplˆome - e
Transcription
Projet de Diplˆome - e
Projet de Diplôme SIMS - Security Intrusion Management System (orienté Web) Auteur : Joël Winteregg Professeur : Stefano Ventura Assistant : Cyril Friche École : École d’ingénieurs du Canton de Vaud Date : 16 décembre 2004 Table des matières 1 Introduction 1.1 Résumé du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Introduction au projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Snort VS Prelude 2.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Méthodes de détection d’attaques . . . . 2.1.2 Architecture distribuée . . . . . . . . . . 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 Étude et comparatif de reverse-proxys 3.1 Squid . . . . . . . . . . . . . . . . . . . . 3.1.1 Fonctionnement . . . . . . . . . . . 3.1.2 Caractéristiques . . . . . . . . . . . 3.1.3 Installation . . . . . . . . . . . . . 3.1.4 Configuration . . . . . . . . . . . . 3.1.5 Réécriture d’URL et HTTP redirect 3.2 DansGuardian . . . . . . . . . . . . . . . . 3.2.1 Caractéristiques . . . . . . . . . . . 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 4.1 4.2 . . . . . . . . . . . . . . . 31 35 38 40 40 40 41 42 43 43 44 45 45 47 48 Corrélation 5.1 Définition et principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Mais qu’apportera concrètement la corrélation ? . . . . . . . . . . . . . . . . . . 5.2.2 Événements déclencheurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Corrélation temps réel VS corrélation à postériori . . . . . . . . . . . . . . . . . . . . . 5.4 Mise en place des contextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Contextes de sessions TCP communes . . . . . . . . . . . . . . . . . . . . . . . 5.5 Scénarii d’investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Possibilités et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Diminution des faux positifs par analyse des requêtes - réponses et du status du serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 Traçabilité des comportements à 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émentation, installation et tests 6.1 Watchdog de contrôle d’état du/des serveur(s) Web 6.1.1 Détermination de l’état du service Web . . 6.1.2 Installation . . . . . . . . . . . . . . . . . 6.1.3 Configuration . . . . . . . . . . . . . . . . 6.2 Algorithme de corrélation et site Web (frontend) . . 6.2.1 Choix du langage et du frontend hôte . . . 6.2.2 Étude de l’interfaç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éfinition de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modification du code source de Dansguardian pour le contrôle des donnée POSTée 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éation 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écupération des logs du firewall . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Gestion des logs syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 64 64 65 65 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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éthodes d’analyses utilisées . . . . . . . . . . . 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élation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion 88 10 Remerciements et références 10.1 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Annexes A.1 Planning et coût 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’établissement des règles du firewall . A.4.2 Configuration du sensor . . . . . . . . . . . A.4.3 Configuration de la sonde HIDS . . . . . . . A.4.4 Configuration des règles à utiliser . . . . . . A.4.5 Configuration de la rotation des logs . . . . . A.5 Configuration de Piwi et du moteur de corrélation . . 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é par : EIVD - institut TCOM - et l’EIG (projet CCTI) 1.1 Résumé du problème La gestion de la sécurité est devenue indispensable au même titre que la gestion du réseau lui-même. On peut même prétendre que la gestion de la sécurité est désormais le souci majeur du gestionnaire du réseau de l’entreprise. Ce projet va se focaliser sur le développement d’un gestionnaire (Manager) de sécurité appelé SIMS (Security Intrusion Management System) disposant d’agents intelligents ouverts avec des interfaces SNMPv.31 ou IDMEF22 . SIMS est spécialisé dans le domaine de l’analyse des tentatives d’intrusions détectées par des platesformes de type Firewall et IDS (Intrusion Detection System). L’objectif premier de ce travail est d’étudier et de réaliser une plate-forme de gestion des intrusions basée sur une corrélation de différents événements et logs et permettant de détecter des attaques en temps réel. 1.2 Cahier des charges I. Établissement d’un rapport détaillé concernant les points suivants : 1 2 Simple Network Management Protocol version 3 Intrusion Detection Message Exchange Format 4 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – Définition des principaux domaines de la gestion de la sécurité et brève présentation des principaux standards existant dans ce domaine. Une attention particulière sera portée sur l’Intrusion Management. – Étude approfondie des différentes intrusions réseau et attaques WEB. Il s’agit de rédiger un document ”state of the art” présentant les principales attaques au niveau 2, 3 et 3 du modèle OSI, ainsi que les attaques de niveau applicatif. Les serveurs WEB, ainsi que les applications s’exécutant sur ces dernier, feront l’objet d’une attention particulière. – Développement d’un laboratoire et banc de test permettant de mettre en évidence les stratégies et mécanismes de défense contre les attaques WEB. Ce laboratoire sera basé sur le déploiement d’un reverse-proxy dont le choix fera l’objet d’une justification (Squidguard pour le filtrage d’url, DansGuardian pour le filtrage de contenu http, développement de Tissot, etc...). – Étude et évaluation des principales solutions et plates-formes d’Intrusion Management (OpenSource et produits propriétaires) disponibles sur le marché. – Évaluation des applications (aggregation, data fusion et corrélation) d’analyse des intrusions disponibles sur les systèmes retenus. II. Étude et proposition d’une application de gestion des intrusions basée sur une corrélation de différents événements et logs permettant de détecter et prévenir des attaques. Étude et réalisation d’une plate-forme SIMS basée sur des sondes http (evtl. https) et différents agents SIMS (reverse-proxy). Dans le cadre de cette étude, il s’agit aussi de définir un format général des messages (IDMEF) et logs générés par cette plate-forme. La plate-forme SIMS sera capable de collecter, stocker et traiter des logs depuis plusieurs sources comme, par exemple, des Reverse-proxy d’Apache, des Firewall Linux (Iptables) et éventuellement des logs depuis SSLsniffer qui lui serait capable d’envoyer un mode non crypté des logs vers SIMS. III. Réalisation d’un démonstrateur (applicatif SIMS) permettant d’illustrer les études et réalisations selon le point II. Il s’agit de mettre sur pied un environnement de détection d’intrusions et de gestion de logs avec les outils étudiés et développés au point II. Les attaques pourraient être simulées par les innombrables plugins que contient le scanner de vulnérabilité Nessus. SIMS pourrait intégrer des scénarii similaires à ceux implémentés par le travail de diplôme 2003 de M. Saladino. 5 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Directives : Lors de l’évaluation finale du travail de diplôme, une importance toute particulière sera donnée au respect des directives générales de l’EIVD ainsi qu’aux directives spécifiques à ce travail. 1.3 Introduction au projet La sécurité des serveurs Web est critique car ceux-ci sont généralement accessibles publiquement sur Internet. La moindre vulnérabilité à ce niveau peut être exploitée par n’importe quel cracker dans le monde. Aujourd’hui, de plus en plus de sociétés assurent leur image de marque via un portail Web. Celui-ci devient alors la colonne vertébrale du marketing et des ventes de plus en plus d’entreprises. Ceci explique donc la montée en flèche des attaques Web. Ce projet proposera une architecture d’entreprise sécurisée permettant l’intégration d’un serveur Web. Toute l’attention sera portée sur celui-ci puisque ce projet a pour souhait de proposer des solutions pour le management de la sécurité des serveurs Web. Différentes étapes ont été nécessaires : – Petit comparatif Snort3 - Prelude-IDS4 – Recherche d’un reverse-proxy (première protection du serveur Web) – Mise en place d’une architecture sécurisée 3 4 Sonde réseau Open Source IDS hybride (HIDS et NIDS) centralisé 6 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – Déployement d’IDS – Analyse et proposition de méthodes de corrélation permettant une bonne gestion de la sécurité – Implémentation d’un moteur de corrélation 7 Chapitre 2 Snort VS Prelude Ce chapitre abordera les outils disponibles avec Snort ainsi que les fonctionnalités offertes par Prelude, afin d’en faire le comparatif et la distinction. Le projet de semestre SIMS orienté Web contenait une introduction aux IDS qui détaillait les modes de fonctionnements et les fonctions offertes par la sonde réseau Snort, alors que les outils d’analyses disponibles avec celle-ci n’y étaient pas décrits. 2.1 Snort De simple outil de gestion de réseau, Snort est devenu un système de détection d’intrusion open source distribué dans les entreprises du monde entier. Son investigateur, Marty Roesch, avait initialement conçu Snort comme un outil personnel d’aide à l’analyse du trafic réseau. Snort peut être utilisé comme mouchard (sniffer), enregistreur de paquets ou système de détection d’intrusion réseau. Les NIDS1 , semblent au premier abord, particulièrement intéressants, mais il ne s’agit, en réalité, que d’une version améliorée des sniffers. En mode détecteur d’intrusion, il permet d’écouter le trafic réseau sur lequel il est connecté (sniffer) et de l’analyer, afin d’identifier des informations potentiellement dangereuses (tentatives d’attaques). 2.1.1 Méthodes de détection d’attaques Snort offre la possibilité de travailler selon deux méthodes d’analyse du trafic : 1. Par signature (via la syntaxe2 des signatures Snort) 2. Par l’heuristique (via le module SPADE3 ) 1 Network Intrusion Detection System, détecteur d’intrusion réseau Syntaxe décrite dans le rapport de travail de semestre 3 Statistical Packet Anomaly Detection Engine 2 8 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Détection par signature Il s’agit du moyen le plus efficace aujourd’hui. Cette détection repose sur le principe que le trafic réseau anormal ou malveillant reproduit un modèle spécifique, ce qui n’est pas le cas du trafic normal ou bénin. Le trafic malveillant se distingue au niveau de sa structure et de son contenu, c’est pourquoi il est possible de créer une signature d’attaque à partir de laquelle il pourra être reconnu. Dans Snort, une signature de trafic malveillant permet de créer une règle que l’on peut charger dans le moteur de détection du détecteur. Détection par l’heuristique La détection par signature est très efficace pour identifier du trafic suspect, mais ce type de détection n’est malheureusement pas efficace à 100%. Dans certains cas, le trafic peut se révéler dangereux sans exposer de signature particulière. La communauté Snort a donc développé le module SPADE pour détecter le trafic suspect ne correspondant à aucune signature. SPADE observe le trafic réseau et construit une table qui reflète le trafic normal. La table contient des données sur les types de paquets et les adresses de source et de destination. Une fois que la table a atteint une taille significative, chaque paquet récupéré par SPADE se voit attribuer un numéro basé sur la fréquence à laquelle il apparaı̂t dans la table. Plus le paquet est rare, plus son numéro est grand. Lorsqu’un seuil configuré est atteint, une alerte est générée. Supposons que vous vouliez configurer SPADE pour qu’il protège un serveur Web. Vous déployez Snort avec SPADE activé sur un segment réseau connecté à Internet. SPADE construit une table pour modéliser le trafic entrant (principalement des connexions TCP vers les ports 80 et 443). Une fois que la table est construite, les requêtes TCP sur les ports 80 et 443 sont considérées comme du ”trafic normal” et reçoivent un petit numéro. Si un attaquant tente de sonder le serveur Web pour trouver des services sur des ports différents, SPADE attribuera un numéro élevé à ce trafic puisqu’il est rare et inhabituel sur ce serveur particulier. Si des tentatives sont réalisées sur des ports inhabituels au-delà d’un certain seuil prédéfini, SPADE générera une alerte. Cette technique est efficace pour détecter les opérations réalisées par des crackers qui espèrent se fondre dans la masses du trafic normal. 2.1.2 Architecture distribuée Snort propose ensuite une architecture distribuée permettant aux sondes d’envoyer leurs alarmes dans une base de donnée commune qui sera ensuite analysée par une application Web. Ceci permettra à l’ingénieur système de monitorer l’évolution des attaques via un browser Web. L’architecture 3-tiers décrite ci-dessus est présentée sur la figure 2.1. 9 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 2.1 – Architecture distribuée de Snort Premier tiers - le tiers détecteur L’application Snort, à proprement parler, s’exécute sur le détecteur. Elle est chargée d’interpréter la nature des paquets ”reniflés” et de transmettre les alertes à la base de donnée. Les détecteurs doivent être placés sur les segments de réseau à protéger, c’est pourquoi la sécurité est primordiale. Sur le détecteur, seul Snort et les applications associées doivent être exécutés. Cette configuration se justifie pour des raisons liées, à la fois aux performances et à la sécurité. Les IDS sont des cibles très tentantes pour les crackers et il est préférable d’éviter d’exécuter sur le détecteur des applications susceptibles d’ouvrir une brèche dans la sécurité. Le détecteur doit être équipé de deux cartes réseau : la première pour l’interface de la fonction sniffer et l’autre pour l’interface de gestion. L’idée consiste à avoir un réseau séparé pour la gestion et de traiter tous les paquets entrant (surveillés) avec une interface et toutes les alertes sortantes avec l’autre. L’interface de la fonction sniffer ne doit pas posséder d’adresse IP afin que le trafic ne puisse circuler que dans un sens4 . L’interface de gestion doit, quant à elle, être en mesure de communiquer avec les autres éléments de 4 Une interface est incapable d’émettre des paquets lorsqu’elle n’a pas d’adresse IP (0.0.0.0) 10 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web l’architecture de Snort. C’est donc pour cela qu’une adresse IP lui sera assigné. Elle nous permettra, entre autre, de régler Snort en ajoutant, en soustrayant ou en modifiant les règles et la configuration des préprocesseurs. Deuxième tiers - le tiers serveur Le deuxième tiers, le tiers serveur, récupère les données d’alertes auprès des détecteurs et les présente dans un format exploitable par l’utilisateur. Ces données sont enregistrées par Snort dans une base de données relationnelle. Cette base de données n’est pas obligatoire : les alertes peuvent être enregistrées par d’autres moyens, tel que syslog. Le tiers serveur prend aussi en charge une interface graphique qui présente les données dans un format exploitable par l’utilisateur. Plusieurs interfaces graphiques sont dipsonibles avec Snort, y compris demarc, snortsnar, snortdb et l’application ACID5 . Troisième tiers - la console de l’analyste C’est dans le troisième tiers que sont présentées les données à l’analyste. La console exige uniquement une machine dédiée, équipée d’un navigateur Web compatible SSL. ACID fonctionnne bien avec Internet Explorer, Mozilla, Netscape et la plupart des autres navigateurs. Il est préférable de dédier une machine à la console pour en contrôler l’accès physique et pour empêcher les autres applications d’interférer avec le système de détection d’intrusion. 2.1.3 Outils d’analyse et de gestion Snort offre ensuite plusieurs outils de gestion pour son architecture distribuée, dont : – ACID (Analysis Console for Intrusin Database), application serveur permettant à l’ingénieur système d’interroger et d’analyser la base de données contenant la liste des attaques détectées par les différentes sondes. – IDS Policy Manager, application Windows 2000/XP servant à gérer à distance les différents détecteurs Snort. ACID ACID est le principal outil pour exploiter et pour gérer les données d’intrusion rassemblées par Snort. Il présente les données d’alerte et d’intrusion de manière à clarifier les données brutes émises par Snort. Les données sont organisées de façon logique pour simplifier la prise rapide de décision. De plus, chaque signature d’attaque est associée à un lien Internet qui permettra à l’analyste de trouver les causes de l’intrusion. 5 application décirte dans la section 2.1.3 11 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web IDS Policy Manager Cette application6 permet de modifier les paramètres des fichiers de configuration et les règles (ajout, supression, modification) des différentes sondes du réseau. Elle est capable d’atteindre les paramètres suivants d’une sonde : – variable réseau – classifications des règles – réglage des préprocesseurs – modules de sortie – paramètre du système de règles Ces paramètres sont stockés dans ce que l’on appelle une ”politique”. Ces politiques peuvent être différentes en fonction de l’emplacement de la sonde. Il est donc facile, à l’aide de cette notion de politique, de changer la configuration globale des sondes. Tous les échanges d’informations entre cette application et les sondes sont crpytés à l’aide du paquetage SCP inclus dans Putty. 2.2 Prelude Prelude-IDS est un système de détection d’intrusions et d’anomalies distribué sous licence GPL7 . La détection d’intrusion est réalisée par l’analyse du trafic réseau et l’utilisation de signatures d’évènements hostiles (NIDS) ou par l’analyse, en continu, de fichiers de journalisation (HIDS). L’architecture de Prelude est modulaire8 , distribuée9 et sécurisée10 . Les sondes (réseaux comme locales) n’effectuent que les opérations de surveillance et de génération d’alertes, alors que les managers prennent en charge la gestion des sondes et la journalisation des alertes. 2.2.1 Composants et architecture La figure 2.2 présente l’architecture distribuée envisageable à l’aide de Prelude. Libprelude (la bibliothèque Prelude) La bibliothèque libprelude a été créée dans le but de fournir une interface unique et standard de communication entre les différents éléments du système de détection. Cette bibliothèque est, bien sûr, utilisée par 6 Disponible uniquement pour Windows 2000/XP sur : http ://activeworx.com/download/index.htm General Public License 8 Il est possible d’intégrer ou développer de nouvelles fonctionnalités grâce à 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 2.2 – Architecture distribuée de Prelude (source : Projet SIMS 2003, Patrick Saladino) tous les modules de Prelude et peut aussi être intégrée à d’autres produits, afin de leur assurer une compatibilité avec ce système de détection d’intrusions. Pour des raisons de compatibilité et d’évolutivité, le format de messages IDMEF a été retenu. C’est cette bibliothèque qui offre, entre autres, les possibilités d’authentification mutuelle et de chiffrement de la communication. Prelude-Nids (la sonde réseau) Cette sonde prend en charge l’analyse en temps réel du trafic réseau. Elle est construite au-dessus de la bibliothèque libprelude et fournit : – Un moteur de gestion de signatures générique, actuellement compatible avec les signatures Snort mais pouvant être étendu par l’ajout de nouveaux parsers (analyseurs syntaxiques) de règles. – Des modules spécialisés par protocole. Par exemple, un plugin est dédié aux protocoles RPC et permet l’analyse fine de ce type de connexions. 13 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – Des modules spécialisés dans la détection non basée sur les signatures, comme la reconnaissance des scans et la normalisation des chaı̂nes de caractères de requêtes HTTP. – Les sondes réseaux peuvent aussi prendre en charge la défragmentation IP et le réassemblage des flux TCP de façon à rendre une sonde réseau Prelude moins vulnérable aux attaques de type Stick ou Snot11 . Prelude-LML (la sonde locale) Cette sonde prend en charge la remontée d’alertes détectées localement sur l’hôte. Cette détection est basée sur l’application de règles construites autour d’expressions régulières compatibles Perl (PCRE) à des objets12 . Une sonde hôte Prelude peut aussi recevoir les logs de machines distantes, de routeurs et de firewalls grâce à son serveur Syslog intégré. Prelude-Manager (le contrôleur) Prelude-manager centralise les messages des sondes réseaux et locales et les traduit en alertes. Il est responsable de la centralisation et de la journalisation à travers deux fonctions : – Celle de relais : un contrôleur relais va assurer le routage vers un contrôleur maı̂tre des alertes provenant des sondes qui lui sont rattachées. – Celle de maı̂tre : un tel contrôleur va assurer la réception des messages et des alertes provenant des sondes ainsi que leur journalisation dans un format lisible par l’analyste : en mode texte (dans les fichiers), XML-IDMEF ou SQL dans le cas de l’utilisation d’un SGBD13 (MySQL ou PostgreSQL). Il est possible d’étendre les capacités d’un contrôleur à l’aide de plugins, en autorisant, par exemple, le traitement de messages en provenance de composants autres que Prelude. Un contrôleur Prelude peut ainsi centraliser la remontée d’alarmes en provenance de sondes Snort. Prelude-Frontend (l’interface web) Prelude-Frontend est l’interface de visualisation des alertes. Il est actuellement proposé deux interfaces, l’une développée en PHP et l’autre en Perl : 1. Prelude-PHP-Frontend est l’interface proposée sur le site officiel de Prelude-IDS14 . Elle est composée de scripts PHP et destinée à être installée sur un serveur web indépendamment des autres composants Prelude. Cela signifie que l’installation préalable de la librairie libprelude est inutile, mais que par contre celle d’un serveur web supportant PHP4 l’est. 11 Ces deux techniques sont utilisées pour tromper le moteur de l’IDS en fragmentant l’attaque dans plusieurs paquets, ceci en espérant que la reconstruction se fera après qu’ils aient traversés l’IDS 12 fichiers de journalisation et/ou d’application (logs) 13 Système de gestion de base de données 14 http ://www.prelude-ids.org 14 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 2. Prelude-Perl-Frontend est une interface issue d’un projet intitulé ”Le Routier15 ”. Elle nécessite, bien évidemment, l’installation d’un serveur web supportant Perl. 2.3 Comparatif Dans le cadre du projet, ces deux outils sont très proches. Ce sont tous les deux des outils libres. Les projets dont ils sont les résultats sont très actifs, aussi bien dans le développement que dans la mise à jour des attaques. Quelques avantages de Snort sur Prelude-IDS sont sa popularité et sa disponibilité 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ées des signatures d’attaque de Snort, explique peut être sa plus grande popularité. Prelude-IDS est de plus en plus connu dans le monde des professionnels de la sécurité et a l’avantage sur Snort de ne pas être un NIDS pur puisqu’il intègre des fonctionnalités NIDS et HIDS17 . De plus, il est capable de récupérer les fichiers de logs (syslog) d’un bon nombre d’équipement réseaux actifs18 afin de les analyser sur la sonde spécialisée à cet effet (Prelude-LML) et d’envoyer les alertes à sa base de donnée centralisée pour que l’analyste réseau puisse en tirer des informations pertinantes. Il est donc un IDS hybride. Dans ce qui suivra, nous ne comparerons que ce qui est comparable, c’est-à-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 (à 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, échange des messages en XML, IDMEF). En regroupant les alertes de même type, nous nous retrouvons alors avec aproximativement le même nombre d’alertes (Prelude ayant ses propres règles, il est normal qu’il en trouve un peu plus que Snort). Prelude-NIDS comme Snort offrent la possibilité d’archiver les payloads. Prelude-IDS a l’avantage d’être très modulaire de par son architecture client-serveur. Un manager peut gérer plusieurs sondes et une sonde peut envoyer ses alertes à plusieurs managers. Le filtrage au niveau de la sonde pour savoir à quel manager est envoyée telle alerte ou telle autre n’est pas encore 15 http ://www.leroutier.net/Projects/PreludeIDS La liste complète des plateformes compatibles est disponible sur : http ://www.snort.org/about.html 17 Host Intrusion Detection System, intégré dans Preldue comme une fonction de récupération des logs Syslog et de leur analyse 18 Routeurs, Firewall, etc.. 16 15 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web opérationnel. De plus, Prelude-IDS n’offre aucune sonde réseau permettant la détection d’attaques par l’heuristique comme le permet Snort via le module SPADE. Grâce à l’architecture modulaire et standardisée de Prelude-IDS, il suffirait d’inclure une sonde Snort dans l’architecture de Prelude afin d’obtenir une détection par l’heuristique sur le ou les segments voulus. Les deux produits nous fournissent des alertes bien détaillées qui permettent de connaı̂tre la source et la destination d’une attaque, le type d’attaque, un classement de sévérité de l’alerte ou encore un lien vers un bulletin d’alerte officiel. Dans les deux outils, il est intéressant de constater la présence de niveaux d’alertes permettant d’en déduire du premier coup d’oeil la dangerosité. Il est à noter que Prelude-IDS archive aussi les charges utiles des trames suspectes. Cela permettra ensuite, dans certains cas, à l’administrateur d’analyser le contenu afin d’écarter plus facilement les faux-positifs. 2.3.2 La console de l’analyste (frontends) Les plus grandes différences entres les 2 outils se trouvent au niveau des frontends. Sous Prelude, il n’y a pas vraiment de frontends officiel. Le premier fut développé en PHP, puis quelques semaines après sa parution, un nouveau frontend en perl arrivait à maturité 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édié à Snort : ACID. Snort compte lui aussi plusieurs interfaces et sa popularité fait qu’il est maintenant intégré dans des outils comme webmin. Cependant, la référence reste ACID. Le classement et regroupement des alertes sont dans les deux cas possibles suivant des critères communs basiques pour les deux IDS (même adresse IP source, même type d’attaque, même niveau d’alerte, ...). Pour des filtrages plus détaillés, la logique est différente dans les deux outils. Le frontend-perl de Prelude-IDS propose une rubrique Filter Factory qui permet de créer des filtres, de les modifier ou de les supprimer. Au niveau de l’interface graphique, autant Prelude-IDS que Snort proposent des graphiques et statistiques permettant d’avoir une vue globale des attaques sur le réseau. 2.4 Conclusion Dans le cadre de ce projet, nous préférerons donc Prelude-IDS à Snort, puisque celui-ci intègre directement deux fonctionnalités (NIDS et HIDS), très intéressantes pour la suite de cette étude. De plus, la première partie de ce projet effectuée par Monsieur Saladino avait déjà mené à la conclusion de l’utilisation de ce produit Open Source déjà bien abouti. 16 Chapitre 3 Étude et comparatif de reverse-proxys Afin de déterminer quel reverse-proxy utiliser dans l’architecture de SIMS orientée Web, nous allons en étudier plusieurs. Nous dresserons un petit comparatif entre différents produits afin de sélectionner le produit correspondant à nos attentes. Nous nous pencherons tout particulièrement sur les possibilités de configuration offertes ainsi que sur les informations (logs, etc...) des tentatives d’attaques bloquées. Ces dernières sont un point crucial dans le projet puisque nous recherchons un produit qui nous fournisse un grand nombre d’informations pertinantes, permettant une corrélation avec celles d’une sonde réseau. 3.1 Squid Squid est un proxy/reverse-proxy Open Source, servant en premier lieu d’accélérateur Web (cache). Configuré en proxy (dans une entreprise par exemple), il a pour but de réduire l’utilisation d’une connexion à Internet. En effet, lorsqu’un grand réseau LAN1 est connecté sur Internet et qu’un grand nombre de personnes surfent sur le Web, il y a de fortes chances que plusieurs accès sur un même site se fassent dans un court intervalle de temps. Le proxy va donc enregistrer tout ce qui n’est pas susceptible de changer entre deux accès à un même site. Il s’agira donc de tout contenu non dynamique comme des pages html, des images, etc... Il va ensuite fournir aux clients voulant accéder à des pages déjà visitées, ce qu’il a enregistré en cache plutôt que d’envoyer une requête au serveur Web distant. Squid configuré en reverse-proxy a pour but de réduire la charge d’un serveur Web. Il se place donc entre Internet et le serveur Web et se charge de fournir à tous les clients les contenus statiques du serveur afin de le laisser libre pour les tâches de génération de pages html (pages dynamiques du serveur). L’ajout d’un reverse-proxy dans une architecture réseau permettra donc de réduire le nombre de serveurs puisqu’une partie de leurs tâches seront prise en charge par le reverse-proxy. Des fonctions de filtrage et de contrôles d’accès sont également disponibles, ce qui permettra dans le cas d’un proxy de contrôler et restreindre l’accès à certains sites et dans le cas d’un reverse-proxy, d’accroı̂tre 1 Local Area Network, réseau d’entreprise 17 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web la sécurité. 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é pour mettre en cache des pages Web statiques sur un réseau local. Comme expliqué précédemment lorsqu’une page est réclamée une seconde fois par un client Web (browser2 ), celui-ci recevra les données du proxy local plutôt que celle du serveur Web d’origine. Le browser du client devra explicitement envoyer ses requêtes au proxy plutôt qu’au serveur Web cible. C’est ensuite le proxy qui, lui même, établira cette connexion ou alors servira le client avec des données enregistrées dans son cache. Transparent Cache Un cache transparent a le même but qu’un proxy standard mais opère de manière transparente. Le browser n’a pas besoin d’être explicitement configuré pour passer par le proxy. Dans ce mode, le proxy intercepte le trafic réseau et retire le trafic HTTP (sur le port 80) du réseau. Si le contenu demandé ne se trouve pas dans le cache du proxy, celui-ci relaiera (comme le ferait un routeur) la requête effectuée par le browser du client. Ce mode d’utilisation est surtout utilisé par les ISP3 , puisqu’il ne requiert aucune configuration spécifique du browser client. Reverse Proxy Cache Un reverse-proxy diffère des deux autres modes d’utilisation. Il se place dans l’architecture du serveur et non plus dans celle du client. Comme susmentionné, il a pour but de soulager les serveurs Web ainsi que de répartir la charge. De plus à l’aide du filtrage de contenu, il permettra d’accroı̂tre la sécurité sur les serveurs Web. Les architectures envisageables ont été discutées dans le chapitre 4.1 (page 12) du projet de semestre, que je vous laisserai consulter pour plus d’informations. 3.1.2 Caractéristiques Squid offre les fonctionnalités suivantes : – Cache HTTP et FTP – Prend en charge les connexions sécurisées HTTPS (très utile en configuration reverse-proxy) – Hiérarchie de cache (à l’aide d’échanges d’informations entre proxys) – Contrôle d’accès – Agent SNMP intégré – Cache pour les DNS lookups La fonctionnalité la plus intéressante dans le cadre de ce projet et celle de contrôle d’accès, puisqu’elle nous permettrait d’établir des règles afin de filtrer les requêtes considérées dangereuses. 2 3 au sens navigateur Web Internet Service Provider, fournisseurs d’accès Internet 18 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 3.1.3 Installation Pour ce faire, nous téléchargeons les sources sur l’un des nombreux miroir : ftp ://sunsite.cnlab-switch.ch/mirror/squid/squid-2/STABLE/squid-2.5.STABLE6.tar.gz Nous décompressons l’archive dans un répertoire (/usr/local/src) : jo:/usr/local/src# tar -xvvzf squid-2.5.STABLE6.tar.gz Et nous nous plaçons maintenant dans le répertoire des sources pour passer à la configuration de la compilation : jo:/usr/local/src/squid-2.5.STABLE6# ./configure --prefix=/usr/local/squid \ --enable-err-language=French Nous précisons le répertoire de destination de l’application ainsi que la langue utilisée par les pages d’erreurs retournées par Squid. Voici une liste non exhaustive des options de compilation utilisables lors de la configuration : – Choix de la méthode d’allocation de la mémoire pour le cache, activation des librairies écrites pas Doug Lea (–enable-dl-malloc) – Compilation interne de la librairie des expression régulières (–enable-gnuregex). – Activation d’un agent SNMP (–enable-snmp). – Activation du contrôle d’accès sur les adresses MAC (–enable-arp-acl) – Choix du protocole d’échange de cache entre les proxys (–enable-cache-digests ou –enable-htcp) – Enregistrement de l’adresse source de chaque requête (–enable-forw-via-db) Pour plus de détails sur les options de compilation disponibles, consultez : http ://squid-docs.sourceforge.net/latest/book-full.html#AEN250 Nous pouvons maintenant passer à la compilation et à 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é, nous pouvons passer à sa configuration. Pour ce faire nous éditons le fichier squid.conf (/usr/local/squid/etc/squid.conf). Un grand nombre de valeurs par défauts sont commentées (à l’aide du caractère #). Nous devons donc décommenter tous les tags4 utiles et changer leurs valeurs si nécessaire. Voici donc ce que nous avons modifier : 4 directives de configuration 19 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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éciser sur quel port Squid agira. cache dir Nous permet d’indiquer la mémoire maximale du cache ainsi que son emplacement sur le disque. Il nous permet ensuite de donner le nombre maximal de répertoires et sous répertoires que Squid pourra créer pour l’indexation des pages web. cache effective user et cache effective group Nous permettent de préciser sous quel user Squid s’exécutera. visible hostname Précise le nom du proxy (qui sera donné dans les pages d’erreurs). httpd accel port Nous permet de préciser sur quel port le reverse-proxy agira. httpd accel host Nous permet de préciser l’adresse du serveur pour lequel le reverse-proxy travaille. httpd accel single host Indique si le reverse-proxy travaille pour un ou plusieurs serveurs (1 seul dans notre cas). httpd accel with proxy Permet de faire travailler Squid en proxy et reverse-proxy (en même temps). Il faut ensuite prendre garde à mettre les droits suffisants sur le répertoire de logs, afin que l’utilisateur sous lequel s’exécute Squid puisse y accéder en lecture et en écriture. Nous pouvons ensuite lancer la création du cache swap qui permettra à Squid d’enregistrer les fichiers statiques : jo:/usr/local/squid/sbin# ./squid -z Nous pouvons maintenant lancer le reverse-proxy à 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 à notre projet, les exemples et explications ci-dessous considèrent un mode de fonctionnement en reverse-proxy. 20 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Le filtrage HTTP nous est offert par le biais du tag http access et http reply access qui sont des opérateurs ACL5 . Le premier permet d’effectuer le filtrage de la requête d’un client, alors que le second permet le filtrage de la réponse du serveur. Le filtrage est possible sur les paramètres suivants (type ACL) : – Adresse IP source / destination – Domaine source / destination – Expression régulière : – Sur une URL entière (url regex) – Sur le chemin de l’URL sans tenir compte du type et du nom du serveur (urlpath regex) – Sur le nom de domaine source et destination (srcdom regex et dstdom regex) – Jour courant et heure – Port de destination – Protocole (FTP, HTTP, SSL) – Méthode (POST, GET) – Le type du browser client – Username / password lors de procédure d’authentification – Communauté SNMP Il suffit de définir un ACL, (s’apparentant à la déclaration d’un type dans un langage de programmation) en précisant sur quel paramètre ci-dessus s’applique la déclaration (donc le type de l’ACL). Ensuite nous pouvons définir si l’ACL est autorisé ou non via un opérateur (ici le tag http access) . En voici un exemple : acl ClientOK src 10.192.73.0/23 http_acces allow ClientOk Tous les client faisant partie du sous réseau TCOM6 auront le droit d’accéder le serveur Web, alors que tous les autres seront rejetés. Il est bien de noter que Squid fonctionne en whitelist par défaut et que la ligne ”http acces deny all” est implicite à la fin de la configuration des règles d’accès. Celle-ci indique bien un fonctionnement en whitelist puisque tous les accès sont refusés, sauf ceux explicitement précisé à l’aide d’une règle ”allow”. Il est tout de même judicieux de l’ajouter à la fin de la définition des règles, afin que l’administrateur non averti ne se trompe pas. Il est aussi possible de travailler en blacklist en ajoutant simplement la règle suivante à la fin de la configuration des accès : http acces allow all. Celle-ci changera donc le fonctionnement par défaut et des règles ”deny” devront être définies afin de créer la blacklist. Un ACL permet la définition de plusieurs conditions d’un même paramètre sur une même ligne. Il est alors possible de condenser l’écriture des conditions en séparant celles-ci par un espace, qui sera interprété comme un OU. En voici un petit exemple : 5 6 Access Control List Réseau du département de télécommunication de l’EIVD 21 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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éseaux définis ci-dessus auront accès au serveur Web. Squid contrôlera que la source de la requête appartienne au sous-réseau 10.192.73.0/23 ou 10.192.63.0/16. Afin de simplifier la lecture du fichier de configuration il est possible de définir les conditions dans un fichier externe. Si dans l’exemple ci-dessus, la liste des adresses autorisée à se connecter au serveur Web est définie dans le fichier /usr/local/squid/conditions/clientsOk (une condition par ligne), il suffira de charger la règle de la façon suivante : acl ClientsOK src "/usr/local/squid/conditions/clientsOk" http_acces allow ClientsOk De la même manière que pour les conditions, il est possible de condenser l’écriture avec les opérateurs ACL (tag http access dans ce cas) et de créer une logique combinatoire afin de définir une règle complexe. Il suffira de les séparer par un espace, qui signifiera que les deux conditions (ACL) doivent être valides afin que la règle s’applique. Nous obtenons donc un ET logique entre les conditions. En voici un exemple : acl monNet src 168.209.2.0/255.255.255.0 acl heureTravail time 08:00-17:00 http_access deny monNet heureTravail http_access allow all Si une machine de monNet tente d’accéder le serveur Web pendant les heures de travail, la connexion sera refusée puisque les deux conditions ACL s’appliqueront. Si par contre une machine de monNet tente d’accéder le serveur hors des heures de travail, la condition ”heureTravail” ne sera plus valide. Comme un ET logique est opéré entre les différentes conditions, la règle ne sera pas appliquée puisque l’une d’elle n’est pas valide. C’est ensuite les règles suivantes qui définiront si un filtrage est opéré. 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 à l’aide de ces deux fonctionnements (ET et OU) de définir des conditions complexes pour opérer un filtrage précis. Pour plus de détails sur les différents paramètres utilisables pour la déclaration d’ACL (types ACL), consultez la page Web suivante : http ://squid-docs.sourceforge.net/latest/book-full.html#AEN1493 Jusqu’à maintenant, nous avons uniquement travaillé avec l’opérateur ACL ”http access”, mais il existe différents types d’opérateurs permettant la gestion des actions en fonction de la requête. Le lecteur intéressé pour se référer à la page suivante : http ://squid-docs.sourceforge.net/latest/book-full.html#AEN1831 pour de plus amples informations à ce sujet. 22 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Filtrage des requêtes (http access) Cette opérateur déjà grandement illustrée dans les exemples ci-dessus ne sera pas plus détaillé ici. Nous allons par contre illustrer la configuration qu’il faudrait mettre en place afin que Squid agisse comme reverse-proxy spécifique à 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âce à cette configuration, il sera possible d’accéder à la page d’accueil du securitystore (avec les images et feuilles de style) ainsi qu’à la page d’authentification (login.php). Malheureusement, nous remarquons que Squid ne permet pas un filtrage de contenu (paramètres contenus dans un POST par exemple), ce qui ne nous permettra pas de filtrer les cas de SQLinjection, XSS, etc... ou toutes autres attaques effectuées via un paramètre non contenu dans l’URL (GET). Filtrage des réponses (http reply access) Cet opérateur s’utilise exactement comme l’opérateur de filtrage des requêtes mais ne s’occupe que du filtrage des réponses fournies au client. 3.1.5 Réécriture d’URL et HTTP redirect Il est possible, à l’aide d’un programme externe, de réécrire les URL à l’aide d’expressions régulières. Apache offre aussi cette opportunité comme la plupart des serveurs Web. Il est donc nécessaire de choisir si la réécriture se fera plutôt sur le serveur Web ou le reverse-proxy. Elle permettra ainsi de cacher l’arborescence crée sur le serveur ou de rediriger des requêtes en fonction de la page demandée. Nous avons testé Squirm (redirector Open Source pour Squid) disponible sur : http ://squirm.foote.com.au/ Il permet la réécriture des requêtes émises par les browser Web à l’aide d’expressions régulières. Il n’est malheureusement pas possible à l’aide de ce module externe de réécrire les réponses du serveur Web. Il sera ainsi impossible de réécrire les réponses HTTP redirect8 émises par le serveur Web. Celle-ci contiendra donc l’adresse IP du serveur Web lui-même, ce qui forcera le client à essayer de se connecter 7 Reverse-proxy développé par Sylvain Tissot dans le cadre de son travail de diplôme 2003 et étudié dans le cadre du travail de semestre 8 Réponse indiquant au client la nouvelle page à charger 23 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web directement sur le serveur Web (sans passer par le reverse-proxy). Il faudra donc plutôt réécrire l’entête HTTP directement sur le serveur Web afin d’opérer un remplacement de l’adresse IP du serveur par celle du reverse-proxy. Ainsi, le client se fera rediriger sur le reverse-proxy, ce qui ne posera aucun problèmes. 3.2 DansGuardian DansGuardian est un produit Open Source offrant des possibilités de filtrage de contenu. Il fonctionne sur les systèmes d’exploitation suivants : Linux, FreeBSD, OpenBSD, NetBSD, Mac OS X, HP-UX, et Solaris. Il permet d’explorer le corps de contenu HTTP (donc des pages html ou autre). A l’instar de Squid, il n’implémente aucune fonction de cache et n’est donc pas utilisé comme accélérateur de serveur Web. Son but premier est de protéger des utilisateurs (souvent des enfants) contre des contenus litigieux. Il s’agit donc plutôt d’une utilisation en proxy et non en reverse-proxy. Étant donné qu’aucune documentation précise sur Dansgusrdian n’est disponible sur Internet, nous avons décidé de le tester afin d’observer l’effet de la configuration sur les contenus traités ainsi que les possibilités offertes pour une configuration en reverse-proxy. 3.2.1 Caractéristiques – Filtre (remplacement de mots) le contenu de la réponse du serveur (fichiers texte et HTML) à l’aide d’expressions régulières – Possibilité d’assigner un popoids des mots afin de définir si un filtrage à lieu en fonction de leur nombre d’apparition dans un contenu HTML ou texte – Bloquage de réponse HTTP offert selon les type MIME retourné par le serveur – Bloquage de réponse HTTP offert selon l’URL demandée par un client à l’aide d’expressions régulières – Syntaxe de la blacklist d’URL compatible avec celle de Squid – Filtrage d’URL sur des requêtes HTTPS – Log facile à lire et configurable dans différents formats – Possibilité de logger les usernames lors d’authentification HTTP – Possibilité de bloquer les uploads (uniquement suivant la taille d’un POST) – Possibilité de journaliser les sites qui auraient été bloqués sans pour autant les bloquer – Les caractères Big5, Unicode et les caractères peuvent être utilisés pour des recherches dans des contenu HTML – Supporte les fichiers compressés 24 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 3.2.2 Installation Pour ce faire, nous téléchargeons les sources sur : http ://mirror2.dansguardian.org/downloads/2/Stable/DansGuardian2.6.1-9.source.tar.gz Nous décompressons l’archive dans un répertoire (/usr/local/src) : jo:/usr/local/src# tar -xvvzf DansGuardian-2.6.1-9.source.tar.gz Et nous nous plaçons maintenant dans le répertoire des sources pour passer à la configuration de la compilation : jo:/usr/local/src/DansGuardian-2.6.1-9.source# ./configure --runas_grp root --runas_usr root Nous procédons à une configuration par défaut en ce qui concerne l’emplacement de tous les répertoires utiles à Dansguardian. Nous précisons simplement sous quel utilisateur et quel groupe s’exécutera Dansguardian (root dans notre cas, afin que l’application aie accès au port 80 de la machine). Pour plus de précisions sur les options de configuration vous pourrez consulter : http ://dansguardian.org/downloads/detailedinstallation2.html#installation La configuration ainsi faite placera les différents fichiers de Dansguardian dans les répertoires suivants : Description des fichiers Les binaires Les fichiers de configuration Les scripts de démarrage 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éro 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 à la compilation et à 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ès bien des essais et analyses à l’aide d’Ethereal9 , nous nous sommes rendus compte qu’il n’était pas possible d’utiliser Dansguardian comme pièce unique dans l’architecture d’un reverse-proxy (Figure 3.1). En effet, les pages Web reçues par les browser (clients) ne contenaient pas toutes les informations nécessaires pour leur affichage, ce qui provoquait une erreur dans le browser. Dansguardian travaille 9 analyseur réseau Open Source 25 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 3.1 – Architecture de Test (non-fonctionnelle) d’une manière différente 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écutent sur la même machine et utilisent la loopback pour communiquer. F IG . 3.3 – Architecture retenue 3.2.4 Configuration Maintenant que Dansguardian est installé, et que son architecture est définie, nous pouvons passer à sa configuration. Pour ce faire nous éditons le fichier dansguardian.conf (/etc/dansguardian/dansguardian.conf). Les principales lignes de configuration figures donc ci-dessous : 26 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web # Adresse IP sur laquelle Dansguardian attend les requêtes filterip = 192.168.1.2 #Port sur lequel Dansguardiant attend les requêtes filterport = 80 # L’adresse IP du proxy à qui il transmettra les requêtes (après filtrage) proxyip = 127.0.0.1 # Port sur lequel atteindre le proxy proxyport = 3128 Cette configuration se rapporte à l’architecture de la figure 3.3. Nous remarquons que Dansguardian transmet ses requêtes sur le port 3128 de sa loopback, qui correspond au port d’écoute de Squid, qui les transmettra au serveur Web. Il est donc indispensable de modifer la configuration de Squid que nous avions présenté à la section 3.1.4. Nous changeons simplement la directive suivante afin que Squid écoute sur l’adresse et le port par lequel Dansguardian transmet ses requêtes : http_port 127.0.0.1:3128 Il est maintenant possible de démarrer Dansguardian à l’aide de la commande suivante : jo:/#dansguardian Il est bien de noter que Squid doit être démarré avant Dansguardian, puisque celui-ci ne démarrera pas tant qu’il ne pourra pas atteindre (connexion TCP) le proxy auquel il transmettra ses requêtes. Filtrage Les termes bloquage et filtrage utilisés dans la suite de ce document on une signification particulière. Le terme bloquage indique un refus de transmission d’une requête client10 ou d’une réponse du serveur par Dansguardian. Le terme filtrage, indique quant à lui que le corps11 de la réponse émise par le serveur (faisant suite à la requête d’un client) est contrôlée et modifiée si nécessaire (selon le fichier de configuration contentregexplist mentionné ci-dessous). Paramètres configurables pour le filtrage dans le sens aller (requête vers le serveur) : – Sites entier interdits (bloqués) (fichier : bannedsitelist) – URL12 de sites interdits (bloqués) (fichier : bannedurllist, bannedregexpurllist) – Sites entier non filtrés et non bloqués (dont le contenu aller-retour n’est pas contrôlé) (fichier : exceptionsitelist) 10 Indiqué au client par une page HTML ”AccAccèsfusé” Document HTML ou TXT 12 ”Sites entier interdits” bloque les accès au site entier alors que ce fichier de configuration offre la possibilité de bloquer une partie d’un site. 11 27 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – URL13 de sites non bloqués et non filtrés (fichier : exceptionurllist) – Utilisateurs interdits (bloqués lors d’authentification HTTP) (fichier : banneduserlist) – Utilisateurs non filtrés et non bloqués (lors d’authentification HTTP) (fichier :exceptionuserlist) – Adresses IP source (client Web) non autorisées (requête bloquée) (fichier : bannediplist) – Adresses IP source (client Web) dont les paquets (aller-retour) ne sont pas filtrés ni bloqués (fichier : exceptioniplist) Paramètres configurables pour le filtrage dans le sens retour (réponse du serveur) en fonction des entêtes HTTP : – Bloquage de la réponse suivant le type MIME retourné par le serveur (fichier : bannedmimetypelist) – Bloquage de la réponse suivant l’extension du fichier demandé par la requête (fichier : bannedextensionlist) Paramètres configurables pour le filtrage dans le sens retour (réponse du serveur) en fonction du corps des réponse HTTP : – Filtrage du corps de la réponse (remplacement de mots) à l’aide d’expressions régulières (fichier : contentregexplist) – Non bloquage des réponses contenant un des mots figurant dans le fichier exceptionphraselist (filtrage par remplacement de mots toujours actif) – Bloquage de réponses contenant un des mots figurant dans ce fichier (fichier : bannedphraselist) – PICS14 , permettant d’établir des règles de bloquage en fonction du contenu de l’entête html (httpequiv=”PICS-Label”) , permettant de décrire le contenu de la page d’une manière standardisée (fichier : pics) – Fichier permettant d’assigner un poids aux mots permettant ainsi d’établir des règles de filtrage en fonction de leur nombre d’apparition dans les réponses HTTP (fichier : weightedphraselist) L’utilisation d’expressions régulières pour le filtrage de contenu, nous semble un grand atout pour ce produit, c’est donc pour cette raison que nous allons détailler la syntaxe de configuration et la plage d’application du fichier correspondant (contentregexplist). Le fichier contentregexplist Celui-ci contient une liste de mots qui seront recherchés dans les pages retournées aux clients et remplacés par le mot de remplacement correspondant à celui trouvé dans le corps de la page HTTP. Dans l’exemple ci-dessous, tous les popups javascript (alert) envoyés aux clients seront retirés et remplacés par un commentaire HTML : 13 ”Sites entier non filtré” autorise des accès au site entier alors que ce fichier de configuration offre la possibilité de ne pas filtrer et bloquer une partie d’un site. 14 http ://www.w3.org/PICS/ 28 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web "<script.*>.*alert.*</script>"->"<!-- RETRAIT POPUP -->" Il est important de noter que les règles introduites dans ce fichier ne contrôle et remplacent en aucun cas des mots dans les entêtes HTTP ou des paramètres POSTés par le clients. Ce type de filtrage n’a donc pas une grande utilité dans une configuration en reverse-proxy puisque ce que l’on ne cherche pas à protéger un utilisateur mais le serveur Web et l’application serveur elle-même. Il peut tout de même avoir sa raison d’être dans une telle architecture si l’on pense à filtrer des scripts malveillants comme des ”document.cookie()” permettant les attaques de type XSS15 . 3.3 Conclusion Synthèse des différents produits étudiés : Open Source Fonctionnement Whitelist Fonctionnement Blacklist Syntaxe des règles ProxyFilter Squid X X X X X X XML Expressions régulières Dansguardian X X Expression régulières Par interface graphique AppShield X Filtrage de contenu HTML (réponses) Bloquage selon GET X X X X X X Bloquage selon POST X X Bloquage selon entêtes HTTP les URL rewriting X selon certaines X à l’aide d’un programme externe X X ProxyFilter Ce produit étudié durant le travail de semestre et développée par Sylvain Tissot dans le cadre de son projet de Diplôme (2004) repose sur l’architecture d’Apache. Il est donc le module d’un serveur Apache dédié à l’exécution de celui-ci. La configuration en whitelist est très pointue et très ccoûteuseen temps mais offre une protection optimale puisque seul les paramètres non dangereux sont autorisés à être relayé au serveur Web. De même, il sera possible d’éditer une whitelist ou blacklist des entêtes HTTP pouvant être retournées aux clients. AppShield Ce produit étudié par Sylvain Tissot durant son travail de diplôme16 est un outil propriétaire (donc cher) offrant une configuration de type whitelist. Il permet l’utilisation de niveaux de sécurité prédéfinis ainsi que l’affinement de ceux-ci par différentes règles pouvant être définies à l’aide d’une interface graphique. La création de nouvelles règles est facilitées à l’aide de l’analyse des logs qui permettra la création de règles en fonction de ceux-ci en un simple clic. Un support SSL est disponible, ce qui permet la sécurisation de sites HTTPS. Squid (Proxy Open Source) Configuré en reverse-proxy, celui-ci joue le rôle d’accélérateur de serveur Web plutôt que de moyen de protection contre les attaques Web. En effet il offre un service de cache permettant de fournir les pages statiques et les images aux clients à la place du serveur Web. Cependant, il permet à l’aide de règles d’accès (ACL) de définir le bloquage de requêtes clientes. Ce genre de contrôle d’accès est toute fois limité aux types ACL défini par Squid (section 3.1.4) 15 16 Cross site scripting étude disponible sur http ://proxyfilter.sourceforge.net/documents/rapport websecurity diplome.pdf 29 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web et limitera le champ d’action de celui-ci. Squid offre un filtrage17 dans le sens aller (requête vers le serveur) ainsi que dans le sens retour (réponse du serveur). Dansguardian Ce proxy Open Source permet un filtrage pointu sur les contenu HTML ainsi qu’un bloquage des URLs dangereuses demandées par les clients Web. Configuré en reverse-proxy, il permettra la protection du serveur via des expressions régulières offrant la validation des requêtes HTTP. De plus il permettra la protection des clients en contrôlant le contenu des pages HTML transmises à ceux-ci à l’aide d’expressions régulières. 17 Au sens, bloquage de messages 30 Chapitre 4 Architecture retenue et mise en place Ce chapitre définit l’architecture globale du banc d’essai déployé dans le cadre de ce projet. De plus, il soulève les problèmes d’implémentation du reverse-proxy (Dansguardian), propose les modification à y apporter et explique comment celles-ci ont été effectuées. Ensuite, la configuration et la mise en place de la totalité de l’architecture définie sur la figure 4.3 y sont expliqués. 4.1 Définition de l’architecture Après l’étude de ces différents reverse-proxys (ProxyFilter, AppShield, Squid et Dansguardian), il en est ressorti que deux utilisations étaient envisageables : 1. Reverse-proxy générique, nécessitant peu de configuration. 2. Reverese-proxy spécifique à l’application à protéger, nécessitant une configuration pour chaque formulaire présent dans les pages HTML fournies par le serveur (exemple : ProxyFilter). Le premier principe cité repose sur l’utilisation d’une blacklist, alors que le second repose sur une whitelist. Il est évident qu’une whitelist sera toujours plus efficace qu’une blacklist puisqu’elle bloquera tout ce qui n’est pas spécifiquement autorisé. Cette méthode de travail permet de bloquer un grand nombre d’attaques puisqu’elle ne nécessite pas de signatures. Elle stoppera donc simplement tout ce qui n’est pas considéré comme normal pour l’application Web. L’inconvénient majeur de ce fonctionnement vient de la configuration des règles de filtrage. En effet, il faudra, comme dans le cas de ProxyFilter, définir pour chaque document HTML ce qu’il est possible de fournir en paramètres dans l’URL, dans les données POSTées et dans les entêtes HTTP. Un fonctionnement en blacklist devra, quant à lui, définir toutes les signatures des attaques que l’on désire stopper, sans ”aucune” configuration en fonction de l’application à protéger. Il sera donc aisé de protéger son serveur Web en plaçant simplement le reverse-proxy devant celui-ci. La sécurité du serveur Web dépendra ainsi des signatures disponibles sur le reverse-proxy, ce qui impliquera des mises à jour 31 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web régulières de la liste des signatures. Dans le cadre de ce projet, nous avons privilégié une mise en place facilitée (sans configuration spécifique à l’application Web à protéger) plutôt que l’efficacité d’un principe de fonctionnement en whitelist. Ceci permettra de proposer un produit simple d’installation et efficace puisque l’inconvénient du fonctionnement en blacklist du reverse-proxy est ”contré” à l’aide de l’ajout de sondes NIDS et HIDS (comme proposé lors du travail de semestre) dans l’architecture globale. Celles-ci permettront, à l’aide d’une console d’administration des sondes (Prelude-NIDS et Prelude-HIDS) et d’une corrélation des alarmes générées par celles-ci, d’obtenir des informations pertinentes relatives à la sécurité des serveurs Web. Ceci permettra à l’administrateur en charge de la sécurité du réseau, d’ajouter ou corriger les règles de filtrages définies sur le reverse-proxy. Notre choix s’est porté sur Dansguardian, puisque celui-ci travaille en blacklist (proxy générique) et offre les mêmes caractéristiques que Squid, avec la capacité supplémentaire non négligeable permettant de filtrer les corps des documents HTML et TXT. Comme expliqué 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é sur une machine disposant d’une seule interface réseau. L’utilisation de Dansguardian implique quelques petites modifications de son code source, puisque celuici n’est pas prévu pour fonctionner en reverse-proxy. Nous lui avons alors ajouté la possibilité de contrôler des données POSTées par les clients. Nous avons ensuite testé son fonctionnement et l’avons adapté (le code source) aux besoins d’un reverse-proxy. Ces modifications sont relatées dans la section 4.2. La figure 4.1 illustre l’architecture retenue pour le reverse-proxy fonctionnant à l’aide de signatures d’attaques (blacklist), alors que la figure 4.2 illustre l’architecture globale de SIMS orienté Web. Cette architecture a été ébauchée lors du travail de semestre. Pour le travail de corrélation qui suivra, nous pensons que l’adjonction d’un HIDS sur le firewall en plus des sondes NIDS avant et après le reverse-proxy et de la sonde HIDS du reverse-proxy est un atout supplémentaire. En effet, une attaque commence très souvent par une étape de découverte du réseau cible et des services s’exécutant sur les machines accessibles. Le HIDS du firewall nous permettra de détecter très facilement les scans de ports qui précédent une attaque. Une sonde NIDS ne pourrait pas suffire à la détection de scans de ports puisque celles-ci n’ont pas une capacité d’analyse permettant la corrélation d’événements indépendants et n’ont aucune possibilité d’établir des règles permettant de lever des alertes affirmant qu’il y a eu un scan de ports. Il faudrait établir des règles permettant d’alerter l’accès à chaque port d’une machine pour qu’un corrélateur externe puisse analyser ces alertes et en conclure à un scan de ports. Le HIDS du firewall nous offre donc la possibilité de récupérer facilement des informations sur les paquets refusés par le firewall et sur les ports auxquels ceux-ci s’adressaient. Une fois ces informations transmises par le HIDS du firewall vers le Manager, il sera aisé de les analyser afin de mettre en évidence les scans de ports et autres manipluations avant-coureuses d’une attaques. 32 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 4.1 – Fonctionnement du reverse-proxy de SIMS orienté Web Nous avons ensuite placé différentes sondes réseaux (NIDS) et host (HIDS permettant l’analyse de logs). Afin de pouvoir en tirer les meilleures conclusions pour l’élaboration de la stratégie de corrélation, nous avons placé un maximum de sondes. Nous disposons donc d’une sonde réseau à chaque niveau (prereverse-proxy et post-reverse-proxy). La première permettra de relever des alertes avant l’éventuel bloquage du reverse-proxy (sonde pre-reverse-proxy) alors que la seconde permettra de relever les attaques ayant tout de même passé le filtrage imposé par le reverse-proxy (sonde post-reverse-proxy). De plus, nous avons disposé les sondes HIDS sur le firewall (comme expliqué ci-dessus), sur le reverseproxy ainsi que sur le serveur Web. Il nous sera possible, à l’aide de la sonde HIDS du reverse-proxy d’observer les bloquages effectués par celui-ci. La sonde placée sur le serveur Web, nous permettra quant à elle d’observer les accès effectués sur le serveur Web. A l’aide des toutes ces informations, il nous sera possible de retracer l’activité d’un client et d’en déduire précisément ses intentions (Cracker ou simple client Web). Le travail de corrélation qui suivra nous amènera peut-être à retirer l’une ou l’autre des sondes NIDS ou HIDS puisque seule l’analyse des différentes attaques et des informaitons recueillies par les sondes pourra nous prouver l’utilité de cellesci. 33 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 4.2 – Architecture globale de SIMS orienté Web Vous constaterez, à l’aide de la figure présentant l’architecture physique 4.3, que l’Intranet a été supprimé pour les tests, puisque celui-ci n’apporte rien de plus pour la corrélation des événements. Nous avons donc créé 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écurité, se trouver dans le réseau local de l’entreprise (comme illustré sur l’architecture logique globale), mais pour des raisons de facilité de mise en place, nous avons préféré le garder dans la DMZ. La machine officiant en SGBD permettra, en plus, d’interroger le manager des différentes sondes (Prelude manager) à l’aide d’un client Web (console d’administration). Cette console d’administration devrait en principe se trouver dans le réseau d’entreprise afin d’éviter la mise en place d’une machine supplémentaire dans la DMZ. Pour des raisons de facilité de mise en place, nous avons préféré la laisser dans la DMZ. Afin de ne pas dédier des machines à chaque NIDS, nous en avons placé un sur la machine Prelude Manager et nous la connectons sur le même segment que le serveur Web. Ce NIDS nous servira donc de sonde post-reverse-proxy alors que la sonde pre-reverse-proxy se situera directement sur celui-ci. Il est évident que cette dernière capturera le trafic post-reverse-proxy et pre-reverse-proxy, puisque le reverse proxy ne dispose que d’une seule interface réseau. Afin d’isoler le trafic pre-reverse-proxy, il suffira, lors de la visualisation des alertes, de mettre en place une règle de filtrage en fonction de l’adresse IP de destination. 1 Zone démilitarisée 34 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 4.3 – Architecture physique de SIMS orienté Web 4.2 Modification du code source de Dansguardian pour le contrôle des donnée POSTée Après avoir obtenu des informations sur le forum de Dansguardian (http ://groups.yahoo.com/group/dansguardian/), il s’est avéré très facile de modifier le code source pour que les données contenues dans un POST (requête d’un client) soient contrôlées. Il faut donc ajouter le code ci-dessous dans le fichier ConnectionHandler.cpp après le contrôle de la taille des paramètres du POST dans la méthode suivante ”handleConnection(Socket peerconn)” : //si la requete n’est pas encore été refusée on contrôle le POST} if (!checkme.isItNaughty){ #ifdef DGDEBUG std::cout << "Check des data dans le POST" << std::endl; #endif //controle le buffer passé en paramètre avec les fichiers de configuration //bannedphraselist et exceptionphraselist checkme.checkme(&header.postdata); //check pour le filtrage contentregexlist 35 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web header.postdata.contentRegExp(); } L’inconvénient majeur de cette modification vient du fait que les fichiers de configurations utilisés pour déterminer s’ il y a filtrage ou bloquage sont les mêmes pour les données émises au client (réponse du serveur Web) et celles transmises par celui-ci (POST). De ce fait, si nous définissons des règles de filtrage du POST afin d’éviter des attaques de SQLinjection, nous établirons une règle recherchant le pattern ’ OR 1=1. Si maintenant celui-ci se retrouve dans une phrase d’une page Web, celui-ci sera aussi filtrée. Ce fonctionnement posera des problèmes puisque le filtrage opéré sur une requête HTTP ou une réponse HTTP n’est pas le même. En effet, les attaques possibles du côté client et du côté serveur ne sont strictement pas identiques. Améliorations Dans l’architecture d’un reverse-proxy, il est préférable de bloquer les requêtes d’un client Web transportant un contenu suspect, plutôt que de les filtrer (remplacement de mots). Cette conclusion est très facilement justifiée lors du couplage du serveur Web avec une base de donnée. En effet, il serait très peu souhaitable pour un client Web, de recevoir des données ne correspondant pas à sa requête (venant de la substitution de mots opérée par le reverse-proxy). Dans tous les cas, il est préférable de l’avertir par une page html de refus d’exécution du serveur plutôt que de filtrer le contenu de la requête HTTP à son insu. De plus, il peu recommandable d’offrir la possibilité de bloquer la réponse du serveur Web (en envoyant une page html similaire à celle d’un refus d’exécution), puisque l’on pourrait imaginer de simples déni de services en insérant des mots bien précis dans un forum. La seule opération envisageable sur une réponse HTTP est le filtrage de contenu (remplacement de mots) afin d’éviter la présence de scripts malveillants tout en évitant des bloquages indésirables. Après ces différentes observations, il nous est possible de définir les modifications que nous devrons apporter à Dansguardian afin que celui-ci fonctionne en reverse-proxy. Le filtrage du GET ne pose aucun problème puisqu’il est déjà disponible à l’aide d’expressions régulières via le fichier de configuration bannedregexpurllist. Pour le filtrage du POST, il est indispensable d’utiliser des expression régulières. Il est flagrant, que pour l’exemple de SQLinjection donné ci-dessus, qu’il est impossible d’établir une règle sans utiliser une expression régulière, puisque les ”1” utilisé dans l’attaques peuvent être remplacés par n’importe quel nombre. Les trois principaux fichiers de configuration existants pour le filtrage de contenu (dans les deux sens) sont : exceptionphraselist, bannedphraselist, contentregexplist. Nous garderons donc uniquement le fichier contentregexplist pour opérer le filtrage de contenu (remplacement de mots) des réponses HTTP émises par le serveur Web. Il nous faut alors retirer : bannedphraselist afin d’éviter le bloquage des réponses du serveur HTTP et exceptionphraselist puisque celui-ci n’a plus aucun sens si bannedphraselist n’existe plus. En effet, il offrait la possibilité de relayer la réponse HTTP si un des mots qu’il contenait apparaissaient dans la page Web, même si des mots bannis (contenu dans bannedphraselist 36 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web étaient présents). Il nous faudra ensuite définir un fichier de configuration (bannedregexpostdata) permettant d’établir des expressions régulières définissant si un refus de la requête à lieu en fonction du contenu du POST. Après ces quelques modifications Dansguardian fonctionnera comme un parfait reverse-proxy. Nouvelles modifications du code source (partie technique) Puisque les données transitant par Dansguardian sont encapsulées dans une structure de données nommée Databuffer (Databuffer.cpp), nous ajoutons une méthode dans cette classe qui nous permettra de contrôler les données fournies par le client (POST). Celle-ci se nomme PostDataRegExOk() et retourne un boolean qui indique si les données postées sont autorisées ou non. Pour ce faire, nous nous appuyons sur l’implémentation de contentRegExp() qui, elle, contrôle le contenu du corps des réponses HTTP et remplace les mots trouvés. Nous sommes ensuite obligé de modifier la classe OptionContainer (OptionContainer.cpp) qui offre les méthodes de lecture des fichiers de configuration. Nous ajoutons donc une méthode qui nous permettra de lire le fichier de configuration propre au filtrage des données POSTées (bannedregexpostdata). Celle-ci se nomme readPostRegexfile(const char* filename) et sera appelée dans la même classe (dans la méthode read(std : :string filename)). Nous nous appuyons sur la méthode readbreufile(const char* filename) qui, elle, s’occupe de lire les expression régulières du fichier bannedregexpurllist pour l’implémentation de notre méthode. Comme le fichier de configuration global (dansguardian.conf) contient tous les chemins des différents fichiers de configuration pour le filtrage, nous ajoutons la lecture d’une balise dans cette même méthode read(std : :string filename) permettant de déterminer l’emplacement du nouveau fichier de configuration. Il nous faut maintenant appeler la méthode de contrôle des donnés POSTées précédemment créé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éthode handleConnection(Socket peerconn) et, suivant le résultat retourné par celle-ci, de mettre à jour la variable indiquant si la requête sera bloquée ou non (checkme.isItNaughty). Comme l’utilisation de PostDataRegExOk() n’a aucun sens s’il n’y a pas de data POSTée, nous décidons d’utiliser la méthode (header.isPostUpload()) fournie par la classe Header permettant de déterminer s’il y a ou non des données à destination du serveur. Après quelques essais, nous remarquons que celle-ci ne fonctionne pas puisqu’elle nous indique dans tous les cas qu’il n’y a pas de données POSTées. Peut-être que son fonctionnement est dépendant de la configuration du contrôle de la taille des données POSTées (configuration faisant partie des fonctionnalités de bases de Dansguardian). Nous décidons donc de créer une nouvelle méthode dans la classe Header afin de savoir si des données sont transmises au serveur. Il s’agit donc d’une méthode (bool void isPostData()) qui retournera un boolean (postDataInHeader) à true lorsque la méthode in(Socket sock) détecte une entête POST. Nous retirons ensuite la lecture des fichiers de configuration plus utiles dans une architecture en reverseproxy (comme expliqué dans le paragraphe améliorations). Il s’agit donc des fichiers bannedphraselist, 37 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web exceptionphraselist, bannedurllist et bannedsitelist et leurs méthodes 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érer de filtrage ni de bloquage pour les sites mentionnées dans ces fichier de configurations. Ainsi configuré, 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érer des tests de mise au point des fichiers de configurations et d’observer la différence entre le site filtré et non filtré sans pour autant retirer le reverse-proxy de l’architecture. Nous allons maintenant retirer les appels aux méthodes testant les requêtes et réponses en fonction des fichiers de configurations non désirés. Celles-ci seront retirées de la classe ConnectionHandler (dans la méthode de gestion de la connexion handleConnection(Socket peerconn)). Il s’agit donc de la méthode checkme.checkme(&docbody) qui bloque tout réponse au client lorsque des mots contenu dans bannedphraselist y figurent, o.banned url list(temp) qui bloque la requête si l’URL fournie figure dans bannedsitelist et o.inBannedSiteList(temp) qui bloque la requête si le site indiqué dans la requête figure dans bannedsitelist. Il est important de noter que toutes les modification apportées dans les fichiers d’entêtes (*.hpp) et d’implémentation (*.cpp) on été indiquées par un commentaire commençant par 4 étoiles (/****) il est ainsi facile de les retrouver. Dès lors, chaque fois que nous parlerons de DansguardianSims, nous nous référerons à l’application Dansguardian modifiée (comme expliqué 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ême pour la compilation (make). Ensuite, lorsque vous exécuterez le make install, il se peut que différentes erreurs surviennent puisqu’il cherchera à copier des fichiers de configuration qui n’ont plus lieu d’être dans le cadre de l’application DansguardianSims. Afin de passer outre, il vous suffira d’éditer le fichier Makefile que le ./configure aura créer afin de commenter (# en début de ligne) les lignes interrompants l’installation. Une modification du script de configuration aurait été nécessaire afin d’éviter l’intégration gênante de 38 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web ces lignes lors de la génération du Makefile. Comme la modification de Dansguardian n’est pas le but premier de ce projet de diplôme, nous décidons d’en rester là afin de ne pas ”perdre” trop de temps sur la mise en place de l’architecture. Afin de pouvoir exécuter DansguardianSims, il faudra encore ajouter le chemin du fichier de configuration du contrôle des données émises par les clients (POST). Il vous suffira donc d’ajouter la lignes suivante à la suite des chemins d’accès pour les différents fichiers de configurations : bannedregexpostdata = ’/chemin/fichier/conf/reglesPost’ Configuration Dans cette section, nous allons passer en revue tous les fichiers de définition des règles utilisés dans le cadre de DansguardianSims : bannediplist Ce fichier permet de donner une liste d’adresses IP (une par ligne) qui seront interdites d’accès au site web protégé par le reverse-proxy. Celui-ci renverra une page html indiquant que l’accès est refusé. exceptioniplist Ce fichier permet de donner une liste d’adresses IP (une par ligne) dont les requêtes et les réponses qui en découlent ne seront jamais contrôlées (filtrées2 ou bloquées) par le reverse-proxy. banneduserlist Lorsque l’accès à un répertoire requiert une authentification HTTP, ce fichier de configuration permet de bloquer les utilisateurs dont le nom (username) est présent dans ce fichier (un username par ligne). exceptionuserlist Lorsque l’accès à un répertoire requiert une authentification HTTP, ce fichier de configuration permet de ne pas contrôler (filtrer ou bloquer) les requêtes (et les réponses qui en découlent) des utilisateurs présent dans cette liste. exceptionsitelist Ce fichier permet de préciser des sites pour lesquels il n’y a aucun filtrage ou bloquage à opérer (sur les requêtes ainsi que sur les réponses). Il faudra y placer un nom de domaine par ligne en retirant l’entête ”http ://www.”. exceptionurllist Ce fichier permet de préciser des URLs (pas un site entier, mais une sous arborescence ou un répertoire) pour lesquels il n’y aura aucun filtrage ou bloquage (des requêtes et des réponses). Il faudra donc y placer une URL par ligne en retirant l’entête ”http ://www.”. bannedextensionlist Fichier définissant toutes les extensions de fichiers à bloquer (à ne pas transmettre au client). Le contrôle s’opère sur la fin de l’URL (qui contient le nom de fichier transmis, donc son extension) que le client demande. Il faudra placer une extension par ligne dans le format suivant : .¡extension¿ bannedregexpurllist Ce fichier permet de définir des expressions régulières afin de contrôler l’URL que le client transmet (requête). Si une de ces expression s’applique, la requête du client sera bloquée. Il faudra donc entrer une expression régulière par ligne. 2 Au sens remplacement de mots dans le corps d’un document html ou text 39 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web bannedregexpostlist Ce fichier permet de définir des expression régulières afin de contrôler les paramètre POSTé au serveur (dans la requête du client). Il faut prendre garde au codage, puisque l’analyse des données POSTées ce fait sans décodage préalable de celles-ci. Il faudra donc, dans les expressions régulières, coder les caractères spéciaux en UTF8. bannedmimetypelist Ce fichier permet de définir les types MIME (un par ligne) que DansguardianSims bloquera. Il ne transmettra pas les réponses au client contenant un des types MIME mentionné dans ce fichier. messages Ce fichier permet de définir les messages qui seront affichés dans la page html retournée au client en cas de bloquage de sa requête par DansguardianSims. contentregexplist Ce fichier de configuration permet de définir des règles de filtrage (remplacement de mots) des réponses émises par le serveur Web. Il est donc possible de définir des expressions régulières afin de rechercher des mots dans un document html ou txt (retourné par le serveur) afin de les remplacer par le ou les mots indiqués dans ce fichier. La syntaxe de configuration est illustrée dans la section 3.2.4. Les fichiers de configuration ”exception....” sont conservé pour une architecture en reverse-proxy pour une question de facilité de test et non pas pour leur utilité dans l’exploitation du reverse-proxy. En effet, lors de la mise sur pied de règles de filtrage, il est très intéressant d’observer l’effet du filtrage ou du bloquage. Il sera ainsi très facile de changer la configuration afin d’observer des requêtes sans filtrage/bloquage plutôt que ”d’attaquer” directement le serveur Web. 4.3 Installation des NIDS Pour la compilation, l’installation et la configuration de Prelude-nids, nous nous sommes reporté au travail de diplôme de Patrick Saladino annexe C.4.3 page 93 et C5 page 96. Nous avons ensuite suivi la procédure d’enregistrement de la sonde sur le manager comme décrit dans cette annexe. La configurations de celles-ci (indication de l’IP du manager et choix des règles à 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é au travail de diplôme de Patrick Saladino annexe C.4.4 page 95 et C5 96. Nous avons ensuite suivi la procédure d’enregistrement de la sonde sur le manager comme décrit 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 4.4.2 Création d’une blacklist Pour ce faire, nous scannons à l’aide de Nessus3 le serveur Web (sans passer par le reverse-proxy) afin d’en ddéterminerses vulnérabilités. A l’aide du rapport de sécurité établi par Nessus, il nous est possible de connaı̂tre le CVE4 des différentes attaques réussies et d’en rechercher le pattern dans les codes NASL5 des attaques fournies par Nessus. Pour ce faire, nous téléchargeons (sur : http ://www.nessus.org/scripts.php) les codes NASL des attaques Nessus que nous décompressons dans un répertoire. 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 plaçons dans le répertoire 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érabilité correspond au fichier rontpage chunked overflow.nasl. Il nous est ainsi possible à l’aide du code, d’observer les data émises, vers la machine cible, qui caractérisent l’attaque afin d’en établir la règle qui la bloquera. De plus, nous isolons l’attaque dont nous voulons créer la règle correspondante (à l’aide de la sélection de scripts sous Nessus) et nous analysons les paquets émis à l’aide d’Ethereal. Il nous est ainsi possible d’observer la construction exacte et les caractéristiques de la trame ou des trames constituant l’attaque. Les règles permettant de bloquer les attaques sont définies dans les fichiers de configuration (étudié dans la section 4.2.1) de DansguardianSims à l’aide d’expression régulières. Une fois la black liste établie sur le reverse-proxy (section 4.4.2), nous lanç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’établir les règles de récupération de ceux-ci sur le HIDS (section 4.4.3). Blacklist pour DansguardianSims A l’aide de la méthodologie décrite précédemment nous établissons les différentes règles permettant de bloquer plusieurs vulnérabilités découvertes à l’aide de Nessus. Il nous est alors possible de définir le fichier de configuration bannedregexpurllist permettant de bloquer l’accès au serveur Web lorsqu’un des pattern contenu dans ce fichier est trouvé dans l’URL. #Empêcher le SQL injection sur des paramètre émis via GET .*?.*=.*’.*OR.*=.* .*?.*=.*’.*UNION.*SELECT.*FROM.* #CVE: CAN-2003-0822 Buffer overflow sur la DLL fp30reg.dll .*/_vti_bin/_vti_aut/fp30reg.dll 3 Scanner de vulnérabilités Open Source Common Vulnerabilites and Exposures 5 Nessus Attack Scripting Language, langage de script permettant de coder des attaques qui permettrons d’établir si une machine est vulnérable 4 41 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web #CVE: CAN-2000-0884 exécution de commande à distance à l’aide d’une représentation unicode #du slash permettant la remontée à cmd.exe (les points doivent etres échapés #dans les expressions régulières) .*/msadc/\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\.%c0%af\.\./ #CVE: CVE-2001-0333 exécution de commande à distance à l’aide d’une représentation unicode #du slash permettant la remontée à cmd.exe (les points doivent etres échapés #dans les expressions régulières) .*/msadc/\.\.%255c\.\.%255c\.\.%255c\.\.%255c\.\.%255c\.\./ #CVE: CAN-1999-0739 visualisation des codes sources via un script ASP de démo .*/iissamples/sdk/asp/docs/codebrws? #CVE: CAN-1999-1011 Possibilité 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ées par le serveur Web, nous servira pour le moment uniquement à la protection des clients contre le cross site scripting. Nous remplaçons tous les scripts permettant l’affichage d’un cookie par un commentaire, à l’aide de la syntaxe de configuration ci-dessous : "document.cookie"->"<!-- document.cookie -->" Le fichier bannedregexpostdata permettant de bloquer l’accès au serveur à des requêtes comportant des données POSTées dangereuses sera pour le moment uniquement utilisé pour un bloquage des tentatives de SQL injection sur des paramètres émis via la méthode HTTP POST. Étant donné que les paramètres émis via un post sont codés en x-www-form-urlencoded et qu’aucune conversion n’est effectuée avant le filtrage, nous avons été obligé d’écrire les différentes règles en transformant les caractères spéciaux en leur représentation x-www-form-urlencoded : #empêcher le SQL injection (%27 représente ’ et %32 représente =) %27.*OR.*%3d .*union.*select.*from 4.4.3 Pattern matching de Prelude-lml pour DansguardianSims Après avoir établi les différentes règles de bloquage et de filtrage de DansguardianSims, nous avons effectué les attaques susceptibles d’être bloqués par DansguardianSims. Il nous a ensuite suffit d’observer le fichier de log de dansguardianSims (/var/log/dansguardian/access.log) afin de déterminer la construction des logs et les différentes informations fournies par ceux-ci. Ces observations nous ont ensuite permi la création des règles de récupération des logs par l’intermédiaire des alarmes IDMEF qu’offre prelude-lml. Nous avons donc créé un fichier de règle pour le HIDS du reverse-proxy (/etc/preludelml/rulset/dansguardian.rules) que nous avons placé avec les règles déjà disponible dans prelude-lml. Nous avons ensuite activé son utilisation dans le fichier de configuration des règles de l’HIDS (/etc/preludelml/rulset/simple.rules) et nous avons précisé quel était le nouveau fichier de log à analyser (à l’aide du 42 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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 Étant donné qu’aucunes sondes Prelude n’est ddiponiblessur Windows, nous sommes dans l’obligation de récupérer les logs produit par IIS6 et de les envoyer à un serveur syslog (Linux) distant. Pour ce faire, nous utiliserons l’outils open source ”SnareIIS” développé par InterSect Alliance7 . Nous utiliserons la machine officiant en reverse-proxy pour la récupération des ces logs puisqu’une sonde Prelude-lml y est déjà disponible. Sur celle-ci, il suffira de créer de nouvelles règles (pattern matching des logs) afin que les alarmes voulues soient rapatriées vers le Manager (Prelude Manager). La figure 4.4 illustre ce principe de fonctionnement. F IG . 4.4 – Principe de rapatriement des logs d’IIS vers la sonde HIDS du reverse-proxy 4.5.1 Configuration du client Windows Snare et d’IIS La figure 4.5 illustre la configuration du client Snare effectuée, afin que la station 192.168.1.2 (reverseproxy) reç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ère ainsi qu’un format é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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 4.5 – Configuration de l’utilitaire de récupération des logs d’IIS Log File Format) afin que Snare soit capable de les lire. Cette configuration est accessible dans le menu de configuration de IIS, dans l’onglet Web Site. En cliquant sur le bouton Properties..., il sera possible de définir la période de rotation des logs ainsi que leur format. 4.5.2 Configuration du serveur syslog Linux Syslogd est le daemon s’occupant de la récupération de log d’une machine Linux. Par défaut celui-ci travaille uniquement en local. Lors de son lancement (commande syslogd), via l’argument ”-r”, il est possible de lui indiquer d’ouvrir le port 514 UDP pour la récupération de logs distants. Nous modifions donc son script de lancement ”sysklogd” placé dans /etc/ini.d/. Il suffira donc d’ajouter le ”-r” dans la variable SYSLOGD déjà présente dans ce fichier, comme illustré 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éciser que le protocole de transfert de logs basé sur UDP n’est pas sécurisé. Les trames circulent ”en clair” sur le réseau. De plus l’utilisation d’UDP implique une éventuelle possibilité de perte des paquets sans qu’aucun des deux partenaires ne s’en rende compte (principe même d’UDP). 44 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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’établir l’expression régulière qui permettra de relever (donc d’envoyer des alarmes IDMEF à Prelude Manager) les logs d’accès d’IIS qui ont un code de status indiquant une erreur de la requête HTTP effectuée par le client (4xx). En effet, il sera iintéressantlors de la phase de corrélation, de connaı̂tre les requêtes n’ayant pas abouti. Nous créons un fichier de règles (/etc/preludelml/rulset/iis.rules) dans lequel nous définissons le pattern à rechercher et le message IDMEF à 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ésenté dans l’architecture globale a une fonction de routage, puisqu’il comprend deux interfaces réseaux (la première ayant une adresse IP publique8 et la seconde ayant une adresse IP privée, du réseau 192.168.1.0/24). Il permet ainsi la communication entre la DMZ contenant nos serveurs et le monde extérieur. Pour ce faire, nous avons utilisé une machine Linux à deux interfaces réseaux dédiée à la fonction de firewall. Nous avons activé Iptables, logiciel directement intégré au Kernel Linux, permettant de filtrer et modifier les paquets arrivant et partant des cartes réseau de la machine en question. Pour son activation, il suffit, dans le répertoire des sources de votre kernel, d’éditer le menu de configuration de celui-ci, à l’aide de la commande suivante : eduPc002:/usr/src/linux-2.4.27# make menuconfig Puis, dans l’interface ”graphique” qui vous sera proposée, 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écessaires au NAT, MASQUERADING, ainsi qu’au filtrage. Pour notre part, nous avons activé 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éseau TCOM, donc en 10.192.72.0/23 45 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ères que nous définirons. Maintenant que la configuration d’Iptables dans le kernel est terminée, 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érieur (réseau TCOM). A l’aide de cette configuration, nous pouvons définir que toutes les adresses IP de destination des paquets arrivant sur l’interface publique du firewall, avec comme adresse IP de destination 10.192.72.83 (l’adresse publique du firewall) et comme port de destination 80, se feront substituer par l’adresse IP du proxy (192.168.1.2) avant le routage. Ces paquets seront relayés vers le reverse-proxy par le firewall. Iptables applique implicitement la règle inverse sur tous paquets ayant l’adresse IP du proxy comme adresse source et le port source 80. Il substituera donc l’adresse IP source d’un paquet ayant ces caractéristiques par sa propre adresse IP publique. De cette façon, tous les clients Web extérieurs penserons directement atteindre le serveur Web via l’adresse IP 10.192.72.83. Nous devons ensuite configurer les règles permettant de bloquer le trafic indésirable. Lors de l’utilisation du filtrage avec une fonction de NAT activée, il suffira, pour l’établissement des règles de filtrage d’ignorer les changements d’adresses opéré par le NAT. Lors de la mise en place d’un firewall/NAT il est donc préférable de mettre au point la fonction de translation d’adresses (NAT) avant la fonction de filtrage afin de ne pas mélanger les problèmes lors des tests. Les règles de filtrages sont à l’instar des règles de translation d’adresses unidirectionnelles. Il faudra à chaque fois créer une règle pour le flux entrant et le flux sortant. Voici un extrait du script d’établissement des règles de filtrage que nous avons établi pour l’accès au serveur Web : ############################################################# #NAT statique pour l’accès au reverse-proxy depuis l’extérieur ############################################################# iptables -t nat -A PREROUTING -p tcp --dport 80 -d 10.192.72.83 -i eth0 -j DNAT --to-dest 192.168.1.2 ########################################################### #Authorise le trafic Web avec le reverse-proxy 192.168.1.2 ########################################################### iptables -A FORWARD -i eth0 -p tcp -d 192.168.1.2 --dport 80 -j ACCEPT iptables -A FORWARD -i eth1 -p tcp -s 192.168.1.2 --sport 80 -j ACCEPT 9 daemon de récupération des logs Linux Network Address Translation 11 Changement d’adresses avant le routage opéré par le stack IP de la machine (PREROUTING) 10 46 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web ###################################################################### #Autorisation des requêtes DNS pour tout le réseau (Squid en a besoin) ###################################################################### iptables -A FORWARD -i eth1 -p udp -s 192.168.1.0/24 --dport 53 -j ACCEPT iptables -A FORWARD -i eth0 -p udp -d 192.168.1.0/24 --sport 53 -j ACCEPT De plus, il est préférable d’établir les polices par défaut des différentes chaı̂nes12 à l’état ACCEPT et d’établir une règle finale (la dernière du script) qui refusera tous les paquets. Étant donné que les paquets traversent les différentes chaı̂nes de filtrage dans l’ordre de déclaration des règles, la règle finale interviendra uniquement sur les paquets auxquels aucune règle ACCPET ne s’applique. Cette méthode de travail permettra une réinitialisation aisée lors des tests. En effet l’utilisation de la commande iptables -F a pour effet d’effacer toutes les règles de filtrage des différentes chaı̂nes sans pour autant effacer les polices par défaut. Lors de son utilisation, et d’une police par défaut au refus de toute connexions (DROP), le firewall ne sera malheureusement plus atteignable et bloquera absolument tout. Une police par défaut à ACCEPT permettra par exemple, lors de la réinitialisation du firewall (iptables -F) effectué par un shell SSH13 de garder la connexion active après son exécution. ############################################ #Polices par défaut des différentes chaı̂nes ############################################ iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT .... règles de filtrages .... ########################## #règles de refus finales ########################## iptables -A INPUT -j DROP iptables -A FORWARD -j DROP 4.6.1 Récupération des logs du firewall Pour ce faire, nous créons une nouvelle chaı̂ne de filtrage utilisateur que nous nommons LOG DROP. Cette nouvelle chaı̂ne aura pour effet de ”jeter” le paquet et de le logger. Nous ajoutons la règle LOG et DROP à cette nouvelle chaı̂ne (comme illustré ci-dessous) : #création de la chaı̂ne iptables -N LOG_DROP #ajout des règles iptables -A LOG_DROP -j LOG --log-prefix "Drop " iptables -A LOG_DROP -j DROP 12 Une chaı̂ne représente un groupe de règles pour une fonctionnalité. Les différentes chaı̂nes présentent de base sont : INPUT (paquet entrant), OUTPUT (paquet sortant), FORWARD (paquet devant être routé) 13 Shell distant reposant sur une connexion TCP cryptée (port 22) 47 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web L’ajout du préfixe ”Drop ” aux logs ainsi crées est indispensable au bon fonctionnement de PreludeLML (sonde HIDS de Prelude), puisque la recherche de pattern préétabli pour Netfilter (/etc/preludelml/rulset/netfilter.rules) recherche un tel préfixe afin de déterminer si le logs doit être apatrié au Manager Prelude. La totalité 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 Étant donné qu’un grand nombre de paquets sont refusé par le firewall (le seul port ouvert étant le port 80), les fichiers de logs ont la fâcheuse tendance à 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éfaut cet utilitaire est exécuté journalièrement par CRON14 afin de contrôler si les critères de rotation des logs sont atteints. Le fichier de configuration crontab définit plusieurs répertoires ccomportantles scripts étant exécutés : chaque heure pour le répertoire cron.hourly, chaque jour pour le répertoire cron.daily, chaque semaine pour le répertoire cron.weekly ou chaque mois pour le répertoire cron.monthly. Logrotate figure donc dans le répertoire /etc/cron.daily. Lorsque CRON exécutera cet utilitaire, il contrôlera suivant les critères défini dans /etc/logrotate quels sont les fichier de logs à ”roter”. Suivant la configuration, cette rotation aura pour effet de compresser le fichier de log et de le stocker dans le répertoire voulu. Lorsque le nombre maximum d’archives de fichiers de logs compressé 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ées (*.tar.gz). rotate 3 Indique que 3 archives compressées seront gardée (les anciennes étant remplacées par les nouvelles). size=4M Indique que lorsque la taille du fichier /var/log/syslog atteindra 4M, celui-ci sera ”roté”. 14 daemon exécutant des commandes suivant un calendrié pré-programmé (/etc/crontab) 48 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web olddir Permet de préciser dans quel répertoire seront placé les archives compressées. postrotate - endscript Englobe une commande qui sera directement exécutée après 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éer les fichiers de logs supprimés. Lors de l’utilisation de la directive size, et suivant la vitesse de d’accroı̂ssement des logs, il sera nécessaire de déplacer le script de rotation des logs se trouvant dans /etc/cron.daily/ vers le répertoire /etc/cron.hourly/. En effet, il se peut que la taille limite définie dans le fichier de configration ci-dessus soit rapidement atteinte en un jour. Un contrôle horraire peut donc s’avérer indispensable. 49 Chapitre 5 Corrélation Ce chapitre commencera par poser les bases de la corrélation, son utilisation et pour finir son application au banc d’essai du projet. Différents scénarii d’attaques seront envisagés afin d’illustrer au mieux les mesures introduites par la corrélation. 5.1 Définition et principe La corrélation est définie comme une relation entre deux ou plusieurs variables. Imaginons maintenant que ces variables soient les alarmes de différents IDS répartis sur un réseau. Un mécanisme de corrélation1 capable de trouver une relation entre plusieurs alarmes de différents IDS nous permettra ensuite de déduire plus facilement la dangerosité d’une alarme puisque celle-ci ne se trouvera plus noyée dans un flot d’alarmes mais associée à un contexte ou à une action bien précise. Le lieutenant Colombo2 est donc un exemple ”concret” de moteur de corrélation puisqu’il sera toujours capable de reconstruire le puzzle d’un crime. Après 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éduire le coupable. Il s’agit donc d’un comportement totalement analogue à un moteur de corrélation pour des alarmes de détecteurs d’intrusions. En effet, les alarmes d’une source (IDS) bien précise pourraient être définies comme le crime potentiel, alors que les alarmes des autres sources (IDS) comme les suspects. Notre moteur de corrélation se chargera donc de les analyser (équivalent à l’interrogation d’un suspect) et fournira un bilan sur chaque alarme. 1 2 Mécanisme mis en place par un moteur de corrélation (software s’occupant de la corrélation) Lieutenant bien connu d’une série américaine du même nom (crée en 1968 ) 50 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 5.2 Application L’architecture réseau à disposition (figure 4.3 page 35) et les nombreuses sondes disposées dans celleci nous permettrons de défnir plusieurs stratégies d’investigations. En effet, l’événement déclencheur (appelé crime potentiel dans la section 5.1) de l’investigation pourrait provenir de différentes sources d’alarmes (IDS). Nous sommes donc dans l’obligation de définir plusieurs scénarii d’investigation (un pour chaque déclencheur). A ce stade de la corrélation, il est important de faire la distinction entre les scénarii d’investigation et ceux d’attaques. En effet, le projet de diplôme SIMS 2003 de Patrick Saladino était orienté sur la création de scénarii caractéristiques d’une attaque. Ces scénarii étaient recherchés dans le flot des alarmes d’un IDS par le moteur de corrélation mis au point dans le cadre de ce projet. Il s’agissait donc d’une recherche de suite d’alarmes dans une fenêtre temporelle prédéfinie. Étant donné que les alarmes ne provenaient que d’une seule source, une stratégie d’investigation était impossible. Grâce à l’architecture déployée dans la première partie de ce projet, nous sommes capable de définir des scénarii d’investigation à l’aide des différentes alarmes émises par les sondes NIDS et HIDS puis récoltées par Prelude-Manager3 . Le principal avantage des scénarii d’investigations sur ceux d’attaques vient du fait qu’il sont génériques et très souvent indépendants du type d’attaques, puisqu’ils ne dépendent plus de l’attaque mais de l’architecture mise en place (des différentes sondes et de leurs positions dans le réseau). 5.2.1 Mais qu’apportera concrètement la corrélation ? L’image entre l’insepecteur Colombo et notre moteur de corrélation est bonne jusqu’à un certain point seulement. En effet, l’inspecteur Colombo n’enquêtera jamais pour un crime inexistant, alors que dans notre cas, chaque événement (alarme) déclencheur d’un scénarii de corrélation doit être considéré comme un ”crime potentiel”, puisqu’il est impossible en analysant uniquement cet événement de savoir s’il s’agit d’une alarme dangeureuse pour notre architecture ou d’une alarme levée pour aucun4 événement dangereux dans notre cas. Ce problème provient uniquement du mode de fonctionnement en blacklist des sondes réseaux (NIDS) et des sondes analysant les logs (HIDS). En effet, dès qu’un pattern sera détecté par l’une ou l’autre de ces sondes, une alarme sera levée même si l’élément à protéger n’est pas vulnérable à ce genre d’attaques (Script vulnérable non présent sur le serveur). Il sera donc très intéressant d’éliminer une grande partie des faux positifs à l’aide d’une étape de filtrage dans chaques scénarii de corrélation. De plus, lors d’une corrélation d’alarmes d’IDS, nous sommes en présence d’une multitude d’attaques quasi simultanées. Il devient donc très difficile d’identifier les alarmes appartenant à la même attaque. Il est alors nécessaire de regrouper les alarmes suivant des critères5 prédéterminés afin de pouvoir identifier plus facilement les alarmes provenant de la même attaque. Il sera intéressant de mettre en place différents scénarii de corrélation permettant d’améliorer le sta3 Manager des sondes (comportement décrit dans la section 2.2.1 page 14) Faux positif 5 Critères regroupé sous la forme de contextes (défini dans la section 5.4) 4 51 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web tus de dangerosité d’une alarme en l’associant avec différentes alarmes générées par la même tentative d’attaque. La figure 5.1 représente donc le processus de corrélation élaboré. La phase de mise en place de contextes établi concrètement le regroupement des alarmes suivant des critères prédéfinis, comme expliqué ci-dessus. F IG . 5.1 – Principe de corrélation Par la suite, il serait intéressant de pouvoir retracer l’activité totale d’un client sur notre architecture réseau. L’analyste réseau pourrait ainsi, après consultations des alarmes très critiques, suivre l’activité des adresses IP ayant déclenché ces alarmes. 5.2.2 Événements déclencheurs Jusqu’à présent nous avons beaucoup parlé d’événements déclencheurs de scénarii d’investigation, mais à quoi servent-ils et où se situent-ils exactement dans l’architecture réseau ? Un événement déclencheur est le point de départ du diagramme d’état représentant le scénario d’investigation. Sans cet élément de base (groupe d’alarme ou alarme spécifique), il sera impossible de démarrer le processus de corrélation du scénario défini. Cet événement est donc la source d’informations de départ de la corrélation. Lors de l’établissement d’un scénario d’investigation, deux stratégies pour la détermination de l’événement déclencheur sont applicables. En effet, il est possible de définir l’action avant-coureuse d’une attaque comme déclencheur ou alors, la détection de l’attaque elle-même. L’utilisation d’une action avantcoureuse entrera plutôt dans une stratégie de prévention6 , alors qu’une corrélation déclenchée par l’attaque elle même permettra plutôt une analyse de la cause et apporte une façon d’y remédier rapidement. Géographiquement, ces deux types d’événements déclencheurs se situent à l’opposé de l’architecture 6 Recherche des actions effectuées par un client déterminé comme potentiellement dangereux 52 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web réseau. Un événement avant-coureur sera généralement défini comme un scan de ports sur le firewall ou un trop grand nombre de requêtes bloquées par le reverse-proxy, alors que l’attaque elle-même sera détectée par la sonde post-reverse-proxy ou le HIDS du serveur Web. Les événements avant-coureurs se situent donc proches du réseau publique (proche du firewall), alors que les informations d’attaque proviendront des sources les plus proches possibles du serveur Web (élément à protéger). Il serait donc très intéressant de mettre sur pied ces deux principes puisqu’ils ne paraissent pas concurrents mais complémentaires. Malheureusement, dans le cadre de ce travail de diplôme, il ne sera pas possible d’établir plusieurs scénarii de corrélation pour une question de temps à disposition. Pour commencer, nous choisirons une approche permettant de réduire au maximum les faux positifs. Nous utiliserons donc un déclencheur proche du serveur Web afin d’analyser les attaques détectées et d’en déterminer la gravité (faux positifs ou non et niveau de gravité). 5.3 Corrélation temps réel VS corrélation à postériori Une méthode de travail en temps réel permettrait un monitoring permanent et une remontée en temps réel des alarmes critiques vers le gestionnaire de réseau (personne physique). Ceci aurait pour effet d’améliorer le temps de réaction entre une attaque et la mise en place des dispositions pour la prévenir. Malheureusement le modèle 3-tiers employé par Piwi7 auquel nous désirons ajouter notre moteur de corrélation ne permet pas un fonctionnement en temps réel. La figure 5.2 illustre cette architecture. F IG . 5.2 – Architecture 3-tiers du frontend Prelude (Piwi) En effet, il est impossible d’exécuter continuellement du code serveur8 puisque son exécution doit obligatoirement se terminer pour permettre l’envoi des informations demandées par le client Web. De plus, le fonctionnement client-serveur d’un serveur Web implique qu’une requête doit être émise par un client (gestionnaire réseau dans notre cas) pour qu’une réponse puisse être reçue. Il faudrait donc qu’un script client invoque continuellement le programme serveur de corrélation. Cette méthode de travail (utilisée 7 8 Frontend de Prelude permettant l’interrogation de la base de donnée stockant les alarmes Programme situé sur le serveur Web 53 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web par M. Saladino dans le cadre de SIMS 2003) serait envisageable mais poserait quelques problèmes au niveau du temps d’exécution du programme serveur. En effet, celui-ci devrait continuellement reconstruire toutes les associations entre les différentes alarmes (interrogation du SGBD de Prelude, parcours de toutes les alarmes, tri, mise en place dans des structures de données et corrélation) ce qui s’avère extrêmement long pour un grand nombre d’alarmes. Nous serions donc dans l’obligation de stocker les structures de données et les résultats de chaque corrélation dans une nouvelle base de données ou dans une structure de fichiers afin de ne pas relancer, à chaque invocation du programme serveur, une corrélation sur la totalité des alarmes contenues dans le SGBD de Prelude. La solution idéale (illustrée par la figure 5.3), pour une corrélation en temps réel, serait de développer un daemon9 qui s’occuperait de la récupération des alarmes du SGBD de Prelude et qui stockerait les résultats intermédiaires (structure de données, etc..) dans une structure de fichiers ou une base de données intermédiaire afin d’uniquement récupérer les dernières alarmes auprès du SGBD et non pas l’historique complet. Il faudrait ensuite définir un protocole d’interrogation de ce deamon qui permettrait à un programme serveur de l’interroger et d’afficher sous forme de page Web les informations désirées par le gestionnaire de réseau. De cette manière, l’affichage des informations serait totalement indépendant de l’exécution du moteur de corrélation et l’exécution d’un daemon permettrait, en plus, l’envoi spontané d’alarmes critiques au gestionnaire du réseau. F IG . 5.3 – Architecture 3-tiers, fonctionnement en temps réel Pour des contraintes de planning, ne nous pourrons pas, dans le cadre de ce projet de diplôme, développer un moteur de corrélation sous la forme d’un daemon. Nous allons donc ajouter un module au frontend existant (Piwi, figure 5.2). Le moteur de corrélation s’exécutera pour une fenêtre temporelle d’alarmes et ne pourra en aucun cas interagir spontanément avec le gestionnaire de réseau (envoi d’alarmes critiques via e-mail, popup, etc..). Il faudra donc, à chaque lancement du moteur de corrélation, préciser le nombre de jours ou d’heures passées qu’il faudra analyser. Afin d’améliorer la réactivité de notre application (sans pour autant prétendre atteindre celle d’un système temps réel), nous développerons un petit daemon qui contrôlera en permanence (toutes les 10 minutes par défaut) le fonctionnement du ou des serveurs Web. Il permettra ainsi d’avertir l’administrateur réseau 9 Programme s’exécutant en permanence 54 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web (via e-mail) lorsqu’un des serveurs sera hors service. Les détails de cette implémentation sont disponibles dans le chapitre 6 section 6.1. 5.4 Mise en place des contextes Comme illustré sur la figure 5.1, l’étape de création de contextes est indispensable pour une bonne corrélation. Cette étape a comme objectif de regrouper les alarmes par caractéristiques ou critères communs. En effet, il est particulièrement difficile d’opérer une corrélation lorsqu’ aucun tri préalable des alarmes n’a été effectué. Ces contextes permettrons d’envisager des scénarii d’investigations en fonction de leurs caractéristiques. Un contexte regroupant les alertes ayant la même adresse IP source permettra, par exemple, d’identifier un hacker alors qu’un contexte regroupant les alarmes de même type permettra de trouver quelles sont les types d’attaques effectuées et les pages Web attaquées (donc potentiellement vulnérables). Nous remarquons donc que les contextes sont complémentaires et qu’ils permettent une vue plus globale des attaques effectuées. A l’aide de l’architecture réseau et des différentes sondes mises en place dans le chapitre précédent, nous sommes capables de définir les contextes suivants : – Source commune – URL de destination commune – URL de destination commune et source commune – Session TCP commune (post-reverse-proxy ou pre-reverse-proxy) – Source commune et même classe d’alarme – URL de destination commune et même classe d’alarme De par l’architecture réseau définie (dans le chapitre 4), la plupart de ces contextes ne sont pas directement extractables du SGBD de Prelude (par une simple requête SQL). En effet, les champs retirés du SGBD devront subir un traitement (recherche de pattern) préalable pour qu’une décision d’association à un contexte soit possible. De plus, l’utilisation du reverse proxy implique une corrélation entre les alarmes post-reverse-proxy et pre-reverse-proxy afin de retrouver l’adresse IP source de l’attaquant. L’utilisation d’un reverse-proxy a pour effet de couper la connexion TCP et d’éliminer l’accès directe du client Web au serveur. Le NIDS post-reverse-proxy ainsi que les logs du serveur Web indiquerons donc toujours l’adresse IP du reverse-proxy comme source de l’attaque ou de la requête refusée. L’idée est de s’appuyer sur le type de l’alarme générée afin d’effectuer une recherche de type dans une fenêtre temporelle réduite pour les alarmes pre-reverse-proxy et post-reverse-proxy (NIDS uniquement). En effet, les alarmes pre-reverse-proxy contiendront l’adresse réelle du client ayant tenté 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égie soit applicable, il est nécessaire que les deux sondes NIDS possèdent exactement 55 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web les mêmes règles afin que les mêmes alarmes soient identifiables. En effet, si la sonde post-reverseproxy lève une alarme, il est nécessaire que la même alarme ait été précédemment levée 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érentes sondes afin que la fenêtre temporelle de recherche puisse être appliquée. Nous décidons alors d’intégrer un client NTP10 sur les machines de notre DMZ, afin de permettre l’obtention d’une horloge système synchronisée. La section 5.6 vous expliquera en détail l’installation du client NTP sur les systèmes d’exploitations utilisés (Windows Server et Linux Debian). La méthode décrite ci-dessus implique malheureusement que plusieurs mêmes types d’alarmes peuvent correspondre à la recherche effectuée. Dans certains cas, il ne sera donc pas possible d’obtenir une seule adresse IP source puisque, lors d’un grand nombre de mêmes attaques provenant de différentes sources durant un court intervalle de temps, la recherche effectuée fournira plusieurs adresses sources possibles. Une approche basée sur la comparaison des payloads11 des sondes post et pre-reverse-proxy a dû être écartée. En effet, Prelude-IDS n’archive qu’une courte partie de ceux-ci (le début) qui se compose bien souvent de l’entête HTTP qui sera modifiée par le reverse-proxy. Il devient alors impossible de retrouver la même alarme par la comparaison des payloads. 5.4.1 Contextes de sessions TCP communes Ce contexte de regroupement des alarmes en fonction des sessions TCP nous permettra une corrélation subtile du genre attaque-réponse. En effet, les attaques menées par des crackers mènent souvent à une réponse immédiate puisque le protocole HTTP fonctionne comme tel (chaque requête implique une réponse). Il est alors très intéressant de relever les alarmes appartenant à la même paire requête-réponse afin de permettre un diagnostique rapide de la réussite de l’attaque (faux positif ou non). Comme toutes méthodes de travail, celle-ci comporte ses limites puisque, par exemple, dans le cas d’un buffer overflow, nous aurons à faire à deux connexions TCP pour la même attaque. Effectivement, l’alarme levée par la détection d’un shell code contenu dans une attaque de type buffer overflow ainsi que celle levée par la détection des commandes exécutées par le cracker ayant lancé 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ésirable constituera une seconde session. Il sera donc impossible, à l’aide de ce contexte, de reconstituer directement ce genre d’attaque parmi le flot des alarmes levées. Par la topologie mise en place, nous sommes capables de définir deux contextes de session TCP : 1. Les sessions post-reverse-proxy 2. Les sessions pre-reverse-proxy L’obligation de définir 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web qui, comme précisé ci-dessus, a pour effet de ”casser” la connexion client-serveur. Nous sommes donc en présence de deux connexions TCP pour une unique requête. Dans le cadre de ce projet, nous utiliserons uniquement les contextes post-reverse-proxy puisque, comme expliqué dans la section 5.2.2, les alarmes proches du serveur Web nous serviront de déclencheur du scénario d’investigation. Algorithme de définition des sessions TCP post-reverse-proxy Afin de déterminer l’appartenance d’une alarme à une session TCP, nous nous basons en premier lieu sur les adresses IP sources et destinations du paquet incriminé puis sur le numéro du port utilisé par le client. Lors de l’application à notre architecture, nous remarquons que la différenciation des sessions sur les adresses IP n’apporte rien puisque celles-ci sont identiques (seul le reverse-proxy interroge le serveur Web). Ces deux seuls paramètres ne sont de loin pas suffisants au classement des alarmes par sessions TCP. Il est donc impératif d’intégrer un troisième paramètre. Deux solutions ont alors été envisagées : – Utilisation des numéros de séquences TCP. – Utilisation d’un intervalle de temps pour l’utilisation d’un même port source. Numéros de séquences TCP Les numéros de séquences sont codés sur 4 bytes et offrent donc 4,29 milliards de possibilités et permettent la régulation de flux du niveau 412 . A chaque début de connexion TCP ces numéros de séquences sont initialisés par un algorithme aléatoire. L’idée est donc de définir un écart maximum entre les numéros de séquences de deux alarmes de même session et de contrôler pour chaque nouvelle alarme si celle-ci entre dans les critères d’une session existante. Si ce n’est pas le cas, il faudra créer une nouvelle session. Cette solution se base sur le fait que les numéros de séquences sont initialisés de manière totalement aléatoires et qu’aucune connexion TCP simultanée n’utilise la même plage de numéros de séquences. Malheureusement, une notion de temps sera indispensable puisqu’il est fort probable d’avoir deux sessions TCP grandement écartées dans le temps utilisant les mêmes plages de numéros de séquences. Sans cette notion de temps, il serait donc impossible de différencier ces deux sessions TCP temporellement très écartées mais très proches au niveau de leurs numéros de séquences. Intervalle de temps entre deux même ports source Cette méthode de différenciation des sessions TCP s’appuie sur le fait que, sur une même machine cliente, le même port source dynamique ne peut être employé pour deux connexions TCP simultanées. Cette stratégie sera donc uniquement applicable dans le cadre de notre architecture réseau, puisqu’une seule machine (reverse-proxy) interroge le serveur Web. D’une certaine manière, cela signifie que le serveur Web ne voit qu’un seul client (le reverse-proxy), qui parcourera la liste de ses ports source dynamiques afin d’établir les connexions TCP vers le serveur Web. Ceci implique donc qu’il n’y aura jamais deux mêmes ports source utilisés simultanément. En effet, le stack TCP de chaque machine comporte une plage de ports allouable dynamiquement (pour les sockets du niveau applicatif) qui seront utilisés comme port source des connexions TCP. Ceux-ci sont parcouru les uns après les autres selon l’algorithme défini dans les sources du kernel (Linux 2.4.27 dans notre cas) implémentant le stack TCP. La fonction static int tcp v4 get port(struct sock *sk, unsigned short snum) du fichier linux-2.4.27/net/iv4/tcp ipv4.c correspond à cette allocation. 12 Niveau de transport du modèle OSI 57 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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 à l’aide de la commande système sysctl permettant de configurer certains paramètres du noyau durant son exécution. Sa valeur par défaut est : net.ipv4.ip_local_port_range = 32768 61000 Il faudrait donc être capable de connaı̂tre le taux d’utilisation des ports source (intervalle de temps entre l’utilisation du même port source) du stack TCP du reverse-proxy pour une charge maximum du serveur Web. Ceci permettrait de déterminer l’intervalle temporel limite, permettant de différencier l’utilisation d’un même port source pour deux sessions (ou connexions) TCP différentes. Il nous serait ainsi possible, à l’aide de l’heure de l’alarme ainsi que du port source du reverse-proxy, de déterminer l’appartenance d’une alarme à une session TCP existante ou non. Après réflexions, nous en avons déduit que l’utilisation des numéros de séquence pour l’identification des sessions TCP repose sur une approche trop comportementale (dépendante de la masse des données téléchargées). En effet, les alarmes peuvent être levées à n’importe quel moment de la transaction HTTP et être espacées d’un grand nombre de bytes de payload13 pouvant ainsi donner de grands pas d’incrémentation des numéros de séquence entre deux alarmes. Il serait alors possible que les compteurs (numéros de séquence) de deux sessions TCP simultanées soient très proches et que le classement opéré pour le contexte de session TCP communes soit erroné. Nous avons donc opté pour l’approche de tri de session en fonction de l’intervalle de temps entre l’utilisation du même port source. Nous devrons donc être capables d’évaluer le temps de réutilisation d’un même port source afin d’avoir un minimum d’errreurs de classement. Détermination de l’intervalle de temps pour l’utilisation du même port source Le schéma de la figure 5.4 illustre le nombre maximum de requêtes acceptées par différents serveurs Web Microsoft. A l’aide de ces statistiques, il nous est possible de connaı̂tre le nombre de ports par seconde utilisés par le reverse-proxy pour une charge maximale du serveur Web. Nous relevons qu’un petit serveur de production est capable de traiter 755 requêtes par seconde (soit l’utilisation de 755 ports sources par seconde) et 2507 requêtes par seconde pour un gros serveur de production. A l’aide de ce chiffre ainsi que de la plage de ports dynamiques disponibles (de 32768 à 61000) sur le reverse-proxy, nous sommes capables de calculer l’intervalle de temps de réutilisation des ports sources : Ports source dynamiques par défaut : 61000 − 32768 = 28232 Période de réutilisation des ports source du reverse-proxy pour un petit serveur de production : 13 Contenu des segments TCP 58 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 5.4 – Statistiques de charge de IIS mesurée à l’aide de 240 Mb de données (80% de pages statiques et 20% de pages dynamiques, source Microsoft) 28232 755 = 37.4secondes Période de réutilisation des ports source du reverse-proxy pour un gros serveur de production : 28232 2507 = 11.3secondes Maintenant, il serait intéressant d’observer la rapidité d’utilisation de la plage des ports source sur le reverse-proxy. En effet, l’état Time wait du protocole TCP implique un temps d’attente du côté de la station demandant la fermeture du socket (reverse-proxy dans notre cas) avant le restitution de celui-ci. Étant donné que TCP s’appuie la plupart du temps sur IP (protocole de niveau 3 ne garantissant en aucun cas l’arrivée des paquets dans l’ordre d’émission), l’état Time wait permet d’attendre les éventuels paquets égarés sur le réseau 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é), ce qui nous assurerait que deux segments TCP de deux sessions différentes ne peuvent pas être physiquement émis sur le réseau avec le même port source dans cet intervalle de temps. En effet, le serveur Web traitera au maximum 2507 requêtes par seconde mais rien n’empêche d’en envoyer plus. Le supplément serait donc stocké dans un buffer et traité ultérieurement. Ce cas de figure implique que le NIDS placé entre le reverse-proxy et le serveur Web détecterait deux segments TCP ayant le même port source mais appartenant à deux sessions TCP différentes dans un intervalle de temps plus petit que le maximum calculé précédemment à l’aide des caractéristiques du serveur Web. Idéalement, ce test devrait être effectué à l’aide d’un programme en C ou C++ puisque le reverse-proxy 59 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web est lui-même écrit en C (Squid) et C++ (Dansguardian). Il serait ensuite nécessaire de créer un maximum de thread14 effectuant des connexions TCP au serveur Web ainsi qu’une requête HTTP afin qu’un nombre considérable de connexions TCP soient effecutées et que le test reflète le fonctionnement normal du reverse-proxy. Il faudrait ensuite que chacun de ces thread contrôle que le port dynamique source qu’il s’est fait allouer n’a pas déjà été attribué précédemment à un autre thread. Si ce cas de figure survient, il faudrait que le thread concerné mette fin à l’exécution du programme. En relevant le temps d’exécution de ce programme (à l’aide de la commande time de Linux), il nous serait possible de connaı̂tre précisément le temps nécessaire au reverse-proxy pour le parcours de tous ses ports sources allouables. Nous pourrions ainsi le comparer aux résultats trouvés pour une charge maximum (en requête par seconde) calculée précédemment. Nous serions ensuite dans l’obligation de nous accorder à l’élément le plus rapide (reverse-proxy ou serveur Web) afin que notre classement par sessions reste en tout temps sans erreur. En effet, si le reverse-proxy est capable d’envoyer plus de requêtes que le serveur Web peut traiter, cela signifierait que les calculs effectués ci-dessus ne peuvent être pris en considération. Ceci signifierait que le reverse-proxy serait plus rapide que le serveur Web et serait capable d’émettre plusieurs segments TCP de deux connexions différentes avec le même port source dans l’intervalle de temps défini par la rapidité du serveur Web (calculé ci-dessus). Malheureusement, pour une question de temps à disposition, nous ne pourrons pas écrire un tel programme de test. Nous créons donc un petit script perl appelant le programme netcat permettant d’ouvrir des connexion TCP sur un port. A l’aide d’une boucle nous parcourons 2200 ports afin d’avoir une idée du temps d’exécution. Cette méthode de test effectuera malheureusement des connexions de manière séquentielle... Le résultat nous fournit un temps de 3 minutes et 24 secondes pour effectuer séquentiellement une requête HTTP vers le serveur Web pour attendre sa réponse et pour recommencer avec un nouveau port source. Nous remarquons donc que nous sommes bien loin des 11.3 secondes nécessaires au serveur Web pour accepter un nombre de connexions égales au nombre de ports sources dynamiques du reverse-proxy. Suite à cette mesure TRÈS approximative15 , nous opterons pour un temps de 15 secondes pour l’intervalle de temps entre l’utilisation du même port source. 5.5 Scénarii d’investigation 5.5.1 Possibilités et limites Avant de définir précisément une méthode de corrélation (diagramme d’états permettant la description de celle-ci), il est intéressant, en fonction de l’architecture à disposition, de définir les possibilités et les limites de la corrélation : Comme mentionné dans Vocabulaire et avant propos du tutorial d’intrusions réseaux et d’attaques Web rédigé lors du travail de semestre, les attaques Web sont scindées en deux familles bien distinctes : 14 15 ”Tache” vivant dans l’espace mémoire d’un autre processus (le programme principal) Provenant du principe de test séquentiel 60 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 1. Attaques visant le programme serveur offrant le service Web (typiquement Apache ou IIS) 2. Attaques visant les applications hébergées par le serveur Web : – Script serveur ou répertoire connu pour être vulnérable (typiquement les scripts de démo deployés à chaque installation du serveur) – Outre-passage de l’authentification mise en place sur un site Web ou modification de l’intégrité du site (base de donnée ou pages HTML) La première sous-catégorie des attaques visant les applications serveurs se présente comme facilement détectable à l’aide d’un NIDS puisque ces scripts ou répertoires sont répertoriés dans les listes d’alarmes du détecteur d’intrusions réseau. Cette détection lèvera malheureusement un grand nombre de faux positifs puisqu’il sera impossible, pour le NIDS, de savoir précisément si le serveur contient ou non le script vulnérable détecté par le NIDS. La seconde sous-catégorie pose quant à elle certains problèmes de détection puisqu’il est extrêmement difficile de faire la distinction entre un comportement à 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ête s’exécutera sans problème) et des règles génériques sur un NIDS généreraient un grand nombre de faux positifs lors d’uploads vers le serveur Web par exemple. Deux stratégies d’investigation complémentaires permettent de mettre en évidence ces deux sous-catégories : 1. La première sous-catégorie (Script serveur ou répertoire connu pour être vulnérable), pourra facilement être détectée à l’aide d’un NIDS (comme expliqué ci-dessus). L’élimination des faux positifs pourra alors s’effectuer à l’aide de la récupération du status d’exécution des pages désirées par les clients ou crackers. Cette méthodologie a été implémentée dans le cadre de ce projet de diplôme. Celle-ci est décrite dans la section suivante (section 5.5.2). 2. La seconde sous-catégorie ( Outre-passage de l’authentification...) impliquera une analyse plus comportementale. En effet l’utilisation des logs du reverse-proxy comme source d’informations peut s’avérer utile pour ce genre d’attaques. Comme les NIDS ne peuvent être d’une grande utilités pour ces cas de figure, il sera intéressant de détecter le dépassement d’un seuil de requêtes bloquées sur le reverse-proxy afin d’effectuer une investigation approfondie pour l’adresse IP source désirée. Cette stratégie se base donc sur le fait qu’une attaque visant l’outre-passage de l’authentification ou des tentatives de modifcation de la base de données via les champs de saisies offerts par la page Web implique souvent un grand nombre de tentatives avant une réussite. Cette méthode d’investigation ne pourra malheureusement pas être implémentée dans le cadre ce projet de diplôme puisque le temps à disposition ne le permettra pas. Néanmoins, la section 5.5.3 Traçabilité des comportements à risque ébauchera une solution envisageable. La famille des attaques visant l’application serveur elle-même pourra être détectée à l’aide d’une sonde NIDS (détection de buffer overflow par exemple). Une investigation plus étendue pourra ensuite être effectuée sur les alarmes levées par la même source (adresse IP identique) afin de rechercher un comportement indiquant la réussite d’un buffer overflow (exécution de commandes, par exemple). 61 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 5.5.2 Diminution des faux positifs par analyse des requêtes - réponses et du status du serveur Web Le principe est donc de fournir le meilleur status de réussite ou d’échec de l’attaque possible. Pour ce faire nous allons nous appuyer sur le NIDS post-reverse-proxy et le HIDS récupérant les logs de refus du serveur Web (erreurs 4xx). A l’aide du contexte de session TCP communes précédemment décrit, il nous sera possible de distinguer la réponse à une requête. Nous serons donc capable d’observer si la requête (définie comme dangeureuse par une alarme du NIDS post-reverse-proxy) a entraı̂né une réponse dangereuse (levée par la même sonde NIDS). De plus, il nous sera possible d’affiner la dangerosité de l’alarme et consultant les logs du serveur Web. En effet, si l’URL demandée par la requête ayant levé une alarme sur le NIDS post-reverse-proxy n’est pas présente dans la liste des alarmes informant des refus du serveur Web (erreur 4xx), l’alarme sera considérée comme encore plus critique puisque cela signifiera que le serveur Web contient la page cible de l’attaque et qu’il a bien retourné une information au client. Il nous a donc été possible de dresser un scénario générique16 illustré par la figure 5.5. Description du diagramme d’état de la figure 5.5 Comme mentionné dans la section 5.2.2, le principe de corrélation mis en place dans le cadre de ce projet de diplôme s’appuie sur les alarmes proches du serveur Web. Le déclencheur sera les alarmes regroupées dans le contexte de session TCP communes post-reverse-proxy. Pour commencer, celles-ci seront analysées une à une afin de définir si des alarmes IN17 et/ou des alarmes OUT18 sont présentes dans la session. Plusieurs cas sont dès lors répertoriables : 1. Uniquement des alarmes OUT sont présentes dans la session TCP (point A du diagramme d’états) Aucune investigation plus approfondie sur le serveur Web ne pourra être effectuée sur ce type de session TCP puisqu’aucune URL ne sera présente dans celles-ci. En effet, les alarmes n’indiquent aucune activité entrante suspecte alors qu’une activité sortante suspecte a été relevée. Le classement de ces sessions peut dès lors être effectué et être considéré comme très dangereux. Celles-ci pourraient correspondre à une attaque pas encore répertoriée (pattern non existant dans le NIDS) ou nécessitant plusieurs connexions TCP, alors que la réponse à cette attaque est typiquement connue pour être dangereuse. Il s’agit d’une ”opportunité” de découvrir de nouvelles attaques sur le serveur Web à protéger. Il sera donc impératif que le gestionnaire de réseau19 prenne le temps d’analyser plus profondément ce type d’alarmes afin d’en définir sa dangerosité réelle. 2. Uniquement des alarmes IN sont présentes dans la session TCP (point 2 du diagramme d’états) Une investigation plus approfondie est possible puisque la récupération des URLs de ces alarmes est possible. 16 Générique : Car il ne s’appuie pas sur la connaissance d’un scénario d’attaque mais plutot sur une méthodologie de contrôle des alarmes 17 En direction du serveur Web 18 En direction du client Web 19 Personne physique 62 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 3. Présence d’alarmes IN et OUT (point 3 du diagramme d’états) Une investigation plus approfondie est aussi possible puisque la récupération des URLs des alarmes IN présentes est envisageable. L’investigation faisant suite aux points 2 et 3 du diagramme d’états sera exactement pareille, à la différence près, que la dangerosité de la session définie à la suite de cette investigation plus poussée sera ajustée en fonction de la présence d’alarmes OUT (différenciant le point 2 du point 3). En effet, la présence d’alarmes OUT dans la session TCP implique souvent la réussite de l’attaque, ce qui amènera à classifier la session comme plus dangereuse. L’analyse d’investigation effectuée pour les points 2 et 3 se différenciera donc par une dangerosité plus élevée pour les sessions composées d’alarmes IN et OUT (point 3). Celle-ci se présente sous la forme d’un contrôle d’exécution de la requête sur le serveur Web. En effet, le protocole HTTP définit pour chaque requête un status de retour (retourné au client). Celui-ci est donc enregistré dans les fichiers de logs du serveur Web avec l’URL demandée. A l’aide de la sonde HIDS disposée sur celui-ci, il nous est possible de récupérer toutes les lignes de logs à des URLs non existantes (status code 404) ou non atteintes par le client pour différentes 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’établissement des règles de rapatriement des logs (génération d’alarmes IDMEF) vous êtes libres de consulter la section 4.5 page 43 de ce rapport. L’algorithme d’investigation fonctionne de la manière suivante : Chaque alarme IN est contrôlée afin de définir si la requête la composant contient bien une URL. Si c’est le cas, une recherche de la même URL est effectuée sur les alarmes du serveur Web afin de définir si la requête a été exécutée ou non. Ceci correspond à la présence de l’URL dans les alarmes pour une requête non exécutée et à son absence pour une requête exécutée. En fonction de l’exécution ou non de la requête du client, une décision de classement de la session TCP est prise, comme l’illustre le diagramme d’état de la figure 5.5. La classification des sessions est ensuite définie comme suit : – Alarmes OUT présentes : – Exécution de la requête (point E) : La session est considérée comme extrêmement critique puisque la requête a levé une alarme (alarme IN) et que sa réponse aussi (alarme OUT). Cet état est représenté par Maximum Risk dans l’application de corrélation. – Non exécution de la requête (point D) : La session est considérée comme très critique puisqu’une alarme OUT est présente. En effet, le serveur Web pourrait très bien avoir refusé l’accès à l’URL demandée et avoir tout de même été compromis lors du traitement de la requête (buffer overflow par exemple). Un contrôle supplémentaire (effectué par le gestionnaire de réseau) est donc nécessaire afin d’affiner au maximum les résultats critiques fournis par cette analyse. Le cas de non exécution de la requête nécessite une attention particulière afin de déterminer s’il s’agit d’un faux positif ou non. 63 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Le contenu d’une requête (alarme IN) désignée comme dangereuse par le NIDS pourrait, en effet, être répétée dans la page d’erreur du serveur Web (alarme OUT), ce qui aménerait le classement d’une session non dangereuse dans cette catégorie. – Alarmes OUT absentes : – Exécution de la requête (point C) : La session est considérée comme très critique puisque la requête ayant levé une alarme (alarme IN) a été exécutée par le serveur Web. Il se peut que la réponse à cette requête ne paraisse pas dangereuse ou qu’aucun pattern ne la répertorie, ce qui expliquerait l’absence d’alarmes OUT. La possibilité de faux positif ne doit pas être écartée puisqu’il pourrait s’agir d’une requête considérée dangereuse pour une ancienne version du serveur Web en question et non dangereuse pour la version patchée utilisée. – Non exécution de la requête (point B) : La session est considérée comme peu critique (faux positif) puisque le serveur Web ne contient pas ou refuse de fournir l’URL demandée par la requête considérée comme dangereuse. La possibilité d’attaque réelle ne doit cependant pas être écartée puisqu’il pourrait s’agir d’attaques du genre buffer overflow ne nécessitant pas le retour de l’URL demandée mais uniquement une partie du traitement de la requête par le serveur Web. Nous remarquons qu’un contrôle supplémentaire (effectué par le gestionnaire) reste toujours judicieux afin de vérifier les conclusions fournies par l’algorithme d’investigation. 5.5.3 Traçabilité des comportements à risque Cette méthode d’analyse permettra de repérer un comportement à risque sur l’une ou l’autre des sondes et de mener une investigation approfondie sur les différentes alarmes afin de repérer un comportement dangereux. Cette stratégie s’applique donc lors d’une attaque réfléchie et poussée (tentatives successives) et non pas lors de l’essai d’un script trouvé au hasard sur le Web. Le signe avant coureur qui nous permettrait de déclencher l’investigation approfondie nous parviendrait de l’HIDS du reverse-proxy (trop grand nombre de requêtes d’une seule source bloquée par DansguardianSims), du serveur Web (grand nombre de status de refus ou d’erreurs levées par la même source) ou encore du firewall (scan de ports). Il sera nécessaire de définir un seuil sur les différents déclencheurs afin de pouvoir décider si une investigation aura lieu. Cette stratégie serait typiquement applicable pour la détection d’outre-passage de l’authentification abordée dans la section 5.5.1 5.6 Mise en place de NTP (Network Time Protocol) Ce protocole permet la synchronisation des horloges systèmes des machines. Son fonctionnement s’appuie sur une hiérarchie d’horloges synchronisées. Il est donc indispensable de lui indiquer un serveur sur lequel il pourra s’appuyer (ntp01.eivd.ch dans notre cas). Ensuite, chaque station synchronisée à l’aide de NTP pourrait jouer le rôle de serveur pour d’autres stations en demande de synchronisation. NTP nous permettra d’obtenir un timestamp synchronisé de toutes les alertes présentes dans la base de 64 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web données de Prelude Manager. Il est alors indispensable d’installer un applicatif s’occupant de la gestion de la synchronisation de l’heure sur toutes les machines générant des alertes. 5.6.1 Installation Linux Pour ce faire, nous utiliserons la commande apt-get install afin de récupérer les applications nécessaires : – ntp, permettant de réguler en permanance l’horloge système (daemon). – ntpdate, permettant de forcer la mise à jour de l’heure du système (exécuté au démarrage). Installation du daemon du contrôle de l’heure via NTP : :/# apt-get install ntp Installation de l’utilitaire de mise à jour de l’heure : :/# apt-get install ntpdate Son démarrage se fera ensuite automatiquement via un script de lancement situé dans /etc/init.d/ Configuration Celle-ci s’opère via le fichier /etc/ntp.conf. Il suffira donc de préciser l’adresse du serveur maı̂tre (fournissant la synchronisation) en fin de fichier, comme illustré 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’état du protocole NTP et d’observer si la synchronisation de l’horloge a eu lieu. Si c’est le cas, une étoile apparaı̂t sur l’extrême gauche de l’affichage (comme illustré 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émentation de NTP est nativement disponible sur Windows 2000. Deux outils sont utilisables (Net Time et W32tm) mais seul Net Time permet une configuration sauvegardable, puisque W32tm permet un diagnostique du service et une configuration non permanente. 65 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Configuration La configuration du serveur NTP s’opère de la façon suivante à l’aide d’un shell dos : net time /setsntp:ntp01.eivd.ch Il est ensuite indispensable de démarrer le service à l’aide de l’interface graphique de la manière suivante : 1. Dans le menu démarrer, cliquez sur Settings puis Control Panel 2. Double-cliquez sur Administrative Tools puis sur Services 3. Sélectionnez Windows Time dans la liste de service 4. Dans le menu d’action cliquez sur Start pour démarrer le service Pour de plus amples informations sur ces deux outils de configuration et sur l’implémentation de NTP pour windows 2000, consultez : http ://www.microsoft.com/windows2000/docs/wintimeserv.doc 66 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 5.5 – Méthode de corrélation requête-réponse (session TCP) 67 Chapitre 6 Implémentation, installation et tests Ce chapitre présente la partie logiciel de ce projet. Il définit les principes d’implémentation utilisés ainsi que la configuration et l’installation du watchdog et du moteur de corrélation. De plus, des tests sur le moteur de corrélation permettront d’observer les capacités et les limites du scénario d’investigation mis en oeuvre. 6.1 Watchdog de contrôle d’état du/des serveur(s) Web Comme expliqué dans la section 5.3 du chapitre 5, ce watchdog permettra le contrôle du bon fonctionnement de serveurs Web (plusieurs à la fois) à intervalle de temps régulier. Il sera capable d’avertir l’administrateur réseau (via e-mail) en cas de disfonctionnements et de lui fournir un petit diagnostique. Le watchdog commencera, à l’aide d’un ping, par déterminer si la machine officiant en tant que serveur Web est toujours en fonction. Si ce premier test est concluant, il contrôlera cette fois-ci le service HTTP. En effet, suite à une attaque, le service Web peut être inopérant alors que le stack IP du système d’exploitation du serveur fonctionne toujours (réponse aux pings). Deux types de mails (émis à l’administrateur réseau) sont envisageables : 1. Alerte indiquant que le serveur est hors service (ne répond pas aux pings) 2. Alerte indiquant que le service Web est inopérant Un fichier de log contenant l’historique des tests effectués et les erreurs d’exécutions du watchdog (erreurs lors de l’envoi du mail) est conservé dans le répertoire indiqué dans le fichier de configuration. 6.1.1 Détermination de l’état du service Web Afin de définir si le serveur Web est opérationnel, il est indispensable, dans le fichier de configuration du watchdog, de fournir non pas l’adresse du serveur mais l’URL complète d’une page Web existante et accessible. Il est évidemment préférable, si nous avons à faire à un site Web non statique, de fournir 68 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web l’URL d’une page dynamique afin de contrôler en plus, le bon fonctionnement de l’interpréteur1 ou de la machine virtuelle2 du serveur Web . Le watchdog enverra une requête HTTP à 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éponse du serveur sera récupéré est ajouté à l’e-mail d’alarme envoyé à l’administrateur réseau. Un diagnostique succint sera ainsi directement possible après lecture du mail. 6.1.2 Installation Étant écrit en Perl, son installation requiert les modules suivants : LWP : :UserAgent Pour les requêtes HTTP. HTTP : :Response Pour le contrôle de l’état des réponses HTTP. Net : :SMTP auth Pour l’authentification au serveur de mail. Net : :Ping Pour l’exécution des pings. Net : :DNS Pour les requêtes DNS avant l’exécution d’un ping. Leurs installations sous Linux peut être facilement effectuée à l’aide d’un outil du CPAN3 comparable à 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 à l’aide de la commande install ¡nomModule¿ comme illustré 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éléchargement et la compilation du module se fera automatiquement après le lancement de la commande install. Nous avons ensuite placé le watchdog sur le Manager Prelude (/usr/local/watchdog/) et configuré son lancement en tâche de fond lors du démarrage de celui-ci (dans le script /etc/init.d/local) : echo "Demarrage du watchdog" /usr/local/watchDog/watchdog.pl & 6.1.3 Configuration Celle-ci s’opère à l’aide du fichier Perl confWatchDog.pl. Les première directives permettent la configuration du serveur mail, le chemin du fichier de log ainsi que l’intervalle de temps entre deux contrôles. Quant à la dernière directive, elle permet d’indiquer les sites Web à contrôler (comme illustré ci-dessous) : 1 Software interprétant les scripts serveurs (PHP, Perl, etc...) Pour des sites Web écrits en Java (Servlets ou JSP) 3 Comprehensive Perl Archive Network 2 69 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web $conf{’webSites’}=["192.168.1.4/securitystore/index.php", "192.168.1.3", "www.monSite.ch/index.jsp"]; 6.2 Algorithme de corrélation et site Web (frontend) Comme mentionné dans le chapitre 5, il ne nous a pas été possible, dans le cadre de se travail de diplôme, d’implémenter plusieurs scénarii de corrélation. Cette section définira uniquement l’implémentation du scénario de corrélation basé sur les sessions TCP post-reverse-proxy communes (défini dans la section 5.5.2 du chapitre 5. 6.2.1 Choix du langage et du frontend hôte Comme mentionné dans la section 5.3 du chapitre 5, l’implémentation d’une application temps réelle n’a pas été possible dans le cadre de ce travail de diplôme. Nous avons donc décidé d’ajouter un module à l’interface Web 4 existante avec Prelude. Nous avons préféré ajouter notre module de corrélation à Piwi plutôt qu’à l’interface PHP développée par Patrick Saladino (durant son travail de diplôme 2003) puisque nous avions comme première idée d’effectuer la corrélation à proprement parlé à l’aide de SEC5 , logiciel également écrit en Perl. Le langage de programmation commun ne fut pas le seul point déterminant de l’intégration a Piwi. En effet, après avoir exploré les différents Frontend, il s’est avéré que Piwi offrait une grande souplesse dans le tri des alarmes que l’interface développée par M. Saladino ne permettait pas. Piwi offre la possibilité de créer ses propres filtres et permettra de différencier facilement les alarmes en fonction leurs sonde source. Il sera ainsi aisé d’observer les alarmes en fonction de leur emplacement sur le réseau. Il a alors été nécessaire d’investir un peu de temps dans l’apprentissage du langage Perl puisque mes connaissances en la matière étaient inexistantes. 6.2.2 Étude de l’interfaçage avec SEC Ce logiciel de corrélation étudié dans le chapitre 7, permet de définir un scénario de corrélation d’événements extraits de fichiers (typiquement de fichiers de logs). Dans un premier temps, l’idée est de créer un programme effectuant les recherches dans la base de données, le rassemblement des sessions TCP commune et le stockage de celles-ci sous forme d’un fichier texte. SEC récupérera ce fichier afin d’appliquer la corrélation définie dans son fichier de configuration. le résultat retourné sera ensuite stocké dans un second fichier texte que l’application récupérera pour un affichage sous forme de page Web dynamique. Après une phase de tests, cette méthode de travail (par échange de fichiers) pourra être améliorée puisque comme mentionné plus haut, le langage de programmation est identique (Perl). Il sera intéressant de directement passer une structure de donnée (stockée en RAM6 ) à SEC afin d’éviter une lecture de fichiers 4 Frontend écrit en Perl et nommé Piwi, http ://www.leroutier.net/Projects/PreludeIDS/ Simple Event Correlator, Logiciel open source permettant la définition de scénarii de corrélation d’événements http ://sixshooter.v6.thrupoint.net/SEC-examples/article.html 6 Mémoire vive de l’ordinateur (Random Access Memory) 5 70 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web coûteuse en temps processeur. Après une étude plus approfondie de SEC (relatée dans le chapitre 7), il s’est avéré quasiment impossible de l’intégrer dans l’application envisagée (comme expliqué ci-dessus). En effet, nous avonc remarqué que cette application était vraiment vouée à une utilisation temps réel puisque presque la totalité des règles à disposition utilisent une notion de temps. Étant donné que notre application se voue à une analyse (corrélation) à postériori, il ne sera pas possible d’intégrer SEC dans le cadre ce projet. Le chapitre 7 traitant de SEC offrira néanmoins des exemples d’utilisation pratique, afin d’offrir un petit aperçu de la capcité de cet outil de corrélation. 6.2.3 Architecture logiciel Le paradigme de programmation utilisé est procédural puisque l’apprentissage de la programmation orientée objets en Perl aurait été trop couteuse en temps. Il est évident que si l’application venait à être améliorée par l’ajout de nouveaux scénarii de corrélation, il serait avantageux de reprendre celle-ci afin de la faire migrer vers un paradigme orienté objets. En effet, un tel paradigme offre une réutilisation facilitée des objets déjà défini. Il serait ainsi beaucoup plus aisé, pour les personnes désireuses d’ajouter une nouvelle fonctionnalité au moteur de corrélation, de le faire en implémentant simplement un nouvel objet. L’application de corrélation peut tout de même être découpée en plusieurs fichiers correspondant à différents niveaux. La figure 6.1 illustre l’architecture élaborée. F IG . 6.1 – Structure du logiciel de corrélation développé 71 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – Communication avec la base de donnée, dataBasee.pl – Recherche des sessions TCP, contextes.pl – Correlation par l’algorithme définit dans la section 5.5 du chapitre 5, correlation.pl – Interface graphique (CGI), showCorrelation.pl Le fichier dataBase.pl offre les fonctions d’interrogatinde la base de données. Celles-ci retourneront des structures de données décrites dans les entêtes du code source (tables de hash ou tableaux). Il est important de noter que les procédures setConf() et setTime() font offices de ”constructeurs”. En effet, il serait abérant de récupérer toutes les alarmes de la base de donnée pour effectuer la corrélation des alarmes de la journée. La procédure setTime(), permet de figer l’heure afin que les différentes fonctions d’accès à la base de donnée utilisent une heure commune. Le hash $conf’fenetreCorrelation’ contenu dans le fichier de configuration permettra ensuite de définir la fenêtre de corrélation à appliquer. Certaines fonction (définies dans la deuxième partie du code) ne nécessitent aucune initalisation temporelle (setTime()), puisque elles effectuent une recherche spécifique dans la base de données. Le fichier contextes.pl implémente l’algorithme de recherche des sessions TCP post-reverse-proxy communes. Il nécessite les fonctions d’accès à la base de donnée afin que l’algorithme définit dans la section 5.4.1 du chapitre 5 soit applicable. Son utilisation est similaire à dataBase.pl puisqu’il sera nécessaire de l’initialiser à l’aide des procédure init() et setConf(). Celles-ci on pour effet d’effectuer toutes les requête nécessaires à la base de données afin de pouvoir fournir rapidement les structures de données nécessaire à l’algoritme de reconstitution des session TCP. De plus, les structures de données nécessaire à l’algorithme de corrélation et à l’affichage des informations d’une sessions TCP seront disponibles via les fonctions définies dans ce fichier. De cette manière un seul accès à la base de donnée (effectué via l’appel à init()) sera nécessaire. Le fichier correlation.pl implémente le diagramme d’état d’investigation présenté dans la section 5.5 du chapitre 5. Il fournit une fonction retournant un tableau indiquant la dangerosité de chaque sesison TCP. Son pseudo code est présenté 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écution sur le serveur Web */ Pour chaque alarmes IN de la session, boucler{ Si l’alarme courant contient une URL{ Si l’URL de l’alarme courante a été refusée par le serveur{ /* afin de garder la dangerosité la plus élevée de la session */ 72 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Si la dangerosité de la session courante n’est pas plus élevée{ la dangerosité de la session vaut: peu critique } } sinon{ la dangerosité de la session vaut: très critique } } sinon{ la dangerosité de la session vaut: indéterminé (pas d’URL disponnibles) } } /* ajustement de la dangerosité en fonction du sens des alarmes */ Si il y a que des alarmes IN{ Si la dangerosité de la session a été déterminée comme très critique{ dangerosité de la session = C } sinon{ dangerosité de la session = B } } /* il y a alors des alarmes IN et OUT */ sinon{ Si la dangerosité de la session a été déterminée comme peu critique{ dangerosité de la session = D } sinon{ dangerosité de la session = E } } } Le fichier showCorrelation.pl implémente l’interface graphique permettant l’interaction du gestionnaire de réseau avec le moteur de corrélation. Celui-ci nécessite l’inclusion du module CGI permettant l’interfaçage avec le serveur Web. Pour de plus amples informations sur l’implémentations et les structures de données utilisées, le lecteur averti pourra se plonger dans le code source disponnibles sur le CD du projet. 6.2.4 Installation Le moteur de corrélation et son interface graphique sont prévu pour s’exécuter du côté serveur. Il est donc nécessaire de disposer d’un serveur Web supportant Perl. L’installation du moteur de corrélation doit impérativement être effectuée dans le répertoire de l’interface Web de Piwi puisqu’il nécessite un fichier de configuration communs et certaines librairies d’accès au SGBD. L’installation de Piwi est détaillée à l’adresse suivante : http ://www.leroutier.net/Projects/PreludeIDS/Demo/Docs/INSTALL.txt 73 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Pour l’installation du moteur de corrélation, il vous suffira d’ajouter le répertoire correlation, le fichier showCorrelation.pl ainsi que la feuille de style commonCorrelation.css à la racine de Piwi. Le fichier racinePiwi/Templates/Links devra ensuite être remplacé par celui fournit avec le moteur de corrélation afin qu’un lien vers celui-ci soit disponnible dans l’interface existante de Piwi. Étant donné que le fichier de configuration du moteur de corrélation est défini dans celui de Piwi racinePiwi/Functions/config.pl, il est indispensable de le remplacer par celui fournit avec les sources du moteur de corrélation. 6.2.5 Configuration La première partie du fichier de configuration contenue dans racinePiwi/Functions/config.pl permet le réglage de Piwi, alors que la seconde permet la configuration du moteur de corrélation développé dans le cadre de ce travail de diplôme. Comme Perl est un langage interprété7 , la configuration du moteur de corrélation se présente sous la forme d’une table de hash. Les modifications apportée à ce fichier seront ainsi directement prise en compte lors de l’utilisation du programme. La première partie de la configuration du moteur de corrélation nécessite les identificateurs des différentes sondes. Ceux-ci sont disponnibles dans le fichier /etc/prelude-sensors/sensors.ident de chaques sondes. Les directives suivantes sont expliquées ci-dessous : $conf’TcpSessionDuration’ Permet la configuration de la durée d’une session TCP post-reverse-proxy. Celle-ci sera utilisée pour la recherche des sessions communes et la création du contexte de session TCP communes. $conf’portServeur’ Permet de préciser le port d’écoute du serveur Web à protéger. $conf’ipServeur’ Permet de préciser l’adresse IP du serveur Web. $conf’ipProxy’ Permet de préciser l’adresse IP du reverse-proxy. $conf’fenetreCorrelation’ Permet de préciser la fenêtre de corrélation à utiliser. Il s’agira du nombre de secondes à analyser depuis le lancement du moteur de corrélation. $conf’timeIntervalHidsNids’ Permet de préciser le temps de recherche de l’URL des alarmes du NIDS post-reverse-proxy sur les logs du serveur Web. $conf’timeIntervalFindingIP’ Permet de préciser le temps de recherche du même type d’alarme entre le NIDS post-reverse-proxy et pre-reverse-proxy afin de déterminer l’adresse IP réelle de l’attaquant. Le fichier de configuration utilisé dans le cadre de ce projet est disponnible dans les Annexes, section A.5. 7 Nécessitant aucune compilation 74 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 6.2.6 Utilisation Aucun manuel d’utilisation du moteur de corrélation n’a été rédigé, puisque son interface Web se présente sous forme didactique. En effet le diagramme d’états du scénario d’investigation mis en place est disponnible via cette interface. L’utilisateur désireux d’obtenir des informations détaillées sur les niveaux de dangerosité utilisés, aura la possibilité 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érents sondes présentes. F IG . 6.2 – Interface Web d’accueil du management de l’architecture Web (permettant de démarrer la corrélation) La figure 6.3 illustre l’affichage des résultats d’une corrélation. 75 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 6.3 – Interface Web affichant les résultats de la corrélation 6.3 Tests du moteur de corrélation Cette partie relate les différents essais effectués sur le moteur de corrélation. En effet, nous avons procédé en deux phases : 1. Tests d’attaques spécifiques 2. Tests à l’aide de scans Nessus8 Le test d’attaque spécifique nous a permis d’observer le comportement du moteur de corrélation aux attaques prévues et d’en corriger son fonctionnement si besoin était. Le test à l’aide d’un scan Nessus nous a permis de déterminer l’efficacité du moteur de corrélation à l’élimination des faux positifs. La figure 6.5 illustre bien l’élimination d’un grand nombre de faux positifs puisque toutes les sessions représentées par une dangerosité de couleur verte représente un faux positif. Nous avons alors analysé (manuellement) la majorité de ces alarmes afin de contrôler l’efficacité de l’applicatif développé. La figure 6.6 illustre quant à elle la détection d’une session TCP post-reverse-proxy très dangereuse (exécution de commandes sur le serveur Web via cmd.exe). Nous remarquons bien la détection de la totalité de la session puisqu’il est possible d’observer via différentes alarmes : L’accès au fichier cmd.exe 8 Scanner de vulnérabilités open source 76 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 6.4 – Interface Web permettant de visualiser l’algorithme de corrélation utilisé ainsi que le retour de l’exécution de la commande (listage d’un répertoire). D’autres tests ont ensuite été effectués afin de vérifier le bon fonctionnment du moteur de corrélation. Ceux-ci ne seront pas illustrés dans cette section puisqu’ils seront présentés lors de la défense du projet le 19 janvier 2005, à l’EIVD (B01b à 10h). 77 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 6.5 – Résultat de la corrélation permettant d’éliminer un grand nombre de faux positifs F IG . 6.6 – Résultat de la corrélation retrouvant une session TCP dangereuse 78 Chapitre 7 Descriptif et utilisation de SEC 7.1 Description SEC est un logiciel Open Source récupérant le flux d’entrée d’un fichier texte ou d’un pipe1 afin d’y appliquer une détection de pattern selon des règles décrites dans un fichier de configuration. SEC dispose de différents directives de configuration permettant une utilisation variée (analyse de logs, machine d’états, logique, etc...). Ces directives de configuration fonctionnent principalement à l’aide de fenêtres temporelle. Il sera facile de le configurer pour un traitement en temps réel. En effet, nous avons tenté dans le cadre de ce projet, de le configurer pour une corrélation de logs à postériori. Ceci c’est très rapidement averré impossible puisque la gestion de conditions sans aucune notion de temps n’est vraiment pas aisée. Nous allons maintenant étudier quelques petits exemples permettant d’illustrer le fonctionnement temps réel d’une corrélation à 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ée. Voici le descriptif de cette configuration : 1 Récupération d’un flux de sortie d’une commande 79 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web type Permet de préciser le genre de règles à utiliser. Nous somme ici en présence d’une simple règle de recherche de pattern. ptype Permet de préciser le pattern type utilisé pour la recherche d’une suite de caractères (dans notre cas à l’aide d’expressions régulières). pattern Indique le pattern à rechercher (à l’aide du ptype mentionné précédemment). Dans ce cas, une expression régulière. desc Permet la description de l’événement. $0 représente le pattern total détecté à l’aide de l’expression régulière de la directive pattern. action Indique l’action à entreprendre lorsque la règle s’applique. Dans ce cas, la description sera envoyée dans un fichier de log (si un fichier est mentionné au lancement) sinon la sortie standard (le shell). Son exécution s’opère ensuite de cette manière : % perl sec.pl -conf=essai.conf -input=- La directive input=- indique que le flux d’entrée n’est rien d’autre que le shell courant (entrée standard). Après son lancement, nous remarquons que dès que nous entrons le mot foo suivi d’un espace (dans le shell), la totalité de la ligne entrée est répétée sur la sortie standard. Le principe de lecture du fichier de configuration par SEC est similaire à celui d’un firewall puisqu’il prendra les directives les unes après les autres en regardant si celles-ci s’appliquent au pattern courant. Il sera ainsi possible de chaı̂ner plusieurs groupe de règles dans le même fichier. L’exemple ci-dessous illustre un fonctionnement un peu plus complexe : # essai2.conf # source: http://sixshooter.v6.thrupoint.net/SEC-examples/article.html # type=Single ptype=RegExp pattern=foo desc=$0 action=event 5 baz is now matched. ; \ write - foo matched baz event in 5 seconds... # simple règle type=Single ptype=RegExp pattern=bar desc=$0 action=write - $0 is matched. # Cette règle récupère le pattern écrit (baz) par la règle 1 type=Single ptype=RegExp 80 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web pattern=baz desc=$0 action=write - %s matched Trois règles sont maintenant définies. La première utilise l’action event permettant la création d’événements internes à SEC (après un temps déterminé ici 5 secondes), récupérables par les autres règles. Nous remarquons qu’il est possible de cumuler différents événements à l’aide d’un point virgule. L’action write - aura pour effet d’écrire le texte qui suivra sur la sortie standard (le shell dans ce cas). La seconde règle fonctionne de la même manière que l’exemple précédent. C’est donc pour cette raison que nous n’allons pas plus la détailer. La troisième règle détectera l’événement contenant le pattern baz (généré par la première règle) qui sera ensuite écrit sur la sortie standard (%s indiquant la récupération de la description). Après ces petits exemples d’utilisation il est intéressant d’observer les différents types de règles disponibles avec SEC : Single Lorsque l’événement défini par pattern est détecté, une action est exécutée. SingleWithScript Lorsque l’événement défini par pattern est détecté et qu’un script externe retourne une certaine valeur de retour, une action est exécutée. SingleWithSuppress Lorsque l’événement défini par pattern est détecté, une action est exécutée et les prochains événements sont ignorés pendant t secondes. Pair Lorsque l’événement défini par pattern est détecté, une action est immédiatement exécutée. Pendant les t prochaines secondes les événement entrants seront ignorés, jusqu’à l’arrivée d’un second événement qui exécutera une seconde action. PairWithWindow Lorsque l’événement défini par pattern est détecté un time out est déclenché dans l’attente d’un second événement. Si ce second événement arrive (dans la fenêtre définie par le time out) une action est exécutée. Si le second événement n’arrive pas dans la fenêtre mentionnée, une seconde action sera exécutée. SingleWithThreshold Compte le nombre d’événements défini par la directive pattern durant t secondes. Lorsqu’un nombre suffisant d’événements est détecté, une action est effectuée et le compteur d’événements est remis à zéro. SingleWith2Thresholds Compte le nombre d’événements défini par la directive pattern durant t secondes. Lorsqu’un nombre suffisant d’événements est détecté, une action est effectuée. Le compteur d’événements n’est pas remis à zéro et lorsqu’un nouveau seuil est atteint en moins de t’ secondes une seconde action est exécutée. Suppress Supprime des événement entrant. Calendar Exécute une action à une date spécifiée. A l’aide des deux exemples ci-dessus, ainsi que de la description des différents types de règles disponibles, ll nous est déjà possibles d’entrevoir les possiblités offertes par SEC. 81 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Imaginez maintenant que les logs d’accès à un serveur Web soient rapatriés (via syslog de Linux) dans le même fichiers que les logs d’une sonde Snort. Il serait alors possible d’établir le même genre de scénario d’investigation mis en place dans le cadre de ce projet (contrôle du status d’exécution de chaque requête critique sur le serveur Web) en fonctionnement temps réel. 7.3 Conclusion Grâce à l’étude de l’association de SEC avec notre moteur de corrélation, il nous a été possible d’entrevoir les capacités d’analyse temps réel qu’offre cet outil. Son utilisation pourrait tout de même être envisagée dans l’architecture proposée afin de permettre une analyse temps réel d’événement très critiques offrant un système d’alerte rapide en cas de gros problèmes. 82 Chapitre 8 Panorama de l’offre actuelle Ce chapitre présente quelques solutions existantes d’IDS offrant une corrélation des informations récoltées. Il sera ainsi possible d’observer et comparer quelques solutions existantes sur le marché. 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ême phylosophie (open source) afin d’y intégrer une infrastructure de monitoring. Cette application a comme objectif principal, d’améliorer la visualisation de la masse d’alarmes (émises par différentes sondes). En effet le problème principal du management d’alarmes provient : 1. Du volume de donnée émises par les différentes sondes 2. De la relation inexistante entre les différentes alarmes 8.1.1 Description L’objectif principal d’OSSIM est de fournir un système centralisé, organisé permettant l’amélioration de la détection d’attaques ainsi que l’affichage organisé d’événements de sécurité. OSSIM possède les outils d’affichages suivants : – Fenêtre de contrôle pour les alarmes de haut niveau – Fenêtre de contrôle pour l’affichage des risques et de l’activité de niveau intermédiaire – Fenêtre de contrôle pour l’affichage des risques réseaux de bas niveau Ces différents outils utilisent des méthodes d’analyses améliorant la détection de relations entre les événements. Celles-ci peuvent être décomposées en : – Corrélation – Mise en place de niveaux de priorité 1 disponible sur : http ://www.ossim.net/ 83 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – Evaluation des risques OSSIM prévoit la récupération d’informations de différents détecteurs. En effet il est capable de récupérer et d’utiliser les informations d’IDS, de détecteurs d’anomalies, de firewalls et d’une variété d’autres éléments réseaux. Finalement il fournit un outil d’administration permettant de configurer et d’organiser les modules utilisés (externes et natifs). Cet outil permet la définition de la topologie utilisée, des polices de sécurité, des règles de corrélation et fournit les liens vers une variété d’outils existants intégrés à OSSIM F IG . 8.1 – Architecture d’OSSIM Nous observons sur la figure 8.1, les différents composants logiciel d’OSSIM. Nous remarquons l’utilisation de plusieurs base de données intermédiaires, décrites ci-dessous : EDB La base de données d’événements. Celle-ci est la plus volumineuse puisqu’elle stockera tous les événements individuel reçu par les détecteurs. KDB La base de données de configuration. Celle-ci stockera les polices de sécurité ainsi que les paramètres liés à l’architecture réseau. UDB La base de données des profiles. Celle-ci stockera toutes les informations générées par le moniteur de profile. 8.1.2 Méthodes d’analyses utilisées Le procédés de détection d’alarmes et de récolte de celles-ci repose sur des solutions existantes. En effet, rien de nouveau n’a été mis en place dans le domaine. OSSIM apporte alors une nouvelle solution pour tout ce qui touche au post-processing2 . Trois méthodes d’analyse à postériori sont appliquées : 2 Analyse des informations après leur réception 84 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web 1. Les alarmes sont classées suivant une priorité définie par les polices de sécurités mises en place sur l’architecture 2. La menace de chaque alarme est ensuite évaluée en fonction des éléments en dangers et de la probabilité de risque qu’il en découle 3. Une corrélation est ensuite appliquée afin de regrouper des alarmes indépendantes entre elles en événement hostiles Pour l’étape de corrélation, deux méthodes ont été déployées : Basée sur l’heuristique Cette méthode offrira une évaluation du risque comparable à un ”thermomètre”. Il sera ainsi possible, en tous temps, d’observer la ”température” de la sécurité du réseau. Pour ce faire, le risque a été séparé en deux catégories : Le risque que la machine soit compromise (risque nommé C), le risque potentiel d’une attaque sur cette machine (nommé A). A l’aide de ces deux types de risque, il sera possible à l’aide d’un algorithme (CALM3 ), de définir l’état global de sécurité de l’architecture. Basée sur des diagrammes d’états Cette méthode permet la création de diagrammes d’états du type : ”Si l’événement A et B sont détectés, effectuer l’action C”. A la suite des ces différentes étapes, OSSIM propose une visualisation des risques sous forme de page Web. Les figures suivantes illustrent l’interface proposée : F IG . 8.2 – Console de monitoring (affiche des statistiques d’une semaine) 3 Compromise and Attack Level Monitor 85 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 8.3 – Console de monitoring (affichage en temps réel du trafic Web, selon l’algorithme d’heuristique) 8.2 Open security management La société Open4 , spécialiée dans la corrélation d’alertes de sécurité en temps réel propose différents produits de sécurité. Leur Security Threat Manager est une application de gestion de la sécurité qui met en oeuvre une couche d’intelligence entre les équipements de sécurité et ceux qui sont en charge de leur administration. La figure 8.4 illustre le principe de corrélation mis en place par Open security. Le STM5 transforme les capteurs d’événements déployés sur les équipements de sécurité en un ensemble unifié. Pour ce faire, STM corrèle les données reçues afin de fournir un système d’alertes temps réel pour des administrateurs réseaux. STM combine l’intégralité des données de vulnérabilités et des événements de sécurité des é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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web F IG . 8.4 – Principe d’analyse et de corrélation mise en place par Open security management 8.2.1 Description La corrélation définie par STM utilise les caractéristiques suivantes : – Associe automatiquement les attaques aux vulnérabilités et la valeur de la cible – Rapporte les menaces sur la base du risque d’attaque et de l’impact sur les activités de l’entreprise – Relie les événements de multiples éditeurs et capteurs – Extensible et personnalisable : – Modification de l’interface par utilisateur – Sauvegarde, planification et impression de rapports de vulnérabilités pour des analyses en temps réel ou à postériori Le moteur de corrélation est basé sur NerveCenter, outil de corrélation utilisant une machine d’états. Les algorithmes intégrés ne requierent aucunes maintenance des règles et utilisent des données directement stockée en mémoire afin de tendre vers une utilisation le plus temps réel que possible. 87 Chapitre 9 Conclusion Durant ces trois mois de travail de diplôme, il nous a été offert d’effectuer différentes tâches aussi variées qu’intéressantes. En effet, nous avons eu le plaisir d’effectuer les travaux suivants : – Étudier et comparer différents reverse-proxys – Programmer en C++ (modification du code source de Dansguardian) – Déployer une architecture réseau complète (Firewall, reverse-proxy, serveurs Web, gestion des logs, etc...) – Étudier et appliquer une corrélation d’événements à notre architecture réseau – Programmer en Perl (conception d’un moteur de corrélation de démonstration) Nous estimons avoir atteint notre but, puisque la quasi totalité du cahier des charge a été remplie. Le lecteur attentif aura remarqué que l’étude des différentes attaques réseaux et Web (point I.b du cahier des charges) ne figure pas dans ce rapport, puisqu’un tutorial lui a été dédié lors du travail de semestre1 . Ce travail de diplôme ne peut en aucun cas prétendre avoir fait le tour du sujet. En effet, la corrélation d’événements reste un domaine en pleine évolution et en recherche de solutions efficaces. Il serait intéressant d’approfondir l’analyse et de mettre en place d’autres scenarii d’investigation permettant d’observer le comportement de l’architecture mise en place. De plus, il serait très utile de deployer et tester l’application de gestion d’intrusions Open Source OSSIM2 puisqu’il ne nous a pas été possible de le faire dans le cadre de ce projet (la découverte de cet outil s’est faite trop tard). Sur un point de vue plus logiciel et commercial, il serait souhaitable de mette sur pied une syntaxe de configuration permettant de définir ses propres scenarii d’investigations sans être un programmeur chevronné. D’un point de vue plus personnel, ce travail m’a permis d’élargir mes connaissances en sécurité réseau, configuration d’éléments réseaux et gestion de la détection d’intrusions. Ces différents domaines m’ont 1 2 Travail fournit en annexe à ce rapport Application décrite dans le chapitre 8 88 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web donné une forte envie d’approfondir mes connaissances en la matière. C’est pour cela que j’envisage fortement une formation plus poussée dans le domaine.... Yverdon-les-Bains, le 17 décembre 2004 Joël Winteregg 89 Chapitre 10 Remerciements et références 10.1 Remerciements Je tiens à remercier très chaleureusement les personnes suivantes pour leur soutien ainsi que pour leur aide apportée à l’élaboration de ce projet : Cyril Friche Pour les conseils, les informations sur SEC et la relecture. Stefano Ventura Pour différents conseils et la validation des idées. Gérald Litzistorf Pour les conseils de corrélation appliquée à l’architecture mise en place. Christian Tettamanti Pour les coups de pouces sous Linux. Sylvain Maret Pour les conseils d’architecture réseau. Yann Souchon Pour les conseils sur la mise en place du reverse-proxy Squid. Jérôme Caillet Pour différentes conseils et les échanges d’idées Raphaël Lienhard Pour différents conseils et les échanges d’idées Famille Winteregg Pour la relecture et la correction orthographique. 10.2 Références – Livre Snort 2 de Jack Koziol, édité 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ègles pour Prelude-lml (hids) : http ://www.leroutier.net/Projects/PreludeIDS/ 90 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – Installation : http ://entreelibre.com/scastro/prelude/preludeLML-secured-installation howto.txt – Reverse-proxy AppShield : Rapport de diplôme ”Securité 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émentation TCP du kernel Linux : http ://www.kernelnewbies.org/documents/ipnetworking/linuxipnetworking.html – Langage Perl : – Introduction à 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âches journalières via Cron : http ://www.commentcamarche.net/tutlinux/lincron.php3 – Dansguardian : – Principe de fonctionnement : http ://dansguardian.org/ ?page=dgflow 91 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web – Guide d’installation : http ://dansguardian.org/downloads/detailedinstallation2.html – Configuration : http ://linsec.ca/bin/view/Main/DansGuardian – Rating HTML utilisé 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élation : – Exemple de corrélation par SANS : http ://www.sans.org/resources/idfaq/role.php – Exemple d’application : http ://www.securityfocus.com/infocus/1708 – Outil de corrélation Open : http ://www.hermitagesolutions.com/public/pages/32092.php – Solution open source de corrélation : http ://www.ossim.net/whatis.php – SEC, outil de corrélation d’événements : http ://sixshooter.v6.thrupoint.net/SEC-examples/article.html – Manuel d’utilisation de MySql : http ://dev.mysql.com/doc/mysql/fr/index.html – Status code HTTP : http ://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 92 Annexe A Annexes A.1 Planning et coût horaire Après une partie théorique de recherche d’un reverse-proxy efficace et si possible open source, nous avons pu nous orienter sur la mise en place de l’architecture. Il a été nécessaire de configurer tous les éléments réseaux utilisés. Après cette partie de mise en place forte intéressante, il nous a été possible d’observer les comportements du réseau (surtout des sondes) face à différentes attaques. C’est ainsi qu’il nous a été possible d’établir un scénario d’investigation que nous avons implémenté sous forme de site Web dynamique en Perl. Le tableau suivant relate en coût horaire le travail effectué : 93 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web Activités Correction du travail de semestre et installation du système d’exploitation pour le reverse-proxy Documentations sur Snort et rédaction de la comparaison avec Prelude-IDS Étude, installation et tests de Squid Étude, installation et tests de Dansguardian Modification du code source de Dansguardian Rédaction et tests de Dansguardian Étude de l’URL rewriting à l’aide de Squid, installation HIDS du reverse-proxy Étude sonde HIDS (Prelude-lml) et installation du serveur Web vulnérable (IIS) Création des règles du HIDS et d’une blacklist à l’aide de Nessus et d’Ethereal Mise en place du firewall, de l’architecture totale et rédaction du rapport Mise en place de la rotation des logs et documentation sur la corrélation Documentation sur la corrélation et mise en place de NTP Étude d’une corrélation appliquée à notre architecture Étude de SEC et de son interfaçage avec le moteur de corrélation Apprentissage de Perl et de l’utilisation des CGI Étude de la détection des sessions TCP communes et implémentation du moteur de corrélation Implémentation du moteur de corrélation et rédaction du rapport Tests du moteur de corrélation et rédaction du rapport Rédaction du rapport Durée [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ère en deux parties. La première consiste à configurer le sensors1 à l’aide du fichier /etc/prelude-sensors/sensors-default.conf. Il permettra de définir l’adresse du manager, le type de machine hébergeant le sensors ainsi que son emplacement. Il s’agit donc d’une configuration globale d’un sensors (indépendante de son type). La seconde consiste en la configuration de la sonde elle même (NIDS ou HIDS). Il s’agira de définir, dans le cas d’une sonde HIDS, les fichiers de logs à analyser ainsi que les règles à utiliser. Dans le cas d’une sonde NIDS, il sera possible de sélectionner les plugins à utiliser. A.2.1 Configuration du sensor Fichier de configuration global du sensor. Situé à : /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épendante du type de sonde utilisée (NIDS ou HIDS) 94 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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 à 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web # # [Udp-Srvr] # # port = 514 # addr = 0.0.0.0 # # Files to monitor # #Fichier de réception des logs de IIS file = /var/log/messages #Fichier des logs d’accès du reverse-proxy file = /var/log/dansguardian/access.log # # Specifies the maximum difference, in seconds, between # the interval of two logfiles’ rotation. If this difference # is reached, a high severity alert will be emited # rotation-interval = 3600 #################################### # Here start plugins configuration # #################################### [SimpleMod] ruleset=/etc/prelude-lml/ruleset/simple.rules; # [Debug] # # This plugin issue an alert for each packet. # Carefull to the loging activity it generate. Configuration des règles à utiliser Fichier de configuration des règles (pattern matching) à utiliser. Celui-ci est précisé dans le fichier de configuration du HIDS par la directive ruleset=¡chemin¿/fichierDesRèglesAUtiliser.rules. Il se trouve à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ègles de récupération des logs de dansguardian include = dansguardian.rules; #fichier de règles de récupération des erreurs 4xx de IIS include = iis.rules; Règles (pattern matching) de Prelude-lml pour DansguardianSims Ce fichier se trouve à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ère demandée 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ère demandée 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ègles (pattern matching) de Prelude-lml pour IIS Ce fichier se trouve à : /etc/prelude-lml/ruleset/iis.rules 99 POST 0 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ël Winteregg # ##### ##################################################### # To get When a requested URL throw a 4xx status code #--------------------------------------------------# #IIS NEED TO have the following log configuration for #a matching by these rule: # # - W3C Extended Log File Format # # - Client IP # - Server IP # - Server Port # - Method # - URI Stem # - URI Querey # - Protocol Status # ##################################################### #LOG exemple: #Nov 8 14:48:06 192.168.1.4 edu-pc068 IISWebLogˆI3ˆI2004-11-08 13:48:03 192.168.1.2 - 192.168.1.4 80 GET /securitystore/lon.php - 404 regex=([\d+\.]+) - ([\d+\.]+) (\d+) (GET|POST) (.*) (4\d+); \ #si mot de la highsecuritywordlist ici alors sera en rouge dans interface graphique class.name=IIS Server: DENIED request to Web server $2, error code $6; \ impact.severity=medium; \ impact.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 à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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=<ip> <macaddr>; Configuration des règles à utiliser Ce fichier se trouve à : /etc/prelude-nids/ruleset/prelude.rules 102 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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 $<interfacename>_ADDRESS # which will be always initialized to IP address and # netmask of the network interface which you run # snort at. Under Windows, this must be specified # as $(<interfacename>_ADDRESS), such as: # $(\Device\Packet_{12345678-90AB-CDEF-1234567890AB}_ADDRESS) # # var HOME_NET $eth0_ADDRESS # # You can specify lists of IP addresses for HOME_NET # by separating the IPs with commas like this: # # var HOME_NET [10.1.1.0/24,192.168.1.0/24] # # MAKE SURE YOU DON’T PLACE ANY SPACES IN YOUR LIST! # # or you can specify the variable to be any IP address # like this: var HOME_NET 192.168.1.0/24 # Set up the external network addresses as well. # A good start may be "any" var EXTERNAL_NET any # # # # # Configure your server lists. This allows snort to only look for attacks to systems that have a service up. Why look for HTTP attacks if you are not running a web server? This allows quick filtering based on IP addresses These configurations MUST follow the same configuration scheme as defined above for $HOME_NET. # List of DNS servers on your network var DNS_SERVERS $HOME_NET # List of SMTP servers on your network var SMTP_SERVERS $HOME_NET # List of web servers on your network # The reverse-proxy is like the Web server for external IP var HTTP_SERVERS 192.168.1.2 # List of sql servers on your network var SQL_SERVERS $HOME_NET # List of telnet servers on your network var TELNET_SERVERS $HOME_NET # # # # # # # # # Configure your service ports. This allows snort to look for attacks destined to a specific application only on the ports that application runs on. For example, if you run a web server on port 8081, set your HTTP_PORTS variable like this: var HTTP_PORTS 8081 Port lists must either be continuous [eg 80:8080], or a single port [eg 80]. We will adding support for a real list of ports in the future. # Ports you run web servers on var HTTP_PORTS 80 # Ports you want to look for SHELLCODE on. var SHELLCODE_PORTS !80 # Ports you do oracle attacks on var ORACLE_PORTS 1521 # other variables # 103 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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é à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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 à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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=<ip> <macaddr>; Configuration des règles à utiliser Ce fichier se trouve à : /etc/prelude-nids/ruleset/prelude.rules ################################################### # Step #1: Set the network variables: # # You must change the following variables to reflect # your local network. The variable is currently # setup for an RFC 1918 address space. # # You can specify it explicitly as: # # var HOME_NET 10.1.1.0/24 # # or use global variable $<interfacename>_ADDRESS # which will be always initialized to IP address and # netmask of the network interface which you run # snort at. Under Windows, this must be specified # as $(<interfacename>_ADDRESS), such as: # $(\Device\Packet_{12345678-90AB-CDEF-1234567890AB}_ADDRESS) # # var HOME_NET $eth0_ADDRESS # # You can specify lists of IP addresses for HOME_NET # by separating the IPs with commas like this: # # var HOME_NET [10.1.1.0/24,192.168.1.0/24] # # MAKE SURE YOU DON’T PLACE ANY SPACES IN YOUR LIST! # # or you can specify the variable to be any IP address # like this: var HOME_NET 192.168.1.0/24 107 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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’établissement des règles du firewall Ce script est exécué à chaque démarrage du firewall. Il se trouve donc à : /etc/init.d/configFirewall Il est ensuite lié aux runlevels adéquats pour une exécution automatique. La commande update-rc.d permet la création automatiquement des liens dans les différents runlevel : # update-rc.d configFirewall defaults 90 Script de configuration du Firewall : #!/bin/sh # #Configuration du firewall #========================== #Projet SIMS orienté Web #========================== # #Le contrôle des regles s’opère dans l’ordre de leurs declaration. #Nous avons donc place le drop indiquant le fonctionnement whitelist #a la fin. ####################################### #Initialisation des chaines ####################################### #on efface les regles iptables -F iptables -t nat -F #on efface les chaines utilisateurs iptables -X ####################################################### #creation d’une chaine utilisateur pour droper et loger ####################################################### iptables -N LOG_DROP iptables -A LOG_DROP -j LOG --log-prefix "Drop " iptables -A LOG_DROP -j DROP ############################################################################### #Initialisation des polices par defauts: Tout est autorisé afin de tout #laisser passer lors de la réinitialisation (iptables -F) #le drop se fait à 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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êtes 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ée à sortir du réseau iptables -A FORWARD -i eth1 -p tcp -s 192.168.1.3 -j ACCEPT iptables -A FORWARD -i eth0 -p tcp -d 192.168.1.3 -j ACCEPT #on accepte de router tous les pings iptables -A FORWARD -p icmp -j ACCEPT #pour l’envoi des mails du watchdog situé 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émo) ############################################################################ iptables -t nat -A PREROUTING -p tcp --dport 666 -d 10.192.72.83 -i eth0 -j DNAT --to 192.168.1.3:80 ######################################################################### #Activation du NAT dynamique (Masquerading) pour que les machines internes autorisee #a sortir sur le reseau TCOM puissent le faire ######################################################################### iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE ########################### #Activation du routage ########################### echo 1 > /proc/sys/net/ipv4/ip_forward ########################## #Lancement du HIDS ########################## prelude-lml -d A.4.2 Configuration du sensor Fichier de configuration situé à : /etc/prelude-sensors/sensors-default.conf # This is the default configuration for sensors that use libprelude. 110 Projet de Diplôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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é à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ègles à utiliser Ce fichier se situe à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté 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 été atteinte. Fichier de configuration situé à : /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ôme 2004 - Joël Winteregg SIMS - Security Intrusion Manager System orienté Web A.5 Configuration de Piwi et du moteur de corrélation # Database : $conf{’dbtype’}=’mysql’; # mysql / Pg $conf{’dbname’}=’prelude’; $conf{’dbhost’}=’192.168.1.5’; $conf{’dbport’}=3306; # default mysql port is 3306 / pgsql 5432 # $conf{’dboptions’}=’mysql_compression=1’; $conf{’dblogin’}=’prelude’; $conf{’dbpasswd’}=’prelude’; # Other : $conf{’debug’}=0; # Debug perl code onscreen (0 or 1) $conf{’extension’}=’.pl’; # scripts file extension (.pl) $conf{’refresh’}=600; # AlertList refresh in seconds (600) $conf{’ettercap_fp_db’}=’./generated/DB/etter.passive.os.fp’; $conf{’ettercap_mac_db’}=’./generated/DB/mac-fingerprints’; $conf{’HostName_Lookup’}=1; # Host Name Resolution (0 or 1) $conf{’GD_transparent’}=0; # Are graphs transparent ? $conf{’GMTdiff’}=+1; # default element number by page in Alert List $conf{’nb_resbypage’}=30; # default alert number by group in Alert List when grouping (0 to hide) $conf{’nb_resbygroup’}=5; # default elements listed in TopAttack*s pages $conf{’nb_topattack*s’}=20; $conf{’gs_path’}=’/usr/bin/gs’; $conf{’default_backend’}=’PS’; ###################################################### # Configuration de la corrélation (SIMS orienté 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ée max d’une session TCP: pour la création du contexte session TCP (en secondes) $conf{’TcpSessionDuration’}= 10; #port d’écoute du serveur Web $conf{’portServeur’}= 80; #IP du serveur Web $conf{’ipServeur’}= ’192.168.1.4’; #IP du reverse-proxy $conf{’ipProxy’}= ’192.168.1.2’; #fênetre de corrélation (en secondes) = de maintenant à N secondes dans le passé... $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éelle de l’attaquant $conf{’timeIntervalFindingIP’}=10; 115