Le meilleur pare-feu gratuit pour un VPS Linux n'est pas un seul outil. C'est un pare-feu d'hôte (la couche dont chaque serveur a besoin) et, si vous faites tourner une application web, un pare-feu applicatif web par-dessus. Ce guide couvre les deux, nomme les meilleures options de pare-feu gratuites ou open source pour chaque couche, et précise ce que chacune vous coûte en RAM et en effort de configuration. Il s'adresse aux exploitants de VPS Linux. Ce n'est pas un tour d'horizon Windows.
La version courte
- « Meilleur pare-feu gratuit » désigne quatre produits différents : les pare-feu d'hôte Linux, les distributions de pare-feu réseau, les pare-feu applicatifs web (WAF) et les outils grand public Windows. Seuls le premier et le troisième ont leur place sur un VPS.
- Sur la couche hôte, utilisez l'outil le plus simple adapté à votre distribution : UFW sur Ubuntu, firewalld sur la famille RHEL, et soit UFW soit nftables directement sur Debian selon le niveau de contrôle dont vous avez besoin. Les outils frontend modernes reposent généralement sur nftables, mais nftables lui-même est le framework par défaut et recommandé sur Debian.
- Un WAF est une couche distincte et complémentaire pour les applications web. Il ne remplace pas le pare-feu d'hôte.
- SafeLine est le WAF gratuit le plus léger (1 GB de RAM). BunkerWeb est le plus complet mais réclame 8 GB. Haltdos Community est une troisième option gratuite dotée d'une interface web.
Ce que ce guide laisse de côté
Quelques catégories de pare-feu qui apparaissent dans d'autres listes de « meilleurs pare-feu gratuits » ne s'appliquent pas ici, et les nommer une fois vous évite de courir après le mauvais outil.
- Les pare-feu de poste de travail Windows et grand public (ZoneAlarm, Comodo, TinyWall). Mauvais système d'exploitation, mauvaise machine.
- Les pare-feu commerciaux et d'entreprise payants (Cisco ASA, Palo Alto, Fortinet). Hors du périmètre « gratuit ».
- Les WAF SaaS cloud (Cloudflare, Sucuri). Valables, mais basés sur le DNS ou un proxy et hors du périmètre de ce VPS auto-hébergé. Cloudflare propose bien un jeu de règles WAF de base gratuit, tandis qu'une couverture plus complète des règles gérées et du jeu de règles OWASP dépend du forfait.
- Faire tourner pfSense ou OPNsense comme passerelle sur un VPS mutualisé. Architecturalement inadapté sans passthrough de NIC. Expliqué dans la section sur les distributions réseau.
Ce que « meilleur pare-feu gratuit » signifie réellement (quatre catégories)
Si cette recherche vous fait tourner en rond, c'est qu'elle recouvre quatre produits qui résolvent quatre problèmes différents sur quatre machines différentes. Classez-vous d'abord dans une catégorie, puis choisissez un outil.
- Pare-feu d'hôte/VPS Linux : des logiciels qui tournent sur la même machine que vos services et contrôlent quels ports sont accessibles. UFW, firewalld et nftables. C'est la couche dont chaque VPS a besoin.
- Distributions de pare-feu réseau : des systèmes d'exploitation complets bâtis autour d'un moteur de pare-feu, déployés sur une machine dédiée ou une VM pour protéger tout un réseau. OPNsense, pfSense, IPFire. Ils sont destinés à un homelab ou à un LAN de bureau, pas au VPS que vous cherchez à protéger.
- Pare-feu applicatifs web (WAF) : des reverse proxies qui inspectent le trafic HTTP à la recherche d'attaques de la couche web comme l'injection SQL, le XSS et le reste du Top 10 OWASP. SafeLine, BunkerWeb, Haltdos, ModSecurity. Ils sont destinés à une application web ou une API qui tourne sur votre VPS.
- Pare-feu de poste grand public/Windows : des logiciels de bureau qui contrôlent l'accès à Internet par application sous Windows. Nommés ici uniquement pour les exclure.
Pour un VPS, ce sont les catégories 1 et 3 que vous exploitez. La catégorie 2 tourne sur une autre machine. La catégorie 4 tourne sur un autre système d'exploitation. La bonne option de pare-feu gratuite ou open source pour votre situation est celui des outils de la catégorie 1, et éventuellement de la catégorie 3, qui convient à votre distribution et à votre trafic.
Verdict rapide : Pour la plupart des exploitants de VPS, utilisez UFW pour l'hôte, et ajoutez SafeLine si vous faites tourner une application web et voulez un WAF sans monter un serveur de 8 GB.
À retenir de cette section : Sur un VPS, vous choisissez entre des pare-feu d'hôte et des WAF. Les distributions réseau et les outils grand public sont des produits différents pour des machines différentes.
Pare-feu d'hôte : UFW vs nftables vs firewalld
Le pare-feu d'hôte est la seule couche dont vous avez toujours besoin. Il contrôle quels ports de votre serveur acceptent des connexions, et sur un VPS tout neuf il fait la différence entre une machine verrouillée et une machine ouverte. Sur Ubuntu, ce pare-feu est généralement UFW. Sur les distributions de la famille RHEL, c'est firewalld. Sur Debian, UFW est un frontend de pare-feu d'hôte simple, mais le framework de pare-feu par défaut et recommandé de Debian est nftables.
Les trois options se répartissent nettement selon la distribution et le niveau de contrôle dont vous avez besoin :
| Outil | Défaut de la distribution | Interface | Idéal pour | Complexité |
|---|---|---|---|---|
| UFW | Ubuntu, option simple courante sur Debian | CLI | Un VPS unique, le cas courant | Faible |
| firewalld | RHEL, CentOS, AlmaLinux, Rocky | CLI (basé sur les zones) + systemd | Serveurs de la famille RHEL, règles basées sur les zones | Moyen |
| nftables | Le moteur sous les deux | Fichier de configuration / CLI | Des milliers de règles, un contrôle fin, un débit élevé | Élevée |
UFW est l'outil de configuration de pare-feu par défaut d'Ubuntu et un choix simple courant sur Debian, mais le framework de pare-feu par défaut de Debian est nftables. Pour un seul VPS, UFW reste le point de départ le plus facile lorsque vous n'avez besoin que d'un petit ensemble de règles d'autorisation/refus. Sa CLI est la plus simple des trois, les règles persistent automatiquement d'un redémarrage à l'autre, et quelques commandes couvrent tout ce dont la plupart des exploitants de VPS ont besoin. Sa limite tient aux règles avancées : une logique complexe basée sur des ensembles ou une correspondance fine est laborieuse dans UFW.
firewalld est le pare-feu par défaut sur RHEL, CentOS, AlmaLinux et Rocky. Il est basé sur les zones, s'intègre à systemd et est plus capable qu'UFW pour segmenter le trafic par interface ou par niveau de confiance. Cette puissance se paie en temps de configuration. Si vous êtes sur un VPS de la famille RHEL, firewalld est déjà présent et constitue la voie de moindre résistance.
nftables est le moteur au niveau du noyau qui se trouve sous les deux. Vous l'utilisez directement lorsque vous avez réellement besoin de son échelle de règles ou de sa vitesse : des milliers de règles, un filtrage haute performance ou un contrôle qu'un frontend n'expose pas. Selon la comparaison UFW vs nftables de Better Stack, nftables tourne 10 à 100 fois plus vite qu'iptables dès que des milliers de règles sont présentes. Ce chiffre compare nftables à iptables, pas UFW à iptables. Pour un VPS typique avec une poignée de règles d'autorisation, vous ne ressentirez pas cette différence, et la courbe d'apprentissage plus raide ainsi que l'absence d'UI conviviale ne valent pas la peine d'être payées. Il y a aussi un angle sécurité à garder en tête : nftables a connu de vrais bugs du noyau, dont CVE-2025-40206, donc gardez votre noyau à jour. C'est une raison de rester à jour, pas une raison d'éviter le backend que vous faites déjà tourner.
Si vous voulez le mode d'emploi des règles UFW, le guide des commandes UFW de Cloudzy couvre les commandes étape par étape. Cette section porte sur le choix de l'outil, pas sur l'écriture des règles.
Astuce de pro : « iptables est obsolète » ne veut pas dire que vous avez du travail à faire. nftables a remplacé iptables comme backend du noyau, et UFW et firewalld reposent déjà sur nftables sur les distributions modernes. Vos règles UFW existantes n'ont pas besoin d'être réécrites ; la commande frontend est la même, seul le moteur en dessous a changé. Si vous venez d'iptables brut et voulez comprendre la transition, la référence des règles iptables de Cloudzy s'applique toujours, puisque les règles que vous avez écrites se transposent sur le nouveau backend.
À retenir de cette section : Suivez le chemin normal de votre distribution : UFW sur Ubuntu, firewalld sur la famille RHEL, et UFW ou nftables directement sur Debian selon le niveau de contrôle dont vous avez besoin. Ne recourez à nftables directement que lorsque vous avez réellement besoin de son échelle de règles ou de sa vitesse.
Distributions de pare-feu réseau : où OPNsense et pfSense trouvent leur place (et pourquoi pas sur votre VPS)
OPNsense, pfSense et IPFire sont des systèmes d'exploitation complets destinés à une machine dédiée ou une VM qui protège tout un réseau. Ce n'est pas quelque chose que vous faites tourner sur le VPS que vous cherchez à protéger. Ils méritent d'être connus parce que les résultats de recherche vous les mettront sous les yeux : voici donc où ils conviennent et où ils ne conviennent pas.
Quand vous en voudriez réellement un : un homelab ou un LAN de petit bureau, sur du matériel dédié ou une VM avec passthrough de NIC, placé entre votre réseau et Internet. Que vous protégiez une baie de machines de bureau ou un labo personnel que vous exposez à Internet, c'est la catégorie qui fait le travail.
Pourquoi c'est le mauvais outil sur un VPS mutualisé : ces distributions s'attendent à contrôler le trafic entre plusieurs interfaces réseau. Sur un VPS mutualisé, cela suppose un passthrough de NIC, que la plupart des fournisseurs n'exposent pas. Sans lui, vous faites tourner un OS de passerelle réseau sur une machine qui n'a aucun réseau à filtrer. Si vous avez un seul VPS, toute cette catégorie est la mauvaise couche, et UFW plus un WAF est la bonne.
Les trois options gratuites en 2026, en bref :
- OPNsense (sous licence BSD, série CE stable actuelle : 26.1, avec la 26.1.11 sortie le 1er juillet 2026). Entièrement open source, fréquemment mis à jour, et non scindé selon le même modèle CE/Plus que pfSense. Cela en fait le choix d'appliance réseau gratuit le plus clair pour de nombreux utilisateurs qui veulent une distribution de pare-feu entièrement open source sans confusion de niveaux de fonctionnalités.
- pfSense Community Edition (version CE actuelle : 2.8.1, sortie en septembre 2025). Toujours gratuit et open source, avec une documentation et une bibliothèque communautaire plus vastes qu'OPNsense. Le hic est la scission CE/Plus : pfSense CE reste le produit communautaire gratuit, tandis que pfSense Plus est la voie commerciale distincte pour les appliances Netgate, les déploiements cloud et le matériel tiers. Pour les conditions actuelles de Plus, consultez la page pfSense Plus de Netgate plutôt que de vous fier à un chiffre issu d'un article comparatif.
- IPFire (dernière version 2.29 Core Update 202, selon le blog des versions d'IPFire). Une empreinte plus légère que les deux autres, avec une communauté plus restreinte. Un choix raisonnable lorsque vous voulez une appliance plus épurée et que vous n'avez pas besoin de l'étendue des plugins d'OPNsense.
Ces résumés se fondent sur la documentation et les notes de version actuelles. Testez toute distribution de pare-feu réseau dans une VM avant de vous y fier pour un réseau réel.
À retenir de cette section : Si vous avez un réseau à protéger et une machine libre, OPNsense est le choix gratuit en 2026. Si vous avez un seul VPS, toute cette catégorie est la mauvaise couche.
Pare-feu applicatifs web : SafeLine vs BunkerWeb vs Haltdos
Un pare-feu d'hôte contrôle quels ports sont ouverts. Un WAF fait quelque chose de différent : il inspecte le trafic HTTP à la recherche d'attaques de la couche web comme l'injection SQL, le XSS et le reste du Top 10 OWASP, qu'un pare-feu basé sur les ports ne peut pas voir. Si vous faites tourner une application web ou une API sur votre VPS, un WAF est une seconde couche complémentaire. Il ne remplace pas le pare-feu d'hôte ; les deux se situent à des points différents de la pile.
Pour les déploiements sur VPS, commencez par l'empreinte en ressources. Le WAF qui tient dans votre budget de RAM est généralement celui que vous pourrez réellement garder en fonctionnement.
| WAF | Plancher de RAM | Licence | Déploiement | Interface de gestion |
|---|---|---|---|---|
| SafeLine | 1 GB | licence GPL-3.0 | Docker | Interface web |
| BunkerWeb | 8 GB | AGPLv3 | Docker (reverse proxy NGINX) | Interface web |
| Haltdos Community | 2 GB | Édition communautaire gratuite | VM, Docker ou matériel | Interface web |
SafeLine est le point d'entrée le plus léger. Son dépôt GitHub l'identifie comme un WAF/reverse proxy auto-hébergé sous licence GPL-3.0. Une couverture d'installation tierce indique comme minimum 1 cœur CPU, 1 GB de RAM et 5 GB de disque, avec Docker 20.10.14 ou plus récent et Docker Compose 2.0.0 ou plus récent. SafeLine s'appuie sur une analyse sémantique plutôt que de se reposer uniquement sur une liste de règles traditionnelle, mais ses chiffres de taux de détection publiés doivent être considérés comme des affirmations fournies par le projet ou l'éditeur plutôt que comme des résultats de benchmark indépendants. Sur les seules ressources, SafeLine reste le choix pour les petits VPS.
BunkerWeb est le plus complet et le plus lourd. C'est un WAF reverse proxy basé sur NGINX sous AGPLv3, bâti sur ModSecurity avec l'OWASP Core Rule Set. Le coût, c'est la RAM. La documentation de BunkerWeb elle-même indique 2 vCPU et 8 GB de RAM comme spécification minimale recommandée, et 4 vCPU avec 16 GB pour la production avec de nombreux services.
Haltdos Community est la troisième option gratuite. Sa page de l'édition communautaire cite la couverture du Top 10 OWASP, la protection contre les DDoS et les bots, la limitation de débit, des règles intégrées et une interface graphique de gestion web. Sa documentation indique comme prérequis minimaux 2 GB de RAM, 60 GB de disque et au moins 2 vCPU, avec une prise en charge du déploiement sur VM, Docker ou matériel.
SafeLine, BunkerWeb, et Haltdos sont tous disponibles en déploiements en un clic dans la marketplace Cloudzy, et ils tournent aussi manuellement sur n'importe quel VPS. Que vous protégiez une API destinée aux clients ou un service personnel que vous exposez à Internet, la couche est la même ; le choix tient surtout à la quantité de RAM que vous êtes prêt à lui accorder.
À retenir de cette section : Un WAF est une couche distincte de votre pare-feu d'hôte. SafeLine est l'option gratuite la plus légère ; BunkerWeb est le plus complet mais nécessite un serveur bien plus gros.
Si vous avez décidé qu'un WAF a sa place sur votre serveur, c'est à l'étape du déploiement que la marketplace peut faire gagner du temps. SafeLine et BunkerWeb tournent tous deux dans Docker, ce qui suppose généralement un fichier Compose, une configuration de reverse proxy et un débogage au premier lancement. Les options de la marketplace Cloudzy pour SafeLine, BunkerWeb et Haltdos peuvent sauter l'étape d'installation initiale, mais vous devez toujours configurer le routage en amont, le DNS, le TLS, la gestion des faux positifs et les règles de pare-feu d'hôte. La couche de pare-feu d'hôte elle-même est légère et généralement disponible dans les paquets de la distribution ; assurez-vous qu'elle est installée, configurée et activée avant d'exposer des services. Dimensionnez le forfait pour le WAF : 1 GB convient à SafeLine, mais le plancher de 8 GB de BunkerWeb implique une instance plus grande. Vous pouvez déployer un WAF sur un Cloudzy VPS Linux et faire tourner votre pare-feu d'hôte sur la même machine.
Une réserve concernant Docker : si votre application ou votre WAF tourne dans Docker, ne présumez pas qu'UFW à lui seul contrôle chaque port de conteneur publié. Docker crée ses propres règles de pare-feu par défaut, alors liez les conteneurs de backend à localhost ou à des réseaux Docker privés lorsque c'est possible, et n'exposez que les ports côté WAF que vous avez réellement l'intention de publier.
Avez-vous besoin à la fois d'un pare-feu d'hôte et d'un WAF ?
Oui, si vous faites tourner une application web publique : ils protègent des couches différentes. Le pare-feu d'hôte (UFW ou firewalld) contrôle quels ports sont ouverts et constitue la base de tout VPS. Un WAF inspecte le trafic HTTP qui transite par ces ports ouverts à la recherche d'attaques de la couche applicative. Le WAF ne remplace pas le pare-feu d'hôte ; il se place derrière lui.
Le pare-feu d'hôte n'est pas négociable. Chaque VPS en a besoin, application web ou non, car c'est lui qui empêche le reste d'Internet d'atteindre des services que vous n'avez jamais voulu exposer. Le WAF est conditionnel. Ajoutez-le lorsque vous servez du trafic HTTP ou HTTPS susceptible d'être attaqué au niveau de la couche applicative : une API publique, un CMS, tout ce qui accepte des entrées utilisateur via le web. Un site statique ou un service purement interne derrière un VPN peut n'avoir aucun besoin d'un WAF ; dans ce cas, le pare-feu d'hôte seul est la bonne réponse, et ajouter un WAF est une charge dont vous n'avez pas besoin. Adaptez les couches à ce que vous faites réellement tourner, pas à une liste de contrôle.
À retenir de cette section : Le pare-feu d'hôte est la base de tout VPS. Ajoutez un WAF lorsque vous exposez une application web à Internet.
Foire aux questions
iptables est-il obsolète sous Linux ?
En pratique, oui. nftables a remplacé iptables comme backend de filtrage de paquets du noyau sur les Linux modernes. Mais il s'agit d'un changement de backend, pas d'un appel à l'action. UFW et firewalld reposent déjà sur nftables sur les distributions actuelles, et vos règles UFW existantes n'ont pas besoin d'être réécrites. Les commandes frontend restent inchangées ; seul le moteur en dessous a évolué.
pfSense est-il encore gratuit en 2026 ?
Oui. pfSense Community Edition, actuellement en 2.8.1, est gratuit et open source. Le hic est la scission CE/Plus : pfSense CE reste le produit communautaire gratuit, tandis que pfSense Plus est la voie commerciale distincte pour les appliances Netgate, les déploiements cloud et le matériel tiers. Pour les conditions actuelles de Plus et tout coût d'abonnement, consultez la page pfSense Plus de Netgate plutôt que de vous fier à un chiffre issu d'une comparaison tierce.
Puis-je faire tourner pfSense ou OPNsense sur un VPS ?
Techniquement possible, mais architecturalement inadapté sur un VPS mutualisé. Ce sont des systèmes d'exploitation de passerelle réseau qui s'attendent à contrôler le trafic entre plusieurs interfaces réseau, ce qui nécessite un passthrough de NIC que la plupart des fournisseurs de VPS n'exposent pas. Sur un VPS unique, ce dont vous avez réellement besoin, c'est d'un pare-feu d'hôte (UFW ou firewalld) et, pour les applications web, d'un WAF.
Ai-je besoin d'un WAF si j'ai déjà un pare-feu sur mon serveur Linux ?
Ils protègent des couches différentes, donc cela dépend de ce que vous faites tourner. Un pare-feu d'hôte contrôle quels ports sont ouverts ; un WAF inspecte le trafic HTTP qui les traverse à la recherche d'attaques de la couche web comme l'injection SQL et le XSS. Si vous servez une application web ou une API publique, ajoutez un WAF par-dessus le pare-feu d'hôte. Si vous ne faites tourner qu'un site statique ou un service interne, le pare-feu d'hôte seul suffit.
Quel est le meilleur WAF gratuit pour un petit VPS Linux ?
SafeLine est l'option gratuite la plus légère, avec un minimum de 1 GB de RAM en fonctionnement dans Docker, ce qui convient à un petit VPS. BunkerWeb est plus complet mais nécessite 8 GB de RAM, ce n'est donc pas un déploiement pour petit serveur. Haltdos Community est une troisième option gratuite dotée d'une interface web ; consultez sa documentation pour connaître les prérequis en ressources actuels avant de dimensionner votre serveur.
