Understanding Discrepancies in 'Total Banned' Count Reported by Fail2Ban

[DevLiamJ]

Hello GitHub Community,

I am currently running Fail2Ban version 0.11.2 on my host machine to monitor and manage access to an Nginx service that is operating within a Docker container. The Nginx logs are bind-mounted from the container to a directory on the host machine, and Fail2Ban is configured to observe this bound directory for any malicious activity. In fail2ban.conf, dbfile option is enabled and dbpurgeage value is increased to 1296000 [seconnds] (15 days).

I'm seeking some insights into an issue I've encountered with Fail2Ban on my server. Specifically, I am seeing inconsistencies in the 'Total banned' count reported by Fail2Ban for my nginx-bad-request jail. Despite being aware of numerous IP addresses that should have triggered the fail conditions, the 'Total banned' metric is capped at 10.

When running the fail2ban-client status command for the nginx-bad-request jail, the output is as follows:

$ sudo fail2ban-client status nginx-bad-request
Status for the jail: nginx-bad-request
|- Filter
|  |- Currently failed:  0
|  |- Total failed:  1
|  `- File list:  /path/to/log/nginx/access.log
`- Actions
   |- Currently banned:  10
   |- Total banned:  10
   `- Banned IP list:  [Redacted IP List]

Based on my logs and monitoring, I am confident that the actual number of IPs that should be banned exceeds this figure. However, the reported 'Total banned' does not reflect this higher number, instead showing a limit of 10, which corresponds to the number of currently banned IPs. This is happening to other jails as well.

I'm curious to know if there is a configuration setting that I might be overlooking, or if there's a known limitation within Fail2Ban that could be causing this. Is there a way to ensure that the 'Total banned' count accurately reflects all IPs that have been banned over time, rather than just the current snapshot?

Thank you in advance for your assistance and any advice you can provide!

[sebres]

See #3413.
Shortly: fail2ban doesn't have persistent statistic - all that values are since last start of fail2ban.

[sebres]

Despite being aware of numerous IP addresses that should have triggered the fail conditions, the 'Total banned' metric is capped at 10.

After restart fail2ban will restore active bans - tickets with end of ban (start_of_ban + bantime) larger than now.
The failures are made in previous run of fail2ban and will be not counted.

[DevLiamJ]

[Update on Fail2Ban Inconsistencies with 'Total banned' Count]

After further investigation into the issue I previously reported about Fail2Ban's 'Total banned' count being capped at 10 for my nginx-bad-request jail, I have realized that the server block configurations for Nginx I put in a separate .conf file within /etc/nginx/conf.d/ had to do with it. This separation seemed to affect how remote IP addresses were logged, causing them to be replaced with the Nginx service's default gateway in access.log. As a result, Fail2Ban was not able to accurately track the number of IP addresses that should have been banned.

To address this, I moved the server blocks to the main nginx.conf file, situating them inside the http block. This change resulted in the remote IP addresses being correctly logged in access.log. Subsequently, Fail2Ban began to report an accurate 'Total banned' count, which surpassed the previous cap of 10 and continued to increase in response to failed jail rules.

This experience suggests that the placement of server block configurations within Nginx can impact the logging of IP addresses and the subsequent ban enforcement by Fail2Ban. If others are facing similar issues, I recommend reviewing the Nginx configuration files to ensure that server blocks are correctly located to facilitate proper logging for Fail2Ban and hence appropriate banning.