Une règle de pare-feu cloud est une instruction qui identifie le trafic selon un 5-tuple (adresse source, adresse de destination, protocole, port source et port de destination) puis l'autorise ou le rejette. La décision la plus importante que vous prenez avec un pare-feu, quel qu'il soit, est la politique par défaut : tout refuser par défaut, puis n'autoriser explicitement que ce dont vous avez besoin. Tout le reste de cet article n'est qu'un ensemble de détails qui viennent se greffer sur ce principe.
Sur quoi porte réellement une règle de pare-feu
Chaque paquet possède une IP source, une IP de destination, un numéro de protocole (TCP, UDP, ICMP, etc.) et, pour TCP et UDP, un port source et un port de destination. Les pare-feu cloud (security groups AWS, NSG Azure, règles de pare-feu VPC GCP) évaluent tous les règles sur ce même 5-tuple, même si leurs interfaces diffèrent. Lorsque vous écrivez une règle comme « autoriser TCP 443 depuis 0.0.0.0/0 », vous demandez au pare-feu de faire correspondre tout paquet utilisant le protocole TCP, le port de destination 443 et n'importe quelle adresse source.
ICMP (le protocole utilisé par ping et par la découverte du MTU de chemin) est souvent traité comme une catégorie à part, distincte de TCP/UDP : il lui faut donc sa propre règle d'autorisation explicite si vous voulez que des outils de diagnostic comme ping fonctionnent à travers le pare-feu.
Default-deny ou default-allow : refuser ou autoriser par défaut
Default-deny signifie que si aucune règle ne correspond au trafic, celui-ci est rejeté. Default-allow signifie l'inverse : tout ce qui n'est pas explicitement bloqué passe. Le default-deny est la bonne pratique reconnue pour le trafic entrant chez tous les grands fournisseurs cloud, car un service oublié ou mal configuré est alors inaccessible par défaut au lieu d'être exposé par défaut.
La plupart des fournisseurs configurent déjà les nouveaux groupes de pare-feu en refus total en entrée et autorisation totale en sortie :
- Security groups AWS : les nouveaux groupes personnalisés refusent tout le trafic entrant par défaut, autorisent tout le trafic sortant par défaut et ne prennent en charge que des règles d'autorisation (pas de refus explicite ; le trafic sans correspondance est implicitement rejeté).
- NSG Azure : ils sont livrés avec des règles par défaut qui autorisent le trafic VNet-à-VNet et celui du load balancer, refusent tout le reste en entrée et autorisent la sortie vers le VNet et Internet. Ces règles par défaut ne peuvent pas être supprimées, mais peuvent être remplacées par une règle personnalisée de priorité supérieure.
- Règles de pare-feu VPC GCP : chaque réseau dispose d'une règle implicite autorisant tout le trafic sortant et d'une règle implicite refusant tout le trafic entrant, à la priorité la plus basse, que vos règles explicites de priorité supérieure viennent remplacer.
À retenir en pratique : ne vous fiez pas au « ce n'était sans doute pas grave de laisser ça ouvert ». Partez d'une configuration fermée et ouvrez les ports un par un, au fur et à mesure que les services en ont besoin.
Trafic entrant et sortant : pourquoi les deux sens comptent
Les règles entrantes contrôlent ce qui peut atteindre votre serveur. Les règles sortantes (egress) contrôlent ce que votre serveur peut atteindre sur Internet. La plupart des gens consacrent tout leur temps aux règles entrantes et ignorent complètement le trafic sortant. C'est une erreur, car un egress non restreint est précisément ce qui permet à un serveur compromis d'exfiltrer des données ou de contacter un serveur de commande et de contrôle.
La nécessité d'écrire des règles distinctes pour chaque sens dépend du caractère stateful ou stateless du pare-feu :
- Les pare-feu stateful (security groups AWS, NSG Azure, règles VPC GCP pour les connexions établies) suivent l'état de la connexion à l'aide des flags TCP (SYN, ACK, FIN). Si vous autorisez une requête entrante, le trafic de réponse correspondant est automatiquement autorisé en sortie : aucune règle miroir n'est nécessaire.
- Les pare-feu stateless (les network ACL AWS en sont l'exemple classique) évaluent chaque paquet indépendamment, dans l'ordre numérique : vous devez donc écrire des règles explicites pour la requête comme pour la réponse, y compris pour les ports éphémères élevés utilisés au retour.
UDP ne possède aucun état de connexion (il est sans connexion par conception) : les pare-feu qui prétendent suivre des « sessions » UDP s'appuient en réalité sur des délais d'expiration et des heuristiques, et non sur une véritable table d'état comme pour TCP.
NoteLes security groups AWS ne prennent en charge que des règles d'autorisation, combinées par un OU logique sans aucun ordre : la notion de priorité des règles n'existe pas. Les network ACL, les NSG Azure et les règles de pare-feu GCP utilisent au contraire une priorité numérotée, où le numéro le plus bas l'emporte.
Les ports laissés ouverts par erreur
La plupart des intrusions évitables découlent d'une poignée d'erreurs prévisibles, et non de failles zero-day. Les coupables habituels :
| Port | Service | Pourquoi c'est risqué de le laisser ouvert à 0.0.0.0/0 |
|---|---|---|
| 22 | SSH | Cible d'attaques par force brute ; doit être limité à des IP connues ou à un bastion |
| 3389 | RDP | Même problème que SSH, massivement scanné par des bots |
| 3306 / 5432 | MySQL / PostgreSQL | Une base de données ne doit jamais être exposée à Internet ; utilisez un réseau privé ou un VPN |
| 6379 | Redis | Souvent déployé sans aucune authentification ; une cible de choix pour les botnets de minage de cryptomonnaie |
| 27017 | MongoDB | Même schéma que Redis : public et sans authentification, une erreur de configuration fréquente |
| 9200 | Elasticsearch | Souvent exposé pendant les tests et jamais verrouillé ensuite |
La solution est presque toujours la même : limitez la source de la règle à l'IP de votre bureau, à une plage VPN ou à un sous-réseau privé au lieu de 0.0.0.0/0, ou placez le service derrière un bastion et supprimez complètement la règle publique. Une règle ouverte « temporairement » pendant une session de débogage est justement celle qui a le plus de chances d'être encore là un an plus tard.
Exemple concret : sécuriser un serveur web
Un serveur web public classique n'a besoin que de trois règles d'autorisation entrantes, tout le reste étant refusé par défaut :
Allow TCP 443 from 0.0.0.0/0 # HTTPS
Allow TCP 80 from 0.0.0.0/0 # HTTP (redirect to 443)
Allow TCP 22 from 203.0.113.0/24 # SSH, office range only
Deny all * from 0.0.0.0/0 # implicit or explicit default-deny
Le trafic sortant peut généralement rester plus ouvert (autoriser tout l'egress est courant pour les serveurs web qui doivent appeler des API externes, récupérer des mises à jour ou envoyer des e-mails), mais si le serveur n'a aucune raison de communiquer avec des hôtes arbitraires, restreignez aussi l'egress : c'est ce qui limite réellement l'étendue des dégâts si la machine est un jour compromise.
Ordre d'évaluation des règles selon le fournisseur
C'est le point qui piège le plus de monde : les security groups AWS n'ont aucun ordre. Chaque règle d'autorisation est évaluée indépendamment et les résultats sont combinés par un OU logique, si bien que l'ordre des règles dans la console est purement cosmétique. Les NSG Azure et les règles de pare-feu GCP utilisent au contraire une priorité numérique où le numéro le plus bas l'emporte et où l'évaluation s'arrête à la première correspondance. Les network ACL AWS fonctionnent de la même façon : numérotées, première correspondance, arrêt. Si vous êtes habitué au modèle d'un fournisseur et passez à un autre, c'est le détail qui crée le plus de confusion : vérifiez-le explicitement plutôt que de le supposer.
Garder des règles de pare-feu cohérentes entre fournisseurs
Faire tourner des workloads sur AWS, Azure, GCP et quelques fournisseurs de VPS implique de dupliquer la logique du pare-feu dans trois ou quatre consoles différentes, chacune avec ses particularités en matière de valeurs par défaut, de priorités et de limites de règles. C'est exactement le type de dérive qui laisse une règle obsolète ouverte chez un fournisseur longtemps après qu'elle a été nettoyée partout ailleurs. Consultez la dérive d'infrastructure expliquée pour voir comment cela se produit en pratique. La gestion des pare-feu d'InfraNest vous offre un point unique pour définir et auditer les règles de tous les serveurs cloud que vous exploitez, de sorte qu'une posture default-deny devient quelque chose que vous pouvez réellement vérifier, et non simplement supposer.
Si vous configurez un nouveau serveur aujourd'hui, partez d'une politique entrante default-deny, n'ouvrez que les ports dont vous pouvez justifier l'usage et auditez l'egress au moins une fois : c'est le sens que presque tout le monde oublie. Découvrez les pare-feu pour serveurs cloud pour gérer tout cela de façon cohérente entre fournisseurs.
Questions fréquentes
#Quelle est la différence entre un pare-feu stateful et un pare-feu stateless ?
Un pare-feu stateful suit l'état des connexions à l'aide des flags TCP : autoriser le trafic entrant autorise donc automatiquement le trafic de retour correspondant, sans règle distincte. Un pare-feu stateless, comme les network ACL AWS, évalue chaque paquet indépendamment et nécessite des règles explicites pour les deux sens.
#Faut-il aussi restreindre le trafic sortant (egress) ?
Oui : un egress non restreint est ce qui permet à un serveur compromis d'exfiltrer des données ou de contacter un serveur de commande et de contrôle. Limiter les règles sortantes aux seules destinations dont un service a réellement besoin réduit donc les dégâts en cas d'intrusion.
#Pourquoi ne faut-il pas exposer un port de base de données comme 3306 ou 5432 à Internet ?
Les bases de données sont des cibles fréquentes des scans automatisés et des attaques par force brute, et de nombreuses intrusions proviennent d'un port de base de données laissé ouvert à 0.0.0.0/0. Limitez plutôt l'accès à la base de données à un réseau privé, un VPN ou une plage d'IP restreinte.
#L'ordre des règles compte-t-il dans les pare-feu cloud ?
Cela dépend du fournisseur : les security groups AWS n'ont aucun ordre (toutes les règles d'autorisation sont combinées par un OU logique), tandis que les NSG Azure, les règles de pare-feu GCP et les network ACL AWS utilisent tous une priorité numérotée avec évaluation à la première correspondance : l'ordre y est donc important.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
