4

I am using fail2ban/firewalld to restrict bot-like access to a Nginx server. Typically, the configuration of the corresponding jail looks like:

[nginx-botsearch]
#banaction = iptables-multiport
enabled = true
filter = nginx-botsearch
logpath = /var/log/nginx*/*access*.log
maxretry = 3
bantime = 3600

This works as expected (the banaction defaults to firewallcmd-ipset), i.e., the iptables -L command shows an entry in the INPUT_direct chain:

REJECT     tcp  --  anywhere             anywhere             multiport dports http,https match-set fail2ban-nginx-botsearch src reject-with icmp-port-unreachable

with the corresponding ipset of fail2ban-nginx-botsearch.

However, I noticed a strange behavior when the bantime is increased. Everything works as expected for bantime <= 4294967. When I set bantime = 4294968 and reload fail2ban service, the entry in the iptables output is missing (the ipset is not created) and indeed, testing with, e.g., the ab utility shows that the ban is not enforced. Interestingly, using banaction = iptables-multiport works even for "large" bantimes. What might be the reason for this behavior? I am using fail2ban v 0.9.7 on CentOS 7.

ewcz
  • 143
  • 6

1 Answers1

3

This isn't strictly a fail2ban related issue, bit rather a bug in netfilter code on your kernel. In short, your version of ipset has an integer overflow for timeout parameter, so you see an unpredictable behavior when it exceeds 32bit integer.

You don't see this with multiport as it does not use this code and instead relies on its own devices to track timeouts.

Here's a link to the patch for this issue in netfilter code.

Peter Zhabin
  • 2,276
  • 8
  • 10