Thanks for the info!

Maybe a random of drop reject would be a good default.

Wayne Sallee

On 08/10/2018 04:56 PM, Philip James Clarke via Fail2ban-users wrote:
No fail2ban keeps a database as the logs change, located 
in/usr/lib/python3/dist-packages/fail2ban/server/__pycache__/ ), all my files 
in that folder total 220Kbytes it’s not a big load only storing which ip 
registered against with jail.

Historically after analysing my logs I found that one persistent brute force on 
my IMAP server was running for weeks (never banned) as it was set up to probe 4 
times every two hours. Increasing the findtime knocked that on the head.

There’s also a debatable point in changing the default bantime to shorter if 
using recidive.

But what I believe currently (in conjunction with recidive) is that a small ban 
time of 5 minutes on some services that are prone to long attacks, triggers 
fail2ban, quite often that’s enough to make the bot go away, but if not then it 
triggers recidive for 5 days inside of 15 minutes rather than waiting 6 hours 
(which I believe is the defaults). Some bots are just stupid, they keep on 
hammering away, ignoring all HTTP codes, that they are waiting around for a 
connection. That’s a problem for server load, with a multiple bot attack and 
you’re dropping or hanging connections on a web server, so want to knock the 
bots out of the way quickly and if they pop up again then wipe them out for a 
long time before they tie up 20 connections. Knocking them inside of 15 minutes 
is (in my view), better than waiting a longer time, if there’s a distributed 
command and control model and the attack is shared you get a higher percentage 
of the bot net faster.

I do wonder if “DROP” rather than “REJECT” is better, there’s an interesting 
discussion on

where the only advantage is possibly that DROP would perform better in a denial 
of service (in theory), in practice DOS’s are so large then in my opinion it 
offers little advantage. A “stupid botnet” is going to ignore REJECT, it may be 
slowed down by DROP as it waits for network response until it times out, but 
then it’s going to continue on probing which could exceed the findtime and 
bantime. My theory (totally up for debate) would be that it is more likely that 
an instant rejection is going to cause the “stupid botnet” to run through it’s 
cycle faster (even though it’s not going anyway near the services) by receiving 
a REJECT and then move on. If it’s a clever botnet it going to communicate to 
any other members of it’s network that it received multiple rejections and to 
pass on by without wasting the hackers report. Though these botnets are 
automated, the better ones are optimised to find easy targets rather than waste 
time after fail2ban has been triggered, and DROP or REJECT, they are going to 
have received one response so they know what software you are running roughly 
on which port, so if they are mapping for future exploits it makes no 

On 10 Aug 2018, at 21:05, Wayne Sallee<>  wrote:

Which brings me to another question:

Does longer find times (obviously it needs to be longer than what it is) make 
for more load on the server by causing Fail2Ban to load more data?

Wayne Sallee

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Fail2ban-users mailing list

Reply via email to