Dear Maintainer, when a system is configured to use the systemd journal as the sole logging system, i.e. when none of the packages provided by system-log-daemon are installed, the default sshd jail does not work. When logging in the system is done by using the systemd journal, the file /var/log/auth.log is not used anymore. While fail2ban 0.9 can use the systemd journal for matching offending log entries, the Debian package comes with a "backend = auto" statement that effectively disables matching against entries in the journal. As the log files in /var/log are not updated anymore, fail2ban becomes useless. In order to have the sshd jail to work correctly I had to: 1. install python3-systemd, which is right now only suggested by fail2ban, but given that systemd is going to be default in jessy it should probably become a Depends 2. activate the systemd backend by adding [DEFAULT] backend = systemd to the jail.d/defaults-debian.conf file 3. modify filter.d/sshd.conf to use the correct name of the sshd systemd unit in Debian, which is ssh.service and not sshd.service: [Init] journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd I did not find a way to perform 3 in a way that is robust against future upgrades of the fail2ban package... With the above mentioned modifications in place fail2ban correctly bans abusive hosts. I am not sure if syslog-ng or rsyslog are still going to be installed by default in jessy (probably yes?), but I would assume that a number of people would want to solely rely on the systemd journal, as otherwise logging gets duplicated and would be unhappy to discover that fail2ban has not been working for months (like it happened to me ;). I don't know if fail2ban should use the systemd backend by default, but the steps needed to make it work that way should be at least mentioned in NEWS.Debian or README.Debian *and* the sshd filter should use the correct name of the systemd unit [maybe all filters should be checked for wrong systemd unit names?]. As a side note, do you think that package systemd should Provide system-log-daemon? Is this worth filing a bug against systemd? Ciao, Tiziano
Hi, after upgrading my servers to jessie and journald, I’m also interested in having fail2ban working again. If this bug is fixed, I would greatly appreciate an upload to jessie-backports. Thanks, Joachim
Based on the fail2ban changelog, it looks like fail2ban added support for systemd in 0.9.0. The stretch repos include 0.9.2-1. source: https://github.com/fail2ban/fail2ban/blob/master/ChangeLog It seems a shame that the Debian base system moved to systemd but left fail2ban behind. Also a shame that the fail2ban.org changelog appears ~6 months out of date compared the github page.
For people looking for an easy work around: apt-get install rsyslog will ensure sshd is logged as usual.
Install rsyslog? Nonsense. Creating /etc/fail2ban/jail.local with [DEFAULT] default_backend = systemd will do the trick. IMO the error lies within /etc/fail2ban/paths-common.conf which says [DEFAULT] default_backend = auto This should be changed to default_backend = systemd
hi there, i surprisingly discovered today that fail2ban didn't work for quite some (too long) time. Reason was changing from syslog to systemd. after changing "backend = auto" to "backend = systemd" and wondering why it fail all the time, it took me hours to find out that there is a bug/ missing dependency. guys please fix this! this bug is nearly 3 years old!! or is there any technical reason for this? autor has already mentioned how to fix this. 1. add python[1-3]-systemd as dependency 2. fix /etc/failt2ban/filter.d/sshd.conf form journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd to journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd btw duplicated bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862348 pls fix :)
Idézem/Quoting Sebastian Walther <sebastian.r.walther@googlemail.com>: This is not a solution but you may try to install Fail2ban from testing https://packages.qa.debian.org/f/fail2ban.html It is quite old but may help you. SZÉPE Viktor, honlap üzemeltetés https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
I can confirm this behaviour is still buggy in version 0.9.6-2 (current debian stretch repo). So far I have switched to systemd backends for sshd and postfix on my machine, and I had to make the following changes: replace journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd with journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd in /etc/fail2ban/filter.d/sshd.conf /etc/fail2ban/filter.d/sshd-ddos.conf and replace journalmatch = _SYSTEMD_UNIT=postfix.service with journalmatch = _SYSTEMD_UNIT=postfix@-.service in /etc/fail2ban/filter.d/postfix.conf /etc/fail2ban/filter.d/postfix-sasl.conf HTH, Vincent
Hi, in Debian 11 with f2b version 0.11.2-2 the issue with "journalmatch" seems to be fixed, but now the filter is wrong. /etc/fail2ban/filter.d/sshd.conf # consider failed publickey for invalid users only: cmnfailre-failed-pub-invalid = ^Failed publickey for invalid user <F-USER>(?P<cond_user>\S+)|(?:(?! from ).)*?</F-USER> from <HOST>%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$) The log output in systemd does not match, the regex has to be changed to something like: cmnfailre-failed-pub-invalid = ^Failed publickey for <F-USER>(?P<cond_user>\S+)|(?:(?! from ).)*?</F-USER> from <HOST>%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$) Daniel
Hi all, Still an issue for the backend option being left on 'auto', could the default for Debian be changed to use systemd as the backend? (Fresh install on Bookworm). Regards, Nephi.Aust
Hi Team, This is getting pretty annoying, a 9 years old inconvenience, especially now that Debian 12 does not even have a syslog service installed by default. Fail2ban fails to start right after its installation. The solution is really trivial. At least an SSHD override should be added in "paths-debian.conf" file, such as: sshd_backend = systemd so that the fail2ban service can start after one installs it. Thanks, Andrei
default. did you read the esrlier messages in the bug report - those messages say that fail2ban works provided python3-systemd is installed. there is no need to edit any config files.
On Fri, 11 Aug 2023 at 12:57, Richard Lewis < richard.lewis.debian@googlemail.com> wrote:
Hi Richard,
Thanks for your swift reply.
python3-systemd is just a wrapper that ties python to systemd's functions.
How would one expect it to magically solve this issue if no one _instructs_
the SSHD jail to actually use the logs in the journal instead of some file
logs(which is the default setting)?
Reproduction:
default paths_debian.conf contents
# dpkg -l | grep python3-systemd
ii python3-systemd 235-1+b2 amd64
Python 3 bindings for systemd
root@blabla:/etc/fail2ban# service fail2ban start
root@blabla:/etc/fail2ban# service fail2ban status
× fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; preset:
enabled)
Active: failed (Result: exit-code) since Fri 2023-08-11 15:14:52 EEST;
5s ago
Duration: 123ms
Docs: man:fail2ban(1)
Process: 91337 ExecStart=/usr/bin/fail2ban-server -xf start (code=exited,
status=255/EXCEPTION)
Main PID: 91337 (code=exited, status=255/EXCEPTION)
CPU: 120ms
Aug 11 15:14:52 seif.radiocom.ro systemd[1]: Started fail2ban.service -
Fail2Ban Service.
Aug 11 15:14:52 seif.radiocom.ro fail2ban-server[91337]: 2023-08-11
15:14:52,937 fail2ban [91337]: ERROR Failed during
configuration: Have not found any log file for sshd jail
Aug 11 15:14:52 seif.radiocom.ro fail2ban-server[91337]: 2023-08-11
15:14:52,940 fail2ban [91337]: ERROR Async configuration
of server failed
There are at least 2 options I can think of to overcome this issue:
1. Add sshd_backend = systemd to paths_debian.conf
2. Create a jail.local file with the following contents:
[sshd]
backend = systemd
enabled = true
Then it'll work.
In conclusion, just installing python3-systemd package _won't_ fix
anything, therefore this should still be considered a bug, as this software
does _NOT_ work out-of-the-box.
Thanks,
Andrei
Hi again, Also, it seems to me that you've skipped some reading from the original bug report. I quote Tiziano Zito, saying: "In order to have the sshd jail to work correctly I had to: 1. install python3-systemd, which is right now only suggested by fail2ban, but given that systemd is going to be default in jessy it should probably become a Depends 2. activate the systemd backend by adding [DEFAULT] backend = systemd to the jail.d/defaults-debian.conf file" So switching to the systemd backend was there from the beginning. Thanks, Andrei
This bug report from 2014 is meanwhile more important than ever. With the latest stable release Debian marked rsyslog as deprecated (see https://wiki.debian.org/Rsyslog). If a user removes the rsyslog package without removing the related logfiles in /var/log, fail2ban silently stops doing its job, because it looks for failed ssh logins in /var/log/auth which no longer gets updates. The same applies to other jails which were activated by local settings. If the user not only removes rsyslog but also removes all old files in /var/log/, fail2ban no longer runs at all but silently fails. If fail2ban is not working as expected or not running at all, that can effect the security of a Debian system. Therefore I suggest to increase the priority of this bug report. My fix for this issue (and also for issue 1024305) is a small modification of jail.d/defaults-debian.conf:------ # cat /etc/fail2ban/jail.d/defaults-debian.conf [DEFAULT] allowipv6 = auto dovecot_backend = systemd postfix_backend = systemd sshd_backend = systemd # ... add more affected backends here [sshd] enabled = true------ I only added the backends which where required for my Debian system. Maybe some other jails also must use the systemd backend. I suggest to update jail.d/defaults-debian.conf and distribute that as a security fix. In addition, rsyslog could be removed from the list of suggested packages in future Debian releases. Stefan
Confirmed that this is still annoying. I (as a moderate linux user) had to search several hours, during several days until finding the fix. It works fine in a debian11 fresh install, not in a debian12. So I suppose it was fixed some time before, but came back an issue recently. After adding "backend=systemd" to the jail.d/defaults-debian.conf in the ssh section should be the simplest solution for having back some safety in a default apt-get install. An extra burden is that you need to manually install python3-systemd also. If not, it will not work after a fresh install. This should be a dependency on the jail2ban installation. For me, it is not the extra work to do to make it work that is the problem, the big issue is that people may rely on the fact that they installed fail2ban, and think their safety increased, however it doesn't work out of the box! I wonder how they make all these tutorials. Have a nice day, Stefaan On Sun, 24 Sep 2023 19:52:07 +0200 Stefan Weil <sw@weilnetz.de> wrote: > This bug report from 2014 is meanwhile more important than ever. > > With the latest stable release Debian marked rsyslog as deprecated (see > https://wiki.debian.org/Rsyslog). > > If a user removes the rsyslog package without removing the related > logfiles in /var/log, fail2ban silently stops doing its job, because > it looks for failed ssh logins in /var/log/auth which no longer gets > updates. The same applies to other jails which were activated by local > settings. > > If the user not only removes rsyslog but also removes all old files in > /var/log/, fail2ban no longer runs at all but silently fails. > > If fail2ban is not working as expected or not running at all, that can > effect the security of a Debian system. Therefore I suggest to increase > the priority of this bug report. > > My fix for this issue (and also for issue 1024305) is a small > modification of jail.d/defaults-debian.conf: > > ------ > > # cat /etc/fail2ban/jail.d/defaults-debian.conf > [DEFAULT] > allowipv6 = auto > dovecot_backend = systemd > postfix_backend = systemd > sshd_backend = systemd > # ... add more affected backends here > > [sshd] > enabled = true > > ------ > > I only added the backends which where required for my Debian system. > Maybe some other jails also must use the systemd backend. > > I suggest to update jail.d/defaults-debian.conf and distribute that as a > security fix. > > In addition, rsyslog could be removed from the list of suggested > packages in future Debian releases. > > Stefan > > >
Hello, Bug #770171 in fail2ban reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/fail2ban/-/commit/47a2ffa95ac787382f439505a257468ea666d17d (this message was generated automatically) -- Greetings https://bugs.debian.org/770171
We believe that the bug you reported is fixed in the latest version of
fail2ban, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 770171@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Sylvestre Ledru <sylvestre@debian.org> (supplier of updated fail2ban package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 19 Sep 2023 13:55:20 +0200
Source: fail2ban
Architecture: source
Version: 1.0.2-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Team <team+python@tracker.debian.org>
Changed-By: Sylvestre Ledru <sylvestre@debian.org>
Closes: 770171 1037437
Changes:
fail2ban (1.0.2-3) unstable; urgency=medium
.
* Add banaction = nftables in the defaults-debian.conf default
see https://github.com/fail2ban/fail2ban/discussions/3575#discussioncomment-7045315
* Move python3-systemd as depend (Closes: #770171, #1037437)
* Add backend = systemd to jail.d/defaults-debian.conf
Checksums-Sha1:
a221158a81ce3906b05263c58fdaece56c57f8b0 2059 fail2ban_1.0.2-3.dsc
d829392cc6f53fb56b982bb3ba7ab41803221ef0 29616 fail2ban_1.0.2-3.debian.tar.xz
28f80e77797db56e03b1b4efc6e35301fe07bfe3 6938 fail2ban_1.0.2-3_amd64.buildinfo
Checksums-Sha256:
7c7c70e55b8d0ddeb9e860053a4db66acd9a75e133d62e3f58e6be012c1bb9d7 2059 fail2ban_1.0.2-3.dsc
720d8c6fd124031f7c2488af6a6f86f4be0d407c45cd94b7220209e7cf4f93c0 29616 fail2ban_1.0.2-3.debian.tar.xz
ee98ac04f491e5ca921bd8f1742a917a72da11653229fd056acff92229fb92fc 6938 fail2ban_1.0.2-3_amd64.buildinfo
Files:
59fbaf232d2f678777e538b75286fe7c 2059 net optional fail2ban_1.0.2-3.dsc
4e233c00e21527de7ae02c9b889e6fc5 29616 net optional fail2ban_1.0.2-3.debian.tar.xz
0c83648e5ef62309e42a04768d375a28 6938 net optional fail2ban_1.0.2-3_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmWUX4kACgkQfmUo2nUv
G+FPSA//Qev+iTo3047na6J3er9NbuLg1k3IUoPfRE4VNlApapA7mEZsfQmmfqTg
1gUfBpeFN6qINdVVby7kB2zTel0z1dsyDkra+17WgoQJv8nTLiUEUdGq8JFuzYoq
a+gljp6HbYSry7bS3RnZMZD11wW+1JzkxJ2OtbKopfEcVyNe7FDa+Dm8W4NOudyl
7VFL93uC1Sb2I5hE5mWexdi8By8rk4fwTh4RQhcLbsd45gf9y4MB9S7Dk1S+k+n7
uRVFBZqzTY89gGULgpQboTewLiGqRQGAcNtF7jBZMElOe7Wy6eJSKA8oTloNZQHT
zIFlvt5XP+XbS4zi4DIGPmCTVmg3F90CSbzMJqsqU2tvPeIMo11OEG1+ZeBGkqD/
9jYV3xpkpYkp/emhOvxuq3Ll22ty3qa4PhoTT4W4zaTeb3eLsJev2iT4eQdzH1vI
GNayOQ5wGe2vSdqPwi4BjUjKsa6snLcrjXerpnaHzihrE22qajiKjxn1TOTd2lKN
eJR3a4O5BwIXyeR+03VqGIehEhaAXE6sfeQTvvk+pRLzZA8vXXzecXV+TmNPm6py
bmycYs2kg/KaLHBJAdevg0CYaSEauYltBPtk3mRPsltIZKIj+gK8mOx04ab3inni
f0z/mJ0TcuixKb3qMFvjEU+8k6XLafJvencJWfh+7HY/beFuB6A=
=DbGW
-----END PGP SIGNATURE-----