5.2 Campagnes d’attaque
5.2.5 Analyse des incohérences de détection
A partir des attaques détectées et des attaques non détectées, nous sommes en mesure de préciser les incohérences dans la détection ou non détection de certaines at- taques. Une incohérence de détection est une attaque non détectée mais dont l’exploit a été utilisé dans une autre attaque détectée (pour des hôtes ou sur un service diffé- rents). Pour chaque incohérence, nous sommes ainsi en mesure de donner les adresses IP, protocoles, ports et identifiants des signatures associées.
5.3
Conclusion
Dans ce chapitre, nous avons présenté la dernière phase du processus d’évaluation et d’analyse des mécanismes de sécurité réseau. Elle concerne l’évaluation des NIDS, guidée par la méthode d’exécution de campagnes d’attaque que nous avons présen- tée dans son ensemble. Elle comprend l’utilisation de trafic d’évaluation modélisé par des automates qui permettent de simuler le trafic nécessaire pour réaliser des sessions d’attaque et analyser ensuite la réaction des systèmes de détection d’intrusion par un calcul de métriques d’évaluation.
Dans le chapitre suivant, nous présentons la plateforme de maquettage et d’ex- périmentation qui nous a permis de valider le développement d’un prototype associé à l’approche présentée jusqu’ici. Nous décrivons également ce prototype, utilisé pour mener des expérimentations sur la plateforme afin de démontrer la faisabilité et l’ef- ficacité des méthodes que nous proposons. Pour finir, nous expliquons nos démarches expérimentales, puis exposons et discutons les résultats d’expérimentation obtenus.
Chapitre 6
Prototype et expérimentations
Sommaire
6.1 Plateforme de maquettage et d’expérimentation . . . 87 6.2 Prototype . . . 89 6.2.1 Architecture logicielle . . . 89 6.2.2 Intégration . . . 94 6.3 Expérimentations et résultats . . . 94 6.3.1 Scénario expérimental . . . 94 6.3.2 Résultats expérimentaux . . . 98 6.4 Conclusion . . . 104
Dans ce chapitre, nous présentons d’abord la plateforme de maquettage et d’ex- périmentation qui a été le support pour le prototypage de notre approche. Puis, nous décrivons le prototype développé pour mettre en œuvre les différentes méthodes d’éva- luation et d’analyse présentées dans les chapitres précédents. Enfin, nous présentons nos démarches expérimentales puis exposons et discutons les résultats obtenus après l’utilisation du prototype sur la plateforme pour un scénario donné.
6.1
Plateforme de maquettage et d’expérimentation
Pour pouvoir tester expérimentalement et valider notre prototype, nous avons mis en place une plateforme de cloud privé IaaS reposant sur la solution VMware vCloud Suite [30]. Le choix s’est porté sur cette technologie car, bien que propriétaire et sou- mise à licences payantes, elle est une des plus complètes notamment en termes de fonctionnalités offertes pour le réseau et la sécurité. C’était particulièrement le cas au début de ces travaux de thèse, même si des solutions alternatives intéressantes ont émergé ces derniers mois. En outre, les spécifications techniques du projet1dans lequel ces travaux de thèse s’inscrivent requéraient l’utilisation de la technologie VMware.La plateforme est composée de quatre machines physiques :
– Un serveur Dell PowerEdge R320 muni d’un CPU Intel Xeon E5-2407, 8 Go de mémoire et deux disques durs de 2 To. Il est utilisé en tant que serveur NFS pour le stockage des disques durs virtuels des machines virtuelles du cloud.
– Deux serveurs Dell PowerEdge R620 munis chacun de deux CPUs Intel Xeon E5-2660, 64 Go de mémoire et deux disques durs de 146 Go. Ils exécutent l’hy- perviseur VMware ESXi et hébergent les composants de la solution VMware vCloud Suite sous forme de machines virtuelles.
– Un commutateur réseau HP 5120-24G EI. Il interconnecte les trois serveurs. La solution VMware vCloud Suite comprend VMware vCenter, vCloud Director et vShield Manager. vCenter permet de gérer l’infrastructure de virtualisation contenant les hyperviseurs, les commutateurs virtuels et les machines virtuelles. vCloud Director offre la possibilité de gérer des clients du cloud IaaS et leur donne accès à une interface Web pour paramétrer leur infrastructure virtuelle. Les informations d’administration des clients sont stockées dans un serveur de base de données Microsoft SQL Server 2008. Enfin, vShield Manager apporte des fonctionnalités de sécurité avec un pare-feu en mode hyperviseur (appelé vShield App par VMware), un antivirus (appelé End- point par VMware) et un antispoofing (appelé SpoofGuard par VMware).
Un commutateur virtuel distribué (c’est-à-dire réparti sur les deux hyperviseurs) connecte toutes les machines virtuelles de la plateforme. Il est indirectement connecté au commutateur physique par un lien trunk. Ce lien est composé d’un segment virtuel reliant le commutateur virtuel aux interfaces réseau des deux hyperviseurs, et d’un seg- ment physique entre ces interfaces et le commutateur physique. Les réseaux virtuels sont représentés sous forme de groupes de ports sur le commutateur virtuel distribué. Il y a donc un groupe de port par réseau virtuel de clients. Un réseau virtuel de gestion, associé à un VLAN spécifique, interconnecte toutes les machines virtuelles de gestion du cloud et tous les réseaux virtuels des clients. Il s’agit donc du réseau externe, dans lequel on retrouve également les passerelles éventuelles (pare-feu en mode pont, ap- pelés vShield Edge par VMware) des réseaux virtuels des clients ainsi que la machine virtuelle d’audit. De plus, deux solutions de NIDS sont déployées dans ce réseau : Suri- cata 2.0.5 et Snort 2.9.2.2. Chacun de ces NIDS est installé dans une machine virtuelle munie de 4 CPUs et 8 Go de mémoire. Nous avons conservé la configuration par défaut de ces NIDS, en leur fournissant le dernier jeu de signatures issu de [26]. Un mécanisme de mise en miroir des ports ou port mirroring est appliqué sur le commutateur virtuel distribué, de manière à envoyer une copie de tout le trafic des machines virtuelles du cloud vers les deux NIDS.
La Figure 6.1 illustre l’infrastructure physique et virtuelle de la plateforme d’expé- rimentation. Nous y avons représenté les quatre machines physiques (à savoir les trois serveurs et le commutateur), les solutions de gestion du cloud, ainsi que les liens phy- siques (reliant le commutateur physique aux serveurs physiques) et virtuels (reliant le commutateur vituel distribué aux machines virtuelles et aux serveurs physiques). Les liens physiques sont au nombre de deux pour chaque serveur physique hébergeant l’hyperviseur ESXi, où un des liens d’accès est utilisé pour administrer directement le serveur (qui est en fait également dans le réseau de gestion associé au VLAN dédié), et l’autre est le lien trunk reliant le commutateur physique au commutateur virtuel distribué (hébergé de manière identique sur l’hyperviseur de chaque serveur). Il est à noter que le lien série représenté sert à administrer le commutateur physique.