La réseautique définie par logiciel – SDN
L’Open Network Foundation (ONF) définit le réseau SDN comme suit : «Software-Defined Networking (SDN) is an emerging architecture that is dynamic, manageable, cost-effective, and adaptable, making it ideal for the high-bandwidth, dynamic nature of today’s applications. This architecture decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services» (Open Networking Foundation, 2017a). La réseautique définie par logiciel (SDN) est un nouveau paradigme qui transforme la façon dont les infrastructures des réseaux informatiques sont gérées, contrôlées et configurées. Le concept du SDN repose sur la séparation du plan de contrôle, qui représente l’intelligence du réseau, et du plan de données qui est en charge du transfert des paquets. Le plan de contrôle est sous la responsabilité d’un contrôleur centralisé qui possède une vue globale sur l’ensemble du réseau et qui prend en charge toutes les décisions de routage des flux ainsi que toutes les fonctions de gestion et de contrôle au sein du réseau.
Cette vue globale du réseau, offerte par SDN, permet de simplifier la gestion pour ses administrateurs (par exemple, le changement de la topologie, le choix des routes pour les flux, la surveillance, la sécurité). Le plan de données est constitué de commutateurs qui sont responsables de transmettre le trafic dans le réseau SDN, de la source vers la destination, en se basant sur les règles des flux attribuées par le contrôleur. La communication entre ces commutateurs et le contrôleur se fait par un protocole de communication standard comme OpenFlow (OF) (Open Networking Foundation, 2017b), ForCES (Halpern et Hadi, Salim, 2010), NetConf (Enns, Bjorklund, Schoenwaelder et Bierman, 2011), IRS (Clarke, Salgueiro et Pignataro, 2016). Ces protocoles permettent au contrôleur SDN de modifier les tables de commutation des commutateurs avec les règles de commutation nécessaires pour assurer la transmission des flux dans le réseau. En outre, la technologie SDN offre une programmabilité permettant aux administrateurs de configurer, de gérer et de contrôler automatiquement l’ensemble du réseau par des interfaces de programmation applicatives (Application Programming Interface – API) (TechTerms, 2017).
Protocole de communication OpenFlow
Il existe plusieurs protocoles de communication entre le plan de contrôle et le plan de données tels que ForCES (Halpern et Hadi, Salim, 2010), IRS (Clarke, Salgueiro et Pignataro, 2016) et NetConf (Enns, Bjorklund, Schoenwaelder et Bierman, 2011). Cependant, le protocole de communication OpenFlow reste le plus utilisé sur les équipements du réseau SDN. OpenFlow est une norme multifournisseur définie par l’ONF qui agit comme un relais entre le contrôleur et les équipements réseau du plan de transmission. Il fournit un protocole ouvert pour programmer les tables de flux sur différents commutateurs et routeurs. C’est un protocole standard utilisé par le contrôleur SDN pour transmettre aux commutateurs des instructions qui permettent de programmer leur plan de données et d’obtenir des informations de ces commutateurs afin que le contrôleur puisse disposer d’une vue globale logique du réseau physique. Cette vue est utilisée pour toutes les décisions que doit prendre le plan de contrôle (par exemple, routage, filtrage de trafic, partage de la charge, traduction d’adresse) (EFORT, 2016). En effet, le contrôleur peut ajouter, supprimer ou modifier les flux en obtenant des statistiques sur les ports et les flux et d’autres informations à l’aide du protocole OpenFlow.
Techniques de mitigation sans l’utilisation de l’IDS
• FlowRanger : Lei Wei et Carol Fung (Wei, Lei et Fung, Carol, 2015) proposent FlowRanger, un système de rangement de flux qui permet de détecter et d’atténuer l’impact des attaques de DdS. FlowRanger est implémenté dans le contrôleur SDN. Ce système est constitué de trois composants principaux. Le premier est un composant de gestion de la valeur de confiance qui calcule la valeur de confiance pour chaque message «packet-in» en vérifiant sa source. Le deuxième est responsable à la gestion de la file d’attente du contrôleur, qui va attribuer des règles de commutation à chaque paquet entrant. Ce composant est en charge de mettre les messages «packet-in» dans file d’attente en priorité selon sa valeur de confiance déjà calculée par le premier composant. Et le troisième représente le composant d’ordonnancement de message qui traite les messages selon la stratégie «Weighted Round Robin» (WRR) (Brocade Communications Systems, 2016). La technique FlowRanger peut réduire l’impact des attaques DdS sur les performances du réseau en garantissant que les flux légitimes sont servis en premier dans le contrôleur. Cependant, cette solution n’empêche pas la surcharge du contrôleur et la surcharge des tables de commutation des commutateurs.
• Technique de filtrage des adresses IP : Une autre solution a été proposée dans (Dao, Nhu-Ngoc, Park, Junho, Park, Minho et Cho, Sungrae, 2015) pour protéger les réseaux SDN contre les attaques DDdS et qui est basée sur la technique de filtrage IP. Le mécanisme consiste à analyser le comportement et les activités de l’utilisateur dans le réseau afin de calculer le nombre des tentatives de connexion du son adresse IP. Les auteurs définissent une table de stockage dans le contrôleur pour stocker les adresses IP source du chaque paquet transmis par les commutateurs demandant une règle de commutation. Ensuite, le contrôleur incrémente un compteur qui calcule le nombre des paquets arrivés au contrôleur de la même adresse IP. Enfin, le contrôleur va générer l’expiration de la règle de commutation dans le commutateur en se basant sur le nombre de connexions de l’adresse IP. Si le nombre des tentatives de la connexion dépasse le seuil d’une utilisation normale, les paquets provenant de cette adresse IP sont considérés comme malicieux et le contrôleur va attribuer un court timeout aux flux des utilisateurs malveillants. Par contre, si le nombre de connexions ne dépasse pas le seuil défini, l’utilisateur de l’adresse IP est considéré comme légitime et un long timeout est assigné à sa règle de commutation. Cette solution force les règles de commutation du trafic malveillant à être rapidement supprimées des tables des flux des commutateurs.
Cependant, cela peut conduire à l’envoi de nouveaux messages «packetin » au contrôleur, demandant des nouvelles règles de commutations pour le même flux, si la durée d’utilisation de flux est supérieure au timeout défini dans la règle de commutation. Par conséquent, ceci engendre la surcharge du contrôleur. En outre, cette solution bloque tout le trafic malveillant, ce qui peut être critique pour les flux faux positifs.
• Technique de gestion autonome : Dans cette solution (Sahay, Rishikesh, Blanc, Gregory, Zhang, Zonghua et Debar, Hervé, 2015), les auteurs exploitent la centralisation et la programmabilité offertes par la technologie SDN et proposent un système de gestion autonome dans lequel le fournisseur d’accès internet (FAI) et ses clients collaborent pour atténuer l’impact des attaques DdS. Dans cette solution, le FAI collecte des informations sur les menaces déclarées par les clients afin de les utiliser pour appliquer les politiques de sécurité et mettre à jour les tables de flux des commutateurs dans le réseau. Si un flux est considéré comme légitime par les clients, le contrôleur du FAI le marque avec une priorité élevée de sorte qu’il prend un chemin de haute qualité qui assure la rapidité du l’envoi et garantit sa réception. Cependant, en cas de doute sur la légitimité du flux, le contrôleur du FAI lui affectera une faible priorité et le dirigera vers le chemin désigné pour les flux malveillants. Cette proposition réduit l’impact de l’attaque DdS sur la performance du réseau au niveau de plan de transmission en équilibrant la charge sur différents chemins. Cependant, elle n’atténue pas les risques de surcharge du contrôleur et la saturation des tables de commutation des commutateurs à cause du grand nombre de flux reçus par les commutateurs et qui génèrent, à la suite, un nombre élevé des règles de commutation dans leurs tables TCAM ainsi qu’une communication agressive entre ces commutateurs et le contrôleur pour attribuer les règles des commutations nécessaires.
|
Table des matières
INTRODUCTION
CHAPITRE 1 ÉTAT DE L’ART
1.1 Introduction
1.2 La réseautique définie par logiciel – SDN
1.2.1 Définition
1.2.2 Architecture et caractéristiques de la technologie SDN
1.2.2.1 Architecture
1.2.2.2 Caractéristiques
1.2.3 Protocole de communication OpenFlow
1.3 Les attaques par déni de service – DdS
1.3.1 Définition
1.3.2 Impacts des attaques de DdS sur le réseau SDN
1.4 Les systèmes de détection d’intrusions – IDS
1.4.1 Types des systèmes de détection d’intrusions
1.4.2 Approches de détection des intrusions
1.4.3 Exemples des systèmes de détection d’intrusion
1.5 Revue de littérature
1.5.1 Techniques de mitigation sans l’utilisation de l’IDS
1.5.2 Techniques de mitigation avec l’utilisation de l’IDS
1.5.3 Techniques d’échantillonnage de trafic
1.5.4 Discussion
1.6 Conclusion
CHAPITRE 2 SOLUTION PROPOSEÉ : SDN-GUARD
2.1 Introduction
2.2 Architecture du SDN-Guard
2.2.1 Module de gestion des flux
2.2.2 Module d’agrégation des règles de commutation
2.2.3 Module de surveillance
2.3 Mitigation des attaques de déni de service
2.3.1 Routage selon le type du flux
2.3.2 Gestion du timeout
2.3.3 Agrégation des règles de commutation
2.3.4 Résumé des décisions du SDN-Guard
2.4 Emplacement de l’IDS et la gestion du trafic
2.4.1 Emplacement optimal de l’IDS et duplication du trafic
2.4.2 Échantillonnage de trafic dupliqué
2.5 Conclusion
CHAPITRE 3 EXPÉRIMENTATIONS ET RÉSULTATS
3.1 Introduction
3.2 Environnement expérimental
3.2.1 Topologie émulée
3.2.2 Description des expériences effectuées
3.3 Évaluation de la performance et de la précision d’IDS
3.3.1 Précision de l’IDS versus le taux d’échantillonnage
3.3.2 Temps du traitement des paquets par IDS
3.4 Emplacement optimal de l’IDS
3.5 Évaluation de l’efficacité du SDN-Guard
3.5.1 Taux de traitement du contrôleur
3.5.2 Taille des tables TCAM des commutateurs
3.5.3 Taux de perte des paquets
3.5.4 Temps moyen de réponse
3.5.5 Discussion
3.6 Conclusion
CONCLUSION ET PERSPECTIVES
BIBLIOGRAPHIE
Télécharger le rapport complet
