Garantir que le pare-feu de l'hôte refuse par défaut (quel que soit le backend)
Le pare-feu de l'hôte doit appliquer une politique de refus par défaut sur le trafic entrant : tout ce qui n'est pas explicitement autorisé est rejeté. Pavois accepte n'importe quel backend et vérifie dans le jeu de règles chargé la présence d'une chaîne input nftables en policy drop, ou d'une cible par défaut iptables -P INPUT DROP / REJECT.
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.
Ce que vérifie Pavois
Pavois inspecte le jeu de règles chargé (nft list ruleset, avec repli sur iptables -S INPUT), c'est-à-dire ce que le noyau applique réellement à chaque paquet. Lire /etc/nftables.conf ou /etc/ufw/ prouverait seulement qu'une politique existe sur le disque : un jeu de règles jamais chargé, un service de pare-feu qui a échoué au démarrage, ou un jeu de règles vidé par un autre outil seraient tous déclarés conformes alors que l'hôte est grand ouvert. C'est aussi la raison du reboot_survivable: no : un policy drop actif n'est durable que si le service de pare-feu est activé au démarrage, ce que fait précisément la remédiation Pavois.
describe command('if nft list ruleset 2>/dev/null | grep -qE \'hook input.*policy drop\' || iptables -S INPUT 2>/dev/null | grep -qE \'^-P INPUT (DROP|REJECT)\'; then echo ok; else echo ko; fi') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Sur un hôte nftables, vérifiez que le hook d'entrée rejette par défaut et que SSH reste explicitement autorisé :
nft list ruleset | grep -E 'hook input|dport 22'
# type filter hook input priority 0; policy drop;
# ip saddr { 203.0.113.0/24 } tcp dport 22 accept
Sur un hôte iptables/ufw, iptables -S INPUT | head -1 doit afficher -P INPUT DROP. Vérifiez aussi que le jeu de règles revient après un redémarrage : systemctl is-enabled nftables (ou ufw / firewalld) renvoie enabled.
Inspecter et investiguer
Un policy drop est silencieux : nftables ne journalise pas les paquets rejetés tant qu'une règle log prefix explicite n'est pas ajoutée avant la politique. Utilisez les compteurs de nft list ruleset -a, ou ufw logging on (qui écrit dans /var/log/ufw.log et le journal du noyau), pour voir ce que la politique par défaut rejette réellement. Le cycle de vie du service de pare-feu (échec de chargement du jeu de règles, erreur de syntaxe) se trouve dans journalctl -u nftables / -u firewalld / -u ufw : c'est là qu'apparaît un hôte silencieusement sans protection.
Remédiation
Le plan Pavois expose cette règle comme un choix de backend (choose:) : nftables (par défaut), firewalld ou ufw. Avec nftables, Pavois installe le paquet et écrit un jeu de règles complet : policy drop sur input et forward, accept sur output, plus la boucle locale, ct state established,related, le rejet de ct state invalid, ICMP/ICMPv6, et une règle d'autorisation SSH que Pavois injecte lui-même. Renseignez ssh_allow_from: [203.0.113.0/24] sur la règle dans le plan et cette règle devient ip saddr { 203.0.113.0/24 } tcp dport 22 accept (avec le backend ufw : ufw allow from 203.0.113.0/24 to any port 22 proto tcp, exécuté avant ufw --force enable). Si vous laissez ssh_allow_from vide, SSH est ouvert à tous : c'est la valeur de repli sûre et volontaire, pour qu'un plan qui l'oublie n'enferme jamais l'administrateur dehors. Le pare-feu est levé avant le reste de la convergence, et Pavois active le service afin que le jeu de règles soit rechargé au démarrage.
Cette règle appartient à un groupe exclusif : un seul démon de pare-feu est conservé, et ceux que personne n'a choisis sont désactivés une seule fois, après que tous les contrôles du groupe se sont exprimés.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| default | nftables |
|---|---|
| options | firewalld: package: firewalld, service: firewalld, nftables: package: nftables, ruleset: #!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority 0; policy drop; iif "lo" accept ct state established,related accept ct state invalid drop ip protocol icmp accept ip6 nexthdr ipv6-icmp accept %SSH_RULE% } chain forward { type filter hook forward priority 0; policy drop; } chain output { type filter hook output priority 0; policy accept; } } , service: nftables, ssh_rule: tcp dport 22 accept, ssh_rule_from: ip saddr { %CIDRS% } tcp dport 22 accept, ufw: enable_cmd: %SSH_ALLOW%; /usr/sbin/ufw --force enable; systemctl enable --now ufw, package: ufw, service: ufw, ssh_allow: /usr/sbin/ufw allow OpenSSH 2>/dev/null; /usr/sbin/ufw allow 22/tcp 2>/dev/null, ssh_allow_from: /usr/sbin/ufw allow from %SRC% to any port 22 proto tcp 2>/dev/null |
| resource | choose |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Cette règle peut vous couper de la machine. Une politique d'entrée en refus par défaut appliquée sans règle d'autorisation SSH met fin à toute session distante et refuse la suivante, définitivement : sur un hôte sans écran ou une instance cloud sans console, la machine est perdue. Avant d'appliquer :
- Renseignez
ssh_allow_fromdans le plan avec le CIDR de votre réseau d'administration (ou laissez-le vide pour garder le port 22 ouvert à tous) : Pavois injecte la règle d'autorisation dans le jeu de règles qu'il écrit, et c'est votre seule garantie de pouvoir revenir. - Gardez une seconde session ou une console ouverte, puis ouvrez une nouvelle session SSH pour confirmer l'accès avant de fermer la première.
- N'activez jamais deux pare-feux. nftables et firewalld/ufw actifs ensemble finissent par s'annuler (mesuré sur une machine réelle : les deux installés, les deux morts, aucune protection). Pavois résout le groupe exclusif une seule fois, mais un pare-feu configuré à la main en dehors de Pavois peut réintroduire le conflit.
- Attention à l'interaction avec
kmod-loading-disabled. Les règlesct stateont besoin denf_conntrack; si le chargement de modules est déjà verrouillé (kernel.modules_disabled=1) et que le module n'est pas chargé, le jeu de règles ne se charge pas et l'hôte se retrouve sans pare-feu, ou sans SSH. - Chaque service que vous publiez (HTTP, réplication de base de données, agent de supervision) réclame sa propre règle d'autorisation : inventoriez vos ports en écoute (
ss -tulpn) avant de basculer la politique.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 4.2.7, 4.3.8, 4.4.2.1 | direct | per OS, see the benchmark table | haute |
| NIST | CA-3(5), CM-7(b), SC-7(23), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 1.3.1 | support | 4.0.1 | moyenne |
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.