Voici le deuxième article dans la série sur le système de pare-feu FirewallD. Dans notre précédent article, nous avons configuré FirewallD sur un serveur simple dans le réseau local. Aujourd’hui nous allons nous intéresser de plus près à la configuration de FirewallD sur une machine qui relie deux réseaux entre eux.
État des lieux
Dans le réseau de mon entreprise, la machine proxy.microlinux.lan est un routerboard PC Engines muni d’une installation de CentOS 7. Elle dispose actuellement d’un pare-feu géré par un script iptables.
Avant de supprimer ce pare-feu « fait maison », j’affiche les règles en vigueur et je prends note des différents services autorisés. Voici le minimum syndical pour que mon réseau fonctionne correctement.
- SSH
- DHCP
- DNS
- NTP
Le script iptables gère également le relais des paquets (IP Masquerading) pour que les machines du réseau local puissent se connecter à Internet.
Installation et mise en service
Je désactive le pare-feu « fait maison ».
$ sudo systemctl stop iptables $ sudo yum remove iptables-services
J’installe le paquet firewalld.
$ sudo yum install firewalld
J’active et je lance le service correspondant.
$ sudo systemctl enable firewalld --now
J’affiche l’état du pare-feu.
$ sudo firewall-cmd --state running
Interfaces réseau et zone par défaut
Le routeur dispose d’une interface réseau enp1s0 relié à la Freebox et d’une autre interface enp2s0 reliée au switch côté réseau local.
$ nmcli con show NAME UUID TYPE DEVICE WAN b22b118d-6152-3295-a095-1154a6f056cb ethernet enp1s0 LAN c9489004-f823-42df-8d23-5c4ad1294220 ethernet enp2s0
Dans la configuration par défaut, les deux interfaces sont associées à la zone public.
$ firewall-cmd --get-active-zones public interfaces: enp1s0 enp2s0
Définir les zones appropriées
Dans notre précédent article, nous avons eu l’occasion d’aborder les « zones » de FirewallD, qui représentent une collection de règles de pare-feu adaptées à un certain contexte. Les deux zones external et internal sont spécialement adaptées à l’utilisation sur un routeur.
$ firewall-cmd --get-zones block dmz drop external home internal public trusted work
J’associe la zone external à l’interface enp1s0.
$ sudo firewall-cmd --permanent --zone=external --change-interface=enp1s0 The interface is under control of NetworkManager, setting zone to 'external'. success
Quant à l’interface enp2s0, elle va opérer la transition vers la zone internal.
$ sudo firewall-cmd --permanent --zone=internal --change-interface=enp2s0 The interface is under control of NetworkManager, setting zone to 'internal'. success
Voici mes deux zones internal et external avec les interfaces réseau respectives qui leur sont associées.
$ sudo firewall-cmd --get-active-zones internal interfaces: enp2s0 external interfaces: enp1s0
Cette information est inscrite dans la configuration réseau des interfaces respectives.
$ grep -i zone /etc/sysconfig/network-scripts/ifcfg-LAN ZONE=internal $ grep -i zone /etc/sysconfig/network-scripts/ifcfg-WAN ZONE=external
Je définis la zone internal comme zone par défaut.
$ sudo firewall-cmd --set-default-zone=internal success
Afficher les services autorisés
J’affiche la configuration de la zone internal. Étant donné que je viens de la définir comme zone par défaut, je n’ai pas besoin de préciser --zone=internal dans la commande.
$ 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:
Supprimer quelques services prédéfinis
Je peux sereinement me débarrasser de dhcpv6-client, mdns et samba-client pour ne garder que le seul service ssh.
$ 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
Afficher les services disponibles
J’affiche la liste complète des services disponibles et je repère ceux qui m’intéressent.
$ firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula
bacula-client bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph
ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns
docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client
etcd-server finger freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust
ftp ganglia-client ganglia-master git gre high-availability http https imap
imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kerberos
kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls
lightning-network llmnr managesieve matrix mdns minidlna mongodb mosh mountd
mqtt mqtt-tls ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn
ovirt-imageio ovirt-storageconsole ...
Autoriser les services nécessaires
J’autorise les services dns, dhcp et ntp pour la zone internal. Là encore, ce n’est pas la peine de préciser la zone explicitement, étant donné qu’il s’agit de la zone par défaut.
$ sudo firewall-cmd --permanent --add-service=dns success $ sudo firewall-cmd --permanent --add-service=dhcp success $ sudo firewall-cmd --permanent --add-service=ntp success $ sudo firewall-cmd --reload success
J’affiche le résultat de l’opération.
$ sudo firewall-cmd --list-services dhcp dns ntp ssh
Le relais des paquets
À partir de là, mon routeur est parfaitement fonctionnel, et je n’ai rien de plus à faire. En effet, la configuration par défaut de la zone external gère d’emblée le relais des paquets, sans qu’il y ait quoi que ce soit à configurer à la main.
$ sudo firewall-cmd --list-all --zone=external external external (active) target: default icmp-block-inversion: no interfaces: enp1s0 sources: services: ssh ports: protocols: masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules:
Un peu de ménage
Pour finir, je peux faire un peu de ménage. Le répertoire /etc/sysctl.d contient encore un fichier enable-ip-forwarding.conf qui active explicitement le relais des paquets dans le noyau.
# /etc/sysctl.d/enable-ip-forwarding.conf
net.ipv4.ip_forward = 1
Nous pouvons sereinement envoyer ce fichier au paradis des octets, étant donné que FirewallD gère désormais tout ce qui relève du relais des paquets.
$ sudo rm /etc/sysctl.d/enable-ip-forwarding.conf
En conclusion pour aujourd’hui, nous pouvons dire que la transition vers FirewallD sur un routeur apporte une amélioration réelle en termes de facilité et de confort d’utilisation.
Notre prochain article traitera de l’utilisation de FirewallD sur un serveur dédié.
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.
