Created attachment 262943 [details] Patch file According to the Release Notes of OpenSSH, following incompatible change is made with 9.8p1. * sshd(8): several log messages have changed. In particular, some log messages will be tagged with as originating from a process named "sshd-session" rather than "sshd". And it causes fail2ban to fail to detect attack to SSH port. So change filter.d/sshd.conf so it also supports 9.8p1 and later. Reference: https://www.openssh.com/txt/release-9.8 Reference: https://github.com/fail2ban/fail2ban/blob/4e22c20559ea6488bf9a8e84c5f7d8bff5a52c34/config/filter.d/sshd.conf#L19
BTW, though I don't use either filter.d/bsd-sshd.conf or filter.d/bsd-sshd-session.conf, it seems the only difference of them is the value of '_daemon' as below. --- filter.d/bsd-sshd.conf 2025-08-14 03:29:00.000000000 +0900 +++ filter.d/bsd-sshd-session.conf 2025-08-14 03:29:00.000000000 +0900 @@ -14,7 +14,7 @@ [Definition] -_daemon = sshd +_daemon = sshd-session # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The So they can be unified into one by same way as my patch Just FYI.
You are using the wrong filter file. Use bsd-sshd-session.conf.
On second thought we will remove the bsd-sshd.conf and keep bsd-sshd-session.conf. This will reduce confusion. I will also remove any Linux sshd.conf as well.
Patch committed and yet to be pushed. I will push it during my next batch of pushes.
(In reply to Yasuhiro Kimura from comment #1) I'm using: filter = bsd-sshd-session in /usr/local/etc/fail2ban/jail.d/sshd.conf
(In reply to Vladimir Druzenko from comment #5) The next commit, waiting to be pushed, removes sshd.conf. People will be forced to use bsd-sshd-session.conf.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d906503fb22992a7a92d46365b9f2af31454dee6 commit d906503fb22992a7a92d46365b9f2af31454dee6 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2025-08-13 19:16:28 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2025-08-14 00:58:04 +0000 security/py-fail2ban: Remove unneeded filter.d files There is some confusion whether to use the sshd.conf, bsd-sshd.conf. or the bsd-sshd-session.conf filters. bsd-sshd-session.conf is the correct and only filter to use on FreeBSD systems. Using the others will result in incorrect operation on a FreeBSD system with a supported sshd installed. PR: 288849 UPDATING | 8 ++++ security/py-fail2ban/Makefile | 4 +- .../patch-config_filter.d_bsd-sshd.conf (gone) | 44 ---------------------- 3 files changed, 11 insertions(+), 45 deletions(-)
I have used such configuration file as below for years and fail2ban worked fine until system is updated to 14.3-RELEASE. ---------------------------------------------------------------------- [DEFAULT] bantime = 1y findtime = 1mo ignoreip = # home network 192.168.0.0/24 2001:db8::/64 fe80::/10 banaction = pf [sshd] enabled = yes ---------------------------------------------------------------------- After system is updated to 14.3-RELEASE fail2ban doesn't work as is expected. So I applied attachment 262943 [details]. Then fail2ban properly detects such log message as below in /var/log/authlog ---------------------------------------------------------------------- Aug 15 12:00:00 server sshd-session[12345]: Invalid user postgres from 10.1.2.3 port 9876 ---------------------------------------------------------------------- And it writes such log message as below in /var/log/authlog. ---------------------------------------------------------------------- Aug 15 12:00:00 serer fail2ban.filter[23456]: INFO [sshd] Found 10.1.2.3 - 2025-08-15 12:00:00 ---------------------------------------------------------------------- After ports d906503fb229 is committed, however, filter.d/ssh.conf is removed from package and 20250813 item of UPDATING says bsd-sshd-session.conf should be used instead. So I changed last two lines of configuration file as below and restart fail2ban. ---------------------------------------------------------------------- [bsd-sshd-session] enabled = yes ---------------------------------------------------------------------- Then log message from sshd such as above isn't detected again and fail2ban doesn't block attack to SSH port any more.
I find myself in the same position as Yasuhiro: I was using a patched version of upstream's sshd.conf (fail2ban has had the patch in their pre-release for a year but haven't made an actual release) and fail2ban worked fine. Since switching to bsd-sshd-session, fail2ban doesn't detect sshd login failures. The regexes in bsd-sshd-session work fine ("fail2ban-regex auth.log bsd-sshd-session" gets a lot of hits) but fail2ban doesn't appear to log this or take any action. It's possible that the changed jail name is breaking something in my pf action, but that shouldn't prevent fail2ban logging "Found" events.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4571fd63f19cf52ca1db8568fee7b5a1f2d49400 commit 4571fd63f19cf52ca1db8568fee7b5a1f2d49400 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2025-08-20 08:57:36 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2025-08-20 09:01:50 +0000 Revert "security/py-fail2ban: Remove unneeded filter.d files" While some users want the upstream sshd filters to have the contents the BSD sshd filters, others use them as is. Revert this change. Let users decide which to use. PR: 288849 This reverts commit d906503fb22992a7a92d46365b9f2af31454dee6. UPDATING | 8 ---- security/py-fail2ban/Makefile | 4 +- .../patch-config_filter.d_bsd-sshd.conf (new) | 44 ++++++++++++++++++++++ 3 files changed, 45 insertions(+), 11 deletions(-)
The commit has been reverted. The port worked before, people should use the filter of their choosing rather than requesting they all be made the same. If a filter doesn't work for one person, people are free to change it or add new site specific filters. But in the future no filters will be change, no filters will be added, and no filters removed unless there are a significant number of people, i.e > 30 or 40 or more, who agree to such change. The original change that was requested in this PR, is rejected.
Ah, bother, I think I'd just worked out the underlying problem. Upstream's jail.conf sets logpath for the "sshd" jail. It doesn't set it for the "bsd-sshd-session" jail. So the following jail.local will work: ---->8---- [sshd] enabled = true ---->8---- But this one, which someone might reasonably switch to when being told to change to bsd-sshd-session, will have no logpath and will never detect login failures: ---->8---- [bsd-sshd-session] enabled = true ---->8---- Either users need to add "logpath = /var/log/auth.log" (or wherever they keep their SSH auth log) to their jail.local section for the bsd-sshd-session jail, or the following lines need to be added to jail.conf: ---->8---- [bsd-sshd-session] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s ---->8---- Looking at that, people without my Very Strange Banactions probably also need to add "port = ssh" to their jail.local. I think it's worth modifying the distributed jail.conf with a patch to set port and logpath for bsd-sshd-session, or at least documenting in the package message that the user needs to do this.
Nicholas, thanks so much for adding that comment! I spent hours yesterday trying to get fail2ban working on a freshly installed FreeBSD VM. I'm still not sure what I should be doing, and there seems to be almost no documentation about this stuff. Every tutorial out there talks about: ``` [sshd] enabled = yes ``` But this seems to *not* work on FreeBSD. Is that expected? Then I tried: ``` [bsd-sshd-session] enabled = true ``` But that also doesn't work. If you add "logpath = /var/log/auth.log" it seems to work more. I have 1000 questions, but maybe I'll ask just one: where do I RTFM for using fail2ban with FreeBSD? Thanks.
Documentation for fail2ban generally seems to be a bit lacking; it looks as though they used to have a FM but it didn't survive the project's move to Github. For this specific problem, though, the central issue is upstream; see https://github.com/fail2ban/fail2ban/issues/3785 . A fix was added to the prerelease version over a year ago, but the project hasn't put out a release since. No big deal, it just means the release version of their project doesn't achieve the one task anybody uses it for. Yasuhiro's patch on this PR applies that fix to the release version. The fix for you as a user is to put the following two lines in your (by default) /usr/local/etc/fail2ban/filter.d/sshd.local file: [DEFAULT] _daemon = (?:sshd(?:-session)?) That'll override the distributed sshd.conf file so that your [sshd] enabled = yes will cause fail2ban to match login failures for sshd. The instructions in the package installation message for fail2ban should then work to allow fail2ban to ban the hosts from which it detects login failures; you can review the instructions using pkg info -D security/py-fail2ban If you haven't already got pf working, make sure you have console access or a saved state you can roll back to; the FreeBSD Handbook has pretty good instructions for setting up pf but we've all messed up and locked ourselves out at least once. Sorry if that's teaching you to suck eggs.
Many thanks Nicholas! `fail2ban-client status` is showing banned IPs now. Yay! But I'm not certain if pf is actually blocking things or not. Do you know if one must add `banaction = pf`? I have seen mixed info out there about that. Also, should one expect `pfctl -t f2b -T show` to list some IPs?
If you don't set banaction, fail2ban defaults to using iptables to block IP addresses. That's not terribly helpful if you're on FreeBSD. I set banaction = pf[actiontype=<allports>] in the [DEFAULT] section of my jail.local. The comments in fail2ban's action.d/pf.conf are some of the more helpful fail2ban documentation I've met. Because this action inserts its rules under the f2b/sshd anchor, you'll need to use pfctl -a f2b/sshd -t f2b-sshd -T show to list banned IPs. Since that will be empty until fail2ban has banned some IPs, I'd use pfctl -a f2b/sshd -s rules to check fail2ban is adding pf rules in the right place; that should show a single "block quick" rule.
>If you don't set banaction, fail2ban defaults to using iptables to block IP addresses. That's not terribly helpful if you're on FreeBSD. Indeed! Isn't /usr/local/etc/fail2ban/jail.conf customized by the FreeBSD port though? It seems so, since near the top there is: ``` #before = paths-distro.conf before = paths-freebsd.conf ``` And upstream does not have "freebsd" there: https://github.com/fail2ban/fail2ban/blob/7bac8396034b1857577359513911c29a14f8f586/config/jail.conf#L35 Couldn't/shouldn't the `banaction = iptables-multiport` part also therefore be customized so the thing has some hope of working out of the box?
I think I have my answer: https://github.com/freebsd/freebsd-ports/blob/84e02f358a1f386d7d883be8efb13e1fe1a605ef/security/py-fail2ban/Makefile#L58 indeed customizes that part: @${REINPLACE_CMD} -e 's,paths-debian.conf,paths-freebsd.conf,g' \ So I guess it's just an oversight that `banaction = iptables-multiport` isn't also customized...