fail2ban bans after three failures. Nine out of ten of those hosts were already on public blocklists before the first one.
Free, no signup. Checked against 140+ public blocklists rebuilt every day.
For two weeks we asked IPGuardian about every address fail2ban banned on one small server. Out of 447 attackers, 91.5% were already on at least one public blocklist at the moment of the ban, and 78% were on ten or more. Two weeks later 99.8% were listed. Of 9,982 failed SSH password attempts, 61.5% came from addresses the lists already knew.
Report-driven lists do the work: the 30-day AbuseIPDB feed alone covered 95% of the attackers, followed by ipsum (86%), blocklist.de (73%) and its SSH-specific list (72%). Brute-force scanners are loud, so community reports catch them within days.
The integration is two small Python scripts without dependencies and one fail2ban action file.
sudo ./install.sh[sshd]
enabled = true
action = %(action_)s
ipguardianjournalctl -t ipguardianThe second tool scans any log, checks the addresses in batches of 100 and shows which are already listed:
sudo ipguardian-scan /var/log/auth.log --min-sources 2
It is a dry run by default; --ban hands the matches to fail2ban. The threshold of two independent lists is deliberate, a single list is not enough to block on. Put your own addresses in --exclude. The anonymizers category is not a ban criterion: being a Tor exit is not an offence.
No. About one attacker in ten is unknown to every list at first contact. Blocklists complement behaviour-based banning.
Nothing. The API has no key and no signup; limits are 100 addresses per request and 100 requests per minute.
No. The lookup runs after the ban action and takes a few milliseconds; if the API is unreachable the ban still happens.
Yes. ipguardian-scan extracts addresses from any text log.