What fail2ban on your server doesn't see

On a typical Linux server fail2ban protects SSH, and that's it. The sshd jail is enabled by default in almost every distribution, while the web server, mail and FTP keep taking attacks with no protection at all. To see what slips through, you need to know where the logs live, which filters fit them, and run fail2ban-regex by hand. We did this on 13 production servers and counted what fail2ban misses in a single day.

Why fail2ban only sees what you show it

fail2ban doesn't look for attacks on its own. It reads exactly the logs listed in enabled jails and matches lines against the regular expressions in their filters. No jail for nginx means nobody reads the requests for /.env and /wp-login.php in its log. No jail for Exim means SMTP password guessing goes on for weeks.

Turning a jail on isn't as simple as it looks either:

• Logs can be anywhere. Control panels put each site's logs in their own folder, mail servers write to journald or /var/log/maillog, and every FTP server has its own idea.
• Few ready-made filters. fail2ban ships filters for password guessing, but not for backup hunters, vulnerability scanners or garbage requests.
• The fear of banning your own. A web filter written by eye easily catches monitoring, payment notifications or your own office.

What we checked

We took the latest KIPBan log analysis reports from 13 Linux servers as of 9 October 2026. They include WordPress, 1C-Bitrix and Django sites, mail servers, streaming and a CDN. About 1.47 million log lines in total, roughly one day of each server's life. On many of them fail2ban had been set up by an experienced administrator; these aren't bare servers.

Services found on the servers:

What the patterns found in one day

“Addresses” is summed across logs: an address that hit two sites is counted twice. “Not blocked” means addresses that reached the pattern's threshold but that the server doesn't block, neither with its own jail nor from the shared database. The 1C-Bitrix, nginx HTTP auth, Dovecot and FTP patterns found nothing that day.

What these numbers say

SSH is covered everywhere

SSH password guessing shows up on all 13 servers: almost 19 thousand attempts from 886 addresses in a day. All of them are blocked, because an SSH jail runs everywhere. This is the part fail2ban does well. Even here the stock sshd jail misses some scanners; see Why the stock sshd jail misses scanners.

The web is poorly covered

Even where fail2ban was set up with care, in a single day these went unblocked:

• 155 addresses sending garbage instead of HTTP: TLS on the HTTP port, SMB, RDP and SOCKS probes. What those log lines mean is covered in What \x16\x03 in access.log means;
• 81 WordPress and web shell scanners, including on sites that never ran WordPress;
• 76 vulnerability scanners: sqlmap, Nuclei, zgrab and the like;
• 67 hunters for .env, .git and database dumps.

Scanners almost always arrive from a separate address each time: 90 requests from 84 addresses. The classic “ban after five failures” approach doesn't work against them; each address makes one or two attempts and moves on. For such patterns one hit is enough: a request for /.git/config or sqlmap in the User-Agent is never an accident.

Mail is in between

Exim is attacked on all three mail servers: almost 5 thousand SMTP password guesses from 160 addresses. Nearly all are blocked, but 7 addresses got through: the jail exists, but it either doesn't watch every log or waits for more attempts than these addresses make.

Bots make the most “traffic”

SEO service bots and crawlers collecting data for AI training made about 23.5 thousand requests from a thousand addresses in a day. That isn't an attack, and whether to block them is the site owner's call. The pros and cons are in Should you block AI crawlers and SEO bots.

How to check your own server by hand

Without any service, use fail2ban-regex, which runs a log through a filter and blocks nothing:

# which jails are running now
fail2ban-client status

# how many nginx log lines the stock nginx-botsearch filter matches
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-botsearch.conf

# the same for Exim
fail2ban-regex /var/log/exim4/mainlog /etc/fail2ban/filter.d/exim.conf

The routine is: find every service listening on the outside (ss -tlnp), find its logs, pick a filter, test it with fail2ban-regex, check that your own addresses aren't among the matches, and only then enable the jail. On a server with a control panel and a dozen sites that's a few hours of work, and it has to be repeated whenever a new site appears.

How KIPBan does it

KIPBan log analysis does the same work automatically:

• Finds services and logs itself: from files held open by processes, nginx configuration, journald and the known paths of mail and FTP servers. Non-standard paths, control panels and multiple sites per server are supported.
• Checks 16 KIPBan patterns against the last 150 thousand lines of each log, about a day's worth, once a day at night at the lowest priority.
• Compares what it found with what the server already blocks and shows the result: “enabled”, “already blocked”, “not covered: 35 of 58” or “isolated”.
• Enables a jail with a button. A new jail first runs in watch mode and blocks nothing. More in Watch mode: how to enable a jail without banning your own.

The logs never leave the server: the dashboard receives only counters, without log lines or IP addresses. How that works is described in Log analysis without sending logs.

Limits: Linux only (agent 21.5 or newer), logs inside Docker containers aren't analysed, and you can't upload your own filters to the dashboard yet. Your own jails in jail.local are still connected to KIPBan by the agent automatically.

Questions