Le mythe de la traduction d’adresses réseau comme mesure de sécurité
Introduction
Dans les réseaux des fournisseurs de services, la traduction d’adresses réseau (NAT) est principalement utilisée au niveau de la périphérie Internet des abonnés. Malheureusement, ce point constitue également la plus grande surface d’attaque et concentre les menaces les plus importantes au sein du réseau du fournisseur de services. Dans les réseaux mobiles, cette zone est désignée par différents termes, notamment Gi LAN, SGi LAN et périphérie mobile. Plus généralement, il s’agit de l’endroit où la connectivité Internet directe rejoint une passerelle qui gère une technologie d’accès spécifique, telle que le sans-fil, le câble ou la fibre. Les passerelles sont très efficaces pour gérer la connectivité des abonnés sur un réseau d’accès donné, mais elles sont peu adaptées à l’application de contrôles de sécurité ou à la traduction d’adresses, en raison de fonctionnalités de sécurité limitées ou d’un coût excessif.
Par le passé, les fournisseurs de services ont longtemps cru, à tort, que la NAT pouvait assurer à la fois la traduction d’adresses et la sécurité à la périphérie Internet des abonnés. La communauté de la cybersécurité a tenté de dissiper ce mythe, mais celui-ci perdure. Dans le contexte actuel de multiplication des attaques, les fournisseurs de services mobiles et fixes doivent comprendre pourquoi la NAT ne suffit pas. Il faut pour cela reconnaître qu’au point d’agrégation des abonnés, de nombreux types de services de sécurité sont nécessaires, au-delà du simple blocage du trafic entrant.
Sécurité de l’agrégation des abonnés
Une solution architecturale courante consiste à placer entre la passerelle et Internet un système avec état capable de fournir divers services aux abonnés et au réseau. Les types courants de services de sécurité comprennent :
- Protection contre les attaques DDoS. Visant généralement à protéger contre les attaques Internet de grande ampleur, l’atténuation des attaques par déni de service distribué (DDoS) consiste à éliminer les paquets qui ne répondent à aucun objectif légitime et à limiter ceux qui s’écartent des schémas de comportement habituels.
- Limitation des ports et des protocoles. Il y a plus de dix ans, les fournisseurs de services offraient à tous leurs abonnés un accès totalement ouvert, aussi bien entrant que sortant. Si cela facilitait effectivement la connectivité de nombreuses applications, cela créait également un environnement idéal pour la propagation de virus et de vers, qui consommaient alors une quantité excessive de ressources réseau. Aujourd’hui, la plupart des fournisseurs de services bloquent certains protocoles sur leurs réseaux et limitent l’utilisation d’autres afin de réduire le risque de favoriser la prolifération des logiciels malveillants.
- Protection de l’infrastructure. L’un des principaux atouts de la connectivité IP est qu’elle permet à toute personne disposant d’une adresse IP de communiquer potentiellement avec n’importe quelle autre adresse IP dans le monde. Toutefois, elle permet également aux abonnés de se connecter potentiellement, sans motif légitime, aux systèmes du réseau du fournisseur de services. Il est donc essentiel de mettre en place des contrôles afin de protéger l’infrastructure au niveau du point d’agrégation des abonnés.
- Atténuation des botnets. À tout moment, de nombreux abonnés disposent de systèmes infectés par des virus et des logiciels malveillants qui communiquent avec des systèmes de commande et de contrôle (C&C) quelque part sur Internet. Restreindre ces communications profite aussi bien aux abonnés qu’au réseau, en limitant l’utilisation des appareils des abonnés dans le cadre d’attaques par botnet.
- Types de contrôle des services. De nombreux fournisseurs de services proposent différentes offres permettant aux abonnés de bénéficier de divers types de connectivité. Par exemple, les entreprises clientes peuvent avoir besoin d’adresses IP statiques, sans restriction d’utilisation des protocoles, ainsi que de la possibilité d’héberger des serveurs. En revanche, une offre grand public d’entrée de gamme peut interdire l’exécution de serveurs sur les appareils mobiles. Il est également possible d’utiliser une classe d’adresses IP spécialisée pour la connectivité d’administration, afin de mettre à jour le micrologiciel et les logiciels des équipements CPE. Lorsque les opérateurs mobiles déploient la voix sur LTE (VoLTE), ils utilisent un APN dédié dont la connectivité doit être limitée, faute de quoi le risque de perte de revenus augmente considérablement.
Ces cinq exemples de contrôles de sécurité ne sont pas exhaustifs, mais ils constituent un socle de fonctionnalités indispensables aux réseaux modernes au niveau du point d’agrégation des abonnés. Dans cette optique, les solutions NAT n’offrent pas suffisamment de fonctionnalités pour sécuriser et protéger les réseaux modernes. (Il convient de noter que si une entreprise propose une solution NAT de classe opérateur (CGNAT) assurant l’une des fonctions ci-dessus, elle reconnaît de fait que le NAT seul ne suffit pas à protéger le produit le plus précieux d’un fournisseur de services : la capacité à connecter les personnes et les objets.) Pour sécuriser la périphérie Internet des abonnés au moyen de services tels que ceux décrits ci-dessus, la solution appropriée n’est pas le NAT, mais un pare-feu réseau de classe opérateur tel que F5® BIG-IP® Advanced Firewall Manager™ (AFM).
Arguments techniques
Après avoir établi qu’il existe de nombreuses autres menaces de sécurité contre lesquelles la NAT ne peut rien, déconstruisons les mythes techniques et commerciaux liés à son utilisation comme service de sécurité, même lorsqu’il s’agit simplement de bloquer le trafic non sollicité.
Entrées et sorties avec et sans état : IPv6
Bien qu’il ait été créé pour faciliter la communication entre des hôtes situés dans des espaces d’adressage privés qui se chevauchent, le NAT a été largement déployé principalement pour permettre de connecter davantage d’hôtes à un réseau que le nombre d’adresses IP individuelles disponibles. Les problèmes de sécurité associés au NAT sont documentés depuis longtemps. (Voir les sections relatives aux considérations de sécurité des documents de l’Internet Engineering Task Force (IETF) RFC2663 et RFC2993). Ces préoccupations ont largement contribué à la création d’IPv6. Maintenant que la transition mondiale vers IPv6 est engagée depuis un certain temps, le NAT ne sera plus nécessaire pour les hôtes utilisant IPv6. Il ne pourra donc assurer aucune protection aux hôtes IPv6.
On pourrait avancer qu’une passerelle NAT46 ou NAT64 avec état peut offrir une certaine sécurité. Toutefois, cette sécurité ne serait que partielle et temporaire. Le CGNAT est principalement conçu pour assurer la traduction du trafic entre des hôtes lorsque l’une des parties n’est pas encore passée à IPv6, ce qui signifie que l’objectif final est de supprimer le dispositif CGNAT et de permettre un trafic IPv6 natif sans traduction. En l’absence d’un pare-feu réseau de classe opérateur, le dispositif NAT devient un obstacle à la migration complète de l’opérateur vers IPv6.
En outre, de nombreux réseaux de fournisseurs de services proposent désormais des configurations à double pile IPv4/IPv6. Dans ce cas, même si le fournisseur de services a activé NAT44, l’interface IPv6 n’utilise pas la traduction d’adresses. Cela signifie que l’organisation a décidé que NAT suffisait à sécuriser les interfaces IPv4, alors que le même hôte reste totalement exposé sur l’interface IPv6, ce qui est illogique. Pourquoi un architecte réseau estimerait-il qu’une protection est nécessaire en IPv4, mais pas en IPv6, alors que les deux protocoles sont exposés exactement aux mêmes menaces ?
Les pare-feu réseau de classe opérateur doivent dès aujourd’hui être présentés comme des solutions, car les opérateurs n’accepteront pas que le manque de sécurité constitue un obstacle à la migration vers IPv6. Le déploiement aujourd’hui d’un produit CGNAT dédié obligera à l’avenir l’opérateur à racheter des équipements et des logiciels, ainsi qu’à repenser l’architecture du réseau, ce qui entraînera des coûts nettement plus élevés, toute modification d’un réseau de fournisseur de services étant un processus complexe. À l’inverse, l’intégration de la fonctionnalité CGNAT à un pare-feu réseau de classe opérateur garantira une transition fluide vers IPv6 en matière de parité des fonctions de sécurité et de capacité.
Entrée et sortie sans état : IPv4
En général, la NAT sans état constitue un cas d’usage rare, mais elle peut être employée dans certaines situations particulières. Les équipements sans état autorisent tout le trafic vers les ports pour lesquels la NAT inverse est permise, indépendamment de la requête de l’équipement de l’abonné. Comme ils sont sans état, ils ne savent pas quel trafic a été envoyé par l’hôte nécessitant la NAT ; ils doivent donc autoriser tout le trafic de retour. Il est évident que la NAT sans état peut ne pas convenir à la plupart des cas d’usage de la NAT et qu’elle est totalement inadaptée à tout cas d’usage lié à la sécurité.
Trafic sortant avec état : IPv4
Dans la plupart des cas, la NAT IPv4 avec état pour le trafic sortant permet à un opérateur de protéger partiellement les hôtes internes contre le trafic initié depuis l’extérieur. Toutefois, elle ne protège pas les hôtes internes et ne permet pas non plus de réagir aux attaques lancées depuis ces hôtes contre d’autres ressources réseau connectées au dispositif NAT. Dans de nombreux cas, beaucoup d’hôtes internes compromis peuvent accéder à Internet pour communiquer avec l’infrastructure de commande et de contrôle d’un botnet. Dans certains cas rares, mais particulièrement graves, ces hôtes compromis servent de points de départ à des attaques sophistiquées contre le réseau interne du fournisseur de services ou à des attaques dirigées vers l’extérieur, visant des entreprises ou des organismes publics de premier plan et susceptibles d’attirer une publicité indésirable. Les coûts liés à la remise en état après ce type d’incident dépassent largement le coût de la solution.
Trafic entrant avec état : IPv4
Le trafic IPv4 entrant avec suivi d’état est le seul type de trafic pour lequel on pourrait raisonnablement soutenir que le NAT offre une protection de sécurité, et encore, uniquement sous certaines conditions. Ce mythe persiste, mais comme l’expliquent clairement les éléments ci-dessus, ce trafic IPv4 ne représente qu’une fraction de la surface d’attaque des hôtes en réseau. En outre, même pour le trafic IPv4 entrant, le NAT avec suivi d’état n’offre qu’une protection limitée, car les techniques d’attaque modernes partent du principe qu’un dispositif NAT se trouve sur le chemin et qu’il doit être compromis. La traduction statique et la traduction de destination des hôtes n’offrent aucune sécurité.
Une partie de la sécurité supposément assurée par la NAT repose sur l’obscurcissement, que la communauté de la sécurité ne considère pas comme une véritable solution. L’obscurcissement ne fait que compliquer la recherche d’informations pouvant être obtenues par d’autres moyens et n’empêche donc rien. L’autre composante du mythe de la sécurité assurée par la NAT avec état pour le trafic entrant est qu’elle est censée créer une « voie à sens unique » — ce qui n’est en réalité pas le cas. S’il est vrai que la NAT IPv4 avec état pour le trafic entrant rejette le trafic TCP initié depuis l’extérieur, cela ne signifie pas qu’un hôte externe ne puisse pas, dans certaines situations, envoyer du trafic à des hôtes internes ou recourir à d’autres méthodes pour contourner la NAT. En fait, la plupart des attaques réseau partent du principe que cela est nécessaire pour compromettre le système.
Il existe plusieurs façons de contourner ainsi le NAT, et toutes peuvent être bloquées par un pare-feu. Tout d’abord, un attaquant peut lancer une attaque ciblée ou un balayage afin d’envoyer du trafic vers les ports ouverts dans la table d’état du dispositif NAT. Cette attaque peut viser à provoquer un déni de service (DoS) en invalidant une session existante sur l’hôte ou dans la table d’état du NAT, à cartographier un réseau interne ou à injecter une charge utile malveillante dans la session existante d’un tiers afin de compromettre l’hôte interne. Les conséquences peuvent être graves pour le trafic UDP, qui est par conception sans état ; toutefois, le même résultat peut être obtenu avec TCP ou d’autres protocoles, si l’hôte est vulnérable. En outre, le NAT ne garantit pas nécessairement la conformité aux protocoles, la vérification des numéros de séquence ni les autres mesures de protection contre les attaques DoS de couche 2 ou 3 qu’offrent intrinsèquement les pare-feu ou les dispositifs de sécurité avancés. Le NAT ne fournit par ailleurs aucun outil permettant de réagir en cas de faille de sécurité.
Arguments commerciaux
Les arguments commerciaux en faveur du déploiement d’un pare-feu réseau de classe opérateur sont simples : tout d’abord, aucun fournisseur de services ne peut se permettre de subir les failles de sécurité préjudiciables et parfois très médiatisées que l’on connaît aujourd’hui. C’est pourquoi les services de pare-feu et de traduction d’adresses réseau sont souvent proposés conjointement. Sur un réseau mobile moderne, les pertes financières peuvent facilement se chiffrer en millions de dollars, certaines attaques pouvant même mettre à mal des marques entières.
Deuxièmement, lorsqu’un dispositif NAT est le seul équipement présent, le fournisseur de services ne dispose d’aucun outil pour contrer l’attaque et doit la subir, impuissant, jusqu’à ce que des solutions ponctuelles soient trouvées.
Enfin, les fournisseurs de services avisés qui utilisent un pare-feu avancé peuvent enrichir leurs offres destinées aux clients avec des services de sécurité supplémentaires. Traditionnellement, ces ajouts attirent les entreprises clientes qui ont clairement besoin de protéger leurs actifs. Sans un pare-feu doté de telles capacités, un fournisseur de services n’aura jamais la possibilité de générer ces revenus. En effet, s’il ne met pas en avant une solution combinant NAT et pare-feu avec des fonctionnalités de sécurité avancées, le fournisseur de services laisse ses clients supposer que sa gamme de produits ou son expertise présente des lacunes.
Conclusion
Il est temps d’en finir avec le mythe selon lequel le NAT offrirait une sécurité significative face aux attaques sophistiquées d’aujourd’hui. En réalité, d’un point de vue technique, le NAT offre :
- Aucune sécurité pour les hôtes IPv6, puisque la NAT leur est inutile.
- Aucune sécurité pour les hôtes utilisant la NAT sans état.
- Aucune protection contre les attaques sortantes provenant d’hôtes derrière un NAT avec état.
- Protection minimale contre les attaques entrantes visant un hôte derrière un NAT avec état, car les attaques modernes partent du principe qu’un dispositif NAT est présent et parviennent facilement à le compromettre ou à le contourner.
- Aucun outil pour répondre aux attaques de sécurité qui se produisent régulièrement.
D’un point de vue commercial, le fait de négliger le déploiement d’un pare-feu réseau de classe opérateur tel que BIG-IP AFM dans le cadre d’une solution de NAT en périphérie et de sécurité expose le fournisseur de services à des pertes de revenus aussi importantes qu’insidieuses et témoigne de son manque d’innovation.
À l’inverse, les fournisseurs de services qui déploient un pare-feu de classe opérateur adapté et riche en fonctionnalités, comme ceux proposés par F5, peuvent avoir pleinement confiance dans la sécurité de leur réseau, atténuer les risques financiers et réputationnels liés aux attaques, et saisir l’occasion de proposer à leurs clients des services de sécurité de pointe à valeur ajoutée afin d’accroître leurs revenus.
PUBLIÉ LE 10 FÉVRIER 2016