N'ouvrez que le trafic Web dont votre serveur SLES 15 a besoin.

Exemple de scénario : Imaginons un administrateur préparant un serveur SLES 15 fictif nommé web01 pour héberger un petit site web public. L’objectif est d’autoriser le trafic HTTP entrant sur le port TCP 80 tout en conservant l’accès à l’administration SSH existante. Il s’agit d’un exemple illustratif, et non d’un compte rendu de test ni d’une affirmation selon laquelle toutes les installations SLES 15 possèdent les mêmes noms d’interface ou services.

Sur SLES 15, firewalldfirewalld est le pare-feu par défaut et firewall-cmdle gère. Commencez par identifier la zone active et vérifiez l'accès distant ; ajoutez ensuite le service minimal requis à cette zone dans la configuration permanente et redémarrez. Le guide de sécurité et de renforcement de SLES 15 SP7 de SUSE décrit ce modèle basé sur les zones et la distinction entre les règles d'exécution et les règles permanentes. Ces étapes supposent que firewalld est installé et en cours d'exécution ; les systèmes mis à niveau plus anciens peuvent nécessiter une vérification de migration distincte.

1. Vérifiez le service et la zone active avant de modifier les règles.

Connectez-vous via la console du serveur ou une session d'administration que vous pouvez récupérer en cas d'interruption de l'accès réseau. Si vous êtes connecté via SSH, maintenez cette session ouverte pendant que vous modifiez les paramètres du pare-feu. Vérifiez que firewalld est en cours d'exécution et identifiez la zone propriétaire de l'interface.

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

La première commande devrait afficher un résultat running. La commande `active-zones` liste les zones auxquelles sont attribuées des interfaces ou des adresses source ; il est possible qu'elle en affiche plusieurs. Dans l'exemple fictif `web01`, supposons qu'elle affiche publicune interface ens192. Utilisez la zone associée à l'interface réseau entrante dans les commandes suivantes. Ne présumez pas que l'interface est nommée eth0et ne présumez pas publicqu'elle est active simplement parce qu'il s'agit d'une valeur par défaut courante.

Vue illustrative du terminal montrant firewalld en cours d'exécution et l'interface ens192 attribuée à la zone publique
Vue illustrative du terminal pour la vérification initiale : firewalld indique être en cours d’exécution et ens192 apparaît dans la zone publique.

Si le service n'est pas en cours d'exécution, vérifiez son état avant de le démarrer : sudo systemctl status firewalldsur les installations SLES 15 standard, firewalld est installé et activé par défaut, mais les profils d'image, les mises à niveau ou la stratégie locale peuvent différer. S'il est installé mais arrêté, démarrez-le et activez-le uniquement après avoir vérifié que sa stratégie actuelle vous permet d'accéder aux ressources nécessaires : sudo systemctl enable --now firewalldsur un hôte géré à distance, vérifiez l'accès à la console et vos autorisations SSH avant d'activer un pare-feu dont vous ignorez les règles actuelles.

2. Confirmez la définition du service et préservez le protocole SSH.

Un service firewalld est un ensemble nommé de ports et de protocoles. Vérifiez la définition locale avant de l'ouvrir :

sudo firewall-cmd --info-service=http
sudo firewall-cmd --zone=public --list-all

Sous SLES, le httpservice prédéfini correspond au port TCP 80. La liste des zones vous permet de consulter les services et ports actuellement autorisés. Remplacez-la publicpar la zone active que vous avez trouvée. Si vous administrez le serveur via SSH, assurez-vous que ce service sshest autorisé dans cette zone avant de continuer. Le comportement d'installation de SLES et les politiques existantes peuvent varier ; il est donc préférable de vérifier plutôt que de se fier à une supposition. Si le démon SSH installé écoute sur un port non standard, une sshentrée de service générique risque de ne pas correspondre ; vérifiez d'abord le port d'écoute réel du démon et la politique de pare-feu en vigueur.

Vue illustrative du terminal montrant que le service HTTP prédéfini inclut le port TCP 80
Inspection de service illustrative : la définition du service HTTP indique le port TCP 80.

3. Ajoutez HTTP de façon permanente, puis chargez les règles enregistrées.

Firewalld gère des configurations distinctes, à l'exécution et permanentes. Une commande normale modifie uniquement les règles à l'exécution ; --permanentelle enregistre la configuration, mais n'active pas immédiatement la modification. Pour web01, ajoutez le service HTTP à la zone qui possède son interface publique :

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

Utilisez --zone-le explicitement afin que la règle ne soit pas appliquée par erreur dans une zone par défaut. Un rechargement applique les règles permanentes à l'exécution. Les modifications d'exécution non enregistrées sont perdues lors du rechargement ; il est donc important d'examiner et de conserver les règles temporaires nécessaires avant l'exécution. Pour tester un service avant de le rendre permanent, vous pouvez d'abord l'exécuter sudo firewall-cmd --zone=public --add-service=httpsans règle--permanent ; s'il fonctionne, ajoutez la règle permanente et rechargez. Un test d'exécution est perdu après un rechargement ou un redémarrage du pare-feu.

Vue illustrative du terminal montrant l'ajout permanent du protocole HTTP au réseau public et le rechargement de firewalld.
Exemple de séquence de commandes : enregistrez l’autorisation HTTP dans public, puis rechargez firewalld pour l’appliquer.

Si vous avez besoin d'un port spécifique plutôt que d'un service prédéfini, spécifiez à la fois le port et le protocole, par exemple --add-port=8080/tcp. Procédez ainsi uniquement si l'application écoute effectivement sur ce port. Autoriser un pare-feu ne lance pas de serveur web, ne crée pas de règle de groupe de sécurité cloud et ne configure pas de routeur en amont ; toutes les couches réseau doivent autoriser le trafic.

4. Vérifiez les accès et supprimez les règles devenues inutiles.

Vérifiez les configurations en cours et enregistrées :

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

Le résultat doit figurer httpdans les deux listes de services, et la vérification de la configuration doit s'effectuer sans erreur. Vérifiez également que l'application écoute localement, par exemple avec `sudo apt-get` sudo ss -lntp, et testez le site depuis un client du réseau cible. La présence d'une règle dans le pare-feu ne garantit pas l'accessibilité de bout en bout : le DNS, un pare-feu cloud, le routage et le serveur web lui-même peuvent bloquer ou faire échouer la requête.

Vue illustrative du terminal montrant HTTP dans la liste des services de la zone publique aux côtés de SSH
Exemple de résultat de vérification : HTTP apparaît parmi les services de la zone publique tandis que SSH reste listé.

Si le protocole HTTP n'est plus nécessaire, supprimez la règle enregistrée et rechargez-la : sudo firewall-cmd --permanent --zone=public --remove-service=http, suivi de sudo firewall-cmd --reload. Vérifiez ensuite les listes d'exécution et permanentes. Évitez de vider toutes les règles ou de basculer vers une zone de confiance pour résoudre un seul problème d'accès ; ces modifications plus importantes peuvent exposer des services non liés.

Notes de source

Pour des instructions spécifiques à cette version, consultez le Guide de sécurité et de renforcement de la sécurité de SUSE SLES 15 SP7 . Pour connaître le comportement des commandes selon les versions de firewalld, reportez-vous à la documentation de firewall-cmd et au guide de référence sur la configuration dynamique et permanente . Les options disponibles peuvent varier selon la version de firewalld fournie avec un Service Pack SLES donné ; consultez l’aide locale firewall-cmd --helpsi une commande est indisponible.

Laisser un commentaire

Diagnostic d'un serveur SUSE bloqué sur l'écran d'arrêt de systemd

Diagnostic d'un serveur SUSE bloqué sur l'écran d'arrêt de systemd

Utilisez les tâches systemd et le journal de démarrage précédent pour localiser un service, un montage ou une dépendance de stockage lents, puis corrigez-les sans masquer la cause.

N'ouvrez que le trafic Web dont votre serveur SLES 15 a besoin.

N'ouvrez que le trafic Web dont votre serveur SLES 15 a besoin.

Utilisez firewall-cmd pour inspecter la zone active, autoriser HTTP en toute sécurité, préserver l'accès SSH et vérifier que la règle survit à un rechargement sur SLES 15.

Diagnostiquer les échecs de connexion SLES PAM sans se bloquer l'accès.

Diagnostiquer les échecs de connexion SLES PAM sans se bloquer l'accès.

Identifiez la cause d'une défaillance PAM : service, politique de compte ou fournisseur d'identité, puis réparez la configuration SLES appropriée tout en préservant une session d'administration fonctionnelle.

Automatisez les sauvegardes Nextcloud cohérentes avec Restic et Cron

Automatisez les sauvegardes Nextcloud cohérentes avec Restic et Cron

Sauvegardez simultanément les fichiers de Nextcloud et de MariaDB, planifiez des instantanés Restic chiffrés avec cron et vérifiez la récupération sans risquer le serveur en production.

Debian 12 sur un VPS à faible RAM : Comment réduire les plantages MySQL dus à une erreur de mémoire insuffisante

Debian 12 sur un VPS à faible RAM : Comment réduire les plantages MySQL dus à une erreur de mémoire insuffisante

Diagnostiquer les erreurs OOM de MySQL sur Debian 12, vérifier les limites de mémoire du VPS, configurer le swap et optimiser la mémoire et la concurrence de la base de données sans promettre de solution universelle.

Sauvegarde et restauration d'une boîte aux lettres Zimbra CE à l'aide d'exportations TGZ

Sauvegarde et restauration d'une boîte aux lettres Zimbra CE à l'aide d'exportations TGZ

Exportez une boîte aux lettres individuelle de Zimbra Community Edition, validez sa sauvegarde TGZ et restaurez les éléments manquants sans écraser les messages existants.

Autoriser les utilisateurs approuvés à créer des salles Jitsi avec connexion Keycloak

Autoriser les utilisateurs approuvés à créer des salles Jitsi avec connexion Keycloak

Autoriser uniquement les comptes approuvés à créer des salles Jitsi Meet en utilisant l'authentification Keycloak et par jeton, tout en laissant la possibilité de rejoindre les invités en cas de besoin.

Ajout de polices au serveur de documents ONLYOFFICE : Docker ou Linux ?

Ajout de polices au serveur de documents ONLYOFFICE : Docker ou Linux ?

Installez des polices personnalisées dans ONLYOFFICE Document Server, comparez les montages Docker persistants avec les copies directes, reconstruisez la liste des polices et vérifiez le résultat.

Synchronisez les utilisateurs Active Directory avec ONLYOFFICE DocSpace via LDAP.

Synchronisez les utilisateurs Active Directory avec ONLYOFFICE DocSpace via LDAP.

Connectez ONLYOFFICE DocSpace à Active Directory ou OpenLDAP, importez les utilisateurs et les groupes en toute sécurité, mappez les champs de compte et planifiez une synchronisation fiable.

Intégrez ONLYOFFICE Docs derrière HAProxy sans interrompre l'édition.

Intégrez ONLYOFFICE Docs derrière HAProxy sans interrompre l'édition.

Configurez HAProxy HTTPS, le transfert des en-têtes, les délais d'expiration WebSocket et les contrôles d'intégrité pour ONLYOFFICE Docs, puis vérifiez les modifications et les enregistrements.