Nous présentons dans cet article une évolution majeure dans les réseaux consistant à automatiser ou rendre programmable le réseau grâce au concept SDN. L’objectif est de rendre le réseau plus agile, mais aussi de faciliter le déploiement des services activés par les clients eux-mêmes.
1. Introduction
Le SDN (Software-Defined Networking) trouve beaucoup de définitions différentes. L’idée fondamentale derrière le SDN est de rendre le réseau programmable, c’est-à-dire plus apte à subir des modifications liées à des demandes de services de plus en plus dynamiques. La RFC7149 [RFC7149]tente de définir le SDN de la manière suivante :
Le SDN (Software-Defined Networking) est un ensemble de techniques visant à faciliter l’architecture, la livraison et l’opération de services réseaux de manière déterministe, dynamique et pouvant être déployés à grande échelle.
La technique principale utilisée est la mise à disposition d’interfaces de programmation (API) afin que des applications externes puissent directement interagir avec le réseau.
Une autre technique souvent utilisée et bien connue est la centralisation partielle ou totale du plan de contrôle d’un équipement réseau (son intelligence) laissant sur l’équipement le plan de transfert (contenant les tables de commutation) alimenté par ce plan de contrôle centralisé.
2. Les notions d’interfaces
Les outils et composants intervenant dans un processus donné (production par exemple) peuvent être hiérarchisés de la manière suivante :
- les outils/composants se rapprochant du service client seront vers les couches « hautes » ;
- les outils/composants se rapprochant du réseau physique seront vers les couches « basses ».
Cette approche de hiérarchisation reste très similaire à une vision telle que le modèle OSI (couches hautes applicatives, couches basses physiques). Le principe est que chaque couche de niveau N offre un niveau d’abstraction plus important à la couche N+1. Le nombre de couches dépend de l’architecture retenue par l’opérateur et du nombre d’outils/composants mis en jeu. Cependant, on peut définir de manière simple un modèle à quatre couches comme l’illustre la figure 1.
Fig. 1 : Architecture SDN en couches.
La couche de ressource représente le matériel physique des équipements réseaux (routeurs, pare-feux, etc.) et représente ainsi la couche la plus basse, donc la moins abstraite. Ces équipements réseaux représentent des ressources que le service pourra utiliser à la demande. Dans le cas de fonctions réseaux qui seraient virtualisées, la ressource serait la machine virtuelle ou le conteneur assurant la fonction réseau.
Il est possible d’accéder à la couche ressource par le biais d’une couche de contrôle (plan de contrôle) ou de gestion (plan de gestion). Ceci est très similaire au modèle en couches des équipements existant à la différence près que dans l’architecture SDN, un plan de contrôle et/ou gestion centralisé pourra être créé afin d’offrir une interface simplifiée à la couche de service (en gommant par exemple les disparités des équipements) et/ou d’amener plus de fonctionnalités. Le plan de contrôle ou de gestion aura alors la maîtrise de plusieurs ressources.
La couche service réseau s’assure du cycle de vie du service réseau. Elle va s’appuyer sur les couches de contrôle, de gestion (centralisée ou des ressources directement) afin de rendre le service demandé. La couche service réseau va exposer à la couche application un certain nombre de services pouvant être activés, ainsi que les paramètres associés à ces services. La couche application représente la couche la plus haute. Il peut également s’agir d’une application cliente qui interagit directement avec le fournisseur de service.
Les flèches entre les couches représentent des interfaces. Une couche peut disposer de flèches allant vers une couche plus basse, on parlera alors d’interface de service Sud. Elle peut disposer de flèches entrantes venant d’une couche supérieure, on parlera alors d’interface de service Nord.
Il existe des cas où des couches de même niveau discutent entre elles, c’est le cas notamment des plans de contrôle totalement ou partiellement distribués. On parlera alors d’interface de service Est/Ouest.
La figure 2 présente un exemple où un réseau est géré par deux plans de contrôle. Chaque plan de contrôle gère une partie des ressources réseaux. Une interface peut être nécessaire entre les deux plans de contrôle (besoin d’échange d’informations). C’est une interface de service Est/Ouest.
Fig. 2 : Interfaces SDN pour le plan de contrôle.
La notion de direction de l’interface est toujours pour une couche donnée. Ainsi du point de vue de la couche service réseau, celle-ci dispose également d’une interface de service Nord (venant de la couche application), cette interface expose les paramètres de service à l’application. Elle dispose également d’interfaces de service vers les couches de contrôle et de gestion.
Une interface représente un moyen pour une couche d’exposer des capacités de manière abstraite à une autre couche. Une couche peut donc utiliser plusieurs interfaces différentes pour une même direction. Ces différentes interfaces pouvant fournir des services différents ou le même service par une méthode différente. Les interfaces se basent sur des protocoles afin de permettre un dialogue.
La figure 3 illustre un exemple de couche de contrôle ayant trois interfaces de service Nord et trois interfaces de service Sud possibles. Elle propose l’utilisation d’une interface de type REST, l’utilisation du protocole NETCONF ou de la commande en ligne pour l’interface de service Nord. Concernant l’interface de service Sud, elle permet l’utilisation des protocoles PCEP, BGP-LS ou XMPP. En terme d’usage, PCEP serait par exemple utilisé pour la création de tunnels d’ingénierie de trafic, BGP-LS pour l’acquisition de la topologie du réseau en temps réel, et XMPP pour la mise en place de paramètres plus spécifiques.
Fig. 3 : De multiples interfaces pour une couche donnée.
3. La programmation du réseau par flux
Un constat de l’état des réseaux actuels est qu’il est complexe d’y ajouter de nouvelles fonctionnalités de manière simple (à des fins d’expérimentation par exemple) comme on pourrait le faire pour programmer un ordinateur.
Partant de ce constat, un étudiant de l’université de Stanford a réfléchi à la résolution de ce problème : comment programmer de manière simple, la sécurité, le routage (incluant l’ingénierie de trafic), les classes de service…, et en déduisit un besoin de séparation des différents composants des équipements réseaux (plan de gestion, plan de contrôle, plan de transfert).
L’idée est donc d’avoir des équipements matériels effectuant des fonctions de plan de transfert programmables via un protocole standard depuis un contrôleur centralisé. Ainsi sont nés le protocole Openflow et le concept de SDN. Le travail de spécification et d’évolution d’Openflow a depuis été repris par l’ONF (Open Networking Foundation).
Le principe d’Openflow est que le contrôleur au travers d’une interface de programmation peut programmer le plan de transfert des équipements du réseau de manière standard. Ainsi les industriels peuvent développer des équipements réseaux « simples » compatibles Openflow (incluant uniquement le plan de transfert), l’intelligence étant laissée au contrôleur Openflow. Le protocole Openflow représente donc une interface sud pour le contrôleur comme l’illustre la figure 4.
Figure 4 : Pipeline de traitement Openflow.
L’architecture d’un switch Openflow est structurée principalement autour des composants suivants :
- un canal de communication Openflow avec le contrôleur ;
- des tables de flux qui contiennent les informations de traitement sur les flux ;
- des ports : il peut s’agir de ports physiques ou logiques (interface de Loopback, tunnels, agrégation de liens …).
Un switch Openflow peut être Openflow-only (c’est-à-dire qu’il ne supporte que les opérations de commutation issues d’Openflow) ou Openflow-hybrid (il peut alors se comporter également comme un switch de niveau 2).
Un switch Openflow utilise une ou plusieurs tables de flux qui contiennent donc des entrées. Chaque entrée est composée :
- de critères permettant d’identifier le flux ;
- de compteurs permettant d’avoir des statistiques sur le nombre de paquets pour un flux donné ;
- d’instructions (d’actions) de traitement sur le paquet ;
- une temporisation: au-delà d’un certain temps, si aucun paquet pour le flux n’a été vu, l’entrée de flux est supprimée.
Les entrées de flux sont créées par le contrôleur Openflow.
Il est possible qu’un paquet arrive sur un switch Openflow et n’ait pas d’entrée de flux correspondante. Le protocole laisse la possibilité alors, d’envoyer le paquet au contrôleur pour analyse. De cette manière, le contrôleur pourrait décider de programmer une entrée de flux correspondante. Ce comportement est optionnel, le switch Openflow pourrait jeter le paquet pour lequel il n’a pas d’entrée de flux.
Openflow utilise la notion de pipeline pour le traitement des flux. Le pipeline définit comment les paquets vont interagir avec les tables de flux. À chaque entrée dans une table de flux, un paquet est inspecté pour déterminer si une entrée correspondante existe, si elle existe, les actions associées sont appliquées. Une action possible est de pouvoir envoyer le paquet vers une autre table de flux comme l’illustre la figure 5.
Fig. 5 : Pipeline de traitement Openflow.
Openflow décrit simplement une façon de programmer le plan de transfert (plan de commutation), ainsi toute l’intelligence du plan de contrôle, par exemple, la détermination d’un plus court chemin, doit être réalisée par le contrôleur Openflow et ne fait en aucun cas partie de la spécification. Ainsi pour répliquer un réseau IP basé sur un routage au plus court chemin, le contrôleur Openflow doit reconstituer la topologie du réseau, calculer les plus courts chemins du point de vue de chaque switch et peupler les tables de flux de chaque switch avec les bonnes informations. Cette partie intelligence du contrôleur est fondamentale, car l’interface Openflow ne sert à rien si le contrôleur ne sait pas quoi programmer. Il est assez peu envisageable de programmer chaque flux manuellement sur chaque switch.
Un autre exemple est la diffusion de listes de filtrage sur le concept SDN, mais par le protocole de routage BGP (c’est la protocole BGP qui transporte/diffuse une liste de filtrage à un ensemble de routeurs). Nous avions d’ailleurs écrit un article dans un numéro antérieur de MISC auquel le lecteur pourra se référer [MISC BGP].
4. Comment sécuriser le SDN
Le contrôleur SDN est un élément clé du réseau. Un attaquant ayant accès au contrôleur peut piloter le réseau et manipuler ses ressources, ce qui peut avoir un effet dramatique pour les clients. Sa sécurité est donc très importante et peut être déclinée selon les chapitres suivants.
4.1 Sécurité de la zone d’administration
Le contrôleur SDN doit être dans une zone dite de gestion dûment protégée du réseau Intranet. Cette zone de gestion agit comme une zone tampon et de sécurité entre le réseau Intranet et le réseau opérationnel.
Des principes simples peuvent s’appliquer afin de sécuriser ces systèmes :
- aucun accès à cette zone de gestion n’est possible sans une authentification centrale préalable à la frontière de cette zone de gestion. Une fois réalisée, une deuxième authentification aura lieu sur le système visé au sein de la zone de gestion ;
- tout accès doit être préalablement lié à une notion d’autorisation, ai-je droit d’accéder à un tel serveur ? Un système de validation des droits doit être mis en place pour associer à chaque utilisateur des droits d’accès ;
- à des fins de contrôles, tous les accès ou commandes doivent faire l’objet de traces ;
- le trafic entre l’Intranet et le système visé au sein de la zone de gestion est sujet à un filtrage et autres analyses de sécurité ;
- le trafic entre la zone de gestion et le réseau opérationnel est sujet à un filtrage et autres analyses de sécurité ;
- l’accès aux équipements de la zone de gestion doit être soumis à des contrôles physiques stricts (accès règlementé au bâtiment, baie protégée par grille en cas d’hébergement dans un site partagé, etc.). Rappelons qu’il ne s’agit pas d’équipements militaires, et donc que ces équipements ont des failles physiques indéniables.
4.2 Sécurité des systèmes SDN
Le contrôleur SDN est souvent une application hébergée sur un serveur. Les serveurs sont par construction plus sujets aux attaques que les équipements réseaux, ceux-ci utilisant des systèmes d’exploitation plus ou moins propriétaires, là où les serveurs, notamment basés sur Linux, disposent de code plus ouvert.
De plus, la population de serveurs est en général beaucoup plus grande que les équipements donnant un spectre plus intéressant pour les attaquants.
4.3 Sécurité des commandes clientes via l’interface Nord
L’interface Nord constitue l’un des points où la sécurité doit être la plus importante, car accessible par des applications internes ou externes.
En cas d’utilisation par des applications externes, un système d’authentification devra être mis en œuvre pour autoriser les systèmes sous-jacents à accéder aux services de cette interface.
L’exécution de commandes réseaux devra être considérée avec la plus grande prudence à tous les niveaux en restreignant les possibilités offertes et en mettant en œuvre les mesures nécessaires de sécurité (authentification, autorisation, traçabilité, etc.). Une bonne pratique consiste à dériver par exemple un compte réseau (login/password) pour chaque compte client (login/password) de manière à ce qu’un client ne connaisse pas ce compte dérivé tel que :
- Compte client : (« cedric.llorens » / « Misc »)
- Compte réseau :
- msk = chaîne de caractères secrète générée de manière aléatoire avec une forte entropie ;
- Login = AlgoHash(« cedric.llorens » + « login » + msk) : on calcule un nouveau login par un Hash de la concaténation de trois chaînes de caractères ;
- Password = AlgoHash(« cedric.llorens » + « password » + msk) : voir le calcul du login.
Cette interface pouvant faire partie d’un domaine public (joignable depuis l’extérieur du réseau), elle peut être soumise également à des attaques de type déni de service.
Les dénis de service peuvent intervenir à plusieurs niveaux :
- provoquer un impact sur le contrôleur lui-même : le contrôleur est surchargé et ne peut plus réaliser ses tâches provoquant une perte de plan de contrôle dans le réseau ;
- provoquer un impact sur les éléments réseaux au travers du contrôleur : le contrôleur est sollicité pour allouer des ressources dans le réseau entraînant un manque de ressources dans les éléments réseaux pour les besoins réels.
Il convient donc de réfléchir également à des mécanismes de protection contre ces dénis de service, par exemple :
- limitation temporelle du nombre de requêtes de configuration globale et par utilisateur ;
- limitation des ressources allouables pour un utilisateur donné sur un équipement donné.
Les équipements réseaux restent des éléments qui doivent également rester protégés comme aujourd’hui, et il faut réfléchir au besoin de les protéger contre le contrôleur SDN au cas où celui-ci serait manipulé par un tiers malveillant. Ainsi l’équipement peut toujours limiter les capacités qu’il expose au contrôleur ainsi que (si cela est possible) les ressources (et la quantité) qu’il expose.
Les autres interfaces ne sont pas à négliger pour autant, et il sera indispensable de penser au chiffrement et à l’authentification sur ces interfaces. En fonction du niveau de confiance de ces interfaces et de leur exposition (transit sur un réseau privé ou public), certaines règles pourraient être relâchées comme illustré à la figure 6.
Fig. 6 : Sécurité du contrôleur SDN.
4.4 Contrôle des configurations
Que ce soit des configurations d’équipements réseaux ou de systèmes virtualisés, toute configuration induite doit faire l’objet d’un audit vérifiant que les règles de sécurité définies par l’ingénierie sont bien en place, et ce dans la durée.
Deux types d’audit techniques sont classiquement nécessaires :
- pour les audits techniques internes, HAWK vous permettra d’accomplir un tel objectif que ce soit pour des configurations Cisco, Juniper, Fortinet, Packet-filter, etc. [HAWK]. De nombreux exemples de codage sont donnés sur le site permettant de les extrapoler à d’autres types de configuration ;
- pour les audits techniques externes, NESSUS ou outils similaires vous permettront de vous assurer/confirmer votre politique de sécurité vue de l’extérieur.
Conclusion
Le réseau est en pleine mutation et cette mutation s’annonce profonde à tous les points de vue. Les perspectives d’un réseau programmable sont multiples et il est fort à parier que cette révolution permettra aux utilisateurs d’avoir des services plus rapides et performants.
Cependant, l’aspect sécurité, comme dans toute nouveauté, est souvent mal traité et doit faire l’objet d’une attention toute particulière sur des projets que l’on qualifie d’immatures.
Références
[HAWK] D.Valois, C.Llorens :
- code source et historique de HAWK : https://sites.google.com/site/tableaudebordsecurite/supports-de-td
- hk.hawk@laposte.net pour toute question/support.
[MISC BGP] C.Llorens, D.Valois, « Utilisation de BGP pour distribuer des listes de filtrage de manière dynamique », MISC n°78, mars-avril 2015.
[RFC7149] Internet Engineering Task Force (IETF), M. Boucadair, C. Jacquenet, « Software-Defined Networking : A Perspective from within a Service Provider Environment », march 2014
