Avec IPv6, devons-nous utiliser NAT plus?
Je me demande comment utiliser NAT avec IPv6. Il semble que vous n'en ayez même plus besoin. Alors, quel est exactement le concept derrière les configurations de pare-feu dans les environnements IPv6?
Il existe une certaine confusion généralisée à propos de NAT .
NAT n'a jamais été conçu pour être utilisé comme fonction de sécurité. Cependant, il se trouve que dans la plupart cas (pas tous), lorsqu'une machine n'a accès à Internet que par NAT, alors 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 voir comment ça fonctionne:
- Un paquet IP a une source et une adresse de destination. Chaque routeur, en voyant l'adresse de destination, décide à quel routeur suivant le paquet doit être envoyé.
- Lorsqu'un routeur implémente NAT, il transfère les paquets sortants sous couvert; à 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 TCP/UDP numéros de port 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 des adresses IP (privées) qui sont directement accessibles. NAT est pour les communications entre les hôtes internes et les machines au-delà le routeur.
Prenons un exemple:
Inner <---> HomeRouter <---> ISPRouter <---> The 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 ouvert (il s'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 existe deux façons 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, ce qui implique que le port ne correspondra pas à celui du serveur qui s'exécute sur Inner.
Un paquet IP contient l'adresse IP privée d'Inner comme destination et est en quelque sorte porté à l'attention de HomeRouter. Mais ISPRouter ne connaît pas l'IP privée d'Inner et ne transmettrait 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 de HomeRouter comme hôte intermédiaire. Si ISPRouter prend en charge le routage source, un tel paquet atteindra Inner, quel que soit le NAT. Il se trouve que presque aucun FAI ne prend réellement en charge le routage source.
Par conséquent, "l'effet pare-feu" de 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 FAI.
- Le FAI 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 en quelques secondes, sauf qu'elles bénéficient de "l'effet pare-feu" du NAT.
Et IPv6? NAT a été conçu et déployé ( largement déployé) 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 128 bits, au lieu des maigres adresses IPv4 32 bits, précisément afin que des solutions de contournement grossières comme NAT n'aient pas besoin d'être utilisées.
Vous pouvez utiliser NAT avec IPv6, mais cela n'a pas de sens - si vous pouvez vivre avec NAT, pourquoi voudriez-vous passer à IPv6?
Cependant, sans NAT, alors aucun "effet pare-feu", aussi fragile soit-il. La plupart des systèmes d'exploitation sont désormais prêts pour IPv6 et l'utiliseront automatiquement si cela leur est donné. Par conséquent, si un FAI décide d'activer IPv6, comme ça, alors beaucoup de machines qui étaient jusque-là "cachées" derrière un NAT deviendront accessibles de l'extérieur. Cela pourrait bien se transformer en une orgie de piratage mondiale. Il n'est pas étonnant que les FAI soient quelque peu ... réticents.
Pour passer à IPv6 bien, vous devez coupler son activation avec des règles de pare-feu solides et bien pensées, qui empêcheront les connexions entrantes qui n'étaient pas possibles dans un monde NAT (avec les mises en garde expliquées ci-dessus), mais sont désormais réalisables grâce à la magie d'IPv6. Le mot opérationnel ici est "pensez": cela demandera du temps à certaines personnes, et ce n'est pas gratuit.
On peut donc prévoir que l'IPv4 sera utilisé et maintenu aussi longtemps qu'il sera toléré, et, grâce à NAT et aux mandataires transparents, ce sera un temps - long (en particulier si nous réussissons à contenir la population humaine en dessous de 10 milliards).
Le plus gros problème pour moi de supprimer 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 d'un LAN d'être identifié de manière unique. permet ensuite une identification plus facile des appareils individuels et des utilisateurs.
Conséquences sur la confidentialité, comme la possibilité de suivre votre activité sur plusieurs domaines. Les fournisseurs de publicités font évidemment déjà ce type de suivi avec des cookies, mais la suppression de NAT facilite leur travail pour suivre un appareil individuel.
Remarque: les détails de cette réponse supposeront que vous utilisez une boîte Linux comme pare-feu. Si vous utilisez une autre plate-forme, les détails peuvent varier, mais la plupart des principes devraient rester 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 voulez 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 Linux NAT pour IPv4. Je ne peux pas parler avec d'autres implémentations.
Il semble que vous n'en ayez même plus besoin.
Les gens utilisent NAT pour diverses raisons.
- La disponibilité des adresses, ils veulent plus d'adresses pour les hôtes internes qu'ils n'ont d'adresses publiques.
- Indépendant de l'adresse, ils souhaitent conserver leurs adresses internes indépendamment des modifications apportées à leur connectivité.
- Confidentialité, ils veulent cacher les détails de leur réseau interne et de l'hôte interne qui fait la demande du monde extérieur.
- Sécurité, un NAT finit par agir comme un pare-feu brut avec état (bien qu'il ne soit pas très bon). En outre, il est susceptible d'échouer si le NAT les règles ne se chargent pas, alors le résultat probable est l'absence de connectivité plutôt que la connectivité ouverte.
Mais NAT a un certain nombre d'inconvénients (et au moins certains de ces inconvénients ont des implications sur la sécurité).
- Certains protocoles peuvent être rompus par le NAT (bien que cela puisse également être vrai pour les pare-feu avec état)
- Chaque connexion doit être suivie et l'offre de ports est limitée, ce qui peut entraîner des vulnérabilités de déni de service.
- Lorsqu'un abus est détecté NAT peut masquer la source de l'abus.
- La gestion des services entrants peut être gênante. 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 permet de 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 des problèmes qui lui sont propres). Les extensions de confidentialité masquent l'ordinateur sur un sous-réseau qui 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 pourrait ressembler à quelque chose.
ip6tables -P FORWARD DROP
ip6tables -A FORWARD -i ethinternal -j ACCEPT
ip6tables -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, mais il n'utilise ces informations que pour filtrer les paquets, pas pour effectuer la traduction.
Une chose que vous devez faire attention est de vous assurer que votre pare-feu ne se ferme pas. Je suggère que vous n'activez PAS le transfert dans sysctl.conf, activez-le à la fin de votre script de pare-feu et utilisez "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 correctement.
Si vous souhaitez également filtrer le trafic vers/depuis le pare-feu lui-même, vous devez penser à ICMP. Certains types d'ICMP doivent être autorisés à partir de la liaison locale, sinon le réseau se brisera gravement.
En dehors de 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 magiquement sécurisés que les adresses publiques (et ont beaucoup de verrues désagréables en raison de la nature de la traduction des adresses). Pour router vers votre adresse IPv4 privée, un attaquant n'a qu'à pointer votre routeur, puis c'est entièrement au pare-feu de filtrer ce trafic.
Le passage à ipv6 ne changera rien à cet égard, sauf que votre sous-réseau filtré sera routable par le monde au lieu d'être uniquement routable par un 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.
Le NAT est une technique qu'un routeur peut utiliser pour permettre aux hôtes connectés via celui-ci 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 soient acheminées vers eux. Les jeux, par exemple, demandent généralement que le trafic UDP sur un certain port soit redirigé.
À l'inverse, tout paquet qui ne semble pas être destiné à toute personne 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 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 arrivera plus tôt que tard.
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 dit essentiellement que les routeurs de couche 3 intermédiaires doivent ignorer l'état de connexion de la couche 4 afin que les paquets peut être acheminé efficacement sur des routes alternatives. Cependant, 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 à mesure qu'Internet approchait 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 par un pare-feu, qui doit suivre l'état de la connexion pour pouvoir filtrer efficacement les paquets.
Bien que cela ne soit pas du tout clair en 1994, si vous supprimez l'exigence de réutilisation des adresses, 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 établit 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 à fuir sur un réseau externe.
Linux Ip6tables NAT est disponible depuis la version 3 du noyau et fait un travail très professionnel, par exemple en produisant des adresses d'hôte 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 trouvé de cas d'utilisation! Eh bien, le voici. Et pendant que vous y êtes, vous pouvez également vous assurer que les numéros de port sont inclus.
Vu de cette façon, c'est le pare-feu qui a besoin de maintenir l'état, et NAT est exécuté par le pare-feu, donc il n'y a jamais eu de chose comme 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 sécurité.
IPv6 supprime le besoin de destination NAT pour les connexions entrantes, au lieu de les livrer aux hôtes sur le lien local avec l'adresse de destination (publique) intacte. Les routeurs orientés vers l'extérieur annoncent les préfixes disponibles en externe à tous les internes hôtes, puis les hôtes sont libres d'ajouter des adresses avec ces préfixes à leurs interfaces sur le lien local pour recevoir les connexions entrantes.
Je ne suis pas convaincu que nous ayons supprimé le besoin de source NAT sur les paquets sortants. La valeur par défaut semble obliger le client à s’attribuer une adresse publique de la même manière, l’exposant à la monde extérieur en utilisant le même identifiant d'hôte que les adresses locales du lien.
Eh bien, je suis désolé, cela divulgue des informations privées sur Internet public (non fiable), ce qui, dans mon livre, est une violation de la confidentialité - l'un des trois piliers de la sécurité que nous comprenons aujourd'hui.
Je crois que 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 privé réseau.