A host firewall is installed and active
Ensures at least one host firewall service (ufw, nftables, or firewalld) is installed and currently active.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
This domain is thinly covered by Pavois today, see coverage.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
A host firewall is the last line of defense for a machine: it filters inbound and outbound traffic so that only intended services are reachable, even if a service is misconfigured to listen on all interfaces. Without an active firewall, every open port is exposed to the whole network, widening the attack surface and making lateral movement trivial after a single host is compromised. Requiring at least one of ufw/nftables/firewalld ensures a packet filter is actually running, not merely installed.
What Pavois checks
Pavois loops over ufw, nftables and firewalld and runs systemctl is-active --quiet <s>; if any one is active it prints ok. This audits the effective runtime state via systemd, not the mere presence of a package or a config file, a firewall installed but stopped, masked, or failed to start is correctly reported as non-compliant.
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' }
endHow to verify it is applied
Run systemctl is-active ufw nftables firewalld. Expected: at least one returns active. You can also confirm rules are loaded with ufw status, nft list ruleset, or firewall-cmd --state depending on the backend in use.
Inspect & investigate
Use systemctl status firewalld (or ufw/nftables) to see start/stop events, and journalctl -u firewalld for the service journal. Inspect the live ruleset with nft list ruleset or iptables-save; dropped packets appear in journalctl -k / /var/log/kern.log when logging targets are configured.
Remediation
Pavois's harden plan uses a choose resource: you pick one backend among ufw, nftables, or firewalld (default firewalld). It then installs the matching package and enables + starts the matching service. Applied with pavois harden apply. It establishes a running firewall but does not author a tailored ruleset, define your allow/deny policy afterward.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| default | ufw |
|---|---|
| options | firewalld: package: firewalld, service: firewalld, nftables: package: nftables, service: nftables, ufw: package: ufw, service: ufw |
| resource | choose |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Lockout risk: enabling a firewall with a default-deny policy can cut your SSH session if the default ruleset blocks port 22. Before applying on a remote host, explicitly allow SSH first (e.g. ufw allow OpenSSH / firewall-cmd --add-service=ssh --permanent) and keep an out-of-band console (serial/IPMI) available. Running two backends at once (e.g. ufw over nftables) can also produce confusing or conflicting rules, pick one backend per host.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | high |
| CIS | 4.1.1, 4.2.3, 4.1.2, 4.1.3 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.3 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 1.2.1 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-251020, UBTU-24-100300 | direct | per OS STIG release | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.