Comment définir une zone Firewalld personnalisée

Firewalld est le gestionnaire de pare-feu de haut niveau par défaut sur la famille de distributions Red Hat. L’une de ses particularités est qu’il définit une série de zones dites de pare-feu : chaque zone peut être considérée comme un niveau de confiance différent et peut être configurée pour autoriser le trafic via un ensemble spécifique de ports. Bien que Firewalld soit livré avec des zones prédéfinies qui peuvent être facilement examinées et modifiées, nous pouvons parfois vouloir créer nos zones personnalisées à partir de zéro.

Dans ce tutoriel, nous voyons comment définir des zones Firewalld à l’aide du langage de balisage xml et de fichiers de configuration dédiés.

Dans ce tutoriel, vous allez apprendre :

Comment lister les zones Firewalld disponibles
Comment examiner une zone Firewalld
Comment définir une zone Firewalld personnalisée à l’aide du langage de balisage xml

Configuration logicielle requise et conventions utilisées

Introduction

Ce n’est pas la première fois que l’on parle de Firewalld. Dans un tutoriel précédent, nous avons abordé les bases de son utilisation et l’utilitaire firewall-cmd associé. Nous avons vu comment Firewalld s’articule autour du concept de « zone » : chaque zone peut être configurée pour autoriser le trafic à travers un ensemble spécifique de ports, et avec des fonctionnalités différentes. Bien que l’application soit installée avec un ensemble prédéfini de zones, de nouvelles zones peuvent être configurées et ajoutées par l’administrateur système. Dans ce tutoriel, nous voyons comment définir une zone personnalisée directement en écrivant son fichier de configuration à l’aide du langage de balisage xml.

Les zones par défaut

L’obtention de la liste des zones Firewalld prédéfinies est une tâche très facile. Tout ce que nous avons à faire est d’ouvrir notre émulateur de terminal préféré et d’exécuter la commande suivante :

sudo firewall-cmd --get-zones

Sur mon système, (dernière version de Fedora), la commande ci-dessus renvoie la liste suivante :

FedoraServer
FedoraWorkstation
bloquer
zone démilitarisée
goutte
externe
domicile
interne
nm-partagé
publique
Confiance
travail

Il est tout aussi simple de jeter un coup d’œil aux services et aux ports autorisés dans une zone spécifique. Supposons que nous voulions examiner le contenu de la zone d’origine, nous exécuterions :

sudo firewall-cmd --info-zone=home

Voici le résultat renvoyé par la commande :

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

En jetant un coup d’œil à la sortie, nous pouvons facilement voir, entre autres choses, que les services dhcpv6-client, mdns, samba-client et ssh sont activés dans la zone (un service n’est rien de plus qu’un port prédéfini ou un ensemble de ports associés à un nom).

Définition de zones dans des fichiers xml

Une façon d’ajouter de nouvelles zones est d’utiliser firewall-cmd avec l’option --new-zone, et de les personnaliser en ajoutant directement des services ou des ports supplémentaires, respectivement avec --add-port et --add-service, comme nous l’avons vu dans le tutoriel mentionné ci-dessus. Cependant, un moyen plus rapide de définir et de déployer une nouvelle zone consiste à écrire son fichier de configuration à l’aide d’un ensemble de balises dédiées et du langage de balisage xml. Les zones par défaut, par exemple, sont définies dans le répertoire /usr/lib/firewalld/zones. À l’intérieur, nous pouvons trouver un fichier pour chaque zone disponible :

ls /usr/lib/firewalld/zones
-rw-r--r--. 1 root root 312 Mar 25 21:31 block.xml
-rw-r--r--. 1 root root 306 Mar 25 21:31 dmz.xml
-rw-r--r--. 1 root root 304 Mar 25 21:31 drop.xml
-rw-r--r--. 1 root root 317 Mar 25 21:31 external.xml
-rw-r--r--. 1 root root 343 Mar 25 21:31 FedoraServer.xml
-rw-r--r--. 1 root root 525 Mar 25 21:31 FedoraWorkstation.xml
-rw-r--r--. 1 root root 382 Mar 25 21:31 home.xml
-rw-r--r--. 1 root root 397 Mar 25 21:31 internal.xml
-rw-r--r--. 1 root root 809 Aug 2 2021 libvirt.xml
-rw-r--r--. 1 root root 729 Sep 22 2021 nm-shared.xml
-rw-r--r--. 1 root root 353 Mar 25 21:31 public.xml
-rw-r--r--. 1 root root 175 Mar 25 21:31 trusted.xml
-rw-r--r--. 1 root root 349 Mar 25 21:31 work.xml

Lorsque l’une des zones par défaut est modifiée, les modifications ne sont pas écrites directement dans son fichier de configuration d’origine ; À la place, un fichier portant le même nom est créé dans le répertoire /etc/firewalld/zones. En utilisant cette stratégie, pour réinitialiser une zone à sa configuration par défaut, tout ce que nous avons à faire est de supprimer ledit fichier.

Cependant, le répertoire /etc/firewalld/zones n’est pas seulement destiné à contenir des zones par défaut modifiées. Si nous voulons définir des zones personnalisées, c’est à cet endroit que nous devons créer leurs configurations. Voyons comment.

Définition d’une zone personnalisée

Un fichier de configuration de zone Firewalld doit avoir l’extension .xml et la longueur de son nom ne doit pas dépasser 17 caractères. Étant des zones définies à l’aide du langage de balisage xml, la première chose que nous devrions écrire dans un fichier de configuration de zone est ce que l’on appelle le prologue xml :

<?xml version="1.0" encoding="utf-8"?>

Le prologue xml n’est pas obligatoire, mais il permet de spécifier la version xml et l’encodage du fichier.

Chaque définition de zone est entourée de la balise racine : <zone>. Cette balise accepte deux attributs facultatifs :

version
cible

La valeur de l’attribut version doit être une chaîne de caractères qui indique la version de la zone définie ; L’attribut target, en revanche, peut être utilisé pour définir l’action par défaut appliquée aux paquets qui ne correspond à aucune règle définie dans la zone. La cible peut être l’une des suivantes :

ACCEPT : un paquet ne correspondant à aucune règle est accepté
%%REJECT %% : un paquet ne correspondant à aucune règle est rejeté (c’est la valeur par défaut)
DROP : un paquet ne correspondant à aucune règle est abandonné

Comme vous pouvez le voir, lorsque vous utilisez à la fois %%REJECT %% ou DROP, les paquets qui ne correspondent à aucune règle sont ignorés. La différence entre les deux est que lorsque le premier est utilisé, la source du trafic est informée par un message d’erreur, tandis que lorsque le second est utilisé, les paquets sont abandonnés silencieusement.

Deux balises que nous pouvons utiliser dans notre définition de zone sont <short> et <description>. Ces balises, bien que facultatives, sont très utiles, car elles peuvent être utilisées pour mieux décrire la zone et son objectif.

Pour les besoins de cet exemple, nous allons créer une zone appelée « custom », fournir une brève description de celle-ci et spécifier explicitement la cible %%REJECT %%. Dans le fichier /etc/firewalld/zones/custom.xml, nous écrivons :

<?xml version="1.0" encoding="utf-8"?>
<zone target="%%REJECT%%">
  <short>Custom</short>
  <description>This is a demonstrative custom zone</description>
</zone>

Ajout de services et de ports à la zone

Ci-dessus, nous avons défini une zone personnalisée, mais nous n’y avons ajouté aucun port ou service. Pour effectuer ces tâches, nous utilisons respectivement les balises <port/> et <service/>. Ces balises peuvent être répétées plusieurs fois. Supposons que nous voulions autoriser le service « ssh » dans la zone (le service autorise le trafic via le port TCP 22), nous ajouterions ce qui suit à notre définition :

<?xml version="1.0" encoding="utf-8"?>
<zone target="REJECT"> 
  <short>Custom</short>
  <description>This is a demonstrative custom zone</description>
  <service name="ssh"/>
</zone>

Contrairement aux autres balises que nous utilisions jusqu’à présent, la balise <service/> se ferme automatiquement. Cette balise prend un attribut obligatoire, name, dont la valeur doit être une chaîne indiquant le nom du service que l’on souhaite activer dans la zone. Une liste de services prédéfinis peut être obtenue à l’aide de la commande suivante :

sudo firewall-cmd --get-services

Si nous voulons ajouter un port spécifique, à la place, nous devons utiliser la balise <port/>. Cette balise se ferme automatiquement et peut être utilisée pour spécifier directement un port. La balise prend deux attributs, tous deux obligatoires : port et protocol. Le premier est utilisé pour spécifier le numéro de port ou la plage de ports que nous voulons utiliser, le second est utilisé pour spécifier le protocole qui peut être l’un entre tcp, udp, sctp ou dccp. Supposons que nous voulions autoriser le trafic via le port TCP 15432, nous écririons :

<?xml version="1.0" encoding="utf-8"?>
<zone target="%%REJECT%%"> 
  <short>Custom</short>
  <description>This is a demonstrative custom zone</description>
  <service name="ssh"/>
  <port port="15432" protocol="tcp"/>
</zone>

Si nous voulons spécifier une plage de ports à la place, nous pouvons signaler les ports de début et de fin séparés par un trait d’union. Pour autoriser le trafic à travers la plage de ports qui va du port 15432 à 15435, par exemple, nous aurions utilisé la syntaxe suivante :

<port port="15432-15435" protocol="tcp"/>

Ajout d’une règle de portée à la zone

Des règles enrichies sont utilisées pour définir le comportement détaillé du trafic. Si nous voulons autoriser uniquement le trafic provenant d’une adresse IP source ou d’un sous-réseau spécifique vers un port, par exemple, il s’agit d’une règle enrichie que nous devons définir. Une règle enrichie est définie à l’aide de la balise <rule> dans la définition de zone. Supposons que nous voulions autoriser l’accès au service « git » (il s’agit d’un service utilisé pour ouvrir le port 9418, pour le démon git) uniquement à partir de l’adresse IP 192.168.0.39. Voici ce que nous ajouterions à notre définition de zone :

<?xml version="1.0" encoding="utf-8"?> 
<zone target="REJECT"> 
  <short>Custom</short> 
  <description>This is a demonstrative custom zone</description>    
  <service name="ssh"/> 
  <port port="15432" protocol="tcp"/> 
  <rule family="ipv4">
    <source address="192.168.0.39" />
    <service name="git"/>
    <accept/>
  </rule>
</zone>

Ci-dessus, nous avons utilisé l’attribut optional family de la balise <rule> pour limiter la règle à ipv4 (si l’attribut est omis, la règle est considérée comme valide à la fois pour ipv4 et ipv6), puis nous avons utilisé la balise <source/> pour spécifier l’adresse IP source qui doit correspondre pour que la règle soit appliquée (via l’attribut address), la balise <service/> pour spécifier quel service doit faire partie de la règle, et enfin, la balise <accept/> pour spécifier que l’action à laquelle l’action doit être appliquée est « Accept ». Pour en savoir plus sur la syntaxe des règles riches, il est fortement suggéré de jeter un coup d’œil au manuel dédié, accessible en exécutant :

man firewalld.richlanguage

Liaison d’une zone à une interface réseau

Avec Firewalld, nous pouvons lier une zone à une interface spécifique. Lorsque les interfaces sont gérées par le service NetworkManager (par défaut), il n’est pas nécessaire de lier une interface à une zone, car cela se fait automatiquement. Dans certains cas, cependant, nous pouvons vouloir être explicites dans notre définition. Dans ce cas, pour lier la zone à une interface, nous pouvons utiliser la balise de fermeture automatique <interface/>. Cette balise ne prend qu’un seul argument obligatoire, qui est le nom de l’interface à laquelle lier la zone. Supposons que nous voulions lier explicitement notre zone à l’interface ens5f5, nous écririons :

<?xml version="1.0" encoding="utf-8"?> 
<zone target="%%REJECT%%"> 
  <short>Custom</short> 
  <description>This is a demonstrative custom zone</description> 
  <service name="ssh"/> 
  <port port="15432" protocol="tcp"/> 
  <rule>
    <source address="192.168.0.39" />
    <service name="git"/>
    <accept/>
  </rule>
  <interface name="ens5f5"/>
</zone>

Chargement de la zone

Une fois que nous avons enregistré notre définition de zone, pour qu’elle soit « récupérée », nous devons recharger Firewalld :

sudo firewall-cmd --reload

Notre zone devrait maintenant apparaître dans la liste renvoyée par la commande '–get-zones' :

sudo firewall-cmd --get-zones
FedoraServer FedoraWorkstation block custom dmz drop external home internal nm-shared public trusted work

Pour définir notre zone personnalisée comme zone par défaut, nous exécuterions :

sudo firewall-cmd --set-default-zone=custom

Conclusions

Dans ce tutoriel, nous avons vu comment définir une zone Firewalld personnalisée dans un fichier de configuration xml. Les fichiers de configuration de zone utilisent le langage de balisage xml et doivent être enregistrés à l’intérieur du répertoire /etc/firewalld/zones. Nous avons vu quelques-unes des balises qui peuvent être utilisées dans la définition de la zone pour ajouter des ports, des services et des règles riches. Enfin, nous avons vu comment recharger Firewalld pour que la zone soit récupérée, et comment la définir comme zone par défaut.