Comment configurer les règles de pare-feu : un guide technique complet

Une règle de pare-feu est une entrée de politique qui indique à un moteur de pare-feu d’autoriser, de refuser ou de journaliser le trafic réseau en fonction de critères définis tels que l’adresse IP source/destination, le numéro de port, le protocole de transport et la direction du trafic. Des règles de pare-feu correctement configurées constituent la couche d’application principale entre votre infrastructure et l’internet public, ce qui en fait le contrôle de sécurité le plus déterminant sur tout serveur ou périphérique réseau.

Ce guide couvre l’architecture des règles de pare-feu, UFW sur Linux, firewalld, Windows Defender Firewall, nftables, et les pratiques opérationnelles qui distinguent un environnement renforcé d’un environnement mal configuré.

Ce que les règles de pare-feu contrôlent réellement

Chaque règle d’un ensemble de règles de pare-feu est évaluée par rapport à cinq attributs fondamentaux de paquet, communément appelés le 5-tuple :

• Adresse IP source — l’hôte ou le sous-réseau d’origine (ex. : 192.168.1.0/24)
• Adresse IP de destination — l’hôte ou la plage cible
• Port source — le port éphémère du côté initiateur
• Port de destination — le port de service du côté récepteur (ex. : 443 pour HTTPS, 22 pour SSH)
• Protocole — TCP, UDP, ICMP, ou numéro de protocole

Au-delà du 5-tuple, les pare-feux à états suivent également l’état de connexion (NEW, ESTABLISHED, RELATED, INVALID), ce qui leur permet d’autoriser le trafic de retour pour les connexions sortantes sans écrire de règles entrantes explicites pour chaque réponse.

Pare-feux à états vs. pare-feux sans état

Pour pratiquement tous les déploiements de serveurs — y compris l’Hébergement VPS et les Serveurs Dédiés — un pare-feu hôte à états est le choix par défaut approprié.

Traitement des règles de pare-feu : le problème d’ordre

L’une des sources les plus courantes de mauvaise configuration est la mauvaise compréhension de l’ordre des règles. La plupart des pare-feux évaluent les règles de haut en bas et appliquent la première règle correspondante, puis s’arrêtent. Cela signifie :

• Une règle ALLOW générale placée au-dessus d’une règle DENY spécifique la remplacera silencieusement.
• Un DENY ALL en haut d’une chaîne bloque tout, quelle que soit la suite.
• Les règles dupliquées ou masquées gaspillent des cycles de traitement et créent de la confusion lors des audits.

Bonne pratique : Placez toujours les règles spécifiques avant les règles générales. Placez les règles DENY explicites pour les sources connues comme malveillantes en haut, suivies des règles ALLOW spécifiques pour les services de confiance, et terminez chaque chaîne par une politique DENY par défaut.

Configuration des règles de pare-feu sur Linux avec UFW

UFW (Uncomplicated Firewall) est une interface pour iptables et nftables sur les systèmes basés sur Debian/Ubuntu. Il abstrait la syntaxe de chaîne de bas niveau en commandes lisibles par l’homme tout en préservant un contrôle total sur le filtrage par port, protocole, IP et interface.

Étape 1 : Installer et activer UFW

UFW est préinstallé sur Ubuntu. Vérifiez son statut avant de l’activer :

sudo ufw status verbose

S’il est inactif, activez-le :

sudo ufw enable

Avertissement critique : Si vous êtes connecté via SSH et n’avez pas encore autorisé le port 22, l’activation d’UFW vous bloquera l’accès. Autorisez toujours SSH avant d’activer le pare-feu sur un serveur distant.

Étape 2 : Définir les politiques par défaut

Les politiques par défaut définissent ce qui arrive au trafic qui ne correspond à aucune règle explicite. La base de référence sécurisée est :

sudo ufw default deny incoming
sudo ufw default allow outgoing

Cela bloque toutes les connexions entrantes non sollicitées tout en autorisant tout le trafic sortant. Si votre politique de sécurité nécessite un filtrage des sorties (ex. : prévention de l’exfiltration de données ou des rappels C2), modifiez la valeur par défaut sortante :

sudo ufw default deny outgoing

Puis autorisez explicitement uniquement les destinations sortantes dont votre application a besoin.

Étape 3 : Autoriser des services et des ports spécifiques

UFW prend en charge les noms de services de /etc/services ou les numéros de port explicites :

# Allow SSH by service name
sudo ufw allow ssh

# Allow HTTP and HTTPS
sudo ufw allow http
sudo ufw allow https

# Allow a custom application port
sudo ufw allow 8080/tcp

# Allow a UDP service (e.g., DNS resolver)
sudo ufw allow 53/udp

Pour autoriser une plage de ports (ex. : FTP passif) :

sudo ufw allow 49152:65535/tcp

Étape 4 : Restreindre l’accès à des adresses IP sources spécifiques

Exposer des ports d’administration à 0.0.0.0/0 est une cause majeure de compromission par force brute. Verrouillez SSH sur une IP de gestion connue :

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

Pour autoriser un sous-réseau de gestion entier :

sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp

Étape 5 : Refuser le trafic provenant d’adresses IP ou de sous-réseaux spécifiques

Bloquer une IP connue comme malveillante :

sudo ufw deny from 198.51.100.77

Bloquer un sous-réseau entier (ex. : un blocage géographique ou une plage ASN abusive) :

sudo ufw deny from 198.51.100.0/24

Cas particulier : Les règles UFW deny envoient une réponse TCP RST ou ICMP port-unreachable, ce qui confirme l’existence de l’hôte. Utilisez reject pour supprimer silencieusement les paquets à la place :

sudo ufw reject from 198.51.100.0/24

Étape 6 : Inspecter les règles actives

sudo ufw status numbered

L’indicateur numbered attribue un index à chaque règle, ce qui est nécessaire pour une suppression ciblée :

[ 1] 22/tcp                     ALLOW IN    203.0.113.50
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere

Pour une sortie complète et détaillée incluant les politiques par défaut et les liaisons d’interface :

sudo ufw status verbose

Étape 7 : Supprimer des règles

Supprimer par numéro de règle (préféré — évite toute ambiguïté) :

sudo ufw delete 3

Supprimer par spécification de règle :

sudo ufw delete allow 8080/tcp

Étape 8 : Recharger et persister les règles

Les règles UFW persistent automatiquement après les redémarrages. Après des modifications en masse, rechargez sans interrompre les connexions existantes :

sudo ufw reload

Pour réinitialiser complètement toutes les règles et repartir de zéro :

sudo ufw reset

UFW avancé : profils d’application

UFW prend en charge les profils d’application nommés stockés dans /etc/ufw/applications.d/. Cela vous permet de définir des règles multi-ports sous un seul nom :

sudo ufw app list
sudo ufw allow 'Nginx Full'
sudo ufw app info 'Nginx Full'

Création d’un profil personnalisé pour une API Node.js :

[NodeAPI]
title=Node.js API Server
description=Custom Node.js application
ports=3000,3001/tcp

Puis appliquez-le :

sudo ufw allow NodeAPI

Configuration des règles de pare-feu avec firewalld (RHEL/CentOS/Fedora)

firewalld utilise un modèle basé sur les zones plutôt qu’un ensemble de règles plat. Chaque interface réseau est assignée à une zone (ex. : public, internal, dmz), et les règles sont appliquées par zone. C’est architecturalement plus flexible pour les serveurs multi-interfaces.

Opérations de base avec firewalld

# Check status
sudo firewall-cmd --state

# List all active zones and their interfaces
sudo firewall-cmd --get-active-zones

# List rules in the public zone
sudo firewall-cmd --zone=public --list-all

Autoriser et supprimer des services

# Allow HTTPS permanently
sudo firewall-cmd --zone=public --add-service=https --permanent

# Allow a custom port
sudo firewall-cmd --zone=public --add-port=8443/tcp --permanent

# Remove a service
sudo firewall-cmd --zone=public --remove-service=http --permanent

# Reload to apply permanent changes
sudo firewall-cmd --reload

Règles enrichies pour les politiques spécifiques aux IP

Les règles enrichies firewalld offrent la granularité de iptables avec une syntaxe plus lisible :

# Allow SSH only from a specific IP
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="203.0.113.50" service name="ssh" accept' 
  --permanent

# Block all traffic from a subnet
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" drop' 
  --permanent

sudo firewall-cmd --reload

Configuration des règles de pare-feu avec nftables

nftables est le remplacement moderne de iptables, offrant un cadre unifié pour le filtrage IPv4, IPv6, ARP et bridge avec des performances nettement meilleures et un remplacement atomique des règles.

Ensemble de règles nftables de base

# Flush existing ruleset
sudo nft flush ruleset

# Create a basic filtering table
sudo nft add table inet filter

# Add input, forward, and output chains
sudo nft add chain inet filter input { type filter hook input priority 0 ; policy drop ; }
sudo nft add chain inet filter forward { type filter hook forward priority 0 ; policy drop ; }
sudo nft add chain inet filter output { type filter hook output priority 0 ; policy accept ; }

# Allow established and related connections
sudo nft add rule inet filter input ct state established,related accept

# Allow loopback
sudo nft add rule inet filter input iif lo accept

# Allow SSH from a specific IP
sudo nft add rule inet filter input ip saddr 203.0.113.50 tcp dport 22 accept

# Allow HTTP and HTTPS from anywhere
sudo nft add rule inet filter input tcp dport { 80, 443 } accept

Pour rendre l’ensemble de règles persistant, enregistrez-le dans le fichier de configuration par défaut :

sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables

Configuration des règles de pare-feu sur Windows

Windows Defender Firewall avec sécurité avancée fournit des interfaces GUI et en ligne de commande (netsh, PowerShell) pour la gestion des règles.

Utilisation de l’interface graphique

1. Ouvrez Windows Defender Firewall avec sécurité avancée via wf.msc.
2. Sélectionnez Règles de trafic entrant ou Règles de trafic sortant dans le panneau de gauche.
3. Cliquez sur Nouvelle règle dans le panneau de droite.
4. Choisissez le type de règle :

• Port — filtrer par numéro de port TCP/UDP
• Programme — filtrer par chemin d’exécutable
• Prédéfini — utiliser une définition de service Windows intégrée
• Personnalisé — contrôle total sur tous les paramètres

1. Spécifiez le port ou le programme, choisissez Autoriser ou Bloquer, sélectionnez les profils applicables (Domaine, Privé, Public) et nommez la règle.

Utilisation de PowerShell (recommandé pour l’automatisation)

# Allow inbound HTTPS
New-NetFirewallRule -DisplayName "Allow HTTPS Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

# Allow inbound SSH (Windows OpenSSH)
New-NetFirewallRule -DisplayName "Allow SSH Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow `
  -RemoteAddress 203.0.113.50

# Block inbound traffic from a specific IP
New-NetFirewallRule -DisplayName "Block Malicious IP" `
  -Direction Inbound -RemoteAddress 198.51.100.77 -Action Block

# View all inbound rules
Get-NetFirewallRule -Direction Inbound | Select-Object DisplayName, Enabled, Action

# Remove a rule by name
Remove-NetFirewallRule -DisplayName "Allow HTTPS Inbound"

Utilisation de netsh (hérité mais largement pris en charge)

:: Allow inbound port 443
netsh advfirewall firewall add rule name="Allow HTTPS" protocol=TCP dir=in localport=443 action=allow

:: Block a specific IP
netsh advfirewall firewall add rule name="Block IP" dir=in remoteip=198.51.100.77 action=block

:: Delete a rule
netsh advfirewall firewall delete rule name="Allow HTTPS"

Pièges critiques et cas particuliers des règles de pare-feu

L’autorisation implicite pour le trafic ESTABLISHED

Sur les pare-feux à états, le fait de ne pas autoriser explicitement les connexions ESTABLISHED et RELATED dans la chaîne d’entrée interrompra toutes les sessions initiées en sortie (ex. : apt update, curl, recherches DNS) même lorsque la chaîne de sortie est définie sur ACCEPT. Il s’agit de la mauvaise configuration la plus courante sur les configurations brutes iptables ou nftables.

# This rule MUST appear before any DROP rules in the input chain
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Parité IPv6

De nombreux administrateurs configurent méticuleusement les règles IPv4 et oublient complètement IPv6. Si votre serveur possède une adresse IPv6 et que la prise en charge IPv6 d’UFW n’est pas activée, un attaquant peut contourner toutes les règles IPv4 en se connectant via ::. Vérifiez que /etc/default/ufw contient :

IPV6=yes

Interface de bouclage

Autorisez toujours explicitement le trafic sur l’interface de bouclage (lo). De nombreux services locaux (bases de données, files de messages, API internes) communiquent via 127.0.0.1 ou ::1. Bloquer le bouclage interrompt silencieusement la communication inter-processus.

sudo ufw allow in on lo
sudo ufw allow out on lo

Limitation du débit pour prévenir les attaques par force brute

UFW prend en charge nativement la limitation du débit de connexion, ce qui est essentiel pour SSH et autres services d’authentification :

sudo ufw limit ssh

Cela autorise un maximum de 6 tentatives de connexion par 30 secondes depuis une seule IP avant de déclencher un blocage temporaire automatique — une alternative légère à fail2ban pour les déploiements de base.

Trafic ICMP et diagnostique

Bloquer tout ICMP est une pratique courante mais contre-productive. Cela interrompt ping, traceroute, la découverte de MTU de chemin et certains protocoles de routage. L’approche correcte consiste à autoriser des types ICMP spécifiques :

• Type 0 (Réponse d’écho) et Type 8 (Demande d’écho) — pour ping
• Type 3 (Destination inaccessible) — pour la découverte de MTU de chemin
• Type 11 (Temps dépassé) — pour traceroute

Bloquez le Type 17 (Demande de masque d’adresse) et le Type 18 (Réponse de masque d’adresse), qui n’ont aucune utilisation moderne légitime.

Règles de pare-feu et environnements d’hébergement

La stratégie de pare-feu appropriée dépend fortement de votre couche d’infrastructure.

Sur l’Hébergement Web Mutualisé, le pare-feu est géré au niveau de la plateforme par le fournisseur. Les locataires configurent généralement des contrôles d’accès au niveau applicatif plutôt que des filtres de paquets au niveau du noyau.

Sur un VPS avec cPanel, cPanel/WHM inclut ConfigServer Security & Firewall (CSF), qui encapsule iptables avec une interface de haut niveau, une détection automatique des attaques par force brute et la prise en charge du port knocking. CSF est la solution de pare-feu standard pour les environnements cPanel et doit être utilisé de préférence à UFW brut sur ces systèmes.

Sur l’Hébergement VPS non géré ou les Serveurs Dédiés, vous avez un contrôle total sur le pare-feu du noyau. C’est là qu’UFW, firewalld et nftables sont les outils appropriés. La base de référence de renforcement doit inclure :

• Politique entrante de refus par défaut
• SSH restreint aux IP de gestion connues ou à une passerelle VPN
• Tous les ports non essentiels fermés
• Limitation du débit sur les ports d’authentification
• Journalisation activée pour le trafic refusé

Si vous exécutez des charges de travail GPU ou des services d’inférence ML sur l’Hébergement GPU, portez une attention particulière aux ports exposés par les notebooks Jupyter, TensorBoard et les API de service de modèles — ceux-ci sont fréquemment ciblés par des bots de cryptominage qui analysent les ports à numéros élevés ouverts.

Liste de contrôle pour l’audit et la maintenance des règles de pare-feu

Les audits réguliers des règles sont aussi importants que la configuration initiale. Les règles s’accumulent avec le temps et deviennent obsolètes, créant une surface d’attaque inutile.

Tâches d’audit à effectuer trimestriellement :

• Exécutez sudo ufw status numbered ou équivalent et examinez chaque règle par rapport à l’inventaire des services actuels
• Supprimez les règles pour les services désaffectés, les anciennes adresses IP et les exceptions temporaires qui n’ont jamais été nettoyées
• Vérifiez que les politiques par défaut sont toujours deny incoming
• Vérifiez que les règles IPv6 reflètent les règles IPv4
• Confirmez que la journalisation est activée et que les journaux de trafic refusé sont ingérés par votre SIEM ou agrégateur de journaux
• Testez les règles avec nmap depuis un hôte externe pour vérifier que la surface d’attaque correspond à votre intention

# Scan your own server from an external host to verify exposed ports
nmap -sS -sV -p 1-65535 --open YOUR_SERVER_IP

• Validez que les règles ESTABLISHED/RELATED sont présentes et correctement ordonnées
• Examinez les règles de limitation du débit et ajustez les seuils en fonction des modèles de trafic observés

Matrice de décision : choisir le bon outil de pare-feu

Points clés pratiques

• Définissez le refus par défaut entrant avant d’écrire des règles d’autorisation. Cela garantit que toute règle oubliée entraîne une connexion bloquée, et non ouverte.
• N’exposez jamais SSH à 0.0.0.0/0 sur un serveur de production. Restreignez-le à une IP de gestion, un sous-réseau VPN, ou utilisez le port knocking.
• Rédigez des règles d’autorisation aussi spécifiques que possible. Préférez from 203.0.113.50 to any port 22 proto tcp à allow 22.
• Répliquez les règles IPv4 en IPv6. Un pare-feu qui filtre uniquement IPv4 n’est qu’un demi-pare-feu.
• Activez la limitation du débit de connexion sur tous les ports d’authentification comme mesure de base contre les attaques par force brute.
• Journalisez le trafic refusé. Les suppressions silencieuses sans journalisation rendent la réponse aux incidents pratiquement impossible.
• Auditez les règles selon un calendrier. Les règles obsolètes sont une responsabilité, pas un filet de sécurité.
• Testez depuis l’extérieur. Utilisez nmap ou un scanner de ports externe après chaque modification significative des règles pour confirmer la surface d’attaque effective.
• Utilisez ufw reload plutôt que ufw disable && ufw enable pour éviter d’interrompre les connexions actives lors des mises à jour de règles.
• Sur nftables et iptables, placez toujours la règle d’acceptation ESTABLISHED/RELATED en haut de la chaîne d’entrée pour éviter d’interrompre les sessions initiées en sortie.

Foire aux questions

Quelle est la différence entre une règle de pare-feu et un groupe de sécurité dans les environnements cloud ?

Un groupe de sécurité (AWS, GCP, Azure) est un filtre de paquets à états géré par le cloud, appliqué au niveau de l’hyperviseur avant que le trafic n’atteigne votre VM. Une règle de pare-feu basée sur l’hôte (UFW, firewalld) s’exécute dans le noyau du système d’exploitation. Les deux doivent être utilisés simultanément pour une défense en profondeur — le groupe de sécurité cloud comme périmètre externe et le pare-feu hôte comme couche d’application interne.

Pourquoi UFW affiche-t-il une règle comme active mais le trafic est toujours bloqué ?

La cause la plus courante est l’ordre des règles. Une règle DENY plus tôt dans la chaîne correspond avant votre règle ALLOW. Exécutez sudo ufw status numbered et vérifiez l’ordre. Vérifiez également que des règles IPv6 existent si le client se connecte via IPv6, et confirmez que la bonne interface est ciblée si le serveur est multi-interfaces.

Dois-je bloquer entièrement ICMP pour des raisons de sécurité ?

Non. Bloquer tout ICMP interrompt la découverte de MTU de chemin, ce qui provoque le blocage des sessions TCP sur les réseaux avec des MTU non standard. Cela interrompt également traceroute et rend les diagnostics réseau nettement plus difficiles. Bloquez uniquement les types ICMP sans utilisation opérationnelle légitime (types 17 et 18). Autorisez la demande/réponse d’écho, la destination inaccessible et le temps dépassé.

Que se passe-t-il pour les connexions SSH actives lorsque je recharge UFW ?

sudo ufw reload recharge l’ensemble de règles sans vider les entrées d’état conntrack existantes. Les sessions SSH actives restent connectées car la table de suivi des connexions du noyau conserve toujours leur état ESTABLISHED. Seul sudo ufw disable suivi de sudo ufw enable viderait l’état et pourrait potentiellement interrompre les connexions actives.

Comment empêcher la perte des règles de pare-feu après un redémarrage du système ?

UFW persiste automatiquement les règles après les redémarrages via les fichiers de configuration /etc/ufw/. Pour firewalld, utilisez l’indicateur --permanent sur chaque règle et exécutez sudo firewall-cmd --reload. Pour nftables brut, enregistrez l’ensemble de règles avec sudo nft list ruleset > /etc/nftables.conf et assurez-vous que le service systemd nftables est activé. Pour iptables, utilisez iptables-save > /etc/iptables/rules.v4 et installez le paquet iptables-persistent.