Durcir le pare-feu local

La menace : chaque port joignable est une porte ouverte

Chaque démon qui appelle listen() ouvre une porte sur le réseau, et beaucoup en ouvrent plus qu'on ne le croit : une base de données censée ne répondre que sur 127.0.0.1 finit liée à 0.0.0.0, un endpoint de debug reste actif après un déploiement, un paquet tire un service dont on ne voulait pas. Sans filtre de paquets, tous sont exposés à quiconque peut router jusqu'à l'hôte : le LAN du bureau, un VPC cloud, l'Internet ouvert. Les attaquants ne devinent pas : ils scannent en masse tout l'espace IPv4 à la recherche de ports ouverts en quelques minutes, identifient le service, puis lancent l'exploit correspondant. Et dès qu'une machine tombe, un réseau à plat sans pare-feu local transforme un simple pied dans la place en déplacement latéral trivial vers tous les voisins.

Pourquoi le durcir

La taille de votre surface d'attaque, c'est exactement l'ensemble des ports joignables, et l'on veut cet ensemble aussi réduit et délibéré que possible. Un pare-feu local permet d'affirmer, au niveau du noyau, « cette machine accepte le trafic entrant sur ces ports et rien d'autre », indépendamment de la configuration de chaque service. C'est de la défense en profondeur : même si un démon écoute sur toutes les interfaces, ou si un nouveau port apparaît après une mise à jour, le pare-feu garde le réseau silencieux tant que vous ne l'ouvrez pas. C'est aussi votre filet face à l'écart entre installé et filtrant réellement : un paquet pare-feu présent mais arrêté ne protège rien.

Principes de défense appliqués

• Refus par défaut : passez la politique entrante en drop/deny et n'autorisez en liste blanche que les ports dont un rôle a besoin (22/tcp pour SSH, 443/tcp pour un serveur web). Tout ce qui n'est pas listé est refusé.
• Réduction de la surface d'attaque : moins de ports joignables, c'est moins de services à qui un attaquant peut parler.
• Défense en profondeur : le pare-feu épaule la config des services ; il ne remplace pas le durcissement de sshd, il le contient.
• Un seul backend, clairement assumé : un unique filtre (nftables, firewalld ou ufw), jamais deux couches empilées aux règles conflictuelles. Les trois pilotent nftables dans le noyau en dessous.
• Échouer sans danger, rester joignable : une politique de refus par défaut qui oublie 22/tcp coupe votre propre SSH ; autorisez d'abord l'accès d'administration et gardez une console hors-bande.

Ce que Pavois audite : un filtre réellement actif

Pavois audite l'état d'exécution effectif, pas une liste de paquets ni un fichier. Sa règle firewall-present parcourt ufw, nftables et firewalld et exécute systemctl is-active --quiet <service> ; elle n'est conforme que si au moins un filtre de paquets tourne réellement. Un pare-feu installé mais arrêté, masqué ou en échec de démarrage est correctement signalé, précisément l'écart qu'un scan par fichier (OVAL/oscap) rate. La règle porte les vrais mappings ANSSI BP-028 R50, CIS 4.x, NIST 3.1.3, PCI-DSS 1.2.1 et STIG, et le plan de durcissement peut installer puis activer un backend (défaut firewalld).

Comment le poser sans se verrouiller dehors ?

L'ordre compte : autorisez l'accès d'administration d'abord, activez la politique en dernier.

# UFW (Debian/Ubuntu)
ufw allow OpenSSH        # ou : ufw allow 22/tcp  -- AVANT d'activer
ufw default deny incoming
ufw default allow outgoing
ufw enable               # seulement maintenant

# firewalld (RHEL)
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --set-target=DROP   # sur la zone active
firewall-cmd --reload

Le piège firewalld : runtime contre permanent. Un simple firewall-cmd --add-service=... ne change que le jeu de règles runtime et est perdu au --reload ou au redémarrage. Utilisez --permanent puis --reload (ou --runtime-to-permanent) pour que la règle persiste vraiment. C'est l'écart de config effective : le jeu de règles vivant et le jeu sauvegardé peuvent différer.

Vérifier

Lisez le jeu de règles effectif, pas seulement la config :

ufw status verbose                  # UFW : politique + ports autorises
firewall-cmd --list-all             # firewalld : services/ports de la zone active
nft list ruleset                    # le vrai jeu de règles noyau, quel que soit le frontend
ss -tulpen                          # ce qui ecoute reellement (recoupement)

Couverture et limites

Pavois confirme qu'un filtre de paquets est actif, la baseline honnête. Il n'audite pas encore le contenu du jeu de règles (cible default-deny, services par zone, rich rules), ce qui est en roadmap ; aujourd'hui vous rédigez et vérifiez les règles d'autorisation/refus vous-même avec les commandes ci-dessus. Le handbook l'explicite pour que le contrôle ne soit pas pris pour une assurance complète du jeu de règles.

FAQ

Pourquoi Pavois vérifie-t-il seulement qu'un pare-feu tourne ? Parce qu'un filtre présent mais arrêté est l'échec réel le plus courant, et que c'est la baseline honnête et portable entre ufw/firewalld/nftables. L'audit complet du jeu de règles et des zones est en roadmap.

ufw, firewalld ou nftables ? Choisissez-en un. ufw est le plus simple (Debian/Ubuntu), firewalld est à base de zones (RHEL), nftables est le plus bas niveau et ce que les autres pilotent. En faire tourner deux à la fois produit des règles conflictuelles.

Ma règle firewalld a disparu après un reload. Elle était runtime seulement. Réajoutez-la avec --permanent puis --reload, ou firewall-cmd --runtime-to-permanent.