Détection autonome de trafic malveillant dans les réseaux véhiculaires

 La détection d’intrusions et de déni-de-service 

La détection d’intrusions ou d’attaques par déni-de-service est un domaine de recherche depuis longtemps exploré par la communauté scientifique. De nombreuses méthodes ont ainsi été conçues afin de détecter les intrusions ou attaques par dénide-service dans les réseaux. Historiquement, celles-ci étaient d’abord basées sur les connaissances d’experts qui étaient chargés de produire des signatures précises d’attaques connues afin que ces dernières soient détectées par le système de détection si elles venaient à apparaître sur le réseau surveillé. Par exemple, le système de détection d’intrusions open-source Suricata 1 utilise des règles comme celle présentée dans la Figure 1.2. On y distingue trois groupes, en rouge l’action qui sera réalisée si cette règle est déclenchée, en l’occurrence une alerte. L’entête de la règle est représenté en vert, dans ce cas on s’intéresse à n’importe quel flux TCP en partance du réseau surveillé ($HOME_NET) vers l’IP sur le port 80. Enfin, les options relatives à cette règle sont en bleu, on y trouve le message d’alerte qui sera affiché par Suricata (msg) et d’autres informations comme la référence vers une description de l’attaque (ref:url) ou encore le type d’attaque (classtype). Dans le cas présent, il s’agit d’une règle destinée à détecter du trafic généré par un Botnet désirant communiquer avec son centre de commande. Ces méthodes sont extrêmement efficaces pour détecter les attaques connues avec grande précision. Cependant, elles sont incapables de détecter des attaques inconnues et la base des signatures doit constamment être mise à jour afin de se protéger contre les nouvelles attaques ce qui s’avère extrêmement coûteux. De plus, il peut arriver qu’il se passe plusieurs jours entre l’apparition d’une nouvelle attaque et sa découverte par les experts, durée pendant laquelle le système d’information reste à la merci de l’attaque. Ainsi, d’autres méthodes comme celles basées sur les spécifications ont été conçues afin d’être en mesure de détecter des attaques inconnues ou des variations d’attaques existantes. Cependant, les méthodes basées sur la spécification des protocoles de communication ou des applications sont difficiles à mettre en place, car il est nécessaire d’établir le comportement de ces derniers de manière exhaustive ce qui est coûteux et complexe. Ainsi, l’application de ces méthodes est restreinte à des scénarios où le nombre d’applications et protocoles est limité. Une autre solution consiste en l’utilisation d’algorithmes d’apprentissage automatique appliqués à la détection d’anomalies. Un des premiers exemples de l’application de ces algorithmes dans les réseaux mobiles remonte à 1998 où Buschkes et al. [20] proposaient déjà une approche basée sur la création de profils d’utilisateurs et reposant sur des réseaux Bayésien pour la détection d’anomalies. Dans cette section, nous présentons les grandes familles d’approches par apprentissage automatique appliqués à la détection d’anomalies. 

  Terminologie 

La détection d’anomalies dans les réseaux consiste en l’observation des communications à la recherche de motifs ou d’événements différents d’une situation 1.2. La détection d’intrusions et de déni-de-service .Exemple d’une anomalie collective. Figure 1.3 – Illustrations des différents types d’anomalies définis par [24]. normale. En effet, l’hypothèse est que les attaques informatiques telles que les tentatives d’intrusion ou les déni-de-service sont des événements rares par rapport à l’ensemble des communications sur le réseau surveillé. Chandola et al. [24] définissent plusieurs types d’anomalies : ponctuelle, contextuelle ou collective illustrées par la Figure 1.3. 

 Anomalie ponctuelle 

Les anomalies ponctuelles représentent des instances de données considérées comme anormales en rapport avec le reste du corpus de données observé. La Figure 1.3a représente ces anomalies. On y observe deux régions de données dites habituelles, c’est-à-dire que l’ensemble des données du corpus ont tendance à être inscrites à l’intérieur de cette région. Les points θ1, θ2 quant à eux, représentent des anomalies à l’intérieur de ces données. Par exemple, durant une attaque par déni-de-service, le nombre de demandes de connexions auprès d’un serveur croît énormément de façon à priver les demandes légitimes de l’accès au serveur. Ainsi, cet afflux massif constitue une anomalie du fait du nombre aberrant de connexions au serveur à un instant donné. 18 Chapitre 1. Contexte Scientifique et État de l’art 

Anomalie contextuelle

 Les anomalies contextuelles sont des événements considérées comme anormaux par rapport à un contexte particulier, mais qui pourraient être considérés comme normaux dans un autre contexte. Une illustration de ce genre d’anomalies est représentée dans la Figure 1.3b. L’anomalie est illustrée par le point θ1, on constate que sa valeur est présente dans le corpus de données, mais n’est pas prévue à l’instant auquel elle apparaît. Dans cet exemple, imaginons que le débit de données observé sur un poste de travail a pour habitude d’être élevé la journée et faible la nuit. Ainsi, constater un débit élevé la nuit pourrait être le signe d’une intrusion sur ce poste. 

Anomalie collective 

Les anomalies collectives sont liées à une collection de données liées entre elles et considérées comme anormales par rapport à l’ensemble des autres données. Ce type d’anomalie est illustré par la Figure 1.3c où la séquence Θ représente des points collectivement anormaux par rapport au reste des données. Pour autant, il n’est pas nécessaire que chaque instance à l’intérieur de la collection soit considérée comme anormale : seul l’ensemble est considéré comme tel. Un exemple d’attaque représentant ce genre d’anomalie serait une attaque par déni-de-service appliquant la méthode de «slow growth». Dans cette méthode, au lieu de soumettre la victime à un trafic intense dès le début de l’attaque, celui-ci croît continuellement jusqu’à ce que la machine victime ne puisse plus répondre à de nouvelles requêtes. Cette méthode habitue le système au cours du temps à ne pas considérer l’attaque comme telle, mais simplement comme une évolution du trafic habituel.