SDN ou comment le réseau s’automatise à grande échelle – Partie 2/2

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 :

[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

Cédric LLORENS, Stéphane LITKOWSKI & Denis VALOIS

Retrouvez cet article (et bien d’autres) dans MISC n°91, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !