Annonces RA malveillantes en IPv6 : attaques NDP et défense VPN de couche 3

L'adoption du protocole IPv6 a profondément transformé la manière dont les systèmes d'exploitation clients découvrent la topologie de leur réseau local. Alors qu'IPv4 s'appuyait sur des requêtes broadcast ARP et des serveurs DHCP centralisés, IPv6 a introduit le protocole de découverte des voisins (Neighbor Discovery Protocol — NDP). Défini par le standard RFC 4861, NDP opère sur ICMPv6 pour gérer la résolution d'adresses de liaison, la découverte de routeurs, l'identification de préfixes et l'autoconfiguration d'adresses sans état (SLAAC).

Bien que NDP ait considérablement simplifié la connexion des appareils, son architecture repose sur une hypothèse vulnérable : la confiance implicite au sein du domaine de diffusion de niveau 2. N'importe quel équipement connecté au même segment local peut émettre des messages ICMPv6 Router Advertisement (RA) non sollicités.

Lorsqu'un agresseur diffuse des trames RA falsifiées, les terminaux voisins adoptent automatiquement sa machine comme passerelle par défaut. En l'absence d'une politique stricte de routage au niveau du système, les flux IPv6 non encapsulés sont dirigés vers la passerelle malveillante, exposant les échanges sensibles aux interceptions et aux manipulations.

Autoconfiguration sans état et modèle de confiance d'IPv6 Neighbor Discovery

Dans les environnements IPv4, la distribution des adresses requiert un suivi d'état rigoureux. Un serveur DHCP gère les baux, valide les adresses MAC et attribue les paramètres. Le mécanisme SLAAC d'IPv6 a supprimé ce besoin en permettant aux hôtes de générer leurs propres adresses 128 bits de façon autonome.

Lorsqu'une interface réseau IPv6 se raccorde à un lien filaire ou Wi-Fi, elle produit une adresse de liaison locale (link-local) dans la plage fe80::/10. Afin d'identifier les chemins de sortie, l'hôte émet un message Router Solicitation (ICMPv6 type 133) vers l'adresse multicast ff02::2. Les routeurs légitimes répondent par un message Router Advertisement (ICMPv6 type 134) diffusé à l'adresse ff02::1.

Le standard RFC 4861 a été rédigé en supposant que la couche physique 2 assurait un cloisonnement suffisant. Le protocole ne comporte nativement aucune authentification cryptographique obligatoire ni signature numérique. Par conséquent, n'importe quelle machine connectée à un réseau Wi-Fi public ou à un VLAN d'entreprise peut s'auto-déclarer routeur par défaut. Le noyau du système traite les paquets de type 134 dès leur réception et met à jour sa table de routage sans avertissement utilisateur.

Anatomie des annonces ICMPv6 Router Advertisement : drapeaux, préfixes et délais

Un paquet ICMPv6 Router Advertisement standard comporte un champ Type de 8 bits fixé à 134, un champ Code (0), une somme de contrôle de 16 bits et une limite de sauts (Cur Hop Limit) de 8 bits. L'en-tête de base intègre des drapeaux fondamentaux qui pilotent le comportement des hôtes :

• Drapeau de configuration gérée (M) : Ordonne au client d'obtenir une adresse avec état via le protocole DHCPv6.
• Drapeau d'autre configuration (O) : Enjoint le client à interroger DHCPv6 pour récupérer des paramètres complémentaires comme les serveurs NTP.
• Préférence de routeur par défaut (bits Prf) : Standardisé par le RFC 4191 sur 2 bits pour définir la priorité : Faible (11), Moyenne (00) ou Haute (01).
• Durée de vie du routeur (Router Lifetime) : Champ de 16 bits indiquant la durée en secondes (de 0 à 9000) pendant laquelle le routeur sert de passerelle. Une valeur 0 retire le routeur de la table du client.

À la suite de cet en-tête fixe de 16 octets, le paquet RA transporte divers champs d'options :

En modifiant ces paramètres, un agresseur local est capable de redéfinir la topologie de routage et le système de résolution de noms de l'ensemble des postes voisins.

Vecteurs de menace : détournement de la table de routage par faux messages RA

Les annonces RA malveillantes résultent d'erreurs de configuration (hyperviseurs ou ponts réseau mal configurés) ou d'attaques préméditées. À l'aide d'outils comme scapy ou radvd, un attaquant diffuse des trames RA de priorité élevée pour exploiter deux scénarios principaux.

Réadressage SLAAC forcé et préemption de la passerelle par défaut

L'attaquant émet un paquet RA configuré comme suit :

1. Préférence de routeur configurée à Haute (Prf = 01).
2. Durée de vie du routeur fixée à 1800 secondes.
3. Option Prefix Information Option configurée en /64 avec les drapeaux Autonome (A) et Sur-lien (L) activés.

Le noyau de la machine cible installe sans délai l'adresse de liaison locale de l'attaquant (fe80::dead:beef:cafe) en tant que passerelle par défaut prioritaire. Simultanément, le poste s'attribue une nouvelle adresse IPv6 globale appartenant au préfixe adverse.

Les systèmes modernes appliquant l'algorithme Happy Eyeballs (RFC 8305) pour privilégier IPv6, les sessions sortantes HTTPS, SSH et API se déroutent vers la passerelle de l'agresseur. Ce dernier active le transfert de paquets (sysctl -w net.ipv6.conf.all.forwarding=1) pour observer les flux non chiffrés, enregistrer les en-têtes SNI et cartographier les adresses IP distantes.

Injection malveillante de serveurs RDNSS : interception du DNS avant chiffrement

L'option RDNSS formalisée par le RFC 8106 permet d'injecter des adresses de résolveurs DNS directement via les paquets RA. L'attaquant indique l'adresse IPv6 d'un résolveur qu'il contrôle.

Lors des résolutions de noms de domaine, le faux résolveur renvoie des correspondances falsifiées. Cette injection intervenant lors de l'initialisation de l'interface par le noyau, elle prévaut fréquemment sur les paramètres DNS IPv4 statiques.

Si la machine cliente ne dispose pas d'un tunnel de couche 3 strictement encapsulé, les requêtes DNS initiales circulent en clair sur le réseau local. Pour un examen des menaces similaires sur le segment local, consultez notre analyse sur la détection de l'usurpation ARP et l'empoisonnement de cache.

Empoisonnement du cache NDP : exploitation des paquets NA et de la durée de vie

Au-delà de la passerelle par défaut, l'attaque peut cibler les messages Neighbor Advertisement (NA). NDP utilise les requêtes Neighbor Solicitation (type 135) et Neighbor Advertisement (type 136) pour convertir les adresses IPv6 en adresses matérielles MAC Ethernet.

L'agresseur émet des paquets NA non sollicités vers la cible avec le drapeau de remplacement activé (O = 1). Le noyau récepteur actualise immédiatement son cache LLA, liant l'adresse IP de la passerelle légitime à l'adresse MAC physique de l'attaquant.

[Passerelle légitime]                 [Poste cible]              [Poste attaquant]
  2001:db8::1                          fe80::100                   2001:db8::666
       |                                    |                            |
       |                                    |<--- Paquet NA illégitime --|
       |                                    |    Associe 2001:db8::1 à   |
       |                                    |    la MAC de l'attaquant   |
       |                                    |                            |
       |<-- Flux IPv6 dévié vers l'attaquant|--------------------------->|
       |    (Paquets examinés et enregistrés par le proxy adverse)       |

De surcroît, l'émission répétée de paquets RA avec une durée de vie fixée à 0 ordonne au noyau d'effacer ses routes par défaut, provoquant des ruptures de communication soudaines et un déni de service (DoS).

Risques de fuite sous split-tunneling et applications en double pile

La propagation de faux paquets RA s'avère particulièrement préjudiciable lorsqu'un logiciel VPN gère imparfaitement le protocole IPv6.

Plusieurs clients VPN commerciaux configurent uniquement le routage IPv4 sur leur adaptateur virtuel (tun0 ou utun3), en scindant les sous-réseaux :

# Configuration classique de routage VPN limitée à IPv4
ip route add 0.0.0.0/1 dev tun0
ip route add 128.0.0.0/1 dev tun0

Dans ce cas, la table de routage IPv6 de l'adaptateur physique (wlan0 ou eth0) reste vulnérable. Dès qu'un paquet RA malveillant est reçu, le système installe une route IPv6 par défaut pointant vers l'attaquant.

Lorsqu'un navigateur interroge un service accessible en double pile, Happy Eyeballs sélectionne la voie IPv6. En l'absence de route IPv6 au sein du tunnel chiffré, les paquets empruntent directement l'interface physique. L'utilisateur pense sa session sécurisée, alors que ses données applicatives circulent hors du tunnel. Cette situation présente de fortes similitudes avec l'attaque d'injection de routes DHCP Option 121.

Défenses de couche 2 : limites de RA-Guard, du standard SEND et de la sécurité des ports

Les administrateurs d'infrastructures déploient diverses parades au niveau de la couche de liaison :

Mécanisme IPv6 RA-Guard (RFC 6105)

Les commutateurs d'entreprise équipés de RA-Guard séparent les ports en catégories approuvées ou non approuvées. Les circuits intégrés ASIC examinent les paquets ICMPv6 de type 134 et rejettent automatiquement toute annonce provenant des ports d'accès utilisateurs.

Découverte sécurisée des voisins (SEND, RFC 3971)

Le protocole SEND valide les messages NDP au moyen d'adresses générées cryptographiquement (CGA) et de signatures asymétriques. L'hôte prouve sa légitimité grâce à une clé publique liée à son identifiant d'interface.

Limites opérationnelles

Ces dispositifs peinent à protéger les utilisateurs mobiles :

• Absence sur les réseaux publics : Les points d'accès des hôtels, des gares et les routeurs grand public n'intègrent quasiment jamais RA-Guard.
• Complexité de déploiement de SEND : Les systèmes d'exploitation pour postes clients et smartphones n'ont pas généralisé SEND en raison des contraintes liées aux infrastructures d'autorité de certification PKI.
• Évitement des filtres de commutation : Un attaquant peut encapsuler ses paquets RA dans une double étiquette VLAN 802.1Q (Q-in-Q) ou fragmenter les paquets ICMPv6 pour traverser les contrôles rudimentaires des commutateurs.

La sécurité de la couche 2 étant hors du contrôle du terminal, la résilience doit être garantie directement au sein du système d'exploitation client.

Architecture VPN de couche 3 : encapsulation double pile et verrouillage des routes

Pour s'affranchir des annonces RA malveillantes, un VPN moderne de couche 3 doit contrôler l'ensemble de la table de routage du noyau. La protection repose sur l'encapsulation conjointe d'IPv4 et d'IPv6 alliée à une politique stricte de routage (RPDB).

+------------------------------------------------------------------------+
|                          Application utilisateur                       |
+------------------------------------------------------------------------+
                                    |
                                    v (Sockets double pile : AF_INET / AF_INET6)
+------------------------------------------------------------------------+
|                      Règles RPDB du noyau du système                   |
|   Règle 100 : trafic vers <IP-Serveur-VPN> consulte la table main      |
|   Règle 200 : tout autre flux consulte la table 51820 (VPN chiffré)    |
|   Règle 32766 : repli vers la table main (Interface physique locale)   |
+------------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------------+------------------------------------+
|   Table 51820 (WireGuard / RiceGuard)| Table Main (Interface wlan0)    |
|   défaut via :: interface rg0        | défaut via fe80::dead:beef dev  |
|   défaut via 0.0.0.0 interface rg0   | (Route malveillante isolée ici) |
+-----------------------------------+------------------------------------+

Le client VPN isole le routage dans une table distincte (par exemple la table 51820) contenant les préfixes globaux :

• 0.0.0.0/0 via l'interface virtuelle rg0
• ::/0 via l'interface virtuelle rg0

Il applique ensuite des règles de routage prioritaires dans le noyau :

# Verrouillage de l'ensemble du trafic IPv6 dans la table chiffrée
ip -6 rule add pref 200 lookup 51820
ip -6 rule add pref 201 unreachable

Même si un attaquant émet des trames RA de priorité maximale sur l'interface wlan0, le noyau traite la table 51820 à la priorité 200 avant d'atteindre la table main. La route adverse demeure stérile.

Application de la table de routage RiceGuard : neutralisation d'ICMPv6 au niveau socket

VPNRice met en œuvre le protocole de transport RiceGuard, dérivé de WireGuard, pour protéger les communications contre les attaques de niveau 2 :

1. Attribution double pile systématique : RiceGuard alloue une adresse interne IPv4 (10.64.0.0/10) et une adresse locale unique IPv6 (fd00::/8) à chaque session, empêchant Happy Eyeballs de sélectionner l'interface physique non chiffrée.
2. Filtrage de paquets dans le noyau : Sur les systèmes compatibles avec nftables ou pf, RiceGuard configure des règles de pare-feu temporaires supprimant les paquets ICMPv6 de type 134 reçus sur l'interface physique :

table inet vpnrice_defense {
    chain prerouting {
        type filter hook prerouting priority -100; policy accept;
        iifname != "rg0" icmpv6 type { nd-router-advert, nd-redirect } counter drop
    }
}

3. Verrouillage du résolveur DNS : RiceGuard achemine les requêtes DNS vers un résolveur interne écoutant sur 127.0.0.1:53 et [::1]:53. Les paramètres RDNSS transmis sur le réseau local Wi-Fi sont ainsi ignorés.

Chacun peut auditer son adresse publique et contrôler l'étanchéité de son routage grâce à notre outil de vérification d'adresse IP.

Évaluation de la résilience réseau : priorités métriques, temps de bascule et pertes

Nous avons mené des tests au sein d'un laboratoire Wi-Fi isolé soumis à l'injection active de faux paquets RA. Un poste pirate transmettait des trames ICMPv6 de type 134 toutes les 2 secondes avec l'utilitaire scapy, en configurant une priorité High et des paramètres DNS corrompus.

Trois scénarios ont été mesurés : connexion directe sans protection, VPN classique limité à IPv4 et tunnel double pile RiceGuard.

Avec un VPN limité à IPv4, la pile réseau du système oscillait entre deux passerelles concurrentes, provoquant des pertes de paquets et des coupures applicatives.

Sous RiceGuard, la règle RPDB a maintenu la priorité de la table 51820. Les messages ICMPv6 illégitimes ont été écartés par le pare-feu, préservant la stabilité du débit et l'intégrité du chiffrement.

Guide pratique : renforcement des postes de travail et audit des voisins IPv6

Dans les environnements non sécurisés, les utilisateurs et administrateurs peuvent appliquer des mesures de durcissement locales.

Contrôler les passerelles actives et le voisinage IPv6

Sous Linux, analysez les routes et les entrées de voisins pour repérer d'éventuels routeurs suspects :

# Afficher les routes IPv6 par défaut et leurs métriques
ip -6 route show default

# Examiner les adresses matérielles des voisins enregistrés
ip -6 neighbor show

# Observer les trames d'annonces ICMPv6 en temps réel
sudo tcpdump -ni any "icmp6 and (ip6[40] == 134 or ip6[40] == 135)" -v

Désactiver l'acceptation automatique des annonces RA

Sur les postes Linux dépourvus de filtrage dynamique, il est possible de bloquer la réception des annonces sur l'interface physique :

# Désactiver le traitement des Router Advertisements sur wlan0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_defrtr=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_pinfo=0
sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_rtr_pref=0

La valeur accept_ra=0 force le noyau à ignorer les paquets de type 134 arrivant sur wlan0. Lors de l'établissement d'une connexion via l'application VPNRice officielle, ces mécanismes de protection s'activent automatiquement en complément de l'encapsulation WireGuard.

L'association de politiques de routage strictes et d'un filtrage au plus près du noyau offre aux postes clients une protection efficace contre les menaces locales.