Install fail2ban (brute-force protection)
fail2ban watches authentication logs and, when one source IP fails to authenticate too often inside a time window, inserts a firewall rule that drops it for a bantime. On Debian and Ubuntu the sshd jail is enabled out of the box, so installing the package already blunts SSH password-guessing and credential-stuffing floods. No standard mandates it: Pavois carries it as a defence-in-depth practice. It is a rate limiter on failed logins, not an authentication control.
Checked against what is installed or registered, packages present/absent, account databases.
What Pavois checks
Pavois asserts that fail2ban is present in the dpkg inventory. This is an inventory-state control: it proves the package is installed, not that fail2ban-server is running, that a jail is enabled, or that the jail's log backend actually sees anything. That last point matters: a jail pointed at /var/log/auth.log on a host that only logs to the systemd journal reads an empty file and bans nobody, while this rule stays green. Read the check as "the tool is there", and confirm the jail separately.
describe package('fail2ban') do
it { should be_installed }
endHow to verify it is applied
Run dpkg -l fail2ban and confirm the state column reads ii:
ii fail2ban 1.0.2-2 all ban hosts that cause multiple authentication errors
Then check it is doing its job: systemctl is-active fail2ban returns active, fail2ban-client status lists the enabled jails (Jail list: sshd), and fail2ban-client status sshd shows the counters and the currently banned addresses:
|- Currently failed: 2
|- Total failed: 41
`- Banned IP list: 203.0.113.10
Inspect & investigate
fail2ban keeps its own log, /var/log/fail2ban.log, with one line per decision (jail, action, address):
fail2ban.actions [1234]: NOTICE [sshd] Ban 203.0.113.10
fail2ban.actions [1234]: NOTICE [sshd] Unban 203.0.113.10
The daemon's lifecycle is in the journal (journalctl -u fail2ban), and the failed logins it reacts to are in /var/log/auth.log (or journalctl -u ssh). This is the one package in this family that produces a real, greppable audit trail: grep Ban /var/log/fail2ban.log is your evidence that the protection fired.
Remediation
The Pavois harden plan installs the fail2ban package with the system package manager (package resource, action install). It writes no jail configuration: what becomes active is the distribution's default sshd jail (/etc/fail2ban/jail.d/defaults-debian.conf). Tuning bantime, maxretry and above all ignoreip is left to you, in a local jail.local.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | install |
|---|---|
| name | fail2ban |
| resource | package |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without fail2ban, an exposed SSH port absorbs brute-force attempts indefinitely: key-only authentication and MaxAuthTries bound the real risk, but the noise, the log volume and the CPU cost remain. The side effects are the reason to think before installing it. It can ban you: an administrator who mistypes a password from the office IP, or a monitoring probe that authenticates badly, gets exactly the same treatment as an attacker, and on a headless host that is a lockout. Set ignoreip to your admin ranges before the first ban, and keep a second session open. It writes to the firewall (nftables or iptables), so it can collide with a ruleset you manage declaratively elsewhere, and flushing that ruleset silently drops its bans. Finally, a fail2ban whose jail reads the wrong log source runs, reports active, and protects nothing: verify the ban counters, never the service state alone.