Trithème, Distributed and Hybrid Intrusion Detection and Response System by Trithème Dev Team | http://tritheme.sourceforge.net Last Update > 20/06/2001 Now, a few words on looking for things. When you go looking for something specific, your chances of finding it are very bad. Because, of all the things in the world, you're only looking for one of them. When you go looking for anything at all, your chances of finding it are very good. Because, of all the things in the world, you're sure to find some of them. -- Darryl Zero, in The Zero Effect Abstract Ce texte se veut l'article de foundation et de définition de l'architecture du projet d'IDS Trithème. Il est présenté sous la forme d'une FAQ et représente une introduction rapide aux techniques de détection d'intrusion. 1. Qu'est ce qu'un IDS ? 1.1. Quelles sont les différences entre les modèles behavior-based et knowledge-based ? 2. Qu'est ce que Trithème ? 2.1. L'architecture de Trithème 2.1.1. Qu'est ce que le Manager ? 2.1.2. Qu'est ce qu'OLAP ? 2.1.3. Qu'est ce que Ubik_lib ? 2.1.4. Qu'est ce qu'un agent ? 2.1.5. Qu'est ce que l'Intrusion Detection Message Exchange Format ? 2.1.6. Qu'est ce que SSL et OpenSSL ? 2.2. Qu'est ce que Sniff_mod ? 2.2.1. Qu'est ce que la Misuse Detection ? 2.2.2. Qu'est ce qu'une signature et le Pattern Matching ? 2.2.3. Qu'est ce que libpcap et libnet ? 2.3. Qu'est ce que Log_mod ? 2.3.1. Qu'est ce que l'Anomaly Detection ? 2.4. Qu'est ce que Nessusd/Trithème ? 2.5. Qu'est ce que Data_mod ? 2.5.1. Qu'est ce que le Data Mining et le Knowledge Discovery ? 2.7. Qu'est ce qu'ICE_mod 2.7.1. Qu'est ce que les Intrusion Countermeasures ? 2.7.2. Qu'est ce que les rapports ? 3. Conclusion 4. Références 1. Qu'est ce qu'un IDS ? IDS est l'acronyme de Intrusion Detection System. La détection d'intrusion est l'art de détecter une activité inappropriée, incorrecte ou anormale. Des sytèmes ID qui opèrent sur un hôte pour détecter une activité malveillante sur cet hôte sont appelés host-based ID systems, et des systèmes ID qui opèrent sur un flux de données réseau sont appelés network-based ID systems. L'ID host-based implique de charger un ou des blocs de logiciel sur le système à surveiller. Le logiciel chargé utilise des fichiers logs et/ou des agents auditant le système comme sources d'information. En revanche, un système ID basé sur le réseau surveille le trafic sur son segment de réseau comme source d'information. Les capteurs ID network-based et host-based ont tous 2 des avantages et des inconvénients, et à la fin, vous voudrez probablement utiliser une combinaison des 2. La personne chargée de surveiller les IDS doit être alerte, un administrateur système compétent, qui est familier de la machine hôte, des connexions réseau, des utilisateurs et de leurs habitudes, et de tous logiciel installé sur la machine. Ceci ne signifie pas que lui ou elle doit être un expert du logiciel lui-même, mais a besoin plutôt de sentir la façon dont la machine est censée fonctionner et quels programmes sont légitimes. Beaucoup d'intrusions ont été contenus par des admins attentifs qui ont noté quelque chose de "différent" au sujet de leurs machines ou qui ont noté à la fois le log d'un utilisateur et une entrée atypique pour cet utilisateur. L'ID basé sur l'hôte implique de regarder non seulement le trafic des transmissions dans et hors d'un ordinateur simple, mais également de contrôler l'intégrité de vos fichiers système et d'observer les processus soupçonneux. Pour atteindre l'assurance complète votre site avec l'ID host-based, vous devez charger le logiciel ID sur chaque ordinateur. Il y a 2 classes primaires de logiciel de détection d'intrusion basé sur l'hôte : wrappers/firewall personnel hôte et logiciel basé sur des agents. L'une ou l'autre approche est beaucoup plus efficace en détectant des attaques d'intrusion par des hôtes de confiance (prétendue activité anormale) que ne l'est l'ID network-based, et toutes les 2 sont relativement efficaces pour détecter des attaques à partir de l'extérieur. Un système ID network-based surveille le trafic sur son segment de réseau comme source d'informations. Ceci est généralement accompli en plaçant la carte d'interface réseau en mode promiscuous pour capturer tout le trafic réseau qui croise son segment réseau. Le trafic réseau sur d'autres segments, et le trafic sur d'autres moyens de communication (comme les lignes téléphoniques) ne peuvent pas être surveillés. Les capteurs ID network-based et host-based ont des avantages et des inconvénients. En fin de compte, vous voudrez probablement une combinaison des 2. L'ID basée sur le réseau implique de regarder les paquets sur le réseau pendant qu'ils passent par un certain capteur. Le capteur peut seulement voir les paquets qui s'avèrent justement être destiné à son segment réseau. Des paquets sont considérés d'intérêt s'ils correspondent à une signature. Trois types primaires de signatures sont des signatures de strings, des signatures de ports, et des signatures d'header condition. COAST Intrusion Detection Pages http://www.cerias.purdue.edu/coast/intrusion-detection/ Synthèse d'articles http://www.guill.net/reseaux/Articles.html SANS IDS FAQ http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm Robert Graham NIDS FAQ http://www.ticm.com/kb/faq/idsfaq.html CERIAS Technical Reports https://www.cerias.purdue.edu/techreports-ssl/ Columbia IDS Project : Publications http://www.cs.columbia.edu/ids/publications/ Intrusion Detection and Netowkr Auditing in the Internet http://www.infosyssec.org/infosyssec/intdet1.htm Salvatore J. Stolfo http://www.cs.columbia.edu/~sal/ IDS Mailing List Archives http://www.geek-girl.com/ids/index.html 1.1. Quelles sont les différences entre les modèles behavior-based et knowledge-based ? Il y a 2 approches complémentaires pour détecter des intrusions, l'approche knowledge-based et l'approche behavior-based. Les techniques behavior-based intrusion detection supposent qu'une intrusion peut être détectée en observant une modification du comportement normal ou prévu du système ou des utilisateurs. Le modèle du comportement normal ou valide est extrait à partir d'informations de référence rassemblées par de divers moyens. Le système de détection d'intrusion compare plus tard ce modèle à l'activité courante. Quand un changement est observé, une alarme est générée. En d'autres mots, tout ce qui est fait qui ne correspond pas à un comportement préalablement appris est considéré comme une intrusion. Par conséquent, le système de détection d'intrusion pourrait être complet (i.e. toutes les attaques devraient être détectées), mais son exactitude est un facteur difficile (i.e. vous allez avoir beaucoup d'alarmes). Les avantages des approches basées sur le comportement sont qu'elles peuvent détecter des tentatives d'exploitation de vulnérabilités nouvelles et imprévues. Elles peuvent même contribuer (partiellement) à la découverte automatique de ces nouvelles attaques. Ils sont moins dépendants des mécanismes spécifiques des systèmes d'exploitation. Ils aident également à détecter les types d'attaques "d'abus de privilèges" qui n'impliquent pas réellement d'exploiter une vulnérabilité de sécurité. En bref, c'est l'approche paranoïaque : Tout ce qui n'a pas été vu précédemment est dangereux. Le nombre élevé de fausses alarmes est généralement citée comme inconvénient majeur des techniques basées sur le comportement parce que la portée entière du comportement d'un système d'information ne peut être couverte pendant la phase d'apprentissage. En outre, le comportement peut changer avec le temps, présentant le besoin de réapprentissage en ligne périodique du profil de comportement, ayant comme conséquence l'indisponibilité du système de détection d'intrusion ou de fausses alarmes supplémentaires. Le système d'information peut subir des attaques en même temps que le système de détection d'intrusion assimile le comportement. En conséquence, le profil comportemental contient le comportement intrusif, qui n'est pas détecté comme anormal. Les techniques de détection d'intrusion basé sur la connaissance appliquent les connaissances accumulées au sujet des attaques et des vulnérabilités spécifiques du système. Le système de détection d'intrusion contiennent des informations sur ces vulnérabilités et recherche des tentatives d'exploiter ces vulnérabilités. Quand une telle tentative est détectée, une alarme est déclenchée. En d'autres termes, toute action qui n'est pas explicitement identifiée comme une attaque est considérée acceptable. Par conséquent, l'exactitude des systèmes de détection d'intrusion basé sur la connaissance est considérée bonne. Cependant, leur perfection (i.e. le fait qu'ils détectent toutes les attaques possibles) dépend de la mise à jour régulière des connaissances concernant les attaques. Les avantages des approches basées sur la connaissance sont qu'elle ont un potentiel de fausses alarmes vraiment faible, et l'analyse contextuelle proposée par le système de détection d'intrusion est détaillée, facilitant pour l'administrateur sécurité l'utilisation du système de détection d'intrusion afin de prendre des mesures correctives ou préventives. Les inconvénients incluent la difficulté de recueillir l'information exigée sur les attaques connues et de la maintenir à jour avec de nouveaux vulnérabilités et environnements. L'entretien de la base de connaissance du système de détection d'intrusion exige l'analyse soigneuse de chaque vulnérabilité qui est donc une tâche longue. Les approches basées sur la connaissance doivent également faire face à la généralisation des sorties. La connaissance concernant les attaques est très réduite, dépendant du système d'exploitation, de la version, de la plate-forme, et des applications. L'outil de résultat de la détection d'intrusion est par conséquent étroitement rattaché ) un environnement donné. En outre, la détection des attaques internes comportant un abus de privilèges est considérée plus difficile parce qu'aucune vulnérabilité n'est exploitée réellement par l'attaquant. 2. Qu'est ce que Trithème ? Trithème est un système de détection et de contre-mesure d'intrusion IDS hybride et distribué permettant l'utilisation simultanée des approches host-based et network-based par le chargement dynamiques des fonctions de ses modules à des agents répartis sur l'ensemble du segment de réseau à surveiller. En combinant ces approches, il se veut plus exhaustif et alerte que les IDS classiques. Trithème suit par ailleurs l'esprit du libre puisqu'il est distribué sous licence GPL, développé de façon communautaire sur SourceForge et se trouve basé sur les formats libres que sont Linux et les Unix libres, le langage C ou le format XML. General Public License v2 http://www.gnu.org/copyleft/library.txt How To Select a Free Software License http://www.kuro5hin.org/?op=displaystory;sid=2001/3/13/112250/379 Open Source Definition http://www.perens.com/OSD.html Full Disclosure of Vulnerabilities - pros/cons and fake arguments http://ntsecurity.nu/papers/disclosure/ The Open Source Initiative Approved Licenses http://opensource.org/licenses/ Are you ready for C 99 ? www.kuro5hin.org/?op=displaystory&sid=2001/2/23/194544/139 Programming in C, UNIX system calls and subroutines using C http://www.cm.cf.ac.uk/Dave/C/CE.html 2.1. L'architecture de Trithème L'architecture de Trithème est basé sur 2 grands principes : les agents et les modules. Les modules regroupent les diverses fonctions de Trithème. Ces fonctions sont distribuées aux agents qui se répartissent sur le réseau en appliquant chacun une tâche spécifique. Un serveur est défini, appelé manager Trithème, sur lequel est installé les modules qui peuvent être ensuite chargé dynamiquement par chaque agent, la gestion de la communication agents/agents, agents/modules et modules/analyste et l'ensemble des bases de données utilisées par Trithème. L'unique désavantage de cette architecture se trouve dans le manager Trithème qui devient un single point of failure (SPOF) : si il est compromis, l'ensemble du système est compromis. La gestion des modules et des agents se fait de manière dynamique permettant d'adapter Trithème aux besoins et aux capacités précis du réseau. En fait la meilleure illustration de l'architecture Trithème je pense que c'est le Sikorsky Skycrane ;) An Architecture for Intrusion Detection using Autonomous Agents http://www.cerias.purdue.edu/homes/aafid/ Traduction du document précédent http://www.chez.com/keep/aafid.htm Distributed Intrusion Detection for Computer Systems Using Communicating Agents http://www.cs.nps.navy.mil/people/faculty/rowe/c4i00a.htm Autonomous Agents For Distributed Intrusion Detection in a Multihost Environment http://www.cs.nps.navy.mil/people/faculty/rowe/ingramthesis.htm 2.1.1. Qu'est ce que le Manager ? Le Manager Trithème est le coeur de l'architecture Trithème. Il regroupe les fonctions basiques du système telles que la création et la gestion d'agents/senseurs, leur communication et intéraction grâce à Ubik_lib, et l'interface utilisateur. Cette interface permettra donc l'administration et la configuration des agents, de leurs tâches ainsi que des segments et systèmes qu'ils sont chargés de surveiller. Le chargement, une gestion et une mise à jour des différents modules de manière dynamique et indépendante est également possible grâce à l'indépendance des modules entre eux et surtout par l'utilisation de dlopen() permettant d'attacher un processus à un exécutable et donc de charger cette exécutable dynamiquement en fonction du besoin. De plus cette fonction permet d'utiliser Trithème comme un système de détection d'intrusion global ou bien de manière plus spécifique comme NIDS, gestionnaire de vérification d'intégrité système, scanner de vulnérabilités ou encore analyseur et extracteur de données. Cette dernière fonction devrait pouvoir être applicable à un large panel d'IDS grâce à l'interopérabilité. Des capacités de planification et d'automatisation - par l'intermédiaire de cron par exemple - sont aussi possibles. L'interface doit également permettre l'indexation et la recherche par keywords dans l'operationnal datastore (données brutes) et la génération de rapports depuis le data warehouse. La dernière fonction du Manager constiste en une capacité automatique et configurable de réponse aux intrusions par modification de la topologie réseau - permettant par exemple l'isolement en DMZ d'un système attaqué, ou la redirection d'une attaque en cours vers un honeypot/honeynet - ou la suppresion de communication par exemple avec un killer RST. Et bien sûr, le reporting par degrés de gravité eux mêmes configurables et la redirection vers une solution aux vulnérabilités répertoriées. L'ensemble de ces fonctions sont traitées par l'intermédiaire d'une interface graphique PHP visible au sein d'un browser alliée à un compact httpd par simplicité. L'intéraction avec le Data Warehouse Trithème s'effectuera par de simples requêtes SQL puis un parsage des données XML contenues ds le data wrehouse renforcant ainsi la similarité avec un simple site. Cette utilisation de SQL sur une base de données OLAP s'explique par l'utilisation de l'appelation ROLAP pour Relationnal OLAP permettant l'application de directives relationnelles et donc SQL sur un format multidimensionnel. A noter qu'une interface console avec configuration en ligne de commande devrait être également disponible par l'intermédiaire d'une console distante en tunnel SSH. _________________ Agent SSL Manager ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ | _________________ httpd SSL Console Analyste ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ | interface PHP sous browser Linker and Libraries Guide http://ab2.cs.uiuc.edu/ab2/coll.45.5/LLM/@Ab2TocView/123? Dynamic Shared Object Support http://httpd.apache.org/docs/dso.html Webmin : A powerful web-based administration interface for Unix systems http://www.webmin.com/webmin/ 2.1.2. Qu'est ce qu'OLAP ? OLAP est l'acronyme de On-Line Analytical Processing. Il désigne une catégorie d'applications et de technologies permettant de collecter, stocker, traiter et restituer des données multidimensionnelles, à des fins d'analyse. Une autre définition est résumée dans l'acronyme FASMI (Fast Analysis of Shared Multidimensional Information), ou analyse rapide d'information multidimensionnelle partagée. Les outils OLAP doivent respecter 12 règles précises : - Modèle multidimensionnel - Transparence du serveur - Accessibilité - Performances d'accès stables - Client serveur - Dimensionnalité générique - Gestion des données éparses - Multi-utilisateur - Opérations sur les dimensions - Manipulation intuitive des données - Souplesse d'affichage et d'édition - Dimensions et niveaux multiples OLAP est donc basé sur les dimensions ou axes qui sont des ensembles de données du même type, permettant de structurer la base multidimensionnelle. Chaque cellule d'une mesure est associée à une seule position de chaque dimension. OLAP se base sur un second concept que sont les cubes ou hypercubes qui sont construction multidimensionnelle formée de la conjonction de plusieurs dimensions. Chaque case du cube représente une valeur. Les dimensions sont indiquées sur les arêtes du cube. Un plan du cube correspond à toutes les valeurs pour une seule position d'une des trois dimensions. Enfin, le cube complet représente une mesure, parfois appelée population d'analyse. Chaque cellule est définie par un seul membre de chaque dimension. Les hypercubes sont constitués de cellules définies par une position de chaque dimension. Les cellules d'un hypercube peuvent être vides ou remplies. Lorsqu'un grand nombre de cellules sont vides, on parle de données éparses. Les cubes peuvent être regroupés en multicubes partageant certaines dimensions. Ou encore, les données peuvent être modéliser sous la forme de formules, des hypercubes virtuels, où les valeurs obtenues sont le plus souvent calculées à la volée mais non stockée dans la base de données. Un dernier concept de base d'OLAP est la hierarchie. La hierachie représente les positions d'une dimension organisées selon une série de relations 1-n en cascade. Cette organisation de données est comparable à un arbre logique, ou chaque membre n'a pas plus d'un père mais un nombre quelconque d'enfants. Au sein d'une hiérarchie, les positions sont en général organisées en niveaux. Les positions d'un même niveau correspondent à une classification précise. Par exemple, on peut concevoir une dimension "temps", pour laquelle les jours sont au niveau 1, les mois au niveau 2 et les années au niveau 3. La recherche et le calcul au sein de ces dimensions hierarchiques s'effectuent par une opération appelée agrégation qui calcule les valeurs associées aux positions parents. Des variantes d'OLAP ont fleuris : - HOLAP pour Hybrid OLAP qu désigne des outils d'analyse multidimensionnelle qui récupèrent les données dans des bases relationnelles ou multidimensionnelles, de manière transparente pour l'utilisateur. - MOLAP pour Multidimensional OLAP. Ce terme désigne plus spécifiquement une technologie de stockage logique. MOLAP s'oppose à ROLAP. Pour le premier, les corrélations sont déja faites, ce qui explique les performances. Dans le second, les corrélations entre les tables de dimension et de fait sont effectuées au moment de la requête. - ROLAP pour Relational OLAP. Il s'agit d'un ou plusieurs schémas en étoile stockés dans une base relationnelle. Cette technique permet de faire de l'analyse multidimensionnelle à partir de données stockées dans des bases relationnelles. La technologie OLAP est utile dans tous les domaines qui requierent analyse, consolidation de données et aide à la décision. OLAP and OLAP Server Definitions http://www.olapcouncil.org/research/glossaryly.htm OLAP Council API, MDAPI http://www.olapcouncil.org/research/v20ps.zip Data Warehousing and OLAP Bibliography http://www.cs.toronto.edu/~mendel/dwbib.html Project Aardvark : OLAP for LINUX http://www.visionyze.com/products_and_solutions/linux_offering/ Data Warehouse Evolution ftp://ftp.cs.wpi.edu/pub/techreports/pdf/98-2.pdf Mining databases with different schemas : Integrating incompatible classification http://www.cs.columbia.edu/~sal/JAM/PROJECT/HTML-papers/KDD98- bridging/Paper/index.html Les Bases de Données OLAP http://perso.wanadoo.fr/bernard.lupin/ 2.1.3 Qu'est ce que Ubik_lib ? Ubik_lib est une librairie destinée à automatiser la communication entre les agents et le manager Trithème notamment par l'intermédiaire de socket avec une description de données IDMEF et un tunneling SSL. Un agent est crée sur le système distant, hérite ses fonctions du module qui a appelé sa création et transmet ses résultats au manager par l'intermédiaire d'appel Ubik_lib. Le tunneling SSL permet d'offrir des garanties de confidentialité et d'intégrité pour les communication de maintenance et la transmission de raport d'activité. Le système de communication inter-agents est dit du "tableau noir" : L'agent inscrit sur un tableau noir les données dont il a besoin et les agents viennent consulter ce tableau pour s'entraider. La gestion dynamique des modules et agents Trithème requiert un dynamisme égal dans l'architecture de communication et de comportement. Chaque module ou agent s'annonce auprès du manager Trithème qui le prend ainsi en compte pour la répartition des charges et la transmission d'information inter-agents permettant de créer un pool d'agents à qui distribuer les tâches. C'est dans cette optique que la repartition de charge sur des Large Fat Network (LFN) implémentant assez d'agents pour créer une concurrence doit aussi être prise en compte permettant une meilleure efficacité et une redondance. Pour ce faire, l'algorithme de répartition weighted-least connection est implémenté au sein du Manager et appliqué aux routines de Ubik_lib afin d'adapter la destination des communications vers l'agent dont l'indice de capacité est le plus important et qui à un moment T affiche le load average la plus faible. Ainsi les machines les plus performantes qui expedient plus rapidement les tâches ou en ont fini avec des tâches benignes peuvent s'atteler à la nouvelle tâche. Agent -- SSL -\ \ \ Agent ---- SSL --\ Ubik_lib \ | \ | Agent ----- SSL ------- Manager Trithème ------ SSL ------ Console Analyste / | / | Agent ---- SSL --/ On Line Analytical Processing / / Agent -- SSL -/ Une idée à évaluer et de faire passer l'ensemble des communications Ubik_lib par du TCP/80 (HTTP donc) afin de faciliter l'implentation dans un réseau, le port 80 étant rarement filtré ou limité. 2.1.4. Qu'est ce qu'un agent ? Un agent est une unité de travail réduite distante appelée par le Manager Trithème en fonction des besoins et des fonctionnalités requises. Il y aura un agent sur chaque machines compatible POSIX du réseau à surveiller qui receveront leur tâche depuis le manager Trithème et communiqueront l'ensemble de leur données par ce manager et Ubik_lib. Ils sont constitués uniquement des structures necessaire à l'execution de la tâche à accomplir ainsi que d'une structure de communication avec le manager par l'intermédiaire de Ubik_lib. L'agent peut charger les différents modules Trithème de manière dynamique grâce à une gestion similaire par librairies dynamiques et améliorer l'efficacité en minimisant la consommation de ressources - on peut imaginer sur un réseau réduit que chaque agent n'effectue qu'une fonction et donc qu'un seul module à la fois ; en permettant l'utilisation exclusive de Trithème de l'un de ses aspects comme l'ID host based, le logging centralisé ou l'analyse et la corrélation d'information etc. ; ou beaucoup plus pointu, on peut imaginer d''appliquer une technique de "chaises tournantes" consistant à faire changer très régulièrement la fonction de chaque agent rendant la détection et l'attaque de senseurs particuliers beaucoup plus délicates. Machine 1 / Agent 1 Machine 2 / Agent 2 Machine 3 / Agent 3 | | | | | | | |_ Sniff + | |_ Data + | |_ Nessusd + | Log + ICE | Log + ICE | Log + ICE ------------------------------------------------------------- | | transmission d'information et d'ordres par Ubik_lib | | Data Warehouse ------ Manager Trithème ------ Ubik_lib | | interface browser / console Autre avantage des agents, leur répartition permet de ne pas surcharger la machine hôte du manager puisque les agents tournent sur les machines distantes qu'ils testent. Les agents Data_mod permettent d'autre part de réduire la charge de travail du manager Trithème en distribuant les tâches lourdes en ressource d'analyse et d'extraction de données. Et plusieurs agents sont optimisés grâce à des algorithmes de repartition de charge. MIT Media Lab : Software Agent Group http://wex.www.media.mit.edu/groups/agents/ Intelligent Agents for Intrusion Detection http://www.cs.iastate.edu/~honavar/Papers/it98-helmer.ps 2.1.5. Qu'est ce que l'Intrusion Detection Message Exchange Format ? L'Intrusion Detection Message Exchange Format est un projet de format standard dirigé par l'Intrusion Detection Exchange Format Working Group (IDWG) au sein de l'IETF. Il sera utilisé à termes pour la communication de rapports d'activité ou d'évènements entre divers IDS et/ou parties d'IDS. Ce protocole n'est pas encore une spécification officielle et tous les documents qui lui sont relatif sont encore au stade de draft ou memo. Cependant IDMEF offre une excellente source d'inspiration et assurera plus tard la standardisation et l'interoperabilité de Trithème. Il est de plus le prolongement direct de l'initiative Common Intrusion Detection Framework qui fournissait déjà une série de standards pour les NIDS ainsi qu'un langage de définition pour la communication entre les différents composants du modèle CIDF nommé CISL pour Common Intrusion Detection Language. Les prérequis d'IDMEF concernent l'architecture de communication et l'intégrié des communications inter-composants. Ainsi IDMEF doit assurer l'intégrité, la confidentialité, la non répudiation et la prévention contre le rejeu. Toutes ces mesures sont prises pour assurer une transmission des rapports d'activité et des opérations de maintenance sans risquer la compromission du système. Les travaux de l'IDWG descendent directement du format CIDF (Common Intrusion Detection Framework) développé entre autre par la DARPA. IDMEF reprend donc lui aussi un schéma d'architecture des communications qui peuvent être adapté aux IDS spécifiques. Ce schéma définit plusieurs composantes : - l'administrateur qui désignent le facteur humain responsable de la politique de sécurité et de son application. - l'alerte qui désigne un message d'une analyseur vers un manager signalant une activité suspect (EOI, Events of Interest). - l'analyseur qui désigne une composant (pour Trithème, un agent) qui analyse les données collectées par les senseurs à la recherche d'EOI. - la source de données désigne les données brutes utilisés pour détecter une activité non autorisée. Ces sources de données sont généralement les flux de bas niveau et les logs. - l'évènement désigne une séquence suspecte détectée par un senseur au sein d'une source de données. Les alertes sont la suite logique des évènements. - l'IDS, système de détection d'intrusion qui est constitué de senseurs, d'analyseurs et de managers. - le manager désigne le composant depuis lequel l'operateur administre les divers composants de l'IDS. Les fonctions attribués au manager sont habituellement la configuration des senseurs et des analyseurs et les rapports. - la notification est la méthode classique par laquelle le manager alerte l'operateur d'un EOI. Les notifications courantes sont la tramission d'alertes par mail, pager ou encore par canal SNMP. - l'opérateur est l'utilisateur humain habituel du manager. Il surveille les sorties de l'IDS et recommande ensuite des réponses. - la réponse est correspond aux réactions face à un EOI. Une réponse peut être effectuée de manière automatique par un composant de l'IDS ou bien manuellement par l'intermédiaire de l'opérateur. Les réponses classiques inclues la notification, le logging, la modification des contrôles d'accès et la suppresion des connexions. Cette fonction peut être parametrée au sein de Trithème par l'intermédiaire du Manager et les réponses peuvent être la modification à divers degré de la topologie et de l'accessibilité réseau. - le senseur est le composant qui collecte les données auprès de la source de données, puis les envoie à l'analyseur. - la signature est la règle utilisé par l'analyseur pour identifier l'activité malveillante. - la politique de sécurité est un document prédéfini qui définit les activités autorisées au sein du réseau et des systèmes de l'organisation. Senseur Opérateur / \ / / / évènement notification réponse Source / \ / / de --- activité --> --- Analyseur --- alerte ---> Manager _______/ Données \ / | \ \ évènement |----------------- politique de securité \ / / \ Senseur _______/ Administrateur Intrusion Detection Exchange Format Working Group http://www.ietf.org/html.charters/idwg-charter.html Mirror IDWG http://www.silicondefense.com/idwg/ The XML Cover Pages : Intrusion Detection Message Exchange Format http://www.oasis-open.org/cover/idmef.html 2.1.6. Qu'est ce que SSL et OpenSSL ? SSL est l'acronyme de Secure Socket Layer. C'est un protocole de sécurité qui assure l'intégrité des communications sur Internet. Le protocole permet à des applications client/server de communiquer d'une manière destiné à prévenir l'interception, la modificaion ou la fabrication de message. SSL est utilisé pour l'encapsulation de protocoles de haut niveau variés ainis que l'authentification mutuelle de client et serveur, le tout de manière transparente pour l'utilisateur. Les principes de SSL sont : - La connexion est privée. L'encryption est utilisée après une procédure d'handshake pour définir une clé secrète. Des algorithmes de cryptographie à clé symmétrique sont utilisé pour l'encryption des données. - L'identité du port peut être authentifiée en utilisant une clé asymmétrique ou publique. - La connexion est fiable. Le transport de message inclut un contrôle d'intégrité de message. OpenSSL quant à lui est un toolkit open source (sous licence Apache) implémentant les protocoles SSL v2/v3 et TLS v1 en tant que librairie cryptographique. Il existe un remplacement normalisé et extrêmement similaire à SSL qui est TLS pour Transport Layer Secure. OpenSSL Toolkit http://www.OpenSSL.org Universal SSL Wrapper http://www.Stunnel.org Secure Socket Layer v3 http://www.netscape.com/eng/ssl3/draft302.txt Transport Layer Secure v1 http://www.ietf.org/html.charters/tls-charter.html New European Schemes for Signatures, Integrity and Encryption http://www.cosic.esat.kuleuven.ac.be/nessie/ 2.2. Qu'est ce que Sniff_mod ? Sniff_mod est destiné à être le premier module de Trithème. Il regroupera les fonctions de l'approche network-based. Il assurera ainsi la fonction de capturer et d'analyser le trafic réseau et les paquets qui y transitent afin de détecter à l'aide d'un système expert les corrélations avec la base de données de signatures dénotant une tentative d'intrusion. Une seconde corrélation à plus long terme peut être effectuée sur le Data Warehouse pour permettre la détection de scénarios d'attaques décrivant une suite d'évènements. L'ensemble de ces résultats sont ensuite compilés dans un rapport et peuvent également être recherchés par l'intermédiaire de la console analyste. Sniff_mod utilise des règles d'implication if-then qui permettent de spécifier les conditions necessaires à une attaque plutôt que ça simple signature et ensuite de notifier les contre mesures ou alertes à effectuer par l'intermédiaire du Manager. Sniff_mod représente les fonctions de l'approche network-based de Trithème. Il est donc le plus sujet aux vulnérabilités inhérentes au Network IDS. La parade principale de Sniff_mod se trouve dans son architecture distribuée. En effet, l'utilisation de multiples senseurs permet de supprimer les problèmes liés au monitoring monoflux, au TTL courts, à la désynchronisation et même aux problèmes de Denial of Service -- excepté sur le manager Trithème. La défragmentation et le spoofing peuvent être éliminés quant à eux par un contrôle dynamique des ISN et des checksums TCP. Par ailleurs une capacité de gestion de flux et donc de réassemblage semble nécessaire à une meilleure vérification au niveau des payload et des headers lors d'une communication fragmentée ou aux options non conformes qui devraient cependant être évitées grâce au normaliser. Cependant on peut aussi vouloir placer un IDS tel que Sniff_mod dans une DMZ et donc dans un environnement sans filtrage ou presque d'où la necessité d'une gestion TCP/IP avancée. Une fonction intéressante de Sniff_mod est sa capacité à réduire le nombre de signatures à vérifier - et donc d'accélerer d'autant le pattern matching - en ne tenant pas compte des vulnérabilités auxquelles le réseau ou les systèmes ne sont pas sensibles. Ceci s'effectue à l'aide d'une corrélation entre la base de données de signatures Sniff_mod et les rapports d'audit de Nessusd/Trithème. A la suite de cette corrélation, le nombre de signatures à tester peut être ajustée et l'efficacité optimisée d'autant. Notez aussi que bien que Trithème n'effectue pas lui-même les fonctions avancées de pattern matching et de data mining, étant basé sur la libpcap et donc sur BPF, il effectue une première sélection évidente à partir des expressions régulières BPF sur la destination, la source ou encore le type de connexion. Sniff_mod comme l'ensemble de Trithème est basé pour ses opérations de capture et de construction de paquets sur le duo libpcap/libnet (voir section 2.2.3.). Pour compliquer un minimum la tâche d'un intrus le bit IFF_PROMISC est effacé par Log_mod permettant une relative discrétion dans l'écoute même si un utilitaire comme Sentinel pourra le détécter par une requête DNS ou ARP. Berkeley Packet Filter Man Page http://www.gsp.com/cgi-bin/man.cgi?section=4&topic=bpf Berkeley Packet Filter+ http://www.cs.berkeley.edu/~abegel/sigcomm99/bpf+.ps Libpcap http://www.hsc.fr/ressources/breves/pcap.html 2.2.1. Qu'est ce que la Misuse Detection ? Cette approche tente de créer des règles décrivant l'utilisation non sollicitée connue (basée sur des pénétrations ou activité précédentes qui exploitaient des faiblesses connues) plutôt que de décrire l'utilisation "normale" historique. Des règles peuvent être écrites pour identifier un événement auditable simple qui représente seul une menace à la sécurité de système, ou une séquence d'opérations qui représentent un scénario prolongé d'intrusion. L'efficacité des règles de misuse detection fournies dépend du mainteneur du système et de sa capacité à se tenir au courant des dernières vulnérabilités. La détection d'abus peut être mise en application en développant des systèmes experts de règles, des systèmes d'analyses basés sur des modèles de raisonnement ou de transition d'état, ou encore des réseaux neuronaux. Les systèmes experts peuvent être employés pour coder des signatures misuse aussi bien que des règles d'implication if-then. L'analyse de signature se concentre sur la définition des descriptions et des exemples spécifiques du comportement d'attaque type à remarquer. Les signatures décrivent un attribut d'une attaque ou d'une classe d'attaques, et peuvent exiger l'identification des séquences d'évènements. Une base de données de signatures et d'information misuse offre la capacité d'entrer rapidement des attaques nouvellement identifiées avant de les subir sur le système ou réseau cible. Artificial Neural Network for Misuse Detection http://secinf.net/info/ids/nn-idse/ 2.2.2. Qu'est ce qu'une signature et le Pattern Matching ? Une signature d'intrusion est habituellement définie comme une séquence d'évènements et de conditions dénotant une tentative d'intrusion. Les conditions définissent le contexte dans lequel la séquence devient une intrusion. Les patterns ne doivent pas entrer en conflits, être assez généraux pour détecter et capturer des variations de la même attaque de base, et enfin assez simple pour permettre la comparaison et la capture de manière automatiser. Les signatures en misuse detection sont habituellement détecter au sein du flux réseau par l'intermédiaire de clé de corrélation. La pattern matching est une technique utilisé en misuse et model-based detection heritée des expressions regulières. Elle consiste à analyser des séquences de chaînes de caractères à la recherche d'une correpondance au sein d'une base de connaissance. En misuse detection, cela peut signifier chercher des corrélations entre les payloads des paquets transitant au sein du réseau et la base de données de signatures du système de détection d'intrusion. En élevant le niveau d'absraction, on peut appliquer le pattern matching aux approches model-based et d'analyse de transition d'état. Dans ces modèles, on peut intégrer des correspondances sémantiques permettant de detecter des séquences d'évènements donnant lieu à une attaque et ne plus seulement se baser sur une unique signature. Sniff_mod utilise le pattern matching pour rechercher des correspondances de séquence entre le flux réseau et sa base de connaissance de vulnérabilités. De plus en alliant ces capacités d'analyse à une capacité de recherche et de corrélation à plus long terme sur son data warehouse, Trithème peut également définir et détecter des scénarios d'attaques, alliant ainsi une détection linéaire et non linéaire. Sequence Comparison http://www-igm.univ-mlv.fr/~lecroq/seqcomp/ Exact String Matching Algorithms http://www-igm.univ-mlv.fr/~lecroq/string/ A Pattern Matching Model for Misuse Intrusion Detection http://www.raptor.com/lib/ncsc.ps An Application of Pattern Matching in Intrusion Detection http://www.raptor.com/lib/9413.ps Pattern Matching et Détection d'Intrusion http://eleves.mines.u-nancy.fr/~huin/fake/filtres.html Mining in a Data Flow Environment http://www.cs.umbc.edu/cadip/docs/NetworkIntrusion/kdd99.ps arachNIDS http://www.whitehats.com/ids/ XML-Signatures Syntax and Processing  http://www.w3.org/TR/xmldsig-core/ 2.2.3. Qu'est ce que libpcap et libnet ? Pour l'ensemble du travail de manipulation de paquets, Sniff_mod utilise 2 librairies C à la qualité éprouvée : libpcap et libnet. Libpcap est une API portable et basée sur Berkeley Packet Filter (BPF) permettant la capture facile de paquet au niveau utilisateur et de manière indépendante du système. Elle inclut plusieurs fonctions comme la collection statistique, le monitoring ou le debugging. Libnet quant à elle est une collection de routine facilitant la construction de paquets. Ces 2 librairies permettent d'automatister, d'accélerer et de faciliter l'ensemble des manipulations de paquets de Sniff_mod et ce de manière standard. Elles permettent également d'améliorer la portabilité en se passant des interfaces réseau spécifiques à chaque système. TCPdump/Libpcap http://www.tcpdump.org/ The Libnet Reference Manual http://www.packetfactory.net/libnet/manual/ LBNL's Network Group Research http://ee.lbl.gov/ 2.3. Qu'est ce que Log_mod ? Log_mod regroupe les capacité de détection d'intrusion host-based, behavior-based et par détection d'anomalies. Un agent log_mod est basé sur chacune des machines du réseau et effectue un ensemble de tâche de monitoring, de logging et de profiling auprès de chacun des utilisateurs. Il collecte ainsi les fichiers logs système, firewall ou routeur spécifiés par l'administrateur et le redistribue à Data_mod pour leur analyse à la recherche de séquence correspondant à une signature d'attaque ou à un comportement en dehors du profil attribué à l'utilisateur. Ceci est la 2ème capacité de Log_mod : le monitoring et profiling comportementale. Il consiste à logger puis schématiser l'ensemble de l'activité d'un utilisateur ou groupe d'utilisateurs afin de lui assigner un profil d'activité en dehors duquel tout activité sera considerée comme une anomalie et suivra le barème de gravité jusqu'à déclencher une alerte auprès de l'opérateur par l'intermédiaire du Manager. Un profiling est également effectué sur les ressources système et réseau ainsi que sur les applications privilégiées afin de détecter une compromission ou un rootage à partir d'une machine ou d'une application. Sa dernière fonction est la vérification d'intégrité système ou profiling statique réalisée périodiquement par comparaison à une image du système ou d'une liste de fichiers (sous Unix, tout est fichier) séléctionnés par l'admin. Une corrélation est effectuée entre les résultats de la comparaison avec l'image et le profil de l'utilisateur du système. Chaque modification détectée par Log_mod sur le système qui sort du profil correspondant à ce système et à son utilisateur est considérée comme une anomalie et suit à son tour le barème d'alerte jusqu'à l'opérateur. L'ensemble des méthodes de profiling sont définies sous formes de règles facilement applicables et extensibles par l'administrateur et réévaluée assez souvent pour intégrer des modifications de l'activité et limiter les faux positifs à la prochaine vérification de l'administrateur. Bien sûr, pour éviter d'intégrer aux profils de comportement une activité non appropriée, des règles d'exclusion sont aussi mise en place en étroite collaboration avec la verification d'intégrité et le sequence matching. Dans le dernier cas particulier du sequence matching il faut par exemple être capable de lire et d'interpréter même des connexion distantes. Or ceci faisant parti de la couche application, il nécessiterai une capacité de décodage d'un nombre phénoménal de protocoles. Dans ce cas-ci l'approche host-based s'avère très utile puisque nous pouvons capturer le flux non pas au niveau réseau mais au niveau application après son décodage comme un simple flux d'entrée/sortie. Universal Format for Logger Messages http://www.hsc.fr/ressources/veille/ulm/draft-abela-ulm-05.txt Automated Detection of Vulnerabilities in Priviliged Programs by Monitoring http://seclab.cs.ucdavis.edu/papers/kfl94.ps Sequence Matching and Learning in Anomaly Detection for Computer Security http://citeseer.nj.nec.com/lane97sequence.html Network Intrusion Detection : Evasion, Traffic Normalization, and End-to-End Protocol Semantics http://www.aciri.org/vern/papers/norm-usenix-sec-01-html/ 2.3.1. Qu'est ce que l'Anomaly Detection ? La détection d'anomalie compare l'activité observée aux profils normaux prévus d'utilisation qui peuvent être développés pour des utilisateurs, des groupes d'utilisateurs, des applications, ou l'utilisation de ressource de système. Des audits d'enregistrements d'événement qui tombent en dehors de la définition du comportement normal sont considérés comme des anomalies. La détection répond aux limitations de l'approche network-based en permettant la détection d'attaques inconnues ou bien la compromission de comptes d'utilisateurs privilègiés. - Le monitoring par seuils détermine des valeurs définissant un comportement acceptable (par exemple, moins d'un certain nombre de tentatives de connexion échouées par période de temps). Les seuils fournissent une définition précise et compréhensible du comportement inacceptable et peuvent utiliser d'autres équipements sans compter les audits de log. Malheureusement il est souvent difficile de caractériser le comportement intrusif seulement en termes de seuils correspondant aux enregistrements disponibles. Il est difficile d'établir les valeurs de seuils et les intervalles appropriés de temps au-dessus desquelles contrôler. L'approximation peut avoir comme conséquence une fréquence élevée de faux positifs de faux négatifs au sein d'une population d'utilisateur non-uniforme. - Le profiling d'activité utilisateur met à jour les différents profils de travail auxquels on s'attend que l'utilisateur adhère à l'avenir. Lorsque l'utilisateur change ses activités son profil prévu de travail est mis à jour. Quelques systèmes tentent l'interaction à court terme contre des profils à long terme ; le premier pour capturer les configurations de travail changeantes récentes, le dernier pour fournir une perspective sur de plus longues périodes d'utilisation. Cependant il reste difficile de profiler une base irrégulière et/ou dynamique d'utilisateur. Les profils trop largement définis permettent à n'importe quelle activité de passer. On peut aussi lui adjoindre le sequence computing matching qui consiste en un logging des commandes entrées par un utilisateur afin d'effectuer une corrélation avec son profil comportemental et détecter un comportement non autorisé - Le profiling de groupe de travail affecte des utilisateurs à des groupes de travail spécifiques qui dénotent une configuration de travail commune et par conséquent un profil commun. Un profil de groupe est calculé à partir des activités historique du groupe entier. On s'attend à ce que différents utilisateurs dans le groupe adhèrent au profil de groupe. Cette méthode peut considérablement réduire le nombre de profils devant être mis à jour. D'autre part un utilisateur simple a moins de possibilité d'élargir le profil auquel il doit se conformer. Il y a peu d'expérience opérationnelle avec la séléction de groupes appropriés (i.e., les utilisateurs avec des professions semblables peuvent avoir des habitudes tout à fait différentes de travail). La création de profils individuels à partir de la création de groupes peut être une complication necessaire pour les utilisateurs qui ne s'adapte pas proprement dans les groupes définis. - Le profiling de ressources surveille l'utilisation au niveau système de ressources comme des comptes, des applications, des supports de stockage, des protocoles, des ports de transmissions, etc., et développe un profil historique d'utilisation. On s'attend à ce que l'utilisation de ressource - illustrant l'utilisation de la communauté d'utilisateurs des ressources système en général - adhère au profil de ressources de système. Cependant, il peut être difficile d'interpréter la signification des changements de l'utilisation système globale. Le profiling de ressources est indépendant de l'utilisateur, permettant potentiellement la détection de collaboration volontaire ou non avec un intru. - Le profiling d'exécutables est destiné à surveiller l'utilisation d'executables de ressources système, particulièrement ceux dont l'activité ne peut pas toujours être rattachée à un utilisateur particulier. Trojans, virus, worms, backdoors, bombes logiques et autres attaques logiciels, sont détectéés en profilant la manière dont des objets système tels que des fichiers et des periphériques sont normalement employés, non seulement par des utilisateurs, mais également par d'autres composants système. Dans la plupart des systèmes conventionnels, par exemple, un virus hérite de tous les privilèges de l'utilisateur exécutant le logiciel infecté. Le logiciel n'est pas limité par le principe de moindre privilège seulement aux privilèges requis pour s'exécuter correctement. Cette architecture de virus permet de modifier et d'infecter des parties totalement indépendantes du système. Le profiling d'exécutable independemment de l'utilisateur peut également servir à détecter des utilisateur collaborant avec un intrus. - Le profiling statique d'activité met à jour des profils d'utilisation seulement périodiquement selon la décision de l'administrateur. Ceci empêche des utilisateurs d'élargir lentement leur profil en introduisant progressivement les activités anormales ou déviantes qui sont alors considérées normales et incluses dans le calcul adaptatif du profil de l'utilisateur. L'exécution des mises à jour de profil peut être au choix sur la totalité de la base de profil ou, de préférence, configurable pour s'adresser à différents sujets. Les mises à jour contrôlées par l'administrateur permettent la comparaison des profils d'utilisateur discrets aux différences entre le comportement d'utilisateur ou les changements du comportement d'utilisateur. Malheureusement ces profils doivent être larges et peu sensibles ou fréquemment mis à jour. Autrement si les configurations de travail d'utilisateur changent de manière significative, beaucoup de faux positifs résulteront. Cette approche exige également une surveillance étroite de la part de l'administrateur qui doit mettre à jour des profils en réponse aux faux positifs, et s'assure que les changements représentent des modifications légitimes d'habitude de travail. - Le profiling adaptatif d'activité gère automatiquement les profils d'activité pour refléter l'activité (acceptable) actuelle. Le profil d'activité est sans interruption mis à jour pour refléter l'utilisation récente du système. Le profiling peut être sur un utilisateur, un groupe, ou un application. Le profiling adaptatif d'activité peut permettre à l'administrateur d'indiquer si l'activité actuelle est : 1) intrusif, dans l'état actuel ; 2) non intrusif, et devienne une mise à jour du profil afin de refléter cette nouvelle configuration d'activité, ou 3) non intrusif, mais d'être ignorés comme aberration dont la prochaine occurrence sera encore d'intérêt. Une activité qui n'est pas marquée comme intrusive normalement est automatiquement introduite dans un mécanisme de mise à jour de profil. Si ce mécanisme est automatisé, l'administrateur ne sera pas dérangé, mais les profils d'activité peuvent changer et continuer à changer sans connaissance ou approbation des administrateurs. Le profiling basé sur des règles adaptatives diffère d'autres techniques de profiling en capturant les configurations historiques d'utilisation d'un utilisateur, d'un groupe, ou d'une application sous forme de règles. - Des transactions décrivant le comportement actuel sont comparées avec l'ensemble de règles développées, et des changements du comportement/règle prévu noté. Par opposition aux systèmes basés sur les règles d'abus, aucune connaissance experte antérieure des vulnérabilités de sécurité du système surveillé n'est exigée. Des règles "d'utilisation normale" sont produites par l'outil dans sa période de formation. Cependant, la formation peut être lente comparée aux méthodes de profilage statistiques. En outre, pour être pertinent, un vaste nombre de règles doit être mis à jour avec les issues inhérentes d'exécution. La gestion des outils adoptant cette technique exigent une formation étendue, particulièrement si des règles spécifiques à un site doivent être développées. Intelligent Profiling by Example http://sibyl.www.media.mit.edu/people/sibyl/projects/apt/iui2001_profile.pdf 2.4. Qu'est ce que Nessud/Trithème ? Nessus est un scanner de vulnérabilité permettant de tester un ou plusieurs systèmes à la recherche de vulnérabilités potentielles. Il se place donc dans la lignée du logiciel SATAN mais se caractérise par plusieurs fonctionnalités : - Une architecture client/serveur composé d'une part de Nessusd qui effectue les tests de sécurité et d'autre part le client qui est l'interface utilisateur. Ces 2 parties peuvent fonctionner sur des systèmes différents permettant de scanner un réseau entier depuis un serveur tout en contrôlant Nessus depuis une console. Des clients sont disponible pour X11, Win32 et Java. Par ailleurs Nessus peut également fonctionner de manière automatiser ou en tâche de fond. Il supporte également le scanning en local d'un hôte ou en remote de plusieurs, tout dépendant des ressources de la machine exécutant Nessusd. - Les tests de sécurité sont écrit sous la forme de plug-ins externes permettant d'écrire facilement de nouveau tests en NASL (Nessus Attack Scripting Language) - un langage dérivé du C spécialement destiné à l'écriture de test - ou en C sans avoir besoin d'être un excellent programmeur ou de connaître précisément le fonctionnement de Nessusd. Ce système permet d'obtenir une base de vulnérabilité très à jour et updatée très souvent. Au 26/04/2001, Nessus comptait 643 plug-ins. A leur initialisation, chaque plugin déclare : - son type (ACT_SCANNER, ACT_GATHER_INFO, ACT_ATTACK ou ACT_DENIAL) - le port sur lequel il agit (ie: 139 ou alors notation symbolique 'Services/www') - les plugins dont il dépend (ie: "je dépends absolument de smb_login.nasl") - les entrées de la Knowledge Base dont il a besoin (ie: "il me faut un mot de passe SMB") - les entrées de la KB qui font qu'il ne se lancera pas (ie: "si la machine en face est un unix, ne me lance pas"). La KB, c'est la "Knowledge Base" ou base de connaissance, autour de laquelle s'articule toute la communication inter plugins. Les plugins sont triés par type, puis par dépendance et sont executés dans cet ordre. Lors de son execution, un plugin peut rentrer une information dans la KB. Il peut s'agir du fait que que le port 123 soit ouvert, ou alors que le mot de passe foobar fonctionne, etc... Tout est noté un peu comme dans la base de registre de windows (mais avec les slashes dans l'autre sens). On y trouve aussi des détails sur les protocoles derrière. Nessus ne raisonne pas tellement en terme de ports mais de services. Un plugin (find_service.nes) fait la liaison port <-> service et met tout ca dans la KB. On y trouve par exemple : "Services/www" pour le web. Ensuite, les plugins ne font pas open_sock_tcp(80) mais open_sock_tcp(get_kb_item("Services/www")). Une entrée donnée peut avoir plusieurs valeurs, au quel cas le script sera ré-executé avec des valeurs de retour à get_kb_item() différentes à chaque fois, ce qui permet au moment de l'écriture du script, de ne pas faire des while, des for, etc... On écrit comme si une entrée n'avait qu'une valeur, meme si ce n'est pas forcément vrai. De plus Nessus ne tient pas compte des ports assignés mais bien du services écoutant effectivement au port testé permettant la reconnaissance intelligente de service. Ceci permet également à Nessus de tester une machine faisant fonctionner plusieurs serveurs du même type à des ports différents (i.e. 2 serveurs web aux ports 80 et 8080). Vous pouvez également sélectionner les tests que vous souhaitez effectuer ou pas. Si un plugin met la valeur spéciale "Host/dead" dans la KB, alors le test s'arrete aussitot (c'est utilisé pour les DoS). Pour finir, Nessus dispose d'une capacité de rapport facilement exportable dans plusieurs formats, vous indiquant de quelle manière vous protégez des vulnérabilités détectées. Nessusd/Trithème quant à lui est un module Trithème destiné à intégrer le serveur Nessusd à l'IDS Trithème en participant directement au développement de Nessus et en facilitant son intégration par le développement de patchs. Les améliorations avaient également été envisagé sous forme de plug-ins NASL ou C mais l'architecture de Nessus ne permet pas autant de flexibilité. De plus Nessusd sera intégré à l'interface de Trithème sous la forme d'un panel. Les améliorations apportées devraient être : - Capacité de corrélation entre la KB Nessus et le Data Warehouse Trithème permettant d'adapter très précisément les signatures et scénarios d'attaque à la menace qui pèse sur le réseau et ainsi accélerer le fonctionnement de l'IDS. Cette corrélation pourrait être effectuée à partir des entrées CVE attachées aux vulnérabilités et signatures. - Capacité d'audit des logiciels par audit du code source ou désassemblage à la recherche de vulnérabilités de type buffer overflow ou format strings. - Intégration des rapports Nessus aux rapports Trithème permettant une cartographie détaillée de l'état de la sécurité du réseau ou système. L'intégration à l'interface devrait également permettre l'aide à la décision à la suite de la découverte d'une vulnérabilité. - Clonage de serveurs Nessusd en fonction du besoin de la même manière que les modules et agents Trithème. Nessus Documentation http://www.nessus.org/documentation.html A Static Vulnerability Scanner for C and C++ Code http://www.cigital.com/papers/download/its4.pdf Improving the security of your site by breaking into it http://www.porcupine.org/satan/admin-guide-to-cracking.html System Audit Standards http://www.jipdec.or.jp/security/system-audit.htm Common Vulnerabilities and Exposure http://cve.mitre.org/ ICAT Metabase http://icat.nist.gov/icat.taf (Merci à Renaud Deraison pour les toutes les précisions concernant Nessus) 2.5. Qu'est ce que Data_mod ? Data_mod regroupe l'ensemble des fonctions d'analyse, de stockage et d'extraction de données de Trithème. Il fournit une capacité distribuée - et donc proportionnelle à l'échelle du réseau - d'analyse, de corrélation et de recherche d'informations au sein des données brutes et des rapports/alertes. Les données brutes sont les données recueillie par les différents senseurs que sont Sniff_mod et Log_mod. Elles sont stockées dans une operationnal datamart permettant un accès rapide aux informations pour analyse et recherche. Les données analysées sont transmises au data warehouse de Trithème qui regroupe la base de connaissance de Trithème et permet la génération de rapports ainsi que des corrélations à plus long terme. La combinaison des différents operationnal datamart constitue le data warehouse de Trithème. Il regroupe en plus des données collectées, les différentes informations nécessaire au fonctionnement de Trithème que sont les signatures de Sniff_mod, les tests de vulnérabilités de Nessud/Trithème, les modèles comportementaux et les images de disque des hôtes de Log_mod, et les scénarios d'attaque représentés par des clés de corrélation entre ces différentes données. La technologie utilisée pour le stockage et la consultation de ces informations est MOLAP (Multidimensionally On Line Analytical Processing) permettant une mise en évidence des corrélations et dépendances de manière multidimensionnelle par opposition aux méthodes relationnelles habituellement utilisées. Data_mod est aussi chargé de l'extraction des données pour le Manager. L'ensemble de ces technologies sont destinées à faciliter et accélerer la prise de décision par l'opérateur du système en fournissant une vision exhaustive d'un évènement par l'intermédiaire des différentes clés de corrélation et de classement - telles que l'adresse source, l'addresse de destination, le temps, la signature, la fréquence, le senseurs, la corrélation à long terme et multidimensionnelle etc... - permettant une indexation et une recherche approfondie et accélérée. Pour permettre une personnalisation de la corrélation des règles d'association déterminant quels type de données, clés de corrélation et clés de classement doivent être appliqués pour la recherche et l'analyse d'information. _ | Senseur | Agent Trithème | _| | _ | | Operationnal Datamart | Manager Trithème | _| | _ | | Agent Data_mod | Agent Analyse | Trithème | _| | _ | | Data Warehouse | | | Manager | | | | Trithème Opérateur <------------- Manager | Reporting | _| L'analyse, l'extraction et la corrélation de données sont effectués par des "agents experts" Data_mod de manière distribuée en reprenant des techniques statistiques telles que les modules statistiques, les méthodes récursives non linéaires ou encore le raisonnement basé sur la mémoire. Pour l'ensemble des capacité de pattern matching avancé, de comparaison de séquence et simplement de recherche et de data mining dans la base de données, toute une série d'algorithmes de string/pattern matching ont été implémenté et peuvent donc être appliqués de manière aléatoire ou en fonction du type de données - déterminé par la source/senseur - permettant d'incrémenter l'efficacité et la capacité de l'extraction de données sur des chaînes de caractères exactes mais aussi approximative. Parmis les algorithmes retenus on trouve Landau-Viskhin, Galil-Giancarlo, Not So Naive, Apostolico Giancarlo, Galil-Seiferas, Barry-Ravindran, Optimal Mismatch ou encore Turbo Reverse Factor. 2.5.1. Qu'est ce que le Data Mining et le Knowledge Discovery ? Le Data Mining correspond à l'ensemble des techniques et des méthodes qui à partir de données permettent d'obtenir des connaissances exploitables. Son utilité est grande dès lors qu'une organisation possède un grand nombre d'informations stockées sous forme de bases de données. Plus particulièrement, une distinction plus précise s'établit autour du concept de KDD (Knowledge Discovery in Database) et celui de Data Mining. En effet, ce dernier n'est que l'une des étapes du processus de KDD correspondant précisément à l'extraction des connaissances à partir des données. Avant de réaliser une analyse Data Mining, il faut donc procéder à l'élaboration d'un Data Warehouse. Le Data Mining est utile lorsque les volumes de données sont trop importants pour un traitement à l’aide de techniques d’analyses classiques ou que l’utilisateur final n’est pas un expert en analyse ou en statistique métier. Des nombreux algorithmes et techniques existent pour le data mining : - Modules Statistiques Tandis que dans la majorité des dernières versions des modules statistiques sont bien connus les méthodes statistiques traditionnelles sont complétées par quelques éléments de data mining, leurs méthodes principales d'analyse de données demeurent de nature classique : corrélation, régression, et analyses factorielles et d'autres techniques de ce genre. De tels systèmes ne peuvent pas déterminer la forme des dépendances cachées dans les données et exiger que l'utilisateur fournisse ses propres hypothèses qui seront évaluées par le système. Un des inconvénients principaux de tels systèmes est qu'ils ne permettent pas à l'analyse de données d'être exécutée par l'utilisateur qui n'a pas une formation complète en statistiques. Un utilisateur "of-the-shell" doit passer par plusieurs moi de cours spéciaux pour pouvoir utiliser ces systèmes plus ou moins intelligemment. Un autre inconvénient des modules statistiques est que pendant l'exploration des données l'utilisateur doit exécuter à plusieurs reprises un ensemble d'opérations élémentaires. Les outils pour l'automatisation des processus n'existent pas, ou exigez en la programmation dans langage interne. Ces dispositifs rendent les modules statistiques trop maladroits et inefficaces pour résoudre des problèmes réels complexes. - Méthodes récursives non linéaires Ces méthodes sont basées sur la recherche de dépendances à une variable cible à l'égard d'autres variables sous forme de fonction d'une certaine forme prédéterminée. Par exemple, dans l'implémentation la plus réussie des algorithmes de ce type, la méthode comptable d'attribut de groupe, une dépendance est recherchée sous forme de polynômes. De telles méthodes doivent fournir des solutions d'une plus grande signification statistique que les réseaux neuronaux. Une formule obtenue, un polynôme, est plus appropriée à l'analyse et à l'interprétation en principe (en réalité elle est toujours habituellement trop complexe pour cela). Ainsi cette méthode a de meilleures chances de fournir les solutions fiables dans des applications spécialisées. - Programmation Evolutive Actuellement c'est la plus jeune et la plus prometteuse branche du data mining. L'idée fondamentale de la méthode est que le système formule automatiquement des hypothèses au sujet de la dépendance de la variable cible à l'égard d'autres variables sous forme de programmes exprimés en langage de programmation interne. En utilisant un langage de programmation universel l'approche s'assure que n'importe quelle dépendance ou algorithme peut être exprimée en ce langage en principe. Le processus de production des programmes internes (hypothèses) est organisé comme une évolution dans le monde de tous les programmes possibles (c'est une sorte de réminiscence de la méthode d'algorithmes génétiques). Quand le système trouve une hypothèse décrivant la dépendance observée raisonnablement bien, il commence à présenter de diverses légères modifications à ce programme et choisit les meilleurs programmes fils réalisés par ce processus, ceux qui améliorent l'exactitude de la prévision le plus. De cette façon le système développe un certain nombre de lignées génétiques de programmes qui se concurrencent l'un l'autre dans l'exactitude d'exprimer la dépendance recherchée. Quand le meilleur programme (hypothèse) avec l'exactitude désirée est obtenu, un module spécial du système traduit la dépendance découverte du langage interne en une forme explicite facilement comprise par l'humain : formules mathématiques, tables de prévision, etc... Ceci fournit à l'utilisateur une perspicacité et un contrôle très important de la dépendance obtenue, et permet la visualisation graphique des résultats. Le contrôle de la signification statistique des résultats obtenus est exécutée par un certain nombre de méthodes statistiques modernes pertinentes, par exemple, une méthode de test aléatoire de données. - Raisonnement basé sur la mémoire (Memory Based Reasoning) L'idée principale qui sous-tendant cette méthode est très simple. Pour prévoir une situation future, ou pour prendre une décision correcte, de tels systèmes trouvent les analogies passés les plus proches de la situation actuelle et choisissent la même solution qui était la bonne dans ces situations passées. C'est pourquoi cette méthode s'appelle également la méthode du plus proche voisin (nearest neighbor). Les systèmes MBR montrent des résultats plutôt bons dans des problèmes énormément divers. D'autre part, leur plus grand inconvénient est que ces systèmes ne créent aucuns modèles ou règles récapitulant l'expérience précédente. Leurs prévisions sont basées sur le traitement de l'ensemble des données historiques disponibles, et il est ainsi impossible de dire quels facteurs spécifiques ont influencé la prévision d'un système MBR. - Algorithmes Génétiques À proprement parler, l'analyse de données n'est pas la zone d'application principale des algorithmes génétiques. Ils devraient être vus plutôt comme technique puissante pour la résolution de divers problèmes combinatoires ou d'optimisation. Néanmoins, les algorithmes génétiques sont parmi les instruments modernes standards pour le data mining, et ils sont ainsi inclus ainsi dans ici. Le nom de la méthode dérive de sa similitude au processus de la sélection normale. Laissez le problème trouver une solution à un problème qui serait le plus optimal du point de vue d'un certain critère. Et laissez chaque solution être exhaustivement décrite par un certain ensemble de paramètres numériques ou non numériques. On peut penser à ce positionnement en comme un ensemble de chromosomes déterminant des qualités d'un "organisme" - une solution du problème. Après cette analogie, les valeurs des paramètres déterminant une solution correspondent aux gènes. Une recherche de la solution optimale est semblable au processus de l'évolution d'une population d'organismes, où chaque organismes est représentée par un ensemble de ses chromosomes. Cette évolution est pilotée par trois mécanismes : d'abord, sélection du plus fort - ces ensembles de chromosomes qui caractérisent les solutions les plus optimales ; en second lieu, accouplement croisé - production de nouveaux organismes en mélangeant des ensembles de chromosomes et ensembles de parent de chromosomes ; et troisièmement, mutations - changements accidentels des gènes dans quelques organismes de la population. Après qu'un certain nombre de nouvelles générations établies avec l'aide des mécanismes décrits on obtient une solution qui ne peut pas être améliorée plus. Cette solution est considérée comme finale. Les algorithmes génétiques ont 2 points faibles. D'abord, la manière même de formuler le problème prive de n'importe quelle occasion d'estimer la signification statistique de la solution obtenue. En second lieu, seul un spécialiste peut élaborer un critère pour la sélection de chromosome et formuler le problème pertinemment. Ainsi des algorithmes génétiques devraient être considérés actuellement plus comme instrument pour la recherche scientifique plutôt que comme outil pour l'analyse de données pratique générique. - Réseaux Neuronaux C'est une classe des systèmes divers dont l'architecture dans une certaine mesure imite la structure du tissu neural fait de neurones séparés. Une des architectures les plus répandues, perceptron multicouche avec la propagation récursive des erreurs, émule le travail des neurones incorporés dans un réseau hiérarchique, où l'entrée de chaque neurone de la prochaine couche (plus étroite) est reliée aux sorties de tous les neurones de la couche (plus large) précédente. Des données analysées sont traitées comme paramètres d'excitation de neurone et alimentent les entrées de la première couche. Ces excitations des neurones inférieurs d'une couche sont propagées aux prochains neurones de couche, étant amplifié ou affaibli selon des poids (coefficients numériques) attribués aux connexions intraneural correspondantes. Comme résultat final de ce processus, le neurone simple, comportant la couche le plus élevé de neurone, saisit une certaine valeur (force d'excitation) qui est considérée comme prévision/réaction du réseau entier aux données traitées. Afin de faire à des prévisions signicatives un réseau neural doit d'abord être entrâiné avec des données décrivant les situations précédentes pour lesquelles, des paramètres d'entrée et leurs réactions correctes sont connus. La formation consiste à choisir des poids attribués aux connexions intraneural qui fournissent la proximité maximale des réactions produites par le réseau aux réactions correctes connues. Cette approche s'est avérée pertinente dans les problèmes d'identification d'image. Cependant, l'expérience prouve qu'elle n'est pas toujours appropriée par exemple aux applications sérieuses. Il y a plusieurs raisons de cette difficulté. D'abord, les réseaux neuronaux réels qui sont établis pour analyser un système compliqué, tel que les marchés financiers, doivent être les systèmes fortement complexes eux-mêmes. Ils incluent des douzaines de neurones avec une centaine de connexions entre eux. En conséquence, le nombre de degrés de liberté du modèle créé de prévisions (ce sont des poids de toutes les connexions entre les neurones de réseau) devient souvent plus grand que le nombre d'exemples (enregistrements séparés) qui avaient été employés pour former le réseau. Ceci prive la prévision de n'importe quels sens et valeur : le réseau peut facilement "être formé" pour expliquer un choix de quelques données aléatoirement produites. Des expériences d'application les réseaux neuronaux aux prix de valeurs boursières indique qu'ils pourraient idéalement expliquer toutes les fluctuations dans les données employées pour former le réseau mais ont échoué une fois appliqués aux prévisions des valeurs. Le deuxième inconvénient est l'obscurité des modèles de prévisions représentés par un réseau neural qualifié. Cette difficulté est également étroitement reliée à la complexité de la structure de réseau neural : la connaissance reflétée en termes de poids d'un couple de cents connexions intraneurales ne peuvent pas être analysées et interprétées par un humain. Data Mining Approaches for Intrusion Detection http://www.cs.columbia.edu/~sal/hpapers/USENIX/usenix.html A Data Mining Framework for Adaptive Intrusion Detection http://citeseer.nj.nec.com/187998.html PMML 1.0 - Predictive Model Markup Language http://www.dmg.org/public/techreports/pmml-1_0.html 2.7. Qu'est ce que ICE_mod ? ICE_mod représente la partie 'Response' de Trithème. Concretement il regroupe l'ensemble des fonctions de contre mesures applicables aussi bien au niveau réseau qu'au niveau local pour répondre à une attaque. Dans la logique de développement il répond à un besoin de séparer toutes ces mesures pour simplifier le code du reste des modules. On peut ainsi penser qu'il fait doublet avec Log_mod de part son emplacement prépondérant sur un maximum de machines du réseau du moins celles servant de routeur filtrant ou de border firewall, ou encore de senseur avancé au sein d'une DMZ ou simplement de machines critiques nécessitant un degré encore plus élevé de sécurité. ICE_mod toi ainsi fournir des contre-mesures haut niveau. Tout d'abord, Trithème introduit la modification dynamique de la configuration réseau notamment au niveau du filtrage dans un but d'islanding et de création de DMZ autour d'une machine et ceci par un accès en écriture aux fichiers de configuration réseau disponible. Cette mesure devrait bien sûr être prise de préférence sur des systèmes dédiés au rôle de firewall. Ensuite Trithème peut appliquer le throttling ou ralentissement des ressources disponibles à l'attaquant par exemple en limitant les ressources matérielles, ou en réduisant le temps avant timeout. De manière optionnelle et de préférence sur une machine unique et dédiée prête à recevoir une éventuelle réponse d'un attaque, ICE_mod doit pouvoir utiliser le back tracing ou le piège introduisant la possibilité de rediriger un attaquant vers un honeypot ou honeynet pour le surveiller ou encore la capacité d'effectuer un port mapping et/ou d'OS fingerprinting considéré comme légal afin de confondre et d'identifier immédiatement un attaquant si les paquets ne sont pas spoofés par exemple. Trithème doit également pouvoir à des attaques simples répondre simplement : par exemple en incluant une capacité de forgeage d'un RST Killer ou de deny automatique à certaines tentatives de scanning, de spoofing ou usurpation etc. Trithème malgré son architecture distribué et hybride incluant donc l'approche host-based reste cependant vulnérable à quelques techniques d'attaques ou de reconnaissance réseau liées à la mauvaise gestion des paquets par l'IDS et surtout la non-connaissance de la gestion de certains paquets malformé par le système destinataire. Normalement en possédant un agent sur chaque hôte, Trithème doit pouvoir adapter son filtrage au système hôte et éviter les attaques liées à la malformation spécifique de paquets. Cependant Trithème est exclusivement compatible POSIX donc il doit envisager l'attaque de systèmes différents dont il ne connaîtra pas le comportement de la pile TCP/IP. Trithème reprend comme solution à ce problème une idée de Vern Paxson : - la normalisation du trafic. Cette approche présentée récemment necessite l'implentation par les agents Trithème situés sur des points filtrant d'un plug-in permettant la normalisation du trafic TCP/IP. Ainsi une série de règles est définie de manière similaire à un firewall mais destinée à refuser systèmatiquement tous paquets non conformes, non reconnus et ce par défaut ou depuis la console analyste. Par exemple toute tentative d'attaque liée à la fragmentation, au TTL ou aux numéros de séquence se voient éliminés par la normaliseur de trafic. La majorité des attaques directes sur les IDS ou les capacités de network mapping ou d'OS fingerprinting sont ainsi supprimées et l'IDS peut se limiter à une étude simple et normalisée du trafic à la recherche d'attaques réelles. La dernière fonction de ICE_mod mais non des moindres est la classique mais primordiale génération dynamique de rapports à partir des résultats d'analyse, d'extraction de données et de corrélation de Data_mod - entreprosés dans le Data Warehouse - suivie d'une notification à l'analyste/opérateur en suivant le barème de sévérité célébre en détection d'intrusion : severity = (criticality + lethality) - (system countermeasures + network countermeasures) avec éventuellement une personnalisation par l'opérateur en fonction du timestamp -- les entreprises ne travaillent pas la nuit, mais surtout du type d'attaque détectée. Tout ceci avec une présentation claire - en tout cas beaucoup plus claire qu'un simple fichier log - avec timestamp, port et adresse source, port et adresse de destination, attaque détectée, et une corrélation statistique à court et long terme en fonction des paramètres cités plus haut mais également en fonction du service attaqué avec une corrélation de ses vulnérabilités découvertes par Nessus et éventuellement la nécessité d'une mise à jour des tests. 2.7.1. Qu'est ce que les Intrusion Countermeasures ? Les Intrusion Countermeasures offrent à un IDS la capacité de réagir de manière autonome à la détection d'une tentative d'intrusion. Elle permettent de palier aux problèmes liés à la surveillance de l'IDS par un opérateur, ce qui pourrait demander l'attention d'un homme de manière permanente. Protégé avec les autorisations appropriée, un système aura une probabilité beaucoup plus grande d'interrompre une intrusion en cours, mais court le risque de réagir à une utilisation valide. Ce qui doit être évité est la situation où un utilisateur effectue une activité non autorisée mais dans un but honnête, et qui se retrouve à tort sous le coup des contre mesures. L'inconvénient majeur des contre-mesures est directement lié au problème des faux positifs en détection d'intrusion, i.e. que le contre-mesures doivent s'appliquer uniquement à des tentatives certaines d'intrusions. Les Intrusion Countermeasures (ICE) désignent les mécanismes qui non seulement détectent mais également réagissent de manière autonome aux intrusions quasiment en temps réel. Un tel outil a la capacité de prendre une mesure autonome de plus en plus grave si une activité pouvant porter préjudice au système est identifiée, particulièrement si aucun administrateur n'est disponible. Les actions ICE autonomes, en ordre croissant de sévérité, peuvent être envisagées : - Alerte : - Afficher les variations sur la console analyste - Augmentez la quantité de collecte de données sur l'utilisateur irrégulier - Alerter l'administrateur par une alarme sur la console analyste - Notifier l'administrateur par mail ou autres - Chercher à confirmer, augmenter les données disponibles sur l'utilisateur : - Réauthentifier l'utilisateur ou le système distant (pour déceler des intrus profitant d'une session sans surveillance, ou en cas de spoofing de paquets sur une connexion authentifiée) - Informez les responsables securité afin d'obtenir une confirmation visuelle ou vocal de l'identification de l'utilisateur - Minimiser les dommages potentiels : - Ralentir les réponses système (throttling) ou ajouter des obstacles - Feindre l'exécution de commande (ex : placer en buffer plutôt que de réellement supprimer) - Isolement : - Vérouiller l'accès à l'hôte local / Refuser les paquets - Tracer l'ID réseau et vérouiller tous les accès associé à l'hôte concerné, faire le ménage au niveau des systèmes intermédiaires. - Verrouiller la totalité du système / Déconnecter du réseau - Déconnecter le réseau de tout accès exterieur - Piège : - Modifier la topologie réseau pour rediriger l'intrus vers un honeypot - back tracing - utiliser un outil indépendant ou intégré de port mapping ou d'OS fingerprinting afin de confondre l'attaquant Les ICE offrent un certain nombre d'avantages par rapport aux IDS passifs classiques. Un système peut être protégé sans exiger d'un administrateur d'être constamment présent, et de devoir en un instant des décisions complexes. Les ICE sont impassibles, impartiaux, répondent en temps et en heure même à des attaques automatisées. Parce que les ICE souffrent des mêmes problèmes de gestion de discrimination et de profil que les mécanismes de détection d'intrusion, mais avec potentiellement aucune interposition humaine, un grand soin doit être apporté à ce que le service ne soit pas perturbé à un moment critique par des attaques DoS. Une méthode récente et intéressante de contre-mesure peut être les honeypots. L'idée du honey pot est d'installer un système leurre avec un système d'exploitation non sécurisé ou présentant de nombreuses vulnérabilités permettant un accès facile à ses ressources. Le système leurre doit être installé de manière similaire à un serveur de production classique de l'organisation et doit comporter de nombreux faux fichiers, répertoires et autres données ressemblant aux vraies. Ce faisant, le honeypot ressemblera à une machine légitime avec des fichiers légitimes, laissant le hacker croire qu'il a obtenu un accès à des informations importantes. Avec un petit peu de chance, l'intrus restera dans les alentours pour rassembler des données pendant que le honeypot collectera des informations sur l'intrus et la source de son attaque. Idéalement, les honeypots fournissent un environnement où les intrus peuvent être surveillé ou/et les vulnérabilités décelée avant qu'elle soient utilisées sur les vrais serveurs. Les leurres ne sont pas installés pour capturé les intrus mais pour surveiller et apprendre leurs mouvements, trouver comment ils sondent et exploitent le système et comment prévenir l'utilisation de ses vulnérabilités sur des serveurs de production sans que tout ceci ne soit remarqué par le hacker. AINT Misbehaving : A Taxonomy of Anti-Intrusion Techniques http://www.sans.org/newlook/resources/IDFAQ/aint.htm Intrusion Detection and Response http://www.all.net/journal/ntb/ids.html Know your Ennemy : HoneyNets http://project.honeynet.org/papers/honeynet/ Honey Pots and Intrusion Detection http://www.sans.org/infosecFAQ/intrusion/honeypots.htm Honeynets http://www.ists.dartmouth.edu/IRIA/knowledge_base/honeynets.htm The Deception Toolkit http://www.all.net/dtk/index.html 2.7.2. Qu'est ce que les rapports ? Les rapports sont le résultat final de la chaîne de collection et d'analyse des données par l'IDS. Ils doivent être assez simples et complets pour permettre la prise rapide de décision de la part d'un analyste ou d'un administrateur. De plus, les rapports doivent permettre la corrélation d'information aussi bien à court et long terme pour permettre la détection de scénarios d'attaques. Une autre capacité des rapports doit être d'établir des niveaux d'alertes graduels de pair avec les scénarios d'attaques pour permettre un classement des alertes et éviter de submerger l'analyste de falses positives (fausses alarmes). Au sein de Trithème les rapports sont générés en XML/IDMEF à la volée ou par automatisme par ICE_mod avec l'aide de libIDMEF depuis les données analysées par Data_mod et conservées dans la data warehouse, puis stockés par le manager qui les conservent en vue d'une consultation par l'analyste ou qui les lui transmet directement par l'intermédiaire d'un MUA ou tout autre fonction. Une autre fonction des rapports au sein de Trithème sera leur capacité d'aide à la décision en pointant vers un résolution de problème à la suite d'une compromission système, d'une intrusion réseau ou encore de la détection d'une vulnérabilité. Cette aide à la décision pourra se manifester au sein des rapports par une liaison avec un CERT ou une autre institution utile, une Intrusion CounterMeasures proposée par ICE_mod ou enfin le pointage vers un patch en fonction de l'entrée CVE attachée à une vulnérabilité ou signature. Intrusion Detection Message Exchange Format Data Model and Extensible Markup Language http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-03.txt CERT Incident Reporting Guidelines http://www.cert.org/tech_tips/incident_reporting.html 3. Conclusion Trithème est un IDS qui se veut extrêmement complet par ses approches et efficace par ses méthodes de collecte et d'analyse de l'information très évoluées. Mais ses avantages consitutent également ses inconvénients. En effet Trithème est un projet ambitieux et intéressant mais le nombre d'approches à combiner et les techniques à utiliser peuvent rendre son développement fastidieux et complexe. Un dernier mot. Un Intrusion Detection System peut faire parfois pensé à une sorte de Big Brother du réseau encore plus avec une architecture distribuée qui renforce la sensation d'ubiquité. Mais l'IDS ne reste qu'un simple outil s'adaptant à la politique de sécurité. Il est purement technique et ne fait que préserver la technique. Après tout dépend de qui se trouve derrière la console et selon quel principe a été rédigé la politique de sécurité. Trithème est un logiciel libre basé sur des standards ouverts et au mode de développement coopératif, son équipe suit les principes du logiciel libre et l'éthique des hackers. En parlant de hackers, Trithème ne sera je pense pas une menace pour leur *loisir* mais plutôt un challenge de plus, la cible de Trithème reste essentiellement les script kiddies. C'est là aussi un de ces avantages et c'est grâce à la communauté que Trithème a pu naître et espérons le se développera. Et n'oubliez pas : le projet et immense, nous avons besoin de développeurs ou de collaborateurs sans cesse :) * hackers community challenge - script kiddies killer * -------------------------------------------------------------------------------------- Copyright (c) 2001 CNS and Trithème Dev Team. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation ; with no Invariant Sections, with the Front-Cover Texts, and with the Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". GNU Free Documentation License http://www.gnu.org/copyleft/fdl.html GNU Coding Standards http://www.gnu.org/prep/standards_toc.html