fail2ban log analyzer

Get a log to analyse#

Copy a chunk of the log from your server and paste it above, or save it to a file and open it. A few hours to a few days of log is plenty.

# SSH on systems with log files (Ubuntu 22.04, RHEL with rsyslog)
sudo tail -n 20000 /var/log/auth.log > ~/auth-sample.log     # Debian/Ubuntu
sudo tail -n 20000 /var/log/secure > ~/auth-sample.log       # RHEL/Rocky/Alma

# SSH on journal-only systems (Debian 12+, Ubuntu 24.04 with backend = systemd)
sudo journalctl -u ssh -u sshd --since "24 hours ago" -o short > ~/auth-sample.log

# nginx
sudo tail -n 50000 /var/log/nginx/access.log /var/log/nginx/error.log > ~/web-sample.log

journalctl -o short prints the classic syslog format (Oct 25 14:02:11 host sshd[1234]: …), which every fail2ban filter understands.

What the analyzer does#

1. Detects the log type by trying 40 of fail2ban's most common built-in filters (sshd, nginx, Apache, Postfix, Dovecot, FTP servers, Proxmox, Vaultwarden and more) on the first few thousand lines.
2. Runs the matching filters over every line exactly like fail2ban: it removes the timestamp, applies prefregex, failregex and ignoreregex, and extracts the address and user name. This is the same engine as the regex tester.
3. Simulates the jail. For each address it slides a findtime window over the failures and counts a ban whenever maxretry failures fall inside it — then starts counting again, as fail2ban does after a ban.

The result tells you which jails are worth enabling, how aggressive your maxretry and findtime need to be, and whether one address is responsible for most of the noise. Turn the findings into a config with the jail.local generator.

Reading the results#

• Failures found — lines that a filter treats as an authentication failure or attack. Successful logins are ignored.
• Would be banned — addresses that reach maxretry failures within findtime at least once. Change the two values in the toolbar to see the effect immediately.
• Usernames tried — from filters that capture <F-USER>. Names like root, admin, oracle and test are the classic signature of automated scans; your real user names appearing here is a reason to check where the attempts come from.
• Failures per hour — bursts often line up with a single botnet campaign.

If the analyzer finds nothing in a log you know is full of failures, the service probably logs in a format no built-in filter covers — build one with the filter generator.

FAQ#

How do I see failed SSH login attempts on Linux?#

Run sudo grep "Failed password" /var/log/auth.log (or /var/log/secure on RHEL), or on journal-only systems sudo journalctl -u ssh --since today | grep -i failed. Paste the output into the analyzer to group it by IP and see which addresses fail2ban would ban.

Which IPs would fail2ban ban from my log?#

The analyzer answers exactly that: it applies the built-in filters and simulates maxretry within findtime for each address. Set the two values to match your jail.local (the stock defaults are 5 and 10m).

Is it safe to paste my server logs here?#

Yes — nothing is uploaded. The page runs the filters in JavaScript on your computer. Logs can still contain usernames and internal addresses, so treat any copy you save or share with care.

Can it read compressed logs like auth.log.2.gz?#

Not directly. Decompress first with zcat /var/log/auth.log.2.gz > auth-old.log, then open or paste the text.