Contrôle d’accès basé sur les politiques de Firewalld pour WireGuard

Nous avons couvert les bases de la façon d’utiliser WireGuard avec firewalld dans un article l’an dernier. Cet article vous montrera comment ajouter des politiques firewalld à ces configurations de base de firewalld afin d’appliquer le contrôle d’accès aux connexions transférées via firewalld.

Les politiques firewalld ont été introduites avec la version 0.9 de firewalld (la première sortie en automne 2020). La version 0.9 ou plus récente est disponible aujourd’hui dans les dernières versions de nombreuses distributions Linux — consultez le tableau Versions des distros à la fin de l’article pour vérifier si elle est empaquetée pour les distros que vous utilisez.

Les politiques firewalld contrôlent le trafic transféré entre les zones de firewalld. Lorsque vous attachez une ou plusieurs zones à la face entrante (entrée) d’une politique et une ou plusieurs zones à la face sortante (sortie) de la même politique, la politique filtrera le trafic transféré des zones entrantes vers les zones sortantes.

Par exemple, dans le diagramme suivant, la politique mywg2mysite filtra les nouvelles connexions transférées depuis la zone mywg vers la zone mysite, et la politique mysite2mywg filtra les nouvelles connexions transférées depuis la zone mysite vers la zone mywg :

Voici la traduction en français :

Passons en revue comment utiliser les politiques de firewalld pour appliquer le contrôle d’accès aux composants suivants :

1. Hub d’une topologie hub-and-spoke
2. Site Masquerading avec une topologie point-to-site
3. Site Gateway avec une topologie site-to-site

Hub

Dans l’article original Comment utiliser WireGuard avec Firewalld , nous avons couvert la façon de configurer le hub, Host C, comme partie d’une scène hub-and-spoke dans la section Configuration de firewalld sur Host C. Dans cette section, nous avons couvert comment utiliser la zone public de firewalld pour permettre un accès public au port WireGuard du hub (51823 dans cet exemple), et pour configurer une zone personnalisée mywg pour permettre le transfert du trafic WireGuard entre les spokes (Endpoint A et Endpoint B).

Pour la zone personnalisée mywg de l’article original, nous avons ajouté une série de règles riches et des règles directes spéciales pour appliquer un contrôle d’accès au réseau WireGuard, de sorte qu’il n’ait permis que de nouvelles connexions à être initiées vers le serveur web sur Endpoint B (10.0.0.2), et a bloqué tout autre chose. Cependant, avec les politiques firewalld, nous pouvons simplifier considérablement cette configuration et utiliser davantage des paramètres intégrés de firewalld au lieu de règles riches complexes et de règles directes.

Ainsi, dans cet article, nous remplacerons la zone mywg de l’article original par une nouvelle zone nuwg, beaucoup plus simple, et l’accompagnerons d’une nouvelle politique intrawg, avec laquelle nous appliquerons le contrôle d’accès.

Voici le texte corrigé :

ut d’abord, sur Host C, enregistrez les modifications de runtime que vous avez apportées depuis votre dernier enregistrement :

$ sudo firewall-cmd --runtime-to-permanent
success

Et supprimez votre ancienne zone mywg si vous l’aviez précédemment ajoutée :

$ sudo firewall-cmd --permanent --delete-zone=mywg
success

Ensuite, créez la nouvelle zone nuwg :

$ sudo firewall-cmd --permanent --new-zone=nuwg
success

Et créez ensuite la nouvelle politique intrawg, en la configurant pour refuser les nouvelles connexions par défaut :

$ sudo firewall-cmd --permanent --new-policy=intrawg
success
$ sudo firewall-cmd --permanent --policy=intrawg --set-target=REJECT
success

Chargez ensuite la nouvelle zone et la politique dans l’état de runtime actif :

$ sudo firewall-cmd --reload
success

Ajoutez maintenant vos règles de contrôle d’accès, en utilisant la syntaxe des règles riches de firewalld. Dans ce cas, nous avons simplement besoin d’une règle pour accorder l’accès au serveur web de Endpoint B (10.0.0.2) :

$ sudo firewall-cmd --policy=intrawg --add-rich-rule='rule family="ipv4" destination address="10.0.0.2" service name="http" accept'
success

Si nous voulions limiter l’accès encore plus, disons pour permettre uniquement à Endpoint A d’accéder au serveur web de Endpoint B, nous pourrions rédiger la règle comme suit, en spécifiant également l’adresse source de Endpoint A (10.0.0.1) :

$ sudo firewall-cmd --policy=intrawg --add-rich-rule='rule family="ipv4" source address="10.0.0.1" destination address="10.0.0.2" service name="http" accept'
success

Ou si le serveur web sur Endpoint B fonctionnait sur un port personnalisé, comme par exemple le port TCP 8080, nous pourrions rédiger la règle de cette manière, en spécifiant le port personnalisé au lieu de la définition standard du service HTTP :

$ sudo firewall-cmd --policy=intrawg --add-rich-rule='rule family="ipv4" destination address="10.0.0.2" port port="8080" protocol="tcp" accept'
success

Pour terminer les paramètres de la politique, appliquez-la au trafic transféré à l’intérieur de la zone nuwg elle-même (avec les entrées et sorties connectées à la même zone) :

$ sudo firewall-cmd --policy=intrawg --add-ingress-zone=nuwg
success
$ sudo firewall-cmd --policy=intrawg --add-egress-zone=nuwg
success

Si vous affichez les informations de la politique intrawg, c’est ce que vous verrez :

$ sudo firewall-cmd --info-policy=intrawg
intrawg (actif)
  priorité : -1
  cible : REJECT
  zones d'entrée : nuwg
  zones de sortie : nuwg
  services :
  ports :
  protocoles :
  masquerade : non
  ports de transfert :
  ports sources :
  blocs ICMP :
  règles riches :
        règle famille="ipv4" destination adresse="10.0.0.2" service nom="http" accepter

Maintenant pour la zone nuwg, simplement liez l’interface wg0 à cette zone :

$ sudo firewall-cmd --zone=nuwg --add-interface=wg0
success

Contrairement aux paramètres de configuration complexes pour la zone mywg dans l’article original, c’est tout ce que nous avons besoin pour la zone nuwg. Si vous affichez les informations de la zone nuwg, voici ce que vous verrez :

$ sudo firewall-cmd --info-zone=nuwg
nuwg (actif)
  cible : default
  inversion des blocs ICMP : non
  interfaces : wg0
  sources :
  services :
  ports :
  protocoles :
  transfert : non
  masquerade : non
  ports de transfert :
  ports sources :
  blocs ICMP :
  règles riches :

Si vous n’avez pas encore configuré la Zone Publique sur l’Hôte C, comme décrit dans l’article original, faites-le maintenant. Alors vous êtes prêt à Tester !

Si cela fonctionne pour permettre à l’Endpoint A d’accéder au serveur web à l’Endpoint

B (et de rejeter toutes autres connexions via le réseau WireGuard), enregistrez vos paramètres de configuration avec la commande suivante :

$ sudo firewall-cmd --runtime-to-permanent
success

Après avoir exécuté cette commande, vous trouverez la configuration pour la stratégie intrawg à /etc/firewalld/policies/intrawg.xml :

<!-- Hôte C /etc/firewalld/policies/intrawg.xml -->
<?xml version="1.0" encoding="utf-8"?>
<policy target="REJECT">
  <rule family="ipv4">
    <destination address="10.0.0.2"/>
    <service name="http"/>
    <accept/>
  </rule>
  <zone src="nuwg"/>
  <zone dst="nuwg"/>
</policy>

Et la configuration pour la zone nuwg à /etc/firewalld/zones/nuwg.xml :

<!-- Hôte C /etc/firewalld/zones/nuwg.xml -->
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <interface name="wg0"/>
</zone>

Masquerading

Dans l’article original Comment utiliser WireGuard avec Firewalld, nous avons couvert la façon de configurer le côté site de la connexion, Hôte β, en tant qu’ partie d’un point-to-site avec un scénario de masquerading dans la section Configuration de Firewalld sur l’Hôte β. Dans cette section, nous avons couvert la façon de configurer quatre zones firewalld personnalisées :

1. myadmin: permettre un accès SSH à l’Hôte β pour une administration système.
2. mypub: permettre un accès public au port WireGuard sur l’Hôte β (51822).
3. mysite: permettre un accès au LAN de Site B (192.168.200.0/24) avec masquerading.
4. mywg: permettre un accès à partir du réseau WireGuard.

Dans cet article, nous ajouterons une nouvelle politique pour restreindre l’accès entre les zones mywg et mysite de telle sorte que seul l’accès au serveur web sur le Point B (192.168.200.22) soit autorisé, tout le reste sera bloqué.

Tout d’abord, sur l’Hôte β, enregistrez les modifications de configuration en cours depuis la dernière fois que vous les avez enregistrées :

$ sudo firewall-cmd --runtime-to-permanent
success

Ensuite, créez une nouvelle politique firewalld pour la connexion entre les zones mywg et mysite, et définissez-la par défaut pour refuser de nouvelles connexions :

$ sudo firewall-cmd --permanent --new-policy=mywg2mysite
success
$ sudo firewall-cmd --permanent --policy=mywg2mysite --set-target=REJECT
success

Et exécutez la commande de rechargement pour rendre ces modifications actives :

$ sudo firewall-cmd --reload
success

Ensuite, nous ajouterons nos règles de contrôle d’accès en utilisant la syntaxe des règles riches de firewalld. Dans ce cas, nous avons simplement besoin d’une règle pour accorder un accès au serveur web du Point B (192.168.200.22) :

$ sudo firewall-cmd --policy=mywg2mysite --add-rich-rule='rule family="ipv4" destination address="192.168.200.22" service name="http" accept'
success

Si nous voulions limiter l’accès encore plus, disons pour permettre uniquement au Point de terminaison A d’accéder au serveur web du Point de terminaison B, nous pourrions rédiger la règle de cette manière, en spécifiant l’adresse source du Point de terminaison A (10.0.0.1) :

$ sudo firewall-cmd --policy=mywg2mysite --add-rich-rule='rule family="ipv4" source address="10.0.0.1" destination address="192.168.200.22" service name="http" accept'
success

Ou si le serveur web sur le Point de terminaison B fonctionnait sur un port personnalisé, comme disons le port TCP 8080, nous pourrions rédiger la règle de cette manière, en spécifiant le port personnalisé au lieu de la définition standard du service HTTP :

$ sudo firewall-cmd --policy=mywg2mysite --add-rich-rule='rule family="ipv4" destination address="192.168.200.22" port port="8080" protocol="tcp" accept'
success

tiantes depuis la zone mywg (notre réseau WireGuard) vers la zone mysite (la LAN Site B). Si vous affichez les informations de la nouvelle stratégie mywg2mysite, voici ce que vous verrez :

$ sudo firewall-cmd --info-policy=mywg2mysite
mywg2mysite (active)
  priority: -1
  target: REJECT
  ingress-zones: mywg
  egress-zones: mysite
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" destination address="192.168.200.22" service name="http" accept

Si vous n’avez pas encore configuré la Zone Mypub sur le Hôte β comme décrit dans l’article original, faites-le maintenant. Alors vous êtes prêt à Tester !

Si cela fonctionne pour permettre à Endpoint A d’accéder au serveur web à Endpoint B (et de rejeter toutes autres connexions via le réseau WireGuard), enregistrez vos paramètres de configuration avec la commande suivante :

$ sudo firewall-cmd --runtime-to-permanent
success

Après avoir exécuté cette commande, vous trouverez la configuration pour la nouvelle politique mywg2mysite à /etc/firewalld/policies/mywg2mysite.xml :

<!-- Hôte β /etc/firewalld/policies/mywg2mysite.xml -->
<?xml version="1.0" encoding="utf-8"?>
<policy target="REJECT">
  <rule family="ipv4">
    <destination address="192.168.200.22"/>
    <service name="http"/>
    <accept/>
  </rule>
  <ingress-zone name="mywg"/>
  <egress-zone name="mysite"/>
</policy>

Passerelle

Dans l’article original Comment utiliser WireGuard avec Firewalld , nous avons couvert la façon de configurer chaque passerelle WireGuard, le Hôte α et le Hôte β, en tant qu’éléments d’un scénario site à site dans les sections Configuration Firewalld sur le Hôte α et Configuration Firewalld sur le Hôte β. Dans chacune de ces deux sections, nous avons couvert la façon d’utiliser la zone public de firewalld pour permettre un accès public au port WireGuard de la passerelle (51821 pour le Hôte α et 51822 pour le Hôte β), ainsi que la façon d’utiliser la zone internal de firewalld pour permettre le transfert du trafic WireGuard entre les deux sites (Site A et Site B).

Lors de l’application du contrôle d’accès à un scénario site-to-site, vous configurerez généralement chaque site individuellement pour restreindre l’accès entrant au site lui-même, tout en permettant un accès complet au autre site. C’est ce que nous ferons ici.

Dans cet article, nous ajouterons deux nouvelles zones, mywg et mysite, à chacun des passerelles WireGuard, avec l’interface WireGuard sur chaque passerelle liée à sa zone mywg, et le propre site local de la passerelle liée à sa zone mysite. Ensuite, nous ajoutons deux politiques, mywg2mysite et mysite2mywg, pour contrôler l’accès du réseau WireGuard au site local et vice versa. Cela sera très similaire à la configuration pour le Masquerading ci-dessus, mais sans masquerer les paquets envoyés du réseau WireGuard au site local (et avec l’ajout de permettre de nouvelles connexions sortantes à partir du site local vers le réseau WireGuard).

Pour cet exemple, nous restreignons l’accès de Site A à Site B de telle sorte qu’il n’y ait que des nouvelles connexions initiantes depuis la zone mywg (notre réseau WireGuard) vers la zone mysite (la LAN Site B).

Voici le texte corrigé :

Ainsi sur le Hôte β, enregistrez les modifications de runtime que vous avez apportées depuis la dernière sauvegarde :

$ sudo firewall-cmd --runtime-to-permanent
success

Ensuite, créez de nouvelles zones mysite et mywg :

$ sudo firewall-cmd --permanent --new-zone=mysite
success
$ sudo firewall-cmd --permanent --new-zone=mywg
success

Et enfin, créez une politique pour les connexions envoyées de la zone mysite à la zone mywg, mysite2mywg; ainsi qu’une politique pour les connexions envoyées de la zone mywg à la zone mysite, mywg2mysite :

$ sudo firewall-cmd --permanent --new-policy=mysite2mywg
success
$ sudo firewall-cmd --permanent --new-policy=mywg2mysite
success

Définissez la cible par défaut pour la stratégie mysite2mywg sur ACCEPT, afin d’autoriser toutes les nouvelles connexions sortantes du site local au réseau WireGuard :

$ sudo firewall-cmd --permanent --policy=mysite2mywg --set-target=ACCEPT
success

Mais définissez la cible par défaut pour la stratégie mywg2mysite sur REJECT, afin de bloquer toutes les nouvelles connexions entrantes par défaut du réseau WireGuard au site local :

$ sudo firewall-cmd --permanent --policy=mywg2mysite --set-target=REJECT
success

Ensuite, exécutez la commande de rechargement pour rendre ces modifications actives :

$ sudo firewall-cmd --reload
success

Maintenant, nous ajouterons nos règles de contrôle d’accès en utilisant la syntaxe des règles riches de firewalld. Dans ce cas pour le Hôte β, nous avons simplement besoin d’une règle, pour accorder l’accès au serveur web d’Endpoint B (192.168.200.22). Nous ajoutons nos règles de contrôle d’accès à la stratégie mywg2mysite, qui réglera les connexions entrantes du réseau WireGuard au site local :

$ sudo firewall-cmd --policy=mywg2mysite --add-rich-rule='rule family="ipv4" destination address="192.168.200.22" service name="http" accept'
success

Si nous voulions limiter l’accès encore plus, disons pour permettre uniquement à Endpoint A d’accéder au serveur web d’Endpoint B, nous pourrions écrire la règle de cette manière, en spécifiant également l’adresse source de Endpoint A (192.168.1.11) :

$ sudo firewall-cmd --policy=mywg2mysite --add-rich-rule='rule family="ipv4" source address="192.168.1.11" destination address="192.168.200.22" service name="http" accept'
success

Ou si le serveur web sur Endpoint B fonctionnait sur un port personnalisé, comme par exemple le port TCP 8080, nous pourrions écrire la règle de cette manière, en spécifiant le port personnalisé au lieu de la définition standard du service HTTP :

$ sudo firewall-cmd --policy=mywg2mysite --add-rich-rule='rule family="ipv4" destination address="192.168.200.22" port port="8080" protocol="tcp" accept'
success

Pour finaliser les paramètres de la stratégie, connectez les zones mywg et mysite à la stratégie mywg2mysite :

$ sudo firewall-cmd --policy=mywg2mysite --add-ingress-zone=mywg
success
$ sudo firewall-cmd --policy=mywg2mysite --add-egress-zone=mysite
success

Et connectez-les dans le sens inverse (site local sortant vers le réseau WireGuard) via la stratégie mysite2mywg :

$ sudo firewall-cmd --policy=mysite2mywg --add-ingress-zone=mysite
success
$ sudo firewall-cmd --policy=mysite2mywg --add-egress-zone=mywg
success

Maintenant, si vous affichez les informations de la nouvelle stratégie mywg2mysite,

Voici le texte corrigé :

oici ce que vous verrez :

$ sudo firewall-cmd --info-policy=mywg2mysite
mywg2mysite (active)
  priority: -1
  target: REJECT
  ingress-zones: mywg
  egress-zones: mysite
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule family="ipv4" destination address="192.168.200.22" service name="http" accept

Et si vous affichez les informations de la stratégie mysite2mywg, voici ce que vous verrez :

$ sudo firewall-cmd --info-policy=mysite2mywg
mysite2mywg (active)
  priority: -1
  target: ACCEPT
  ingress-zones: mysite
  egress-zones: mywg
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Maintenant pour les zones : Supprimez l’interface wg0 de la zone internal si vous l’aviez ajoutée précédemment :

$ sudo firewall-cmd --zone=internal --remove-interface=wg0
success

Et ajoutez l’interface wg0 à notre nouvelle zone mywg :

$ sudo firewall-cmd --zone=mywg --add-interface=wg0
success

Si vous affichez les informations de la zone mywg, voici ce que vous verrez :

$ sudo firewall-cmd --info-zone=mywg
mywg (actif)
  cible : par défaut
  inversion des blocages ICMP : non
  interfaces : wg0
  sources :
  services :
  ports :
  protocoles :
  transfert : non
  masquerade : non
  ports de transfert :
  ports sources :
  blocages ICMP :
  règles riches :

Si vous aviez précédemment ajouté l’interface eth1 (ou toute autre interface connectée au site local) à la zone internal, retirez-la maintenant :

$ sudo firewall-cmd --zone=internal --remove-interface=eth1
success

Ou si vous aviez précédemment associé le sous-réseau du site local (192.168.200.0/24 pour Site B) à la zone internal, retirez-le :

$ sudo firewall-cmd --zone=internal --remove-source=192.168.200.0/24
success

Ensuite, liez l’interface eth1 (ou toute autre interface dédiée connectée au site local) à la zone mysite :

$ sudo firewall-cmd --zone=mysite --add-interface=eth1
success

Ou si l’hôte n’a pas d’interface dédiée pour le site local, liez plutôt le sous-réseau du site local à la zone mysite :

$ sudo firewall-cmd --zone=mysite --add-source=192.168.200.0/24
success

Maintenant, affichez les informations de la zone mysite. Vous devriez voir ceci (si vous avez lié l’interface eth1 à elle) :

$ sudo firewall-cmd --info-zone=mysite
mysite (actif)
  cible : par défaut
  inversion des blocages ICMP : non
  interfaces : eth1
  sources :
  services :
  ports :
  protocoles :
  transfert : non
  masquerade : non
  ports de transfert :
  ports sources :
  blocages ICMP :
  règles riches :

Ou ceci, si vous avez lié le sous-réseau du site local à elle :

$ sudo firewall-cmd --info-zone=mysite
mysite (actif)
  cible : par défaut
  inversion des blocages ICMP : non
  interfaces :
  sources : 192.168.200.0/24
  services :
  ports :
  protocoles :
  transfert : non
  masquerade : non
  ports de transfert :
  ports sources :
  blocages ICMP :
  règles riches :

Si vous n’avez pas encore configuré la Zone Publique sur l’Hôte β, comme décrit dans l’article original, faites-le maintenant. Configurez Host α de la même manière (mais sans aucune règle riche pour sa politique mywg2mysite). Ensuite, Testez-le !

Si cela fonctionne pour permettre à l’Endpoint A d’accéder au serveur web à l’Endpoint B (et de rejeter toutes autres connexions via le réseau WireGuard), enregistrez vos paramètres de configuration avec la commande suivante :

$ sudo firewall-cmd --runtime-to-permanent
success

Après avoir exécuté cette commande, vous trouverez la configuration pour la nouvelle politique mysite2mywg à /etc/firewalld/policies/mysite2mywg.xml :

<!-- Host β /etc/firewalld/policie

s/mysite2mywg.xml -->
<?xml version="1.0" encoding="utf-8"?>
<policy target="ACCEPT">
  <ingress-zone name="mysite"/>
  <egress-zone name="mywg"/>
</policy>

Et la configuration pour la nouvelle politique mywg2mysite à /etc/firewalld/policies/mywg2mysite.xml :

<!-- Host β /etc/firewalld/policies/mywg2mysite.xml -->
<?xml version="1.0" encoding="utf-8"?>
<policy target="REJECT">
  <rule family="ipv4">
    <destination address="192.168.200.22"/>
    <service name="http"/>
    <accept/>
  </rule>
  <ingress-zone name="mywg"/>
  <egress-zone name="mysite"/>
</policy>

Et la configuration pour la zone mysite à /etc/firewalld/zones/mysite.xml :

<!-- Host β /etc/firewalld/zones/mysite.xml -->
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <source address="192.168.200.0/24"/>
</zone>

Et la configuration pour la zone mywg à /etc/firewalld/zones/mywg.xml :

<!-- Host β /etc/firewalld/zones/mywg.xml -->
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <interface name="wg0"/>
</zone>

Versions de Distribution

Voici le tableau des versions de firewalld empaquetées par certaines des distributions Linux les plus populaires en avril 2022. La version 0,9 est requise pour utiliser les politiques :

Vous pouvez également exécuter la commande suivante pour vérifier la version de firewalld installée sur un hôte particulier :

$ sudo firewall-cmd --version
1,0.4

14/4/2022

par Justin Ludwig

• WireGuard
• Réseautage
• Pare-feu
• firewalld