Rocky Linux / Gérer firewalld : zones, services et ports

Rocky Linux

Date de création 2026-04-25 Dernière modification 2026-10-26

Sur Rocky Linux, firewall-cmd permet de gérer les zones, services, ports et règles de firewalld. Pour autoriser un accès, identifiez la zone qui reçoit ce trafic, testez une règle active, vérifiez une nouvelle connexion SSH (Secure Shell) puis enregistrez les changements à conserver.

Ce guide explique les commandes nécessaires pour l'administration courante du pare-feu Rocky Linux et les vérifications qui aident à éviter un verrouillage accidentel.

Ce guide vise un système Rocky Linux utilisant systemd et firewalld. Les noms public et System eth0 sont des exemples à remplacer par votre zone et votre profil actifs. Les sections présentent des opérations distinctes : ne les exécutez pas toutes à la suite. Notez les règles déjà présentes et gardez un accès console de secours avant de modifier une machine distante.

Vérifier l’état de firewalld et les zones actives

sudo firewall-cmd --state
sudo systemctl status firewalld
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone

Une zone de firewalld est un ensemble de règles associé à un niveau de confiance. Une zone peut être attribuée à une interface réseau, à une connexion NetworkManager ou à une adresse source. Vérifiez les zones actives avant de faire des modifications car omettre --zone peut modifier la zone par défaut au lieu de la zone qui gère le trafic que vous souhaitez contrôler.

Si une interface n'apparaît pas là où vous l'attendez, inspectez la connexion NetworkManager active avant d'ajouter des règles. Une règle correcte dans la mauvaise zone ne permettra pas le trafic prévu.

Démarrer firewalld et l'activer au démarrage

Si le paquet manque, installez firewalld avec le gestionnaire DNF de Rocky Linux. Avant d’activer un pare-feu jusque-là arrêté, examinez sa configuration permanente et confirmez les accès d’administration prévus depuis la console ; son activation applique cette configuration et peut modifier immédiatement l’accès distant.

sudo systemctl enable --now firewalld

Vérifiez à la fois le paramètre de démarrage et l'état actuel du service :

systemctl is-enabled firewalld
systemctl is-active firewalld

Ne désactivez pas le pare-feu entier sur un serveur en production juste pour rendre une application accessible. Autorisez uniquement le service, le port, le protocole et la source requis. Dans un environnement cloud, rappelez-vous qu'un groupe de sécurité, une liste de contrôle d'accès réseau ou un pare-feu du fournisseur peut bloquer le trafic indépendamment de firewalld.

Comprendre les configurations en temps réel et permanentes

Configuration	Quand elle prend effet	Comportement
Active (runtime)	Immédiatement après l'exécution de la commande	Les règles de test non enregistrées sont remplacées par la configuration permanente lors d’un rechargement ou d’un redémarrage.
Permanente	Stocké avec `--permanent` et activé par un rechargement	Survit au redémarrage, mais de nombreux changements permanents n'affectent pas immédiatement la configuration en cours d'exécution.

Pour un serveur distant, ajoutez d'abord la règle à la configuration en cours d'exécution. Testez l'application et ouvrez une deuxième connexion SSH avant d’enregistrer les changements que vous souhaitez conserver.

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

La requête affiche yes et renvoie 0 si le service est autorisé dans cette configuration ; no et 1 indiquent son absence. Cela ne teste pas une connexion complète. Depuis un autre ordinateur, vérifiez le service web et ouvrez une nouvelle session SSH avant d’enregistrer le changement.

Pour ne conserver que cette règle HTTP, ajoutez aussi son équivalent permanent :

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

La règle est déjà active et désormais enregistrée : un rechargement n’est pas nécessaire pour la faire prendre effet dans cet exemple. Une autre méthode consiste à copier l’ensemble de la configuration active :

sudo firewall-cmd --runtime-to-permanent

--runtime-to-permanent remplace la configuration permanente par toute la configuration active, y compris d’autres changements temporaires. Utilisez cette méthode seulement après avoir examiné l’ensemble de ces différences. Elle n’enregistre pas seulement le dernier service ajouté.

Si vous effectuez plutôt une modification avec --permanent, révisez-la et rechargez firewalld pour l'activer :

sudo firewall-cmd --reload

Un rechargement remplace la configuration en cours d'exécution par la configuration permanente. Les modifications non sauvegardées uniquement dans la configuration en cours d'exécution sont donc perdues.

Pour annuler uniquement la règle HTTP ajoutée pour cet essai, et seulement si elle n’existait pas auparavant, supprimez-la dans les deux configurations :

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

Vérifiez ensuite son absence dans les deux configurations. La documentation sur les configurations active et permanente précise leur cycle de vie.

Autoriser et supprimer des services prédéfinis

Lister les définitions de services disponibles

firewall-cmd --get-services
firewall-cmd --info-service=http

Lorsque firewalld définit déjà un service standard tel que HTTP, HTTPS ou SSH, l'utilisation du nom du service communique généralement l'objectif de manière plus claire que l'ouverture de ports individuels. Une définition de service peut également inclure plus d'un port, protocole ou assistant.

Autoriser un service dans la configuration en cours d'exécution

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

Ouvrir le pare-feu ne démarre pas le serveur web. Confirmez que l'application fonctionne et écoute à l'adresse et au port attendus :

ss -lntup

Supprimer un service autorisé

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

Avant de supprimer l'accès SSH sur une machine distante, confirmez qu'une autre règle d'accès testée et une console hors bande sont disponibles. Gardez la session SSH existante ouverte jusqu'à ce qu'une nouvelle connexion réussisse.

Gérer les ports personnalisés

Autoriser un port TCP ou UDP

sudo firewall-cmd --zone=public --add-port=8443/tcp
sudo firewall-cmd --zone=public --add-port=5000/udp

TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) nécessitent des règles séparées. Vérifiez la documentation de l'application et ouvrez uniquement le protocole et le port qu'elle utilise réellement.

Autoriser une plage de ports

sudo firewall-cmd --zone=public --add-port=6000-6010/tcp

Avant d'ouvrir une plage large, confirmez la plage exacte requise par l'application. Dans la mesure du possible, restreignez également l'accès aux adresses sources connues ou à un réseau de gestion dédié.

Supprimer et lister les ports

sudo firewall-cmd --zone=public --remove-port=8443/tcp
sudo firewall-cmd --zone=public --list-ports

Inspecter les règles actuelles

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

La première commande montre les règles en cours pour la zone spécifiée, tandis que la dernière commande montre ses règles permanentes. Si les résultats diffèrent, le serveur peut se comporter différemment après le prochain rechargement ou redémarrage. Comparez les deux configurations avant de finaliser un changement de maintenance.

Restreindre l’accès à une adresse source

Créer une règle avancée pour une source SSH

Vérifiez d’abord la définition du service avec firewall-cmd --info-service=ssh. Le service prédéfini correspond généralement au port 22/tcp ; il ne suit pas automatiquement un port SSH personnalisé. Pour un autre port, construisez la règle correspondant à ce port réel avant de retirer un accès existant.

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" service name="ssh" accept'

192.0.2.10 est une adresse de documentation, pas une adresse à copier dans une règle de production. Remplacez-la par l'adresse IP publique fixe de l'administrateur ou par un réseau interne de confiance. Le suffixe /32 désigne ici une seule adresse IPv4. Pour IPv6, utilisez une source et une famille IPv6 appropriées au lieu de copier l'exemple IPv4.

Une règle d’acceptation pour une source précise ne supprime pas les autres autorisations. Si le même port reste ouvert à tous via une règle de port, un autre service, une autre zone ou une politique applicable, l’accès reste plus large que prévu.

Tester avant de supprimer l’accès SSH général

Après avoir ajouté la règle spécifique à la source, gardez la session actuelle ouverte et établissez une nouvelle connexion SSH depuis l'adresse autorisée. Vérifiez l'accès de récupération sur la console avant de supprimer la règle de service SSH plus large.

sudo firewall-cmd --zone=public --list-rich-rules
sudo firewall-cmd --zone=public --remove-service=ssh

Une restriction de source peut vous bloquer lorsque l'adresse publique de l'administrateur change. Utilisez une adresse fixe, un réseau privé virtuel (VPN) ou un réseau de gestion dédié lorsque l'accès basé sur la source doit être stable.

Une fois l’accès restreint vérifié par une nouvelle connexion depuis la source autorisée, enregistrez ces deux changements dans le même ordre. Remplacez aussi l’adresse de documentation dans cette version permanente :

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --zone=public --remove-service=ssh

Comparez ensuite les règles actives et permanentes. Pour revenir à l’état initial, rétablissez depuis la console les autorisations qui existaient auparavant et retirez uniquement la règle de source créée pour cet essai, dans les deux configurations. Ne rechargez pas une configuration permanente dont l’accès d’administration n’a pas été vérifié.

Associer une connexion NetworkManager à une zone

nmcli connection show --active
firewall-cmd --get-active-zones

Attribuer une zone à un profil de connexion NetworkManager permet de conserver ensemble la configuration réseau et l'association de zone de firewalld. Remplacez le nom de connexion exemple par le nom exact affiché par nmcli.

nmcli -g connection.zone connection show 'System eth0'
sudo nmcli connection modify 'System eth0' connection.zone public
firewall-cmd --get-active-zones

Notez la valeur de zone affichée avant modification. La documentation NetworkManager de connection.zone indique qu’une modification sur une connexion déjà activée prend effet immédiatement ; une réactivation complète du profil n’est pas requise pour ce seul changement. Cela peut tout de même modifier le filtrage de votre session : prévoyez la console de secours. Pour revenir en arrière, rétablissez la valeur précédente avec nmcli connection modify ; une valeur vide connection.zone '' redonne la zone par défaut si c’était le réglage initial.

Dépanner les connexions bloquées dans un ordre utile

Exécutez systemctl is-active firewalld pour confirmer que firewalld est actif.
Utilisez firewall-cmd --get-active-zones pour trouver la zone associée à l'interface ou à la source pertinente.
Comparez la sortie --list-all d'exécution et permanente pour cette zone.
Exécutez ss -lntup pour confirmer que l'application écoute sur l'adresse, le port et le protocole attendus.
Vérifiez les groupes de sécurité cloud, les pare-feu du fournisseur, les listes de contrôle d'accès du routeur et les règles de traduction d’adresses réseau (NAT).
Examinez les refus du contrôle d’accès SELinux (Security-Enhanced Linux) et les journaux de l'application.

Un port firewalld ouvert ne garantit pas une connexion réussie. L'application doit être en cours d'exécution et à l'écoute sur une adresse accessible, et chaque autre couche de pare-feu ou de routage sur le chemin doit également permettre le trafic.

Questions fréquemment posées

Pourquoi une règle ajoutée avec --permanent n'a-t-elle pas pris effet immédiatement ?

Une règle permanente est stockée pour une utilisation future et devient normalement active après firewall-cmd --reload. Sur un serveur distant, testez d'abord l'équivalent en temps réel de la règle, confirmez l'accès, puis enregistrez son équivalent avec --permanent. Réservez --runtime-to-permanent au cas où toute la configuration active a été vérifiée.

Pourquoi un service est-il inaccessible même si son port est ouvert ?

Vérifiez la zone active, l'adresse et le protocole sur lesquels l'application écoute, les pare-feu en amont du cloud ou du réseau, le NAT et SELinux. Firewalld ne contrôle qu'une seule couche du chemin de connexion.

Dois-je utiliser une règle de service ou une règle de port ?

Utilisez un service prédéfini lorsqu'il représente avec précision l'application, car la règle est plus facile à comprendre et peut inclure tous les protocoles requis. Utilisez un port et un protocole explicites pour une application personnalisée ou un port non standard.

Est-il sûr d'arrêter firewalld pour le dépannage ?

Arrêter le pare-feu entier peut exposer tous les services en écoute et n'est pas sûr sur un serveur de production. Inspectez la zone active, les journaux et les règles actuelles, puis effectuez le plus petit changement temporaire nécessaire pour un test contrôlé.

Résumé

Un flux de travail sécurisé de firewalld sur Rocky Linux commence par identifier la zone active, tester la règle d'exécution minimale requise et ne la sauvegarder qu'une fois que la connexion fonctionne. Privilégiez les services nommés pour les applications standard, spécifiez à la fois le port et le protocole pour les services personnalisés, et comparez les règles d'exécution avec les règles permanentes avant de terminer.

Pour l'administration SSH à distance, conservez la session actuelle et un chemin de récupération console jusqu'à ce qu'une deuxième connexion réussisse. Cette précaution est plus importante que toute option individuelle de firewall-cmd.

Références officielles

Rocky Linux