Basics

How to Test a Fail2ban Filter Before Enabling It (fail2ban-regex)

3 min read

Before you enable a jail, prove its filter actually matches your log lines. fail2ban-regex does exactly that without banning anyone.

1. Test a log file against a filter

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

It prints something like:

Results
=======
Failregex: 42 total
|- #) [# of hits] regular expression
|  1) [42] ^...Failed password for ...
Lines: 1839 lines, 0 ignored, 42 matched, 1797 missed

matched = lines that would count toward a ban. missed = lines the filter ignored (usually normal traffic — that’s fine).

2. Test a single line

Quote the log line and the filter name:

fail2ban-regex 'Jan  1 12:00:00 host sshd[123]: Failed password for root from 1.2.3.4 port 22 ssh2' sshd

If it shows 1 matched and pulls out the host 1.2.3.4, the filter works.

3. Test against the systemd journal

On distros with no /var/log/auth.log:

fail2ban-regex "systemd-journal[_SYSTEMD_UNIT=ssh.service]" /etc/fail2ban/filter.d/sshd.conf

4. See exactly what was captured

Add --print-all-matched to list every matched line, or -o '<ip>' to print just the host the regex extracted — handy when writing a custom filter:

fail2ban-regex --print-all-matched /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-botsearch.conf

Rule of thumb: if matched is 0 on a log you know contains attacks, your failregex is wrong or you pointed at the wrong logpath. Fix the filter first — only then set enabled = true.

Open the full version (with copy buttons) ↗

← All recipes