Sécurité de l'implémentation standard de VXLAN

VXLAN est largement utilisé dans les réseaux servant de support à des environnements où des serveurs virtualisés sont déployés en masse, tels que les « clouds ». Dans ce cadre, VXLAN permet une grande mobilité des VM, et des serveurs situés dans des réseaux Ethernet disjoints peuvent communiquer naturellement comme s'ils étaient dans le même réseau local. La complexité raisonnable de déploiement proposée par la RFC 7348 [1] peut facilement pousser un opérateur à opter pour l'implémentation décrite par la RFC. Cependant, la simplicité de fonctionnement proposée laisse une porte ouverte qui peut se révéler facilement exploitable par un attaquant, lui permettant, entre autres, de subtiliser des informations, de les modifier à la volée, ou de réaliser un déni de service dont l'origine peut être complexe à identifier.

1. VXLAN selon la RFC 7348

1.1 Étendre Ethernet via IP

La RFC 7348 décrit comment permettre à des serveurs de se parler comme s'ils étaient connectés dans le même réseau Ethernet alors qu'ils se situent en réalité dans des réseaux Ethernet disjoints.

Pour y parvenir, leurs trames Ethernet sont encapsulées par une entité spécifique, appelée VTEP (pour « VXLAN Tunnel End Point »), dans des paquets VXLAN, qui sont des paquets IP/UDP auxquels un en-tête VXLAN spécifique est concaténé.

Dans la figure 1, le serveur 1 émet une trame Ethernet à destination du serveur 2. Le VTEP qui gère le serveur 1 encapsule la trame dans un paquet VXLAN.

Les trames Ethernet ainsi encapsulées peuvent alors être acheminées jusqu'au VTEP destination qui cette fois décapsule la trame pour pouvoir la transmettre au destinataire final.

Dans la figure 2, le paquet VXLAN précédemment émis est reçu par le VTEP qui gère le serveur 2. Le VTEP décapsule la trame contenue dans le paquet VXLAN et la transmet au serveur 2.

Ces deux VTEP s'échangeant les paquets VXLAN au travers d'un réseau IP, le réseau Ethernet des serveurs est ainsi virtuellement étendu.

La figure 3 illustre le principe général de VXLAN : les trames émises par le serveur 1 sont encapsulées par le VTEP A dans des paquets VXLAN qui sont transmis aux VTEP B et C, qui à leur tour décapsulent et transmettent les trames aux serveurs destinataires.

1.2 Structure d'un paquet VXLAN

Un paquet VXLAN est un paquet UDP auquel un en-tête VXLAN spécifique de 8 octets, défini dans la RFC 7348, est concaténé, suivi par la trame Ethernet originale. L'extrait de la RFC ci-après présente la structure d'un paquet VXLAN (sans la trame Ethernet originale encapsulée).

On remarque ici que l'encapsulation occasionne une surcharge de 50 octets (constituée par l'en-tête Ethernet, l'en-tête externe IP et l'en-tête externe UDP) pour une trame Ethernet classique. On ajoutera 4 octets pour du 802.1q dans l'en-tête Ethernet externe.

Cette surcharge doit être prise en compte en particulier pour configurer au mieux la MTU dans le réseau et sur les serveurs.

On peut légitimement se questionner sur l'utilité en pratique du champ Flags : en effet, un seul « flag » est mentionné, sa sémantique n'est pas très précise, et rien n'est spécifié quant à la façon dont il doit être géré.

Le champ VNI (acronyme de VXLAN Network Identifier) sert à identifier le réseau virtuel auquel appartient la trame contenue : lorsqu'un VTEP reçoit un paquet VXLAN, le VTEP utilise ce numéro pour sélectionner la correspondance {adresse MAC → destination} adéquate (la destination pouvant être un VTEP ou une interface locale) qui lui permettra de délivrer la trame au destinataire.

En clair, cela signifie :

• qu'un VTEP possède des correspondances {adresse MAC → destination} pour chaque réseau virtuel qu'il gère ;
• que deux serveurs situés dans des réseaux virtuels distincts ne peuvent pas échanger de données directement au niveau Ethernet.

Afin d'éviter une lourdeur inutile, dans la suite de l'article le champ VNI ne sera plus mentionné et il sera considéré que les paquets VXLAN et les serveurs font systématiquement partie d'un même réseau virtuel.

1.3 Quelques détails complémentaires sur le VTEP

Le VTEP peut se situer sur un hyperviseur, sur un hôte hébergeant des conteneurs, ou encore sur un élément réseau physiquement séparé (par exemple un routeur) situé dans les mêmes réseaux Ethernet que les serveurs qu'il gère.

Comme on l'a vu précédemment, un VTEP doit pouvoir réaliser les deux opérations suivantes :

• encapsulation : le VTEP reçoit une trame Ethernet en provenance d'un serveur (VM, conteneur, ou serveur physique), il encapsule cette trame dans un paquet VXLAN et transmet ce dernier au VTEP correspondant) ;
• décapsulation : le VTEP reçoit un paquet VXLAN en provenance du réseau (communément d'un autre VTEP), il décapsule la trame Ethernet contenue dans le paquet VXLAN et transmet celle-ci à la VM destinataire.

1.4 Établir l'association {adresse MAC → destination}

Ce point représente le cœur de la vulnérabilité mise en avant par cet article.

Selon l'implémentation décrite par la RFC 7348, un VTEP apprend automatiquement l'origine d'une adresse MAC en inspectant les trames des serveurs qu'il voit passer, qu'il les reçoive directement d'un serveur, sous forme d'une trame Ethernet classique, ou qu'il les reçoive d'un autre VTEP via un paquet VXLAN.

Dans les deux cas, il enregistre l'adresse MAC source de la trame Ethernet et sa provenance :

• dans le cas d'une trame Ethernet classique provenant directement d'un serveur, le VTEP enregistre l'interface source et crée une association {adresse MAC → interface} (cf. figure 4) ;

- dans le cas d'une trame Ethernet contenue dans un paquet VXLAN, le VTEP enregistre l'adresse IP source du paquet VXLAN (i.e. l'adresse IP du VTEP ayant émis le paquet VXLAN) et crée une association {adresse MAC → VTEP d'origine} (cf. figure 5).

Grâce à cet apprentissage automatique, un VTEP va être capable de transmettre les trames qu'il reçoit, que ce soit à destination d'un autre VTEP ou à destination d'un serveur local.

Cependant, lorsqu'il reçoit une trame Ethernet à destination d'un serveur distant, le VTEP origine ne connaît pas encore nécessairement l'adresse IP du VTEP qui saura transmettre la trame au serveur destinataire. C'est en particulier le cas d'un VTEP qui vient de s'initialiser : il ne connaît alors aucune association.

Dans ce cas de figure, la RFC 7348 propose d'utiliser une adresse multicast prédéfinie comme adresse IP de destination du paquet VXLAN : tous les VTEP ayant la capacité de gérer ce paquet VXLAN sont abonnés au groupe multicast prédéfini. Lorsque le VTEP effectivement concerné (i.e. pouvant gérer les trames à destination de l'adresse MAC destination figurant dans la trame Ethernet encapsulée) reçoit le paquet VXLAN, il décapsule la trame contenue et la transmet au serveur final.

À cette occasion, comme indiqué précédemment, ce VTEP crée l'association {adresse MAC → VTEP} idoine.

Dans le cas de trames de « broadcast » (p. ex. une requête ARP), tous les VTEP d'un même réseau, recevant ce type de trames via un paquet VXLAN, transmettent ces trames à tous les serveurs de ce réseau qui leur sont rattachés, permettant ainsi aux serveurs potentiellement intéressés de répondre à ces trames.

Suite à cet apprentissage, lorsque le VTEP doit encapsuler une trame c'est cette association {adresse MAC → VTEP} qui lui permettra de déterminer l'adresse IP destination du paquet VXLAN.

Ce procédé d'apprentissage, propre à la RFC 7348, rend possible une attaque de type « homme du milieu » : un attaquant peut faire croire à un VTEP qu'il doit envoyer les paquets à destination d'une adresse MAC donnée à un VTEP malveillant en forgeant à dessein un paquet VXLAN. Aucune protection n'existant, le VTEP apprendra cette association et l'utilisera par la suite.

2. Exploitation de la vulnérabilité

L'attaque présentée par cet article permet d'écouter et d'éventuellement modifier le trafic échangé par deux serveurs situés dans un réseau virtuel VXLAN. Elle repose sur le fait de fournir de fausses informations aux VTEP en leur faisant envoyer les paquets VXLAN souhaités à l'attaquant. L'attaquant est supposé situé sur un équipement différent de ceux hébergeant les VTEP attaqués : c'est l'attaque la plus simple, car elle ne requiert aucune altération du système attaqué, seul ce type d'attaque sera considéré ici.

2.1 Conditions de réalisation

Afin de réaliser une attaque complète portant sur un échange entre deux serveurs d'un réseau virtuel VXLAN, certaines conditions doivent être remplies :

• l'attaquant doit avoir le contrôle d'un équipement capable d'émettre et de recevoir des paquets dans le réseau des VTEP ;
• les deux serveurs doivent être gérés par des VTEP différents : si les deux serveurs sont gérés par le même VTEP non modifié l'attaque échouera ;
• il peut être nécessaire d'empoisonner durablement les deux VTEP gérant les deux serveurs (cf. section 2.2.3 Événements perturbateurs) ;
• l'attaquant doit connaître les adresses IP des VTEP attaqués ainsi que les adresses MAC utilisées par les serveurs.

On ne parle donc pas d'une attaque réalisable par n'importe quel attaquant : il est déjà présent dans le réseau, et suffisamment renseigné.

Cela étant dit, selon les éléments déjà compromis par l'attaquant, celui-ci peut aussi prendre connaissance d'informations utiles en « écoutant » le réseau VXLAN :

• si l'attaquant a compromis un serveur pouvant s'abonner à des groupes multicast, il finira par découvrir ceux utilisés dans le réseau VXLAN et de fil en aiguille aura suffisamment d'informations pour réaliser des attaques (on notera que cette approche peut être longue, mais il est très probable qu'elle passe inaperçue) ;
• si l'attaquant a compromis un hyperviseur (suite à une évasion de VM par exemple), il peut également observer le trafic et identifier ce qui peut être intéressant pour lui.

2.2 Les différents aspects de l'attaque

2.2.1 Empoisonnement des 2 VTEP

Le but de l'empoisonnement est d'indiquer aux 2 VTEP qu'ils doivent envoyer des trames destinées à des adresses MAC spécifiques au VTEP de l'attaquant.

Pour y parvenir, l'attaquant peut forger un paquet VXLAN contenant une trame ayant comme source l'adresse MAC que l'on souhaite détourner. L'attaquant doit réaliser cette action pour les 2 adresses MAC de la conversation qu'il souhaite détourner.

2.2.2 Actions sur les paquets détournés

Lorsque l'attaquant reçoit un paquet détourné, il peut réaliser bon nombre d'actions, dont, entre autres :

• envoyer le paquet reçu vers le destinataire légitime, modifié ou non ;
• détruire le paquet ;
• enregistrer le paquet ;
• transmettre une copie du paquet à un autre équipement.

Pour transmettre la trame au destinataire légitime, il suffit à l'attaquant de reforger un paquet VXLAN avec la trame reçue.

2.2.3 Événements perturbateurs

Selon les services configurés sur un serveur, certains événements peuvent perturber l'attaque en rétablissant les associations {adresse MAC → VTEP} légitimes. Ces événements sont souvent caractérisés par l'envoi de trames en mode « broadcast » : ce type de trames est nécessairement envoyé dans des paquets VXLAN en multicast, provoquant le réapprentissage de l'adresse MAC source y figurant par les VTEP précédemment empoisonnés. Ces paquets sont en général des requêtes DHCP IPv4 ou des découvertes de voisins IPv6, provoquées par des renouvellements de bail, ou encore des configurations réseau incomplètes/incorrectes de serveurs.

Un attaquant conscient de ce type d'événement peut simplement mettre en place un empoisonnement régulier des VTEP qui n'occasionnera pour lui qu'une perte limitée de paquets lorsqu'un tel événement se produit.

2.2.4 Conclusions sur l'attaque

Les outils nécessaires pour réaliser l'attaque sont peu complexes. Par ailleurs, les informations requises peuvent être obtenues assez simplement et un attaquant peut se permettre de réaliser une phase de reconnaissance. Même s'il semble raisonnable de penser qu'un attaquant déjà présent dans le réseau préfèrera utiliser d'autres vecteurs d'attaque plus classiques, il est judicieux de ne pas laisser la porte ouverte à ce type d'attaque, alors qu'il est possible de s'en prémunir sans efforts démesurés.

3. Sécurisation d'un réseau VXLAN

Nous nous intéresserons ici principalement au point de vue d'un gestionnaire de réseau, car d'un point de vue utilisateur (par exemple une VM dans un « cloud ») la seule recommandation valable est de chiffrer, authentifier et assurer l'intégrité de ses communications, les rendant ainsi inutilisables par un attaquant. Bien entendu, cela n'empêchera pas les dénis de services, ou les dysfonctionnements aléatoires difficilement analysables, et c'est là que l'action du gestionnaire de réseau prend toute sa valeur, car elle permettra également de se prémunir de ce type de nuisances, pouvant potentiellement mettre en danger vos activités.

Dans l'idéal, une première mesure pour le gestionnaire de réseau pour éviter le type d'attaque décrite dans cet article est de choisir une solution dans laquelle le mécanisme d'apprentissage automatique de l'emplacement des adresses MAC est désactivé sur le VTEP : on évitera ainsi d'apprendre une mauvaise association {adresse MAC → VTEP attaquant} simplement en recevant un paquet !

Toujours dans l'idéal, une deuxième mesure est d'éviter autant que possible les solutions reposant sur le multicast pour gérer l'absence de relation {adresse MAC → VTEP} : cela évitera de trop simplifier la tâche d'un attaquant qui aurait besoin d'informations sur le réseau qu'il est en train de compromettre.

Une solution possible reposant sur des standards permet d'éviter ces deux écueils tout en offrant certains avantages par rapport à la RFC 7348 : il s'agit de BGP eVPN. Nous verrons un peu plus loin quels sont ces avantages, et également quels peuvent en être les inconvénients, afin de permettre de peser le pour et le contre.

Mais dans un premier temps, regardons comment nous pouvons essayer de sécuriser un réseau VXLAN déjà déployé reposant sur la RFC 7348.

3.1 Recommandations dans le cadre de l'implémentation standard

Dans les équipements réseau, les administrateurs du réseau VXLAN peuvent :

• configurer des filtres pour empêcher des serveurs ne faisant pas partie du réseau VXLAN d'envoyer des paquets à destination du port utilisé par les VTEP (4789 ou 8472, selon qu'on utilise le port « historique » ou celui attribué par l'IANA) ;
• bloquer IGMP pour les serveurs n'ayant pas besoin de multicast, ou filtrer les abonnements aux groupes multicast selon les besoins ;
• configurer des filtres pour empêcher des serveurs n'ayant pas besoin d'utiliser multicast d'envoyer des paquets multicast.

Au niveau des VTEP, on peut également ajouter ces mesures :

• configurer des filtres pour n'accepter de paquets VXLAN que de VTEP connus (cette mesure peut devenir particulièrement lourde puisque pour chaque VTEP ajouté tous les autres VTEP doivent être mis à jour) ;
• selon les besoins, et si le réseau VXLAN ne comporte pas trop de VTEP, configurer IPsec pour les communications entre les VTEP.

Ces recommandations peuvent être complexes à mettre en place ainsi qu'à maintenir dans le temps tant au niveau des équipements réseau que des VTEP. Cela le sera encore plus et en particulier si la taille du réseau VXLAN est importante. L'automatisation ici doit être envisagée pour s'assurer de la cohérence et du fait que les recommandations sont systématiquement appliquées.

3.2 Mise en place d'un plan de contrôle sécurisant avec BGP eVPN

La RFC 8365 [2] datant de mars 2018 décrit spécifiquement comment utiliser BGP eVPN pour gérer un réseau virtualisé et s'applique à un réseau de type VXLAN.

Le principe de cette solution est simple : les hôtes hébergeant les VTEP utilisent BGP pour échanger les informations nécessaires au fonctionnement de VXLAN. Un VTEP n'apprend plus les associations {adresse MAC → VTEP} en observant des paquets : il est désormais impossible pour un attaquant d'empoisonner des VTEP simplement en envoyant des paquets VXLAN.

3.2.1 Les avantages de la solution reposant sur BGP eVPN

La solution BGP eVPN apporte une sécurité au réseau VXLAN, mais elle apporte également les avantages suivants :

• élimination du besoin de gérer le multicast pour VXLAN dans le réseau ;
• possibilité d'opérer un filtrage avancé des annonces d'adresses MAC ;
• interopérabilité avec diverses implémentations de BGP eVPN ;
• possibilité d'injecter des annonces (p. ex. ajout/suppression/modification d'adresses MAC/IP dans des VM) au niveau des « routes reflectors » si on souhaite gérer la solution depuis un contrôleur global (plus d'apprentissage au niveau des VTEP) ;

Tout est contrôlé par les « routes reflectors », éliminant ainsi les configurations et interactions avec les équipements réseaux et les serveurs, seuls les « routes reflectors » doivent être configurés/alimentés en informations.

3.2.2 Recommandations de configurations BGP pour BGP eVPN

BGP eVPN s'appuie sur iBGP, l'aspect routage interne de BGP. Afin de ne pas multiplier inutilement le nombre de sessions BGP et faciliter l'administration, on utilisera des « routes reflectors » BGP.

On veillera par ailleurs à :

• utiliser un mécanisme d'authentification et d'intégrité (cf. Guide des bonnes pratiques de configuration de BGP de l'ANSSI, section 2.1) ;
• configurer uniquement des sessions pair à pair, bannir la possibilité d'autoriser des subnets à se connecter aux « routes reflectors » ;
• définir un nombre maximum de NLRI (Network Layer Reachability Information) par session ;
• si possible, et en particulier si besoin, chiffrer les échanges BGP (via IPsec par exemple).

Pour une question de disponibilité et de résilience, on privilégiera le déploiement d'au moins deux « routes reflectors ».

3.2.3 Inconvénients de la solution BGP eVPN

La solution BGP eVPN pourra demander un effort par rapport au déploiement de la solution reposant sur la RFC, effort récompensé par une sécurisation renforcée de la solution et permettant de faire grandir aisément son réseau VXLAN.

On notera en particulier :

• que la connaissance de BGP est requise, et, même si aujourd'hui beaucoup d'administrateurs réseaux connaissent BGP, ce prérequis peut être un frein au déploiement de cette solution ;
• que des « routes reflectors » sont à déployer/configurer/administrer ; cet aspect est automatisable, et ne nécessite pas obligatoirement une solution matérielle ;
• que des clients BGP sont à déployer/configurer/administrer ; cet aspect est lui aussi automatisable, et ne nécessite pas non plus obligatoirement une solution matérielle.

3.3 Recommandations d'ordre général

Une bonne pratique, qui ne s'applique pas uniquement à VXLAN, mais constitue une règle d'ordre général, consiste à séparer physiquement et logiquement des environnements de sensibilités différentes.

En particulier :

• dans le cas de l'implémentation de la RFC 7348, on choisira avec soin des groupes multicasts distincts a minima pour chacun des niveaux de sensibilité ;
• on hébergera des VMs ou conteneurs de sensibilités différentes sur des hôtes physiques distincts.

Par ailleurs, on notera que quelle que soit la solution retenue, le trafic reste en clair : si un attaquant se situe sur un équipement réseau situé sur le chemin du trafic, il pourra toujours l'observer et l'altérer (même si cela n'est pas du tout trivial, cela reste une possibilité). Une bonne pratique est d'authentifier, chiffrer et assurer l'intégrité du trafic.

3.4 Considérations de sécurité complémentaires

La sécurisation vers le modèle BGP eVPN complexifie une usurpation, car il n'est plus possible de simplement envoyer des paquets forgés, l'attaquant doit être capable de communiquer en TCP avec le « route reflector » BGP, et donc de connaître la clé de session. De plus, il doit le faire depuis une adresse IP configurée dans le « route reflector ».

Cela étant dit, dans le cas d'une évasion de VM, l'attaquant se retrouve sur l'hôte et a potentiellement accès à cette clé, et même plus simplement au client BGP directement : l'attaquant a alors la possibilité d'injecter ce qu'il souhaite.

Par conséquent, on ne peut que recommander de ne pas implémenter le VTEP sur l'hôte gérant les VM/conteneurs, mais bien sur un élément externe (i.e. le plus souvent un ou des équipements réseau). Cette mesure est potentiellement pénalisante, car, justement, implémenter le VTEP sur l'hôte c'est aussi simplifier les configurations entre le réseau et les serveurs, et répondre à la problématique du nombre de VLAN disponibles. Mais dans un déploiement où le nombre de locataires distincts restera réduit et dans une optique de défense en profondeur, c'est l'approche à privilégier.

Conclusion

L'implémentation proposée par la RFC 7348 est séduisante du point de vue du gestionnaire de réseau, car les mécanismes mis en œuvre automatisent grandement la gestion des transferts d'informations entre VTEP, réduisant ainsi le travail à fournir par le gestionnaire. Cependant, cette simplification rend vulnérable la solution à une attaque du type « homme du milieu » assez simple à réaliser. Par ailleurs, la complexité de la sécurisation de cette implémentation augmente avec la taille du réseau VXLAN, ce qui peut rendre caduc le bénéfice de cette simplification. D'un autre côté, déployer un réseau VXLAN en se basant sur la RFC 8365 renforce la sécurité de la solution et apporte des avantages complémentaires, mais nécessite un surcoût initial et des compétences BGP.

En fin de compte, c'est la taille du réseau VXLAN opéré qui devrait être le facteur majeur orientant le choix de l'option de sécurisation :

• pour un réseau de petite taille n'évoluant pas, il sera plus simple et potentiellement suffisant de le sécuriser en suivant les recommandations fournies en section 3.1 ;
• pour un réseau de grande taille, ou un réseau destiné à grandir, il devient rapidement intéressant d'opter pour la solution reposant sur BGP eVPN, les bénéfices apportés pouvant justifier l'acquisition des compétences qui feraient éventuellement défaut.

Remerciements

Merci à François CONTAT, Arnaud EBALARD et Fabien VINCENT pour leurs relectures, corrections et conseils précieux.

Références

[1] « Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks », IETF, RFC 7348, août 2014

[2] « A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) », IETF, RFC 8365, mars 2018