Introduction à la détection d'intrusion
L'ordinateur se faisant chaque jour plus présent dans nos vies quotidiennes, la question de la sécurité informatique prend elle aussi de l'importance. Avec l'essor d'Internet et du « tout connecté », nous dépendons de plus en plus de la fiabilité de nos appareils, sans même parfois nous en rendre compte. Je vous propose, grâce à cet article, de faire un « premier pas » dans cet univers un peu à part en vous présentant les notions clefs et le vocabulaire de base de la détection d'intrusions.
Cet article est basé, de manière directe et indirecte, sur les cours de Ludovic Mé, dont vous pouvez retrouver une présentation extrêmement intéressante ici (clôture du SSTIC 2013).
« Dura lex, sed lex »
En sécurité informatique, il convient en premier lieu « d’exprimer une politique de sécurité ». D'une certaine manière, il s'agit de définir les propriétés que l'on veut voir respecter au sein de notre système d'information. Le système d'information est l'ensemble des composants informatiques qui peuvent interagir entre eux. Prenons un exemple : pour une entreprise, un système d'information peut potentiellement ressembler à quelque chose comme ça :
- tout le matériel possédé par l'entreprise (postes de travail des employés, serveurs, etc.) ;
- tous les logiciels utilisés par l'entreprise (intranet, extranet, application de pose de congés, etc.) ;
- tous les utilisateurs (on parle souvent de sujets) amenés à se connecter ;
- les données produites et échangées sur le réseau.
Une manière beaucoup plus schématique de voir un système d'information est d'identifier trois composants primaires :
- les sujets du système (ses acteurs, humains ou non) ;
- les objets de ce système (globalement, les données qui sont manipulées) ;
- les actions que les sujets peuvent effectuer sur les objets.
La politique de sécurité va permettre de spécifier qui peut faire quoi sur quoi dans un système d'information. Dans un premier temps, il ne s'agit pas de configurer telle ou telle solution de sécurité, mais bien de spécifier les besoins en terme de sécurité, de la même façon que l'on peut concevoir un logiciel ou écrire le script d'un film, finalement.
Une fois cette politique exprimée, il faut s’assurer de son respect. Cela passe par la bonne configuration des outils utilisés1, mais pas seulement. Il est aussi nécessaire d'utiliser des mécanismes de sécurité afin de structurer la façon dont les utilisateurs accèdent et interagissent aux différents services de votre système d'information. Il s'agit du rôle des mécanismes de contrôle d'accès. Un tel mécanisme doit déterminer si un sujet peut accéder à un objet d'un système. Prenons un nouvel exemple : celui du système d'exploitation. Dans Linux, on peut dire en simplifiant les choses que :
- les sujets sont les utilisateurs du système2 pour lesquels sont exécutés les programmes ;
- les objets sont les fichiers stockés sur le disque dur ;
- les actions sont la lecture, l'écriture et l'exécution d'un fichier.
Sous Linux, le Discretionary Access Control (DAC)3 est le mécanisme de contrôle d'accès utilisé par défaut. Il se manifeste par le biais des commandes chmod et chown, ou encore l'affichage de ls -l (les fameux rwx). Je ne vais pas rentrer dans les détails du fonctionnement du DAC, pas plus que dans ceux de ses nombreux concurrents. Retenez juste l'idée principale : le contrôle d’accès permet de déterminer si un sujet peut effectuer une action sur un objet.
Ces mécanismes qui visent à assurer le respect de la politique de sécurité sont donc « bloquants » et sont censés protéger un système d’information de potentielles attaques. Néanmoins, ils restent des programmes comme les autres et sont sujets eux-mêmes aux vulnérabilités et aux failles. C’est pourquoi des détecteurs d’intrusions (ou IDS pour Intrusion Detection System) ont été développés, ils sont un peu les agents de sécurité « de la dernière chance ».
-
Petit exemple, comme cela. Sur certaine solution logicielle, il existe parfois un « compte par défaut » avec un mot de passe connu. Ce compte peut posséder certains droits et le fait de ne pas le supprimer peut potentiellement permettre à un attaquant d'entrer dans le système. ↩
-
Au sens UNIX, ce qui veut dire qu'il ne s'agit pas forcément d'un humain. Ainsi, il n'est pas rare qu'un serveur web possède son propre compte utilisateur ! ↩
-
Le Discretionary access control ou contrôle d’accès discrétionnaire en bon français est un mécanisme de contrôle d’accès qui définit pour chaque objet du système les droits (lecture, écriture, exécution par exemple) des entités de ce système. Il est dit discrétionnaire, car le sujet qui possède l’objet peut décider de déléguer ses droits. ↩
Les IDS à la rescousse
Un détecteur d’intrusions peut être vu comme une caméra de sécurité1. Une caméra de sécurité est placée à un endroit stratégique et elle capture tous les mouvements à cet endroit. Elle peut ainsi filmer un homme en train de voler la Joconde, mais elle ne peut en aucun cas l’arrêter. C’est une caméra, elle n’a pas de bras2. La seule chose qu'elle peut faire, c'est analyser les images qu'elle capture et prévenir la sécurité en cas de comportement suspect.
Si vous avez compris cela, vous avez compris l’utilité d’un IDS.
Il existe plusieurs types de détecteurs fonctionnant à différents niveaux d’abstractions. On parlera de NIDS pour un détecteur surveillant les paquets réseaux, de HIDS pour un détecteur s’assurant du bon fonctionnement de l’hôte (host) comme le système d’exploitation et l’on parlera plus rarement de AIDS pour un détecteur dédié à une application en particulier.
Il est possible de classer les différents IDS selon deux approches majeures : la détection signature-based et la détection comportementale.
Les signatures ou le délit de sale gueule
Si vous utilisez Windows comme système d’exploitation, il y a de grandes chances pour que vous ayez installé un antivirus. Si vous avez prêté un minimum d’attention à ce dernier, vous avez pu parfois voir s’afficher des messages du genre « La base de données de signatures a été mise à jour. » Ces signatures caractérisent l’approche majoritairement utilisée dans les solutions commerciales d’antivirus et de détecteurs d’intrusion actuelles, on parle d’ailleurs de détection signature-based.
Une signature peut être assimilée à un avis de recherche. Elle décrit précisément ce que le détecteur doit trouver : les preuves de l’exploitation d’une faille de sécurité. Pour les antivirus, il va s’agir du code binaire des malwares s'étant ajouté au contenu d'un exécutable jusqu'alors sain. Il existe des bases de données répertoriant ces codes binaires malicieux, régulièrement mises à jour. Votre antivirus va « simplement » regarder le contenu de chaque exécutable à la recherche de code malveillant. Malheureusement, une menace inconnue restera sous le radar. C’est pour cela que votre antivirus se met à jour aussi souvent que possible : afin d’éviter d’être vulnérable trop longtemps aux virus qui sont lâchés dans la nature chaque jour3.
Il existe une autre approche, suivant une logique complètement inversée, qui vise à pouvoir reconnaître des attaques dont elle ne sait rien a priori.
Un exemple : Snort
Publié sous licence libre (GPL), Snort est un Network-based IDS4 (ou NIDS). Son travail se résume assez simplement : placé à l’entrée de votre réseau, il analyse tous les paquets qu’il récupère, à la recherche d'anomalies. Ces anomalies, il les repère grâce à des signatures textuelles qui ressemblent à ça :
alert ip any any - any any (msg:"Bad-traffic IP Proto 55 IP Mobility";
ip_proto:55; reference:bugtraq,8211; reference:cve, 2003-0567;
classtype:non-standard-protocol; sid:2187; rev:3;)
Cette signature permet de repérer tout trafic passant par le port 55 et d’émettre une alerte le cas échéant.
Snort est sans doute le NIDS le plus populaire du marché. En plus de la — confortable — base de signatures fournie par les développeurs de Snort, il est possible d’écrire ses propres règles. Cela permet aux administrateurs réseau qui repèrent une attaque particulière jusqu’alors inconnue d’écrire leur propre signature afin de pouvoir la détecter de manière automatique par la suite.
L’approche comportementale ou le profilage sécuritaire
Là où l’approche par signature se base sur une connaissance de la menace, l’approche comportementale s’intéresse au système surveillé. Le comportement normal du système est modélisé et le détecteur possède des outils pour relever les différences entre le comportement courant et le comportement normal. Il existe plusieurs manières de « modéliser » un comportement, la plupart ne sont pas triviales et reposent sur des modèles mathématiques probabilistes (les modèles sont alors construits par apprentissage5,6).
Un IDS comportemental ne faisant aucune hypothèse sur les menaces qu’il doit détecter, il est en mesure de découvrir des failles inconnues (appelées communément 0-day). Néanmoins, il ne faut pas sous-estimer la difficulté de construire un modèle exhaustif et représentatif de la réalité.
Un exemple : KBlare
KBlare est un HIDS visant à protéger le noyau Linux issu du projet Blare. Il s'agit d'un projet de l'équipe CIDRE7, qui a connu plusieurs versions successives, au rythme des sujets de thèse le concernant. Ce dernier vise à proposer une « méthode générique » de détection d’intrusion basée sur du suivi de flux. En plus de KBlare, il existe aussi AndroBlare (une version pour Android) et JBlare (une JVM modifiée qui effectue du suivi de flux pour des programmes Java).
L’idée du suivi de flux est somme toute assez intuitive : on veut pouvoir traquer les informations de notre système. Par exemple, prenons le fichier /etc/passwd qui contient les mots de passe sous Linux. Si un programme lit ce fichier et copie son contenu dans un autre fichier, on veut pouvoir le savoir. Dans le cadre du projet Blare, on définit la politique de sécurité de notre système comme une politique de flux d’informations. Plus précisément, on déclare :
- quel est le contenu d’un fichier ($C$) ;
- quel est le contenu autorisé pour un fichier ($P$).
Blare s’assure, pendant l'exécution de notre système, de la cohérence de ce dernier en vérifiant que pour tout fichier, $C \subseteq P$8. On voit ici que l’approche est complètement différente de celle de Snort, car KBlare ne fait aucune hypothèse sur la façon dont se déroule une attaque mais plutôt à ses conséquences9.
Évaluer l’efficacité d’un IDS
Dans la détection d’intrusion, on se base souvent sur quatre indicateurs intéressants :
- les vrais-positifs ($TP$) : l’IDS lève une alerte pour un événement qui est une véritable menace (il a raison) ;
- les faux-positifs ($FP$) : l’IDS lève une alerte pour un événement qui n’est pas une véritable menace (il se trompe) ;
- les vrais-négatifs ($TN$) : l’IDS ne lève pas une alerte pour un événement qui n’est pas une menace (il a raison) ;
- les faux-négatifs ($FN$) : l’IDS ne lève pas une alerte pour un événement qui est pourtant une menace (il se trompe).
À partir de ces indicateurs, on définit deux métriques :
Le $TPR$ (True Positive Rate) est le rapport entre le nombre de menaces détectées (les vrais positifs $TP$) et le nombre total de menaces (les vrais positifs et les faux négatifs $TP + FN$). On veut que le $TPR$ tende vers 1 (ce qui signifie que l’on détecte toutes les menaces).
Le $FPR$ (False Positve Rate) est le rapport entre les fausses alertes (les faux positifs $FP$) et le nombre totale d’événements bénins (les faux positifs et les vrais négatifs $FP + TN$). On veut que le $FPR$ tende vers zéro.
Il faut néanmoins comprendre une chose importante : l’ordre de grandeur du $TPR$ et celui du $FPR$ ne doit pas être le même. Pourquoi ? Parce que le volume d’événements sains est beaucoup plus grand que le volume d’attaques. Ce qui veut dire qu'avec un $FPR = 0,1$, les alertes légitimes sont noyées dans les faux positifs… Il faut garder cela en tête quand vous vous intéressez aux IDS.
Voilà qui conclue ce petit tour d'horizon de la détection d'intrusion. Il existe autant de façons de détecter les intrusions qu’il y a d’IDS. Cependant, on détaille deux grandes « familles » de solutions : l’approche par signature (typiquement utilisée dans les antivirus commerciaux) et l’approche comportementale. Ces dernières ont chacune — comme souvent — leurs avantages et leurs inconvénients et elles ne s’excluent pas ! Les travaux visant à faire coopérer des IDS sont nombreux. On parle alors de corrélation d’alertes. Je ne vais néanmoins pas rentrer dans les détails, car ce n’est ici pas mon but.
Un peu de lecture pour aller plus loin
Si vous n'avez pas peur de lire de l'anglais, je ne peux que vous conseiller
de jeter un coup d'œil vers la littérature scientifique. Très souvent, il existe
une partie entière dédiée à l'état de l'art, qui présente de manière synthétique
ce qui se fait déjà dans le domaine de l'article. Vous pouvez ainsi, entre autre source,
faire des recherches sur Google Scholar
Par exemple, un bon complément à ce très court article serait cet article. Il commence à dater
un peu (2000), mais les grands principes d'un domaine ne changent pas du jour au
lendemain. 
Une autre source d'information intéressante est le canal sécurité informatique de reddit. Les liens que l'on peut y trouver abordent des sujets variés, couvrant aussi bien le côté « défense » de la sécurité informatique que l'aspect « attaque ».
-
En réalité, on parle plus volontiers de « sondes » dans le cadre de la détection d’intrusions. L’idée reste néanmoins la même. ↩
-
Pas de chocolat. ↩
-
Ce qui représente un nombre non négligeable, les vilains cybercriminels ne prenant pas leurs week-ends. ↩
-
Il est aussi présenté comme un IPS (Intrusion Prevention System). La seule différence entre un IDS et un IPS, c’est que là où le premier va lever une alerte pour ce qu’il pense être une action malveillante, le second va la bloquer. ↩
-
Il y aurait beaucoup à dire sur la méthodologie à adopter pour construire un tel domaine, mais ce n’est pas le sujet de cet article. Néanmoins, pour vous donner une idée de ce qui se fait, sachez qu’il y a grossièrement deux approches : l’utilisation du système dans un milieu contrôlé supposé sain (s’il ne l’est pas, on apprend de « mauvaises » choses que l’on ne détectera pas par la suite, car elles seront considérées comme « normales ») ou l’utilisation de traces d’exécution fictives (et donc forcément incomplètes). ↩
-
Une illustration intéressante de cette manière de faire est l’utilisation de N-Grams pour la détection de paquets réseaux malicieux. Si cela vous intéresse, j’avais fait une présentation à ce sujet. À noter que je ne fais que synthétiser le résultat de travaux de recherches dont je ne me prévaux aucunement de la parenté. ↩
-
L'équipe CIDRE est basée à Supélec et dépend de plusieurs organismes de recherche français, en particulier l'INRIA, l'IRISA et le CNRS (la recherche publique en France, c'est parfois compliqué). ↩
-
En réalité, c’est un peu plus compliqué que cela, mais j’aurai sans doute l’occasion d’en reparler dans un autre article. ↩
-
Une question philosophique pour ceux que ça intéresse : une attaque sans conséquence est-elle réellement une attaque ? Vous avez quatre heures. ↩
