Introduction à Firewalld : Gestion Dynamique du Pare-feu sur Linux

Firewalld est un démon de gestion de pare-feu en espace utilisateur pour Linux qui fournit une interface dynamique basée sur des zones au-dessus des backends de filtrage de paquets au niveau du noyau iptables et nftables. Contrairement aux outils de pare-feu statiques qui nécessitent un redémarrage complet du service pour appliquer les modifications de règles, Firewalld modifie les règles netfilter à la volée — préservant les sessions TCP actives et éliminant les temps d’arrêt lors des mises à jour de politique.

Ce guide couvre chaque couche opérationnelle de Firewalld : son modèle architectural, les abstractions de zones et de services, les règles enrichies, la configuration runtime par rapport à la configuration permanente, et les commandes exactes dont vous avez besoin pour gérer un serveur de production de manière sécurisée.

Pourquoi Firewalld a remplacé les flux de travail iptables statiques

La gestion traditionnelle de iptables consiste à écrire des règles dans des scripts shell ou des fichiers de configuration plats, puis à vider et recharger l’ensemble des règles chaque fois qu’une modification est nécessaire. Sur un serveur occupé, ce cycle de vidage et rechargement interrompt les connexions en cours et introduit une brève fenêtre pendant laquelle aucun filtrage n’est actif.

Firewalld résout ce problème grâce à un démon activé par D-Bus (firewalld) qui maintient l’état autoritatif des règles et communique les modifications au noyau de manière incrémentielle. Le résultat est des mises à jour atomiques des règles sans interruption de connexion — essentiel pour tout serveur exécutant des charges de travail persistantes telles que des bases de données, des tunnels VPN ou des connexions API de longue durée.

Lorsque vous provisionnez un environnement VPS Hosting et que vous devez le renforcer sans redémarrer ni interrompre les services, Firewalld est le choix opérationnel naturel sur les distributions de la famille RHEL et de nombreuses distributions de la famille Debian.

Architecture principale : comment Firewalld interagit avec le noyau

Comprendre la pile sous-jacente à Firewalld permet d’éviter les mauvaises configurations et vous aide à déboguer les comportements inattendus.

User Space
┌─────────────────────────────────────────────┐
│ firewall-cmd / firewall-config / D-Bus API  │
└────────────────────┬────────────────────────┘
                     │ D-Bus
┌────────────────────▼────────────────────────┐
│              firewalld daemon               │
│  (zone engine, service definitions, rich    │
│   rule parser, direct rule passthrough)     │
└────────────────────┬────────────────────────┘
                     │ nftables / iptables backend
Kernel Space
┌────────────────────▼────────────────────────┐
│           netfilter (kernel module)         │
└─────────────────────────────────────────────┘

Depuis RHEL 8 et Fedora 32, Firewalld utilise par défaut le backend nftables. Sur les systèmes plus anciens ou dans des environnements explicitement configurés, il utilise le backend iptables. Vous pouvez inspecter ou remplacer le backend actif dans /etc/firewalld/firewalld.conf via la directive FirewallBackend.

Piège critique : Ne mélangez jamais les commandes iptables ou nft directes avec Firewalld sur la même interface. Firewalld possède les tables netfilter qu’il crée ; les règles manuelles insérées en dehors du démon seront silencieusement écrasées au prochain rechargement.

Concepts clés de Firewalld

Zones

Une zone est un niveau de confiance nommé appliqué à une interface réseau ou à une plage d’adresses source. Chaque paquet entrant dans le système est mis en correspondance avec la zone assignée à son interface d’entrée, et l’ensemble de règles de la zone détermine ce qui est autorisé.

Firewalld est livré avec les zones prédéfinies suivantes, ordonnées de la plus permissive à la moins permissive :

Nuance architecturale : Une zone peut être liée à une interface réseau (par ex., eth0) ou à un CIDR source (par ex., 192.168.1.0/24). La liaison basée sur la source a la priorité sur la liaison basée sur l’interface, ce qui vous permet d’appliquer différentes politiques au trafic arrivant sur la même interface physique depuis différents sous-réseaux — un schéma courant dans les environnements multi-locataires ou conteneurisés.

Services

Un service dans Firewalld est un fichier de définition XML stocké sous /usr/lib/firewalld/services/ (valeurs par défaut du système) ou /etc/firewalld/services/ (remplacements utilisateur). Chaque fichier déclare les ports, les protocoles et les modules d’assistance optionnels requis pour une application nommée.

Par exemple, la définition du service https ouvre le port TCP 443 et ne charge aucun module d’assistance supplémentaire du noyau. Le service ftp ouvre le port TCP 21 et charge le module d’assistance nf_conntrack_ftp pour gérer la négociation de port dynamique du canal de données FTP.

L’utilisation de noms de services plutôt que de numéros de ports bruts rend votre politique de pare-feu auto-documentée et réduit le risque de fautes de frappe qui laissent un port involontairement ouvert ou fermé.

Pour lister toutes les définitions de services disponibles sur votre système :

firewall-cmd --get-services

Pour inspecter la définition XML d’un service spécifique :

cat /usr/lib/firewalld/services/https.xml

Règles enrichies

Les règles enrichies étendent le modèle de zone avec une logique conditionnelle que l’abstraction simple service/port ne peut pas exprimer. Elles prennent en charge la correspondance sur les adresses source et destination, les plages de ports, les protocoles, les fenêtres temporelles et l’état de connexion, et peuvent déclencher des actions incluant accept, drop, reject, log et audit.

La syntaxe des règles enrichies suit une grammaire structurée :

rule [family="ipv4|ipv6"]
  [source address="addr[/mask]" [invert="true"]]
  [destination address="addr[/mask]" [invert="true"]]
  [service name="service-name"] | [port port="port" protocol="tcp|udp"]
  [log [prefix="prefix"] [level="level"] [limit value="rate/duration"]]
  [audit]
  [accept|drop|reject [type="reject-type"]]

Un exemple pratique — limiter le débit des tentatives de connexion SSH à 3 par minute depuis une seule source IPv4, puis journaliser et abandonner l’excédent :

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  log prefix="SSH_RATELIMIT " level="warning" limit value="3/m"
  accept' --permanent

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  drop' --permanent

Cas particulier : L’ordre des règles enrichies est important. Firewalld évalue les règles enrichies dans l’ordre où elles ont été ajoutées au sein d’une zone. Si vous ajoutez une règle drop générale avant une règle accept spécifique, la règle accept ne sera jamais atteinte. Ajoutez toujours les règles les plus spécifiques en premier.

Configuration runtime vs. permanente

C’est la distinction la plus importante sur le plan opérationnel dans Firewalld et la source des erreurs de production les plus courantes.

Flux de travail recommandé pour les modifications en production :

1. Appliquez la règle uniquement au runtime (sans l’indicateur --permanent) et vérifiez qu’elle se comporte comme prévu.
2. Si correct, appliquez la même règle avec --permanent pour l’écrire sur le disque.
3. Exécutez firewall-cmd --reload pour synchroniser la configuration permanente dans l’état runtime et confirmer la parité.

Ce flux de travail évite le scénario classique où un administrateur ajoute une règle --permanent, recharge, et découvre qu’il s’est verrouillé hors de SSH — car le test runtime aurait révélé le problème avant qu’il ne devienne permanent.

Installation et activation de Firewalld

Firewalld est installé par défaut sur RHEL, CentOS Stream, Fedora, AlmaLinux et Rocky Linux. Sur Debian et Ubuntu, il doit être installé explicitement.

RHEL / CentOS Stream / AlmaLinux / Rocky Linux :

sudo dnf install firewalld

Debian / Ubuntu :

sudo apt-get update && sudo apt-get install firewalld

Note pour les utilisateurs Ubuntu : Si ufw est actif, désactivez-le avant d’activer Firewalld pour éviter les conflits de règles netfilter :

sudo ufw disable
sudo systemctl disable ufw

Démarrez et activez le démon :

sudo systemctl start firewalld
sudo systemctl enable firewalld

Vérifiez que le démon est en cours d’exécution et que le backend noyau est actif :

sudo firewall-cmd --state
sudo firewall-cmd --info-zone=public

Commandes essentielles de Firewalld

Inspecter l’état actuel

Vérifier l’état du démon :

sudo firewall-cmd --state

Lister toutes les zones actives avec leurs interfaces et sources assignées :

sudo firewall-cmd --get-active-zones

Afficher l’ensemble complet des règles pour une zone spécifique :

sudo firewall-cmd --zone=public --list-all

Afficher l’ensemble complet des règles pour toutes les zones simultanément :

sudo firewall-cmd --list-all-zones

Gérer la zone par défaut

La zone par défaut est appliquée à toute interface non explicitement assignée à une autre zone :

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --set-default-zone=public

Assigner une interface à une zone

sudo firewall-cmd --zone=internal --change-interface=eth1 --permanent
sudo firewall-cmd --reload

Piège : Sur les systèmes utilisant NetworkManager, les assignations interface-vers-zone effectuées via firewall-cmd peuvent être remplacées par le profil de connexion NetworkManager lors de la reconnexion. Définissez la zone de manière persistante dans la connexion NetworkManager :

nmcli connection modify "Wired connection 1" connection.zone internal

Ajouter et supprimer des services

Autoriser HTTP dans la zone publique au runtime :

sudo firewall-cmd --zone=public --add-service=http

Le rendre permanent :

sudo firewall-cmd --zone=public --add-service=http --permanent

Supprimer un service :

sudo firewall-cmd --zone=public --remove-service=http --permanent

Ouvrir et fermer des ports spécifiques

Ouvrir le port TCP 8080 au runtime :

sudo firewall-cmd --zone=public --add-port=8080/tcp

Ouvrir une plage de ports UDP de manière permanente :

sudo firewall-cmd --zone=public --add-port=60000-61000/udp --permanent

Supprimer un port :

sudo firewall-cmd --zone=public --remove-port=8080/tcp --permanent

Liste blanche et liste noire d’adresses IP

Autoriser tout le trafic depuis un sous-réseau de gestion de confiance :

sudo firewall-cmd --zone=trusted --add-source=10.0.0.0/24 --permanent

Bloquer tout le trafic depuis une IP spécifique (abandon basé sur la source) :

sudo firewall-cmd --zone=drop --add-source=203.0.113.45/32 --permanent

Redirection de port

Rediriger le port TCP externe 2222 vers le port SSH interne 22 (utile pour masquer le port SSH par défaut sans modifier sshd_config) :

sudo firewall-cmd --zone=public --add-forward-port=port=2222:proto=tcp:toport=22 --permanent
sudo firewall-cmd --reload

Masquerade IP (NAT)

Activer le masquerade sur la zone externe pour permettre à un VPS agissant comme passerelle de faire du NAT sur le trafic d’un sous-réseau privé :

sudo firewall-cmd --zone=external --add-masquerade --permanent
sudo firewall-cmd --reload

Recharger et synchroniser la configuration

Appliquer toutes les modifications permanentes à l’état en cours d’exécution sans interrompre les connexions :

sudo firewall-cmd --reload

Effectuer un redémarrage complet (interrompt toutes les connexions — à utiliser uniquement en cas d’urgence) :

sudo systemctl restart firewalld

Création de zones et de définitions de services personnalisées

Zone personnalisée

sudo firewall-cmd --new-zone=management --permanent
sudo firewall-cmd --zone=management --add-source=10.10.0.0/16 --permanent
sudo firewall-cmd --zone=management --add-service=ssh --permanent
sudo firewall-cmd --zone=management --add-service=cockpit --permanent
sudo firewall-cmd --reload

Définition de service personnalisée

Créer un fichier de service pour une application personnalisée écoutant sur TCP 9200 (par ex., Elasticsearch) :

sudo nano /etc/firewalld/services/elasticsearch.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Elasticsearch</short>
  <description>Elasticsearch HTTP API and transport port</description>
  <port protocol="tcp" port="9200"/>
  <port protocol="tcp" port="9300"/>
</service>

sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --add-service=elasticsearch --permanent
sudo firewall-cmd --reload

Firewalld vs. alternatives : choisir le bon outil

Pour les équipes gérant des Dedicated Servers à grande échelle, l’API D-Bus de Firewalld permet la gestion programmatique des règles depuis des outils de gestion de configuration comme Ansible (module ansible.posix.firewalld) ou Puppet, ce qui représente un avantage opérationnel significatif par rapport à la maintenance de scripts iptables bruts.

Modèles pratiques de renforcement de la sécurité

Sécurisation d’un serveur web

Une configuration typique pour un serveur exécutant HTTPS avec SSH restreint à une IP de gestion :

# Set the default zone
sudo firewall-cmd --set-default-zone=public --permanent

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

# Allow HTTP only to redirect to HTTPS (optional)
sudo firewall-cmd --zone=public --add-service=http --permanent

# Restrict SSH to a specific management IP only
sudo firewall-cmd --zone=public --remove-service=ssh --permanent
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  source address="198.51.100.10/32"
  accept' --permanent

sudo firewall-cmd --reload

Si vous exécutez un serveur web avec un déploiement de SSL Certificates, s’assurer que le port 443 est ouvert dans la bonne zone avant l’émission du certificat (en particulier pour les défis ACME HTTP-01 ou TLS-ALPN-01) est une étape préalable fréquemment négligée.

Protection d’un serveur de messagerie

Pour les serveurs exécutant des piles Email Hosting (Postfix, Dovecot), l’ensemble de services requis est :

sudo firewall-cmd --zone=public --add-service=smtp --permanent
sudo firewall-cmd --zone=public --add-service=smtps --permanent
sudo firewall-cmd --zone=public --add-service=imap --permanent
sudo firewall-cmd --zone=public --add-service=imaps --permanent
sudo firewall-cmd --zone=public --add-service=pop3s --permanent
sudo firewall-cmd --reload

Journalisation des paquets abandonnés pour la forensique

sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  log prefix="DROPPED_PUBLIC " level="warning" limit value="10/m"
  drop' --permanent
sudo firewall-cmd --reload

Les journaux apparaissent dans /var/log/messages ou le journal systemd (journalctl -k -g DROPPED_PUBLIC). Limitez le débit des journaux (comme indiqué ci-dessus) pour éviter l’inondation des journaux dans un scénario DDoS.

Firewalld sur un VPS géré par cPanel

Si vous utilisez un VPS avec cPanel, sachez que cPanel installe et gère sa propre couche de pare-feu (CSF/LFD par défaut). Exécuter Firewalld aux côtés de CSF sans coordination explicite produira des règles netfilter conflictuelles. L’approche recommandée est de choisir une seule couche de gestion de pare-feu par serveur et de désactiver l’autre, ou d’utiliser l’interface de passage direct des règles de Firewalld pour s’intégrer aux exigences de cPanel.

Résolution des problèmes courants de Firewalld

Problème : La règle ajoutée avec --permanent n’est pas en vigueur.

Cause : Les règles permanentes nécessitent un rechargement pour entrer dans l’état runtime.

Solution :

sudo firewall-cmd --reload

Problème : La connexion SSH est interrompue après une modification du pare-feu.

Cause : Le service SSH a été supprimé de la zone active, ou une règle enrichie drop a été ajoutée avant la règle accept.

Solution : Accédez au serveur via la console hors bande (console VNC/KVM de votre hébergeur), puis restaurez le service SSH :

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload

Problème : firewall-cmd retourne FirewallD is not running.

Cause : Le démon a planté ou n’a jamais été démarré.

Solution :

sudo systemctl start firewalld
sudo journalctl -u firewalld -n 50

Problème : Les règles semblent correctes mais le trafic est toujours bloqué.

Cause : Une règle iptables ou nft conflictuelle existe en dehors des tables gérées par Firewalld, ou SELinux/AppArmor bloque la connexion au niveau de la couche applicative.

Solution : Vérifiez les règles manuelles et les refus SELinux :

sudo iptables -L -n -v
sudo ausearch -m avc -ts recent

Problème : L’interface n’est pas assignée à la zone attendue après le redémarrage.

Cause : Le profil de connexion NetworkManager remplace l’assignation d’interface de Firewalld.

Solution : Définissez la zone dans le profil NetworkManager comme décrit dans la section d’assignation d’interface ci-dessus.

Matrice de décision et liste de contrôle technique

Utilisez cette liste de contrôle avant de déployer Firewalld sur un serveur de production :

• Confirmez que le backend de pare-feu actif (FirewallBackend dans /etc/firewalld/firewalld.conf) correspond à la prise en charge nftables/iptables de votre noyau.
• Vérifiez qu’aucun outil de pare-feu conflictuel (UFW, CSF, scripts iptables directs) n’est actif sur les mêmes interfaces.
• Assignez explicitement chaque interface réseau à une zone — ne vous fiez jamais uniquement à la zone par défaut pour les serveurs multi-domiciliés.
• Appliquez toutes les modifications au runtime d’abord, vérifiez la connectivité, puis validez avec --permanent et --reload.
• Restreignez l’accès SSH à des IP sources spécifiques via des règles enrichies avant de supprimer le service SSH de la zone publique.
• Ajoutez des règles enrichies de limitation de débit pour tous les services d’authentification exposés publiquement (SSH, SMTP, points de terminaison de connexion HTTPS).
• Activez la journalisation pour la zone drop avec une limite de débit pour capturer des renseignements sur les menaces sans inonder le stockage.
• Pour les serveurs gérés via des VPS Control Panels, confirmez que les ports requis par le panneau de contrôle sont en liste blanche avant d’appliquer une politique par défaut restrictive.
• Testez la configuration permanente en exécutant firewall-cmd --reload et en vérifiant immédiatement que tous les services critiques restent accessibles.
• Documentez chaque zone personnalisée, règle enrichie et définition de service dans un système de contrôle de version aux côtés de votre infrastructure-as-code.

FAQ

Quelle est la différence entre --reload et sudo systemctl restart firewalld ?

--reload applique les modifications de configuration permanentes au démon en cours d’exécution sans interrompre les connexions établies. systemctl restart redémarre complètement le processus du démon, ce qui vide toutes les règles netfilter et interrompt brièvement les connexions actives. Préférez toujours --reload sur les systèmes de production.

Firewalld et iptables peuvent-ils coexister sur le même serveur ?

Pas de manière sûre sur la même interface. Firewalld gère ses propres chaînes netfilter ; les commandes iptables directes qui modifient les mêmes chaînes seront écrasées au prochain rechargement de Firewalld. Si vous devez injecter des règles personnalisées, utilisez plutôt l’interface --direct de Firewalld ou des règles enrichies.

Comment rendre une règle runtime permanente sans la ressaisir ?

Il n’existe pas de commande intégrée pour promouvoir toutes les règles runtime en permanentes en une seule étape. Le flux de travail correct consiste à appliquer chaque règle deux fois — une fois sans --permanent pour les tests, puis avec --permanent pour la persistance — suivi de --reload. Alternativement, utilisez firewall-cmd --runtime-to-permanent (disponible dans Firewalld 0.9+) pour prendre un instantané de l’état runtime actuel sur le disque.

Pourquoi mon assignation de zone est-elle réinitialisée après une reconnexion NetworkManager ?

NetworkManager stocke les assignations de zones dans ses propres profils de connexion. Une assignation firewall-cmd --change-interface est un remplacement runtime que NetworkManager peut écraser. Persistez l’assignation avec nmcli connection modify <profile-name> connection.zone <zone>.

Firewalld prend-il en charge IPv6 ?

Oui. Firewalld gère simultanément les règles netfilter IPv4 et IPv6. Les règles enrichies nécessitent l’attribut family="ipv6" pour cibler spécifiquement le trafic IPv6. Les règles de zone et de service s’appliquent aux deux familles d’adresses par défaut, sauf si la définition du service ou la règle enrichie restreint la portée.