Comment configurer le pare-feu SLES 15 avec firewall-cmd

Un service peut être exécuté sur un serveur SLES 15 et continuer à générer des délais d'attente pour les clients distants, car le pare-feu bloque le nouveau trafic entrant. La solution consiste généralement à identifier la zone firewalld active et à autoriser uniquement le service ou le port nécessaire à l'application. L'outil en ligne de commande SLES permettant d'effectuer cette opération est `firewalld` firewall-cmd.

Ce guide suit les recommandations du Guide de sécurité et de renforcement de SLES 15 SP7 de SUSE et la documentation de référence des commandes firewalld (mise à jour le 7 octobre 2026). Les Service Packs antérieurs et les systèmes SLES 12 mis à niveau peuvent présenter des configurations de pare-feu différentes ou héritées. Les captures d'écran du terminal sont des exemples représentatifs et non des résultats issus d'un serveur réel ; remplacez les noms d'interface, de zones et de services par les valeurs correspondantes sur votre système.

1. Vérifiez que firewalld est en cours d'exécution.

La documentation SUSE indique que firewalld est installé et activé par défaut sur SLES 15. YaST le démarre généralement après l'installation et place les interfaces dans la publiczone par défaut. Toutefois, il est préférable de vérifier la configuration système plutôt que de supposer que les paramètres par défaut n'ont pas changé. Exécutez les commandes suivantes avec un compte disposant des droits nécessairessudo :

sudo systemctl status firewalld
sudo firewall-cmd --state

Le gestionnaire de services devrait indiquer que le firewalldservice est actif et firewall-cmd --statedevrait signaler son état running. Si le service est installé mais arrêté, démarrez-le et activez-le au démarrage du système.

sudo systemctl enable --now firewalld

Si firewall-cmdle paquet est manquant, vérifiez s'il firewalldest installé et disponible dans les dépôts SUSE activés. N'installez ni ne remplacez à l'aveugle les composants du pare-feu sur un serveur géré.

2. Trouvez la zone qui protège l'interface du serveur

Firewalld regroupe les règles en zones , qui représentent différents niveaux de confiance. Les publiczones sont généralement utilisées pour les réseaux non fiables. Un service ouvert dans une zone ne s'ouvre pas automatiquement dans toutes les zones ; par conséquent, une règle correcte dans une zone inappropriée peut rendre votre application inaccessible.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --zone=public --list-all

Utilisez la sortie active-zone pour trouver la zone associée à l'interface transportant le trafic client. Le nom de l'interface peut être eth0, ens160, ou un autre nom. Si vous devez vérifier une interface, exécutez :

sudo firewall-cmd --get-zone-of-interface=eth0

Remplacez eth0par l'interface réelle. Une interface non explicitement affectée à une zone est gérée par la zone par défaut. Évitez de modifier la zone par défaut sans précaution : cela pourrait affecter les interfaces qui en dépendent. Sur un serveur distant, identifiez la zone SSH ou autre zone de gestion et vérifiez sa règle d'accès avant de recharger les paramètres du pare-feu. Conservez une console ou une voie de récupération hors bande disponible, le cas échéant.

3. Choisissez un service nommé ou un port spécifique

Un service firewalld est une définition nommée pouvant inclure un ou plusieurs ports et protocoles. Il est généralement plus simple d'autoriser un service connu par son nom que de mémoriser son numéro de port. Consultez la liste des services installés et examinez une définition avant de l'utiliser.

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

Pour un serveur web, le httpservice prédéfini couvre généralement le port TCP 80 ; httpsun service distinct est dédié au trafic web TLS. La documentation SLES présente cette même méthode basée sur les services, avec des exemples tels que DHCP. Utilisez le service requis par votre application et, en cas de doute, vérifiez sa définition localement.

Si aucun service prédéfini ne convient, ouvrez uniquement le port et le protocole requis. Par exemple, une application écoutant sur le port TCP 8443 peut être autorisée --add-port=8443/tcp. L'ouverture d'un port dans le pare-feu ne lance pas l'application, ne la connecte pas au réseau et ne la sécurise pas ; assurez-vous que le service est bien configuré pour écouter sur l'adresse souhaitée.

Testez d'abord une règle temporaire

Pour un test rapide, appliquez une règle à la configuration d'exécution. Les modifications apportées en cours d'exécution sont prises en compte immédiatement, mais sont perdues après un rechargement du pare-feu ou un redémarrage du service, sauf si vous les enregistrez également de manière permanente. Firewalld prend en charge les règles à durée limitée, utiles pour faire expirer automatiquement un test.

sudo firewall-cmd --zone=public --add-service=http --timeout=5m

Pour un test de port ponctuel, utilisez --add-port=8443/tcp --timeout=5mà la place de --add-service=http. Sélectionnez la zone qui contient réellement l'interface du serveur ; ne copiez pas publicsi votre hôte utilise une autre zone.

4. Enregistrez la règle et rechargez firewalld

Lorsque vous êtes prêt à conserver une règle, ajoutez-la à la configuration permanente. L'exemple suivant autorise le protocole HTTP dans la zone publique :

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

Pour HTTPS, répétez la commande permanente avec --add-service=https. Pour un port d'application personnalisé, utilisez une commande telle que :

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

Ces exemples modifient d'abord la configuration permanente, puis la rechargent pour que la nouvelle règle devienne active. Un rechargement remplace également les paramètres d'exécution par la configuration permanente. Par conséquent, toute modification effectuée uniquement en cours d'exécution ailleurs peut être perdue. Avant de recharger un système de production, vérifiez les règles d'exécution et permanentes importantes, notamment celles relatives à l'accès à l'administration à distance.

Il existe également un flux de travail basé sur l'exécution : tester une règle en cours d'exécution, vérifier le bon fonctionnement du service, puis ajouter cette même règle --permanentet recharger. Évitez d'utiliser cette méthode --runtime-to-permanentcomme raccourci, sauf si vous souhaitez enregistrer toutes les règles en cours d'exécution, y compris les modifications temporaires apportées par d'autres administrateurs ou logiciels.

Comment vérifier que la modification a fonctionné ?

Vérifiez la règle d'exécution active et la règle enregistrée. Pour un service HTTP dans la zone publique, exécutez :

sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --permanent --zone=public --list-services
sudo firewall-cmd --check-config

La requête doit renvoyer un résultat yes, la liste des services permanents doit inclure le service concerné httpet la vérification de la configuration doit se terminer avec succès. Pour une règle de port, utilisez `--port` --query-port=8443/tcpet --list-ports`--port` dans les commandes équivalentes. Testez également depuis un client distinct pouvant accéder au serveur ; une requête de pare-feu local confirme la présence de la règle, et non la configuration DNS, le routage, les pare-feu en amont ou le bon fonctionnement de l'écouteur d'application.

Problèmes courants et solutions sûres

• La règle est présente, mais les connexions expirent toujours : assurez-vous qu’elle a bien été ajoutée à la zone associée à l’interface client. Vérifiez ensuite que l’application écoute sur l’adresse et le port attendus, et contrôlez le pare-feu réseau en amont.
• La règle fonctionnait jusqu'au rechargement : elle n'a probablement été ajoutée qu'à l'exécution. Ajoutez-la --permanentet rechargez, puis interrogez les deux configurations.
• L'accès SSH est vulnérable : vérifiez les services de la zone active et les services permanents avant de redémarrer. Si SSH est requis et absent, ajoutez le sshservice à la zone appropriée de manière permanente avant de redémarrer. Ne fermez pas votre session distante actuelle tant que vous n'avez pas testé une seconde connexion.
• Vous effectuez une migration depuis une version SUSE antérieure : SLES 15 a remplacé SuSEfirewall2 par firewalld. SUSE signale que les anciens profils de pare-feu présentent une compatibilité descendante limitée ; consultez le guide de migration plutôt que de supposer que toutes les anciennes règles ont été traduites.
• Il semble y avoir un conflit entre les règles : firewalld est conçu pour gérer les règles de pare-feu de l'hôte. SUSE déconseille de modifier séparément les mêmes règles avec des outils tels que `firewalld` iptables, car cela peut perturber la configuration active.

Pour supprimer un service ou un port permanent inutile, utilisez l'option correspondante --remove-serviceavec --remove-port, --permanentpuis rechargez et vérifiez à nouveau. Par exemple, supprimez HTTP de la zone publique avec sudo firewall-cmd --permanent --zone=public --remove-service=httpsuivi de sudo firewall-cmd --reload.

Auto-évaluation avant de terminer

• firewalldIl est en cours d'exécution et démarre au démarrage du serveur.
• Vous avez identifié la zone active de l'interface qui reçoit le trafic.
• Seul le service ou le port dont l'application a besoin est autorisé dans cette zone.
• L'administration à distance reste autorisée avant et après le rechargement.
• La règle apparaît dans les requêtes d'exécution et permanentes, et la vérification de la configuration est réussie.
• Un test de connexion depuis un autre hôte confirme que l'application est accessible.

Pour plus de détails spécifiques à cette version, consultez le guide du pare-feu SUSE SLES 15 SP7 , le manuel de firewall-cmd et les notes de firewalld sur la configuration d'exécution et permanente et l'ouverture d'un port ou d'un service .