Fail2ban with nftables and Crowd-Sourced Blacklists

Step 9: Enable and test

# Start and enable fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check jail status
sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo fail2ban-client status nginx-forbidden
sudo fail2ban-client status nginx-ratelimit
sudo fail2ban-client status nginx-404

To test the nginx-forbidden jail, trigger a 403 intentionally — request a blocked path from an external IP:

curl -I https://yoursite.com/wp-config.php

Repeat three times within 2 hours. Check that the IP appears in the banned list:

sudo fail2ban-client status nginx-forbidden
sudo nft list set inet f2b-table abuse-blacklist | head -20

Test the nginx-ratelimit jail by hitting a PHP endpoint rapidly:

for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" https://yoursite.com/; done

After 15+ rapid requests you should see 429 responses. Check the jail:

sudo fail2ban-client status nginx-ratelimit

Verify the blacklist script works by running it manually once:

sudo /usr/local/bin/update-abuse-blacklist.sh

Step 10: Production hardening

Cloudflare and reverse proxies: If you use Cloudflare or any reverse proxy with ngx_http_realip_module, nginx gives you two client-address variables:

$binary_remote_addr is the compact binary form of $remote_addr — the visitor IP after realip processing. This is the variable you want for per-visitor rate and connection limiting.

If you accidentally key limit_req_zone on $realip_remote_addr, all visitors behind the same Cloudflare edge share one bucket. One bot burns the rate limit; legitimate visitors get throttled or 429'd. On a small site with only a few Cloudflare edge IPs, this silently collapses your rate limiting to a handful of shared buckets.

To verify which values your variables hold, add a temporary debug location and hit it through your proxy:

location /debug-realip {
    allow YOUR_HOME_IP;
    deny all;
    default_type application/json;
    add_header X-Remote-Addr "$remote_addr" always;
    add_header X-RealIP-Remote-Addr "$realip_remote_addr" always;
    return 200 '{"remote_addr":"$remote_addr","realip_remote_addr":"$realip_remote_addr"}';
}

Hit it through Cloudflare and inspect the response headers. X-Remote-Addr should be your real IP; X-RealIP-Remote-Addr should be a Cloudflare IP. Remove the location after testing.

SSH on systemd systems: Modern OpenSSH logs authentication failures from sshd-session, not sshd. If your server uses the systemd backend (the default on Debian/Ubuntu), add this to /etc/fail2ban/jail.d/defaults-debian.conf:

[sshd]
backend = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session
enabled = true

Without sshd-session in the match, fail2ban sees almost no authentication failures. This requires a full restart — sudo systemctl restart fail2ban — not a reload. A reload preserves the journal subscription; only a restart tears it down and re-establishes with the new match string.

What this setup protects against

Daily blacklist (AbuseIPDB + Bitwire + Spamhaus) — Known bad actors before they ever send a packet. ISP netblocks run by criminals, IPs with thousands of abuse reports, and addresses flagged across the community are dropped at the firewall before they reach Nginx.

fail2ban (nginx-forbidden) — Bots probing your specific site right now. Hitting wp-config.php, xmlrpc.php, .env files, and other protected paths triggers a 403, which fail2ban detects and bans on repeat — with each offense reported to AbuseIPDB.

fail2ban (nginx-ratelimit) — Bots that bypass forbidden rules by probing random framework paths that return 404 through the PHP stack. Rate limiting the PHP handler caps their throughput, and repeated 429s trigger a ban.

fail2ban (nginx-404) — Scanners that enumerate non-existent paths without hitting PHP or forbidden rules. High-speed 404 storms trigger a short ban, breaking the scanner's momentum without risking false positives for normal users.

fail2ban (sshd) — SSH brute-force attempts caught early, banned for escalating durations with the incremental formula, and reported to AbuseIPDB so other servers know about the attacker too.

The blacklist catches the drive-by scanner before it even reaches Nginx. fail2ban catches the targeted bot that's specifically probing your site. Together they cover both the generic noise and the directed attacks.