CHAPITRE 4
Assurer la sécurité des réseaux SDN
1. Disponibilité dans la spécification OpenFlow
2. Contrôle d’accès
3. Intégrité
03 - La sécurité des réseaux SDN
Evolution de la sécurité OpenFlow
Specifications
OpenFlow version 0.8.9 (2 décembre 2008) : Comportement défini lorsque la connexion
du contrôleur est perdue ("ne rien faire - laisser les flux expirer naturellement", "geler les
délais", "devenir un commutateur d'apprentissage" et "tenter de se connecter à un autre
contrôleur")
OpenFlow version 0.9 (20 juillet 2009) : la première version qui inclut un mécanisme de
basculement simple
Cache de flux d'urgence : entrées de flux spécifiques aux urgences qui sont inactives
jusqu'à ce qu'un commutateur perde la connectivité du contrôleur
OpenFlow version 1.0 (31 décembre 2009) : remplacer les références SSL par TLS
PARTIE
2
03 - La sécurité des réseaux SDN
Evolution de la sécurité OpenFlow
OpenFlow version 1.1 (28 février 2011) :
Supprimer le cache de flux d'urgence de la spécification en raison du manque
d'adoption et de la complexité à mettre en œuvre Les déclencheurs d'interruption de
connexion échouent en mode sécurisé ou autonome.
En mode sécurisé, le commutateur continue de fonctionner en mode
OpenFlow jusqu'à ce qu'il se reconnecte à un contrôleur. En mode
autonome en cas d'échec, le commutateur revient à l'utilisation du
traitement normal (commutation Ethernet)
OpenFlow version 1.2 (5 décembre 2011) :
Mécanisme de changement de rôle du contrôleur : permet à chaque
contrôleur de changer ses rôles en égal, maître ou esclave
OpenFlow Version 1.4.0, le message d'état du rôle permet au commutateur
PARTIE
d'informer le contrôleur du changement de son rôle
2
03 - La sécurité des réseaux SDN
Disponibilité dans la spécification OpenFlow
Disponibilité dans la spécification OpenFlow
• Disponibilité dans la spécification OpenFlow
• Load Balancing / Failover
• Load Balancing : EQUAL / EQUAL or
MASTER / EQUAL
• Failover : MASTER / SLAVE
• Messages spécifiques :
OFPT_ROLE_REQUEST, OFPT_ROLE_REPLY
PARTIE
2
03 - La sécurité des réseaux SDN
Disponibilité dans la spécification OpenFlow
Disponibilité dans la spécification
OpenFlow
Scénario de Failover
PARTIE
2
03 - La sécurité des réseaux SDN
Disponibilité dans la spécification OpenFlow
Disponibilité dans la spécification OpenFlow
Performance
• OpenFlow 1.5.0 (depuis1.4.0 version)
• Mécanisme d’éviction (mesure corrective)
• Quand la table de flux est saturée, de nouvelle règles de flux ne peuvent êtres ajoutées
et un message d’erreur est retourné au contrôleur
• Le mécanisme d’éviction permet au Switch de supprimer automatiquement des entrés de
flux moins importantes pour créer suffisamment d’espaces pour en rajouter de nouvelles
• Atténue les dégradations de performances dans les situations extrêmes
• Vacancy Event (mesure préventive)
• Grace aux Vacancy events, le contrôleur reçoit une alerte quand la table de flux atteint
un seuil de remplissage prédéfini
PARTIE
• Le contrôleur anticipe à l’avance les situations de saturation et agit pour résoudre le
problème
2
03 - La sécurité des réseaux SDN
Disponibilité dans la spécification OpenFlow
Fonctionnalité « Group table »
• Monitoring permanent de l’état des ports des Switchs
• La valeur du champ OFPPC_PORT_DOWN du message ofp_port_config communique l’état du
port au contrôleur
• La valeur du champ OFPPC_LINK_DOWN du message ofp_port_state communique l’état du
lien au contrôleur
• L’exploitation de Fast Failover Table Group (chemin de backup précalculé) permet de renseigner
le Switch sur le comportement en cas de panne de port ou de lien de façon autonome (sans
revenir au contrôleur)
PARTIE
2
03 - La sécurité des réseaux SDN
Disponibilité Fast Failure Recovery
AFRO (Automatic Failure Recovery for OpenFlow) – La
problématique de la reprise après un échec
d’un élément du réseau (Switch en l’occurrence)
Automatisation de la reprise après incidents de réseau
SDN
Idée principale : Séparation des modules fonctionnels de
ceux relatifs à la reprises après échec
• Réduit la probabilité d’introduction de bugs dus à la
complexité des modules
développés
Shadow Controller : Après détection d’échec d’un
composant réseau, créer un contrôleur
logique travaillant sur un environnement émulé identique
PARTIE
mais sans le noeud en échec
• Re-calcul de l’état de transmission de nouvelle
2
topologie (peut être effectué avant l’incident pour
accélérer la reprise)
03 - La sécurité des réseaux SDN
Disponibilité dans la spécification OpenFlow
AFRO opère en deux modes :
Record mode : Etat normal du réseau
Enregistre tous les PacketIn et garde trace des
règles configurées « FlowMod
» et « FlowRem »
Recovery mode : activé après la découverte d’un échec
(Replay + Reconfig)
Replay : AFRO crée une nouvelle instance du
contrôleur « shadow controller » identique mais
avec un état de transmission vierge
Reconfiguration : Application des changements de
configuration au niveau du contrôleur et des Switchs
sans mettre le réseau dans un état inconsistant.
PARTIE
2
CHAPITRE 3
Assurer la sécurité des réseaux SDN
1. Disponibilité dans la spécification OpenFlow
2. Contrôle d’accès
3. Intégrité
03 - La sécurité des réseaux SDN
Contrôle d’accès
Disponibilité : Fast Failure Recovery
Privilèges élevés du contrôleur sur les Switchs
Peut être exploités à des fins malveillantes
Deux types d’interfaces d’accès au contrôleur :
Southbound interface (Switch au contrôleur)
Northbound interface (application au contrôleur) : la
sécurité de cette interface est hors du périmètre de
la spécification OpenFlow
PARTIE
2
03 - La sécurité des réseaux SDN
Contrôle d’accès
Sécurité de l’interface Northbound
Il s’agit de l’interface qui permet la programmabilité du contrôleur
La stratégie de contrôle d’accès doit être la plus restrictive possible pour empêcher les
effets d’erreurs ou d’introduction d’applications malicieuses
Stratégie « defense in depth » :
• Verrouiller le contrôleur autant que possible
• Désactiver les comptes et les services non nécessaires
• Maintenir le contrôleur à jour (correction des vulnérabilités)
• Politique de gestion des droits en conformité avec les principes fondamentaux
de la sécurité (Least privilege & separation of duties)
• Monitoring permanent de l’activité des ressources critiques (CPU, RAM, I/O…)
• Journalisation des activités critiques
PARTIE
• Surveiller toute déviation par rapport à un profil de comportement normal (IDS)
• Profils fail safe vs fail secure
2
• …
03 - La sécurité des réseaux SDN
Contrôle d’accès
Sécurité de l’interface Southbound
Southbound interface (network devices to controller)
• Problématique essentielle : Authentification entre le Switch et le contrôleur
• « The OpenFlow channel is usually encrypted using TLS, but may be run
directly over TCP “
L’usage de TLS assure :
• L’authentification du contrôleur (requise)
• L’authentification du noeud réseau par certificat (optionelle)
• La confidentialité des données échangées (session chiffrée)
• L’intégrité des données échangées
PARTIE
2
03 - La sécurité des réseaux SDN
Contrôle d’accès
Points critiques :
• L’usage de TLS est optionnel jusqu’à la version 1.5.0
• Pas de mention sur la version de TLS
• La version 1.5.1 (Mars 2015) recommande l’usage de la version 1.2 de TLS
• Pas de précision sur la version du certificat à utiliser pour l’authentification
Apports de TLS 1.2
• Correction de la vulnérabilité Mant-In-The-Middle Attack (CBC attack)
• Remplacement des algorithmes MD5/SHA1 par SHA256
• Compatibilité avec SSL 2.0 n’est plus obligatoire
PARTIE
2
CHAPITRE 3
Assurer la sécurité des réseaux SDN
1. Disponibilité dans la spécification OpenFlow
2. Contrôle d’accès
3. Intégrité
03 - La sécurité des réseaux SDN
Sécurité
Le contrôleur est supposé interagir avec plusieurs types d’applications
Possibilité de conflits entre les règles générées par diverses applications
Catégorisation des applications par rôle:
• ADMIN : politique statique définie par l’administrateur
• Politique Firewall, zoning réseau, ACL
• SEC-APP : application générant des règles dynamiques en réponse à des événements précis NAC,
DLP, IPS…
• APP : applications classiques d’ingénierie de trafic : routage, QoS, Load balancing…
PARTIE
2
03 - La sécurité des réseaux SDN
Politique de médiation
RCA : Rule-Based Conflict Analysis
• Champ d’application : Couche application vers Couche infrastructure
• Concerne les messages d’ajout ou de modification de règle de flux (Flow rule Mod) et concerne tous les
types d’applications
Politique : aucune application d’un niveau de privilège déterminé ne doit ajouter une règle de flux en
conflit avec une autre ajoutée par une application de niveau de privilège supérieur
Exemple : une application de routage autorise un flux qui a été bloqué par une application IPS
Public read : concerne les messages des événements notifiés par les noeuds réseaux aux applications
(n’affectent pas les tables de flux)
• Global Read : les événements destinés à toutes les applications
• Flow removal messages, flow error reply …
PARTIE
2
03 - La sécurité des réseaux SDN
Intégrité
• Selected Read : les événements destinés uniquement à certaines applications concernées
par l’événement
Barrier replies, Packet-In return, Switch config reply, Switch stats report and Echo replies
Politique : conformité au principe Least privilege par la limitation de la visibilité des
applications sur le réseau au strict minimum nécessaire
Permission : opérations spécifiques nécessitant une permission explicite avant d’être autorisées
• Configuration de switchs ou tests de connectivité (peuvent altérer les règles de flux ou la
configuration des Switchs)
• Barrier request, Packet-Out, Switch port mod, Switch port status, Switch set config, Switch
get config, Switch stats request, Echo request, Vendor features, vendor actions
Politique : conformité au principe Least privilege par la limitation des privilèges sur le réseau
au strict minimum nécessaire
PARTIE
2
03 - La sécurité des réseaux SDN
Intégrité
Politique de médiation
PARTIE
2
