Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic bantime #71

Closed
yajo opened this issue Aug 7, 2012 · 11 comments
Closed

Automatic bantime #71

yajo opened this issue Aug 7, 2012 · 11 comments

Comments

@yajo
Copy link

yajo commented Aug 7, 2012

IMHO Fail2ban should have an option to enable automatic bantime, which increases each time an IP gets blocked. Other ways, an attacker could get to guess how many tries he can do in a given time and exploit your services without reaching that limit.

See http://www.sshguard.net/docs/faqs/#why-addresses-released for more info.

@yarikoptic
Copy link
Member

indeed would be a good feature to have -- any takers? ;-)

@luckyredhot
Copy link

That'll be really nice feature!

@hamilton5
Copy link
Contributor

I like the idea of iptables recent module..

Have the bantime start when the packets stop.

@takeda
Copy link

takeda commented May 2, 2013

There is a filter called recidive. You simply set it to monitor fail2ban log and use it to set permanent bans for repeated offenders.

It's not exactly what you want but pretty much accomplishes the same goal and you can already use it without waiting for this functionality to be added to fail2ban.

@johnwbyrd
Copy link

Another vote for an option to increase ban time exponentially where the exponent is some factor >= 1.0. I suppose I could write this myself, if I understood your protocol for accepting patches.

@yarikoptic
Copy link
Member

well -- #716 is WIP for that.. but it is a bit "messy" since also has #824 in it... let me see if may be I would just finally merge 824 in ;)

@johnwbyrd
Copy link

Thanks, you just saved me a lot of duplication of effort. I'll be patient.

@yarikoptic
Copy link
Member

Well, I would encourage you @johnwbyrd to look through #716 and express your opinion even on specifications of the incremental bans... I still feel that that aiming at max flexibility they are a bit cumbersome but I could be convinced just to be biased ;)

@sebres
Copy link
Contributor

sebres commented Oct 23, 2014

but it is a bit "messy"

just a little bit :)
it Is my major branch, once not paying attention - and merged, but #824 concerns other files, therefore can be easy distinguished from ban-time-incr.

@sebres
Copy link
Contributor

sebres commented Nov 22, 2014

since #824 merged in master, #716 is "clean" again.

@sebres
Copy link
Contributor

sebres commented Mar 13, 2017

implemented in #1460

@sebres sebres closed this as completed Mar 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants