Fail2Ban perpetual recidive ban issues

Support
,
1

Good morning,

My fail2ban had something go odd with it recently with 1 IP going back and forth. I logged into my NS box and found this error in the logs. The IP kept getting banned on the postfix-ddos jail and would never transition into the recidive jail. I only have the only recent update I recall on this machine is an auto-update on the stable repository, let me know if there are better/more logs that could help track down the error.

    2020-09-04 07:34:31,634 fail2ban.jail           [75532]: INFO    Jail 'rspamd' started
    2020-09-04 07:34:32,211 fail2ban.utils          [75532]: ERROR   7fcf74164f90 -- exec: ipset add f2b-recidive 185.234.216.63 timeout -1 -exist
    2020-09-04 07:34:32,314 fail2ban.utils          [75532]: ERROR   7fcf74164f90 -- stderr: "ipset v7.1: Syntax error: '-1' is out of range 0-2147483"
    2020-09-04 07:34:32,324 fail2ban.utils          [75532]: ERROR   7fcf74164f90 -- returned 1
    2020-09-04 07:34:32,327 fail2ban.actions        [75532]: ERROR   Failed to execute ban jail 'recidive' action 'shorewall-ipset-proto6' info 'ActionInfo({'ip': '185.234.216.63', 'bantime': -1, 'fid': <function <lambda> at 0x7fcf75131cf8>, 'family': 'inet4', 'raw-ticket': <function <lambda> at 0x7fcf75132320>})': Error banning 185.234.216.63
2 Likes
2

what version of fail2ban do you have ?

rpm -qa | grep -i 'fail2ban'

3 
[root@ns1 ~]# rpm -qa *fail2ban*
fail2ban-firewalld-0.11.1-9.el7.2.noarch
fail2ban-shorewall-0.11.1-9.el7.2.noarch
fail2ban-server-0.11.1-9.el7.2.noarch
fail2ban-0.11.1-9.el7.2.noarch
fail2ban-sendmail-0.11.1-9.el7.2.noarch
nethserver-fail2ban-1.4.1-1.ns7.noarch
[root@ns1 ~]#
4

actually I have installed

nethserver-fail2ban noarch 1.4.2-1.ns7 nethserver-updates 1.1 M

but I do not remember what we fix with this version

EDIT : above not related to the issue

5

I try to reproduce

6

I have an update available in my software center, let me see if this resolves the issue :expressionless:

7

ok, sometimes a restart of failban (by an update) could solve

8

Updated to latest available software and then rebooted the machine. So far I have the IP sitting in a jail and now currently also viewable in the Unban section within Cockpit whereas before there was nothing listed. I’ll either mark as resolved if this fixes itself or povide an update once it throws an error again in the log file.

[root@ns1 ~]# rpm -qa *fail2ban*
fail2ban-firewalld-0.11.1-9.el7.2.noarch
fail2ban-shorewall-0.11.1-9.el7.2.noarch
fail2ban-server-0.11.1-9.el7.2.noarch
fail2ban-0.11.1-9.el7.2.noarch
nethserver-fail2ban-1.4.2-1.ns7.noarch
fail2ban-sendmail-0.11.1-9.el7.2.noarch
[root@ns1 ~]#
9

yes please but this kind of post are nice because it spot the light on new feature of fail2ban. I never liked the perpetual ban, however now we have bantime incremental with version 0.11

# incremental ban-time:
bantime.increment = true
# max ban-time 7 week:
bantime.maxtime = 7w
10

Fun we could have a short ban time for the first error, and really long ban time if you continue to do brute force

bantime = 1m
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 10w

maxretry = 3
findtime = 1d

really interesting feature for users that forget their password, the first time you wait 60 seconds, the second time 120s etc

2 Likes
11

Well you are right we have an issue with the perpetual ban with ipset and the version 0.11. Our fix doesn’t work anymore, but the official fix of fail2ban itself is broken also

12

We are going to drop perpetual recidive, instead we will use recidive with 2w maximum ban OR incremental banning with a multiplier

The goal is to set a tiny ban time for example 60 seconds, the first ban is 60 seconds, the second 120, then 240, 


For a sysadmin point of view it is better, if you user go to jail three times with recidive, then he needs to call for help to go out of jail, with incremental he is supposed to wait the end of ban.

We could have the same behavior by just disabling the recidive but clever bots could find the time of release and try a brute force.

4 Likes
13

Would threat shield mitigate a good majority of that bot threat vector if configured adequately? The input quality of the lists used I would suspect determines much many go undetected. I like the way Nextcloud handles it where the system automatically places a time buffer after multiple failed logins.

I like the suggestions above, when you get to a point for a beta tester is needed please let me know.

1 Like
14

Looks like you got it figured out but wanted to make sure. I maintain the Fedora EPEL version of fail2ban which it looks like you’re either using directly, or it’s worked its way into the Nethserver repository as I recently updated EL 7 from 0.10.x to 0.11.x.

Thanks,
Richard

2 Likes
15

thank for your work @hobbes1069 it our job to follow
continue the good job