Analyse Et Detection Des Intrusions

ANALYSE ET DETECTION DES
INTRUSIONS
• 1. Contexte
1.1 Problématique
1.1.1 Difficulté de mise en œuvre des mesures préventives
1.1.2 Complexité des technologies de filtrage
1.1.3 Objectifs des systèmes de détection d’intrusions
1.2 Description d’un système de détection d’intrusions
1.2.1 Normalisation du domaine
1.2.2 Composition
1.2.3 Premiers systèmes
• 2. Technologies d’analyse
2.1 Détection par scénarios
2.1.1 Description des scénarios
2.1.2 Scénarios et fausses alertes
2.1.3 Scénarios et non-détection
2.1.4 Scénarios et réaction
2.1.5 Généralisation des scénarios
2.1.6 Exemple : le format de signatures de Snort
• 2.2 Détection comportementale
2.2.1 Description du modèle de bon comportement
2.2.2 Détection comportementale et fausses alertes
2.2.3 Approche comportementale et non-détection
2.2.4 Approche comportementale et réaction
2.2.5 Généralisation de l’approche comportementale
2.2.6 Exemple de l’approche comportementale : stide
• 3. Sources de données
3.1 Trafic réseau
3.1.1 Acquisition
3.1.2 Avantages
3.1.3 Inconvénients
3.1.4 Préparation des données
3.2 Traces système
3.2.1 Acquisition
3.2.2 Avantages
3.3 Traces applicatives
3.3.1 Acquisition
3.3.2 Avantages
3.3.3 Préparation
• 4. Préparation et mise en œuvre

4.1 Choix de la technologie
4.1.1 Mise en œuvre interne ou service
4.1.2 Choix de la source de données
4.1.3 Évaluation des systèmes de détection d’intrusions
4.1.4 Logiciel libre ou produit commercial
4.1.5 Technologies et outils connexes
4.2 Installation et configuration
4.2.1 Localisation
• 4.2.2 Implantations possibles
4.3 Maintenance opérationnelle
4.3.1 Logiciel
4.3.2 Signatures
4.4 Traitement des alertes
• 4.4.1 Analyse
4.4.2 Réponse
4.4.3 Gestion des fausses alertes
4.4.4 Gestion des incidents internes
4.4.5 Gestion des tentatives d’attaque externe
• 5 . Conclusion
• Annexe
1
2 Organismes
3 Logiciels
4 Bases de données
INTRODUCTION
•
Le développement de l’informatique s’est accompagné de problèmes de

sécurité. À l’origine, les virus se propageaient lentement, par l’échange de

supports informatiques. Avec l’apparition des premiers réseaux TCP/ IP, les
problèmes de sécurité se sont diversifiés et ont conduit au développement de
nouvelles techniques de sécurité.
• Très tôt dans le développement d’Internet, des vulnérabilités sur les systèmes
d’exploitation ont permis à des attaquants de se déplacer virtuellement de
système en système. Dans le contexte militaire de déploiement des réseaux
TCP/ IP, la détection des actions malveillantes est rapidement devenue une
nécessité. Les mesures de prévention se sont révélées insuffisantes et ont
amené la création de systèmes de détection d’intrusions (IDS).
• Ces systèmes ont été développés dans le but de détecter des
fonctionnements anormaux des systèmes d’information et des réseaux,
indiquant que des actions non conformes à la politique de sécurité sont
menées par un ou plusieurs utilisateurs. Deux familles de techniques
d’analyse ont été élaborées pour effectuer cette détection. La première
famille de techniques d’analyse postule que l’on peut différencier le
comportement d’un attaquant du comportement habituel du système
d’information surveillé. La deuxième famille exploite la connaissance
accumulée sur les vulnérabilités et les manières de pénétrer les systèmes
d’information ; lorsque des actions d’utilisateurs ressemblent à des attaques
précédemment décrites, le système de détection d’intrusions transmet une
alerte.
• Ces techniques d’analyse s’appliquent à différentes sources de données,
qui doivent être acquises par le système de détection d’intrusions (écoute
du réseau ou lecture de fichiers par exemple), et prétraitées pour
simplifier l’analyse.
• L’objectif de ces systèmes de détection d’intrusion aujourd’hui est

principalement de fournir des informations sur la santé du système
d’information surveillé aux opérateurs. Cependant, l’évolution des
techniques d’analyse et l’amélioration de leur fiabilité permettent
d’envisager dans quelques années des systèmes de protection plus fins
que ceux disponibles à l’heure actuelle. En particulier, il devrait devenir
possible de protéger individuellement chacun des services offerts par un
système d’information, sans être lié aux points d’accès réseau comme
cela est le cas aujourd’hui avec la technologie généralisée des pare-feu.
• 1. Contexte
• 1.1 Problématique
1.1.1 Difficulté de mise en œuvre des
mesures préventives
1.1.2 Complexité des technologies de filtrage
1.1.3 Objectifs des systèmes de détection
d’intrusions
1.2 Description d’un système de détection
d’intrusions
1.2.1 Normalisation du domaine
1.2.2 Composition
1.2.3 Premiers systèmes
• 1.1 Problématique
• Depuis de nombreuses années, les attaques contre les systèmes
d’information et les réseaux se multiplient. Cette progression va de pair
avec une multiplication du nombre de vulnérabilités informatiques publiées,
majoritairement des failles logicielles. Ces vulnérabilités font l’objet de
publications officielles ou semi-officielles, qui sont souvent accompagnées
de programmes permettant de réaliser automatiquement tout ou partie
d’une attaque.
• 1.1.1 Difficulté de mise en œuvre des mesures

préventives
• Dans le même temps, les mesures préventives induisent des contraintes
difficiles à satisfaire dans un environnement opérationnel. La généralisation
des pare-feu protège l’accès au réseau interne de la majorité des
entreprises. Ces pare-feu laissent cependant pénétrer à l’intérieur du
réseau de l’entreprise un certain nombre de protocoles considérés comme
nécessaires, par exemple DNS ou HTTP.
• En particulier, nous pouvons dire aujourd’hui qu’il est extrêmement
difficile de contrôler le bon fonctionnement d’un pare-feu. Les traces
générées sont peu explicites et ce manque sérieux d’outils d’analyse est
en partie comblé par les systèmes de détection d’intrusions.
• 1.1.2 Complexité des technologies de filtrage

• L’apparition de protocoles plus complexes, comme la téléphonie sur IP
(Internet Protocol) ou la visioconférence, rend la configuration des pare-
feu difficile car les ports devant rester ouverts ne sont pas connus à
l’avance. Il devient donc nécessaire d’avoir des configurations plus
ouvertes, qui sont autant d’opportunités de faire pénétrer du trafic
indésirable dans un réseau d’entreprise. Ces configurations moins
contraignantes induisent d’ailleurs des difficultés plus importantes pour la
définition de la politique de sécurité.
• Il convient de remarquer que les opérations réalisées par les systèmes de
détection d’intrusions au niveau des couches applicatives du réseau sont
petit à petit réintégrées dans les pare-feu, à mesure que les technologies
augmentent en fiabilité.
• Pare-feu et systèmes de détection d’intrusions sont amenés à converger, au
moins sur certains principes de base comme l’audit et les technologies
d’analyse, pour améliorer globalement la sécurité du système d’information.
• Nous assistons ainsi à l’émergence des systèmes de prévention d’intrusions
(IPS). Incluant des technologies développées pour les IDS, les IPS utilisent les
alertes pour bloquer les attaques. Les contre-mesures sont présentes dans
les IDS depuis de nombreuses années, mais le manque de fiabilité de ces
outils a souvent empêché leur mise en œuvre. Avec l’amélioration des
algorithmes de détection, les IPS peuvent bloquer le trafic malveillant avant
que l’attaquant fasse des dommages sur le système d’information. Les IPS ne
représentent donc pas une révolution technologique, mais une évolution de
techniques mises en œuvre depuis plusieurs années, que nous allons
présenter maintenant.
• 1.1.3 Objectifs des systèmes de détection d’intrusions

• L’objectif des systèmes de détection d’intrusions est donc de surveiller et
d’analyser le fonctionnement du système d’information pour détecter des
attaques. Pour ce faire, il recueille des données sur les actions qui s’y
déroulent, analyse ces données pour déterminer si une action malveillante
s’est produite, et émet des alertes vers une console de supervision.
• La source de données utilisée par le système de détection d’intrusions est
un élément de choix important pour la sélection et le déploiement d’un
tel outil.
• 1.2 Description d’un système de détection d’intrusions

• 1.2.1 Normalisation du domaine
• Depuis plusieurs années, le groupe IDWG (Intrusion Detection Exchange
Format Working Group) standardise différents aspects du domaine. Le
premier document écrit concerne la définition d’une terminologie
commune aux participants du groupe de travail. Les principaux concepts
sont regroupés sur la figure 1.
• Un système de détection d’intrusions au sens IDWG du terme est
constitué d’un ensemble de blocs ayant chacun une fonction précise, de
flux d’information orientés entre ces blocs, et de deux intervenants
humains, l’opérateur (operator ) et l’administrateur sécurité
(administrator ).
• Opérateur : l’opérateur est chargé d’observer les alertes provenant du
système de détection d’intrusions et de réagir en conséquence, souvent
en fonction de consignes données par l’administrateur sécurité ou par un
expert.
• Administrateur sécurité : l’administrateur sécurité est chargé de
configurer la politique de sécurité des sondes et de la mettre à jour.
Cette politique de sécurité fixe les raisons pour lesquelles les
sondes envoient une alerte.
Figure 1 - Concepts de la détection d’intrusions

• Une sonde de détection d’intrusions (probe ) reçoit de l’information (activity )
d’une source de données (data source ). Cette information est découpée en
événements élémentaires qui sont ensuite analysés, pour éventuellement
générer des alertes. Le flux de données activité (activity ) peut être vu comme
une suite d’octets, découpés ensuite en paquets réseaux ou lignes de log en
fonction de la source de données et des capacités de l’élément d’acquisition
(sensor ). Lorsqu’un événement malveillant est détecté par l’analyseur, une
alerte est émise à l’intention du gestionnaire d’alertes (manager ).
• L’administrateur sécurité a pour rôle de configurer les différents composants
logiciels, en définissant ce qui constitue un événement nécessitant la
remontée d’une alerte. L’opérateur a pour rôle de traiter ces alertes, en les
validant et en prenant les mesures appropriées (reaction ). Ces contre-
mesures peuvent être automatisées. Pour des raisons de rapidité et de
localisation des équipements, certaines contre-mesures sont prises
directement en compte par la sonde, comme l’injection de paquets dans le
flux réseau pour prévenir la propagation de l’attaque. En effet, la sonde se
trouve sur le flux d’information et elle seule est capable d’insérer
suffisamment rapidement les paquets dans le flux réseau pour permettre une
contre-mesure efficace.
• D’autres contre-mesures, comme la reconfiguration des pare-feu, ne
peuvent pas être prises en charge par les sondes dans la mesure où elles
sont le plus souvent isolées du réseau d’administration. Le gestionnaire
d’alerte reçoit donc la charge d’appliquer, automatiquement ou sous
contrôle de l’opérateur, toutes les opérations de reconfiguration.
• Cette description se limite à l’environnement de détection. L’objectif du
groupe de travail est même encore plus limité, dans la mesure où il s’agit de
standardiser le flux d’alertes. Cela ne constitue pas, cependant, un système
complet de détection d’intrusions, ce que nous allons voir maintenant. Ce
système fait naturellement l’usage des sondes décrites ci-avant, mais
comporte également d’autres composants.
• 1.2.2 Composition
• Un système de détection d’intrusions regroupe les composants suivants,
présentés sur la figure 2 :
• sondes : ce sont les composants actifs du système de détection d’intrusions.
Elles collectent des données, les analysent et émettent des alarmes ;
• consoles de gestion : elles permettent de gérer et de configurer les
sondes. En particulier, elles sont utilisées pour configurer et mettre à jour
les paramètres de l’algorithme d’analyse. Elles peuvent également
contrôler le bon fonctionnement des sondes ;
• concentrateurs d’alertes : ils gèrent et corrèlent les alertes reçues,
généralement à partir d’une base de données relationnelle. Ils peuvent
également avoir des outils de présentation des données comme un
serveur web ;
• consoles d’analyse : elles permettent à l’opérateur d’interagir avec les
concentrateurs d’alerte et de traiter les alertes reçues. Elles dialoguent
avec les concentrateurs d’alertes pour traiter les alertes importantes en
temps réel, générer des rapports périodiques et fonder le contenu des
bases d’alertes pour le suivi d’incidents.
Figure 2 - Configuration des composants d’un système de détection
d’intrusions

• La figure 2 illustre un arrangement possible de ces différents composants.
Deux consoles de gestion se partagent cinq sondes, qui envoient toutes
leurs alertes à un seul concentrateur. Ce concentrateur offre ses services à
deux consoles d’analyse. Dans la plupart des déploiements, il n’y a qu’un
petit nombre de concentrateurs, car c’est un composant difficile à mettre
en œuvre et à maintenir.
• Les consoles de gestion sont des machines de classe moyenne, type
Pentium 3 ou 4. Elles doivent impérativement avoir une connexion Internet
pour permettre les mises à jour des bases et du logiciel à partir des sites
des éditeurs.
• Les sondes sont soit des machines indépendantes (cas de l’écoute réseau),
soit des composants logiciels installés sur des serveurs. Les sondes et les
consoles de gestion dialoguent suivant un protocole propriétaire
permettant de mettre à jour logiciel et signatures, et de configurer le
logiciel de détection. Les concentrateurs d’alertes sont en général des
machines puissantes, capables d’accueillir une base de données avec
plusieurs millions d’événements, ainsi qu’un serveur web. Ils dialoguent
avec les sondes suivant un protocole propriétaire, mais offrent également
des interfaces standards comme SNMP (Simple Network Management
Protocol) ou Syslog. Idéalement, ce dialogue se fera en échangeant des
messages IDMEF (The Intrusion Detection Message Exchange Format). sur
protocole IDXP(Hypertext Transfer Protocol – HTTP/1.1.), dès que le
standard aura été validé par l’Internet Engineering Task Force (IETF).
• Finalement, les consoles d’alertes accèdent aux informations fournies par le
concentrateur d’alertes via un protocole standard (HTTPS) ou propriétaire.
• 1.2.3 Premiers systèmes
• Les systèmes de détection d’intrusions ont été conçus initialement comme
des dispositifs passifs permettant simplement l’observation. Cette conception
est due à la complexité de ces systèmes qui, dans l’esprit de leurs
concepteurs, ne pouvaient pas se passer d’une intervention humaine pour
faire face à l’attaquant. Plus récemment, des méthodes de contre-mesures
simples ont été proposées et implémentées, qui sont un premier pas vers la
prévention des attaques en cours, dès qu’une tentative est détectée. Ces
évolutions sont abordées dans le paragraphe 4.4.2.
• Les principes fondateurs utilisés pour l’analyse des données dans les
systèmes de détection d’intrusions ont été développés aux États-Unis au
début des années 1980 au cours du projet IDES (Intrusion Detection Expert
System) financé par l’armée américaine . Lors de ce projet, deux familles de
technologies ont été définies, qui permettent de détecter des actions
malveillantes sur les systèmes d’information.
• La première famille de technologies est dite approche par scénarios
(misuse detection ). L’objectif de cette famille de technologies est de
décrire explicitement les mauvais comportements, ceux qui vont donner
lieu à des alarmes ; l’inspiration initiale de cette famille de technologies
est d’utiliser la connaissance des vulnérabilités et techniques d’attaques,
car les tentatives malveillantes peuvent exploiter (et exploitent
effectivement dans la majorité des cas) des failles déjà connues,
largement publiées, et pour lesquelles des correctifs sont disponibles.
• La deuxième famille de technologies, dite approche comportementale
(anomaly detection ), fait l’hypothèse que le fonctionnement d’un
système d’information atteint un rythme stable au cours du temps, et que
ce fonctionnement normal peut être modélisé. Il fait également
l’hypothèse qu’une action malveillante ne va pas être comprise par le
modèle et qu’il faut donc analyser les événements ne trouvant pas
d’explication dans celui-ci.
• Ces deux familles de technologies ont été exploitées à la fois dans le
monde de la recherche et par les produits commerciaux. La technologie
d’analyse choisie par le vendeur, approche par scénarios ou approche
comportementale, est un élément fort de différenciation entre les
différents produits.
• Le paragraphe 2 présente plus en détail ces deux familles de technologies
ainsi que leur mise en œuvre, leurs avantages et inconvénients. Nous
abordons ensuite la problématique des sources de données sur lesquelles
s’appliquent ces technologies d’analyse
• 2. Technologies d’analyse

• 2.1 Détection par scénarios
2.1.1 Description des scénarios
2.1.2 Scénarios et fausses alertes
2.1.3 Scénarios et non-détection
2.1.4 Scénarios et réaction
2.1.5 Généralisation des scénarios
2.1.6 Exemple : le format de signatures de Snort
2.2 Détection comportementale
2.2.1 Description du modèle de bon comportement
2.2.3 Approche comportementale et non-détection
2.2.4 Approche comportementale et réaction
2.2.5 Généralisation de l’approche comportementale
2.2.6 Exemple de l’approche comportementale : stide
• 2.1 Détection par scénarios
• La détection par scénarios s’appuie sur la connaissance accumulée au
sujet des attaques et des vulnérabilités spécifiques des systèmes
d’information, systèmes d’exploitation et applications. Le système de
détection d’intrusions contient 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 alerte est produite.
• En d’autres termes, toute action qui n’est pas explicitement identifiée
comme un mauvais usage du système d’information, est considérée
comme acceptable. Notons que la détection par scénarios couvre plus que
les attaques connues. Une politique de sécurité peut explicitement
déclarer des événements comme « indésirables » sans qu’il y ait de
vulnérabilité associée. Par exemple, certains protocoles comme SNMP
peuvent être bannis d’un réseau indépendamment de toute vulnérabilité.
• D’autre part, un certain nombre de mécanismes d’attaque ou de
vulnérabilité ont été analysés, pour extraire des caractéristiques
communes à une classe de vulnérabilités, par exemple les débordements
de mémoire.
• Ces modèles abstraits permettent de détecter des phénomènes anormaux
liés à ces mécanismes d’attaque, sans que pour autant la vulnérabilité
spécifique soit connue. La même démarche est utilisée pour généraliser les
scénarios spécifiques à une vulnérabilité, pour les rendre indépendants d’un
outil d’attaque.
• 2.1.1 Description des scénarios

• La description des scénarios peut se faire de multiples manières. Dans le
projet IDES, l’implémentation de référence était constituée d’un système
expert contenant, sous forme de règles, la connaissance des vulnérabilités.
Une action d’un utilisateur était introduite sous forme d’un fait dans la base
de connaissances, et le système expert devait déterminer si l’ensemble des
faits et règles permettait de conclure à une intrusion ou tentative
d’intrusion. Cette manière de faire est coûteuse, car elle oblige le
développeur à extraire de sa source de données l’information dont il a
besoin, et de l’exprimer dans un formalisme de haut niveau compréhensible
par un système expert. Elle a donc été abandonnée au profit de l’expression
de scénarios sous forme de signatures d’attaques.
• Signature : en général, information à rechercher dans le flux de données,
permettant de caractériser une tentative d’attaque. L’expression la plus
courante d’une signature est l’association de chaînes de caractères (ou
expressions régulières) appliquées en fonction de caractéristiques du flux
de données (ports par exemple).
• Initialement, une signature est l’expression de l’utilisation d’une
vulnérabilité, telle qu’elle doit se traduire dans la source de données. Le
processus de détection est donc extrêmement simplifié et permet ainsi
une plus grande performance au niveau de l’analyse, au détriment du
temps nécessaire pour écrire les signatures dans le format des différentes
sources de données possibles. Il y a donc, par rapport au système expert,
une amélioration sensible de la performance en détection au prix d’une
difficulté d’expression de la vulnérabilité.
• En pratique, une signature s’exprime sous la forme d’expressions
régulières appliquées à la totalité ou à une partie des données. Ces
expressions sont plus faciles à écrire que les suites d’octets initialement
utilisées. La difficulté du développement des signatures a rendu cette
approche également difficile à implémenter en pratique.
• Il y a difficulté car, pour une même source de données et une même
vulnérabilité exploitée, des attaques peuvent avoir une forme très
différente : les attaquants peuvent masquer leur tentative sous des codages
ou séquences différents. L’application des signatures doit donc
nécessairement être précédée d’une phase de canonisation des données (les
données sont mises dans un format nominal, indépendant des différents
codages supportés par le protocole). Cette phase peut être complexe
(reconstitution de protocoles par exemple) et coûteuse en performances.
• 2.1.2 Scénarios et fausses alertes

• L’approche par scénarios ne produit en principe qu’un taux très faible de
fausses alertes. Cela suppose cependant que la vulnérabilité soit
effectivement détectable à partir de la source de données et que la ou les
signatures représentent correctement son exécution.
• Les fausses alertes proviennent essentiellement d’une mauvaise
caractérisation de la vulnérabilité. Cette mauvaise caractérisation touche en
particulier les signatures visant à détecter l’exécution d’une application
particulière, sans différencier un usage normal d’une tentative d’attaque.
• Ce défaut est fréquemment rencontré sur les signatures détectant des
attaques via des scripts CGI (Common Gateway Interface) ; le nom du script
dans la requête HTTP suffit à déclencher l’émission d’une alerte.
• De plus, les interactions observées entre utilisateur et système d’information
sont similaires, que l’application visée soit vulnérable ou non. Il faudrait
observer finement les dialogues entre utilisateur et système d’information
pour déterminer si le système d’information a été effectivement compromis,
ou si les actions de l’attaquant ne lui ont pas permis de réussir. Il est donc
important d’analyser les alertes produites par un système de détection
d’intrusions en fonction de la configuration du système d’information
surveillé, cela pour relativiser les niveaux de priorité affectés aux alertes.
• 2.1.3 Scénarios et non-détection
• La non-détection d’une tentative d’attaque se produit tout d’abord lorsqu’il
n’y a pas de signature associée à la vulnérabilité utilisée. Il est difficile de
recueillir les informations nécessaires relatives aux attaques connues et de
maintenir la base à jour avec de nouvelles vulnérabilités et de nouveaux
environnements.
• L’entretien de la base de connaissances du système de détection
d’intrusions exige l’analyse soigneuse de chaque vulnérabilité, c’est donc
une tâche fastidieuse.
• Prenons quelques chiffres pour illustrer ce fait. Un système de détection
d’intrusions aujourd’hui contient entre 500 et 2 000 signatures utilisables.
Les bases de données de vulnérabilités contiennent entre 6 000 et 20 000
vulnérabilités différentes. Il existe donc un rapport de 1 à 10 entre ce que
connaît un système de détection d’intrusions et le corpus de connaissance
sur les vulnérabilités. Ce ratio est stable ; on annonce en moyenne entre
100 et 150 nouvelles vulnérabilités par mois, pour 10 à 20 nouvelles
signatures publiées par les vendeurs de systèmes de détection
d’intrusions.
• Il faut relativiser cet écart par le fait que les vulnérabilités non couvertes
par les systèmes de détection d’intrusions sont anciennes ou concernent
des environnements (applications, systèmes d’exploitation) rares. Par
conséquent, la majorité des systèmes d’informations n’est pas concernée
par ces vulnérabilités.
• La connaissance doit être généralisée pour prendre en compte des
mutations possibles dans les formes de l’attaque ou les cibles. La
connaissance au sujet des attaques est très focalisée, dépendant du
système d’exploitation, de la version, de la plate-forme et de l’application.
Le système de détection d’intrusions qui s’impose est donc étroitement
attaché à un environnement donné.
• La détection des attaques internes est plus difficile. Ces attaques s’appuient
toujours sur des privilèges existants donnés à l’utilisateur. L’abus de ces
privilèges plus que l’utilisation d’une vulnérabilité spécifique est le vecteur
menant à la compromission du système d’information.
• 2.1.4 Scénarios et réaction
• Dans le cadre de la détection par scénarios, l’analyse contextuelle proposée
par le système de détection d’intrusions peut être détaillée, ce qui facilite la
compréhension du problème et donc la prise de décision qui s’impose pour
une action préventive ou corrective.
• Dans la mesure où le service et la machine cible sont identifiés, il est
relativement facile de déterminer si l’attaque a une probabilité de succès, et
si ces effets sont incompatibles avec les objectifs de sécurité. L’opérateur
peut fonder sa décision sur un compromis entre les objectifs de
fonctionnement du système d’information et ses objectifs de sécurité. C’est
un point fondamental à prendre en compte lors de l’implémentation d’une
réaction à une attaque : il peut être légitime de laisser fonctionner le
système d’information même sous attaque.
• 2.1.5 Généralisation des scénarios
• Les prototypes de détection d’intrusions basés sur la détection d’attaques
ont été implémentés initialement en utilisant la logique de premier ordre
et les systèmes experts. Les produits commerciaux emploient
majoritairement une approche par signatures (reconnaissance
d’expressions régulières). Il existe également des implémentations basées
sur les réseaux de Petri et l’analyse des transitions d’état.
• Côté signatures, chacune décrit un certain nombre de caractéristiques
d’une attaque. Ces caractéristiques sont souvent exprimées comme des
chaînes de caractères, des expressions régulières ou des couples champ-
valeur (numéro de port de communication par exemple). Ces
caractéristiques sont représentatives de certaines facettes de la
vulnérabilité ou de l’événement indésirable que l’on souhaite détecter.
• L’expression de la signature dépend naturellement de l’information
disponible dans la source de données au moment où l’exploitation de la
vulnérabilité est en cours. Les avantages de cette approche sont que
l’expression est simple et l’algorithme de recherche de l’expression est
efficace. Malheureusement, les fournisseurs tendent à proposer des
signatures à large spectre (produisant des fausses alertes) ou des
signatures trop spécifiques (inadaptées à des attaques mutantes).
• 2.1.6 Exemple : le format de signatures de Snort
• Le logiciel libre Snort est un système de détection d’intrusions réseau
suivant une approche par signatures. Le langage de signatures de Snort a
été très largement adapté par la communauté sécurité pour les produits
de détection d’intrusions, et également pour les antivirus. Par
conséquent, un opérateur de sécurité aura affaire à ce format de
signature. La description d’un élément à rechercher se fait de la manière
suivante :
• <type d’alerte><couche transport><source IP><source port>
<direction><destination IP><destination port> (options)
où les fonctions suivantes sont listées :
• type d’alerte : le type d’alerte définit le fonctionnement de la signature.
Les mots-clés suivants sont définis : alerte pour envoyer un message si un
événement dont les caractéristiques correspondent à la signature se
produit, log pour enregistrer l’événement dont les caractéristiques
figurent dans la signature, pass pour indiquer que l’événement est
conforme à la politique de sécurité, et dynamic pour indiquer que la
signature est activée par une ou plusieurs autres signatures, mais n’est
pas active directement ;
• couche transport : spécifie le protocole de transport utilisé, par exemple
TCP, UDP ou ICMP (Transmission Control Protocol, Universal Datagram
Protocol, Internet Control Message Protocol). La définition de ce champ
peut activer des traitements particuliers, comme la défragmentation
associée au protocole ou la vérification de l’existence de sessions, réalisés
par les préprocesseurs de Snort ;
• source IP : adresse source sous forme d’une liste de sous- réseaux ;
• source port : numéro individuel de port ou plage de ports ;
• direction : la règle s’applique soit quand le paquet va de la source à la
destination, soit sans notion de direction. Notons que les options
permettent de préciser en plus les rôles de chaque adresse (client ou
serveur) ;
• destination IP : adresse destination sous forme d’une liste de sous-
réseaux ;
• destination port : numéro individuel de port ou plage de ports. Dans le cas
où le port de destination est associé à un protocole applicatif spécifique
(RPC : Remote Procedure Call, HTTP) connu de Snort, des opérations
complémentaires, comme le décodage des données applicatives, peuvent
être réalisées par les préprocesseurs de Snort ;
• options : propriétés complémentaires que doit satisfaire l’événement pour
aboutir au déclenchement de la signature (trigger).
• Il existe un opérateur universel (any) et un opérateur de négation (!) sur
tous ces champs, la combinaison par défaut étant un « et logique » sur
l’ensemble des propriétés (la signature s’applique si l’ensemble des
propriétés est vrai).
• Les possibilités de filtrage de base de ces signatures sont extrêmement
proches des pare-feu de réseau, mais sont loin d’être suffisantes pour la
détection d’intrusions. En particulier, il est souvent nécessaire d’examiner
le contenu du paquet. Par conséquent, le champ options est utilisé pour
deux fonctions distinctes :
• associer à la signature des informations complémentaires, en plus du
message. Pour transmettre davantage d’informations sur la signature, il est
possible de transmettre des pointeurs vers des sources d’information
complémentaires. À chaque signature peuvent être associés une classe et
un niveau de priorité correspondant à la gravité de l’alerte. Si aucun niveau
de priorité n’est spécifié, celui de la classe, qui est obligatoire, s’applique à
l’alerte ;
• restreindre le déclenchement des signatures. Les options permettent de spécifier
la direction du trafic par rapport à la notion de client ou de serveur, et de spécifier
la présence ou l’absence de chaînes de caractères ascii ou hexadécimaux dans les
données examinées (charge du paquet réseau pour Snort, fichier pour un
antivirus, etc.).
• Voici une instance particulière de signature Snort :
• alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"WEB-IIS
MDAC Content-Type overflow attempt"; flow:to_server,established;
uricontent:"/msadcs.dll"; content: "Content-Type\:"; content:!"│0A│"; within:50;
reference:cve, CAN-2002-1142;
reference:url,www.foundstone.com/knowledge/randd-advisories- display.html?
id=337; classtype:web-application-attack; sid:1970; rev:1;)
• L’exemple montre l’écriture d’une signature Snort pour détecter une vulnérabilité
particulière, consistant en l’envoi d’une requête HTTP vers la librairie msadcs.dll
(champ uricontent) pour lequel la chaîne caractères de caractères transmise en
argument contient plus de 50 (absence de caractère fin de chaîne – 0A au bout de
50 caractères). Les paramètres exprimant les adresses source et destination
utilisent des variables qui permettent d’adapter rapidement un grand nombre de
signatures à un réseau particulier, en spécifiant les plages d’adresses adéquates.
Nota :
• une documentation complète de cette signature peut être trouvée sur la
base de données de signatures Snort, SID 1970.
• Ce format de signatures pose plusieurs problèmes. En particulier, la
recherche de contenus se fait sur la base de chaînes (de caractères ou
d’octets), alors qu’il serait souhaitable de disposer d’expressions
régulières. D’autre part, l’implémentation des mots-clés et plus
particulièrement des mots-clés liés aux options varie grandement de
produit à produit. Finalement, le parcours dans un fichier de signatures
n’est pas spécifié ; Snort optimise ce parcours en fonction de ses besoins
et ne donne aucune garantie d’ordre de passage entre des signatures. Il
convient donc de vérifier soigneusement de quelle manière le produit
cible utilise les fichiers de signatures au moment de l’écriture ou de la
modification de celles-ci.
Nota :
• le lecteur recherchant des informations complètes pourra consulter le site
web de Snort ou l’ouvrage.
• 2.2 Détection comportementale
• La détection comportementale est aussi quelquefois appelée détection
d’anomalies, traduction de l’anglais anomaly detection. L’objectif général
est de définir le fonctionnement correct du système d’information surveillé
et d’émettre une alerte si un événement survient qui ne peut pas être
expliqué par ce fonctionnement correct. Elle suppose qu’une intrusion
puisse être détectée en observant une déviation du comportement
attendu du système d’information ou de ses utilisateurs.
• 2.2.1 Description du modèle de bon comportement

• Le modèle du comportement normal ou valide est extrait à partir d’une
référence collectée par observations ou spécifiée a priori. Lors de la
détection, le système de détection d’intrusions compare ce modèle à
l’activité actuelle. Une alerte correspond à une déviation entre modèle et
comportement courant.
• En d’autres termes, quelque chose qui ne correspond pas à un
comportement précédemment connu est considéré comme étant intrusif.
• Bien évidemment, l’efficacité d’un tel système dépend fortement de
l’efficacité du modèle et de sa capacité à séparer le comportement normal du
comportement malicieux. Il convient de noter que ceci est un postulat établi
par D. Denning en 1985 ; il n’existe pas de validation théorique du fait qu’une
action malveillante se différencie du fonctionnement normal du système
d’information.
• Les premiers modèles utilisés sont fondés sur l’apprentissage. Un ensemble
de variables est utilisé pour modéliser le fonctionnement du système
d’information, par exemple les différentes consommations de ressources, les
suites de commandes passées ou les appels systèmes effectués par les
applications. Pendant une période d’observation, le modèle se construit en
considérant que le comportement observé est le comportement normal du
système d’information.
• Des implémentations alternatives ont utilisé des systèmes experts, des
réseaux de neurones et l’immunologie. Cela reste largement un domaine de
recherche, car les rares outils commerciaux existants se contentent
d’algorithmes statistiques simples à mettre en œuvre et peu discriminants.
• Le taux élevé de fausses alarmes est généralement cité comme inconvénient
principal des techniques de détection d’anomalies parce que la portée entière
du comportement d’un système d’information ne peut être couverte pendant
la phase d’étude. De plus, les phénomènes de saturation peuvent changer
grandement le fonctionnement nominal du système surveillé.
• En outre, le comportement peut évoluer avec le temps, impliquant la
nécessité de recycler en ligne périodiquement le profil de comportement,
avec comme conséquence l’indisponibilité du système de détection
d’intrusions ou éventuellement de nouvelles fausses alarmes.
• Ce problème est accru par la difficulté de comprendre les alertes fournies
par un système de détection d’intrusion comportemental. En effet, ces
alertes peuvent avoir des causes multiples, non nécessairement liées à la
sécurité. En fait, il faut même envisager que le système de détection
d’intrusions reçoive des informations en provenance d’outils de mesure
(compteurs SNMP, sondes RMON : Remote Monitoring, gestionnaires de
serveurs par exemple) et construise un modèle de bon fonctionnement de
ces mesures.
• 2.2.3 Approche comportementale et non-détection

• L’approche comportementale peut détecter des tentatives d’utilisation de
vulnérabilités nouvelles et imprévues. Elle peut même contribuer
(partiellement) à la découverte automatique de ces nouvelles attaques
dans la mesure où elle isole des ensembles de données suspectes à
examiner. Elle dépend moins des mécanismes spécifiques des systèmes
d’exploitation. Elle aide également à détecter les abus de privilège,
attaques qui n’impliquent pas réellement d’exploiter une vulnérabilité.
• La non-détection d’une attaque peut provenir de deux facteurs, la
corruption du modèle de bon fonctionnement et l’absence de mesures.
• Prenons l’exemple de la supervision d’un serveur ; elle comporte
notamment le suivi de la charge du processeur, de l’utilisation du disque et
de la liste des processus. Si une attaque sature le disque ou le processeur,
alors elle peut être détectée. Si une attaque permet de désactiver un
processus sans pour autant qu’il se termine ou sature le processeur, cette
attaque n’est pas détectée. La détection de l’attaque dépend donc non
seulement de la vulnérabilité, mais également de la manière dont
l’attaquant la met en œuvre, et finalement des conditions de
fonctionnement du système d’information surveillé. Il n’existe pas
aujourd’hui de fondements technologiques permettant de lister les
variables observables et d’indiquer quelles attaques peuvent être détectées
et quelles attaques ne peuvent pas être détectées, y compris sur les
attaques connues aujourd’hui.
• Le système d’information peut subir des attaques durant la phase
d’apprentissage du système de détection d’intrusions. En conséquence, le
profil du comportement du système d’information contient le
comportement intrusif et celui-ci n’est pas détecté comme anormal. Par
conséquent, une attaque est perçue comme un fonctionnement normal par
le système de détection d’intrusions.
• 2.2.4 Approche comportementale et réaction
• Les alarmes provenant d’un système de détection d’intrusions
comportemental sont difficiles à analyser. C’est pourquoi une nouvelle
génération de systèmes est en cours de développement, dont le
fonctionnement s’approche de celui des leurres (honeypots ).
• Un leurre est un système configuré spécifiquement pour attirer les
attaquants. C’est en général un système publiant des informations
intéressantes et montrant de nombreuses failles de sécurité. Deux
approches peuvent être suivies : les leurres passifs, qui se contentent
d’enregistrer les interrogations qu’ils reçoivent sans répondre, et les
leurres actifs, qui simulent des réponses intéressantes aux interrogations
qu’ils reçoivent.
• Dans le contexte de la détection d’intrusions, les réponses contiennent
des marques spécifiques. Le système de détection d’intrusions attend
ensuite d’autres interrogations utilisant ces mêmes marques, pour tracer
le comportement de l’attaquant. Ces marques peuvent être par exemple
des adresses IP spécifiques ou des noms d’utilisateurs, qu’il suffit de
retrouver lors de demandes d’ouverture de sessions.
• Exemple :
• prenons le cas d’un attaquant qui commence par rechercher les machines
existant dans un sous-réseau. Il envoie une requête DNS pour une
machine inexistante. Le système de détection d’intrusions répond à cette
source avec un nom spécial. L’attaquant essaie ensuite de se connecter en
utilisant ce nom spécial, permettant ainsi au système de détection
d’intrusions de retrouver une information qu’il a lui-même générée, et de
corréler les multiples actions faites par un attaquant.
• L’utilisation des leurres en sécurité est prometteuse, mais elle reste
encore très anecdotique d’une part et consommatrice de temps d’autre
part.
• 2.2.5 Généralisation de l’approche
comportementale
• Les systèmes de détection d’intrusions comportementaux ont cherché à
se libérer de la contrainte d’apprentissage. Cette phase a donné côté
serveurs les systèmes immunologiques, et côté réseau les systèmes de
vérification de conformité à un protocole.
• Dans ces deux familles de systèmes, le modèle de comportement est fixé
par des spécifications.
• Dans le premier cas, le fonctionnement des applications surveillées est
analysé pour construire des séquences d’appels systèmes que
l’application utilise pour répondre aux requêtes. Ces séquences sont
regroupées dans une bibliothèque modélisant l’ensemble des fonctions
acceptables de l’application. Une attaque contre l’application doit se
traduire par l’exécution d’une suite d’appels systèmes non contenue dans
la bibliothèque. Dans de nombreux cas, l’objectif de l’attaquant est
effectivement de faire exécuter du code sur sa cible. Si la bibliothèque
contient des séquences suffisamment longues, il est très difficile à
l’attaquant de construire son attaque sans être détecté.
• Dans le deuxième cas, le système de détection d’intrusions vérifie la
conformité des messages échangés avec les spécifications du protocole
utilisé. Si les messages ne sont pas conformes aux spécifications, une
alerte est émise. Ces approches récentes devraient permettre d’améliorer
le fonctionnement des systèmes de détection d’intrusions
comportementaux.
• 2.2.6 Exemple de l’approche comportementale : stide
• Stide (Sequence Time-Delay Embedding) est un système de détection
d’intrusions comportemental fondé sur le suivi des appels systèmes
effectués par les processus. Comme dans tout système de détection
d’intrusions comportemental, l’utilisation de stide comporte deux phases
distinctes : la construction du modèle de comportement normal et la
surveillance du système d’information par rapport à ce modèle de
comportement.
• Le modèle de comportement normal est constitué d’une bibliothèque de
séquences d’appels systèmes. Ces séquences sont extraites d’un ensemble
d’exemples d’exécutions des processus que l’on désire surveiller. Plusieurs
méthodes existent pour les construire, depuis l’analyse du code source
jusqu’à la segmentation d’exécutions réelles du processus.
• Une fois la bibliothèque constituée, la phase de détection vérifie que les
séquences d’appels systèmes effectuées par les processus appartiennent à
la bibliothèque.
• C’est un système intéressant car il permet de détecter des attaques
inconnues et des effets anormaux du fonctionnement d’une application,
comme le lancement d’autres exécutables. Cependant, il est coûteux en
temps processeur et n’est pas disponible comme produit.
• 3. Sources de données

• 3.1 Trafic réseau
3.1.1 Acquisition
3.1.2 Avantages
3.1.4 Préparation des données
3.2 Traces système
3.2.1 Acquisition
3.2.2 Avantages
3.3 Traces applicatives
3.3.1 Acquisition
3.3.2 Avantages
3.3.3 Préparation
• Les méthodes d’analyse présentées dans le paragraphe 2 s’appliquent à
une source de données. Dans tous les cas, il est rare que la source de
données soit utilisée brute par le système de détection d’intrusions. Nous
nous intéressons donc ici non seulement à l’interception des données,
mais également à une préparation de ces données pour supprimer des
dépendances dues aux protocoles ou aux systèmes d’exploitation.
• 3.1 Trafic réseau
• Le trafic réseau est la source de données la plus utilisée par des systèmes
de détection d’intrusions ; de tels systèmes de détection d’intrusions sont
appelés Network Intrusion Detection Systems (NIDS).
• 3.1.1 Acquisition
• La sonde collecte les données en écoutant le réseau et en examinant les
en-têtes et le contenu des paquets. Cette source de données était très
populaire pour les réseaux Ethernet coaxiaux, où une seule sonde avec une
carte en mode écoute réseau (promiscuous mode ) pouvait surveiller un
sous-réseau entier. Les réseaux sont devenus beaucoup plus rapides,
rendant la tâche d’analyse du trafic difficile. D’ailleurs, les réseaux
commutés exigent une configuration spécifique des commutateurs (ports
SPAN) pour permettre la surveillance d’un sous-réseau complet. En
conséquence, les sondes employant cette source de données sont souvent
situées près des points d’accès où le trafic sensible est agrégé.
• Récemment, une autre forme de sonde réseau est apparue, le NNIDS
(Network Node Intrusion Detection System). Un NNIDS est un NIDS qui ne
surveille que le trafic adressé à la machine sur laquelle il réside. Installer le
logiciel de détection d’intrusions sur la machine surveillée induit une
baisse des performances. Il en résulte cependant une meilleure résistance
à certains phénomènes de masquage car le NNIDS tire bénéfice de
l’interprétation des paquets réseau par le système d’exploitation.
• En ce qui concerne l’aspect physique des sondes réseau, ce sont des
boîtiers dédiés avec deux interfaces réseau, une pour l’écoute et une pour
la gestion. L’interface d’écoute n’a pas d’adresse IP et est inconnue du
réseau surveillé. L’interface de gestion devrait être située sur un réseau
séparé physiquement ou logiquement pour éviter les interférences avec la
surveillance et pour assurer la sécurité des transactions de gestion. Le
boîtier dédié est un matériel (recommandé) ou un PC standard
convenablement durci avec le logiciel d’exploitation et le logiciel de
détection approprié installés. Le choix d’un matériel est recommandé
pour la sécurité (aucun durcissement spécifique requis) et les
performances.
• 3.1.2 Avantages
• L’utilisation de cette source permet tout d’abord la détection des attaques
spécifiques au réseau. Il y a un certain nombre d’attaques du réseau, en
particulier les attaques par déni de service, qui ne peuvent pas être détectées
d’une manière aisée en recherchant l’information sur le système, mais plutôt
en analysant le trafic réseau.
• Ensuite, cette source de données minimise l’impact sur le système
d’information surveillé. Les données sont collectées sur une machine séparée,
sans impact sur le reste du réseau. Par conséquent, l’installation des outils de
détection d’intrusions est facilitée parce qu’ils n’affectent pas le reste du
système d’information.
• Cette source permet d’homogénéiser le format des données à traiter,
indépendamment des systèmes d’exploitation utilisés et (au moins en première
approximation) des services offerts par le système d’information surveillé. Le
standard de fait TCP/IP facilite l’acquisition, le formatage et l’analyse.
Cependant, l’indépendance vis-à-vis des systèmes d’exploitation installés dans
le système d’information surveillé peut conduire à des erreurs de diagnostic
lorsque les implémentations des différentes piles IP n’interprètent pas le
standard de la même manière.
• Les réseaux haut débit et commutés ont introduit de nouveaux problèmes
pour l’insertion des sondes dans le réseau. Cependant, dans un contexte
de besoin de garantie de service, l’utilisation d’espions matériels permet
l’utilisation des sondes réseau sans perturber les systèmes surveillés.
• 3.1.3 Inconvénients
• Plusieurs problèmes spécifiques des réseaux peuvent se poser The
Intrusion Detection Message Exchange Format.
• Masquage des adresses : tout d’abord, la traduction d’adresses réseau
(NAT) pose le problème de la corrélation d’adresses IP. Quand les flux
d’entrée et de sortie ne circulent pas sur le même segment de réseau
(cela semble devenir le cas des environnements d’hébergement pour des
raisons de performance et de fiabilité), le système de détection
d’intrusions voit seulement une des deux directions du flux et ne peut pas
reconstruire les sessions (TCP).
• Chiffrement des paquets : le trafic chiffré empêche le système de
détection d’intrusions d’examiner la charge utile du paquet lorsque le
chiffrement protège la couche applicative (SSH ou SSL par exemple).
• Si un médiateur (proxy ) SSL est employé, localiser le NIDS après le
médiateur est la manière la plus efficace de surveiller le trafic HTTP. Dans
le cas des réseaux privés virtuels, une partie des en-têtes est également
masquée.
• Fragmentation : la fragmentation au niveau IP d’une part et au niveau
transport d’autre part doit être traitée correctement pour mettre à
disposition de l’algorithme d’analyse la totalité des données applicatives
transportées.
• Fiabilité de l’association entre adresse source et attaquant : de
nombreuses attaques peuvent se faire en utilisant des adresses IP fictives
(IP spoofing ), lorsque l’attaquant n’a pas besoin de recevoir de réponse
de sa cible. D’autre part, un attaquant peut traverser plusieurs systèmes
(stepping stones ) pour masquer l’origine de l’attaque. Finalement,
certaines attaques par déni de service fonctionnent en incitant d’autres
agents à générer du trafic répondant à la cible (reflectors ). Par
conséquent, l’association entre attaquant et adresse IP est peu fiable, et
de nombreuses vérifications doivent être entreprises pour être certain de
l’identification de l’attaquant.
• Pérénité de l’adresse IP : dans de nombreuses organisations, et
particulièrement chez les FAI (fournisseur d’accès à Internet), les adresses
sont allouées dynamiquement (DHCP : Dynamic Host Control Protocol) à
partir d’un pool. L’identification de l’auteur d’un acte malveillant
demande donc d’auditer l’allocation d’adresses en fonction du temps.
• 3.1.4 Préparation des données

• Les protocoles applicatifs codent des données échangées. De ce fait,
l’exploitation de la partie données (payload ) d’un paquet réseau
nécessite des traitements lourds. L’attaquant peut masquer (evasion ) son
attaque en utilisant des codages alternatifs, non compris par le système
de détection d’intrusions.
• Par exemple, le protocole HTTP permet de remplacer n’importe quel
caractère par son code ascii hexadécimal, précédé du caractère % . Ptacek
et Newham ont montré en 1998 que plusieurs systèmes de détection
d’intrusions réseau ne savaient pas reconnaître ce codage, et donc ne
voyaient pas certaines tentatives malveillantes. Ce problème a été résolu,
mais d’autres codes apparaissent.
• Le codage Unicode est un standard permettant de représenter dans un
même système de codage l’ensemble des signes nécessaires à l’écriture.
Unicode spécifie un numéro unique pour chaque caractère, quelle que soit
la plate-forme, quel que soit le logiciel et quelle que soit la langue.
• Cette flexibilité, très appréciable pour les développeurs, devient un
cauchemar pour les développeurs de systèmes de détection d’intrusions.
En effet, Unicode permet de représenter certaines lettres de plusieurs
dizaines de manières. De plus, certaines extensions, non conformes aux
standards, et donc inconnues des vendeurs, sont parfois présentes dans les
systèmes d’exploitation modernes, et peuvent devenir des outils de
masquage très efficaces. C’est le cas du codage dit %u encoding, où le u
remplace la référence au codage Unicode simple dans l’environnement
Windows. De nombreuses attaques ont pu être masquées par l’utilisation
de ce codage, jusqu’à ce qu’il soit rendu public et pris en compte par les
vendeurs.
• Ces problèmes sont correctement traités par les systèmes de détection
d’intrusions actuels, qui sont capables de décoder correctement les
protocoles les plus fréquents.
• Les systèmes de détection d’intrusions peuvent être encore plus
intelligents et incorporer une reconnaissance des protocoles (protocol
awareness ). Un NIDS connaissant les protocoles recompose la machine
d’état des protocoles et applique son algorithme d’analyse seulement aux
états appropriés des protocoles.
• Un NIDS ne connaissant pas les protocoles (souvent désigné sous le nom
de network grep ) applique son algorithme d’analyse sur la charge utile du
paquet et ignore les informations d’état.
• 3.2 Traces système
• Les sources système regroupent les diverses données disponibles au
niveau du système d’exploitation. Les systèmes de détection d’intrusions
employant des ressources système sont nommés HIDS (Host-based
Intrusion-Detection Systems).
• Syslog sous Unix (format de facto en cours de normalisation à l’IETF ) et le
système d’audit « NT event log » sous Microsoft Windows NT fournissent
à des applications un service pour identifier, horodater et stocker
l’information relative à leur comportement. L’utilisation de ces deux
sources est naturelle et, de fait, elles sont employées par beaucoup de
HIDS ou d’autres outils de gestion d’alertes comme base pour corréler des
données provenant de plusieurs sources.
• Beaucoup de systèmes d’exploitation offrent un audit C2 pour être
conformes aux exigences du gouvernement des États-Unis sur l’achat des
systèmes informatiques. L’audit C2 fournit une trace de toutes les
opérations privilégiées exécutées par un logiciel d’exploitation,
habituellement par des appels systèmes. L’audit C2 offre l’identification
forte de l’utilisateur, traçant les éventuels changements d’identifiant jusqu’à
l’utilisateur d’origine. Il a été incorporé dans de nombreux prototypes de
HIDS, mais a été abandonné par les produits commerciaux en raison d’un
fort impact sur les performances du système d’exploitation surveillé, et
d’une utilisation plus difficile, notamment en milieu hétérogène.
• Hewlett-Packard a développé un système de détection d’intrusions
propriétaire pour leur système d’exploitation HP/UX. Ce système, installé sur
HP 9000, suit une approche similaire à celle de l’audit C2, mais il repose sur
l’usage d’un dispositif d’acquisition des appels systèmes intéressants pour le
moteur d’analyse. Ce dispositif est spécifique au système d’exploitation
HP/UX.
• 3.2.2 Avantages
• Le principal avantage des données relatives au système d’exploitation est
leur précision. C’est sur cette base qu’un HIDS est capable de produire moins
de fausses alarmes tout en fournissant des informations plus détaillées sur
leur contexte permettant de fixer les seuils de tolérance.
• En particulier, les différents acteurs sont souvent correctement et finement
identifiés. Les informations de contexte, en particulier de réussite, sont
attachées à la trace système pour chaque événement surveillé, ce qui permet de
savoir si la tentative malveillante a effectivement eu des suites.
• L’élément capital des dispositifs d’acquisition d’informations relatives au
système d’exploitation est que, soit le HIDS doit résider sur le système
d’exploitation hôte, soit l’information doit être transportée. Il y a donc une
dégradation des performances similaire à celle induite par un NNIDS.
• D’autre part, il y a nécessairement installation d’une application système sur les
serveurs surveillés. Cette installation a souvent un impact important sur la
gestion du système, et présente donc un obstacle important à la mise en place.
• 3.3 Traces applicatives
• Les informations applicatives regroupent toutes les traces maintenues
indépendamment par les applications. Les systèmes de détection d’intrusions
employant des données applicatives sont également considérés comme des
HIDS. Cependant, une application distribuée (base de données sur machine
répartie par exemple) fonctionnant sur plusieurs machines ou dans des
environnements multiprocesseurs est considérée comme une unique source de
données.
• Les exemples typiques de sources d’informations applicatives sont les logs
de serveurs HTTP stockant les requêtes reçues par le serveur ainsi que le
résultat de leur exécution (par exemple sous le format CLF – Common Log
Format – ou sous des formats spécifiques type Apache) ou les traces de
requêtes vers une base de données.
• Le code suivant montre un exemple de ligne de log HTTP :
• <client> <auth_unix> <auth_http> [<timestamp>] "<method> <URI>
HTTP/1.x" <status> <bytes> 1.2.3.4 - herve [13/Apr/2003 10:20:35 +0200]
"GET / HTTP/1.0" 200 2435
• Le champ client contient l’identité (adresse IP ou nom) de la machine d’où
provient la requête. Si cette machine se trouve derrière un pare-feu ou un
médiateur (proxy ), l’identité peut être celle de cet équipement
intermédiaire. Les deux champs suivants identifient l’utilisateur par rapport
au serveur, s’il y a lieu. La requête est ensuite estampillée et son contenu
conservé. Finalement, la ligne contient le code retour (200 indique un
fonctionnement normal) et le nombre d’octets renvoyés au client.
• Cette ligne ne contient que les en-têtes de la requête HTTP. Elle permet
cependant d’obtenir de nombreuses informations sur le fonctionnement
du serveur, puisque le champ URI contient les arguments passés et que le
champ status indique si la transaction s’est déroulée correctement.
• 3.3.2 Avantages
• Ces données sont souvent plus précises et condensées que les sources de
logiciel d’exploitation, parce qu’elles représentent des opérations qui sont
considérées comme atomiques du point de vue de l’application, même si
elles sont éclatées en milliers d’appels systèmes. Par exemple, chaque
ligne de trace HTTPD représente une demande qui a été reçue et traitée
par le serveur. Ces traces fournissent des informations plus pertinentes
sur la transaction, plus facilement que ne pourraient le faire une
reconstruction des appels systèmes ou une reconstitution des sessions au
niveau réseau. En conclusion, les traces contiennent l’information telle
qu’elle a été traitée par l’application.
• 3.3.3 Préparation
• La préparation des données applicatives dépend fortement de
l’application. Dans certains cas, cette préparation peut être très légère,
car l’application sauve dans le fichier de trace des messages déjà décodés
et normalisés. C’est souvent le cas des messages Syslog.
• Dans d’autres cas, par exemple les logs HTTP, il est nécessaire d’appliquer
les mêmes algorithmes de décodage que ceux utilisés sur les sources
réseau, car l’information est insérée dans les fichiers de trace telle qu’elle
a été reçue du réseau.
• Le fichier de trace est parfois réservé aux cas d’erreur et de fin anormale
des processus. Ces fichiers ne contiennent pas assez d’information pour
les HIDS. Il est nécessaire de collecter l’ensemble des informations des
transactions normales, car celles-ci peuvent contenir des actions
malveillantes.
• Il est dit ci-avant que chaque ligne de trace d’une source, telle que le log d’un
serveur web, représente une transaction. C’est une approximation car certaines
transactions peuvent produire des lignes multiples dans le fichier de trace.
• Exemple :
• une page HTML contenant des images incluses produira plusieurs requêtes et
donc de multiples lignes dans le fichier de trace, une pour la page principale plus
une par image téléchargée.
• Il est dit ci-avant que chaque ligne de trace d’une source telle que HTTPD
représente une transaction. Cela ne tient pas compte des cas d’attaque par déni
de service qui gèlent le serveur avant que l’entrée appropriée ne soit écrite dans
le fichier de trace. Quelques attaques par déni de service contre Microsoft IIS ne
génèrent pas la moindre trace si l’attaque est réussie. Cette situation est
habituellement corrigée par la publication de mises à jour du système concerné
pour éliminer ces vulnérabilités.
• La prise en compte et la visualisation du fichier de trace doivent être faites avec
certaines précautions, en particulier lorsqu’il s’agit de traces comportant
certaines séquences de caractères binaires ou des encodages spécifiques.
Certains fichiers de trace conservent le codage et l’exécution de l’attaque peut
être lancée durant la lecture de la trace.
• 4. Préparation et mise en œuvre

• 4.1 Choix de la technologie
4.1.1 Mise en œuvre interne ou service
4.1.2 Choix de la source de données
4.1.3 Évaluation des systèmes de détection
d’intrusions
4.1.4 Logiciel libre ou produit commercial
4.1.5 Technologies et outils connexes
4.2 Installation et configuration
4.2.1 Localisation
4.3 Maintenance opérationnelle
4.3.1 Logiciel
4.3.2 Signatures
4.4 Traitement des alertes
4.4.1 Analyse
4.4.2 Réponse
4.4.3 Gestion des fausses alertes
4.4.4 Gestion des incidents internes
4.4.5 Gestion des tentatives d’attaque
externe
• De nombreux paramètres sont à prendre en compte lors du déploiement
d’un ensemble de sondes de détection d’intrusions pour protéger un
système d’information ou un réseau. Il convient tout d’abord de ne pas
négliger le coût humain d’une telle opération. En effet, déployer et
maintenir un tel système demande des opérateurs formés à la sécurité,
disponibles pour analyser les alertes produites.
• 4.1 Choix de la technologie
• 4.1.1 Mise en œuvre interne ou service
• La mise en œuvre d’un système de détection d’intrusions est complexe et
coûteuse. De ce fait, plusieurs sociétés proposent des services
externalisés liés à la détection d’intrusions. Deux fonctions principales
sont ainsi externalisées :
• la gestion et la maintenance des sondes. Les sondes de détection
d’intrusions doivent être fréquemment mises à jour pour préserver leur
efficacité. Ce service assure que les dernières bases de connaissances sont
en place et que la configuration est correcte. Il peut également prendre
en compte les aspects performance, pour assurer que les sondes sont
correctement dimensionnées par rapport au flux de données à analyser ;
• la gestion des alertes. Les différentes alertes sont collectées par la société
de service, acheminées jusqu’à un centre opérationnel et analysées par
des opérateurs spécialisés.
• Les données dans ce cas ne sont pas uniquement des alertes provenant de
sondes de détection d’intrusions, mais peuvent inclure toutes les sources
de données importantes, audits de pare-feu par exemple. La société de
service fournit à ses clients des rapports périodiques sur la surveillance du
système et peut également intervenir en cas d’incident grave.
• Dans les deux cas, la définition contractuelle du service est l’élément
important à analyser. Dans la mesure où les sondes de détection
d’intrusions peuvent être prises en défaut, ce type de service ne
fonctionne pas comme une assurance pouvant prendre en charge une
contre-partie financière en cas d’attaque réussie.
• Le modèle du service est intéressant essentiellement pour de petites
structures, et s’il est couplé à d’autres services de sécurité externalisés,
pare-feu ou authentification par exemple. Dans ce cas, le fournisseur de
service peut effectivement mettre en place une corrélation des alertes
provenant des différentes sources de données, et mesurer effectivement le
risque encouru par le client. Pour de grosses structures, le traitement
interne est plus intéressant car l’information sensible concernant la
topologie du réseau reste interne. En revanche, il faut que le système
choisi (sondes et consoles) s’intègre correctement aux autres outils de
gestion de système et de réseau pour pouvoir utiliser les opérateurs et les
procédures existants.
• 4.1.2 Choix de la source de données
• La première chose à prendre en compte lors du déploiement de sondes de
détection d’intrusions est le choix HIDS/NNIDS ou NIDS. L’installation d’un HIDS
a un impact sur le serveur sur lequel il est installé, puisqu’il utilise une partie
des ressources de ce serveur. Cela implique également des opérations de
maintenance supplémentaires sur le serveur pour la mise à jour des signatures.
• L’installation d’un ou de plusieurs NIDS n’est pas neutre non plus, parce qu’elle
exige la disponibilité de points de branchements permettant d’écouter le
réseau. Plusieurs techniques sont possibles : recopie de ports (span ), insertion
de dispositifs de dérivation (hubs, taps ) ou de partage de charge (toplayer ).
Ces dispositifs peuvent avoir un impact négatif sur les performances et/ou la
fiabilité du réseau, ou le rendre plus difficile à administrer.
• Il est recommandé d’utiliser un système de détection d’intrusions et un outil
d’évaluation de vulnérabilité sur les serveurs sensibles. Il y a peu
d’inconvénients pour l’opérateur (exécution de l’extérieur), et l’augmentation
de la conscience du besoin de sécurité est accrue par la mise en évidence de la
vulnérabilité des serveurs.
• 4.1.3 Évaluation des systèmes de détection
d’intrusions
• Les licences d’évaluation sont un enjeu sensible dans le domaine des
systèmes de détection d’intrusions car les vendeurs ne souhaitent pas
exposer le fonctionnement interne et la connaissance contenue dans leur
produit. Dans un premier temps, les résultats obtenus durant l’évaluation
peuvent apparaître comme non significatifs parce que la base de
signatures n’est pas explicite, parce que le profil du trafic n’est pas
caractérisé ou parce que la distinction entre trafic normal et trafic
malveillant est trop évidente. La plupart des fournisseurs présentent sur
leurs serveurs web des résultats d’évaluation par un laboratoire d’essai.
Aucun d’eux ne semble offrir une preuve réelle de l’efficacité de ses
produits.
• Des résultats d’évaluation intéressants sont publiés régulièrement par
divers magazines ou des laboratoires spécialisés, par exemple The NSS
Group. Cela peut fournir un premier ensemble de critères pour une phase
pilote.
• La mise en œuvre d’un système de détection d’intrusions nécessite une
phase d’expérimentation pour s’assurer qu’elle s’adapte correctement
dans l’environnement qu’elle surveille. Aucun moyen ne permet de
prévoir l’efficacité d’un système de détection d’intrusions en se
dispensant de cette phase.
• 4.1.4 Logiciel libre ou produit commercial

• Le débat entre logiciel libre et produit commercial n’est pas ici un débat
idéologique. Cependant, les sondes de détection d’intrusions
commerciales sont chères et il est donc nécessaire de justifier cette
dépense. Le logiciel libre est supposé plus sûr car le code source peut être
examiné par un grand nombre d’utilisateurs. Cet avantage est discutable
car peu de personnes ont l’expertise nécessaire pour analyser ledit code.
• En revanche, l’avantage certain des sondes de détection d’intrusions
libres est l’ouverture des signatures. Cela permet à l’opérateur une
déduction simple entre le contenu des données et l’alerte, et donc une
analyse très rapide et fiable des informations remontées par les sondes.
Les produits commerciaux souffrent là d’un handicap important, car peu
d’entre eux mettent à disposition des utilisateurs leurs signatures.
• L’analyste manque donc d’une information essentielle pour juger de la qualité
des alertes produites et de la réaction appropriée.
• Par exemple, la plupart des produits commerciaux ne savent pas analyser le
succès ou l’échec d’une tentative et renvoient exactement la même alerte dans
les deux cas. L’examen de la signature permet de mettre cela en évidence. Un
analyste faisant face à un volume important d’alertes peut donc choisir d’ignorer
certains types d’alertes car son expérience le conduit à penser qu’elles ne sont
pas pertinentes, sans disposer des données nécessaires à la vérification de son
hypothèse. Il convient d’ailleurs de se demander si le secret entretenu par les
vendeurs de sondes de détection d’intrusions ne provient pas davantage de la
faiblesse de leur technologie que d’un besoin de préservation de leur propriété
intellectuelle.
• 4.1.5 Technologies et outils connexes

• Les sondes de détection d’intrusions peuvent être tout d’abord couplées avec
les outils d’audit de vulnérabilités. Ces outils permettent d’obtenir à distance des
informations sur un serveur, quels sont les services rendus par celui-ci et quelles
sont les vulnérabilités potentielles qui permettraient à un attaquant de
compromettre ce serveur.
• L’outil le plus connu, Nessus, indique quelles vulnérabilités sont présentes sur
un serveur en tentant de les utiliser et en analysant le résultat obtenu.
• Ces outils fournissent tout d’abord une information topologique sur le
système d’information surveillé, en identifiant les différentes machines et les
services rendus. Cela permet de configurer les sondes de détection
d’intrusions, en désactivant la surveillance de services inexistants ou en
affectant une priorité faible aux alertes liées à ces services. Le choix entre l’un
et l’autre est fonction de plusieurs facteurs, essentiellement la charge de
travail des sondes et la charge de travail des opérateurs. Si les sondes sont
positionnées dans un environnement avec des flux très importants, alors le
besoin de performance justifie la désactivation des signatures. Il en va de
même pour la charge de travail des opérateurs. Si elles sont actives, ces
signatures peuvent cependant servir d’avertisseur sur des opérations de
reconnaissance menées par des attaquants ; il revient donc à chacun de
décider, en fonction de son besoin d’information, quelle démarche adopter.
• Les rapports fournis par les outils d’audits peuvent également être utilisés
par des mécanismes de corrélation d’alertes pour trier les alertes à traiter,
entre celles ne présentant pas de risque car l’application n’est pas vulnérable
à l’attaque et les autres.
• La finesse du diagnostic de l’outil d’audit est donc à prendre en compte, en
particulier pour s’assurer qu’une absence d’alerte sur une vulnérabilité indique
bien que l’application en question n’est pas vulnérable. Les rapports ne sont en
effet pas toujours aussi détaillés que nécessaire pour mettre en place ce type
de corrélation.
• 4.2 Installation et configuration
• 4.2.1 Localisation
• Chaque fournisseur de systèmes de détection d’intrusions fournit des exemples
d’architecture. Les points suivants doivent être précisés :
• l’installation d’un système de détection d’intrusions en réseau en amont du
pare-feu crée un risque de surcharge en quantité d’information. Cela n’est utile
que si le surcroît d’alertes corrélées avec les traces du pare-feu permet de
détecter un franchissement du pare-feu. Cette organisation permet également
de surveiller le trafic sortant et de détecter la fuite de données sensibles
(documents sensibles, chevaux de Troie, commandes d’administration) ;
• l’installation d’un système de détection d’intrusions en réseau en aval du pare-
feu fournit des informations intéressantes sur des attaques effectives qui ont
traversé le pare-feu ainsi que sur le trafic sortant suspect (protocoles interdits,
chevaux de Troie), tout en bloquant les tentatives malveillantes. Ce type
d’installation ne permet cependant pas de détecter du trafic dont l’intention
est de provoquer un déni de service par saturation.
Figure 3 - Positionnement possible des sondes de détection d’intrusions
dans une architecture de réseau classique
• En général, les sondes de détection d’intrusions sont naturellement
installées dans la DMZ (zone démilitarisée) pour surveiller le trafic global
du réseau ou le trafic sur des serveurs sensibles. Dans ce cas, elles doivent
être configurées pour comprendre la direction des différents flux
d’information, afin en particulier de déterminer si le trafic d’attaque
provient de l’Internet ou si des machines de la DMZ, ayant été attaquées et
compromises par ailleurs, sont utilisées dans des scénarios d’attaque. C’est
une configuration souvent délicate à mettre en œuvre car de nombreux
outils de détection d’intrusions ont une notion de réseau interne et
externe, et cherchent essentiellement des attaques depuis le réseau
externe vers le réseau interne.
• La figure 3 résume les implantations possibles des différents composants
dans un réseau d’entreprise, ainsi que le type de configuration appliqué
aux sondes. Les consoles de gestion des alertes sont absentes de la figure
car elles se présentent le plus souvent sous la forme de clients légers, par
exemple navigateurs web ou applications java, qui accèdent au
concentrateur d’alertes à partir de PC sur le réseau d’entreprise.
• Dans ce schéma, il convient de noter que la traversée de plusieurs pare-feu
peut se révéler nécessaire pour faire communiquer les différentes entités.
• Il faut donc s’assurer que les sondes peuvent travailler dans les deux modes
push (initiation des connexions par la sonde) et pull (initiation des connexions
par les consoles) afin de ne pas souffrir de problèmes de configuration. L’idéal
pour la sécurité et la disponibilité des communications est de disposer d’un
réseau physiquement séparé. En pratique, on se contentera de VLAN (Virtual
Local Area Network) et de configurations spécifiques des commutateurs
assurant une bonne priorité du trafic d’alertes en cas de surcharge.
• 4.3 Maintenance opérationnelle
• 4.3.1 Logiciel
• Les mises à jour du logiciel des sondes de détection d’intrusions sont
programmées à une fréquence au moins annuelle et ces mises à niveau sont
obligatoires pour préserver leur efficacité. Par conséquent, une révision du
déploiement de n’importe quel système de détection d’intrusions est
susceptible de se produire annuellement.
• L’impact du déploiement du système de détection d’intrusions doit être évalué.
En particulier, il faut vérifier s’il y a des exigences de qualification sur des
machines d’essai avant la mise en production.
• L’impact sur les performances du réseau ou des serveurs doit être mesuré.
Finalement, les changements de configuration du réseau ou des serveurs, et les
coupures de service, doivent être pris en compte.
• 4.3.2 Signatures
• Les signatures constituent le cœur de tous les systèmes de détection
d’intrusions. De nouvelles vulnérabilités ou méthodes d’évasion apparaissent
fréquemment, et donc les signatures doivent être mises à jour pour bénéficier
d’une détection efficace des attaques les plus récentes. Les mises à jour des
signatures sont disponibles chez la plupart des fournisseurs avec une fréquence
mensuelle, parfois plus souvent quand beaucoup de nouvelles vulnérabilités
critiques ou des attaques à grande échelle apparaissent. Ces mises à jour
prennent souvent la forme d’une configuration manuelle dans les cas urgents,
et la signature « officielle » n’est intégrée que plus tard. Ces mises à jour sont
importantes aussi du côté du logiciel, car de nouvelles attaques peuvent
demander de nouvelles fonctionnalités du logiciel d’analyse pour être
détectables. Les nouvelles signatures utilisent naturellement les nouvelles
fonctionnalités logicielles disponibles, et donc les logiciels doivent également
être mis à jour régulièrement.
• En déployant un système de détection d’intrusions, une phase
d’apprentissage et d’ajustement des configurations est très probablement
nécessaire. La liste suivante donne une indication des points à prendre en
compte tout en projetant un déploiement de la technologie :
• déployer en utilisant une politique très large de sécurité, et puis
restreindre en fonction des besoins réels pour réduire le nombre
d’alertes. Cela doit être fait en prenant en compte la charge du réseau ou
du serveur, et la charge des opérateurs et des analystes. Cette phase de
réglage dure environ deux semaines. Il faut s’attendre à recevoir un grand
nombre d’alertes, et donc être très attentif dans les premiers jours pour
désactiver rapidement les signatures induisant des avalanches d’alertes.
En particulier, les signatures surveillant des événements normaux, comme
un échange de cookies HTTP, peuvent avoir ce comportement ;
• déployer de manière restrictive en ne surveillant que peu de protocoles
ou de vulnérabilités et augmenter progressivement la couverture. Cela
permet de bien mesurer l’impact de chaque protocole individuellement
sur le réseau surveillé.
• Les protocoles d’annuaires (DNS, LDAP : Lightweight Directory Access
Protocol), de partages de fichiers (NFS : Network File System, Netbios) et
de connexion web (HTTP) peuvent être étudiés séparément pour mesurer
leur pertinence dans l’environnement surveillé.
• Cookies : informations envoyées par un serveur web à un navigateur,
permettant de réaliser des états dans le protocole HTTP.
• Dans les deux cas, la réduction a lieu non pas en désactivant
définitivement les signatures non désirées, mais en spécifiant pour quelles
machines ou adresses ces signatures doivent être utilisées.
• Un moyen rapide de personnalisation consiste à surveiller non pas une
attaque spécifique mais seulement le protocole présentant un trafic
indésirable.
• Exemple :
• si une machine n’est pas un serveur HTTP, elle ne doit pas recevoir de
trafic sur le port 80.
• 4.4 Traitement des alertes
• 4.4.1 Analyse
• L’analyse des alertes est une tâche très importante pour les systèmes de
détection d’intrusions, car beaucoup de temps est dépensé pour
comprendre si les alertes sont liées à une menace, si elles sont
accidentelles ou si elles sont simplement de fausses alertes. Dans le cas
d’une menace, la gestion des alertes doit aider à déterminer si la menace
correspond à une recherche de vulnérabilités potentielles (scan ) ou à une
tentative réellement malveillante. Elle doit évaluer quel bénéfice pourrait
tirer l’attaquant en cas de réussite, qu’il s’agisse d’un accès malveillant ou
d’un vol d’information.
• La gestion des alertes est une des tâches les plus difficiles à accomplir et
c’est un des chemins d’évolution les plus importants. Les outils
commerciaux dédiés à la gestion des alertes sont encore de première
génération. Ils sont souvent difficiles à installer et à utiliser car ils
interagissent avec des bases de données relationnelles et les sondes du
système de détection d’intrusions.
• Ces systèmes de gestion automatique des alertes sont capables aujourd’hui
de gérer un archivage à long terme, d’établir des rapports sur les tentatives
d’intrusions et de mettre en évidence les alertes majeures. Des fonctions de
corrélation plus élaborées deviendront rapidement disponibles.
• Ces systèmes sont indispensables lorsqu’un déploiement significatif
(dépassant une dizaine de sondes) est envisagé.
• 4.4.2 Réponse
• Les mécanismes de réponse aux alertes doivent permettre de stopper une
attaque ou de limiter ses effets, automatiquement. Ils doivent tout d’abord
préserver le fonctionnement normal du système d’information. Dans l’état
de l’art actuel, peu d’options sont disponibles, et leur efficacité est limitée.
Les options principales sont la fermeture de la connexion TCP incriminée
par insertion de paquets RST dans le flux réseau (peu efficace car cela oblige
à deviner certains paramètres de la communication), la reconfiguration du
pare-feu pour bloquer les communications avec les adresses identifiées
comme malveillantes et le blocage de comptes utilisateurs.
• Appliquer des mécanismes de réponse automatique est risqué aujourd’hui,
car l’on observe encore des taux trop élevés de fausses alarmes. Ces
mécanismes sont aussi facilement détectés par les attaquants, qui peuvent
ensuite les utiliser pour des dénis de service auto-infligés.
• Exemple :
• si le mécanisme choisi est la reconfiguration du pare-feu, un attaquant
peut simuler un grand nombre d’adresses différentes (IP spoofing ) et
ainsi forcer le fournisseur de service à refuser un grand nombre de
communications.
• IP spoofing : pratique par laquelle l’attaquant va initialiser des
communications avec des adresses IP différentes de celles de sa machine.
Cela permet de mettre en œuvre les attaques par réflexion, ou de
nombreuses attaques par déni de service.
• La réponse à une intrusion est une question de politique de sécurité. Il est
souhaitable de procéder avec des fiches de consigne permettant aux
opérateurs de traiter le plus gros volume d’alertes. Nos expérimentations
montrent qu’en créant des fiches de consignes pour 10 % des signatures,
les opérateurs peuvent traiter 95 % des alertes qui leur sont remontées,
car elles constituent la majorité des occurrences d’alertes. De plus, en cas
d’incident opérationnel (panne de routeur, de serveur), le système de
détection d’intrusions observe des comportements nouveaux en relation
avec la résolution du problème et les alertes correspondantes sont
facilement identifiées et éliminées. Finalement, il convient d’ajouter que
ces comportements sont relativement stables, à savoir que les alertes
majoritaires le resteront vraisemblablement pendant plusieurs mois.
• Les aspects décrits dans les paragraphes 4.4.3, 4.4.4 et 4.4.5 doivent être
pris en considération (dans l’ordre dans lequel ils sont susceptibles
d’apparaître).
• 4.4.3 Gestion des fausses alertes

• La décision d’ignorer une alerte peut être arrêtée soit en phase de
déploiement, soit en usage réel. Pendant le déploiement, l’efficacité de
chaque signature doit être évaluée et des modifications peuvent lui être
apportées pour convenir à la configuration du site (restriction d’application
à certaines adresses IP, à certaines périodes). Pendant l’utilisation
normale, les fausses alertes seront conservées pour l’analyse des
tendances.
• La gestion des fausses alertes peut se faire en utilisant des fiches de
consignes aux opérateurs. Lorsqu’une « nouvelle » fausse alerte est
observée, elle est traitée par des experts (typiquement, un support de
niveau 3 en langage opérationnel), et un des résultats attendus de ce
traitement est la création d’une nouvelle fiche de consigne ou la
modification d’une fiche de consigne existante si les conditions de
traitement ont été modifiées. Un audit périodique de ces fiches de
consigne doit permettre de supprimer les plus anciennes, lorsque les
signatures incriminées sont améliorées par les vendeurs et ne donnent
plus de fausses alertes.
• 4.4.4 Gestion des incidents internes
• Un incident interne correspond à la réception d’une alerte telle qu’un
cheval de Troie, qui n’implique pas forcément la coopération
intentionnelle de la victime. Lorsqu’une telle alerte est reçue, il convient
d’informer rapidement l’utilisateur visé. La plupart des produits antivirus
sont capables de détecter les chevaux de Troie, il est donc nécessaire de
prévoir une gestion des doublons d’alertes (voir Virus informatiques).
• Les alertes provenant de machines internes permettent de surveiller des
machines dont la configuration n’est pas gérée suivant des procédures
standards, comme les machines de laboratoire, et dont la configuration
est plus sensible à des attaques. Les alertes des systèmes de détection
d’intrusions, dans un contexte interne, peuvent être assimilées aux alertes
provenant des antivirus, et la même procédure peut être appliquée.
• 4.4.5 Gestion des tentatives d’attaque externe

• Étant donné le nombre de tentatives visant à recueillir de l’information
sur un site (balayage d’adresses, balayage de ports et autres), beaucoup
d’opérateurs de réseau et systèmes d’administration ont abandonné la
recherche des coupables. En outre, dans de nombreux cas, l’information
employée pour identifier l’attaquant est incorrecte ou inexploitable. Il
semble que la nouvelle tendance soit d’entrer en contact avec les
fournisseurs d’accès Internet en amont pour éviter d’avoir à gérer des
relations avec les différents contrevenants.
• Balayage d’adresses (address scan, address sweep ) : recherche par un
attaquant des machines existantes dans une plage d’adresses IP. À la fin
du processus, l’attaquant obtient une liste d’adresses IP actives.
• Exploration de ports (portscan ) : recherche par un attaquant des services
offerts par une machine particulière. Ce type de recherche est effectué
conjointement avec l’exploration d’adresses, pour obtenir la topologie du
réseau cible.
• L’utilisation de fiches de consignes est impérative pour prévenir une
surcharge de travail pour les opérateurs et une escalade systématique sur
les alertes. Toutes les contre-mesures configurées pour une application
automatique devraient expirer après une (courte) période pour assurer un
fonctionnement fiable si aucune manipulation humaine n’est effectuée.
Dans le cas contraire, le risque d’un déni de service par saturation
provoqué par le système de surveillance lui-même est potentiellement
important.
• 5. Conclusion
• Les outils de détection d’intrusions sont apparus depuis quelques années
maintenant et leur usage se répand dans les systèmes d’information et les
réseaux. Ils sont sortis du domaine militaire et commencent à être intégrés à
la définition des architectures de systèmes d’information commerciaux. Ces
systèmes font pour la plupart de l’analyse de trafic (réseau, requêtes) envoyé
à un système d’information, et recherchent dans leurs bases de
connaissances des éléments identifiant ce trafic comme dangereux.
L’évolution naturelle de ces systèmes conduit à prendre en compte des
descriptions génériques des mécanismes d’attaque, plutôt que la détection
d’attaques spécifiques sur des vulnérabilités connues. Dans un deuxième
temps, il pourra apparaître sur le marché des systèmes de détection
d’intrusions utilisant des notions de politique de sécurité pour détecter des
actions non conformes à celle-ci, même si l’attaque sous-jacente n’est pas
explicitement identifiée.
• Il existe sur le marché des systèmes dits de prévention (Intrusion Prevention
Systems : IPS). Il ne s’agit pas là d’une nouveauté, mais de technologies
similaires à celles listées ici. Leur usage est cependant plus actif, puisqu’il
s’agit non plus de générer des alertes mais de bloquer les échanges identifiés
comme dangereux. On peut donc s’attendre à une convergence entre les
pare-feu applicatifs et les systèmes de détection d’intrusions dans quelques
années, lorsque ces derniers auront acquis un degré de fiabilité suffisant pour
ne pas donner lieu à des dénis de service contre des utilisateurs légitimes.
• Annexe
1
2 Organismes
3 Logiciels
4 Bases de données
• 1
• Thèses
• MICHEL (C.) - Langage de description d’attaques pour la détection
d’intrusions par corrélation d’événements ou d’alertes en environnement
réseau hétérogène. - Thèse de doctorat, université de Rennes-I (2003).
• ZIMMERMANN (J.) - Détection d’intrusions paramétrée par la politique
par contrôle de flux de références. - Thèse de doctorat, université de
Rennes-I (2003).
• MARRAKCHI (Z.) - Détection d’intrusions comportementale dans les
systèmes à objets répartis. - Thèse de doctorat, université de Rennes-I
(2002).
• TIBOURTINE (K.) - Détection d’intrusions dans les réseaux de
communication. - Thèse de doctorat, université de Paris-XI (1995).
• DEBAR (H.) - Application des réseaux de neurones à la détection
d’intrusions sur les systèmes informatiques. - Thèse de doctorat,
université de Paris-VI (1993).
• 2 Organismes
• Internet Engineering Task Force (IETF) http:/www.ietf.org
• Intrusion Detection Exchange Format Working Group (IDWG)
http://www.ietf.org/html.charters/idwg-charter.html
• NSS Group http://www.nss.co.uk
• 3 Logiciels
• Snort http://www.snort.org
• Stide (Sequence Time-Delay Embedding)
http://www.cs.unm.edu/~immsec/systemcalls.htm
• Nessus http://www.nessus.org
• Prelude http://www.prelude.ids.org
• Open Source Security Information Management (OSSIM)
http://www.ossim.net
• 4 Bases de données
• Snort Signature Database http://www.snort.org/snort-db

• Bugtraq http://www.securityfocus.com/bid
• Common Vulnerabilities and Exposures (CVE) http://cve.mitre.org
• Open Source Vulnerability Database (OSVDB) http://www.osvdb.org

Analyse Et Detection Des Intrusions

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analyse Et Detection Des Intrusions

Uploaded by

Copyright:

Available Formats

ANALYSE ET DETECTION DES

• 4. Préparation et mise en œuvre

sécurité. À l’origine, les virus se propageaient lentement, par l’échange de

• L’objectif de ces systèmes de détection d’intrusion aujourd’hui est

• 1.1.1 Difficulté de mise en œuvre des mesures

• 1.1.2 Complexité des technologies de filtrage

• 1.1.3 Objectifs des systèmes de détection d’intrusions

• 1.2 Description d’un système de détection d’intrusions

Figure 1 - Concepts de la détection d’intrusions

• 2.1.1 Description des scénarios

• 2.1.2 Scénarios et fausses alertes

• 2.2.1 Description du modèle de bon comportement

• 2.2.3 Approche comportementale et non-détection

• 3.1.4 Préparation des données

• 4.1.4 Logiciel libre ou produit commercial

• 4.1.5 Technologies et outils connexes

• 4.4.3 Gestion des fausses alertes

• 4.4.5 Gestion des tentatives d’attaque externe

• Snort Signature Database http://www.snort.org/snort-db

You might also like