Un pare-feu local est installé et actif
Garantit qu'au moins un service de pare-feu local (ufw, nftables ou firewalld) est installé et actuellement actif.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Domaine peu couvert par Pavois aujourd’hui, voir la couverture.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Un pare-feu local est la dernière ligne de défense d'une machine : il filtre le trafic entrant et sortant pour que seuls les services voulus soient accessibles, même si un service est mal configuré et écoute sur toutes les interfaces. Sans pare-feu actif, chaque port ouvert est exposé à tout le réseau, élargissant la surface d'attaque et rendant le déplacement latéral trivial dès qu'un hôte est compromis. Exiger au moins l'un de ufw/nftables/firewalld garantit qu'un filtre de paquets tourne réellement, et n'est pas seulement installé.
Ce que vérifie Pavois
Pavois parcourt ufw, nftables et firewalld et exécute systemctl is-active --quiet <s> ; si l'un est actif il affiche ok. Cela audite l'état d'exécution effectif via systemd, et non la simple présence d'un paquet ou d'un fichier de configuration, un pare-feu installé mais arrêté, masqué ou en échec de démarrage est correctement signalé non conforme.
describe command('for s in ufw nftables firewalld; do systemctl is-active --quiet "$s" && { echo ok; exit 0; }; done; echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-active ufw nftables firewalld. Attendu : au moins un renvoie active. Vous pouvez aussi confirmer que des règles sont chargées avec ufw status, nft list ruleset ou firewall-cmd --state selon le backend utilisé.
Inspecter et investiguer
Utilisez systemctl status firewalld (ou ufw/nftables) pour voir les événements démarrage/arrêt, et journalctl -u firewalld pour le journal du service. Inspectez le jeu de règles actif avec nft list ruleset ou iptables-save ; les paquets rejetés apparaissent dans journalctl -k / /var/log/kern.log quand des cibles de journalisation sont configurées.
Remédiation
Le plan de durcissement de Pavois utilise une ressource choose : vous choisissez un backend parmi ufw, nftables ou firewalld (défaut firewalld). Il installe ensuite le paquet correspondant puis active et démarre le service correspondant. Appliqué avec pavois harden apply. Il met en place un pare-feu fonctionnel mais ne rédige pas de jeu de règles sur mesure, définissez votre politique d'autorisation/refus ensuite.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| default | ufw |
|---|---|
| options | firewalld: package: firewalld, service: firewalld, nftables: package: nftables, service: nftables, ufw: package: ufw, service: ufw |
| resource | choose |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque de verrouillage : activer un pare-feu avec une politique de refus par défaut peut couper votre session SSH si le jeu de règles par défaut bloque le port 22. Avant d'appliquer sur un hôte distant, autorisez explicitement SSH d'abord (par ex. ufw allow OpenSSH / firewall-cmd --add-service=ssh --permanent) et gardez une console hors-bande (série/IPMI) disponible. Faire tourner deux backends simultanément (par ex. ufw au-dessus de nftables) peut aussi produire des règles confuses ou conflictuelles, choisissez un seul backend par hôte.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| CIS | 4.1.1, 4.2.3, 4.1.2, 4.1.3 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.3 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 1.2.1 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-251020, UBTU-24-100300 | direct | per OS STIG release | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.