One place for hosting & domains

      parefeu

      UFW Essentials : règles et commandes de pare-feu


      Introduction

      UFW est un outil de configuration de pare-feu pour les iptables qui est inclus dans Ubuntu par défaut. Sous forme d’aide-mémo, ce guide vous permettra de trouver rapidement les commandes UFW qui créeront des règles de pare-feu iptables qui sont utiles dans les scénarios classiques du quotidien. Ceci intègre des exemples UFW d’autorisation et de blocage de plusieurs services par port, interface de réseau ou adresse IP source.

      • S’il s’agit de vos premiers pas avec UFW pour la configuration de pare-feu, consultez notre introduction à UFW
      • La plupart des règles décrites ici supposent que vous utilisez le règlement UFW par défaut. En effet, il est configuré pour autoriser le trafic sortant et refuser le trafic entrant, par défaut. Par conséquent, vous pouvez autoriser le trafic de manière sélective par le biais des politiques par défaut.
      • Utilisez les sections suivantes pour réaliser ce que vous tentez de faire. La plupart des sections ne sont prédites sur aucune autre. Vous pouvez donc utiliser les exemples ci-dessous indépendamment
      • Utilisez le menu Contents sur le côté droit de cette page (sur les largeurs de page large) ou la fonction de recherche de votre navigateur pour localiser les sections dont vous avez besoin
      • Copiez et collez les exemples de ligne de commande donnés, en substituant les valeurs en rouge par vos propres valeurs

      N’oubliez pas que vous pouvez vérifier votre règlement UFW actuel avec sudo ufw status ou sudo ufw status verbose.

      Bloquer une adresse IP

      Pour bloquer toutes les connexions réseau qui proviennent d’une adresse IP spécifique, 15.15.15.51 par exemple, exécutez la commande suivante :

      • sudo ufw deny from 15.15.15.51

      Dans cet exemple, from 15.15.15.51 spécifie une adresse IP source de « 15.15.15.51 ». Si vous le souhaitez, vous pouvez spécifier ici un sous-réseau, tel que 15.15.15.0/24 à la place. L’adresse IP source peut être spécifiée dans toute règle de pare-feu, notamment une règle allow.

      Bloquer les connexions à une interface réseau

      Pour bloquer les connexions d’une adresse IP spécifique, par exemple 15.15.15.51 à une interface réseau spécifique, par exemple eth0, utilisez la commande suivante :

      • sudo ufw deny in on eth0 from 15.15.15.51

      C’est la même chose que dans l’exemple précédent, en ajoutant in on eth0. Vous pouvez spécifier l’interface réseau dans n’importe quelle règle de pare-feu. C’est un excellent moyen de limiter la règle à un réseau spécifique.

      Service : SSH

      Si vous utilisez un serveur cloud, vous voudrez probablement autoriser les connexions SSH entrantes (port 22) afin de pouvoir vous connecter à votre serveur et le gérer. Cette section vous montre de quelle manière configurer votre pare-feu avec plusieurs règles liées au SSH.

      Autoriser SSH

      Pour autoriser toutes les connexions SSH entrantes, exécutez la commande suivante :

      Voici une autre syntaxe qui vous permettra de spécifier le numéro de port du service SSH :

      Autoriser un SSH entrant à partir de l'adresse IP ou un sous-réseau spécifique

      Pour autoriser les connexions SSH entrantes à partir d'une adresse IP ou d'un sous-réseau spécifique, vous devez spécifier la source. Par exemple, si vous souhaitez autoriser l'intégralité du sous-réseau 15.15.15.0/24, vous devez exécuter la commande suivante :

      • sudo ufw allow from 15.15.15.0/24  to any port 22

      Autoriser un Rsync entrant à partir de l'adresse IP ou un sous-réseau spécifique

      Vous pouvez utiliser Rsync, qui fonctionne sur le port 873, pour transférer des fichiers d'un ordinateur à un autre.

      Pour autoriser les connexions rsync entrantes à partir d'une adresse IP ou d'un sous-réseau spécifique, vous devez spécifier l'adresse IP source et le port de destination. Par exemple, si vous souhaitez autoriser que l'intégralité du sous-réseau 15.15.15.0/24 soit en mesure de rsync sur votre serveur, exécutez la commande suivante :

      • sudo ufw allow from 15.15.15.0/24 to any port 873

      Service : serveur web

      Les serveurs Web, comme Apache et Nginx, écoutent généralement les requêtes des connexions HTTP et HTTPS sur le port 80 et 443, respectivement. Si votre politique pour le trafic entrant est configurée sur drop ou deny par défaut, il vous faudra créer des règles qui permettront à votre serveur de répondre à ces requêtes.

      Autoriser tous les HTTP entrants

      Pour autoriser toutes les connexions HTTP entrantes (port 80), exécutez la commande suivante :

      Vous pouvez également utiliser une autre syntaxe en spécifiant le numéro de port du service HTTP :

      Autoriser tous les HTTP entrants

      Exécutez la commande suivante pour autoriser toutes les connexions HTTPS entrantes (port 443) :

      Vous pouvez également utiliser une autre syntaxe en spécifiant le numéro de port du service HTTPS :

      Autoriser tout le trafic HTTP et HTTPS entrant

      Si vous souhaitez autoriser le trafic à la fois HTTP et HTTPS, vous pouvez créer une règle unique qui autorise les deux ports. Pour autoriser toutes les connexions HTTP et HTTPS entrantes (port 443), exécutez la commande suivante :

      • sudo ufw allow proto tcp from any to any port 80,443

      Notez que vous devez indiquer le protocole en utilisant proto tcp lorsque vous spécifiez plusieurs ports.

      Service : MySQL

      MySQL écoute les connexions des clients sur le port 3306. Si un client utilise votre serveur de base de données MySQL sur un serveur distant, vous devez avoir la garantie de bien autoriser ce trafic.

      Autoriser MySQL à partir de l'adresse IP ou un sous-réseau spécifique

      Pour autoriser les connexions MySQL entrantes à partir d'une adresse IP ou d'un sous-réseau spécifique, vous devez spécifier la source. Par exemple, si vous souhaitez autoriser l'intégralité du sous-réseau 15.15.15.0/24, vous devez exécuter la commande suivante :

      • sudo ufw allow from 15.15.15.0/24 to any port 3306

      Autoriser MySQL sur l'interface réseau spécifique

      Disons que vous disposez par exemple d'une interface réseau privée eth1, vous devez utiliser la commande suivante pour autoriser les connexions MySQL sur une interface réseau spécifique :

      • sudo ufw allow in on eth1 to any port 3306

      Service : PostgreSQL

      PostgreSQL écoute les connexions des clients sur le port 5432. Si un client utilise votre serveur de base de données PostgreSQL sur un serveur distant, vous devez avoir la garantie de bien autoriser ce trafic.

      PostgreSQL à partir d'une adresse IP ou un sous-réseau spécifique

      Pour autoriser les connexions PostgreSQL entrantes à partir d'une adresse IP ou d'un sous-réseau spécifique, vous devez spécifier la source. Par exemple, si vous souhaitez autoriser l'intégralité du sous-réseau 15.15.15.0/24, vous devez exécuter la commande suivante :

      • sudo ufw allow from 15.15.15.0/24 to any port 5432

      La deuxième commande qui autorise le trafic sortant des connexions PostgreSQL established, n'est nécessaire que si la politique OUTPUT n'est pas défini sur ACCEPT.

      Autoriser PostgreSQL sur une interface réseau spécifique

      Disons que vous disposez par exemple d'une interface réseau privée eth1, vous devez utiliser la commande suivante pour autoriser les connexions PostgreSQL sur une interface réseau spécifique :

      • sudo ufw allow in on eth1 to any port 5432

      La deuxième commande qui autorise le trafic sortant des connexions PostgreSQL established, n'est nécessaire que si la politique OUTPUT n'est pas défini sur ACCEPT.

      Service : Mail

      Les serveurs de courrier électronique, comme Sendmail et Postfix, écoutent sur une variété de ports en fonction des protocoles utilisés pour livrer les courriels. Si vous utilisez un serveur de messagerie, vous devez déterminer les protocoles que vous utilisez et autoriser les types de trafic applicables. Nous allons également vous montrer de quelle manière créer une règle pour bloquer les courriels SMTP sortants.

      Bloquer un courriel SMTP sortant

      Si votre serveur ne doit pas envoyer de courriel sortant, il vous faudra bloquer ce type de trafic. Pour bloquer les courriels SMTP sortants, qui utilise le port 25, exécutez la commande suivante :

      Vous configurez votre pare-feu de sorte qu'il drop tout le trafic sortant sur le port 25. Si vous devez rejeter un autre service en fonction de son numéro de port, vous pouvez l'utiliser à la place du port 25, vous devez simplement le remplacer.

      Autoriser tous les SMTP entrants

      Pour permettre à votre serveur de répondre aux connexions SMTP, port 25, exécutez la commande suivante :

      Remarque : il est courant que les serveurs SMTP utilisent le port 587 pour le courrier sortant.

      Autoriser tous les IMAP entrants

      Pour permettre à votre serveur de répondre aux connexions IMAP, port 143, exécutez la commande suivante :

      Autoriser tous les IMAPS entrants

      Pour permettre à votre serveur de répondre aux connexions IMAPS, port 993, exécutez la commande suivante :

      Autoriser tous les POP3 entrants

      Pour permettre à votre serveur de répondre aux connexions POP3, port 110, exécutez la commande suivante :

      Autoriser tous les POP3S entrants

      Pour permettre à votre serveur de répondre aux connexions POP3S, port 995, exécutez la commande suivante :

      Conclusion

      Ainsi, vous devriez couvrir plusieurs des commandes que l'on utilise couramment pour configurer un pare-feu en utilisant UFW. Bien entendu, UFW est un outil très flexible. N'hésitez pas à combiner les commandes avec différentes options selon vos besoins spécifiques si elles ne sont pas couvertes ici.

      Bonne chance !



      Source link

      Comment mettre en place un pare-feu avec UFW sur Ubuntu 20.04


      Introduction

      UFW, ou Uncomplicated Firewall, est une interface de gestion de pare-feu simplifiée qui masque la complexité des technologies de filtrage de paquets de niveau inférieur telles que iptables et nftables. Si vous souhaitez commencer à sécuriser votre réseau, et vous n’êtes pas sûr de l’outil à utiliser, UFW peut être le bon choix pour vous.

      Ce tutoriel vous montrera comment mettre en place un pare-feu avec UFW sur Ubuntu 20.04.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      UFW est installé par défaut sur Ubuntu. S’il a été désinstallé pour une raison quelconque, vous pouvez l’installer avec sudo apt install ufw.

      Étape 1 — Utilisation d’IPv6 avec UFW (facultatif)

      Ce tutoriel a été écrit en tenant compte d’IPv4, mais il fonctionnera aussi bien pour IPv6 pour autant que vous l’ayez activé. Si votre serveur Ubuntu a activé IPv6, assurez-vous qu’UFW est configuré pour prendre en charge IPv6 afin de gérer les règles de pare-feu pour IPv6 en plus d’IPv4. Pour ce faire, ouvrez la configuration UFW avec nano ou votre éditeur préféré.

      • sudo nano /etc/default/ufw

      Ensuite, assurez-vous que la valeur d’IPV6 est yes. Cela devrait ressembler à ceci :

      /etc/default/ufw excerpt

      IPV6=yes

      Enregistrez et fermez le fichier. Maintenant, lorsque l’UFW est activé, il sera configuré pour écrire les règles de pare-feu IPv4 et IPv6. Cependant, avant d’activer UFW, nous voulons nous assurer que votre pare-feu est configuré pour vous permettre de vous connecter via SSH. Commençons par définir les politiques par défaut.

      Étape 2 — Mise en place des politiques par défaut

      Si vous commencez tout juste à utiliser votre pare-feu, les premières règles à définir sont vos politiques par défaut. Ces règles contrôlent la manière de traiter le trafic qui ne correspond pas explicitement à d’autres règles. Par défaut, UFW est configuré pour refuser toutes les connexions entrantes et autoriser toutes les connexions sortantes. Cela signifie que toute personne essayant d’atteindre votre serveur ne pourra pas se connecter, tandis que toute application à l’intérieur du serveur pourra atteindre le monde extérieur.

      Remettons vos règles UFW à leur valeur par défaut afin que nous puissions être sûrs que vous pourrez suivre ce tutoriel. Pour définir les valeurs par défaut utilisées par UFW, utilisez ces commandes :

      • sudo ufw default deny incoming

      • sudo ufw default allow outgoing

      Ces commandes définissent les valeurs par défaut pour refuser les connexions entrantes et autoriser les connexions sortantes. Ces paramètres par défaut du pare-feu peuvent suffire pour un ordinateur personnel, mais les serveurs doivent généralement répondre aux demandes entrantes d’utilisateurs extérieurs. Nous verrons cela plus loin.

      Étape 3 — Autoriser les connexions SSH

      Si nous activions notre pare-feu UFW maintenant, il refuserait toutes les connexions entrantes. Cela signifie que nous devrons créer des règles qui autorisent explicitement les connexions entrantes légitimes – connexions SSH ou HTTP, par exemple – si nous voulons que notre serveur réponde à ce type de demandes. Si vous utilisez un serveur cloud, vous voudrez probablement autoriser les connexions SSH entrantes afin de pouvoir vous connecter à votre serveur et le gérer.

      Pour configurer votre serveur afin d’autoriser les connexions SSH entrantes, vous pouvez utiliser cette commande :

      Cela créera des règles de pare-feu qui autoriseront toutes les connexions sur le port 22, qui est le port que le démon SSH écoute par défaut. UFW sait quel port allow ssh désigne parce qu’il est listé comme un service dans le fichier /etc/services.

      Cependant, nous pouvons réellement écrire la règle équivalente en spécifiant le port au lieu du nom du service. Par exemple, cette commande fonctionne de la même manière que celle ci-dessus :

      Si vous avez configuré votre démon SSH pour utiliser un port différent, vous devrez spécifier le port approprié. Par exemple, si votre serveur SSH écoute sur le port 2222, vous pouvez utiliser cette commande pour autoriser les connexions sur ce port :

      Maintenant que votre pare-feu est configuré pour autoriser les connexions SSH entrantes, nous pouvons l’activer.

      Étape 4 — Activation d’UFW

      Pour activer UFW, utilisez cette commande :

      Vous recevrez un avertissement qui indique que la commande peut perturber les connexions SSH existantes. Nous avons déjà mis en place une règle de pare-feu qui autorise les connexions SSH, donc nous pouvons continuer. Répondez à l’invite avec y et appuyez sur ENTER.

      Le pare-feu est maintenant actif. Exécutez la commande sudo ufw status verbose pour connaître les règles fixées. Le reste de ce tutoriel explique plus en détail comment utiliser UFW, par exemple en autorisant ou en refusant différents types de connexions.

      Étape 5 — Autoriser d’autres connexions

      À ce stade, vous devez autoriser toutes les autres connexions auxquelles votre serveur a besoin de répondre. Les connexions que vous devez autoriser dépendent de vos besoins spécifiques. Heureusement, vous savez déjà comment écrire des règles qui autorisent les connexions basées sur un nom de service ou un port ; nous l’avons déjà fait pour SSH sur le port 22. Vous pouvez également le faire pour :

      • HTTP sur le port 80, qui est ce qu’utilisent les serveurs web non cryptés, en utilisant sudo ufw allow http ou sudo ufw allow 80
      • HTTPS sur le port 443, qui est ce qu’utilisent les serveurs web cryptés, en utilisant sudo ufw allow https ou sudo ufw allow 443

      Il existe plusieurs autres moyens d’autoriser d’autres connexions, outre la spécification d’un port ou d’un service connu.

      Plages de ports spécifiques

      Vous pouvez spécifier des plages de ports avec UFW. Certaines applications utilisent plusieurs ports, au lieu d’un seul.

      Par exemple, pour autoriser les connexions X11 qui utilisent les ports 6000–6007, utilisez ces commandes :

      • sudo ufw allow 6000:6007/tcp

      • sudo ufw allow 6000:6007/udp

      Lorsque vous spécifiez des plages de ports avec UFW, vous devez spécifier le protocole (tcp ou udp) auquel les règles doivent s’appliquer. Nous n’avons pas mentionné cela auparavant car le fait de ne pas spécifier le protocole autorise automatiquement les deux protocoles, ce qui est correct dans la plupart des cas.

      Adresses IP spécifiques

      Lorsque vous travaillez avec UFW, vous pouvez également spécifier des adresses IP. Par exemple, si vous souhaitez autoriser les connexions à partir d’une adresse IP spécifique, comme une adresse IP professionnelle ou personnelle de 203.0.113.4, vous devez spécifier from, puis l’adresse IP :

      • sudo ufw allow from 203.0.113.4

      Vous pouvez également spécifier un port spécifique auquel l’adresse IP est autorisée à vous connecter en ajoutant to any port suivi du numéro de port. Par exemple, Si vous souhaitez autoriser 203.0.113.4 à se connecter au port 22 (SSH), utilisez cette commande :

      • sudo ufw allow from 203.0.113.4 to any port 22

      Sous réseaux

      Si vous souhaitez autoriser un sous-réseau d’adresses IP, vous pouvez le faire en utilisant la notation CIDR pour spécifier un masque de réseau. Par exemple, si vous souhaitez autoriser toutes les adresses IP allant de 203.0.113.1 à 203.0.113.254 vous pourriez utiliser cette commande :

      • sudo ufw allow from 203.0.113.0/24

      De même, vous pouvez également spécifier le port de destination auquel le sous-réseau 203.0.113.0/24 est autorisé à se connecter. Une fois encore, nous utiliserons le port 22 (SSH) comme exemple :

      • sudo ufw allow from 203.0.113.0/24 to any port 22

      Connexion à une interface réseau spécifique

      Si vous souhaitez créer une règle de pare-feu qui s’applique uniquement à une interface réseau spécifique, vous pouvez le faire en spécifiant « allow in on » suivi du nom de l’interface.

      Vous pouvez consulter vos interfaces réseau avant de continuer. Pour ce faire, utilisez cette commande :

      Output Excerpt
      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
. . .
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
. . .

      Le résultat mis en évidence indique les noms d’interface réseau. Elles sont généralement nommées par quelque chose comme : eth0 ou enp3s2.

      Donc, si votre serveur a une interface réseau publique appelée eth0, vous pouvez l’autoriser à recevoir du trafic HTTP (port 80) avec cette commande :

      • sudo ufw allow in on eth0 to any port 80

      Cela permettrait à votre serveur de recevoir des requêtes HTTP de l’Internet public.

      Ou, si vous voulez que votre serveur de base de données MySQL (port 3306) écoute les connexions sur l’interface de réseau privé eth1, par exemple, vous pourriez utiliser cette commande :

      • sudo ufw allow in on eth1 to any port 3306

      Cela permettrait à d’autres serveurs de votre réseau privé de se connecter à votre base de données MySQL.

      Étape 6 — Refuser les connexions

      Si vous n’avez pas modifié la politique par défaut des connexions entrantes, UFW est configuré pour refuser toutes les connexions entrantes. En général, cela simplifie le processus de création d’une politique de pare-feu sécurisée en vous obligeant à créer des règles qui autorisent explicitement le passage de ports et d’adresses IP spécifiques.

      Cependant, il peut arriver que vous souhaitiez refuser des connexions spécifiques en fonction de l’adresse IP source ou du sous-réseau, peut-être parce que vous savez que votre serveur est attaqué à partir de là. De plus, si vous souhaitez modifier votre politique d’entrée par défaut a allow (ce qui n’est pas recommandé), vous devrez créer des règles deny pour tous les services ou adresses IP pour lesquels vous ne souhaitez pas autoriser les connexions.

      Pour écrire des règles deny, vous pouvez utiliser les commandes décrites ci-dessus, en remplaçant allow par deny.

      Par exemple, pour refuser des connexions HTTP, vous pourriez utiliser cette commande :

      Ou si vous souhaitez refuser toutes les connexions à partir de 203.0.113.4 vous pouvez utiliser cette commande :

      • sudo ufw deny from 203.0.113.4

      Examinons maintenant comment supprimer des règles.

      Étape 7 — Suppression de règles

      Savoir comment supprimer des règles de pare-feu est tout aussi important que de savoir comment les créer. Il existe deux façons différentes de spécifier les règles à supprimer : par le numéro de la règle ou par la règle elle-même (de la même façon que les règles ont été spécifiées lors de leur création). Nous commencerons par la méthode delete by rule number, car elle est plus facile.

      Par numéro de règle

      Si vous utilisez le numéro de règle pour supprimer des règles de pare-feu, la première chose que vous voudrez faire est d’obtenir une liste de vos règles de pare-feu. La commande UFW status permet d’afficher des numéros à côté de chaque règle, comme illustré ici :

      Numbered Output:
      Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22                         ALLOW IN    15.15.15.0/24
[ 2] 80                         ALLOW IN    Anywhere

      Si nous décidons que nous voulons supprimer la règle 2, celle qui autorise les connexions sur le port 80 (HTTP), nous pouvons la spécifier dans une commande de suppression UFW comme celle-ci :

      Cela affichera une demande de confirmation puis supprimera la règle 2, qui autorise les connexions HTTP. Notez que si vous avez activé IPv6, vous voudrez également supprimer la règle IPv6 correspondante.

      Par règle réelle

      L’alternative aux numéros de règle est de spécifier la règle réelle à supprimer. Par exemple, si vous voulez supprimer la règle allow http, vous pouvez l’écrire comme ceci :

      • sudo ufw delete allow http

      Vous pouvez également spécifier la règle par allow 80, au lieu de par nom de service :

      Cette méthode supprimera les règles IPv4 et IPv6, si elles existent.

      Étape 8 — Vérification de l’état et des règles d’UFW

      À tout moment, vous pouvez vérifier le statut d’UFW avec cette commande :

      Si UFW est désactivé, ce qui est le cas par défaut, vous verrez quelque chose comme ceci :

      Output
      Status: inactive

      Si UFW est actif, ce qui devrait être le cas si vous avez suivi l’étape 3, la sortie indiquera qu’il est actif et énumérera toutes les règles qui sont définies. Par exemple, si le pare-feu est configuré pour autoriser les connexions SSH (port 22) de n’importe où, la sortie pourrait ressembler à ceci :

      Output
      Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere

      Utilisez la commande status si vous souhaitez vérifier comment UFW a configuré le pare-feu.

      Étape 9 – Désactivation ou réinitialisation d’UFW (facultatif)

      Si vous décidez que vous ne voulez pas utiliser UFW, vous pouvez le désactiver avec cette commande :

      Toutes les règles que vous avez créées avec UFW ne seront plus actives. Vous pourrez toujours exécuter la commande sudo ufw enable si vous devez l’activer plus tard.

      Si vous avez déjà configuré des règles UFW mais que vous décidez de tout recommencer, vous pouvez utiliser la commande reset :

      Cela désactivera l’UFW et supprimera toutes les règles qui ont été définies précédemment. Gardez à l’esprit que les règles par défaut ne retrouveront pas leurs paramètres d’origine, si vous les avez modifiées à un moment quelconque. Cela devrait vous permettre de repartir à zéro avec UFW.

      Conclusion

      Votre pare-feu est maintenant configuré pour autoriser (au moins) les connexions SSH. Veillez à autoriser toutes les autres connexions entrantes dont votre serveur a besoin, tout en limitant les connexions inutiles, afin que votre serveur soit fonctionnel et sécurisé.

      Pour en savoir plus sur les configurations UFW les plus courantes, consultez le tutoriel UFW Essentials : Règles et commandes communes de pare-feu.



      Source link

      Comment configurer un pare-feu en utilisant firewalld sur CentOS 8


      Introduction

      firewalld est un logiciel de gestion de pare-feu disponible pour de nombreuses distributions Linux, qui fait office d interface pour les systèmes de filtrage de paquets nftables ou iptables du noyau de Linux.

      Dans ce guide, nous allons vous montrer comment mettre en place un pare-feu pour votre serveur CentOS 8, et aborder les bases de la gestion du pare-feu avec l’outil d’administration firewall-cmd.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin d’un serveur qui exécute CentOS 8. Nous supposerons que vous êtes connecté à ce serveur en tant qu’utilisateur non root et sudo. Pour le configurer, consultez notre Guide de configuration initiale du serveur pour CentOS 8.

      Concepts de base dans firewalld

      Avant de commencer à parler de la façon d’utiliser réellement l’utilitaire firewall-cmd pour gérer la configuration de votre pare-feu, nous devons nous familiariser avec quelques concepts que l’outil introduit.

      Zones

      Le démon firewalld gère des groupes de règles en utilisant des entités appelées zones. Les zones sont des ensembles de règles qui dictent quel trafic doit être autorisé en fonction du niveau de confiance que vous avez dans le réseau. Les interfaces réseau sont attribuées à une zone pour dicter le comportement que le pare-feu devrait autoriser.

      Pour les ordinateurs susceptibles de passer fréquemment d’un réseau à l’autre (comme les ordinateurs portables), ce type de flexibilité constitue une bonne méthode pour modifier vos règles en fonction de votre environnement. Vous pouvez avoir mis en place des règles strictes interdisant la plupart du trafic lorsque vous opérez sur un réseau WiFi public, tout en autorisant des restrictions plus souples lorsque vous êtes connecté à votre réseau domestique. Pour un serveur, ces zones ne sont souvent pas aussi importantes car l’environnement réseau change rarement, voire jamais.

      Quelle que soit la dynamique de votre environnement réseau, il est toujours utile de se familiariser avec l’idée générale qui se cache derrière chacune des zones prédéfinies pour firewalld.  Les zones prédéfinies au sein de firewalld sont, dans l’ordre, de la moins fiable à la plus fiable :

      • drop : le niveau de confiance le plus bas. Toutes les connexions entrantes sont interrompues sans réponse et seules les connexions sortantes sont possibles.
      • block : similaire à ce qui précède, mais au lieu de simplement interrompre les connexions, les demandes entrantes sont rejetées avec un message icmp-host-prohibited ou icmp6-adm-prohibited.
      • public : représente les réseaux publics, non fiables. Vous ne faites pas confiance aux autres ordinateurs, mais vous pouvez autoriser certaines connexions entrantes au cas par cas.
      • external : les réseaux externes dans l’éventualité où vous utilisez le pare-feu comme passerelle. Il est configuré pour le masquage NAT de sorte que votre réseau interne reste privé mais accessible.
      • interne : l’autre côté de la zone externe, utilisé pour la partie interne d’une passerelle. Les ordinateurs sont assez fiables et certains services supplémentaires sont disponibles.
      • dmz : utilisé pour les ordinateurs situés dans un DMZ (ordinateurs isolés qui n’auront pas accès au reste de votre réseau). Seules certaines connexions entrantes sont autorisées.
      • work : utilisé pour les machines de travail. Fait confiance à la plupart des ordinateurs du réseau. Quelques services supplémentaires pourraient être autorisés.
      • home : un environnement domestique. Cela implique généralement que vous faites confiance à la plupart des autres ordinateurs et que quelques services supplémentaires seront acceptés.
      • trusted : fais confiance à toutes les machines du réseau. La plus ouverte des options disponibles et doit être utilisée avec parcimonie.

      Pour utiliser le pare-feu, nous pouvons créer des règles et modifier les propriétés de nos zones, puis affecter nos interfaces réseau aux zones les plus appropriées.

      Permanence de la règle

      Dans firewalld, les règles peuvent être appliquées au jeu de règles d’exécution actuel ou être rendues permanentes. Lorsqu’une règle est ajoutée ou modifiée, par défaut, seul le pare-feu en cours d’exécution est modifié. Après le prochain redémarrage – ou rechargement du service firewalld – seules les règles permanentes subsisteront.

      La plupart des opérations firewall-cmd peuvent prendre un drapeau --permanent pour indiquer que les changements doivent être appliqués à la configuration permanente. En outre, le pare-feu en cours d’exécution peut être enregistré dans la configuration permanente avec la commande firewall-cmd --runtime-to-permanent

      Cette séparation entre les configurations d’exécution et permanente signifie que vous pouvez tester en toute sécurité les règles dans votre pare-feu actif, puis les recharger pour recommencer à zéro en cas de problème.

      Installation et activation de firewalld

      firewalld est installé par défaut sur certaines distributions Linux, dont de nombreuses images de CentOS 8. Cependant, il peut vous être nécessaire d’installer firewalld vous-même :

      • sudo dnf install firewalld

      Après avoir installé firewalld, vous pouvez activer le service et redémarrer de votre serveur. Gardez à l’esprit que l’activation de firewalld entraînera le lancement du service au démarrage. Il est préférable de créer vos règles de pare-feu et de profiter de l’occasion pour les tester avant de configurer ce comportement afin d’éviter les problèmes potentiels.

      • sudo systemctl enable firewalld

      • sudo systemctl start firewalld

      Lorsque le serveur redémarre, votre pare-feu devrait s’afficher, vos interfaces réseau devraient être placées dans les zones que vous avez configurées (ou retomber dans la zone par défaut configurée), et toutes les règles associées à la ou aux zones seront appliquées aux interfaces associées.

      Nous pouvons vérifier que le service fonctionne et est accessible en tapant :

      • sudo firewall-cmd --state

      Output
      running

      Cela indique que notre pare-feu est opérationnel avec la configuration par défaut.

      Se familiariser avec les règles actuelles du pare-feu

      Avant de commencer à apporter des modifications, nous devrions nous familiariser avec l’environnement et les règles par défaut fournis par firewalld.

      Explorer les valeurs par défaut

      Nous pouvons voir quelle zone est actuellement sélectionnée comme étant la zone par défaut en tapant :

      • firewall-cmd --get-default-zone

      Output
      public

      Comme nous n’avons donné à Firewalld aucune commande pour dévier de la zone par défaut, et qu’aucune de nos interfaces n’est configurée pour se lier à une autre zone, cette zone sera également la seule zone active (la zone qui contrôle le trafic de nos interfaces).  Nous pouvons vérifier cela en tapant :

      • firewall-cmd --get-active-zones

      Output
      public
  interfaces: eth0 eth1

      Ici, nous pouvons voir que notre serveur d’exemple possède deux interfaces réseau contrôlées par le pare-feu (eth0 et eth1). Elles sont toutes deux gérées actuellement en fonction des règles définies pour la zone public.

      Mais comment savoir quelles sont les règles associées à la zone public ? Nous pouvons imprimer la configuration de la zone par défaut en tapant :

      • sudo firewall-cmd --list-all

      Output
      public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

      Nous pouvons dire à partir de la sortie que cette zone est à la fois par défaut et active, et que les interfaces eth0 et eth1 sont associées à cette zone (nous savions déjà tout cela lors de nos précédentes demandes). Cependant, nous pouvons également voir que cette zone permet le trafic d’un client DHCP (pour l’attribution d’adresses IP), SSH (pour l’administration à distance), et Cockpit (une console basée sur le web).

      Explorer les zones alternatives

      Nous avons maintenant une bonne idée de la configuration pour la zone par défaut et active. Nous pouvons également trouver des informations sur d’autres zones.

      Pour obtenir une liste des zones disponibles, tapez :

      Output
      block dmz drop external home internal public trusted work

      Nous pouvons voir la configuration spécifique associée à une zone en incluant le paramètre --zone= dans notre commande --list-all :

      • sudo firewall-cmd --zone=home --list-all

      Output
      home
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: cockpit dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

      Vous pouvez produire toutes les définitions de zones en utilisant l’option --list-all-zones. Vous allez probablement acheminer la sortie dans un pager pour qu’elle soit plus facile à consulter :

      • sudo firewall-cmd --list-all-zones | less

      Ensuite, nous allons apprendre à assigner des zones aux interfaces de réseau.

      Sélection de zones pour vos interfaces

      À moins que vous n’ayez configuré vos interfaces de réseau autrement, chaque interface sera mise dans la zone par défaut lorsque le pare-feu est démarré.

      Changer la zone d’une interface

      Vous pouvez déplacer une interface entre les zones pendant une session en utilisant le paramètre --zone= en combinaison avec le paramètre --change-interface= Comme pour toutes les commandes qui modifient le pare-feu, vous devrez utiliser sudo.

      Par exemple, nous pouvons déplacer notre interface eth0 vers la zone home en tapant ceci :

      • sudo firewall-cmd --zone=home --change-interface=eth0

      Output
      success

      Remarque : chaque fois que vous déplacez une interface vers une nouvelle zone, sachez que vous modifiez probablement les services qui seront opérationnels. Par exemple, ici nous nous déplaçons vers la zone home, qui dispose de SSH.  Cela signifie que notre connexion ne doit pas être interrompue. Certaines autres zones n’ont pas SSH activé par défaut, et le passage à l’une de ces zones pourrait entraîner la perte de votre connexion, vous empêchant de vous reconnecter à votre serveur.

      Nous pouvons vérifier que cela a réussi en demandant à nouveau les zones actives :

      • firewall-cmd --get-active-zones

      Output
      home
  interfaces: eth0
public
  interfaces: eth1

      Ajuster la zone par défaut

      Si toutes vos interfaces peuvent être bien gérées par une seule zone, il est probablement plus facile de désigner la meilleure zone comme zone par défaut et de l’utiliser ensuite pour votre configuration.

      Vous pouvez modifier la zone par défaut avec le paramètre --set-default-zone= Cela changera immédiatement toute interface utilisant la zone par défaut :

      • sudo firewall-cmd --set-default-zone=home

      Output
      success

      Définir des règles pour vos applications

      Passons en revue la méthode de base pour définir les exceptions de pare-feu pour les services que vous souhaitez rendre disponibles.

      Ajouter un service à vos zones

      La méthode la plus simple consiste à ajouter les services ou les ports dont vous avez besoin aux zones que vous utilisez. Vous pouvez obtenir une liste des définitions de service disponibles avec l’option --get-services :

      • firewall-cmd --get-services

      Output
      RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bb bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc bittorrent-lsd ceph ceph-mon cfengine cockpit condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns dns-over-tls docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server finger freeipa-4 freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git grafana gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kdeconnect kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns memcache minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy prometheus proxy-dhcp ptp pulseaudio puppetmaster quassel radius rdp redis redis-sentinel rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync spotify-sync squid ssdp ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tentacle tftp tftp-client tile38 tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server

      Remarque : vous pouvez obtenir plus de détails sur chacun de ces services en consultant le fichier .xml qui leur est associé dans le répertoire /usr/lib/firewalld/services. Par exemple, le service SSH est défini comme ceci :

      /usr/lib/firewalld/services/ssh.xml

      <?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="22"/>
</service>

      Vous pouvez activer un service pour une zone en utilisant le paramètre --add-service= L’opération ciblera la zone par défaut ou toute zone est spécifiée par le paramètre --zone=. Par défaut, cela n’ajustera que la session de pare-feu actuelle. Vous pouvez ajuster la configuration du pare-feu permanent en incluant le drapeau --permanent.

      Par exemple, si nous exploitons un serveur web desservant un trafic HTTP classique, nous pouvons temporairement autoriser ce trafic pour les interfaces dans notre zone public en tapant :

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

      Vous pouvez omettre le drapeau --zone= si vous souhaitez modifier la zone par défaut. Nous pouvons vérifier que l’opération a réussi en utilisant les opérations --list-all ou --list-services :

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

      Output
      cockpit dhcpv6-client http ssh

      Une fois que vous avez vérifié que tout fonctionne comme il devrait, vous allez probablement vouloir modifier les règles de pare-feu permanent de sorte que votre service soit toujours disponible après un redémarrage. Nous pouvons rendre notre changement précédent permanent en le répétant et en ajoutant le drapeau --permanent :

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

      Output
      success

      Vous pouvez également utiliser le drapeau --runtime-to-permanent pour enregistrer la configuration du pare-feu en cours d’exécution dans la configuration permanente :

      • sudo firewall-cmd --runtime-to-permanent

      Faites attention à cela, car toutes les modifications apportées au pare-feu en cours d’exécution seront appliquées de manière permanente.

      Quelle que soit la méthode que vous avez choisie, vous pouvez vérifier qu’elle a réussi en ajoutant le drapeau --permanent à l’opération --list-services. Vous devez utiliser sudo pour toute opération --permanent :

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

      Output
      cockpit dhcpv6-client http ssh

      Votre zone public autorisera désormais le trafic web HTTP sur le port 80. Si votre serveur web est configuré pour utiliser SSL/TLS, vous voudrez également ajouter le service https.  Nous pouvons ajouter cela à la session en cours et au jeu de règles permanent en tapant :

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

      • sudo firewall-cmd --zone=public --add-service=https --permanent

      Que faire si aucun service approprié est disponible ?

      Les services qui sont inclus dans l’installation firewalld représentent un grand nombre des applications les plus courantes auxquelles vous pouvez souhaiter autoriser l’accès. Cependant, il y aura probablement de scénarios où ces services ne correspondent pas à vos exigences.

      Dans cette situation, vous disposez de deux options.

      Ouvrir un port pour vos zones

      La façon la plus simple d’ajouter un support à votre application spécifique consiste à ouvrir les ports qu’elle utilise dans la ou les zone(s) appropriée(s). Cela se fait en spécifiant le port ou la plage de ports, et le protocole associé (TCP ou UDP) pour les ports.

      Par exemple, si notre application fonctionne sur le port 5000 et utilise TCP, nous pourrions temporairement ajouter cela à la zone public en utilisant le paramètre --add-port=. Les protocoles peuvent être désignés sous forme de tcp ou udp :

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

      Output
      success

      Nous pouvons vérifier que cela a réussi en utilisant l’opération --list-ports :

      • sudo firewall-cmd --zone=public --list-ports

      Output
      5000/tcp

      Il est également possible de spécifier une plage séquentielle de ports en séparant le port de début et de fin de la plage avec un tiret. Par exemple, si notre application utilise UDP ports 4990 à 4999, nous pourrions les ouvrir sur public en tapant :

      • sudo firewall-cmd --zone=public --add-port=4990-4999/udp

      Après avoir testé, nous voudrions probablement les ajouter au pare-feu permanent. Utilisez sudo firewall-cmd --runtime-to-permanent pour faire cela ou réexécutez les commandes avec le drapeau --permanent :

      • sudo firewall-cmd --zone=public --permanent --add-port=5000/tcp

      • sudo firewall-cmd --zone=public --permanent --add-port=4990-4999/udp

      • sudo firewall-cmd --zone=public --permanent --list-ports

      Output
      success
success
5000/tcp 4990-4999/udp

      Définir un service

      L’ouverture de ports pour vos zones est une solution simple, mais il peut être difficile de savoir à quoi chacun d’entre eux sert. Si jamais vous désactivez un service sur votre serveur, vous aurez peut-être du mal à vous souvenir des ports qui ont été ouverts et qui sont encore nécessaires. Pour éviter cette situation, il est possible de définir un nouveau service.

      Les services sont des collections de ports avec un nom et une description associés. L’utilisation de services est plus facile à administrer que les ports, mais nécessite un bon travail en amont. La façon la plus simple de commencer consiste à copier un script existant (trouvé dans /usr/lib/firewalld/services) dans le répertoire /etc/firewalld/services où le pare-feu recherche des définitions non standard.

      Par exemple, nous pourrions copier la définition du service SSH pour l’utiliser dans notre exemple de définition de service comme ceci Le nom de fichier moins le suffixe .xml donnera le nom du service dans la liste des services du pare-feu :

      • sudo cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/example.xml

      Maintenant, vous pouvez ajuster la définition trouvée dans le fichier que vous avez copié. Ouvrez-le d’abord dans votre éditeur de texte préféré. Nous utiliserons vi ici :

      • sudo vi /etc/firewalld/services/example.xml

      Pour commencer, le fichier contiendra la définition SSH que vous avez copiée :

      /etc/firewalld/services/example.xml

      <?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="22"/>
</service>

      La majorité de cette définition est en fait des métadonnées. Vous aurez besoin de changer le nom abrégé du service dans les balises <short>. Il s’agit d’un nom lisible par un humain pour votre service. Vous devez également ajouter une description afin de disposer de plus d’informations si jamais vous avez besoin de vérifier le service. La seule configuration que vous devez effectuer et qui affecte réellement la fonctionnalité du service sera probablement la définition du port où vous identifiez le numéro de port et le protocole que vous souhaitez ouvrir. Plusieurs balises <port/> peuvent être spécifiées.

      Pour notre exemple de service, imaginez que nous devons ouvrir le port 7777 pour TCP et 8888 pour UDP. Nous pouvons modifier la définition existante avec quelque chose de ce type :

      /etc/firewalld/services/example.xml

      <?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Example Service</short>
  <description>This is just an example service. It probably shouldn't be used on a real system.</description>
  <port protocol="tcp" port="7777"/>
  <port protocol="udp" port="8888"/>
</service>

      Enregistrez et fermez le fichier.

      Rechargez votre pare-feu pour accéder à votre nouveau service :

      • sudo firewall-cmd --reload

      Vous pouvez voir qu’il se trouve maintenant parmi la liste des services disponibles :

      • firewall-cmd --get-services

      Output
      RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bb bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc bittorrent-lsd ceph ceph-mon cfengine cockpit condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns dns-over-tls docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server example finger freeipa-4 freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git grafana gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kdeconnect kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns memcache minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy prometheus proxy-dhcp ptp pulseaudio puppetmaster quassel radius rdp redis redis-sentinel rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync spotify-sync squid ssdp ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tentacle tftp tftp-client tile38 tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server

      Vous pouvez maintenant utiliser ce service dans vos zones comme vous le feriez normalement.

      Création de vos propres zones

      Bien que les zones prédéfinies seront probablement plus que suffisantes pour la plupart des utilisateurs, il peut être utile de définir vos propres zones qui décrivent mieux leur fonction.

      Par exemple, vous pouvez créer une zone pour votre serveur web, appelé publicweb. Cependant, vous pouvez avoir une autre zone configurée pour le service DNS que vous fournissez sur votre réseau privé. Vous pouvez vouloir une zone appelée “privateDNS” pour cela.

      Lorsque vous ajoutez une zone, vous devez l’ajouter à la configuration du pare-feu permanent. Vous pouvez ensuite recharger pour intégrer la configuration dans votre session en cours. Par exemple, nous pourrions créer les deux zones dont nous avons parlé ci-dessus en tapant :

      • sudo firewall-cmd --permanent --new-zone=publicweb

      • sudo firewall-cmd --permanent --new-zone=privateDNS

      Vous pouvez vérifier qu’elles sont présentes dans votre configuration permanente en tapant :

      • sudo firewall-cmd --permanent --get-zones

      Output
      block dmz drop external home internal privateDNS public publicweb trusted work

      Comme indiqué précédemment, ils ne seront pas encore disponibles dans le pare-feu en exécution :

      Output
      block dmz drop external home internal public trusted work

      Rechargez le pare-feu pour amener ces nouvelles zones dans la configuration d’exécution active :

      • sudo firewall-cmd --reload

      • firewall-cmd --get-zones

      Output
      block dmz drop external home internal privateDNS public publicweb trusted work

      Maintenant, vous pouvez affecter les services et les ports appropriés à vos zones. Il est généralement bon de régler le pare-feu en cours d’exécution et d’enregistrer ces modifications dans la configuration permanente après l’avoir testé. Par exemple, pour la zone publicweb , vous pouvez vouloir ajouter les services SSH, HTTP et HTTPS :

      • sudo firewall-cmd --zone=publicweb --add-service=ssh

      • sudo firewall-cmd --zone=publicweb --add-service=http

      • sudo firewall-cmd --zone=publicweb --add-service=https

      • sudo firewall-cmd --zone=publicweb --list-all

      Output
      publicweb
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: http https ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

      De même, nous pouvons ajouter le service DNS à notre zone privateDNS :

      • sudo firewall-cmd --zone=privateDNS --add-service=dns

      • sudo firewall-cmd --zone=privateDNS --list-all

      Output
      privateDNS
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: dns
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

      Nous pourrions alors changer nos interfaces pour ces nouvelles zones afin de les tester :

      • sudo firewall-cmd --zone=publicweb --change-interface=eth0

      • sudo firewall-cmd --zone=privateDNS --change-interface=eth1

      À ce stade, vous avez la possibilité de tester votre configuration. Si ces valeurs vous conviennent, vous allez vouloir ajouter ces règles à la configuration permanente. Vous pourriez le faire en exécutant à nouveau toutes les commandes avec le drapeau --permanent annexé, mais dans ce cas, nous utiliserons le drapeau --runtime-to-permanent pour sauvegarder de façon permanente l’ensemble de notre configuration d’exécution :

      • sudo firewall-cmd --runtime-to-permanent

      Après avoir appliqué ces règles de manière permanente, rechargez le pare-feu pour vérifier que les changements demeurent :

      • sudo firewall-cmd --reload

      Valider que les zones correctes ont été attribuées :

      • firewall-cmd --get-active-zones

      Output
      privateDNS
  interfaces: eth1
publicweb
  interfaces: eth0

      Et validezt le fait que les services appropriés sont disponibles pour les deux zones :

      • sudo firewall-cmd --zone=publicweb --list-services

      Output
      http https ssh

      • sudo firewall-cmd --zone=privateDNS --list-services

      Output
      dns

      Vous avez configuré vos propres zones avec succès ! Si vous voulez faire de l’une de ces zones la zone par défaut pour d’autres interfaces, n’oubliez pas de configurer ce comportement avec le paramètre --set-default-zone= :

      • sudo firewall-cmd --set-default-zone=publicweb

      Conclusion

      Vous devriez maintenant avoir une compréhension assez complète de la façon d’administrer le service firewalld sur votre système CentOS pour une utilisation quotidienne.

      Le service firewalld vous permet de configurer des règles et des ensembles de règles maintenables qui prennent en compte votre environnement réseau. Il vous permet de passer en toute transparence d’une politique de pare-feu à l’autre en utilisant des zones et donne aux administrateurs la possibilité d’abstraire la gestion des ports en des définitions de service plus conviviales. L’acquisition d’une connaissance pratique de ce système vous permettra de tirer parti de la flexibilité et de la puissance que cet outil procure.

      Pour plus d’informations sur firewalld, veuillez consulter la documentation officielle de firewalld.



      Source link

      Forgot Your Password ?