Oh yes I did… Is the new update no longer allowed perpetual ?
I was getting so much spam from certain IPs… I normally set the recidive to perpetual in the older version… and manually flush the banned IPs when I see those SPAMMERS settled down… Thanks for the update… now I know
There are only 28 Banned Entries… that seems quite low… normally I used to get up to about 2,000 entries or so…before I flush the banned IPs.
Unfortunately I keep getting the same bad spam IPs all the time and I was able in the last version to enable RBL to block most of those spammers.
Here are the Infor from the recidive output.
Name: f2b-recidive
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 timeout 0
Size in memory: 2712
References: 1
Number of entries: 28
I never understood why sysadmin never trusted fail2ban, it bans all the time you need, three bans after and you go to recidive for 15 days…there is one guilty here… Me
We have changed the ban engine, we store the IP list to ipset, it is really fast but it is limited to 2^16 records per set. Before we used a list in a json file, it was long to read it and not efficient
So the recidive perpetual is still workable until you reach 65500 IP inside
Thanks… I tried to ipset destroy f2b-recidive
getting error: ipset v7.1: Set cannot be destroyed: it is in use by a kernel component
Also tried stopping the fail2ban module before running the ipset command; still getting the same error above.
Thanks… that seems to work…
Made the changed
Name: f2b-recidive
Type: hash:ip
Revision: 4
Header: family inet hashsize 32768 maxelem 80000 timeout 0
Size in memory: 120
References: 1
Number of entries: 0
Members:
Will monitor it for now… much appreciate the quick reply !
Have a good weekend.
Thank you…
Done it ! Appreciate the support …I think this will fix it !
Ideas for Future : Is it possible somehow, track those repeating IPs that keep offending into the recidive filter, such that the BanTime for those IPs will proportionally increased by users’ settings ?