Configurer un pare-feu avec Firewalld

Firewalld est le pare-feu hôte par défaut sur Red Hat Enterprise Linux, Fedora, CentOS Stream, Rocky et AlmaLinux. Il expose un modèle déclaratif à deux niveaux — des zones associées aux interfaces, et des services préconfigurés autorisés par zone — par-dessus nftables (Linux moderne) ou iptables (Linux plus ancien). La promesse : configurer un filtrage riche sans écrire de chaîne de règles, et recharger à chaud sans couper les connexions établies. Ce guide pose les fondations (zones, services, règles riches), traite les deux pièges classiques (runtime vs permanent, oubli d'autoriser SSH), et termine par un plan de rollback.

Ce que vous allez apprendre

• Installer et activer Firewalld, vérifier son état
• Comprendre les zones (public, internal, work…) et leur rôle
• Distinguer runtime et permanent pour ne plus perdre vos règles au reload
• Ouvrir des services et des ports par zone
• Écrire une règle riche pour les cas que les services ne couvrent pas
• Journaliser, dépanner et rollback proprement

Dans quel contexte ?

Firewalld est la valeur par défaut quand vous êtes sur l'écosystème Red Hat (RHEL, Fedora, CentOS Stream, Rocky, AlmaLinux) ou sur openSUSE moderne. Vous le rencontrerez presque systématiquement sur un poste RHCSA, sur une VM cloud RHEL/Rocky, et sur tout serveur géré par firewalld.service.

Il s'utilise :

• quand on veut un pare-feu hôte avec zones (laptop avec différents réseaux, serveur multi-interfaces)
• quand on veut recharger sans couper les connexions TCP établies
• quand on préfère déclarer des services nommés (http, ssh, samba…) plutôt que des numéros de port

Sur Debian/Ubuntu, la valeur par défaut est UFW — plus simple, suffisant pour un serveur mono-interface. Ne mélangez pas les deux sur la même machine.

Prérequis

• Un serveur RHEL, Fedora, CentOS Stream, Rocky ou AlmaLinux (ou Debian/Ubuntu si vous avez un besoin explicite de Firewalld)
• Un utilisateur avec droits sudo
• Une session SSH par clé et un accès de secours (console cloud, IPMI, série) avant toute manipulation

Risque de lockout

Toute politique par défaut drop ou toute suppression du service ssh d'une zone active peut vous couper votre session. Gardez un accès console prêt et testez vos règles en mode runtime avant de les figer en permanent.

Concept central : zones

Firewalld attache chaque interface réseau à une zone, et chaque zone porte ses propres règles. C'est ce qui permet à un laptop d'être strict sur le Wi-Fi public et permissif sur le Wi-Fi maison en basculant automatiquement de zone.

Les zones standard à connaître :

Zone	Usage typique	Politique par défaut
drop	Hostile (réseau inconnu, scan intensif)	Entrée bloquée sans notification
block	Hostile avec rejet explicite	Entrée bloquée, ICMP reject
public	Internet, Wi-Fi public — défaut fréquent	SSH autorisé, reste bloqué
external	Sortie Internet avec masquerade (NAT)	SSH autorisé, masquerade activé
work	LAN de bureau	SSH, DHCP, MDNS autorisés
home	LAN domestique	SSH, MDNS, Samba, IPP client
internal	LAN de confiance	Identique à home
trusted	Tout autorisé	Pas de filtrage

Glissez pour voir

Vérifier la zone par défaut et les zones actives :

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

Runtime vs permanent — le piège principal

Firewalld maintient deux configurations :

• Runtime — les règles actuellement appliquées. Perdues au prochain reload ou reboot.
• Permanent — les règles sauvegardées dans /etc/firewalld/. Appliquées après reload ou reboot.

Une commande sans --permanent touche uniquement le runtime. Une commande avec --permanent touche uniquement le permanent ; il faut alors un firewall-cmd --reload pour que ça prenne effet.

Workflow recommandé

1. Tester d'abord en runtime sans --permanent.
2. Si ça marche, rejouer avec --permanent.
3. firewall-cmd --reload pour appliquer la version permanente.

Alternative rapide : firewall-cmd --runtime-to-permanent copie l'état runtime actuel dans le permanent. Utile quand vous avez enchaîné plusieurs tests concluants.

Installer Firewalld

RHEL / Fedora / Rocky / Alma

Firewalld est normalement installé et activé par défaut :

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld

Vérifier :

sudo firewall-cmd --version
sudo firewall-cmd --state

firewall-cmd --state doit répondre running.

openSUSE

sudo zypper install firewalld
sudo systemctl enable --now firewalld

Debian / Ubuntu

Disponible dans les dépôts officiels, non installé par défaut. Si UFW répond à votre besoin, restez sur UFW. Si vous avez besoin du modèle zones :

sudo apt update
sudo apt install -y firewalld
sudo systemctl enable --now firewalld

Désactivez UFW avant pour éviter tout conflit :

sudo systemctl disable --now ufw

Arch Linux

sudo pacman -S firewalld
sudo systemctl enable --now firewalld

Autoriser SSH avant tout

C'est l'étape à ne jamais sauter. Vous devez connaître la zone active de l'interface d'administration avant d'autoriser SSH — sinon vous ouvrez le port sur la mauvaise zone et vous verrouillez à la première déconnexion.

Repérer la zone active :

sudo firewall-cmd --get-active-zones
# Sortie type :
# public
#   interfaces: eth0
# internal
#   interfaces: eth1

L'interface qui porte votre session SSH (souvent eth0) est associée à une zone — ici public. C'est sur cette zone-là qu'il faut autoriser SSH. Dans la suite de cette section, remplacez public par votre zone active.

Vérifier que ssh est déjà dans la zone (c'est le cas par défaut sur RHEL/Fedora) :

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

Si ssh n'apparaît pas dans la sortie :

# runtime
sudo firewall-cmd --zone=public --add-service=ssh

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

Si SSH écoute sur un port non standard, ouvrez le port brut :

sudo firewall-cmd --zone=public --add-port=2222/tcp --permanent
sudo firewall-cmd --reload

Zones : lire, affecter, basculer

Lister toutes les zones disponibles :

sudo firewall-cmd --get-zones

Voir le détail d'une zone (services, ports, sources, interfaces) :

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

Associer une interface à une zone (persistant) :

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

Définir la zone par défaut :

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

Créer une zone personnalisée — utile pour un segment réseau dédié :

sudo firewall-cmd --new-zone=administration --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=administration --add-source=10.10.10.0/24 --permanent
sudo firewall-cmd --zone=administration --add-service=ssh --permanent
sudo firewall-cmd --reload

Sources vs interfaces

Une zone peut matcher soit par interface (tout ce qui arrive par eth0), soit par source (tout ce qui vient de 10.10.10.0/24). La seconde est utile quand plusieurs sous-réseaux partagent la même interface physique.

Ouvrir des services et des ports

Firewalld embarque plus de 150 services préconfigurés (fichiers XML sous /usr/lib/firewalld/services/). Lister :

sudo firewall-cmd --get-services | tr ' ' '\n' | head

Autoriser un service

# runtime
sudo firewall-cmd --zone=public --add-service=https

# permanent + reload
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload

Ouvrir un port brut

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

Retirer

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

Lister ce qui est ouvert

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

Règles riches (rich rules) : quand les services ne suffisent pas

Les règles riches (--add-rich-rule) expriment des critères que les services simples ne couvrent pas : source précise, action avancée, rate-limit, journalisation par règle. Syntaxe :

# Autoriser HTTP uniquement depuis un sous-réseau interne
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="192.168.1.0/24"
  service name="http"
  accept
' --permanent

# Bloquer explicitement une IP qui martèle
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  source address="203.0.113.42"
  reject
' --permanent

# Rate-limiter les nouvelles connexions SSH
sudo firewall-cmd --zone=public --add-rich-rule='
  rule service name="ssh"
  accept
  limit value="6/m"
' --permanent

sudo firewall-cmd --reload

Lister les règles riches actives :

sudo firewall-cmd --zone=public --list-rich-rules

Supprimer : remplacer --add-rich-rule par --remove-rich-rule en reprenant exactement la même chaîne.

Journalisation et dépannage

Activer la journalisation des paquets refusés :

# valeurs : off | all | unicast | broadcast | multicast
sudo firewall-cmd --set-log-denied=unicast

La valeur unicast suffit pour le dépannage sans noyer le journal. Les événements apparaissent ensuite dans :

sudo journalctl -u firewalld --since "10 min ago"
# ou plus bas niveau
sudo dmesg --follow | grep -i reject

État complet du service :

sudo systemctl status firewalld
sudo firewall-cmd --state
sudo firewall-cmd --list-all-zones

Bonnes pratiques

• Toujours tester en runtime avant de sauver en --permanent.
• Associer les interfaces à une zone explicite plutôt que de dépendre de la zone par défaut — évite les surprises après ajout d'une nouvelle carte.
• Préférer les services aux ports bruts — la maintenance devient lisible (--add-service=http plutôt que --add-port=80/tcp).
• Créer un service custom si vous exposez une appli sur un port non standard : fichier XML sous /etc/firewalld/services/<nom>.xml, firewall-cmd --reload, puis --add-service=<nom>.
• Journaliser (--set-log-denied=unicast) pendant la phase d'ouverture d'un service, désactiver ensuite pour garder le journal propre.
• Sauvegarder /etc/firewalld/ — c'est la totalité de votre état permanent (fichiers XML, versionnables dans Git).

Sécurité et rollback

En cas d'erreur, trois niveaux de repli :

# 1. Revenir au dernier permanent chargé (annule les modifs runtime)
sudo firewall-cmd --reload

# 2. Supprimer une règle runtime immédiatement
sudo firewall-cmd --zone=public --remove-service=<service>
sudo firewall-cmd --zone=public --remove-rich-rule='<règle exacte>'

# 3. Panic mode : bloque TOUT le trafic, entrant ET sortant
sudo firewall-cmd --panic-on
# une fois l'incident maîtrisé depuis la console de secours :
sudo firewall-cmd --panic-off

panic-on coupe tout

--panic-on coupe aussi votre session SSH. Ne l'activez qu'avec un accès console de secours disponible. Utile en réponse à incident, pas en configuration normale.

Pour un rollback complet de la configuration permanente, restaurez /etc/firewalld/ depuis votre sauvegarde (ou depuis /usr/lib/firewalld/ pour les zones officielles de la distribution) puis firewall-cmd --reload.

Dépannage rapide

Symptôme	Cause probable	Action
SSH coupé après --reload	Service ssh retiré de la zone active, ou zone par défaut changée	Console → firewall-cmd --zone=<active> --add-service=ssh puis --permanent
Règle visible mais inactive	Ajoutée en --permanent sans --reload	firewall-cmd --reload
Règle disparue au reboot	Ajoutée en runtime uniquement	Rejouer avec --permanent
Port ouvert mais service inaccessible	Service écoute sur 127.0.0.1 ou mauvaise zone affectée à l'interface	ss -tulpn côté serveur, firewall-cmd --get-active-zones
Paquets bloqués sans trace	log-denied désactivé (défaut)	firewall-cmd --set-log-denied=unicast
Conflit avec UFW ou iptables manuel	Deux gestionnaires actifs en même temps	systemctl disable --now ufw ; ne pas lancer de règles iptables directes
rich-rule non supprimée par --remove-rich-rule	La chaîne doit correspondre exactement à celle ajoutée	Copier-coller depuis --list-rich-rules

Glissez pour voir

À retenir

• Firewalld attache les interfaces à des zones, chaque zone porte ses propres services / ports / règles riches.
• Runtime ≠ permanent. Sans --permanent, la règle est perdue au prochain --reload ou reboot.
• firewall-cmd --reload rejoue la conf permanente ; il n'interrompt pas les connexions TCP établies.
• Toujours autoriser SSH explicitement dans la zone active de l'interface d'admin avant tout changement profond.
• Pour la plupart des besoins, --add-service=<nom> est plus lisible que --add-port=<n>/tcp.
• Règles riches pour tout ce qui demande source, rate-limit ou journalisation par règle.
• --set-log-denied=unicast est l'outil de dépannage n°1.
• --panic-on existe pour l'incident ; jamais en config normale.
• Sur Debian/Ubuntu, UFW suffit presque toujours ; Firewalld sur Red Hat, point.

Prochaines étapes

Introduction aux pare-feux Revoir les concepts de politique par défaut, flux entrant/sortant et ports avant d'approfondir Firewalld.

UFW Alternative simple pour Debian/Ubuntu, à choisir quand les zones ne sont pas nécessaires.

Durcir SSH Compléter le pare-feu par un sshd configuré : clés uniquement, pas de root, logs.

Serveur OpenSSH Configurer sshd côté RHCSA/LFCS : directives clés, validation avant reload.

×

📖 Voir la documentation →