Les systèmes de détections d’intrusions - Sécurité Réseau

1. Les systèmes de détections d’intrusions

 
La sécurité des systèmes d'information vise à garantir la confidentialité, l'intégrité et la disponibilité des services. C'est une tâche difficile, tout particulièrement dans un contexte de connectivité croissante.

 
Pour améliorer la sécurité, il faut mettre en place des mécanismes, d'une part pour assurer que seules les personnes autorisées peuvent consulter ou modifier des données, d'autre part pour assurer que les services peuvent être rendus correctement.

    
La première mesure à prendre est la protection physique des équipements. Les accès aux locaux et aux unités centrales doivent être contrôlés car, par exemple, tous les efforts de protection de données sont vains si on peut s'emparer du disque dur.

        
Il faut également mettre en œuvre les mécanismes d'authentification et de contrôle d'accès. L'authentification consiste pour l'utilisateur à prouver son identité au système d'une ou plusieurs façons : mot de passe, objet de sécurité (carte à puce, clef électronique) ou biométrie (empreinte digitale, vocale ou rétinienne). Le contrôle d'accès permet de définir les droits que l'on accorde aux différents utilisateurs sur les données (droits de lecture, écriture et exécution) ou les machines (droit de se connecter).

     
L'étape suivante consiste à utiliser des outils d'analyse automatique des vulnérabilités du système (ex : COPS, SATAN). Cela permet de trouver certaines failles dues à une mauvaise configuration du système. Ainsi, des droits d'accès trop permissifs à des fichiers sensibles ou à des machines peuvent permettre à un utilisateur, par un enchaînement approprié de commandes, d'obtenir des privilèges d'accès supérieurs à ceux prévus initialement.

          
Avec l'interconnexion croissante des réseaux et le développement de l'internet, les possibilités d'attaque à distance ont considérablement augmenté. Pour contrôler au niveau réseau l'accès à une machine depuis l'extérieur, il faut installer un pare-feu qui devient un point de passage obligé. Il a pour rôle de filtrer les paquets indésirables échangés avec l'extérieur (services non disponibles, adresse source suspecte, adresse destination prohibée) et de relayer les flux applicatifs. Il permet par ce biais d'éviter de nombreuses attaques en déni de service (Ping Of Death, SYN Flood, ...) et réduit le nombre d'informations que l'on peut collecter sur le réseau interne à partir de l'extérieur.

         
Malheureusement, il existe la plupart du temps des moyens pour contourner les mécanismes évoqués ci-dessus. Pour ce faire, il n'est même plus nécessaire d'être un pirate expérimenté car de nombreux « outils » sont offerts sur l'internet. Ces outils exploitent les failles qui sont continuellement découvertes dans les systèmes, services et protocoles.

         
Les pare-feux, aussi indispensables soient-ils, ne doivent pas être pris pour la panacée. En effet, ils ne protègent, ni d'une configuration incomplète ou erronée, ni de ce qui les traverse en mode « tunnel ». Par ailleurs, ils peuvent être compromis par un attaquant externe. De plus, ils sont impuissants face à une menace interne (80% des attaques seraient d'origine interne) puisqu'ils ne surveillent que les échanges réseau avec l'extérieur.

            
On ne peut donc envisager un système sécurisé sans contrôle de ce que font les utilisateurs. C'est le rôle de l'audit de sécurité et de la détection d'intrusions.

       
1.1 La détection d'intrusions : une nécessité

        
L'audit de sécurité est un mécanisme intégré aux systèmes d'exploitation et à toutes les grandes catégories d'applications. Il permet d'enregistrer tout ou partie des actions effectuées sur le système. Une analyse ultérieure des informations enregistrées doit permettre de détecter d'éventuelles intrusions. Cette analyse est appelée détection d'intrusions.

       
Il n'est pas envisageable de faire cette détection manuellement car la recherche d'actions suspectes se fait dans d'immenses volumes de données. Il a donc fallu trouver des méthodes et développer des outils pour analyser automatiquement les traces d'audit.

       
Le grand nombre de systèmes de détection d'intrusions développés à ce jour, ne permet pas d'en envisager une présentation exhaustive. Nous présentons donc dans ce paragraphe une typologie des méthodes proposées à ce jour. On reprend à cet effet un travail fait dans le laboratoire d'IBM à Zurich, qui utilise les critères de classification suivants (voir figure 1) :

      

• Le principe de détection utilisé,
• Le comportement en cas d'attaque détectée,
• La source des données à analyser,
• La fréquence d'utilisation.

       
1.1.1 Principes de détection
       

          
Les deux approches qui ont été proposées à ce jour sont l'approche comportementale et l'approche par scénarios. La première se base sur l'hypothèse que l'on peut définir un comportement « normal » de l'utilisateur et que toute déviation par rapport à celui-ci est potentiellement suspecte. La seconde s'appuie sur la connaissance des techniques employées par les attaquants : on en tire des scénarios d'attaque et on recherche dans les traces d'audit leur éventuelle survenue.

    
1.1.1.1 L'approche comportementale

     
Le comportement normal d'un utilisateur ou d'une application (profil) peut être construit de différentes manières. Le système de détection d'intrusions compare l'activité courante au profil. Tout comportement déviant est considéré intrusif. Parmi les méthodes proposées pour construire les profils, les plus marquantes sont les suivantes :

         

• Méthodes statistiques : Le profil est calculé à partir de variables considérée comme aléatoires et échantillonnées à intervalles réguliers. Ces variables peuvent être le temps processeur utilisé, la durée et l'heure des connexions, etc. Un modèle statistique (ex : covariance) est alors utilisé pour construire la distribution de chaque variable et pour mesurer, au travers d'une grandeur synthétique, le taux de déviation entre un comportement courant et le comportement passé. L'outil NIDES utilise, entre autres, cette méthode.

       

• Systèmes experts : Ici, c'est une base de règles qui décrit statistiquement le profil de l'utilisateur au vu de ses précédentes activités. Son comportement courant est comparé aux règles, à la recherche d'une anomalie. La base de règles est rafraîchie régulièrement. L'outil Wisdom&Sense utilise cette méthode, aujourd'hui tombée en désuétude.

        

• Réseaux de neurones : La technique consiste à apprendre à un réseau de neurones le comportement normal d'un utilisateur. Par la suite, lorsqu'on lui fournira les actions courantes, il devra décider de ¨    leur normalité. L'outil Hyperview comporte un module de ce type et plusieurs travaux de recherche vont dans le même sens. Cette méthode reste prometteuse, mais n'est pas encore industrialisée.

        

• Immunologie : Cette analogie informatique de l'immunologie biologique a été proposée par Forrest. Il s'agit de construire un modèle de comportement normal des services réseaux Unix (et non un comportement normal d'utilisateurs). Le modèle consiste en un ensemble de courtes séquences d'appels système représentatifs de l'exécution normale du service considéré. Des séquences d'appels étrangères à cet ensemble sont alors considérées comme la potentielle exploitation d'une faille du service.

     
L'approche comportementale permet de détecter des attaques inconnues auparavant ainsi que les abus de privilèges des utilisateurs légitimes du système. Par contre, le comportement de référence n'étant jamais exhaustif, on s'expose à des risques de fausses alarmes (faux positifs). De plus, si des attaques ont été commises durant la phase d'apprentissage, elles seront considérées comme normales (risque de faux négatifs).

    
1.1.1.2. L'approche par scénarios

        
Des scénarios d'attaques sont construits et l'analyse des traces d'audit se fait à la recherche de ces scénarios. Les méthodes proposées à ce jour et à cet effet sont les suivantes :

     
Systèmes experts : Le système expert comporte une base de règles qui décrit les attaques. Les événements d'audit sont traduits en des faits qui ont une signification sémantique pour le système expert. Son moteur d'inférence décide alors si une attaque répertoriée s'est ou non produite. Les outils récents ne l'utilisent plus.
Algorithmes génétiques : L'outil GASSATA utilise des algorithmes génétiques pour rechercher des attaques dans des traces d'audit. Chaque individu de la population code un sous-ensemble particulier d'attaques qui sont potentiellement présentes dans les traces d'audit. La valeur d'un individu est proportionnelle au degré de réalisme de l'hypothèse qu'il code, au vu du fichier d'audit.

         
Pattern matching : Il s'agit là de la méthode la plus en vue actuellement. Des signatures d'attaques sont fournies, à des niveaux sémantiques divers selon les outils (de la suite d'appels système aux commandes passées par l'utilisateur). Divers algorithmes sont utilisés pour localiser ces signatures dans les traces d'audit.

   
On peut voir deux inconvénients à cette approche : on ne peut détecter que des attaques connues et il faut remettre à jour la base de scénarios d'attaque très souvent.

  
1.1.1.3. Approche comportementale ou approche par scénarios ?

    
Chacune de ces deux approches présente des avantages et des inconvénients (voir tableau 1). C'est pourquoi une approche hybride semble indispensable.
        

Tableau 8 : Approche comportementale ou approche par scénarios ?

1.1.2 Comportements en cas d'attaque détectée

       
Une autre façon de classer les systèmes de détection d'intrusions, consiste à voir quelle est leur réaction lorsqu'une attaque est détectée. Certains se contentent de déclencher une alarme (réponse passive) alors que d'autres prennent des mesures correctives (réponse active).

          
La plupart des systèmes de détection d'intrusions n'apportent qu'une réponse passive à l'intrusion. Lorsqu'une attaque est détectée, ils génèrent une alarme en direction de l'administrateur système par email, message dans une console, voire même par beeper. C'est lui qui devra prendre les mesures qui s'imposent.

           
Si le système est plus sophistiqué (et surtout plus récent), il peut prendre automatiquement des mesures pour empêcher ou stopper l'attaque en cours. Par exemple, il coupera les connexions suspectes ou même (pour une attaque distante) reconfigurera le pare-feu pour qu'il refuse tout ce qui vient du site incriminé. Il pourra également prévenir l'administrateur.

       
1.1.3. Sources des données à analyser

         
Les sources possibles de données à analyser sont une caractéristique essentielle des systèmes de détection d'intrusions. Les données proviennent, soit de fichiers générés par le système d'exploitation, soit de fichiers générés par des applications, soit encore d'informations obtenues en écoutant le trafic sur le réseau.

       
1.1.3.1. Sources d'information système

        
Un système d'exploitation propose plusieurs sources d'information :

         

• Historique des commandes systèmes : Tous les systèmes d'exploitation fournissent des commandes pour avoir un "instantané" de ce qui se passe. Ainsi, sous UNIX, des commandes telles que ps, pstat ou vmstat fournissent des informations précises sur les événements système.

       

• Accounting : L'accounting fournit de l'information sur l'usage des ressources partagées par les utilisateurs (temps processeur, mémoire, espace disque, débit réseau, applications lancées, ...).

       

• Système d'audit de sécurité : Tous les systèmes d'exploitation proposent ce service pour définir des événements, les associer à des utilisateurs et assurer leur collecte dans un fichier d'audit. On peut donc potentiellement disposer d'informations sur tout ce que font les utilisateurs : accès en lecture à un fichier, exécution d'une application, etc.

Les outils utilisant ces sources de données sont appelés Host Based Intrusion Detection System, HIDS.

      
1.1.3.2. Sources d'information applicatives

           
Les grandes catégories d'applications savent toutes générer des informations sur l'utilisation qui en est faite. C'est le cas des fichiers de logs générés par les serveurs ftp et les serveurs web. Peu de systèmes de détection d'intrusions les utilisent. On peut toutefois citer l'outil WebStalker.

         
1.1.3.3. Sources d'information réseau

              
Des dispositifs matériels ou logiciels (sniffers) permettent de capturer le trafic réseau. Cette source d'information est intéressante car elle permet de rechercher les attaques en déni de service qui se passent au niveau réseau et les tentatives de pénétration à distance. Néanmoins, il est difficile de savoir qui est à l'origine de l'attaque car il est facile de masquer son identité en modifiant les paquets réseau. Presque tous les outils (commerciaux) récents utilisent cette source d'information.
Les outils utilisant ces sources de données sont appelés Network Based Intrusion Detection System, NIDS.

         
1.1.4. Fréquence d'utilisation

            
La dernière caractéristique des systèmes de détection d'intrusions est leur fréquence d'utilisation : périodique ou continue. Certains systèmes de détection d'intrusions analysent périodiquement les fichiers d'audit à la recherche d'une éventuelle intrusion ou anomalie passée. Cela peut être suffisant dans des contextes peu sensibles (on fera alors une analyse journalière, par exemple).

             
La plupart des systèmes de détection d'intrusions récents effectuent leur analyse des fichiers d'audit ou des paquets réseau de manière continue afin de proposer une détection en quasi temps-réel. Cela est nécessaire dans des contextes sensibles (confidentialité) et/ou commerciaux (confidentialité, disponibilité). C'est toutefois un processus coûteux en temps de calcul car il faut analyser à la volée tout ce qui se passe sur le système.

             
1.2. Les limites actuelles de la détection d'intrusions

         
Nous avons déjà évoqué les inconvénients inhérents à chaque approche de la détection d'intrusions. Tout outil implémentant une approche présente bien sûr les inconvénients de cette approche. Nous n'y revenons donc pas.

           
Les systèmes de détection d'intrusions actuels sont trop fermés, ce qui limite, d'une part les possibilités de comparaison de performance, d'autre part les possibilités de coopération. Pourtant, diverses initiatives tendent à résoudre ce problème. Ainsi le groupe de travail Common Intrusion-Detection Framework (CIDF) vise à définir un standard d'interopérabilité entre outils. Par ailleurs, l'IETF a créé récemment un autre groupe, Intrusion Detection Working Group (IDWG), qui vient de commencer ses travaux. Nous ne développons pas plus ici.

           
Bien que le but principal des outils soit de détecter des intrusions afin de s'en protéger, un but annexe pourrait être de fournir des preuves lorsque des poursuites en justice sont envisagées. Dès lors, un problème se pose : l'inadéquation entre les preuves exigées par les tribunaux et celles fournies par les outils. Ceux-ci peuvent fournir des fichiers de logs du système, leurs propres diagnostics, une partie du trafic réseau capturé durant l'attaque, des adresses IP incriminées et divers autres fichiers. Pour autant, comment prouver que tout cela n'a pas été altéré, surtout si l'attaque a réussi ? Quels mécanismes peuvent garantir de manière sûre l'horodatage des événements sur l'ensemble du réseau ? Et surtout, comment prouver que les logiciels qui ont collecté ces preuves sont exempts de bugs lorsque l'on ne peut pas avoir accès au code source ? On le voit, les outils actuels ne peuvent prétendre délivrer des preuves légales d'intrusions.

            
Au delà de ces deux limites, il y a plus grave. Les systèmes de détection d'intrusions actuels peuvent être mis en défaut, soit parce qu'ils sont incapables de détecter certains types d'attaque, soit parce qu'ils sont eux-mêmes attaquables.

        
1.2.1 Attaques non détectables

       
Nous l'avons mentionné, certains systèmes récents permettent de prendre automatiquement des contre-mesures. Un attaquant suffisamment doué peut effectuer une attaque qui aura l'air de provenir d'une machine du réseau interne. L'outil coupera alors les connexions avec la machine incriminée, ce qui constitue un déni de service.

            
Un nouveau type d'attaque met en défaut tous les outils actuels : plusieurs personnes effectuent une attaque distribuée conjointe à la cadence d'une action toutes les quelques heures. La distribution et la lenteur de l'attaque la fait passer inaperçue.

        
Les outils basés réseau présentent quant à eux des faiblesses intrinsèques :

        

• Ceux qui surveillent en temps-réel le trafic sont incapables de suivre les débits des réseaux frame relay ou ATM.
• Une attaque qui consiste à envoyer des paquets altérés. Certains des paquets ne sont pris en compte que par une des deux machines, celle sur laquelle tourne l'outil de détection ou celle attaquée. Ainsi l'outil n'analyse pas réellement ce qui est vu par la machine cible.

         
1.2.2 Attaque des outils eux-mêmes

          
Les outils de détection d'intrusions peuvent eux-mêmes être la cible d'attaques les rendant inopérants sur un ou plusieurs aspects. L'attaque réelle passera ensuite inaperçue. Chacun des composants peut être attaquée : le module qui fournit les données à analyser (système d'audit ou autres), le module d'archivage, l'éventuel module de contre-mesures, le module d'analyse :

             

• Si on réussit à empêcher l'arrivée des données en entrée, la détection d'intrusions s'arrête, bien sûr.
• Si le dispositif d'archivage peut être compromis, alors on ne peut assurer, ni l'enregistrement effectif des détails d'une attaque, ni son intégrité.
• Si le module de contre-mesures est mis hors-service, alors l'attaque peut continuer puisque l'outil est incapable de réagir. Il n'y a que l'administrateur (s'il est présent) qui puisse agir après notification de l'intrusion.
• Le module d'analyse peut être mis à bout de ressources. En déterminant ce qui demande le plus de ressource à l'outil, un attaquant peut le surcharger avec des activités inutiles. Une autre manière de faire consiste à forcer l'outil à allouer toute la mémoire dont il dispose pour analyser des actions sans intérêt. Pour continuer à tourner, il sera amené à libérer de la mémoire en cessant, par exemple, la surveillance de connections restées inactives depuis longtemps. Toute attaque sur l'une d'entre elles restera indétectable. Enfin, si on réussit à faire consommer à l'outil tout son espace disque pour des activités sans importance, il ne pourra plus stocker les événements intéressants. Il n'y aura donc pas de traces d'une intrusion ultérieure.

Conclusion

   
Dans cette partie, on a montré que la détection d'intrusions dans les réseaux ne vient pas concurrencer les mécanismes de sécurité traditionnels mais, au contraire, les compléter. Même si on ne peut pas atteindre la sécurité absolue, on veut au moins pouvoir détecter l'intrusion afin d'y remédier. On a également présenté les principes mis en œuvre par les systèmes de détection d'intrusions pour atteindre leur but. Finalement, on a vu que de nombreux problèmes restent à résoudre avant que la détection d'intrusions soit fiable.
Cette technologie n'est pas encore arrivée à maturité et les outils existants ne sont pas toujours à la hauteur des besoins. Certaines approches théoriques doivent encore être validées dans la pratique. De nouvelles approches demandent encore à être approfondies comme l'immunologie ou les systèmes basés agents.