fail2ban not working with dropbear (+ a hacky solution)

[ThePlanplan]

Required Information

• DietPi version | 8.22.3
• Distro version | bookworm

Additional Information (if applicable)

• Software title | fail2ban + dropbear
• Using log2ram

Steps to reproduce

1. Installing fail2ban on a clean dietpi installation
2. Checking fail2ban-client for jails, dropbear is up and running
3. Trying to connect an other ssh session, 3 tries with erroneous passwords
4. Nothing is seen by the fail2ban jail, still 0 failed, 0 banned

Expected behaviour

I should be banned after 3 failed attempts.

Actual behaviour

Nothing happen.

Extra details

I searched for a bit, and I think the way the logs are formated in journactl are the cause of the problem.

Oct 05 23:37:49 HOST dropbear[15386]: [15386] Oct 05 23:37:49 Bad password attempt for 'USER' from IP:PORT

The date appear 2 times, and the fail2ban filter for dropbear is too strict for this case.

I resolved the problem on my machine by modifying the filter and allowing the filter to search in the middle of a line, but I don't think it's a good thing :

/etc/fail2ban/filter.d/dropbear.conf

prefregex = ^%(__prefix_line)s<F-CONTENT>(?:[Ll]ogin|[Bb]ad|[Ee]xit).+</F-CONTENT>$

to

prefregex = %(__prefix_line)s<F-CONTENT>(?:[Ll]ogin|[Bb]ad|[Ee]xit).+</F-CONTENT>$

[MichaIng]

Many thanks for your report.

The reason might be that Dropbear turned into a native systemd service with Bookworm, while previously it was an init.d service. The difference is that as init.d service is runs in background, while as systemd service is runs in foreground, i.e. the -EF flags are used to prevent the background fork and log to STDOUT instead of syslog. Usually processes interpret it as running on a console, where one usually wants timestamps, while syslog (including the systemd journal) of course add timestamps already. What is missing is a flag to suppress time stamps for STDOUT logs as well, to work with systemd properly.

However, while it is not beautiful to have doubled timestamps, indeed it does not really hurt either, when the Fail2Ban filter allows it. Here is a pattern with works without loosening the regex:

prefregex = ^%(__prefix_line)s\[\d+\] [A-Z][a-z]+ \d\d \d\d:\d\d:\d\d <F-CONTENT>(?:[Ll]ogin|[Bb]ad|[Ee]xit).+</F-CONTENT>$

[MichaIng]

Sent upstream: fail2ban/fail2ban#3597
When merged, I'll ask Debian to backport this as a patch to their Bookworm package.

[MichaIng]

Fixed with: 7095f96
Since my upstream PR is ignored, I'll send a merge request with a patch to Debian instead: https://salsa.debian.org/python-team/packages/fail2ban/-/tree/master/debian/patches

[MichaIng]

Sent to Debian: https://salsa.debian.org/python-team/packages/fail2ban/-/merge_requests/10

I'l mark this as closed now, as it is solved for DietPi users and I did all I can to solve it for Debian and upstream users as well.

[MichaIng]

Uhh, there is more broken: fail2ban/fail2ban#3791
One thing in Dropbear itself: mkj/dropbear#316

The most important cases (wrong password) are again successfully tracked, but login attempts with wrong users cannot be tracked, and the additional fail match when the Dropbear retry limit has been reached (less relevant) does not match anymore.