FirewallD sur un serveur LAN

FirewallD est un système de pare-feu principalement utilisé sur les systèmes Fedora, Red Hat Enterprise Linux et CentOS. On le trouve également sur d’autres distributions comme OpenSUSE. C’est un frontal à iptables qui comporte une série d’avantages par rapport à la gestion « classique » d’un pare-feu avec un script shell fait maison.

• FirewallD a un comportement dynamique, ce qui veut dire qu’un changement « à chaud » de la configuration n’entraîne pas nécessairement un rechargement intégral de l’ensemble des règles du pare-feu avec toutes les perturbations que cela entraîne.
• Il est plus confortable à manipuler qu’une litanie de règles iptables.
• Les règles prédéfinies sont probablement plus saines que ce que l’on pourra concocter avec un script fait maison.

FirewallD est très bien documenté dans la littérature imprimée et un peu partout sur le web. Je ne vais donc pas réinventer la roue et vous concocter une documentation exhaustive qui servirait tout au plus à vous épuiser aussi bien que le sujet. Au lieu de cela, j’ai décidé de vous présenter FirewallD comme j’aime bien le faire, en plongeant les mains dans le cambouis, et en découvrant ses fonctionnalités avec « quelque chose qui marche ». Suivez le guide.

Installation et mise en service

Mon serveur de sauvegardes nestor.microlinux.lan tourne sous CentOS 7 et dispose actuellement d’un pare-feu géré par un script iptables. Avant toute chose, je vais désactiver ce pare-feu « fait maison ».

$ sudo systemctl stop iptables
$ sudo yum remove iptables-services

J’installe le paquet firewalld, qui est fourni par les dépôts officiels.

$ sudo yum install firewalld

J’active et je lance le service correspondant.

$ sudo systemctl enable firewalld --now

L’outil firewall-cmd sert à communiquer avec le service firewalld. Nous pouvons déjà l’utiliser pour afficher l’état du pare-feu.

$ sudo firewall-cmd --state
running

La zone par défaut

La machine dispose d’une interface réseau enp2s0 reliée au réseau local.

$ nmcli con show
NAME  UUID                                  TYPE      DEVICE 
LAN   d99a2cf4-8576-3e56-993b-b18073ad169d  ethernet  enp2s0

Cette interface est actuellement associée à la zone public. Notez en passant que certaines options de firewall-cmd peuvent très bien être utilisées sans les privilèges de l’administrateur root.

$ firewall-cmd --get-active-zones
public
  interfaces: enp2s0

Une « zone » est ici une collection de règles de pare-feu associées à un certain contexte. FirewallD fournit toute une série de zones prédéfinies.

$ firewall-cmd --get-zones
block dmz drop external home internal public trusted work

Changer de zone comme de chemise

Pour me faire une première idée concrète de ces différentes zones, je vais tenter une petite expérience en passant à la volée de la zone public à la zone drop.

$ sudo firewall-cmd --zone=drop --change-interface=enp2s0
success

J’ouvre un deuxième terminal sur ma station de travail et j’essaie d’envoyer un ping vers mon serveur. Je n’obtiens aucune réponse.

[kikinovak@alphamule:~] $ ping nestor
PING nestor.microlinux.lan (192.168.2.250) 56(84) bytes of data.

Je reviens dans la session ouverte sur mon serveur, et je passe de la zone drop à la zone block.

$ sudo firewall-cmd --zone=block --change-interface=enp2s0
success

Je retente un ping depuis ma station de travail. Cette fois-ci, j’ai un message qui me dit explicitement que je n’ai pas le droit d’accéder à la machine.

[kikinovak@alphamule:~] $ ping nestor
PING nestor.microlinux.lan (192.168.2.250) 56(84) bytes of data.
From nestor.microlinux.lan (192.168.2.250) icmp_seq=1 Destination Host Prohibited
From nestor.microlinux.lan (192.168.2.250) icmp_seq=2 Destination Host Prohibited
From nestor.microlinux.lan (192.168.2.250) icmp_seq=3 Destination Host Prohibited
From nestor.microlinux.lan (192.168.2.250) icmp_seq=4 Destination Host Prohibited

À présent, je rebascule vers la zone public initialement définie.

$ sudo firewall-cmd --zone=public --change-interface=enp2s0
success

Et je constate que le ping fonctionne correctement.

[kikinovak@alphamule:~] $ ping nestor
PING nestor.microlinux.lan (192.168.2.250) 56(84) bytes of data.
64 bytes from nestor.microlinux.lan (192.168.2.250): icmp_seq=1 ttl=64 time=0.388 ms
64 bytes from nestor.microlinux.lan (192.168.2.250): icmp_seq=2 ttl=64 time=0.394 ms
64 bytes from nestor.microlinux.lan (192.168.2.250): icmp_seq=3 ttl=64 time=0.388 ms
64 bytes from nestor.microlinux.lan (192.168.2.250): icmp_seq=4 ttl=64 time=0.412 ms

Je ne vais pas rentrer dans les détails de chacune de ces zones. C’est très bien documenté dans la littérature officielle.

Définir la zone appropriée

La zone internal me semble appropriée pour mon serveur de sauvegardes. Comme son nom le suggère, l’option --permanent assure la persistance de cette transition.

$ sudo firewall-cmd --permanent --zone=internal --change-interface=enp2s0
The interface is under control of NetworkManager, setting zone to 'internal'.
success

L’association à la zone internal est inscrite dans le fichier correspondant à la configuration de l’interface réseau, en l’occurrence ifcfg-LAN.

$ grep -i zone /etc/sysconfig/network-scripts/ifcfg-LAN
ZONE=internal

Je définis cette zone par défaut.

$ sudo firewall-cmd --set-default-zone=internal
success

Afficher les services autorisés

J’affiche la configuration associée à la zone.

$ sudo firewall-cmd --list-all
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp2s0
  sources: 
  services: dhcpv6-client mdns samba-client ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

Je peux limiter cet affichage aux seuls services autorisés.

$ sudo firewall-cmd --list-services
dhcpv6-client mdns samba-client ssh

Si l’on veut en savoir un peu plus sur la configuration des accès aux différents services, il suffit de jeter un oeil dans les fichiers XML rangés dans /usr/lib/firewalld/services.

Supprimer quelques services prédéfinis

Sur cette machine, je peux sereinement me débarrasser de dhcpv6-client, mdns et samba-client pour ne garder que le seul service ssh. L’option --reload prend en charge les modifications permanentes effectuées auparavant.

$ sudo firewall-cmd --permanent --remove-service=dhcpv6-client
success
$ sudo firewall-cmd --permanent --remove-service=mdns
success
$ sudo firewall-cmd --permanent --remove-service=samba-client
success
$ sudo firewall-cmd --reload
success

Mon serveur de sauvegardes est désormais doté d’un pare-feu avec une configuration adaptée et cohérente.

La suite au prochain numéro, où nous examinerons FirewallD sur un routeur.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.