Il existe une certaine confusion à propos de NAT.

NAT n'a jamais été conçu pour être utilisé comme une fonction de sécurité. Cependant, il arrive que dans la plupart des cas (pas tous), lorsqu'une machine a accès à Internet via NAT uniquement, la machine est en quelque sorte "protégée". C'est comme si le système NAT était aussi, par nature, un pare-feu.

Voyons comment cela fonctionne:

• Un paquet IP a une adresse source et une adresse de destination. Chaque routeur, en voyant l'adresse de destination, décide à quel routeur suivant le paquet sera envoyé.
• Lorsqu'un routeur implémente NAT, il transmet les paquets sortants sous un prétexte; à savoir, les paquets portent l'adresse IP externe du routeur comme adresse source, et non la source réelle. Pour les paquets entrants, le routeur effectue l'opération inverse. Les numéros de port TCP / UDP sont utilisés pour savoir à quel hôte interne les paquets se rapportent.
• Cependant, du point de vue du routeur, les hôtes internes ont (privé) Adresses IP directement accessibles. NAT est pour les communications entre les hôtes internes et les machines au-delà du routeur.

Prenons un exemple:

  Inner <- --> HomeRouter < --- > ISPRouter < --- > L'Internet  

"Inner" est votre PC. "HomeRouter" est le routeur qui fait le NAT. "ISPRouter" est le routeur de votre FAI.

L '"effet pare-feu" est le suivant: généralement , même si "Inner" a un port (il exécute un service accessible à distance, par exemple un serveur Web local sur le port 80), les personnes "d'Internet" ne pourront pas s'y connecter. La raison est la suivante: il y a deux manières par lesquelles un paquet IP peut être transféré par HomeRouter vers Inner:

• Un paquet entrant peut venir avec l'adresse de HomeRouter comme destination et cibler un port que HomeRouter sait être associé à une connexion sortante d'Inner vers quelque part sur Internet. Cela ne fonctionne que pour une connexion qui a été initiée par Inner, et cela implique que le port ne correspondra pas à celui du serveur qui fonctionne sur Inner.

• Un paquet IP contient le privé d'Inner Adresse IP comme destination et est en quelque sorte portée à l'attention de HomeRouter. Mais ISPRouter ne connaît pas l'IP privée d'Inner et ne transmettra pas un paquet IP destiné à cette adresse à HomeRouter. Le routage source pourrait être utilisé pour marquer un paquet avec l'adresse IP privée d'Inner comme destination et l'adresse IP publique du HomeRouter comme hôte intermédiaire. Si ISPRouter prend en charge le routage source, alors un tel paquet atteindra Inner, quel que soit le NAT. Il se trouve que presque aucun FAI ne prend en charge le routage source.

Par conséquent, "l'effet pare-feu" du NAT repose sur deux propriétés:

• Les attaquants sont loin : les attaquants n'injectent pas de paquets directement sur la liaison entre le routeur domestique et le FAI; toutes leurs tentatives doivent passer par les routeurs ISP.
• ISP n'autorise pas le routage source . C'est le cas (très) courant.

Donc, dans la pratique , il y a beaucoup de machines, dans les maisons privées et les petites entreprises, qui pourraient être piratées dans une question de secondes sauf qu'ils bénéficient de "l'effet pare-feu" du NAT.

Et l'IPv6? NAT a été conçu et déployé ( largement ) afin de faire face à la rareté des adresses IPv4 gratuites. Sans NAT, l'IPcalypse aurait déjà détruit la civilisation (ou déclenché l'utilisation réelle d'IPv6, peut-être). IPv6 utilise des adresses de 128 bits, au lieu des maigres adresses IPv4 de 32 bits, précisément pour que des solutions de contournement grossières comme NAT ne soient pas nécessaires.

Vous pouvez utiliser NAT avec IPv6, mais cela n'a pas de sens - si vous pouvez vivre avec NAT, pourquoi passeriez-vous à IPv6?

Cependant, sans NAT, alors pas d '"effet de pare-feu" aussi fragile que cela puisse être. La plupart des systèmes d'exploitation sont maintenant prêts pour IPv6 et l'utiliseront automatiquement si on leur en donne la possibilité. Par conséquent, si un FAI décide d'activer IPv6, juste comme ça, alors beaucoup de machines qui étaient jusqu'ici "cachées" derrière un NAT deviendront accessibles de l'extérieur. Cela pourrait bien se transformer en une orgie mondiale de piratage informatique. Il n'est pas étonnant que les FAI soient quelque peu ... réticents.

Pour passer à IPv6 joliment , vous devez coupler son activation avec des règles de pare-feu solides et bien pensées, qui empêchera les connexions entrantes qui n'étaient pas possibles dans un monde NAT (avec les mises en garde expliquées ci-dessus), mais qui sont désormais réalisables grâce à la magie d'IPv6. Le mot opérationnel ici est "penser": cela prendra du temps de la part de certaines personnes, et ce n'est pas gratuit.

On peut donc prédire qu'IPv4 sera utilisé et maintenu tant qu'il pourra être toléré, et, grâce au NAT et aux proxys transparents, ce sera long (surtout si nous réussissons à contenir la population humaine en dessous de 10 milliards).

Le plus gros problème pour moi dans la suppression du NAT est la réduction de la confidentialité. Avec IPv6, je remarque que tous mes périphériques LAN ont une adresse IPv6 publique unique, ce qui permet à chaque périphérique sur un LAN d'être identifié de manière unique. Ce qui permet alors une identification plus facile des appareils individuels et des utilisateurs.

Implications en matière de confidentialité, telles que la possibilité de suivre votre activité sur plusieurs domaines. Les fournisseurs de publicité font évidemment déjà ce type de suivi avec des cookies, mais la suppression du NAT facilite leur travail pour suivre un appareil individuel.

Remarque: les détails de cette réponse supposeront que vous utilisez une machine Linux comme pare-feu. Si vous utilisez une autre plate-forme, les détails peuvent varier, mais la plupart des principes doivent toujours être valables.

Je me demande comment utiliser NAT avec IPv6.

Nat pour ipv6 est fortement déconseillé par l'IETF. néanmoins, il existe des implémentations si vous le souhaitez vraiment. Par exemple, linux l'a ajouté dans la version 3.7.

L'implémentation Linux fonctionne essentiellement de la même manière que l'implémentation NAT Linux pour IPv4. Je ne peux pas parler d'autres implémentations.

On dirait que vous n'en avez même plus besoin.

Les gens utilisent NAT pour diverses raisons.

1. Disponibilité des adresses, ils veulent plus d'adresses pour les hôtes internes que d'adresses publiques.
2. Indépendance des adresses, ils souhaitent conserver leurs adresses internes indépendamment des modifications apportées à leur connectivité.
3. Confidentialité, ils veulent cacher les détails de leur réseau interne et de quel hôte interne fait la demande depuis le monde extérieur.
4. Sécurité, un NAT finit par agir comme un grossier pare-feu avec état (bien qu'il ne soit peut-être pas très bon). De plus, il est probable que la fermeture échoue, si les règles NAT ne se chargent pas, le résultat probable est l'absence de connectivité plutôt que la connectivité largement ouverte.

De même, si NAT a un certain nombre d'inconvénients ( et au moins certains de ces inconvénients ont des implications sur la sécurité).

1. Certains protocoles peuvent être interrompus par le NAT (bien que cela puisse également être le cas des pare-feu avec état)
2. Chaque connexion doit être suivi et il y a un nombre limité de ports, cela peut conduire à des vulnérabilités de déni de service.
3. Lorsqu'un abus est détecté, NAT peut masquer la source de l'abus.
4. Traitement des services entrants peuvent être gênants. L'accès des clients locaux aux adresses IP externes peut être un point de complexité particulier.

Ipv6 résout la pénurie d'adresses, il contribue en quelque sorte à résoudre le problème de l'indépendance du FAI en vous permettant d'exécuter des adresses publiques et privées en parallèle (bien que cela crée ses propres problèmes). Les extensions de confidentialité cachent quel ordinateur sur un sous-réseau fait une demande, mais elles ne cachent pas sur quel sous-réseau il se trouve.

Alors, quel est exactement le concept derrière les configurations de pare-feu dans les environnements IPv6?

Vous pouvez effectuer un filtrage de paquets avec état sans NAT, par exemple une configuration de base pour autoriser toutes les connexions sortantes tout en interdisant les connexions entrantes peuvent ressembler à quelque chose comme.

  ip6tables -P FORWARD DROPip6tables -A FORWARD -i ethinternal -j ACCEPTip6tables -A FORWARD -m conntrack –ctstate ESTABLISHED, RELATED -j ACCEPT 

Le pare-feu garde toujours la trace des connexions de la même manière qu'un nat le ferait, mais il n'utilise ces informations que pour filtrer les paquets, pas pour effectuer la traduction.

Une chose vous devez faire attention à vous assurer que votre pare-feu échoue fermé. Je vous suggère de NE PAS activer le transfert dans sysctl.conf, mais de l'activer à la fin de votre script de pare-feu et d'utiliser "set -e" dans votre script de pare-feu. De cette façon, le transfert n'est activé que si le script du pare-feu s'exécute avec succès.

Si vous voulez également filtrer le trafic vers / depuis le pare-feu lui-même, vous devez penser à ICMP. Certains types d'ICMP doivent être autorisés depuis le lien local ou le réseau se cassera mal.

À part cela, ce n'est vraiment pas très différent d'ipv4, décidez ce que vous voulez autoriser et autorisez-le.

Les NAT ne sont pas vraiment plus sûrs comme par magie que les adresses publiques (et ont beaucoup de vilaines verrues, en raison de la nature de la traduction d'adresses). Pour acheminer vers votre adresse ipv4 privée, un attaquant a simplement besoin de pointer vers votre routeur, puis c'est entièrement au pare-feu de filtrer ce trafic.

Le passage à ipv6 ne changera rien à cela respect, sauf que votre sous-réseau filtré sera routable dans le monde au lieu d'être uniquement routable par l'attaquant. Tout le reste reste le même: si vous devez restreindre un sous-réseau ipv6, vous sous-classez votre / 64 et appliquez des règles de pare-feu pour filtrer le trafic autorisé à y accéder.

NAT est une technique qu'un routeur peut utiliser pour permettre aux hôtes connectés par son intermédiaire de partager une seule adresse IP.

Le routeur garde la trace des hôtes qui ont des connexions et les hôtes peuvent demander que certaines données leur soient acheminées. Les jeux, par exemple, demanderont généralement que le trafic UDP sur un certain port soit redirigé.

Inversement, tout paquet qui ne semble pas être pour quelqu'un que le routeur connaît (comme une lettre sans adresse lisible) sera rejeté. Cela le fait fonctionner comme un pare-feu.

IPv6 a des adresses pratiquement illimitées, et les ménages / routeurs auront probablement beaucoup à distribuer. NAT n'est plus nécessaire.

Cela supprime l'effet de pare-feu. Il sera probablement remplacé par des pare-feu appropriés qui sont tout aussi restrictifs et ennuyeux pour fournir une sécurité similaire aux utilisateurs finaux stupides. Avoir des pare-feu appropriés est un grand pas en avant, et j'espère que cela se produira le plus tôt possible.

IPv6 supprime le besoin de NAT de destination pour les connexions entrantes, les livrant à la place aux hôtes sur le lien local avec l'adresse de destination (publique) intacte. Les routeurs orientés vers l'extérieur annoncent des préfixes disponibles en externe à tous les hôtes internes, puis les hôtes sont libres d'ajouter des adresses avec ces préfixes sur leurs interfaces sur le lien local pour recevoir les connexions entrantes.

Je ne suis pas convaincu que nous ont éliminé le besoin de NAT source sur les paquets sortants. La valeur par défaut semble exiger du client qu'il s'attribue une adresse publique de la même manière, l'exposant au monde extérieur en utilisant le même identifiant d'hôte que les adresses locales du lien.

Eh bien, je suis désolé, c'est divulgue des informations privées sur Internet public (non fiable), ce qui, dans mon livre, constitue une violation de la confidentialité - l'un des trois piliers de la sécurité telle que nous la comprenons aujourd'hui.

Je pense que le NAT devrait être utilisé pour traduire la partie privée de l'adresse source (préfixe de routage, identifiant d'hôte et port) en une valeur aléatoire sur n'importe quel pare-feu protégeant la frontière entre l'Internet public et un réseau privé.

Le problème fondamental qui met les architectes Internet mal à l'aise avec NAT est qu'il semble entrer en conflit avec le principe de bout en bout. Cela signifie essentiellement que les routeurs de couche intermédiaire 3 doivent ignorer l'état de connexion de couche 4 afin que les paquets puissent être acheminés efficacement vers des routes alternatives. Cependant, le NAT est facile à implémenter dans le contexte d'un pare-feu avec état, et c'est ainsi qu'il doit être vu.

Le besoin de pare-feu est devenu évident alors qu'Internet approchait de son 20e anniversaire à la fin des années 80. De nos jours, toutes les données entrant et sortant d'un réseau privé sont contraintes de passer à travers un pare-feu, qui doit suivre l'état de la connexion pour pouvoir filtrer les paquets efficacement.

Bien que ce ne soit pas du tout clair dans 1994, si vous supprimez l'exigence de réutilisation d'adresse, alors NAT est une fonction de pare-feu dont le but principal est d'empêcher les données privées de quitter le réseau privé.

Plus précisément, lorsqu'un client initie une connexion à un serveur externe, la partie privée de l'adresse source (préfixe de routage, identifiant d'hôte et port) utilisée dans le réseau privé ne doit jamais être autorisée à s'échapper sur un réseau externe.

Le NAT Linux Ip6tables est disponible depuis la version du noyau 3 et fait un travail très professionnel, par exemple en produisant des adresses d'hôtes aléatoires uniques qui ne sont valables que pour une seule session.

Malheureusement, cette fonctionnalité n'a pas été entièrement documentée au motif que personne n'a proposé de cas d'utilisation! Eh bien, la voici. Et pendant que vous y êtes, vous pouvez également vous assurer que les numéros de port sont inclus.

Si vu de cette façon, c'est le pare-feu qui a une exigence de maintien de l'état, et le NAT est effectué par le pare-feu, il n'y a donc jamais eu de routeur NAT. Le principe de bout en bout ne s'applique pas.

Je pense que la leçon est que les architectes Internet devraient s'en tenir à la conception de protocoles Internet et laisser la conception du pare-feu aux architectes de la sécurité.