Proxy ou pare-feu : quelle est la différence ?

Notre mention obligatoire, qui s'applique ici : nous sommes Geonode et nous vendons des proxys de transfert. Un proxy de transfert tel que celui que nous vendons n'est pas un produit de sécurité et vous ne devriez pas en acheter un pour assurer la défense de votre réseau. Il n'analyse pas le trafic à la recherche de menaces, n'applique pas de politique sur votre réseau et ne protège rien. Il modifie l’apparente provenance de vos requêtes, ce qui est utile pour la collecte de données, les tests géographiques et le contournement d’un filtre réseau — mais cela n’a absolument rien à voir avec la sécurité. Si vous êtes ici parce que vous cherchez à déterminer quoi installer à la périphérie de votre réseau, la réponse est un pare-feu, et cet article devrait vous aider à comprendre pourquoi ces deux concepts sont souvent confondus.

La distinction en une ligne

Un pare-feu est un filtre. Le trafic arrive, le pare-feu consulte un ensemble de règles, puis autorise ou rejette le trafic. C'est une barrière.

Un proxy est un intermédiaire. Vous demandez quelque chose au proxy, celui-ci va le chercher et vous le renvoie. C'est un intermédiaire.

La raison pour laquelle ces deux concepts sont souvent confondus est qu'un intermédiaire est parfaitement placé pour faire office de barrière. Si tout doit passer par vous, autant l'inspecter. Ainsi, ces catégories ont convergé au niveau des produits, même si leurs fonctions restent distinctes.

La distinction qui subsiste malgré cette convergence : le but d’un pare-feu est de décider, tandis que celui d’un proxy est d’agir en votre nom. Les produits qui remplissent ces deux rôles font deux choses différentes, et cet article a pour but de vous aider à déterminer lequel vous convient le mieux.

Le rôle d'un pare-feu, selon la définition du NIST

La Publication spéciale 800-41, révision 1, du NIST donne la définition à retenir :

Les pare-feu sont des dispositifs ou des programmes qui contrôlent le flux de trafic réseau entre des réseaux ou des hôtes appliquant des niveaux de sécurité différents.

Deux éléments de cette définition sont essentiels. « Contrôler le flux » : le rôle consiste à autoriser ou à refuser l’accès, et non à récupérer des données. Et « des niveaux de sécurité différents » — un pare-feu se situe à la frontière entre des zones de confiance différentes. Entre votre réseau et Internet, entre une zone démilitarisée (DMZ) et les systèmes internes, entre un segment et un autre.

Le NIST formule également une observation qui explique en grande partie l’évolution des produits de sécurité au cours des vingt dernières années :

Les menaces, qui étaient auparavant principalement présentes dans les couches inférieures du trafic réseau, se sont progressivement déplacées vers la couche applicative, ce qui a réduit l’efficacité globale des pare-feu pour bloquer les menaces véhiculées par les communications réseau.

Cette évolution — des paquets vers les applications — explique pourquoi les pare-feu simples sont devenus insuffisants et pourquoi des fonctionnalités de type proxy leur ont été ajoutées.

Trois générations de technologies de pare-feu

La taxonomie du NIST est le moyen le plus clair de comprendre comment les pare-feu ont évolué au sein de la pile.

Filtrage de paquets. Le plus ancien et le plus simple. Le NIST décrit les premiers pare-feu à filtrage de paquets comme « essentiellement des dispositifs de routage offrant une fonctionnalité de contrôle d’accès pour les adresses d’hôtes et les sessions de communication », et précise qu’ils sont « également connus sous le nom de pare-feu à inspection sans état », qui « ne conservent pas la trace de l’état de chaque flux de trafic ». Point essentiel : « les filtres de paquets ne se soucient pas du contenu des paquets. »

Rapide, peu coûteux, il ne prend en compte que les adresses et les ports. Le NIST note qu’il reste « au cœur de la plupart des pare-feu modernes », mais qu’« il existe aujourd’hui peu de pare-feu commercialisés qui se contentent d’un filtrage de paquets sans état ».

Inspection avec état. L’amélioration qui a rendu les pare-feu pratiques. Selon le NIST, elle « améliore les fonctions des filtres de paquets en suivant l’état des connexions et en bloquant les paquets qui s’écartent de l’état attendu », ce qui est rendu possible « grâce à une meilleure prise en compte de la couche de transport ». Elle tient à jour une table d’état comprenant généralement « l’adresse IP source, l’adresse IP de destination, les numéros de port et les informations sur l’état de la connexion ».

Concrètement, cela signifie que le trafic de retour correspondant à une connexion que vous avez initiée est automatiquement autorisé, tandis que le trafic non sollicité ne l’est pas. C’est ce comportement que la plupart des gens ont à l’esprit lorsqu’ils parlent de « pare-feu ».

Les pare-feu d’application. Ceux-ci inspectent le contenu. Les exemples fournis par le NIST sont concrets : un pare-feu d’application « peut déterminer si un e-mail contient un type de pièce jointe que l’organisation n’autorise pas », ou détecter « si la messagerie instantanée (IM) est utilisée sur le port 80 (généralement utilisé pour le protocole HTTP) ». Il peut bloquer des opérations spécifiques telles que la commande FTP « put », filtrer les pages contenant un contenu actif particulier et identifier des « séquences de commandes inattendues ».

Cet exemple de messagerie instantanée sur le port 80 illustre parfaitement l’intérêt de remonter la pile. Un filtre de paquets détecte le port 80 et interprète cela comme du « trafic web ». Seul un système capable de lire le contenu peut en juger autrement.

Le rôle d'un proxy

Un proxy intercepte votre connexion et établit la sienne.

Vous vous connectez au proxy et demandez une ressource. Le proxy se connecte à la destination, récupère la ressource et vous la renvoie. Il y a ainsi deux connexions là où vous n'en auriez attendu qu'une, et c'est cette structure qui donne lieu à toutes les propriétés propres aux proxys.

Le NIST décrit ce mécanisme avec précision dans le contexte des passerelles proxy d’application : chaque connexion « entraîne la création de deux connexions distinctes : l’une entre le client et le serveur proxy, et l’autre entre le serveur proxy et la véritable destination », le proxy étant « censé être transparent pour les deux hôtes — de leur point de vue, il s’agit d’une connexion directe ». Et la conséquence : « Comme les hôtes externes ne communiquent qu’avec l’agent proxy, les adresses IP internes ne sont pas visibles depuis l’extérieur. »

Il convient de distinguer deux types :

Les proxys de transfert agissent pour le compte des clients. Vos requêtes transitent par eux ; ainsi, la destination voit l’adresse du proxy plutôt que la vôtre. C’est ce que nous proposons, et cela couvre le web scraping, les tests géographiques, le filtrage sortant d’entreprise et la mise en cache. Le NIST observe que « la plupart des serveurs proxy actuellement utilisés sont des serveurs proxy sortants, les plus courants étant les proxys HTTP ».

Les proxys inversés agissent pour le compte des serveurs. Les requêtes des clients leur parviennent et sont transmises aux serveurs backend ; c’est ainsi que fonctionnent l’équilibrage de charge, la terminaison TLS et les réseaux de diffusion de contenu. Du point de vue du client, le proxy inverse est le site web.

Le NIST fait également une remarque franche concernant le cas des proxys entrants, que la plupart des explications omettent : « Ces dernières années, l’utilisation des serveurs proxy entrants a considérablement diminué », car « un serveur proxy entrant doit imiter les capacités du serveur réel qu’il protège, ce qui devient pratiquement impossible lorsqu’il s’agit de protéger un serveur doté de nombreuses fonctionnalités », et les fonctions de journalisation et de contrôle d’accès fournies par ces proxys « sont désormais généralement intégrées aux serveurs réels ».

Points communs : les passerelles proxy d'application

Ce recoupement correspond à une véritable catégorie de produits, et le NIST prend soin de la distinguer d'un concept dont le nom prête à confusion :

Les passerelles proxy d'application sont très différentes des pare-feu d'application.

Une passerelle proxy d’application est « une fonctionnalité des pare-feu avancés qui combine un contrôle d’accès de couche inférieure avec des fonctionnalités de couche supérieure », comprenant « un agent proxy qui agit comme intermédiaire entre deux hôtes souhaitant communiquer entre eux, et qui n’autorise jamais de connexion directe entre eux ».

Les avantages énumérés par le NIST sont les suivants : empêcher les connexions directes entre les hôtes, inspecter le contenu à la recherche de violations des politiques et — pour certaines implémentations — la « capacité à déchiffrer les paquets (par exemple, les charges utiles protégées par SSL), à les examiner et à les rechiffrer avant de les transmettre à l’hôte de destination », les données non déchiffrables étant transmises telles quelles.

Les inconvénients sont tout aussi spécifiques. Les passerelles de proxy d’application « ont tendance à être limitées en termes de prise en charge des nouvelles applications et des nouveaux protocoles réseau », car « un agent proxy individuel, spécifique à l’application, est requis pour chaque type de trafic réseau devant transiter par un pare-feu ». Les fournisseurs proposent des agents génériques pour combler cette lacune, mais le NIST souligne que ceux-ci « ont tendance à annuler bon nombre des atouts de l’architecture de passerelle proxy d’application, car ils se contentent de permettre au trafic de passer par un « tunnel » à travers le pare-feu ».

C’est là le compromis inhérent à l’ensemble de cette catégorie : la mise en proxy offre une inspection approfondie, au prix de la nécessité de comprendre chaque protocole acheminé, et la « porte de secours » prévue pour les protocoles que l’on ne comprend pas annule cet avantage.

Le NIST distingue également les serveurs proxy dédiés, qui « conservent le contrôle du trafic par le proxy » mais « disposent généralement de capacités de pare-feu bien plus limitées », et sont « généralement utilisés pour réduire la charge de travail du pare-feu et effectuer un filtrage et une journalisation spécialisés qui pourraient être difficiles à réaliser sur le pare-feu lui-même ».

Le sens de la circulation est plus important qu’on ne le pense

Une source fréquente de confusion, qu’il convient de préciser explicitement.

Les pare-feu régulent généralement les deux sens de circulation, mais sont conçus pour protéger le trafic entrant. Le principe de base consiste à empêcher l’accès à l’extérieur — bien que, dans la pratique, le filtrage sortant soit souvent la partie la plus importante, car il limite ce qu’un hôte interne compromis peut atteindre.

Les proxys de transfert ne gèrent que le trafic sortant. Ils empêchent la destination de vous identifier et permettent à une organisation de contrôler et d’enregistrer ce qui sort. Ils ne constituent pas une défense contre les menaces entrantes.

Les proxys inversés ne gèrent que le trafic entrant. Ils protègent le serveur d’origine en se plaçant en avant de celui-ci, et c’est là que s’effectuent l’équilibrage de charge, la mise en cache et la terminaison TLS.

Les pare-feu d’applications web se situent en amont des serveurs web, sur le trafic entrant. Le NIST les décrit comme « des pare-feu d’applications spécialisés… qui se trouvent en amont du serveur web », ajoutés car le protocole HTTP « a été exploité par des attaquants de nombreuses façons ». Comme ils sont placés en amont des serveurs web plutôt qu’à la périphérie du réseau, le NIST note qu’« ils sont souvent considérés comme très différents des pare-feu traditionnels ».

Conséquence : se demander « dois-je utiliser un proxy ou un pare-feu » sans préciser le sens du trafic revient à poser une question incomplète. Un proxy sortant et un pare-feu entrant ne sont pas en concurrence ; ils ne sont même pas orientés dans la même direction.

Côte à côte

La ligne qui répond à la plupart des questions pratiques est la dernière. Un pare-feu sert à imposer une frontière de sécurité. Un proxy de transfert sert à modifier la manière dont vous accédez aux ressources et l’endroit d’où vous y accédez. Ces deux éléments sont complémentaires plutôt qu’alternatifs.

Avez-vous besoin de l’un, de l’autre, ou des deux ?

Tout le monde a besoin d’un pare-feu. Chaque système d’exploitation en intègre un, chaque routeur en possède un, chaque fournisseur de services cloud vous propose des groupes de sécurité. Ce n’est pas facultatif et, à petite échelle, il ne s’agit pas vraiment d’une décision d’achat, mais plutôt d’une décision de configuration. Si votre question est « dois-je avoir un pare-feu ? », la réponse est que vous en avez déjà un et qu’il doit être configuré.

Vous avez besoin d’un proxy de transfert si : vous collectez des données en grande quantité et avez besoin que les requêtes soient réparties sur plusieurs adresses ; vous devez accéder à du contenu spécifique à une région ; vous devez accéder à un contenu filtré par un réseau ; ou vous dirigez une organisation et devez contrôler et consigner les accès Web sortants. Les trois premiers cas relèvent de notre domaine d’activité. Le quatrième cas relève généralement des fonctionnalités d’un pare-feu existant ou d’une passerelle Web sécurisée, plutôt que d’un achat distinct.

Vous avez besoin d’un proxy inverse si vous exploitez un service Web public, quelle que soit sa taille. L’équilibrage de charge, la terminaison TLS, la mise en cache et la limitation de débit font tous partie de cette architecture, qui est standard et non un simple ajout.

Vous avez besoin d’un pare-feu d’applications Web si vous exploitez une application Web publique traitant des données sensibles. Il s’agit d’un produit différent d’un pare-feu réseau, qui remplit une fonction distincte ; le fait d’en posséder un ne signifie pas que vous disposez de l’autre.

La seule combinaison qu’il convient de signaler comme une erreur : l’achat d’un service de proxy direct à des fins de sécurité. Il n’en offre aucune. Les proxys résidentiels et de centre de données que nous et d’autres fournisseurs commercialisons modifient l’adresse d’origine de vos requêtes. Ils n’inspectent pas le trafic, ne bloquent pas les menaces, n’appliquent pas de politique de sécurité et ne protègent pas les terminaux. Si un fournisseur laisse entendre le contraire, il s’agit d’un argument marketing.

Questions fréquentes

Un proxy est-il un pare-feu ?

Non. Un pare-feu contrôle le trafic autorisé entre des réseaux présentant des niveaux de sécurité différents. Un proxy effectue des requêtes pour le compte d’un tiers, en mettant fin à une connexion et en en établissant une autre. Certains pare-feu intègrent des fonctionnalités de proxy — le NIST les appelle « passerelles proxy d'application » — mais leurs fonctions sont distinctes.

Un proxy peut-il remplacer un pare-feu ?

Non. Un proxy de transfert gère les requêtes sortantes et n’offre aucune protection contre le trafic entrant, n’applique aucune politique sur votre réseau et n’effectue aucune inspection des menaces. Même lorsqu’un proxy inspecte le contenu, il ne voit que le trafic qui transite par lui, tandis qu’un pare-feu contrôle la frontière elle-même.

Qu’est-ce qui est le plus sécurisé, un proxy ou un pare-feu ?

Ils ne sont pas comparables sur cet axe. Un pare-feu est un contrôle de sécurité ; un proxy de transfert ne l’est généralement pas. Les passerelles proxy d’application intégrées aux pare-feu offrent certes une inspection rigoureuse, car elles empêchent les connexions directes et peuvent examiner le contenu, mais il s’agit là d’une fonctionnalité propre au pare-feu plutôt que d’une propriété des proxys en général.

À quelle couche chacun d’entre eux opère-t-il ?

Les pare-feu à filtrage de paquets fonctionnent à la couche réseau, au niveau des adresses et des ports. L’inspection avec état ajoute une prise en compte de la couche transport grâce à une table d’état des connexions. Les pare-feu applicatifs et les proxys fonctionnent à la couche application, où ils peuvent lire le contenu des protocoles. Le NIST souligne que les menaces se sont déplacées vers les couches supérieures au fil du temps, ce qui explique pourquoi les approches basées sur les couches supérieures sont devenues nécessaires.

Quelle est la différence entre un proxy direct et un proxy inverse ?

Un proxy direct agit pour le compte des clients ; ainsi, la destination voit le proxy plutôt que vous. Un proxy inverse agit pour le compte des serveurs : ce sont donc les clients qui l’atteignent à la place de la source. Des directions opposées, des bénéficiaires opposés, mais le même mécanisme sous-jacent consistant à mettre fin à une connexion pour en établir une autre.

Ai-je besoin à la fois d’un proxy et d’un pare-feu ?

Vous avez de toute façon besoin d’un pare-feu — vous en possédez déjà plusieurs. Vous n’avez besoin d’un proxy direct que pour des tâches spécifiques : collecte de données en volume, tests spécifiques à une région ou contrôle organisationnel de l’accès Web sortant. Vous avez besoin d’un proxy inverse si vous exploitez un service Web public. Des questions différentes appellent des réponses différentes.

Un proxy masque-t-il mon adresse IP à tout le monde ?

Uniquement vis-à-vis de la destination. Votre FAI voit toujours que vous vous connectez au proxy, l’opérateur du proxy voit les deux extrémités, et tout ce à quoi vous vous connectez vous identifie de toute façon. La définition du NIST — selon laquelle les hôtes externes ne communiquent qu’avec l’agent proxy, de sorte que les adresses internes ne sont pas visibles depuis l’extérieur — est exacte et plus restrictive que le terme « anonyme ».

Qu’est-ce qu’un pare-feu d’application web ?

Il s’agit d’un pare-feu d’application spécialisé placé directement en amont d’un serveur web afin de détecter les attaques visant le protocole HTTP. Le NIST le distingue des pare-feu traditionnels précisément parce qu’il protège un serveur plutôt qu’une périphérie de réseau. Il s’agit d’un produit distinct du pare-feu réseau, et le fait d’en disposer ne remplace pas l’autre.

En conclusion

Voici comment résumer clairement la situation : un pare-feu décide, un proxy agit en votre nom. Tout le reste découle de ces deux verbes.

La confusion est réelle et non due à une négligence, car les catégories ont convergé. Un intermédiaire qui termine chaque connexion est idéalement placé pour les inspecter ; c’est pourquoi les pare-feu ont intégré des fonctionnalités de proxy, et la passerelle proxy d’application du NIST est exactement cet hybride — avec de réels avantages en termes de profondeur d’inspection et un coût réel lié à la nécessité d’un agent spécifique par protocole.

Ce qui n’a pas convergé, c’est la finalité. Un pare-feu existe pour imposer une frontière entre des zones de confiance différentes. Un proxy de transfert existe pour modifier l’apparente provenance de vos requêtes et pour permettre à quelqu’un de contrôler ce qui sort. Si vous choisissez ce que vous placez à votre périmètre, c’est une question de pare-feu. Si vous choisissez comment accéder au monde extérieur, c’est une question de proxy. Les deux ne semblent être des alternatives que d’un point de vue suffisamment éloigné pour que le sens du trajet ne soit plus visible.