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.

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