Fail2ban doesn't have neat functionality to automatically block attacks from a whole subnet. It is possible to do, though, using a recent version of fail2ban (I use v0.11), some simple fail2ban scripts and a small, pure python3 script.
Note: The question refers to 'a whole subnet' (which I'll refer to as CIDR blocks or IP ranges). This is a difficult thing, because we don't know how large a block of addresses the attacker controls. It might even be that the attacker by chance controls a handful of addresses from the same block, with the in-between addresses being legitimate.
Step 1. Get CIDR of hosts
The log files that fail2ban monitors typically show hosts (e.g. 127.0.0.1) instead of CIDR blocks (127.0.0.0/24) or IP ranges (127.0.0.0 - 127.0.0.255).
A solution could be to first assume a small CIDR block and then grow it as logs report more misbehaving hosts. Obviously it should only grow the CIDR, if those hosts are from adjacent addresses. But this is complex and legitimate addresses might get caught up regardless of the sophistication of the algorithm.
Instead, we can also simply lookup the CIDR in whois. This incurs some latency for the whois lookup, and generates some traffic. But the script that parses whois, can just write the CIDR to syslog, which can then be caught by fail2ban again.
Note: don't forget to hook this script into the actionban of your preferred action.d/lorem-ipsum.conf script. Be aware that if its maxretry > 1, then you will not catch CIDR blocks where hosts only fail once!
#!/usr/bin/python
import sys, subprocess, ipaddress, syslog
def narrowest_cidr(cidrA, cidrB):
_ip, subA = cidrA.split('/')
_ip, subB = cidrB.split('/')
if int(subA) > int(subB):
return cidrA
else:
return cidrB
bad_ip = sys.argv[1]
cidrs = []
inetnums = []
ret = None
whois = subprocess.run(['whois', bad_ip], text=True,
stdout=subprocess.PIPE, check=True)
for line in whois.stdout.split('\n'):
if 'CIDR:' in line:
cidrs.append(line.replace('CIDR:', '').strip())
if 'inetnum:' in line:
inetnums.append(line.replace('inetnum:', '').strip())
if len(cidrs) >= 1:
if len(cidrs) == 1:
cidr = cidrs[0]
else:
cidr = narrowest_cidr(cidrs[0], cidrs[-1])
elif len(inetnums) > 0:
if len(inetnums) == 1:
inetnum = inetnums[0]
startip, endip = inetnum.split(' - ')
cidrs = [ipaddr for ipaddr in ipaddress.summarize_address_range(ipaddress.IPv4Address(startip), ipaddress.IPv4Address(endip))]
if len(cidrs) == 1:
cidr = cidrs[0]
else:
cidr = narrowest_cidr(cidrs[0], cidrs[-1])
else:
cidr = "no CIDR found"
syslog.openlog(ident="suspectrange")
syslog.syslog("{} has CIDR {}".format(bad_ip, cidr))
Step 2. Figure out when to block a CIDR
If we had the dynamic CIDR determination this might get a little elaborate, as we'd have to change what we're banning. But with the whois lookup we can simply ban the CIDR block we found, based on a maxretry and findtime that we deem appropriate. Here's the jail I use:
[fail2ban-cidr-recidive]
filter = fail2ban-cidr-recidive
action = nftables-common[name=BADRANGE]
logpath = /var/log/everything/current
#5 bans in 12hrs is 48hr ban
maxretry = 5
findtime = 12h
bantime = 2d
And accompanying filter
[Definition]
failregex = \[suspectrange\] .* has CIDR <SUBNET>
Step 3. Actually block the CIDR
As you may have noticed, I use action.d/nft-common.conf. nftables allows blocking CIDR blocks instead of single hosts. This requires a small change to the first line of the actionstart part of the action script:
actionstart = nft add set netdev f2b <set_name> \{ type ipv4_addr\; \}
Should be modified to:
actionstart = nft add set netdev f2b <set_name> \{ type ipv4_addr\; flags interval\; \}
Here's how I did this..
I added this to jail.local:
[manban]
enabled = true
filter = manban
action = iptables[name=HTTP, port="80,443,110,995,25,465,143,585,993,587,21,22", protocol=tcp]
logpath = /var/log/manban.log
maxretry = 1
# 1 month
bantime = 2592000
findtime = 3600
Then I added the file /etc/fail2ban/filter.d/manban.conf:
[Definition]
failregex = ^\[\w{1,3}.\w{1,3}.\d{1,2}.\d{1,2}:\d{1,2}:\d{1,2} \d{1,4}. \[error] \[client.<HOST>].File does not exist:.{1,40}roundcube.{1,200}
ignoreregex =
I copied the filter protocol of another filter but point it to a file that doesn't exist, then I created a dummy file:
touch /var/log/manban.log
then run the command:
fail2ban-client reload
Now to manually ban an IP address for one month, type:
fail2ban-client set manban banip <IP>
This did the trick.
There are clients now that "learn" your fail2ban bantime, and will automatically adjust their system probes to not get banned. But when you look at the logs, it's obvious these are system probes. You can mess up their systems by creating extraordinary long ban times. You could also write a script that could dump IPs matching a certain criteria to your special ban log and have fail2ban ban them for an extended period of time.
Best Answer
First off. This is (perhaps) not an answer but perhaps better then a comment (and a bit long for it).
Time stamps
Find your statement:
conflicting with the documentation. What do you mean by work?
The manual#filters (v 0.8) states:
Note here that log files can be configured to include time stamps as well as the format of the time stamps. (That include dmesg as mentioned in comment.)
Also see this thread, Message #14 and #19 in particular:
Two examples:
Note that you can also test with commands like:
1 No time stamp:
2 With time stamp:
Scan times
Manual#Reaction time:
In that regard also see this thread: Re: Bug#481265: fail2ban: Poll interval is not configurable.
But under optional but recommended software one find Gamin.
If Gamin is installed and
backend
injail.conf
is set to auto (or gamin) - Gamin will be used.