Utilisez un pare-feu cloud comme première ligne de défense pour tout ce qui est exposé à Internet, et gardez un pare-feu hôte actif en dessous, comme seconde couche indépendante. Les pare-feu cloud (groupes de sécurité, groupes de sécurité réseau, filtres de paquets au niveau du cloud) se situent à l'extérieur du serveur et bloquent le trafic avant même qu'il ne consomme du CPU, de la bande passante ou un socket en écoute. Les pare-feu hôtes (iptables, nftables, ufw, Pare-feu Windows Defender) s'exécutent sur la machine elle-même et constituent votre dernière ligne de défense si la couche réseau est mal configurée ou contournée.
En résumé : le pare-feu cloud pour le contrôle du périmètre et la réduction du rayon d'impact, le pare-feu hôte pour la défense en profondeur et tout ce que la couche cloud ne voit pas (trafic loopback, règles entre conteneurs, filtrage selon les processus). La plupart des environnements de production ont besoin des deux.
Quelle différence entre un pare-feu cloud et un pare-feu hôte ?
Un pare-feu cloud est appliqué par l'infrastructure réseau du fournisseur, en amont de l'interface réseau de votre serveur. Le trafic refusé ne touche jamais le CPU ni la carte réseau de votre instance : il est rejeté au niveau de l'hyperviseur ou de la couche réseau définie par logiciel. Les pare-feu cloud sont donc peu coûteux à faire tourner (aucune ressource serveur consommée) et efficaces contre les attaques volumétriques et les simples scans de ports, puisque ce bruit n'atteint jamais votre machine.
Un pare-feu hôte est un logiciel qui s'exécute dans le système d'exploitation et inspecte les paquets une fois arrivés sur l'interface réseau. Il est plus flexible : vous pouvez filtrer par processus, par utilisateur ou selon une logique applicative, et il fonctionne de la même manière que le serveur soit en bare metal, une VM cloud ou sans aucun pare-feu cloud devant lui. En revanche, il consomme un peu de CPU par paquet, et si l'OS est compromis ou mal configuré, un attaquant peut potentiellement le désactiver.
| Pare-feu cloud | Pare-feu hôte | |
|---|---|---|
| Point d'application | Couche réseau/hyperviseur | Dans l'OS |
| Coût en ressources | Aucun sur l'instance | Légère surcharge CPU/mémoire |
| Résiste à une compromission de l'OS | Oui | Non |
| Granularité | IP, port, protocole, parfois tags | Processus, utilisateur, état de connexion, IP, port |
| Fonctionne sans fournisseur cloud | Non | Oui |
| Outil type | Groupes de sécurité, NSG, règles de pare-feu VPC | iptables, nftables, ufw, firewalld |
Quand utiliser un pare-feu cloud ?
Utilisez un pare-feu cloud dès que votre serveur possède une adresse IP publique. Votre règle par défaut doit être : refuser tout le trafic entrant sauf les ports dont vous avez explicitement besoin, appliquée au niveau réseau avant que quoi que ce soit n'atteigne l'instance.
Le pare-feu cloud est l'outil adapté lorsque vous voulez :
- Restreindre l'accès SSH ou RDP à une liste fixe d'adresses IP de bureau ou de VPN, plutôt que d'exposer les ports d'administration à tout Internet.
- Segmenter les tiers d'une application — par exemple, n'autoriser vos serveurs web à joindre vos serveurs de base de données que sur le port de la base, et bloquer tout le reste entre les sous-réseaux.
- Absorber les scans et le trafic d'attaque peu sophistiqué sans y consacrer de CPU serveur. Un paquet rejeté en amont ne touche jamais la pile TCP de votre instance.
- Appliquer des règles cohérentes sur une flotte de serveurs en attachant le même jeu de règles (souvent appelé groupe de sécurité ou politique de pare-feu) à chaque instance d'un même rôle, plutôt que de configurer chaque machine individuellement.
- Fermer ou ouvrir rapidement un port sur toute la flotte lors d'un incident, sans vous connecter en SSH à chaque serveur.
Si vous exploitez plusieurs serveurs cloud chez différents fournisseurs, maintenir ces jeux de règles cohérents à la main devient vite source d'erreurs : une règle de pare-feu correcte dans la console d'un fournisseur peut être oubliée chez un autre. Gérer vos serveurs cloud depuis un tableau de bord unique permet d'auditer bien plus facilement les ports réellement ouverts sur l'ensemble de votre flotte, plutôt que de supposer que chacun a pensé à mettre à jour toutes les consoles de la même façon.
Quand utiliser un pare-feu hôte (ou les deux) ?
Utilisez un pare-feu hôte sur chaque serveur, qu'un pare-feu cloud soit en place ou non. C'est votre solution de repli si une règle cloud est assouplie par erreur, si le serveur migre plus tard vers du bare metal ou un autre fournisseur sans contrôles équivalents, ou si vous avez besoin d'une logique de filtrage que la couche cloud ne sait pas exprimer — limitation de débit par IP source, filtrage par processus/UID, ou gestion du trafic est-ouest entre conteneurs sur un même hôte.
Utilisez les deux lorsque :
- Le serveur est exposé à Internet et traite des données sensibles — données de paiement, authentification, dossiers clients. Avec la défense en profondeur, une erreur de configuration ne se transforme pas en brèche.
- Vous gérez le serveur au sein d'une flotte où les règles de pare-feu cloud peuvent dériver ou être écrasées par quelqu'un ayant accès à la console.
- Vous avez besoin d'un suivi de l'état des connexions ou d'une journalisation plus faciles à configurer et à inspecter en local que via une console cloud.
N'utilisez qu'un pare-feu hôte lorsqu'aucun pare-feu au niveau cloud n'est réellement disponible — certains petits fournisseurs et hébergeurs dédiés/bare metal n'en proposent pas — ou lorsque le serveur n'a aucune IP publique et vit entièrement dans un réseau privé que vous contrôlez déjà au niveau du routeur.
WarningNe vous reposez jamais uniquement sur le pare-feu cloud en laissant le pare-feu hôte désactivé « parce que le cloud bloque déjà ». Une seule règle mal appliquée, une modification de débogage temporaire que quelqu'un oublie d'annuler, ou un serveur déplacé dans un nouveau groupe de sécurité aux paramètres par défaut plus permissifs, et votre unique couche de protection disparaît.
Règles de pare-feu par défaut recommandées
Une configuration de départ raisonnable pour un serveur web classique, appliquée à la fois au niveau cloud et au niveau hôte :
# Cloud firewall (security group) — inbound
Allow tcp/22 from <your office/VPN IP only>
Allow tcp/80 from 0.0.0.0/0
Allow tcp/443 from 0.0.0.0/0
Deny all from 0.0.0.0/0
# Host firewall (ufw) — mirrors and backs up the above
ufw default deny incoming
ufw default allow outgoing
ufw allow from <your office/VPN IP> to any port 22
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
Quelques habitudes pour que tout cela reste gérable dans la durée :
- Refuser par défaut le trafic entrant, puis autoriser explicitement uniquement ce qui est nécessaire — ne jamais tout autoriser par défaut en essayant de bloquer ce qui est malveillant.
- Ne jamais exposer les ports de base de données (5432, 3306, 27017, etc.) à 0.0.0.0/0, à aucun des deux niveaux ; les restreindre aux serveurs applicatifs qui en ont besoin.
- Journaliser les connexions refusées au niveau hôte pendant un certain temps après chaque modification, afin de repérer une règle trop restrictive avant qu'elle ne casse quelque chose en production.
- Revoir les règles chaque fois qu'un serveur change de rôle — une vieille règle « tout autoriser pour les tests » oubliée sur une machine qui passe ensuite en production est une façon courante d'affaiblir discrètement un périmètre.
Avoir de la visibilité sur tous vos fournisseurs
Le plus difficile dans l'hygiène des pare-feu n'est pas d'écrire les règles, mais de savoir d'un coup d'œil quels ports sont réellement ouverts sur chacun de vos serveurs, surtout lorsque vous êtes réparti sur plusieurs fournisseurs cloud. Considérez votre configuration de pare-feu comme quelque chose à auditer régulièrement, et non comme un réglage fait une fois pour toutes.
Si vous gérez des serveurs sur plusieurs clouds et souhaitez un endroit unique pour voir ce qui est réellement exposé, découvrez la fonctionnalité serveurs cloud d'InfraNest.
Questions fréquentes
#Un pare-feu cloud peut-il remplacer entièrement un pare-feu hôte ?
Pas en toute sécurité. Un pare-feu cloud protège contre l'exposition au niveau réseau, mais s'il est un jour mal configuré, assoupli, ou si le serveur migre vers une autre infrastructure, le pare-feu hôte devient votre seule couche de protection restante.
#Les pare-feu cloud ralentissent-ils les performances réseau ?
Non. Comme ils sont appliqués en amont, au niveau du réseau ou de l'hyperviseur, le trafic bloqué n'atteint jamais le CPU ni la pile réseau de votre serveur : il n'y a donc aucune surcharge par paquet sur l'instance elle-même.
#Les ports de base de données doivent-ils être ouverts sur Internet ?
Non. Les ports de base de données ne doivent être accessibles que depuis les serveurs applicatifs qui en ont besoin, avec une restriction à la fois au niveau du pare-feu cloud et du pare-feu hôte — jamais exposés à 0.0.0.0/0.
#Quelle politique de pare-feu par défaut adopter pour un nouveau serveur ?
Refuser par défaut tout le trafic entrant, puis autoriser explicitement uniquement SSH depuis des IP de confiance et les ports réellement servis par votre application (généralement 80 et 443), de façon cohérente au niveau cloud et au niveau hôte.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
