Vecteurs d’attaque de sécurité SDN et renforcement du SDN

Vecteurs d’attaque de sécurité SDN et renforcement du SDN

Sécuriser les déploiements SDN dès le départ.

1. Vecteurs d’attaque SDN

La mise en réseau définie par logiciel (SDN) est une approche de mise en réseau qui sépare le plan de contrôle du plan de transfert pour prendre en charge la virtualisation. SDN est un nouveau paradigme pour la virtualisation des réseaux. La plupart des modèles d’architecture SDN comportent trois couches : une couche inférieure de périphériques réseau compatibles SDN, une couche intermédiaire de contrôleurs SDN et une couche supérieure qui inclut les applications et les services qui demandent ou configurent le SDN. Même si de nombreux systèmes SDN sont relativement nouveaux et que le SDN est encore l’apanage des premiers utilisateurs, nous pouvons être sûrs qu’à mesure que la technologie mûrit et est plus largement déployée, elle deviendra une cible pour les attaquants.

On peut anticiper plusieurs vecteurs d’attaque sur les systèmes SDN. Les problèmes de sécurité SDN les plus courants incluent les attaques au niveau des différentes couches de l’architecture SDN. Examinons les attaques anticipées qui pourraient survenir au niveau de chacune de ces couches. Voici une image illustrant une architecture SDN typique et la provenance possible des attaquants.

1-1. Attaques au niveau de la couche du plan de données

Les attaquants pourraient cibler les éléments du réseau depuis le réseau lui-même. Un attaquant pourrait théoriquement obtenir un accès physique ou virtuel non autorisé au réseau ou compromettre un hôte déjà connecté au SDN et tenter ensuite de mener des attaques pour déstabiliser les éléments du réseau. Il peut s’agir d’un type d’attaque par déni de service (DoS) ou d’un type d’attaque par fuzzing visant à tenter d’attaquer les éléments du réseau.

Il existe de nombreuses API et protocoles vers le sud utilisés par le contrôleur pour communiquer avec les éléments du réseau. Ces communications SDN vers le sud pourraient utiliser OpenFlow (OF), Open vSwitch Database Management Protocol (OVSDB), Path Computation Element Communication Protocol (PCEP), Interface to the Routing System (I2RS), BGP-LS, OpenStack Neutron, Open Management Infrastructure (OMI). ), Puppet, Chef, Diameter, Radius, NETCONF, Extensible Messaging and Presence Protocol (XMPP), Locator/ID Separation Protocol (LISP), Simple Network Management Protocol (SNMP), CLI, Embedded Event Manager (EEM), Cisco onePK, Infrastructure centrée sur les applications (ACI), Opflex, entre autres. Chacun de ces protocoles possède ses propres méthodes pour sécuriser les communications avec les éléments du réseau. Cependant, bon nombre de ces protocoles sont très récents et leurs responsables ne les ont peut-être pas mis en place de la manière la plus sécurisée possible.

Un attaquant pourrait également exploiter ces protocoles et tenter d’instancier de nouveaux flux dans la table de flux de l’appareil. L’attaquant voudrait tenter d’usurper de nouveaux flux pour autoriser des types de trafic spécifiques qui devraient être interdits sur le réseau. Si un attaquant pouvait créer un flux qui contourne la direction du trafic qui guide le trafic à travers un pare-feu, l’attaquant aurait un avantage décisif. Si l’attaquant peut diriger le trafic dans sa direction, il peut essayer d’exploiter cette capacité pour détecter le trafic et effectuer une attaque Man in the Middle (MITM).

Un attaquant souhaiterait écouter les flux pour voir quels flux sont utilisés et quel trafic est autorisé sur le réseau. L’attaquant voudrait essayer d’écouter les communications vers le sud entre l’élément de réseau et le contrôleur. Ces informations pourraient être utiles pour une attaque par rejeu ou simplement à des fins de reconnaissance.

De nombreux systèmes SDN sont déployés dans les centres de données et les centres de données utilisent plus fréquemment des protocoles DCI (Data Center Interconnect) tels que la virtualisation de réseau utilisant l’encapsulation de routage générique (NVGRE), le tunneling de transport sans état (STT), le réseau local extensible virtuel (VXLAN), la superposition Cisco. Virtualisation du transport (OTV), Layer 2 Multi-Path (L2MP), protocoles basés sur TRILL (Cisco FabricPath, Juniper QFabric, Brocade VCS Fabric), Shortest Path Bridging (SPB), entre autres. Ces protocoles peuvent manquer d’authentification et de toute forme de cryptage pour sécuriser le contenu des paquets. Ces nouveaux protocoles pourraient présenter des vulnérabilités dues à un aspect de la conception du protocole ou à la manière dont le fournisseur ou le client a implémenté le protocole. Un attaquant pourrait être incité à créer un trafic usurpé de telle manière qu’il traverse les liaisons DCI ou à créer une attaque DoS sur les connexions DCI.

1-2. Attaques au niveau de la couche contrôleur

Il est évident que le contrôleur SDN est une cible d’attaque. Un attaquant tenterait de cibler le contrôleur SDN à plusieurs fins. L’attaquant voudrait instancier de nouveaux flux soit en usurpant les messages API en direction nord, soit en usurpant les messages en direction sud vers les périphériques réseau. Si un attaquant parvient à usurper les flux provenant du contrôleur légitime, il aura alors la possibilité de permettre au trafic de circuler à travers le SDN à sa guise et éventuellement de contourner les politiques sur lesquelles on peut s’appuyer pour la sécurité.

Un attaquant pourrait tenter d’effectuer un DoS sur le contrôleur ou utiliser une autre méthode pour provoquer l’échec du contrôleur. L’attaquant pourrait tenter une forme d’attaque de consommation de ressources sur le contrôleur pour l’enliser et l’amener à répondre extrêmement lentement aux événements Packet_In et ralentir l’envoi des messages Packet_Out.

Souvent, les contrôleurs SDN fonctionnent sur une certaine forme de système d’exploitation Linux. Si le contrôleur SDN s’exécute sur un système d’exploitation à usage général, les vulnérabilités de ce système d’exploitation deviennent des vulnérabilités pour le contrôleur. Souvent, les contrôleurs sont déployés en production en utilisant les mots de passe par défaut et aucun paramètre de sécurité configuré. Les ingénieurs SDN l’ont fait fonctionner « à peine » et n’ont pas voulu y toucher de peur de le casser, de sorte que le système se retrouve en production dans une configuration vulnérable.

Enfin, ce serait une mauvaise chose si un attaquant créait son propre contrôleur et faisait croire aux éléments du réseau les flux provenant du contrôleur « malveillant ». L’attaquant pourrait alors créer des entrées dans les tables de flux des éléments du réseau et les ingénieurs SDN n’auraient pas de visibilité sur ces flux du point de vue du contrôleur de production. Dans ce cas, l’attaquant aurait le contrôle total du réseau.

1-3. Attaques au niveau de la couche SDN

Attaquer la sécurité du protocole en direction du nord serait également un vecteur probable. Il existe de nombreuses API orientées vers le nord qui sont utilisées par les contrôleurs SDN. Les API Northbound pourraient utiliser Python, Java, C, REST, XML, JSON, entre autres. Si l’attaquant pouvait exploiter l’API vulnérable en direction nord, il aurait alors le contrôle du réseau SDN via le contrôleur. Si le contrôleur ne disposait d’aucune forme de sécurité pour l’API nord, l’attaquant pourrait alors être en mesure de créer ses propres politiques SDN et ainsi prendre le contrôle de l’environnement SDN.

Souvent, il existe un mot de passe par défaut utilisé pour une API REST qui est simple à déterminer. Si un déploiement SDN ne modifiait pas ce mot de passe par défaut et que l’attaquant pouvait créer des paquets vers l’interface de gestion du contrôleur, alors l’attaquant pourrait interroger la configuration de l’environnement SDN et mettre en place sa propre configuration.

2. Renforcer un système SDN

Avec l’introduction du SDN, une nouvelle méthode est nécessaire pour sécuriser le trafic du plan de contrôle. Dans les réseaux IP traditionnels, la sécurité du plan de contrôle prenait la forme de mesures de sécurité du protocole de routage qui impliquaient l’utilisation de MD5 pour EIGRP, IS-IS ou OSPFv2, IPsec AH dans le cas d’OSPFv3 ou GTSM/ ACL /mots de passe pour MP-BGP. Certains développeurs ne suivent même pas ces techniques simples pour les réseaux IP traditionnels. S’ils abordent le déploiement d’un SDN avec le même mépris pour la sécurité, ils exposeront alors leur organisation à des attaques. Voyons comment sécuriser un système SDN basé sur le renforcement des trois couches illustrées dans le diagramme d’architecture ci-dessus.

2-1. Sécurisation de la couche du plan de données

Les systèmes SDN typiques exploitent les processeurs X86 et utilisent TLS (anciennement SSL) pour la sécurité du plan de contrôle. Ces sessions HTTP de longue durée sont sensibles à un large éventail d’attaques susceptibles de compromettre l’intégrité du plan de données. Cela contournerait la multilocation de ces solutions et compromettrait les services basés sur le cloud. Les organisations devraient préférer utiliser TLS pour authentifier et chiffrer le trafic entre l’agent de périphérique réseau et le contrôleur. L’utilisation de TLS permet d’authentifier le contrôleur et les périphériques réseau/agent SDN et d’éviter les écoutes clandestines et les communications usurpées vers le sud.

Selon le protocole sud utilisé, il peut exister des options pour sécuriser ces communications. Certains protocoles peuvent être utilisés dans les sessions TLS comme mentionné précédemment. D’autres protocoles peuvent utiliser des mots de passe secrets partagés et/ou des mots de passe occasionnels pour empêcher les attaques par réexécution. Les protocoles comme SNMPv3 offrent plus de sécurité que SNMPv2c et SSH est bien meilleur que Telnet. D’autres protocoles propriétaires vers le sud peuvent avoir leurs propres méthodes pour authentifier les agents et les contrôleurs des périphériques réseau et chiffrer les données entre eux, contrecarrant ainsi les écoutes clandestines et l’usurpation d’identité de l’attaquant.

De même, en fonction du protocole Data Center Interconnect (DCI) utilisé, il peut exister des options configurables pour authentifier les points de terminaison du tunnel et sécuriser le trafic tunnelisé. Encore une fois, les mots de passe/secrets partagés peuvent être une option. Cependant, certains protocoles DCI peuvent ne proposer aucune option de sécurité.

Les organisations peuvent croire qu’un réseau privé possède une certaine sécurité inhérente. À mesure que les organisations étendent leurs réseaux virtuels et SDN aux services cloud et aux centres de données distants, la vérification du chemin physique peut ne pas être aussi simple. Il est plus facile d’empêcher les accès non autorisés lorsqu’une organisation contrôle l’accès physique, mais à mesure que les réseaux se virtualisent, le chemin physique réel devient un peu flou. Il est difficile de sécuriser ce que l’on ne peut pas voir.

2-2. Sécuriser la couche contrôleur

Le contrôleur est une cible d’attaque clé et doit donc être renforcé. Le renforcement de la posture de sécurité du contrôleur et des éléments du réseau se résume généralement au renforcement du système d’exploitation hôte. Toutes les meilleures pratiques pour renforcer les serveurs Linux publics sont applicables ici. Néanmoins, les organisations voudront surveiller de près leurs contrôleurs pour détecter toute activité suspecte.

Les organisations voudront également empêcher tout accès non autorisé au réseau de contrôle SDN. Les systèmes SDN doivent permettre la configuration d’un accès administrateur sécurisé et authentifié au contrôleur. Même des politiques de contrôle d’accès basé sur les rôles (RBAC) peuvent être requises pour les administrateurs de contrôleurs. La journalisation et les pistes d’audit peuvent être utiles pour vérifier les modifications non autorisées par les administrateurs ou les attaquants.

En cas d’attaque DoS du contrôleur, il est alors avantageux de disposer d’une architecture de contrôleur haute disponibilité (HA). Les SDN qui utilisent des contrôleurs redondants pourraient subir la perte d’un contrôleur et continuer à fonctionner. Cela mettrait la barre plus haut pour un attaquant essayant de faire un DoS sur tous les contrôleurs du système. En outre, cette attaque ne serait pas particulièrement furtive et ne contribuerait pas à l’objectif de l’attaquant de ne pas être détecté.

2-3. Sécuriser la couche SDN

Une autre mesure de protection consiste à utiliser un réseau hors bande (OOB) pour contrôler le trafic. Il est plus facile et moins coûteux de construire un réseau OOB dans un centre de données que sur un WAN d’entreprise. L’utilisation d’un réseau OOB pour les communications vers le nord et vers le sud pourrait contribuer à sécuriser les protocoles de gestion des contrôleurs.

L’utilisation de TLS ou SSH ou d’une autre méthode pour sécuriser les communications vers le nord et sécuriser la gestion des contrôleurs serait considérée comme une bonne pratique. Les communications des applications et des services demandant des services ou des données au responsable du traitement doivent être sécurisées à l’aide de méthodes d’authentification et de cryptage.

Les pratiques de codage sécurisées pour toutes les applications vers le nord demandant des ressources SDN devraient constituer une bonne pratique. Non seulement les pratiques de codage sécurisées sont bénéfiques pour la sécurité des applications Web Internet publiques, mais elles sont également applicables aux connexions SDN vers le nord.

Certains systèmes SDN ont la capacité de valider les flux dans les tables de périphériques réseau par rapport à la stratégie du contrôleur. Ce type de vérification (similaire à FlowChecker ) des flux dans les périphériques réseau par rapport à la politique de la politique pourrait aider à identifier les écarts résultant d’une attaque.

3. Résumé

Nous ne pouvons qu’essayer d’anticiper ce que les attaquants pourraient tenter de cibler avec les SDN. Les déploiements sont nouveaux, les protocoles sont nouveaux, le logiciel du contrôleur est nouveau et l’historique des attaques SDN passées est inconnu. Grâce à l’architecture SDN, nous pouvons prédire où un attaquant est susceptible de frapper. Si nous nous mettons à la place de l’attaquant, nous pourrons peut-être repérer une faiblesse à exploiter. Nous pourrons alors renforcer cette faiblesse à l’avance.

Avant qu’une organisation se lance dans un projet de déploiement SDN, elle doit réfléchir à la manière dont elle va sécuriser le système dès les premières étapes de conception. Ne quittez pas la sécurité avant la phase finale de nettoyage. Si une organisation attend jusqu’à ce qu’elle fonctionne, le renforcement des messages de contrôle en direction nord et sud peut entraîner des problèmes affectant le service. Comme pour la plupart des choses, sa mise en place dès le départ évitera aux organisations de nombreux problèmes à long terme.