Using fail2ban over longer time spans? #2952
Replies: 2 comments 2 replies
-
Fail2ban uses real-time monitoring either (but you can indeed define
It depends on kind of activity you need to consider, fail2ban would count all matches (by regex) during
If it is simple threshold calculation (like fail2bans
Persistent banning is something ugly (just an unneeded last on net-subsystem etc), and is obsolete once fail2ban gets bantime increment feature in v.0.11... but if you want it nevertheless - set [jail]
# initial ban time:
bantime = 1h
# incremental banning:
bantime.increment = true
# default factor (causes increment - 1h -> 1d 2d 4d 8d 16d 32d ...):
bantime.factor = 24
# max banning time = 5 week:
bantime.maxtime = 5w This will firstly ban for 1 hour (this way not so aggressive by false positives for some legitimate users doing some mistakes, but it also allows to reduce initial
What exactly? |
Beta Was this translation helpful? Give feedback.
-
You can try it. The config for latest 0.11 will be something like this:
[DEFAULT]
dbmaxmatches = 0
dbpurgeage = 20d
[DEFAULT]
maxmatches = 0
[sptestlimit]
logpath = /var/log/kern.log
filter =
failregex = ^\s*\S+\s+kernel:(?: +\[[^\]]+\])? Speed-Test (?:\b(?:IN=\w+|OUT=|(?:(?!OUT=|IN=)[A-Z]+=[^ \[]*)+) )*SRC=<ADDR> DST=\S+
findtime = 2d
maxretry = 350
bantime = 1d
bantime.increment = true
bantime.factor = 7
bantime.maxtime = 5w
banaction = iptables-ipset-proto6-allports This configures a jail
If your line format for speed test attempt looks different, you must adjust As for possible benefits, there are indeed some probably:
|
Beta Was this translation helpful? Give feedback.
-
I am using some homegrown scripts that look through log files and update iptables rules. Here's my current process:
/var/log/kern.log.*
files for the last two daysI just realized that fail2ban uses a lot of the same machinery.
Is this something that fail2ban could accommodate? Or should I stick with my current scripts? Many thanks!
Beta Was this translation helpful? Give feedback.
All reactions