2025-07-03 fail2ban some more

This is a continuation of 2025-06-16 Ban autonomous systems.

2025-06-16 Ban autonomous systems

I kept wondering why the "recidive" jail never found any repeated offenders from the "butlerian-jihad" jail. I think I know why, now. The "recidive" jail uses the following:

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

Far to the right, it uses `HOST` and that only matches a single IP number. If you examine the regular expression generated and scroll over far enough to the right, you'll see the named groups `` and ``.

# fail2ban-client get recidive failregex
The following regular expression are defined:
`- [0]: ^(?:\[\])?\s*(?:<[^.]+\.[^.]+>\s+)?(?:\S+\s+)?(?:kernel:\s?\[ *\d+\.\d+\]:?\s+)?(?:@vserver_\S+\s+)?(?:(?:(?:\[\d+\])?:\s+[\[\(]?(?:fail2ban(?:-server|\.actions)\s*)(?:\(\S+\))?[\]\)]?:?|[\[\(]?(?:fail2ban(?:-server|\.actions)\s*)(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)\s+)?(?:\[ID \d+ \S+\]\s+)?(?:\s*fail2ban\.actions\s*(?:\[\d+\])?:\s+)?NOTICE\s+\[(?!recidive\])(?:.*)\]\s+Ban\s+(?:\[?(?:(?:::f{4,6}:)?(?P<ip4>(?:\d{1,3}\.){3}\d{1,3})|(?P<ip6>(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):)))\]?|(?P<dns>[\w\-.^_]*\w))\s*$

I decided to create an additional jail.

In my own `/etc/fail2ban/jail.d/alex.conf` I added a second jail:

[butlerian-jihad]
enabled = true
bantime = 1h

[butlerian-jihad-week]
logpath = /var/log/fail2ban.log
enabled = true
findtime = 1d
bantime = 1w
maxretry = 5

The first one uses the filter `/etc/fail2ban/filter.d/butlerian-jihad.conf` which remains empty. Remember, entries are added to this jail via a cron job discussed in an earlier post.

earlier post

[Definition]

The second one uses a new filter `/etc/fail2ban/filter.d/butlerian-jihad-week.conf` defining the date pattern and the regular expression to detect "failures" (i.e. a hit).

[Init]
# 2025-06-29 01:17:08,887 fail2ban.actions [543]: NOTICE  [butlerian-jihad] Ban 1.12.0.0/14
datepattern = ^%%Y-%%m-%%d %%H:%%M:%%S

[Definition]
failregex = NOTICE\s+\[butlerian-jihad\] Ban <SUBNET>

The important part is that this uses `` instead of ``. If you scroll over to the right, you'll find a new `` group:

# fail2ban-client get butlerian-jihad-week failregex
The following regular expression are defined:
`- [0]: NOTICE\s+\[butlerian-jihad\] Ban \[?(?:(?:::f{4,6}:)?(?P<ip4>(?:\d{1,3}\.){3}\d{1,3})|(?P<ip6>(?:[0-9a-fA-F]{1,4}::?|::){1,7}(?:[0-9a-fA-F]{1,4}|(?<=:):)))(?:/(?P<cidr>\d+))?\]?

And it seems to be working.

The Munin graph shows how the butlerian-jihad-week jail immediately jumps to 3000 members

I had to restart this particular jail a few times. Using `--unban` makes sense because those deserving of a new ban will be discovered immediately as the `findtime` was set to one day up above.

fail2ban-client restart --unban butlerian-jihad-week

#Administration #Butlerian Jihad #fail2ban

**2025-07-05**. Two days later.

Link

**2025-07-06**. Hm. I made a change to Emacs Wiki search, hoping to get rid of the DuckDuckGo dependency:

I made the page title match much more prominent

I switched the search from GET to POST

I count the search via GET as a bot (since it's no longer doable via the user interface)

I reinstated the old full-text search (essentially a grep within Perl)

I was hoping that it would have very little effect. At about the same time, however, load started creeping up. The question is whether this is caused by so many search requests or not. There aren't many search requests in the logs, and the process monitors don't show unusually activity for the Emacs Wiki processes. Therefore, I think the answer is that the problem lies elsewhere. But where?

Somewhere around the 3rd of July load minimum seems to raise up from 0.5 to 1.0

This virtual server has two cores so load should remain below 2.0, ideally.

Somewhere around the 3rd of July the number of hosts banned for a week goes up from 2000 to more than 7000

Is it the processing of all the bans? I don't think so, since the firewall had many thousands of banned networks before.

Is it the extra cron jobs monitoring the logs? I don't think so because there's no 15min or 20min periodicity to see.

And note how load does come back down to 0.5 for a very short moment around midnight from the 4th to the 5th and in the early morning hours of the 6th.

How strange.

**2025-07-07**. Maybe just a fluke. I mean, if these defences actually worked the way I'd want them to, then an actual attack would feel like a fluke, right? 😄

The load graph shows that the current value is 0.5 although the average is still 1.6.

Also of note: The number of banned-for-a-week IP numbers and networks is up to 7900.

Source