SDN ou comment le réseau s’automatise à grande échelle

Magazine
Marque
MISC
Numéro
91
Mois de parution
mai 2017
Spécialité(s)


Résumé

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.


Body

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.

figure1

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.

figure2

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.

figure3

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.

figure4

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.

figure5

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.

figure6

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 :

[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



Article rédigé par

Par le(s) même(s) auteur(s)

Trouver efficacement les équipements réseau vulnérables à un PSIRT

Magazine
Marque
MISC
Numéro
95
Mois de parution
janvier 2018
Spécialité(s)
Résumé

Nous présentons dans cet article comment rechercher des vulnérabilités sur des équipements réseau grâce au langage BIRD. Après une présentation de celui-ci et d'une vulnérabilité récente concernant des équipements Cisco, nous décrirons une méthodologie de recherche puis nous comparerons les performances de BIRD par rapport à HAWK dans une telle recherche.

Quelques éléments de sécurité IPv6 à prendre en compte sur un réseau d’opérateur

Magazine
Marque
MISC
Numéro
83
Mois de parution
janvier 2016
Spécialité(s)
Résumé

Nous présentons dans cet article les éléments de sécurité IPv6 à prendre en compte au sein d’un réseau multi-services d’un opérateur. Cet article abordera à la fois la partie routage d’accès et de routage interne, mais aussi le filtrage du trafic en transit sur le réseau de l’opérateur.

Renforcer la sécurité par configuration d’un équipement CISCO

Magazine
Marque
MISC
Numéro
82
Mois de parution
novembre 2015
Spécialité(s)
Résumé

Nous présentons dans cet article comment renforcer la sécurité par configuration d’un équipement exécutant un système d’exploitation de type CISCO IOS afin de faire face à la fois à des menaces aussi bien distantes que locales (prise en main physique de l’équipement). Ce guide permettra d’associer à chaque menace une contre-mesure de type configuration.

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 67 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous