[FR]: Suggestion for a recidive FOUND filter (Double Tap)

[SDuesterhaupt]

By default, the Jail threshold is 5 events in 10 minutes. A further reduction of the trigger rate (matches per time) makes no sense. The usability suffers.

Since quite some time I regularly notice double tap events in my logs. These double-tap events occur every few minutes and are caused by several IPs that are probably part of botnets. Thus, these events are below the radar. Many pennies make a dollar. At least the server signals: I’m watching you.

The recidive-filter searches the fail2ban.log for BAN events.

Below is a filter suggestion for the interested community that looks for FOUND events instead:

/etc/fail2ban/filter.d/recidive-found.local

# Fail2Ban filter for repeating FOUND events
#
# This filter monitors the fail2ban log file, and enables you to add long
# time bans for ip addresses that get found by fail2ban multiple times.
#
# Reasons to use this: block very persistent attackers for a longer time,
# stop receiving email notifications about the same attacker over and
# over again.
#
# This jail is only useful if you set the 'findtime' and 'bantime' parameters
# in jail.conf to a higher value than the other jails. Also, this jail has its
# drawbacks, namely in that it works only with iptables, or if you use a
# different blocking mechanism for this jail versus others (e.g. hostsdeny
# for most jails, and shorewall for this one).

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = (?:fail2ban(?:-server|\.actions)\s*)

# The name of the jail that this filter is used for. In jail.conf, name the jail using
# this filter 'recidive', or supply another name with `filter = recidive[_jailname="jail"]`
_jailname = recidive-found

failregex = ^%(__prefix_line)s(?:\s*fail2ban\.filter\s*%(__pid_re)s?:\s+)?INFO\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Found\s+<HOST>.*$

datepattern = ^{DATE}

ignoreregex =

journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=5

# Author: Tom Hendrikx, modifications by Amir Caspi
# further modificated by: Stephan Düsterhaupt, Ivo Noack

The appropriate jail config:

/etc/fail2ban/jail.d/recidive-found.local

[recidive-found]
enabled = true
filter = recidive-found

bantime.increment = false
bantime.rndtime =
bantime.maxtime =
findtime = 1d  # 86400s
maxretry = 20
bantime = 90d  # adapt the dbpurgeage value in /etc/fail2ban/fail2ban.local

logpath = /var/log/fail2ban.log

#banaction = %(banaction_allports)s
blocktype = DROP
action    = %(action_)s[blocktype=%(blocktype)s]

With respect to the recidive-filter maybe there will be an option to log the filter queries to a 'queries.log' instead to the 'fail2ban.log' in order not to build loops during debugging.

Thank you. I appreciate your work. :)

Environment:

• Fail2Ban version : 1.0.1-2.el9
• OS, including release name/version : Rocky Linux 9.1 (Blue Onyx)

Service, project or product which log or journal should be monitored

• Name of filter or jail in Fail2Ban (if already exists) : recidive
• Service, project or product name, including release name/version : fail2ban

Log or journal information

• Log file name(s) : fail2ban.log

Any additional information

na

Relevant lines from monitored log files:

failures in sense of fail2ban filter (fail2ban must match):

2023-03-05 13:50:42,071 fail2ban.filter         [1330]: INFO    [sshd] Found xxx.xxx.xxx.xxx - 2023-03-05 13:50:41
2023-03-05 13:50:42,072 fail2ban.filter         [1330]: INFO    [sshd] Found xxx.xxx.xxx.xxx - 2023-03-05 13:50:41

[sebres]

Recidive filter is a rudiment (because of bantime.increment feature, since we have an observer module now that is able to react on findings and bans).
However recidive jails may be still interesting for someone, just I don't think we should further monitor fail2ban's own log for that purposes.
I'll try to provide fail2ban with recidive backend, monitoring internal found and ban events of fail2ban.

Regarding the suggested filter, it is few accurate (due to catch-all). Better replace (?:.*) with [^\]]*...
I know in recidive filter this catch-all is also there, just it is justified because the expression is anchored at end. You "removed" that anchor with .*$ - with this another catch-all a $ is not an anchor anymore and .*$ can be removed, but only if we don't have other catch-alls inside the RE.
Something like that would be better:

- failregex = ^%(__prefix_line)s(?:\s*fail2ban\.filter\s*%(__pid_re)s?:\s+)?INFO\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Found\s+<HOST>.*$
+ failregex = ^%(__prefix_line)s(?:\s*fail2ban\.filter\s*%(__pid_re)s?:\s+)?INFO\s+\[(?!%(_jailname)s\])[^\]]+\]\s+Found\s+<ADDR>

[SDuesterhaupt]

Thanks for your improvement tips.

I am not referring to the punishment of found IPs. I apply the bantime.increment feature by default.

It is about detecting IPs that mostly access a resource via double tap. Usually these are several IPs from one subnet, which indicates a botnet.

By default 5 accesses (maxretry) per 10 minutes (findtime) are the limit. If more than 5/10, then the jail takes effect.

However, these IPs access 1-4 times per 10 minutes. If now 1/10 (maxretry=1, findtime=10m) is set, the service (e.g. SSH) is no longer manageable. One wrong password (people make mistakes) and you lock yourself.

These suspicious IPs access several 10 times a day and so they move under the radar for weeks/months. There are even several 100s to 1000s events together.

From my point of view, the recidive approach is suitable to evaluate the 24h situation again, which the view of 10 minutes does not do without losing the usability of the service.

I got the tips. Thank you. :) This issue can be closed.