fail2ban jail.local and nftables Backend Setup

fail2ban is the cheapest meaningful hardening step on an internet-facing Linux host: it watches authentication-related logs, counts failures per source address, and installs a temporary firewall block when the count trips a threshold. It is also the tool most likely to be found in a broken state, because administrators edit the shipped configuration and lose the changes at the next package upgrade. This is the maintainable setup.

jail.local, never jail.conf

/etc/fail2ban/jail.conf belongs to the package and is replaced on upgrade. All local changes go into /etc/fail2ban/jail.local, which fail2ban merges on top. The same rule applies to filters and actions: copy into filter.d/*.local or action.d/*.local instead of editing the originals.

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
backend  = systemd
banaction          = nftables[type=multiport]
banaction_allports = nftables[type=allports]
ignoreip = 127.0.0.1/8 ::1 10.0.1.0/24

[sshd]
enabled  = true
port     = ssh
mode     = normal
maxretry = 3

[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log

Three settings carry most of the operational weight. backend = systemd reads the journal instead of flat log files, which is how modern distributions actually log. banaction = nftables[...] integrates with the kernel's packet filter directly - no iptables shim, and no need to disable the host firewall, since the ban set is consulted before the application firewall chain. ignoreip is what keeps you from banning your own jump host or monitoring system; always include loopback, because local processes occasionally trip filters and self-banning a production host is a memorable afternoon.

Validate and reload

# fail2ban-client -t
# systemctl reload fail2ban
# fail2ban-client status sshd
# fail2ban-client status
# fail2ban-client set sshd unbanip 198.51.100.17

-t tests the configuration before you reload it; a syntax error at reload time can leave jails disabled and nobody notices until the next incident. systemctl reload re-reads configuration without dropping active bans, which is preferable to a restart during a brute-force campaign.

Where the bans live

# nft list ruleset | head -30
table inet f2b-table {
  set addr-set-sshd { type ipv4_addr; elements = { 198.51.100.17, 203.0.113.88 } }
  chain f2b-chain { type filter hook input priority filter - 1; policy accept;
    tcp dport 22 ip saddr @addr-set-sshd reject with icmp port-unreachable }
}

The chain priority is filter - 1, so banned addresses are dropped before other input rules see them - the block works even if your own firewall rules are more permissive than intended. Bans are stored in a named nftables set, so adding or removing an address is an atomic set update rather than a ruleset rebuild.

Custom jails: two files, always tested

# /etc/fail2ban/filter.d/wordpress-login.conf
[Definition]
failregex = ^<HOST> .* "POST /wp-login.php HTTP/.*" 200
            ^<HOST> .* "POST /xmlrpc.php HTTP/.*" 200
ignoreregex =

# test against a real log before enabling
# fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-login.conf

The test command reports how many lines matched and how many were rejected. If matches are zero while the log clearly contains the traffic, the regex - not fail2ban - is wrong. Enable the jail only after the count looks right:

[wordpress-login]
enabled  = true
port     = http,https
filter   = wordpress-login
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 5m
bantime  = 2h

Recidive: longer bans for repeat offenders

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 3

The recidive jail watches fail2ban's own log and re-bans addresses that keep coming back. Short bantime values in normal jails plus a long recidive ban is a better combination than a single long ban everywhere: it keeps the nftables set small for the scanners that give up, and applies real pain to the ones that do not.

Keeping it useful

• Monitor fail2ban-client status per jail; a jail whose "currently banned" count is always zero may simply be broken (wrong log path, wrong backend).
• Re-check custom filters after distribution or application upgrades - log formats change, and a filter that matches nothing fails silently.
• Alert on a spike in bans. It is one of the earliest indicators that a host or service is being attacked.
• Do not rely on fail2ban alone for SSH exposure: key-only authentication, a non-default port and a source-restricted firewall rule are all more effective first layers.

Related: nftables migration from iptables, ss, netstat and tcpdump troubleshooting, and Linux server operations guide.

原文链接：https://computingforgeeks.com/install-fail2ban-ubuntu-2604/