Règles de pare-feu qui marchent vraiment : erreurs courantes et meilleures configurations par défaut

Les bonnes pratiques de configuration des règles de pare-feu ne se résument pas à bloquer le trafic malveillant - il s'agit d'écrire des règles suffisamment précises pour stopper les attaquants sans casser les services dont ton équipe a besoin. La plupart des erreurs de configuration suivent des schémas prévisibles : des règles trop larges, un trafic sortant complètement incontrôlé, ou des politiques "tout autoriser par défaut" qui étaient censées être temporaires et n'ont jamais été corrigées. Ce guide passe en revue les vraies erreurs que font les administrateurs système et les développeurs, et les configurations plus intelligentes qui les remplacent.

Règles entrantes et sortantes expliquées

Tout pare-feu évalue le trafic dans deux directions, et les traiter comme une seule préoccupation est l'une des erreurs les plus fréquentes.

Les règles entrantes contrôlent le trafic qui arrive sur ton serveur ou ton réseau depuis l'extérieur. Quand quelqu'un se connecte à ton serveur web sur le port 80 ou 443, c'est du trafic entrant. Quand un attaquant sonde le port 22 à la recherche d'un accès SSH, c'est aussi du trafic entrant. Tes règles entrantes décident si ces connexions passent ou non.

Les règles sortantes contrôlent le trafic qui quitte ton serveur. Un serveur compromis qui contacte une infrastructure de commande et contrôle, une application mal configurée qui fuite des données vers un endpoint externe, ou un conteneur qui télécharge des paquets depuis un registre inattendu - tout cela est du trafic sortant. La plupart des équipes configurent soigneusement le trafic entrant et laissent le trafic sortant complètement ouvert, ce qui est une erreur grave.

Dans les environnements cloud comme AWS Security Groups, les règles entrantes et sortantes sont configurées séparément. Sous Linux iptables ou nftables , elles correspondent aux chaînes INPUT et OUTPUT. Dans le pare-feu Windows, elles sont littéralement étiquetées "Règles de trafic entrant" et "Règles de trafic sortant" dans l'interface graphique. Le concept est universel - l'implémentation varie selon la plateforme.

Erreurs courantes de configuration de pare-feu

1. Autoriser 0.0.0.0/0 sur les ports sensibles

C'est le schéma le plus dangereux en matière de configuration de pare-feu. Laisser l'ensemble d'internet accéder à ces ports, c'est chercher les ennuis :

Le cas MongoDB mérite une attention particulière. Des dizaines de milliers de bases de données ont été effacées et prises en otage entre 2017 et 2019 parce que des instances MongoDB étaient accessibles publiquement sans aucune authentification. Le vérificateur de liste noire d'adresses IP est un bon rappel que la surveillance de l'exposition est essentielle - car "personne ne va le trouver" n'est pas une stratégie de sécurité.

2. Ignorer le trafic sortant (egress)

Laisser le trafic sortant totalement sans restriction signifie qu'un hôte compromis peut communiquer librement avec l'infrastructure d'un attaquant, exfiltrer des données ou participer à un botnet. Un serveur qui héberge une application web n'a aucune raison légitime d'initier des connexions sortantes vers des adresses IP arbitraires sur des ports arbitraires. Limiter l'egress à ce qui est strictement nécessaire - ton résolveur DNS, ton dépôt de paquets, tes endpoints d'API - réduit considérablement ce qu'un attaquant peut faire même après avoir obtenu un accès.

3. Erreurs d'ordre des règles

Considère cette configuration iptables :

# BAD: This allow-all rule fires first
-A INPUT -j ACCEPT
-A INPUT -s 203.0.113.0/24 -p tcp --dport 22 -j DROP

La règle DROP pour SSH depuis ce sous-réseau est totalement inutile parce que chaque paquet rencontre d'abord la règle ACCEPT. La solution consiste à placer les règles spécifiques avant les règles générales, et à mettre le refus par défaut tout à la fin.

4. Plages de ports trop larges

Des règles comme "autoriser TCP 1024-65535 en entrée" sont courantes dans les configurations héritées et n'ont pratiquement aucune valeur en tant que contrôle de sécurité. Si ton application utilise le port 8080, écris une règle pour le port 8080. Si tu as besoin d'une plage pour le FTP passif, documente exactement la plage configurée sur ton serveur et restreins-toi à celle-ci. Les plages larges existent parce que quelqu'un ne voulait pas chercher le bon port - pas parce qu'elles étaient nécessaires.

5. Laisser en place les règles "tout autoriser" par défaut

Les fournisseurs cloud appliquent souvent des règles permissives lors du provisionnement. Le groupe de sécurité par défaut d'AWS autorise tout le trafic sortant. Les nouvelles VM Azure reçoivent une règle entrante "AllowAzureLoadBalancerInBound" qui est acceptable, mais la règle sortante par défaut autorise tout. Ces paramètres par défaut sont conçus pour démarrer rapidement, pas pour la production. Dès que tu passes une charge de travail en production, passe en revue et renforce chaque règle par défaut.

6. Aucune journalisation sur les règles de refus

Un pare-feu qui abandonne silencieusement le trafic ne t'apprend rien. Sans journalisation sur tes règles de refus, tu ne peux pas distinguer un attaquant qui sonde tes ports d'un service légitime mal configuré. Active la journalisation au moins sur tes règles de refus par défaut pour avoir une base de référence de ce qui est bloqué.

Des valeurs par défaut plus intelligentes qui fonctionnent vraiment

La structure de politique de sécurité réseau suivante fonctionne dans la plupart des environnements et te donne un point de départ solide à ajuster, plutôt qu'un désordre permissif à nettoyer.

Règles entrantes

• Par défaut : REFUSER tout le trafic entrant. Commence sans rien d'autorisé et ouvre explicitement uniquement ce qui est nécessaire.
• Port 80 (HTTP) et 443 (HTTPS) : Autoriser depuis 0.0.0.0/0 uniquement si c'est un serveur web accessible au public. S'il est uniquement interne, restreins à ta plage d'IP interne.
• Port 22 (SSH) : Autoriser UNIQUEMENT depuis des adresses IP spécifiques ou des blocs CIDR - l'IP de ton bureau, le nœud de sortie de ton VPN, ton hôte bastion. Jamais depuis 0.0.0.0/0.
• Port 3389 (RDP) : Identique au SSH - IP spécifiques uniquement, ou mieux encore, place-le derrière un VPN et ne l'expose pas du tout à internet.
• Port 3306 (MySQL) et 5432 (PostgreSQL) : Autoriser uniquement depuis les IP privées de tes serveurs applicatifs. Ces ports ne doivent jamais être accessibles depuis internet public.
• ICMP (ping) : Autoriser depuis les plages de confiance pour les diagnostics. Le bloquer entièrement rend le dépannage pénible sans apporter de bénéfice de sécurité significatif.

Règles sortantes

• Port 53 (DNS) : Autoriser uniquement vers tes résolveurs DNS désignés (par exemple, le résolveur interne de ton VPC ou une IP spécifique comme 1.1.1.1).
• Port 80 et 443 : Autoriser vers des destinations connues - tes dépôts de paquets, tes APIs, ton CDN. Si tu peux les énumérer, fais-le.
• Port 25 (SMTP) : Bloquer le SMTP sortant sauf si ce serveur est explicitement un serveur de messagerie. Un serveur compromis qui envoie du spam est un indicateur courant de compromission.
• Tout le reste : REFUSER par défaut.

Voici un exemple minimal avec iptables appliquant cette approche pour un serveur web :

# Flush existing rules
iptables -F

# Default policies: deny all inbound and outbound
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Allow established/related connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Inbound: HTTP and HTTPS from anywhere (public web server)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Inbound: SSH only from your office IP
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.50 -j ACCEPT

# Outbound: DNS to internal resolver
iptables -A OUTPUT -p udp --dport 53 -d 10.0.0.2 -j ACCEPT

# Outbound: HTTPS for package updates
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

# Log dropped inbound packets
iptables -A INPUT -j LOG --log-prefix "DROPPED-IN: " --log-level 4

Pour mieux comprendre comment le filtrage de ports fonctionne au niveau du protocole, la spécification TCP dans la RFC 793 explique précisément ce qui se passe lors de l'établissement d'une connexion - ce que ton pare-feu intercepte lorsqu'il évalue les règles contre les paquets entrants.

Des règles distinctes pour Dev, Staging et Prod

L'une des bonnes habitudes de configuration de pare-feu les plus sous-estimées est de traiter chaque environnement comme distinct, avec son propre ensemble de règles. Utiliser le même groupe de sécurité ou la même politique de pare-feu entre dev et prod, c'est ainsi que des ports de débogage "temporaires" finissent exposés en production.

Une façon pratique de structurer cela :

• Dev : Trafic entrant plus permissif depuis la plage d'IP de ton équipe. Ports 8080, 8443 et autres ports de développement ouverts. Ports de base de données accessibles depuis les machines des développeurs. Journalisation optionnelle.
• Staging : Reproduire les règles de prod aussi fidèlement que possible. L'objectif est de détecter les problèmes liés au pare-feu avant qu'ils n'atteignent la production. Ajouter l'accès pour les IP de ton équipe QA.
• Prod : Règles les plus strictes. Aucun port de débogage. Aucun accès direct à la base de données depuis l'extérieur du sous-réseau privé. Toutes les règles de refus journalisées. SSH restreint à un hôte bastion ou à un VPN uniquement.

Étiquette tes règles de pare-feu avec l'environnement auquel elles appartiennent. Dans AWS, utilise des tags de ressources sur les groupes de sécurité. Dans Terraform ou d'autres outils IaC, utilise des ensembles de règles pilotés par des variables pour que les règles dev et prod partagent la même structure mais des valeurs différentes. Cela facilite considérablement les audits.

Tu peux aussi utiliser notre outil ping pour vérifier rapidement si un hôte dans un environnement donné est joignable au niveau réseau avant de plonger dans des vérifications spécifiques aux ports.

Vérifier ce qui est réellement exposé

Écrire des règles de pare-feu ne représente que la moitié du travail. L'autre moitié consiste à confirmer que ce que tu voulais bloquer est bien bloqué, et que ce que tu voulais autoriser est bien accessible. C'est là que beaucoup d'équipes sautent une étape et livrent des systèmes mal configurés.

Après avoir appliqué des modifications à ta configuration de pare-feu, effectue une vérification externe des ports depuis l'extérieur de ton réseau. Cela simule ce qu'un attaquant verrait - pas ce que ta supervision interne pense être exposé.

Ce qu'il faut vérifier après chaque modification du pare-feu :

• Port 22 (SSH) : doit afficher FERMÉ ou TIMEOUT depuis toute IP qui n'est pas sur ta liste d'autorisation.
• Port 3306 (MySQL) et 5432 (PostgreSQL) : ne doivent jamais être OUVERTS depuis internet public.
• Port 3389 (RDP) : doit être FERMÉ ou TIMEOUT sauf si tu l'as délibérément exposé avec des restrictions d'IP.
• Port 80 et 443 : doivent être OUVERTS sur les serveurs web accessibles au public.
• Tout port applicatif personnalisé : vérifie qu'il correspond à ton intention - ouvert là où c'est nécessaire, fermé partout ailleurs.

Tu peux aussi utiliser notre outil de résolution DNS pour confirmer que le nom d'hôte que tu testes résout bien vers l'IP attendue avant de lancer des vérifications de ports - utile dans les environnements où les enregistrements DNS et les adresses IP réelles des serveurs ne correspondent pas toujours.

Vois exactement quels ports sont exposés après avoir appliqué tes règles de pare-feu

Utilise notre vérificateur de ports gratuit pour tester si SSH (22), RDP (3389), MySQL (3306), PostgreSQL (5432) et d'autres ports sensibles sont réellement ouverts ou fermés depuis l'extérieur - pour confirmer que tes règles de pare-feu fonctionnent comme prévu, et pas seulement qu'elles sont correctement écrites.

Vérifier tes ports ouverts →