Thanks for the info! Maybe a random of drop reject would be a good default.
Wayne Sallee [email protected] http://www.WayneSallee.com 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 http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject 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 difference.On 10 Aug 2018, at 21:05, Wayne Sallee<[email protected]> 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 [email protected] http://www.WayneSallee.com
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
