[FR]: Fix Dropbear failregexes broken since 2020

[MichaIng]

Environment:

• Fail2Ban version :
• OS, including release name/version :

Service, project or product which log or journal should be monitored

• Name of filter or jail in Fail2Ban (if already exists) : Dropbear
• Service, project or product name, including release name/version : v2022.83
• Repository or URL (if known) : https://github.com/mkj/dropbear
• Service type : SSH server
• Ports and protocols the service is listening : 22 TCP

Log or journal information

• Log file name(s) : /var/log/auth.log

• Journal identifier or unit name : dropbear.service/dropbear

Any additional information

Dropbear is supported already. This PR adds support for cases where it runs as systemd service with -E flag, where Dropbear itself adds PID and timestamps: #3597

However, while testing it, I recognised that max retry limit and nonexisting users login attempts do not match anymore: #3597 (comment)

Funnily this was caused by a commit (to Dropbear upstream) which was intended to help software like Fail2Ban, while in practice it broke it, due to lack of communication, and since the nonexisting user case was not carefully checked, which misses the host now: mkj/dropbear#83

From below lines, the first case matches with #3597 and when running Dropbear as init.d service (provided by upstream). The 2nd line does not match anymore after the linked PR merged 2020. The 3rd cannot match anymore, because it lacks the host, and the 4th was never supported, but could be additionally added.

EDIT: I sent a PR to have the nonexisting user login log fixed: mkj/dropbear#316
The "Exit before auth" logs are the only thing which can be fixed/added here.

Relevant lines from monitored log files:

failures in sense of fail2ban filter (fail2ban must match):

Jul 10 23:57:29 VM-Bookworm dropbear[825]: [825] Jul 10 23:57:29 Bad password attempt for 'root' from 192.168.1.3:52289
Jul 10 23:57:29 VM-Bookworm dropbear[825]: [825] Jul 10 23:57:29 Exit before auth from <192.168.1.3:52289>: (user 'root', 10 fails): Max auth tries reached - user 'root'
Jul 10 23:58:41 VM-Bookworm dropbear[826]: [826] Jul 10 23:58:41 Login attempt for nonexistent user
Jul 10 23:59:24 VM-Bookworm dropbear[826]: [826] Jul 10 23:59:24 Exit before auth from <192.168.1.3:52325>: Max auth tries reached - user 'is invalid'

legitimate messages (fail2ban should not consider as failures):

[sebres]

a796cc9 must fix it.
Regarding Login attempt for nonexistent user message: does it really needed? I mean, take a look at last message in your excerpt with invalid user at end - could it not count the attempt twice?

[MichaIng]

"nonexistent" user is used for what it says, and the client host was accidentally removed from the log on Dropbear end, and has been reverted already upstream some months ago.

There is a dedicated "invalid" user log, which is used when the Dropbear server runs as non-root user and hence one can login only with that particular user, rendering other existing users as invalid. That massaage currently misses the host as well, if I am not mistaken, but I did not open a PR to fix/revert it at Dropbear yet, as I did not find time to verify it yet.

[MichaIng]

@sebres
Ah sorry, I mixed up your comment with the fix(es) at Dropbear side. You mean those, right?

Exit before auth from <192.168.1.3:52289>: (user 'root', 10 fails): Max auth tries reached - user 'root'
...
Exit before auth from <192.168.1.3:52325>: Max auth tries reached - user 'is invalid'

This first shows up only when a defined number of authentication attempts was reached (10 in my case). The second in case one retries again afterwards. The first was indeed tracked by Fail2Ban, but because of mkj/dropbear#83, it does not match anymore, as the host, as can be seen above, is now in the generic log prefix for "early exit" logs. We could fix the failregex and add one for the 2nd of the two above messages, but actually those indeed somehow double the ban matches, and I remember I had to take into account this exact thing some years ago, before a Dropbear release with above commit reached Debian stable: I configured Dropbear to early exit already after a single failed login attempt, which lead to 2 matches in Fail2Ban. Hence indeed I think those logs about exceeded login attempts should be better not matched by Fail2Ban, at least not by default, but maybe only hidden behind an extended filter options or so. If any such log appears, other authentication failures appeared before, at least after the "nonexistent" user log has been fixed. And the other one is I mentioned above creates a "wrong user" log entry, which is currently missing the remote host as well.

Shall I open a new issue/PR to either remove or fix the "Max auth tries reached" regex from the Fail2Ban filter?

For completeness: I just opened a PR to fix the missing host in "wrong user" logs as well: mkj/dropbear#338
Once this has been released, Fail2Ban might add a related failregex, to catch as well login attempts with "wrong" users, if the server runs as non-root user.

[sebres]

but actually those indeed somehow double the ban matches
Shall I open a new issue/PR to either remove or fix the "Max auth tries reached" regex from the Fail2Ban filter?

The problem with that is - the stock filter may be used on old systems too, and if an RE adjustment may be made backwards compatible (so it'd match both formats), a removal would be definitely not. In this case dual triggering is better than no one.

Back to your question, sure you can - but... maybe later.

[MichaIng]

For the actual early exit messages, the log format will definitely not be reverted at Dropbear. Then I suggest to additionally add support for the new logs, and add comments to show until which/from which Dropbear version on, they are relevant. So on later review, there is a starting point to decide whether to keep or drop the old failregex entries.