Sécurité IPv6 : menaces, atténuations et bonnes pratiques

Une préoccupation revient constamment quand les organisations envisagent IPv6 : « Sans NAT, ne sommes-nous pas exposés ? »

Non. Le NAT n'a jamais été une fonctionnalité de sécurité. C'était une solution de contournement pour la rareté des adresses qui cachait accessoirement les adresses internes. Un pare-feu avec état fournit la même protection — bloquer les connexions entrantes non sollicitées — sans les inconvénients de la traduction d'adresses.

Le vrai problème est différent : beaucoup de réseaux ont IPv6 activé mais ont oublié de configurer les règles de pare-feu IPv6. C'est un problème sérieux, et c'est entièrement évitable.

Le mythe du NAT#

Une préoccupation revient constamment quand les organisations envisagent IPv6 : « Sans NAT, ne sommes-nous pas exposés ? »

Non. Le NAT n'a jamais été une fonctionnalité de sécurité. C'était une solution de contournement pour la rareté des adresses qui cachait accessoirement les adresses internes. Un pare-feu avec état fournit la même protection — bloquer les connexions entrantes non sollicitées — sans les inconvénients de la traduction d'adresses.

Le vrai problème est différent : beaucoup de réseaux ont IPv6 activé mais ont oublié de configurer les règles de pare-feu IPv6. C'est un problème sérieux, et c'est entièrement évitable.

Ce qui est réellement différent sur la sécurité IPv6#

IPv6 change le paysage des menaces de façons spécifiques :

L'espace d'adressage plus large coupe dans les deux sens. Scanner un sous-réseau /64 prend des siècles par force brute. Mais les attaquants ne font pas de force brute — ils utilisent les enregistrements DNS, les journaux de transparence des certificats et l'analyse de trafic pour trouver des cibles. Ne comptez pas sur l'obscurité des adresses.

Chaque appareil est potentiellement accessible. Avec des adresses globales sur chaque hôte, votre pare-feu est la seule barrière. Cela rend la configuration du pare-feu plus critique, pas optionnelle.

ICMPv6 est essentiel, pas optionnel. Contrairement à IPv4 où vous pouviez bloquer tout ICMP sans rien casser, IPv6 nécessite ICMPv6 pour les opérations de base. Bloquez les mauvais messages et votre réseau arrête de fonctionner.

Nouveaux protocoles, nouvelle surface d'attaque. Le protocole de découverte de voisins (NDP) remplace ARP et introduit de nouveaux vecteurs. Les en-têtes d'extension ajoutent de la complexité que les attaquants peuvent exploiter.

Vecteurs d'attaque spécifiques à IPv6#

Usurpation NDP#

Le protocole de découverte de voisins gère la résolution d'adresse, la découverte de routeur et la détection d'adresse dupliquée. Comme ARP en IPv4, il est confiant par défaut.

Un attaquant sur le réseau local peut :

• Usurper les annonces de voisin pour rediriger le trafic (homme du milieu)
• Envoyer de fausses annonces de routeur pour devenir la passerelle par défaut
• Effectuer des attaques de détection d'adresse dupliquée pour refuser des adresses aux hôtes légitimes

Ces attaques nécessitent un accès au réseau local — ce ne sont pas des menaces à l'échelle d'Internet. Mais sur les réseaux partagés (bureaux, datacenters, WiFi), ce sont des risques réels.

Atténuation : Déployez RA Guard et ND Inspection sur les commutateurs. Sur les hôtes, considérez SEND (Secure Neighbor Discovery), bien que l'adoption soit limitée.

Attaques d'annonce de routeur#

Un RA malveillant peut convaincre les hôtes de :

• Utiliser l'attaquant comme passerelle par défaut
• Accepter un serveur DNS malveillant
• Utiliser un préfixe spécifique (potentiellement pour l'interception de trafic)

C'est particulièrement dangereux car la plupart des hôtes acceptent les RA par défaut.

Atténuation :

• RA Guard sur les ports de commutateur (bloquer les RA des ports non-routeurs)
• Sur les hôtes Linux : net.ipv6.conf.all.accept_ra = 0 pour les serveurs avec config statique
• Surveiller les RA inattendus avec des outils comme ramond ou NDPMon

Exploitation des en-têtes d'extension#

Les en-têtes d'extension IPv6 se situent entre l'en-tête principal et la charge utile. Les utilisations légitimes incluent la fragmentation, les options de routage et IPsec.

Les attaquants peuvent les utiliser pour :

• Éviter les pare-feu qui n'inspectent pas toute la chaîne d'en-têtes
• Attaques de fragmentation pour contourner l'inspection ou les vulnérabilités de réassemblage
• Créer des paquets ambigus que différents appareils interprètent différemment

Atténuation : Utilisez des pare-feu qui analysent complètement les chaînes d'en-têtes d'extension. Abandonnez les paquets avec des en-têtes d'extension inhabituels ou dépréciés (comme les en-têtes de routage Type 0, obsolètes par RFC 5095).

Techniques de reconnaissance#

Les attaquants ne scannent pas les /64 aléatoirement. Ils trouvent les cibles IPv6 via :

• Transferts de zone DNS ou devinette (www, mail, ns1, etc.)
• Journaux de transparence des certificats (tous les certificats HTTPS sont publics)
• Récupération du trafic (surveillance passive)
• Adressage prévisible (::1, ::100, basé sur EUI-64 depuis MAC)

Atténuation : Utilisez les extensions de confidentialité pour les adresses client. Évitez les adresses serveur prévisibles. Ne publiez pas l'infrastructure interne dans le DNS public si pas nécessaire.

Configuration de pare-feu pour IPv6#

Types ICMPv6 essentiels à autoriser#

Bloquez-les et votre réseau casse :

Les types 133-136 ne sont nécessaires que sur le lien local — ne les transférez pas à travers les routeurs.

Règles de pare-feu avec état#

Un ensemble de règles minimal pour un hôte :

# Autoriser connexions établies
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Autoriser ICMPv6 (être plus spécifique en production)
-A INPUT -p ipv6-icmp -j ACCEPT
 
# Autoriser link-local uniquement pour NDP (plus sécurisé)
-A INPUT -s fe80::/10 -p ipv6-icmp --icmpv6-type 133:136 -j ACCEPT
 
# Autoriser services spécifiques
-A INPUT -p tcp --dport 22 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
 
# Abandonner tout le reste
-A INPUT -j DROP

Pour nftables, l'équivalent :

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
 
    ct state established,related accept
    ip6 nexthdr icmpv6 accept
    tcp dport { 22, 443 } accept
  }
}

N'oubliez pas le filtrage de sortie#

Les règles sortantes comptent aussi. Elles peuvent :

• Empêcher l'exfiltration de données sur des protocoles inattendus
• Bloquer le trafic de commande et contrôle
• Limiter les dommages des hôtes compromis

Au minimum, journalisez les connexions sortantes inattendues.

IPsec en IPv6#

IPsec était à l'origine obligatoire pour les implémentations IPv6 (RFC 2460). Cela a été assoupli plus tard (RFC 6434) car le déploiement universel ne s'est jamais produit.

Pourtant, IPv6 rend IPsec plus clair :

• Pas de complications de traversée NAT
• En-têtes d'extension conçus avec IPsec à l'esprit
• ESP et AH fonctionnent comme prévu

Si vous avez besoin de chiffrement entre des hôtes ou sites spécifiques, IPsec sur IPv6 est simple — plus que sur IPv4 avec NAT.

Fonctionnalités de sécurité first hop#

Les commutateurs modernes offrent des protections contre les attaques locales :

RA Guard : Bloque les annonces de routeur des ports non autorisés. Essentiel sur tous les commutateurs d'accès.

DHCPv6 Guard : Limite les réponses de serveur DHCPv6 aux ports autorisés.

ND Inspection : Construit une table de liaison des mappages MAC vers IPv6 et valide le trafic NDP.

Source Guard : Abandonne les paquets avec des adresses source usurpées basées sur la table de liaison.

Ces fonctionnalités sont disponibles sur les commutateurs d'entreprise de Cisco, Juniper, Arista et autres. Configurez-les — elles sont désactivées par défaut.

Erreurs courantes#

Activer IPv6 sans configurer le pare-feu. Si vos règles de pare-feu ne couvrent qu'IPv4, vous êtes grand ouvert sur IPv6. C'est la vulnérabilité réelle n°1.

Bloquer tout ICMPv6. Cela casse la découverte MTU de chemin et cause des échecs de connectivité mystérieux, surtout pour les gros paquets et à travers les tunnels.

Ignorer IPv6 sur les réseaux « IPv4-only ». La plupart des systèmes d'exploitation activent IPv6 par défaut. Sans infrastructure appropriée, ils peuvent utiliser link-local ou tunneliser vers des points de terminaison aléatoires.

Supposer que NAT64 fournit la sécurité. Les technologies de traduction n'ajoutent pas de sécurité. Elles traduisent juste. Vous avez toujours besoin de règles de pare-feu.

Utiliser les mêmes règles de pare-feu pour IPv4 et IPv6. Certaines règles se traduisent directement ; d'autres (comme la gestion ICMP) nécessitent une attention spécifique.

Liste de vérification de sécurité#

Avant de mettre en ligne avec IPv6 :

• Les règles de pare-feu couvrent explicitement le trafic IPv6
• Les types ICMPv6 essentiels sont autorisés
• RA Guard activé sur les commutateurs d'accès
• DHCPv6 Guard configuré si utilisation DHCPv6
• Signatures IDS/IPS mises à jour pour IPv6
• La journalisation capture les adresses source IPv6
• Enregistrements DNS examinés (ne pas publier d'enregistrements AAAA inutiles)
• Extensions de confidentialité activées sur les clients
• Surveillance en place pour les RA malveillants

Résumé#

La sécurité IPv6 n'est pas plus difficile qu'IPv4 — elle est différente. Les fondamentaux restent : pare-feu avec état, contrôle d'accès approprié, surveillance et maintien des systèmes corrigés.

Le plus grand risque n'est pas la complexité technique. C'est la période de transition où IPv6 existe mais n'est pas géré correctement. Traitez IPv6 comme un citoyen de première classe dans votre architecture de sécurité, pas une réflexion après coup.

Articles connexes#

• Configuration du pare-feu IPv6 - Guide détaillé pour configurer les pare-feu pour IPv6
• Extensions de confidentialité IPv6 - Protégez la vie privée des utilisateurs avec des adresses temporaires