L’IPv6 n’est pas moins sûr sous prétexte qu’il n’utilise pas de NAT

 (johnmaguire.me)
4 points par GN⁺ 2026-01-22 | 1 commentaires | Partager sur WhatsApp
  • L’affirmation selon laquelle l’IPv4 serait plus sûr parce qu’il utilise le NAT par défaut provient d’une confusion entre sécurité et traduction d’adresses
  • NAT (Network Address Translation) n’est pas une fonction de sécurité, mais un mécanisme d’économie d’adresses destiné à pallier la pénurie d’adresses IPv4
  • Le fonctionnement du NAT consiste simplement à permettre à plusieurs appareils de partager une même IP publique sur la base du mappage de ports
  • En réalité, le blocage du trafic externe n’est pas assuré par le NAT, mais par un pare-feu à états (stateful firewall)
  • Même dans un environnement IPv6, un pare-feu bloque par défaut le trafic non autorisé ; l’absence de NAT ne signifie donc pas un affaiblissement de la sécurité

Confusion entre NAT et sécurité

  • L’idée selon laquelle l’IPv4 serait plus sûr parce qu’il utilise le NAT est une idée fausse
    • Le NAT n’est pas une fonction de sécurité, mais une technique d’économie d’adresses (address conservation)
    • On peut aussi utiliser le NAT avec l’IPv6, mais cela ne renforce pas la sécurité
  • Le NAT permet à plusieurs appareils d’un réseau interne de partager une seule adresse IP publique
    • Il effectue le routage en réécrivant (rewrite) l’IP de destination selon le port de destination du paquet
    • Il fonctionne suivant des règles de mappage de ports (port mapping) ou de redirection de ports (port forwarding) configurées par l’administrateur réseau

Fonctionnement réel du NAT

  • Dans un environnement NAT, le trafic entrant depuis l’extérieur n’est pas transmis à un appareil interne lorsqu’il possède un port de destination inattendu
    • Ce trafic reste sur l’équipement qui possède l’IP publique et n’est pas routé vers le réseau interne
  • Cela peut donner l’impression que le NAT bloque l’accès externe, mais ce n’est qu’un effet secondaire et non un objectif de conception en matière de sécurité

Le rôle du pare-feu

  • L’effet de sécurité souvent attribué au NAT provient en réalité du pare-feu à états (stateful firewall)
    • La plupart des routeurs modernes intègrent par défaut une politique de pare-feu qui bloque le trafic entrant, qu’ils utilisent ou non le NAT
    • Le pare-feu rejette (drop) le trafic vers des destinations inattendues avant même de réécrire ou de router les paquets
  • Par exemple, les règles par défaut du pare-feu IPv6 d’un routeur UniFi sont les suivantes
    • Autoriser le trafic Established/Related (trafic de réponse sortant)
    • Bloquer le trafic Invalid
    • Bloquer tout le reste du trafic

Sécurité dans un environnement IPv6

  • Même sur un réseau IPv6, les règles de pare-feu par défaut bloquent le trafic entrant non autorisé
    • Le même niveau de protection s’applique même sans NAT
  • Pour autoriser depuis l’extérieur un trafic non sollicité vers un appareil IPv6, il faut ajouter explicitement des règles de pare-feu
    • Cela s’applique de la même manière, qu’il y ait ou non usage du NAT

Conclusion

  • L’affirmation selon laquelle l’IPv6 serait moins sûr parce qu’il n’utilise pas de NAT est infondée
  • La sécurité réelle est déterminée non par le NAT, mais par les politiques de pare-feu et les règles de contrôle du trafic
  • Même dans un environnement IPv6, il est possible de maintenir une stratégie de sécurité default-deny grâce à une configuration appropriée du pare-feu

À lire aussi

1 commentaires

 
GN⁺ 2026-01-22
Réactions sur Hacker News

  • Il est recommandé de lire la section 5 de la RFC 4787 avant de participer à la discussion
    Le NAT n’est pas un pare-feu, mais il filtre tout de même le trafic, ce qui lui confère un certain niveau de fonction de sécurité
    En pratique, le NAT a évolué au-delà de la simple traduction d’adresses, et même si l’IPv6 n’utilise pas de NAT, un pare-feu peut implémenter le même filtrage

    • La RFC 4787 ne reflète pas exactement les implémentations réelles. Comme la plupart des routeurs SOHO sont basés sur Linux, il est plus réaliste de parler du NAT basé sur netfilter
      Le netfilter de Linux implémente à la fois le NAT et le pare-feu ; les règles DNAT/SNAT de la table nat relèvent du NAT, et les règles REJECT/DROP de la table filter font office de pare-feu
      Si seules des règles NAT sont appliquées, le trafic qui ne fait pas partie d’une connexion existante passe quand même
    • La section en question de la RFC 4787 décrit les connexions sortantes
      Elle explique comment le NAT crée une table d’état lorsqu’une connexion vers l’extérieur est établie et autorise les paquets entrants correspondants
      Autrement dit, le « filtering » de ce document ne désigne pas les connexions entrantes non sollicitées
    • L’IPv6 n’est pas moins sûr sans NAT, mais les paramètres par défaut sont essentiels
      L’IPv6 peut être aussi sûr que l’IPv4, mais cela dépend de la configuration
    • En 30 ans de carrière dans l’IT, les environnements NAT ont encouragé une conception paresseuse
      Le fait que des ingénieurs systèmes et applicatifs s’appuient sur le NAT et les pare-feu périmétriques sans comprendre le problème dans son ensemble constitue une mauvaise habitude de sécurité
    • Une RFC n’est pas toujours une référence absolue
      Plus elle s’éloigne des implémentations réelles, plus la fiabilité de la RFC diminue

  • Les réseaux mobiles américains utilisent des adresses IPv6 sans NAT
    Par exemple, T-Mobile utilise 464XLAT pour faire transiter l’IPv4 sur l’IPv6
    Cela montre qu’un pare-feu à états peut fonctionner à grande échelle sans NAT

    • Sur le réseau finlandais Elisa, les connexions TCP entrantes en IPv6 fonctionnent bien
      Le test a été fait avec Termux et netcat ; l’IPv4 était derrière un CGNAT, mais l’IPv6 était joignable directement
    • Certains se demandent « pourquoi les smartphones ne peuvent pas fonctionner comme serveurs »
    • L’idée qu’un appareil personnel puisse servir directement des données est vue comme un droit naturel
      Si la capacité réseau manque, il faut résoudre ce problème
      Quand l’IPv6 sera généralisé, la communication directe deviendra naturelle pour tout le monde
    • Question sur le fait de savoir si, lors de l’utilisation d’un hotspot, le PC client reçoit la même adresse IPv6
    • Les appareils mobiles sont limités par un environnement sandboxé

  • En tant qu’ingénieur réseau, l’un des premiers sujets appris concernait la relation entre NAT et sécurité
    Les adresses privées IPv4 (192.168.0.1) sont difficiles à atteindre depuis l’extérieur, alors que les adresses globales de l’IPv6 peuvent exposer des informations sur les appareils
    L’IPv6 dispose d’alternatives comme la Prefix Translation, qui permet de conserver une partie des avantages du NAT tout en gardant un accès transparent

    • Comparer les adresses privées IPv4 aux adresses globales IPv6 n’est pas équitable
      Il faut comparer soit des adresses internes, soit des adresses externes dans les deux cas
      Dans un environnement CGNAT, les connexions entrantes sont impossibles, donc on peut imposer la même restriction en IPv6
    • Même si une adresse interne fuit, le véritable point d’attaque reste le pare-feu en frontière Internet
      On peut masquer le préfixe avec du NAT66, mais le gain réel en sécurité est limité
    • 192.168.0.1 était bien trop facile d’accès (sur le ton de la plaisanterie)
    • NAT66 est un « mal nécessaire », mais dans certaines situations, cela peut être la meilleure option

  • Beaucoup de hackers confondent NAT et pare-feu
    Le NAT n’est pas un mécanisme de sécurité, et c’est le pare-feu qui fournit la sécurité

    • Ils comprennent la différence entre NAT et pare-feu, mais dans la pratique les deux fonctionnent ensemble
      Le NAT relève du namespacing, tandis que le pare-feu relève d’une sécurité fondée sur des politiques
      Le namespacing lui-même a une forte propriété de sécurité, car il empêche l’attaquant de « connaître ne serait-ce que le nom » des ressources
      Un pare-feu IPv6 peut exposer le monde entier à cause d’une seule règle erronée
    • Le NAT bloque les accès externes, donc il a un effet de sécurité concret
      Même sans pare-feu, le NAT seul peut protéger les ressources internes
      Le NAT réduit la surface d’attaque des réseaux domestiques à un seul routeur
    • Le NAT fournit par défaut le comportement que la plupart des utilisateurs attendent
      À l’inverse, un pare-feu peut avoir des paramètres par défaut différents, ce qui donne l’impression que l’IPv6 constitue un recul en matière de sécurité pour l’utilisateur lambda
    • Le NAT grand public se comporte en pratique comme un pare-feu à blocage par défaut
      Dire que l’UPnP casse la sécurité du NAT revient à dire que PCP casse la sécurité d’un pare-feu
    • Le NAT symétrique ou le CGNAT ne sont pas des pare-feu, mais en pratique ils produisent un effet similaire

  • À propos de l’argument selon lequel la propriété de blocage par défaut du NAT est un avantage de sécurité de l’IPv4
    Comme les règles de blocage par défaut en IPv6 offrent le même niveau de sécurité, il n’y a pas de différence structurelle de sécurité

    • La notion de « sécurité intrinsèque » n’a pas de sens
      Le NAT en IPv4 et les règles de blocage par défaut en IPv6 maintiennent les mêmes invariants
      Dans les deux cas, une mauvaise configuration peut les rendre vulnérables de la même manière

  • Quelqu’un raconte avoir laissé baisser sa garde à cause du NAT, puis s’être fait pirater un SBC à cause d’une absence de configuration du pare-feu IPv6
    La cause n’était pas le NAT, mais une erreur de configuration IPv6

    • L’espace d’adressage IPv6 est si vaste qu’un scan complet est impossible ; quelqu’un se demande donc comment l’attaquant a trouvé l’adresse
    • C’était une erreur assez embarrassante

  • Le NAT crée aussi des problèmes de sécurité
    Il facilite les attaques par réflexion et complique le suivi à cause de la séparation entre adresse et endpoint
    AOL a autrefois partagé un petit nombre d’adresses de sortie entre de nombreux utilisateurs, ce qui compliquait le blocage de certains d’entre eux

    • Selon la RFC 1631, le NAT « réduit les options permettant d’assurer la sécurité »
      Mais avec le temps, le NAT a fini par être perçu comme une sorte de croyance cargo-cult en matière de sécurité

  • L’effet du NAT varie selon le FAI et la configuration du routeur
    Le NAT n’est pas une fonction de sécurité intentionnelle, mais il produit un effet de sécurité secondaire
    En IPv6, si chaque appareil reçoit directement une adresse, un pare-feu à blocage par défaut est nécessaire

    • La plupart des routeurs appliquent aussi le blocage par défaut en IPv6, mais des fonctions d’ouverture automatique de ports comme UPnP peuvent le neutraliser
      Lien vers la spécification UPnP
    • En IPv6 également, le blocage entrant fonctionne comme en IPv4
    • Si l’accès reste impossible même après avoir désactivé le NAT, la cause peut être la configuration du routage plutôt que le NAT lui-même
    • Les cas d’usage du NAT en IPv6 sont rares, et faire du NAT sur des adresses fc00::/7 est un cas particulier
    • Qu’un FAI ne fournisse qu’une seule adresse IPv6 est une configuration anormale. Il devrait au minimum fournir un /56

  • En réponse à l’idée que ceux qui prétendent que le NAT est la base de la sécurité ne comprennent pas bien les réseaux

    • Quelqu’un parle d’« une généralisation excessive » : le NAT ne peut pas être la sécurité en soi, mais il ne faut pas non plus l’ignorer totalement
    • Il se présente comme expert IPv6 et dit exploiter l’IPv6 depuis 2008
      Il partage un cas où un problème d’accumulation d’adresses de confidentialité avait fait échouer un serveur SIP
      La discussion associée reste d’actualité dans ce thread Reddit sur la VOIP

  • À propos de l’affirmation selon laquelle le NAT ne droppe pas le trafic entrant
    Le NAT se contente de faire de la traduction d’adresses et ne droppe pas les paquets

    • Mais selon la configuration du routeur, le trafic entrant sur l’interface de sortie est souvent bloqué explicitement
    • Même si le NAT ne droppe pas les paquets, si l’IP de destination est celle du routeur lui-même, le trafic ne sera finalement pas routé
      L’auteur dit avoir modifié son texte pour tenir compte de ce retour