Introduction au protocole VRRP et à son fonctionnement
1. Présentation du protocole VRRP
Virtual Router Redundancy Protocol (protocole de redondance de routeur virtuel, VRRP) est un protocole dont le but est d'augmenter la disponibilité de la passerelle par défaut des hôtes d'un réseau. Le principe est de définir la passerelle par défaut pour les hôtes du réseau comme étant une adresse IP virtuelle référençant un groupe de routeurs.
Le VRRP est largement utilisé dans les architectures réseau où il est essentiel de maintenir une connectivité constante même en cas de défaillance de l’un des routeurs. Lorsqu'un routeur devient indisponible, VRRP permet à un autre routeur de prendre immédiatement le relais, sans perturber les communications.
Le VRRP est un standard IETF [Internet Engineering Task Force, organisme de normalisation des protocoles internet], pris en charge par de nombreux constructeurs de routeurs, firewalls, ainsi que par des systèmes d'exploitation comme Linux. Le protocole VRRP, en tant que protocole ouvert, est plus déployé que d'autres protocoles similaires ou propriétaires (comme le HSRP, propriétaire CISCO).
[image 1]
2. Fonctionnement du protocole VRRP
Le VRRP fonctionne grâce à un ensemble de routeurs, et utilise la notion de routeur virtuel, auquel est associée une adresse IP virtuelle (VIP) ainsi qu'une adresse MAC virtuelle (IP-Tie Breaking). Les rôles de routeur master et routeur backup sont utilisés et associés aux routeurs d'un groupe VRRP.
Le routeur master est associé à l'adresse IP virtuelle du groupe. C'est lui qui va répondre aux requêtes ARP des clients sur cette adresse IP (et router les requêtes réseau).
Un ou plusieurs routeurs backup pourront reprendre le rôle de master en cas de défaillance de celui-ci.
Il est à noter que le protocole VRRP, fonctionne au niveau 3 du modèle OSI, et que par conséquent ce dernier n’utilise pas les protocoles réseau TCP ou UDP. Par défaut, le VRRP utilise l’unicast pour la communication entre les routeurs, mais il peut également utiliser le multicast.
a. Fonctionnement en situation nominale
En situation nominale, le routeur master est le routeur qui détiens la priorité la plus élevée (valeur entre 0 et 255). Si les priorités sont égales, c'est l'adresse IP la plus basse du routeur qui sera choisie.
Les routeurs backup, eux, écoutent les messages « HELLO » envoyé (normalement toutes les 1 secondes) par le routeur maitre, et attendent une potentielle panne de ce dernier.
Les messages HELLO contiens les informations suivantes : adresse IP VIP, priorité du routeur maître, l’ID unique du groupe VRRP ainsi que la version du protocole VRRP utilisé.
b. Panne du routeur maître
Lorsqu’un ou plusieurs routeur backup, ne reçoivent plus de paquet HELLO, durant la période configuré (par exemple 3 secondes), ces derniers considèrent que le routeur maître est hors ligne et donc inopérant.
Une nouvelle élection de routeur maître est lancé par le VRRP, en utilisant la même méthode que décris plus haut (utilisation du routeur avec la priorité la plus élevée), ce dernier récupérera donc l’adresse IP virtuelle (VIP), afin de prendre en charge le routage du trafic.
Lorsque le routeur initialement maitre est de nouveau en ligne, ce dernier peux (selon si la configuration du groupe VRRP le permet ou non) reprendre son rôle si sa priorité est supérieure au routeur qui est actuellement maitre.
3. Principales différences entre la version 2 et 3 du protocole
| Critère | VRRPv2 | VRRPv3 |
| Spécification | RFC 3768 | RFC 5798 |
| Support d’adresse IP | IPv4 uniquement | IPv4 et IPv6 |
| Encapsulation | Directement dans IP (protocole 112) | Idem, mais format des paquets modifié |
| Authentification | > Pas d'authentification > "Plain Text Password" (mot de passe en clair) > IP AH (HMAC-MD5-96) | Supprimée (aucune authentification intégrée) |
| Sécurité | Faible, facilement contournable | Dépend de la sécurité du réseau sous-jacent |
| Taille du champ priorité | 8 bits | 8 bits (identique) |
| Support de groupes multiples | Limité (1 groupe par interface) | Oui (plusieurs groupes sur la même interface) |
[Image2]
Trame VRRP V2
[Image3]
Trame VRRP V3 1
On peut noter que la principale différence, entre les 2 versions du protocole au-delà de la prise en charge de l’IP V6, que la version 3 du VRRP retire complétement tout mécanisme d’authentification, supposant que des mécanismes externes (comme IPSec, segmentation VLAN, ACLs) assurent la sécurité.
Keepalived ... et la découverte d’une faille dans la RFC
L’outil utilisé est Keepalived, cet outil est un logiciel de routage sous Linux, qui permet d’implémenter le VRRP sur ce dernier.
1. Cas pratique avec Keepalived
Lors de ces nombreuses études et audit, Geoffrey s’est rendu compte, que la majorité des environnements VRRP ne sont pas ou peu sécurisés.
Afin de monter une maquette respectant les recommandations (utilisation d’un ID 255 et de l’IP la plus haute possible sur le réseau sur le routeur nominal, utilisation du mode unicast), il a utilisé plusieurs machines linux avec Keepalived.
Le réseau n’étant pas ou pas suffisamment cloisonné (postes utilisateurs dans le même vlan que
Une fois la maquette montée, il a ajouté un routeur « pirate » avec l’ID 255 et avec le routeur pirate (rogue router), il a diffusé des trames VRRP, il a réussi à prendre le contrôle du réseau (il est devenu routeur maître).
Plusieurs configurations ont étés testées, et dans tous les cas (même avec un routeur pirate avec une priorité inférieure au master), il est devenu au maitre du réseau.
La question est donc la suivante : Cela est-il une vulnérabilité (CVE) de Keepalived ?
2. Découverte d’une vulnérabilité critique et correction par un erratum
Le bug n’est pas une CVE étant donné que, Keepalived suit à la lettre le RFC 9568 (définissant le protocole VRRP).
Keepalived à quand même publié un patch afin de corriger le bug, mais ils affirment qu’ils suivent la RFC.
Une fois le doute levé avec l’IETF, la RFC est bien à l’origine du dysfonctionnement
De plus, le bug n’est pas rencontré sur des équipements Cisco, car ces derniers n’ont pas encore implémenté la dernière version de la RFC.
En réalité, les paquets VRRP ayant une priorité de 255 n’étaient pas réellement discard (« ignores avant traitement »), ce qui empêchait le fonctionnement des mécanismes de IP-Tie Breaking et qui avaient comme conséquence, que le routeur avec la priorité 255 écoutait les paquets, et baissait sa priorité.
L’Erratum 8298 à été validé par l’IETF quelques jours après sa publication par les équipes de Keepalived.
Conclusion & recommandations
La conférence a mis en lumière une vulnérabilité sérieuse dans le protocole VRRP, démontrée via Keepalived, avec un impact concret : un attaquant local peut facilement usurper la passerelle par défaut. Bien que la bonne pratique réseau (segmentation, filtrage, supervision) réduise ce risque, cela souligne une faiblesse conceptuelle de VRRP qui mérite d’être prise en compte par les ingénieurs réseaux.
On peut donner les recommandations suivantes :
Premièrement, en cas d’utilisation de VRRP V2, utiliser une authentification IPSEC (si possible).
De manière commune au VRRP V2 et V3, il est important, de configurer le protocole en mode unicast, afin d’éviter les écoutes réseaux, et de pouvoir reconstruire une configuration VRRP pirate.
Il faut aussi respecter un adressage et un ordre des priorités VRRP rigoureux pour tous les routeurs.
Il est également important de bien segmenter son réseau, afin d’éviter des attaques de types man in the middle.
