L'Internet s'est considérablement étendu au cours des dernières décennies et continue d'être développé en termes de dimension et de complexité. De nombreux problèmes de sécurité ont été soulevés tels que l'authentication et la traçabilité des utilisateurs. Au cours du temps, la sécurité est une des fonctions de réseau les plus importantes destinée à protéger le réseau et à prévenir les attaques telles que l'attaque de l'homme du milieu , l'accès non autorisé, l'usurpation et le déni de service entre autres. La sécurité du réseau peut être améliorée à l'aide des fonctionnalités du type SDN. Par exemple, la programmation qui contient la connaissance et les informations globales sur l'état du réseau. L'architecture SDN ore de nombreuses opportunités pour suivre la croissance exponentielle d'Internet. Cependant, la plupart des technologies SDN sont tout à fait nouvelles et présentent de nombreux problèmes de sécurité pour optimiser le déploiement de SDN. Ce chapitre fourni un aperçu de certains problèmes de sécurité sur le SDN et présente notre approche pour la distribution des applications SDN.
Le protocole OpenFlow est le plus utilisé et largement déployé sur l'interface sud du SDN. Il permet la communication entre les périphériques réseau et les contrôleurs SDN via un canal de communication. Néanmoins, OF n'applique pas de mesure de sécurité dans ce canal de communication par lui-même lors du démarrage. Les techniques de cryptage avec TLS sont possibles mais non obligatoire, car il s'exécute directement sur des connexions TCP en clair. En outre, certains fournisseurs n'ont pas encore mis en place de solution pour sécuriser le canal de communication des échanges de messages entre un contrôleur OF et un commutateur OF. Un pirate peut exploiter ce manque d'authentication sur un canal OF non sécurisé pour inltrer le réseau et écouter ou falsier le trac réseau sur l'interface sud du SDN. Ce manque de sécurisation est particulièrement dangereux si l'attaquant obtient un accès de contrôle complet. Il peut alors arrêter les commutateurs OF, modier les règles dans le commutateur, capturer de trac sensible et surveiller comment le contrôleur gère les paquets OF. Dans le cadre de notre prototype, le canal de communication OpenFlow de l'OVS et du contrôleur ODL est crypté en utilisant la connexion SSL/TLS en fonction du modèle PKI (Public Key Infrastructure).
Avec le protocole OpenFlow 6.5), chaque entrée de ux a une correspondance/action qui peut être congurée contre quatorze champs d'en-tête de correspondance qui fournissent un niveau de granularité plus élevé que celles des techniques d'acheminement traditionnelles. Cependant,
le protocole Openow envoie uniquement les informations (ux) qu'il contient au contrôleur. Dans le cas de la surveillance des périphériques réseau et des informations échangées, nous voudrions également contrôler non seulement les paquets IP, TCP ou UDP mais aussi les paquets au niveau des applications comme HTTP ou FTP par exemple. Openow ne fournit pas le mécanisme approprié pour gérer la sécurité d'un réseau au niveau de l'application. En outre, une fois qu'une entrée de ux est installée sur le OVS, les requêtes OF n'atteignent pas le contrôleur. Tous les paquets seront traités uniquement au niveau de l'équipement de
réseau, couche 2-3. Dans un récent travail un protocole alternatif à OpenFlow, OpFlex [33]
a été proposé par Cisco. Ce paradigme SDN ore de nouvelles perspectives pour surmonter le dé de la gestion des paquets au niveau de l'application. Une autre approche pour gérer le réseau au niveau d'application est d'utiliser l'API Group Based Policy (GBP) RESTCONF Northbound fournie par ODL. Ces techniques seront incluses dans les travaux futurs.
L'architecture centralisée de SDN implique une dépendance sur le plan de contrôle. Cette centralisation expose le contrôleur à des attaques potentielles comme le déni de service (DoS). Cela peut être atténué en utilisant une architecture de haute disponibilité High Availability (HA) avec plusieurs contrôleurs. Les contrôleurs SDN redondants garantissent la disponibilité du réseau, évitant le basculement du réseau comme ce serait le cas avec un seul contrôleur qui deviendrait indisponible. Cependant, sans une conception prudente de la politique de sécurité, tous les membres du cluster peuvent être exposés aux attaques DoS. Il existe une autre faiblesse sur de nombreux contrôleurs SDN qui se trouve sur l'API HTTP à l'interface nord, ces derniers n'ayant aucune méthode de cryptage sur les communications et l'authentication. Nous avons expérimenté un cluster de haute disponibilité pour éviter la présence d'un noeud critique et une défaillance du système. Pour sécuriser les API dans l'interface nord il est nécessaire d'installer et congurer la fonctionnalité Authentication, Authorization and Accounting (AAA) fourni par ODL.
Dans le cas de notre prototype, nous nous sommes inspiré du concept de Contrôleur d'accès
au réseau et des techniques de sécurité existante [22], pour concevoir une architecture sécurisée
exploitant le SDN et étendue à l'IoT. Pour expliquer notre architecture, nous présentons d'abord une solution simple dans laquelle un contrôleur gère la sécurité d'un domaine du SDN. Deux-ièmement, nous appliquons cette solution en incluant plusieurs contrôleurs liés aux ressources disponibles sur chaque plate-forme de contrôle. Ainsi, nous élargissons l'architecture de contrôle distribuée par l'interconnexion à tous les domaines du SDN par les contrôleurs de périphérie, ce qui nous rapproche d'un modèle sécurisé pour l'IoT.
En raison de l'absence d'infrastructure du réseau, l'architecture traditionnelle ad-hoc ne prévoit pas de contrôle d'accès au réseau ou à la surveillance du trac global. L'architecture proposée dans cet dissertation surmonte ces limites de sécurité et permet la conguration du réseau et le déploiement de politiques de sécurité.
Notre but est de réaliser la synchronisation maximum de contrôleurs du SDN dans un périmètre de sécurité permettant un contrôle à grain n sur l'accès au réseau et la surveillance continue des points naux.
An de garantir l'accès au réseau et aux ressources de réseau, les contrôleurs du SDN: 1. Commencent par authentier les périphériques réseau;
2. Une fois la connexion sécurisée par OpenFlow, la communication entre le commutateur et le contrôleur sera établie;
URCA
3. Le contrôleur bloque les ports de commutation connectés directement aux utilisateurs; 4. Le contrôleur autorise seulement la circulation d'utilisateurs authentiés;
5. Suivant le niveau d'autorisation de l'utilisateur;
(a) Le contrôleur va transmettre les entrées appropriées de ux d'accès au commutateur pour le logiciel ou le matériel informatique;
(b) Dans IoT, nous étendons ce processus d'authentication aux périphériques;
(c) Chaque dispositif doit s'associer à un noeud OpenFlow actif, lui-même relié à un contrôleur dans son domaine.
Internet
Contrôleur de
Périphérie Contrôleur dePériphérie Contrôleur de Périphérie Cluster Réseau 1 Cluster Réseau 2 Cluster Réseau 3 Virus 2. connais-tu B? 1. A vers B 2. connais-tu B? 3. Je connais B 4. A vers B 5. B A B
Figure 6.21: Grille de Sécurité SDN Domaine.
Le concept de grille de sécurité du réseau [126] est d'étendre la notion de domaine du SDN
à plusieurs domaines, et que les contrôleurs de diérents domaine échangent leurs règles de sécurité. Certains contrôleurs du SDN se comportent comme des agents de sécurité au bord du domaine du SDN étendu pour assurer la sécurité du réseau. Les connexions entre les domaines de sécurité seront gérées uniquement par les contrôleurs du SDN. Seul le trac certié sera accepté. Chaque contrôleur ne connait que les politiques de son propre domaine. Donc, quand un noeud veut communiquer avec un noeud d'un autre domaine, le ux doit être transmit vers le contrôleur de sécurité, également appelé contrôleur de périphérie. Le contrôleur de sécurité demande à chaque contrôleur voisin s'il connaît la destination de l'information et le ux n'est transmis que si la destination est connue (Fig. 6.21).