![](https://www.silicon.fr/wp-content/uploads/2018/02/shutterstock_131969567-1.jpg)
L’approche Software-Defined Network (SDN) représente un changement de paradigme en termes de sécurité de gestion d’infrastructure réseau. La courbe d’apprentissage se poursuit au regard des enjeux critiques.
Avec l’essor des déploiements du Software-Defined Network (SDN), la notion de sécurité associée à l’ossature même de ces réseaux virtualisés de nouvelle génération est chamboulée. L’enjeu est crucial au regard des maillons de data center qui s’imbriquent : infrastructures, applications et données.
Certes, en matière de SDN, il existe différents modèles de programmabilité selon un guide didactique de Cisco remontant à 2014 (1): à titre individuel par équipement, par un contrôleur, ou par la création d’un réseau virtuel au-dessus d’un réseau physique.
Globalement, le marché des réseaux télécoms d’entreprise tend vers une généralisation de la virtualisation des fonctions réseau (NFV pour Network Function Virtualization en anglais). Qu’importe le modèle retenu initialement, la sécurité SDN nécessite une véritable réflexion au moment même des choix d’architecture par abstraction du réseau.
Dans ce type de configuration, on ne peut pas se contenter d’un ensemble de pièces rapportées ou un patchwork d’éléments ayant vocation à colmater les brèches de sécurité IT de manière ponctuelle.
Une réflexion globale est nécessaire : le moindre maillon faible peut constituer une opportunité pour des cyber-assaillants de faire écrouler l’édifice. Il faut demeurer vigilant au regard de l’importante couche logicielle et des jonctions réalisées avec le monde du cloud et des vulnérabilités nouvelles susceptibles d’émerger.
Dès 2014, le cabinet d’études Gartner tirait déjà le signal d’alarme en évoquant les risques liés à l’implémentation de solutions SDN avec des notions balbutiantes de sécurité.
Stéphane Grosjean, Consultant datacenter de la zone Europe – Moyen Orient – Afrique (EMEA) pour Extreme Networks, évoque « l’aspect fondamental du SDN ».
Tout en tempérant aussitôt : « Je ne pense toutefois pas que ce soit la panacée. Néanmoins, cette approche permet d’apporter un niveau de sécurité supplémentaire. Et l’on peut ajouter une couche de chiffrement dans certains cas de figure. La sécurité va aussi dépendre des types d’applications mises en œuvre. »
Selon Scott Hogg (CTO de Global Technologies Ressources) dans un article didactique de Network World remontant à octobre 2014 (2), l’essor du SDN nécessite l’élaboration de nouvelles stratégies pour sécuriser le flux des informations autour de ce noyau du réseau en matière de « Control Plane » (désigne l’endroit où un routeur gère les protocoles de routage, les adjacences et construit ses tables), un élément à dissocier du « Data Plane » ().
La présence d’un contrôleur SDN – point central de commandement d’un réseau SDN pour la gestion des interactions entre les couches équipements réseaux (southbound) et applications business (northbound) – exige un haut niveau de protection des flux autour sous peine de voir un intrus prendre le contrôle de l’intégralité du réseau.
Autant tenter d’identifier les menaces de manière précoce et apprendre avec les usages qui se développent progressivement. Car, inévitablement, la vulgarisation du SDN va susciter la curiosité malsaine des pirates.
En matière de vulnérabilité SDN, nous assistons à une certaine courbe d’apprentissage dans la sphère de la sécurité IT.
La sécurité doit figurer dans l’ADN du SDN
C’est incontournable. La sécurité doit constituer la plus grande des priorités dans les déploiements SDN.
Intégrées dès la conception, ces fonctions s’activent dynamiquement en différents points sensibles, en particulier au niveau du contrôleur SDN.
Vision globale
On l’a déjà vu à travers ce hub Colt : la sécurité fait intrinsèquement partie du concept de SDN et des offres On Demand du fournisseur de services réseaux à destination des entreprises (1).
Intégrées dès la conception, les fonctions de sécurité s’activent dynamiquement en différents points sensibles, en particulier sur le contrôleur SDN.
« Elle est d’autant plus critique que l’on utilise le réseau Internet comme épine dorsale ». Les tunnels de chiffrement disponibles à travers le SD-WAN (Software Defined – Wide Area Network) apportent une partie de la solution. Mais une partie seulement.
Il convient de disposer d’une vision de l’ensemble de l’architecture et de la sécurité de bout en bout : pare-feu, passerelles d’accès Web, outils IPS (Intrusion Prevention System), filtre antimalware…Tout en prenant soin de ne pas affecter les performances du réseau global au nom de la productivité.
Un challenge délicat à soupeser en fonction des maillons sensibles ou non. Mais c’est aussi une opportunité d’apporter une réponse intelligente en filtrant le trafic d’origine obscure et potentiellement malveillante et en autorisant les flux légitimes.
Supervision et sécurité : gagner en visibilité
Comment gagner en visibilité dans la supervision de la gestion des SDN, gage d’une sécurité accrue du réseau ?
Sur le marché des offres technologiques, il existe des plateformes de sécurité transversale comme GigaSecure Delivery Platform (4) pour couvrir les besoins d’exploitation d’un Cloud privé ou d’un environnement SDN.
La strate intermédiaire baptisée Visibility Fabric se présente comme une couche pervasive qui donne une vision d’ensemble de l’état des flux de trafic et des paquets qui circulent sur les réseaux physiques et virtualisés.
Elle devient essentielle pour trois raisons : surveiller l’état du réseau SDN lui-même, contrôler l’exploitation des applications et garantir la sécurité sur toutes les strates d’interaction.
L’approche granulaire du monitoring est de nature à favoriser la détection précoce des signes de dysfonctionnements ou d’anomalies potentielles servant de vecteurs d’attaques.
Tous les moyens doivent être déployés pour éviter la propagation des risques. Il faut agir vite mais cela passe par l’identification le plus en amont possible des éléments troublants et aboutir à leur isolement.
La contribution du Service Chaining
L’approche de chaînage de service (Service Chaining) par le biais d’un réseau SDN a vocation à renforcer la sécurité globale. Ou comment créer des chaînes de services connectés (pare-feu d’application Web, IPS, sécurité des adresses mail et des postes clients…) et faire transiter divers services disposant de caractéristiques hétérogènes par une unique connexion réseau.
« Le Service Chaining permet d’automatiser la configuration des réseaux virtuels pour gérer les flux de trafic en fonction de la source, de la destination ou du type de trafic », rapporte un expert de F5 Networks (5). On peut ainsi router dynamiquement le trafic vers des appliance de sécurité qui prennent en charge des applications business comme la messagerie ou un ERP.
Gardez un œil sur l’environnement data center
Un des points-clés à prendre en considération dans le déploiement d’une infrastructure SDN est son environnement : le data center. Avec l’explosion des flux de données et de la profusion des services dans le cloud, l’interconnexion de data centers (DCI) avec les protocoles associés (EVPN, VXLAN, MPLS, GRE) joue un rôle essentiel.
Il faut donc s’assurer que les protocoles pour les DCI soient robustes et fiables en termes de sécurité, en recourant à des couches de chiffrement pour sécuriser les flux de données.
La tentation serait grande d’exploiter les vulnérabilités des protocoles pour créer du trafic usurpé à travers les liens DCI et fomenter une attaque par déni de service (Denial of Service ou DoS en anglais) qui affectera au final le SDN.
Contrôleur SDN : incontournable sécurité du cœur réseau
Où faut-il concentrer les lignes de défense avec une infrastructure SDN ? Ainsi, on peut parler de sécurité définie par logiciel (SDsec) dotée de ses propres ressources de machines virtuelles, voire de ses propres liens réseaux.
En cas d’exploitation d’un contrôleur SDN, il devient évident que cette pièce centrale doit bénéficier du plus haut degré de protection possible. Car il constitue le cerveau du réseau en centralisant les commandes.
La sécurité de cette partie névralgique est cruciale : le contrôleur SDN est susceptible d’être affaibli par des vulnérabilités affectant les couches software et les équipements ou composants hardware
Si ce composant névralgique subit une attaque par déni de service, c’est l’ensemble du réseau qui peut s’écrouler. Il faut donc scruter quelques points délicats.
A l’assaut du contrôleur SDN
Une attaque de la couche de contrôle du SDN peut servir à plusieurs desseins : déstabiliser l’infrastructure en vue de la mettre à terre, contourner les règles de sécurité établies pour prendre le contrôle d’une partie des flux ou carrément insérer un faux contrôleur SDN et capter la totalité des flux en vue d’une exploitation détournée.
En guise de vecteur d’attaque, un pirate peut procéder à l’exécution d’un assaut par déni de service (DoS) au niveau du contrôleur SDN susceptible de déstabiliser l’infrastructure télécoms.
Comment ? En saturant le réseau virtualisé d’envois massifs de requêtes pour mettre le système à plat ou du moins ralentir considérablement le traitement des flux entrants et sortants.
Interfaces Northbound et Southbound : deux versants à surveiller
Contrôleur SDN
Si l’on zoome davantage sur les caractéristiques du contrôleur SDN, l’interface Northbound (protocole ascendant) permet d’assurer les connexions avec les applications business virtualisées.
Les éditeurs de contrôleurs SDN se chargent de publier les documentations API (interfaces de programmations, connecteurs logiciels) qui établissent la jonction avec cette couche applications.
L’approche, souvent propriétaire dans ce cas, offre d’énormes possibilités de développement logiciel, comme la création d’applications visant à automatiser les tâches réseau. Les administrateurs réseaux peuvent alors modifier et personnaliser le contrôle SDN à travers les API Northbound, qui s’appuient sur les langages de programmation Java, Python, REST. La qualité de développement du code prime pour éviter les mauvaises surprises comme des portes dérobées.
Le recours à des algorithmes éprouvés de chiffrement (TLS, SSH…) permet de sécuriser les flux circulant sur le flanc Northbound avec les applications. A considérer comme une pratique exemplaire à suivre.
Sur l’autre versant Southbound (protocole descendant), le contrôleur SDN communique avec la couche des équipements réseau (comme des routeurs) par des jeux d’API et de protocoles (parfois propriétaires mais normalisés comme BGP ou SNMP ou open source comme Open Flow…).
Là aussi, il est nécessaire de sécuriser les communications par le biais de techniques de chiffrement. Par exemple, des sessions TLS (ex-SSL) permettent d’authentifier les flux entre le contrôleur SDN et les équipements réseaux adéquats pour éviter les écoutes électroniques et les canaux usurpés.
Selon le protocole Southbound utilisé (BGP, SNMP…), il existe diverses options pour sécuriser les flux d’information transmis. La qualité de certains protocoles tend à s’améliorer. Ainsi, SNMPv3 se montre plus robuste que les versions précédentes (SNMPv2c et SNMPv1).
Généralement, l’exploitation de protocoles propriétaires au niveau Southbound API est associée à des méthodes d’authentification des agents de terminaux d’équipement et des contrôleurs. Tout en proposant le chiffrement des données pour éviter l’entremise de pirates.
Quelles mesures de sécurité à prendre autour du contrôleur SDN (et au-delà)
Choix du contrôleur : décision stratégique
Le choix du contrôleur SDN est donc déterminant. Entre approches ouvertes et propriétaires, nous avions commencé à les recenser sur ce hub (6) : on pense à OpenDaylight (contrôleur SDN Open Source), Cisco APIC (Cisco Application Policy Infrastructure Controller), OSC (Cisco Open SDN Controller, distribution commerciale d’OpenDaylight), Trema, POX, Beacon ou Floodlight (fork de Beacon)… Il en existe des dizaines sur le marché.
Prenons le cas OpenDaylight, un framework SDN open source poussé par la Fondation Linux. Il permet de souligner un point intéressant : les administrateurs de réseaux SDN ont intérêt à se montrer vigilant sur les vulnérabilités globales susceptibles d’émerger dans les environnements open source. Car les faiblesses sur un système d’exploitation général comme Linux seraient susceptibles d’avoir des répercussions sur le contrôleur SDN lui-même.
Autre précaution : ne pas tomber dans le piège des déploiements SDN et des contrôleurs en se contentant des mots de passe par défaut fournis par les éditeurs. La configuration personnalisée des paramètres de sécurité est importante pour éloigner les tentatives d’intrusion.
Renforcer les droits d’accès administrateur
Le renforcement de la sécurité au niveau du contrôleur SDN est primordial. Par voie de conséquence, les systèmes SDN doivent impérativement permettre la configuration d’un accès administrateur sécurisé et authentifié au contrôleur.
Des règles de contrôle d’accès basés sur rôle (RBAC ou Role-Based Access Control en anglais) sont ainsi cruciales pour les administrateurs réseaux en charge de la supervision des contrôleurs SDN.
Les chemins d’enregistrement (logs) peuvent s’avérer essentiels pour vérifier tout changement non autorisé.
Des experts en SDN recommandent aussi des contrôleurs ayant recours à des techniques dites à haute disponibilité (HA pour High Availability en anglais) et/ou avec des canaux de redondance des éléments les plus critiques et éviter ainsi les interruptions de service liées à un éventuel assaut.
Privilégier les configurations multi-contrôleurs
Le recours à redondance au niveau du contrôleur SDN compliquerait la tâche d’un pirate cherchant à faire tomber un système. Si un pirate peut accéder au contrôleur SDN qui joue le rôle de superviseur global, les risques de déstabilisation complet du réseau augmentent.
Au nom d’une résilience accrue, une configuration multi-contrôleurs SDN permet de limiter l’impact d’un assaut et d’isoler l’anomalie.
Si un contrôleur SDN se trouve affecté, un autre contrôleur SDN non compromis pourrait prendre la relève. Laissant un répit pour identifier l’anomalie et colmater la brèche en vue d’un retour à la normale.
La formation réseau
Afin de sécuriser un SDN, il convient avant tout de bien appréhender la technologie. En définir les pourtours et acquérir les compétences requises sont donc au cœur des enjeux. Des formations s’avèrent de ce fait névralgiques et incontournables.
En effet, dans les nouveaux métiers qui émergent avec l’essor du SDN, le programmeur réseau doit d’emblée être en mesure d’intégrer dans l’architecture SDN et dans le code qui la régit des politiques de sécurité.
Dans les opportunités de carrière qui vont se multiplier, ce sont les profils capables d’appréhender le SDN dans son intégralité qui primeront (7). Les compétences informatiques, la connaissance des API et des contrôleurs réseaux vont être névralgiques en suivant cette logique.
SDN : la courbe progressive d’apprentissage de la sécurité IT
Les experts en sécurité IT apprennent progressivement en fonction des usages SDN observés, des POC (proof of concept) dans les labos et des anomalies recensées (vulnérabilités ou attaques).
Par exemple, en juin 2015, le Laboratoire de la sécurité des réseaux et des protocoles de l’ANSSI (agence nationale en charge de la sécurité informatique) avait étudié ce paradigme qui prône, par opposition aux réseaux traditionnels, une séparation des fonctions de routage et de celles de transfert de paquets.
L’expertise technique (8), relayée dans la foulée lors de la session SSTIC 2015, détaillait les spécificités du standard ouvert OpenFlow, une des implémentations du SDN pour permettre la communication entre contrôleur et switches, en mettant l’accent sur certaines de ses faiblesses.
L’ANSSI pointait du doigt à l’époque l’absence de TLS (couche de chiffrement) pour les communications et une certaine « perméabilité » de la liaison au risque de provoquer une attaque DoS sur un switch OpenFlow en le soumettant à un trafic soutenu.
Plus récemment (et donc plus frais), lors de la session Black Hat 2016 aux USA [note 9, voir vidéo disponible sur YouTube], Changhoon Yoon & Seungsoo Lee, deux chercheurs étudiants de l’Institut supérieur coréen des sciences et technologies (KAIST), ont effectué une présentation sur les différents types d’assaut sur une architecture SDN en data center.
En soulignant les risques d’exposition d’attaques en cas de mauvaise configuration du réseau, les possibilités d’attaques par DoS mais aussi les possibilités de chambouler les nœuds d’un réseau en exploitant des nodes ONOS (Open Network Operating System, OS open source pour SDN) non autorisés.
Conclusion :
La sécurité SDN est un sujet incontournable à prendre avec la plus grande rigueur. Elle nécessite des combinaisons de compétences avec des experts en protection des réseaux mais aussi des services Cloud au regard des passerelles entre les deux mondes. Une parfaite compréhension des topologies de réseaux SDN s’avère cruciale pour façonner une approche de sécurité globale.
Si le SDN constitue une formidable opportunité pour dynamiser l’administration réseau en la rendant plus flexible, son épanouissement est lié à la protection globale de l’infrastructure. A commencer par le cœur du réseau : le contrôleur SDN.
Dans l’idéal, il faudrait intégrer la sécurité dès le stade de conception du projet SDN pour optimiser son déploiement ultérieur sous un angle « security by design ».
- Le SDN pour les nuls – Jérôme Durand – Cisco Systems – JRES 2015 – Montpellier
- https://www.networkworld.com/article/2840273/sdn/sdn-security-attack-vectors-and-sdn-hardening.html
- https://www.silicon.fr/hub/colt-hub/sdn-vers-un-environnement-de-securite-dynamique?inf_by=59cadff3671db837728b4636
- https://www.gigamon.com/products/core-offerings/visibility-platform/gigasecure-security-delivery-platform.html
- https://www.lemondeinformatique.fr/actualites/lire-f5-networks-etoffe-ses-services-de-securite-applicative-67235.html
- https://www.silicon.fr/hub/colt-hub/sdn-quelles-competences-pour-sa-mise-en-oeuvre?inf_by=59cadff3671db837728b4636
- https://www.silicon.fr/hub/colt-hub/sdn-quelles-competences-pour-sa-mise-en-oeuvre?inf_by=59cadff3671db837728b4636
- https://www.ssi.gouv.fr/publication/les-risques-dopenflow-et-du-sdn/
- https://www.youtube.com/watch?v=_9wzGFtjQc0