Am 10.04.2023 um 10:06 schrieb Endre Paller:
I didn't fully understand the role of error.log.1 in your answer,
could you please explain in more detail?
Hi,
sorry first. I'm native german, my english tongue is limited.
the difference is only small.
Usualy fail2ban use a findtime of 600s and triggers action if number of
maxretry times the regular expression was found.
I use in some cases a extended findtime of several hours. And extended
bantime (months) too.
ok, lets take a look what happens on logrotation.
first, there are 2 hits within a log, then logrotation happens. if the
third hit is part of the new log, nothing triggers.
there are some solutions for this:
first one is ignore it. The default findtime is only 10 minutes.
Probably attac continues and within these 10 minutes another [maxretry]
numbers of hits are found in the new log created during logrotation.
using a extended findtime, it could be nice to check the "old" log,
moved to by logrotate, too. can be configured by wildcards or given all
the names to fail2ban. In this case a logrotation doesn't break (
doesn't reset) the findtime.
HOWEVER, late versions of fail2ban, using a database [sqlite], remembers
on old hits by that database. So this isn't a big issue anymore, i think.
Simply, test this case (logrotation within findtime) to be sure or
decide to ignore it. Most bad guys kicked out in both cases.
regards
Peter
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
