[BR]: fail2ban does not start on some debian/ubuntu systems - backend should probably be set to systemd on all systemd-based distros

[tobixen]

Environment:

• Fail2Ban master branch, as well as version 0.11.1 on Ubuntu Focal and many others
• OS, including release name/version : Ubuntu Focal. Allegedly, Ubuntu Xenial is also affected, as well as some Debian installations.
• Fail2Ban installed via OS/distribution mechanisms
• You have not applied any additional foreign patches to the codebase
• Some customizations were done to the configuration (provide details below is so)

The issue:

On modern systemd-based distros, like newer releases of Ubuntu, Debian, Archlinux, RHEL, Fedora, etc, services like sshd logs to the systemd journal. Optionally rsyslog or syslog can be installed and run, and logs will also be available i.e. in /var/log/auth.log or /var/log/secure.log.

In the files /etc/fail2ban/paths-{arch|fedora|opensuse} there is a section like this:

syslog_backend = systemd
sshd_backend = systemd
dropbear_backend = systemd
proftpd_backend = systemd
pureftpd_backend = systemd
wuftpd_backend = systemd
postfix_backend = systemd
dovecot_backend = systemd

... and because of this, fail2ban works on arch, fedora (with derivatives) and opensuse. However, it fails on debian and ubuntu, unless the syslog package is installed and the service is running. Apparently this was reported as early as 2014 at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770171 and it's also reported for Ubuntu 16.04 at https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/1696591 ... we're running Ubuntu and EL. On our baseimages with Ubuntu 16.04, fail2ban installs and runs because we have syslog running there, on Ubuntu 20.04 we've had to hand-tune configuration to get fail2ban run on the services above. On EL it also works due to the paths-fedora.conf-file.

Steps to reproduce

• Install Ubuntu 20.04
• Observe that the OS installation comes without any rsyslog/syslog package installed (I suppose YMMV, dependent on how it's installed)
• Install fail2ban (sudo apt-get install fail2ban)
• Enable the sshd jail: echo -e "[sshd]\nenabled=true" | sudo tee /etc/fail2ban/jail.local
• Start up fail2ban: sudo systemctl start fail2ban
• Observe that it's not running: sudo systemctl status fail2ban - the error message looks like ERROR Failed during configuration: Have not found any log file for sshd jail.

Suggestion

I suggest creating a /etc/fail2ban/paths-systemd containing only the lines *_backend = systemd, and make sure it's run from any operating system having systemd installed.

Configuration, dump and another helpful excerpts

Any customizations done to /etc/fail2ban/ configuration

$ sudo cat /etc/fail2ban/jail.local 
[sshd]
enabled=true

[sebres]

It looks to me like a pretty maintainer issue. @fail2ban/maintainers, @sylvestre Any idea?

From other point of view it is a configuration issue and can be surely simply fixed using:

- echo -e "[sshd]\nenabled=true" | sudo tee /etc/fail2ban/jail.local
+ echo -e "[sshd]\nbackend=systemd\nenabled=true" | sudo tee /etc/fail2ban/jail.local

With other words:

  $ sudo cat /etc/fail2ban/jail.local 
  [sshd]
+ backend=systemd
  enabled = true

Pretty simply, isn't?

... and because of this, fail2ban works on arch, fedora (with derivatives) and opensuse

Well, it may work for sshd jail but could fail for some other jail if it gets enabled, but much more important is vice versa situation...

I suggest creating a /etc/fail2ban/paths-systemd containing only the lines *_backend = systemd, and make sure it's run from any operating system having systemd installed.

... that the issue with such a configuration would be - the system having systemd installed doesn't guarantee that every service affected by that include for which the jail would use systemd backend by default will also log into systemd journal.
Moreover it may be dangerous to do that by default, because:

1. if the log file is missing you'd be notified by fail2ban about and so can fix it (e. g. by changing the backend)
2. but if the backend is configured to systemd incorrectly for some jail, fail2ban is unable to detect whether the service logging there or not, so the jail would just not find any message from the service, simply because it will be not written to the journal (ability to read from journal doesn't imply that something, fail2ban is waiting for, writes to the journal at all). With other words if fail2ban starts without errors it would not necessarily mean that it "works" in that case.

The former is unpleasant but safe against possible misconfiguration, whereas the later is pretty ugly and hardly noticeable.

However I'm not against the suggestion to make /etc/fail2ban/paths-systemd as a part of fail2ban.

[tobixen]

It looks to me like a pretty maintainer issue. @fail2ban/maintainers, @sylvestre Any idea?

I thought so at first ... but since the path-*.conf is part of the fail2ban git repository, I feel it should be handled here.

As mentioned, this has also been flagged as a debian bug since 2014 ...

With other words:

  $ sudo cat /etc/fail2ban/jail.local 
  [sshd]
+ backend=systemd
  enabled = true

Pretty simply, isn't?

Well, for you and me ... sure, trivial ... but for anyone setting up fail2ban without any knowledge of the package, and just following the instructions (at least as they are at the top of jail.conf), I think it's a bad user experience when it doesn't work. Actually, it did take me quite some time digging to figure out that the trick is backend=systemd.

... that the issue with such a configuration would be - the system having systemd installed doesn't guarantee that every service affected by that include for which the jail would use systemd backend by default will also log into systemd journal. Moreover it may be dangerous to do that by default, because:

1. if the log file is missing you'd be notified by fail2ban about and so can fix it (e. g. by changing the backend)
2. but if the backend is configured to systemd incorrectly for some jail, fail2ban is unable to detect whether the service logging there or not, so the jail would just not find any message from the service, simply because it will be not written to the journal (ability to read from journal doesn't imply that something, fail2ban is waiting for, writes to the journal at all). With other words if fail2ban starts without errors it would not necessarily mean that it "works" in that case.

You may have a point, I'm just not sure if it is significant. I strongly believe that:

• For all combinations of OS distributions coming with systemd and not being EOL'ed a very long time ago and services on the list (sshd, dropbear, proftpd, pureftpd, wuftpd, postfix, dovecot), one can reliably find the logging in the journal, unless one has deliberately installed and configured things in a "weird" manner.
• One cannot trust fail2ban to work as intended without doing a minimum of testing.
• The risk that people will not use fail2ban because it's too difficult to set up is greater than the risk of fail2ban silently failing because the failed login information was only found in some logfile while fail2ban expected it to be in the journal.
• There is also a risk that the log files fail2ban is searching for exists, but that the information is only written to the journal
• There will always be people that are aiming to shoot themselves in the foot, and pulling the trigger, it's pointless to try to think of all the ways it can be done. My colleague was setting up fail2ban on Ubuntu the other day, did not verify that it was working as it should - but he also did not verify that the service was running. In that case, it would definitively have been better that fail2ban would have been just working "out of the box".

I've been looking a bit around... unfortunately I have no Debian to test with, but I have plenty of Ubuntu flavors, plus some CentOS and RHEL.

• I have an EL7-box with HAProxy running, it logs to syslog but not to journal - meaning that your scenario is possible. Then again, haproxy is not on the list. In the default configuration included in fail2ban the log path is hardcoded to /var/log/haproxy.log with no backend given.
• Ubuntu Precise does not have systemd installed, and it's also very EOL, so it can be ignored.
• Ubuntu Trusty does not come with systemd, but it seems possible to install it. I didn't test. I probably should have tested. Trusty is EOL, but it's possible to buy "extended support" until April 2024.
• Ubuntu Xenial comes with systemd installed. postfix and ssh logs to journal. I have rsyslog installed as well, it ensures the logs ends up in the files that fail2ban expects - but only as long as rsyslog is running! If the rsyslog service is stopped, logging to the files will stop, but logging to the journal will continue.

I could certainly do more testing, like checking every service on the list (sshd, dropbear, proftpd, pureftpd, wuftpd, postfix, dovecot ... syslog is also on the list, perhaps that one should be taken out). Of course it could be all down to "confirmation bias", but what I've seen just makes me stronger in my belief that systemd is the more correct backend for all those services for all systems running systemd :-)

[artfulrobot]

I just came across this today on a fresh Debian 12 install.

It seems a (packaging) bug to me that installing the fail2ban package results in a crashed service. It's taken a bit of searching to get here, and I still haven't got fail2ban running.

I have installed in the usual way:

apt install fail2ban

Then I created /etc/fail2ban/jail.local

[DEFAULT]
# Debian 12 has no log files, just journalctl
backend = systemd

# "bantime" is the number of seconds that a host is banned.
bantime  = 1d
# "maxretry" is the number of failures before a host get banned.
maxretry = 5
# A host is banned if it has generated "maxretry" during the last "findtime"
findtime  = 1h

[sshd]
enabled = true

And then tried to start the service again, but it crashes.

× fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2023-08-15 13:07:06 BST; 4s ago
   Duration: 807ms
       Docs: man:fail2ban(1)
    Process: 32501 ExecStart=/usr/bin/fail2ban-server -xf start (code=exited, status=255/EXCEPTION)
   Main PID: 32501 (code=exited, status=255/EXCEPTION)
        CPU: 516ms

Aug 15 13:07:05 ar11 systemd[1]: Started fail2ban.service - Fail2Ban Service.
Aug 15 13:07:06 ar11 fail2ban-server[32501]: 2023-08-15 13:07:06,056 fail2ban.configreader   [32501]: WARNING 'allowipv6' not defined in 'Definition'. Using default one: 'auto'
Aug 15 13:07:06 ar11 fail2ban-server[32501]: Server ready
Aug 15 13:07:06 ar11 systemd[1]: fail2ban.service: Main process exited, code=exited, status=255/EXCEPTION
Aug 15 13:07:06 ar11 systemd[1]: fail2ban.service: Failed with result 'exit-code'.

I note that there's /var/log/fail2ban.log which contains:

2023-08-15 13:07:06,212 fail2ban.server         [32501]: INFO    Starting Fail2ban v1.0.2
2023-08-15 13:07:06,213 fail2ban.observer       [32501]: INFO    Observer start...
2023-08-15 13:07:06,219 fail2ban.database       [32501]: INFO    Connected to fail2ban persistent database '/var/lib/fail2ban/fail2ban.sqlite3'
2023-08-15 13:07:06,219 fail2ban.jail           [32501]: INFO    Creating new jail 'sshd'
2023-08-15 13:07:06,424 fail2ban.jail           [32501]: ERROR   Backend 'systemd' failed to initialize due to No module named 'systemd'
... absolutely HUGE stack trace here ...
2023-08-15 13:07:06,428 fail2ban                [32501]: ERROR   NOK: ("Failed to initialize any backend for Jail 'sshd'",)
2023-08-15 13:07:06,429 fail2ban.server         [32501]: INFO    Shutdown in progress...
2023-08-15 13:07:06,429 fail2ban.observer       [32501]: INFO    Observer stop ... try to end queue 5 seconds
2023-08-15 13:07:06,450 fail2ban.observer       [32501]: INFO    Observer stopped, 0 events remaining.
2023-08-15 13:07:06,490 fail2ban.server         [32501]: INFO    Stopping all jails
2023-08-15 13:07:06,490 fail2ban.database       [32501]: INFO    Connection to database closed.
2023-08-15 13:07:06,691 fail2ban.server         [32501]: INFO    Exiting Fail2ban

Finally I realised I also needed to install python3-systemd package. And now it appears to be running.

TL;DR: to install on debian 12:

• apt install python3-systemd
• include backend=systemd in the jail.local as above
• and since Debian 12 is well and truly systemd (by default) now: it should have fail2ban log to systemd journal instead of the logfile. (logtarget = SYSTEMD-JOURNAL) in the [DEFAULT] section.

[sebres]

Because we get so many requests related to this issue...

@fail2ban/maintainers, @sylvestre would it make sense to add:

sshd_backend = systemd

to https://github.com/fail2ban/fail2ban/blob/master/config/paths-debian.conf
(and probably few other *_backend used in jail.local, quasi to fulfill #1225 for current debian)

Or would you rather want to add it to debian repository?

From other side, I remember an idea, how we probably can "fix" this and similar issues once and for all - if one would extend backend = auto with the logic: when there is no matches for logpath, and systemd journal is there - switch to systemd backend instead of error. Just I don't know right now how we can avoid a timing issue (for instance if fail2ban starts before some service and this service didn't create a log-file yet, so such a switch to journal monitoring would be wrong.
I must think a bit about that.

[anthonyborriello]

On Debian 12 and Raspberry OS 12
I managed to make fail2ban work writing
backend = systemd in jail.conf
and installing ip6tables to make the sshd work
Anyway log files are not saved!
Every time i reboot the system, the sshd stats return to zero..
Is there a way to make it work?

[sebres]

I managed to make fail2ban work writing backend = systemd in jail.conf

Well, basically it must be jail.local what you should change (see wiki :: Proper fail2ban configuration), not the jail.conf. But OK.

and installing ip6tables to make the sshd work

This is only expecting if IPv6 address need to be banned too and that over some of iptables actions (otherwise one needs nftables instead).

Anyway log files are not saved!

What do you means with that? Neither I understand which logs that are, nor where they need to be saved, nor what does it have to do with fail2ban.

Every time i reboot the system, the sshd stats return to zero..

Do you mean fail2ban stats? Then it is normal, see #2123 (comment)
However this has nothing to do with the tickets fail2ban stores in sqlite database, which will be restored after restart... Although active tickets only, so which end_of_ban (= start_of_ban + bantime) > now.
If it is not happening for you, may be the path to database in your configs points to non-persistent storage (e. g. some in-memory drive?):

fail2ban/config/fail2ban.conf

Line 70 in c6244a8

dbfile = /var/lib/fail2ban/fail2ban.sqlite3

Is there a way to make it work?

Firstly we need to understand what exactly do you want to "repair"?

[anthonyborriello]

I managed to make fail2ban work writing backend = systemd in jail.conf

Well, basically it must be jail.local what you should change (see wiki :: Proper fail2ban configuration), not the jail.conf. But OK.

and installing ip6tables to make the sshd work

This is only expecting if IPv6 address need to be banned too and that over some of iptables actions (otherwise one needs nftables instead).

Anyway log files are not saved!

What do you means with that? Neither I understand which logs that are, nor where they need to be saved, nor what does it have to do with fail2ban.

Every time i reboot the system, the sshd stats return to zero..

Do you mean fail2ban stats? Then it is normal, see #2123 (comment) However this has nothing to do with the tickets fail2ban stores in sqlite database, which will be restored after restart... Although active tickets only, so which end_of_ban (= start_of_ban + bantime) > now. If it is not happening for you, may be the path to database in your configs points to non-persistent storage (e. g. some in-memory drive?):

fail2ban/config/fail2ban.conf

Line 70 in c6244a8

dbfile = /var/lib/fail2ban/fail2ban.sqlite3

Is there a way to make it work?

Firstly we need to understand what exactly do you want to "repair"?

I'm sorry, the file is jail.local :)
For Raspbrry Pi OS based on Debian 12:
This is how i managed to solve the issue:

backend = systemd

Also

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

[SSHD]
Didn't modify anything

Without specifying nftables,, sshd doesn't block the IP address even if it's in the banned list.

Also, this is how I'm tracking the sshd ban status in real time:
sudo tail -f /var/log/fail2ban.log (this log file is still available in systemd).

Also, you can monitor sshd with the new Journalctl:
journalctl -f

Hope this helps. I really liked the out-of-the-box functionality in Debian 11. Fail2ban is great software!

[7wells]

Because we get so many requests related to this issue...

@fail2ban/maintainers, @sylvestre would it make sense to add:

sshd_backend = systemd

to https://github.com/fail2ban/fail2ban/blob/master/config/paths-debian.conf (and probably few other *_backend used in jail.local, quasi to fulfill #1225 for current debian)

Or would you rather want to add it to debian repository?

From other side, I remember an idea, how we probably can "fix" this and similar issues once and for all - if one would extend backend = auto with the logic: when there is no matches for logpath, and systemd journal is there - switch to systemd backend instead of error. Just I don't know right now how we can avoid a timing issue (for instance if fail2ban starts before some service and this service didn't create a log-file yet, so such a switch to journal monitoring would be wrong. I must think a bit about that.

I just ran into the same problem with Debian 12 and was glad to see the solution (or workaround?) mentioned here. All I had to do was changing backend = auto to backend = systemd in /etc/fail2ban/jail.local.

Maybe some further explanation for non-experts in the following guidance text of jail.conf could be helpful?

# "backend" specifies the backend used to get files modification.
# Available options are "pyinotify", "gamin", "polling", "systemd" and "auto".
# This option can be overridden in each jail as well.
#
# pyinotify: requires pyinotify (a file alteration monitor) to be installed.
#              If pyinotify is not installed, Fail2ban will use auto.
# gamin:     requires Gamin (a file alteration monitor) to be installed.
#              If Gamin is not installed, Fail2ban will use auto.
# polling:   uses a polling algorithm which does not require external libraries.
# systemd:   uses systemd python library to access the systemd journal.
#              Specifying "logpath" is not valid for this backend.
#              See "journalmatch" in the jails associated filter config
# auto:      will try to use the following backends, in order:
#              pyinotify, gamin, polling.
#
# Note: if systemd backend is chosen as the default but you enable a jail
#       for which logs are present only in its own log files, specify some other
#       backend for that jail (e.g. polling) and provide empty value for
#       journalmatch. See https://github.com/fail2ban/fail2ban/issues/959#issuecomment-74901200

Especially the final "Note" needs further attention, I guess, but I am a noob to provide more ideas about this, I'm afraid. I rather came here after searching for a solution. So the most I can provide here is this: Thanks a lot, guys, for all your time and work you spend on this! ❤️

[sylvestre]

Folks, don't hesitate to contribute to https://salsa.debian.org/python-team/packages/fail2ban/ if you feel that things could be improved in the package :)

[sebres]

Especially the final "Note" needs further attention

This note means that if someone overwrites backend in default section, it would obviously affect all jails for which the backend parameter is not set (thus uses default value).
In #3292 (comment) I proposed to set it for sshd-jail only.

[anthonyborriello]

Did not work for me. Debian bookworm on arm64 with ufw and ssh on custom port (example: 1234). My relevant sections in jail.conf:

[INCLUDES]

before = paths-debian.conf

[DEFAULT]

backend = auto

[sshd]

enabled = true
mode   = normal
port    = 1234
bantime.overalljails = false
logpath = %(sshd_log)s
backend = %(sshd_backend)s

With this config fail2ban doesn't start (ERROR: Failed during configuration: Have not found any log file for sshd jail). What partially worked:

• create an empty file /var/log/auth/log; or
• change to backend = systemd in the [DEFAULT] section, not in [sshd] (interestingly, the override does not seem to have effect in this section).

In both cases, fail2ban starts but does not work, in the sense that it fails to ban an ip after too many failed attempts.

The content of paths-debian.conf is pretty standard, I can include if it helps but I checked and it's 100 percent the same as in another debian bookworm machine with almost identical configuration (where I do not have this issue).

Any help? Thanks!

Ciao Tommaso.
This is what i did on my raspberry.

Create a jail.local copying the file in /etc/fail2ban/jail.conf

backend = systemd

Also

[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports

[SSHD]
#To use more aggressive sshd modes set filter parameter "mode" in jail.local:
#normal (default), ddos, extra or aggressive (combines all).
#See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode = normal
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

SSHD is set on default, i only changed backend=systemd and nftables.
Debian12 now uses nftables and not iptables!

[tomgagdotnet]

Ciao Tommaso. This is what i did on my raspberry.

You've been too fast :D I posted by accident, I actually solved the issue, the problem was with ufw (I do not use nftables). Thanks anyway!

[WhiteTiger-IT]

You've been too fast :D I posted by accident, I actually solved the issue, the problem was with ufw (I do not use nftables).

Hi, what problem was ufw creating?
How did you solve it?

[tomgagdotnet]

Hi, what problem was ufw creating? How did you solve it?

It was a botched configuration option that I did for testing but I forgot to remove in ufw, nothing related to fail2ban

[lukasza67]

Hello,

The Debian 12 original packages are still misconfigurated out of the box? In this case is there a clear reference jail.conf that actually works?

[sebres]

is there a clear reference jail.conf that actually works?

See the first answer in this topic - #3292 (comment)

[sebres]

I have set the backend to systemd in my jail.d/sshd.conf but fail2ban still fails on:
Failed during configuration: Have not found any log file for sshd jail

It is simply not possible... Also source code show that related to

fail2ban/fail2ban/client/jailreader.py

Line 262 in b59fd2e

if backend.startswith("systemd"): continue

it'd never reach line

fail2ban/fail2ban/client/jailreader.py

Line 276 in b59fd2e

msg = "Have not found any log file for %s jail" % self.__name

[sebres]

@germebl, your jail is calling ssh (without d), so you trying to rewrite and enable non existing jail... Just rename it to sshd:

- [ssh]
+ [sshd]
  backend = systemd
  ...

[germebl]

correct, you where faster in responding than me in deleting my post. ^^ Got it a second later. Sry for the inconvenience.

[sebres]

我遇到到了这个问题，花费两个小时才发现是backend=systemd的问题

人们，让我们知道您需要多少时间泡茶、遛狗等...
(People, let us know how many time you needed to make tea, walk with the dog, etc...)

The facts are:

• this is a developer repository with stock (mostly platform independent) fail2ban version, and must not be equivalent
  with your distribution and maintained version, its filters, jails or default configurations may be (and probably are) different
  and not optimal for some distros or their versions (or even completely unusable in default stock variant);
• by no stretch of the imagination can we provide a solution for every jail, matching every distro and every version of every software across the world.
• if we'll release something here - it could reach your distribution many months or even years later (also if it may become no more relevant), the maintainers for your distribution are probably faster (and know probably better which configs may be changed).
• fail2ban is just a tool (not a magic box) and as every tool needs to be configured properly (even if some pre-configuration are already made).
• the answer can be found in few seconds using man jail.conf.5 or other documentations, GH-wiki, stack-overflow or even google search.
• your time is not more precious than our and we don't owe something for nobody.
• fail2ban is completely for free and we also help people of no earthly use
• also you can help others if you'd contribute to the maintained version as suggested by Sylvestre in this comment.

I'll remove all similar comments now and in the future.

[sebres]

@sapphirecat
I changed your example above - moved backend = systemd to sshd section, because having it by default (in DEFAULT section) would affect any jails where backend is not set, so could unexpectedly switch monitoring for that jails from file to systemd journal.
One would only do that if most of the jails switching to systemd.

Moreover, I don't understand how it'd work, because our stock jail.conf overwrites default backend for sshd-jail with substitution sshd_backend from distribution related include (e. g. paths-debian.conf), see:

fail2ban/config/jail.conf

Lines 274 to 282 in 7b528a6

	[sshd]
	# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
	# normal (default), ddos, extra or aggressive (combines all).
	# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
	#mode = normal
	port = ssh
	logpath = %(sshd_log)s
	backend = %(sshd_backend)s

So normally it doesn't matter what you'd set in default section, because it is overwritten in jail.

[sebres]

In the newest release of 1.1.0-1~upstream1 deb-package here I made sshd by default systemd backend (in oppossite to original deb-package in paths-debian.conf as sshd_backend = systemd)...
See 85a4881

I tend to cherry-pick this into master branch (which also doesn't have any jail.d defaults).

No idea whether the maintainers of debian would take it on in his repo.
But after all, if jail sshd need to be enabled by default (stock fail2band doesn't do that), the file debian/debian-files/jail.d_defaults-debian.conf must only contain a [sshd] section with enabled = true, nothing else.

[sylvestre]

But after all, if jail sshd need to be enabled by default (stock fail2band doesn't do that), the file debian/debian-files/jail.d_defaults-debian.conf must only contain a [sshd] section with enabled = true, nothing else.

Thanks. I followed your advice :)

[perlun]

Like many others, I came here because I installed fail2ban on my newly setup Debian bookworm server only to see it failing to start. Thanks to everyone who has provided valuable feedback in this discussion, as well as those who have worked on fixing the issue. 🙏

So the short story, as far as the current versions of the Debian packages are concerned:

• 1.0.2-2 (the current version in bookworm) has the problem (broken configuration in Debian package)
• 1.1.0-4 (current version in trixie i.e. testing and sid (unstable) has the fix. ❤️
• 1.1.0-3 is the specific first "fixed" version in the Debian repositories. I'll post the changelog entry here now as well as the link to the Debian BTS entry for this bug

/usr/share/doc/fail2ban/changelog.Debian.gz entry:

fail2ban (1.1.0-3) unstable; urgency=medium

  * Restore the use of nftables and, for some jails,
    the systemd backend.
    Many thanks to Vincent Lefevre
    (Closes: #1070677)

 -- Sylvestre Ledru <[email protected]>  Sat, 25 May 2024 08:34:39 +0200

More Debian-related details and context

• #1070677: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070677