Logging login attempts & fail2ban

Hi there,
is there any way to get (OH3) login attempts being logged? Because with that, it would be possible to create a fail2ban filter.

Thanks!

1 Like

Just do trials to login with a wrong password and observe the content of the log files.
Doing that you should be able to see entries like:

2021-04-07 08:32:56.577 [WARN ] [uth.internal.AbstractAuthPageServlet] - Authentication failed: Wrong password for user schlue

and in case of a non existing user:

2021-04-07 08:34:54.234 [WARN ] [uth.internal.AbstractAuthPageServlet] - Authentication failed: User not found: bla

Hi Wolfgang,
sometimes it’s that simple - haha. Great, so basically the only thing left would be the RegEx for the fail2ban-filter.

As you’ve already stated above, according log-entries would be;

07-Apr.-2021 08:52:28.679 [WARN ] [core.io.http.auth.internal.AbstractAuthPageServlet] - Authentication failed: Wrong password for user ABC
07-Apr.-2021 08:52:33.949 [WARN ] [core.io.http.auth.internal.AbstractAuthPageServlet] - Authentication failed: User not found: XYZ

I’ve played around https://regex101.com and came up with the following RegEx (first touchpoint for me);

(\bAuthentication failed: Wrong password\b|\bAuthentication failed: User not found\b)

While it works in the tool, unfortunately I don’t see any matches in fail2ban.

Have you tried to simulate a fail2ban run with

fail2ban-regex  YourLogFile  YourFail2BanRuleForOpenhab.conf

?
This will fail because fail2ban requires to see/find a that tried to connect in the logfile.
The openhab log file does not show that host entry so the rule will fail.

Hi Wolfgang,

yes - I tried that with any combination that worked in regex101-tool, e.g.

failregex = (\bAuthentication failed: Wrong password\b|\bAuthentication failed: User not found\b)/g

or

failregex = ^Authentication failed: Wrong password for \S*$ 
            ^Authentication failed: User not found: \S*$

Both fail2ban-regex, and fail2ban log show;

[...]No failure-id group[...]

Wouldn’t fail2ban require an ip-address to be present in the log line as well, in order to block the offender using the firewall?

Sorry, I don’t know if fail2ban relies on an IP address within the log or if it’s capable of retrieving it itself.

I am wondering why you want to control the web UI.
I use fail2ban on my pi4 checking SSH and OpenVPN server.
My UI has user and password, so no need to control.
But maybe you have a special use case.

  • I also use fail2ban for Nextcloud and also wanted to give it a try for OH
  • within the filters-dir of fail2ban there’s already one for OH, but it’s only for blocking IPs trying to auth openhab by web- or rest api (so at least someone else has a use case)

fail2ban requires an IP address ( or hostname ) to ban the remote host.
As neither openhab.log nor events.log contain IP addresses you can’t use this kind of log files togehter with fail2ban.
For the REST api it is a bit different I assume that an apache logfile or nginx logfile is being used together with fail2ban. They contain IP address / hostname entries to ban a computer in case of fail2ban was triggered. You may have a check in case you use nginx/apache as a reverse proxy how and if wrong authentication is being logged.

What do you mean with “only blocking IPs trying to auth”?
I think this is what fail2ban is designed for.

yeah, I learned that recently - thanks for pointing out!

will check that and come back here if i found something to work with!

i just wanted to say that fail2ban comes with a filter for openhab - it says;

# Openhab brute force auth filter: /etc/fail2ban/filter.d/openhab.conf:
# Block IPs trying to auth openhab by web or rest api
# Matches e.g.
# 12.34.33.22 -  -  [26/sept./2015:18:04:43 +0200] "GET /openhab.app HTTP/1.1" 401 1382 
# 175.18.15.10 -  -  [02/sept./2015:00:11:31 +0200] "GET /rest/bindings HTTP/1.1" 401 1384

For security and revisioning reasons a log of each login would be cool.

For use in critical systems (even if there are other ways, openhab is here a very comfortable and stable solution)

Further for revisioning reasons, it might be very interesting if, for example the instance is hijacked or some user manipulate states