Recidive Jail not Banning IP's in Fail2Ban

NethServer Version: 7.3.1611
Module: Fail2Ban recidive

The recent Update of the Fail2Ban seems to work pretty well for the postfix-ddos, http-access, & dovecot jails on unauthorized access or login.

However, when checking the fail2ban log, I find the recidive function is not quite working, it finds the repeating offending IP’s but not BANNING them.

Here’s what I see from the Status:

Checking with ‘fail2ban-client status recidive’

Status for the jail: recidive
|- Filter
| |- Currently failed: 29
| |- Total failed: 29
| - File list: /var/log/fail2ban.log /var/log/fail2ban.log-20170515 /var/log/fail2ban.log-20170501 /var/log/fail2ban.log-20170507- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:

This is the current setting in the jail.local config file

enabled = true
logpath = /var/log/fail2ban.log*
banaction = shorewall
bantime = 604800
findtime = 169200
maxretry = 6

Here’s the portion from the fail2ban log.

2017-05-15 04:58:57,826 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,846 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,884 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,913 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,921 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,926 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,935 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,941 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,949 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,960 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,978 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:57,996 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,008 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,067 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,086 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,098 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,106 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,116 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,128 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,147 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,150 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,157 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,161 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,173 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,180 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,187 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,201 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,210 fail2ban.filter [3680]: INFO [recidive] Found
2017-05-15 04:58:58,229 fail2ban.filter [3680]: INFO [recidive] Found

Seems to me that Shorewall is not BANNING the IP’s
Any idea what to check for ?.. Would be nice to get this fix too .

Recidive works when an ip is found in logs more than 6 times. It seems that your log never shows the same ip.

Try to ban your IP in the lan and do it several times with different jails

1 Like

Ok… I understand now why it seems not working…the recidive jail maxretry is set to 6 times, some of the typical re-occurrence jails like postfix, dovecot were set to maxretry = 3, and the recidive jail findtime is set to one day, the same IP occurred in previous day, will not get counted to exceed maxretry = 6 within 24 hours in most situation with current setting, even the recidive read the previous log files.

Will try and set the the findtime in jail.local for recidive to 259200 ( 3 days ) and see what happens

1 Like

I might suggest a tighter repeat offender sanction. e.g.

enabled = true
logpath = /var/log/fail2ban.log*
banaction = shorewall
bantime = 604800

#findtime shorter, more efficient
findtime = 86400

#repeat offender tolerance?
maxretry = 1

Remember, this is checking repeat offender via the fail2ban logfile itself, so there should be pretty much zero tolerance for repeatedly blown passwords (such as 12 missed passwords in a 24 hour period if your original policy allows 6 retries…).

At most set maxretry = 2, to allow for up to 18 mistaken passwords in 24 hours.

My infrastructure is under constant attack from bot servers which are automating a type of serialized brute force attack, typically their scripts auto-increment a password guess for root, but also attempt to crack other common usernames.

The offending servers are using additional probing techniques, port-scanning, etc. and if WordPress is on the site, standard port attacks attempting to crack admin privileges, or database privs using vulnerability exploits… at times 5 hits per minute 24/7 just trying to crack unix users, sometimes multiplied by efforts from from clearly 4 or 5 different IP addresses.

Some are apparently “better mousing” the system by limiting their attack to 3 password attempts instead of 5. This is presumably to defeat detection.

Without fail2ban, this boils down to not an insignificant waste of resources as just one bad server IP consumes 18,000 qualified responses in our auth log each day (5 hits per minute) , this also generates a lot of logfile data, up to 25Mb/month.

When multiplied by 4 or 5 server scripts this ends up being up about 150,000 hits per day and 180-250Mb/month in logfile data just from this one attack vector. We set fail2ban very tightly as suggested and it also has the effect of making it very unfortunate for sloppy employee logins.

The bottom line is that for our use-case, we achieved greater efficiency in the fail2ban system and our overall system resources saw improved availability after maintaining a clean separation of concerns using Recidive as suggested. #WorksForUs

1 Like

something similar already asked

Yes///This will be COOL !

released see the wiki page

1 Like

Ola todos

I checked the configuration, all is good on my side, but I found this

in short shorewall is still badly used in fail2ban…WIP

@danb35 could you please try to change the banaction to (in jail.local)

banaction = iptables-allports

then restart fail2ban

systemctl restart fail2ban

take notes that now shorewall won’t be aware about recidive banned ip, do iptables -L |less to see the banned IP

probably other commands can be used to show them

I’m going to be out of the country for the next few days–I’ll try this out when I get back.

1 Like

You know the way…no tests before to go on holidays

ok confirmed

what I plan is for now leave the shorewall banaction and go back to iptables. In fact the shorewall banaction feels not ended…It is not me who said this it is the fail2ban team :smiley:

following this thread, I would be interested by the input of @giacomo, maybe with some clues we could do a nice PR to fail2ban.

what is missing, it is some kind anchor like f2b-sshd and f2b-recidive in shorewall as you can find in iptable banaction

I pushed an update to leave shorewall and go to iptables, both for ns6 and ns7, please check that IP are banned for few days

check /var/log/fail2ban.log
check in the tab blacklist that IP listed in jail are banned in the bottom list

recidive should work
I added also a perpetual ban for recidive (not enabled by default)

I think we could use the blacklist feature of Shorewall but I need to do some tests before having a real solution.

What happen if Shorewall is restarted after fail2ban has put some IPs inside the black list?

1 Like

Possibly IP could still be banned

shorewall show dynamic

Changing the action jail could do some mess…probably I could be blamed a bit :blush:, back to shorewall

I’m thinking to keep shorewall action and to increment/decrement a counter when the IP is banned/unbanned, of course the allow action will be done only when the counter equal ‘0’.
A specific fail2ban esmith database is used to store the information.

So far it works on my servers, need to monitor it a bit

A post was split to a new topic: Fail2ban ignore whitelisting

please upgrade, now a new db is created

db fail2ban show

we increment a counter (with the date of the ban) for each time a jail bans, unban must be possible only if the counter equal zero (the last jail has released its IP)

1 Like