Accueil
» Comment faire
»
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.
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.
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 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 :
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.
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 :
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.
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 :
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.
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.