How to secure your CheckMK Web UI Login with Fail2Ban

I created a gist (Github Code Snippets) for an example fail2ban jail to protect your CheckMK web UI login form against brute-force attacks by banning the attackers IP address for a while after too many failed login attempts.

You can also always find the latest version here: Fail2ban Config for CheckMk Authentication over Web UI · GitHub

CheckMk Web Auth Fail2ban Config

Fail2ban Config for CheckMk Authentication over Web UI

This is a example fail2ban config for failed login attempts in the CheckMK Web UI Login Form.

Setup

Check for log files

CheckMK logs failed login attempts for each site separately at ~/var/log/web.log (relative path from the site’s user).
To view them, type sudo ls -l /omd/sites/*/var/log/web.log
Or as a checkmk user: First change to the user of your checkmk site with omd su <sitename>, then type ls ~/var/log/web.log

Create Fail2Ban Filter and Jail

  1. If not already done, install fail2ban (e.g. for Ubuntu: apt install fail2ban)
  2. Create 2 new files with the following path and name and copy the content inside the code block (Click on them to see the code).
/etc/fail2ban/filter.d/checkmk-auth.conf
# checkmk-auth configuration file
#


[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>\S+)
# Values:  TEXT
#

failregex = Login failed for username: <F-USER>.*</F-USER> \(existing: .*, locked: .*, failed logins until locked: .*\), client: <HOST>$

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

datepattern = ^%%Y-%%m-%%d %%H:%%M:%%S,%%f\s
/etc/fail2ban/jail.d/checkmk-auth.conf
[checkmk-auth]

enabled = true
filter = checkmk-auth

# See the docs for information about used ports: https://docs.checkmk.com/latest/en/ports.html#loopback
# Specify a single port (port=5000) and multiple ports comma-separated (e.g. port=5000,5001,5002) or as a range (e.g. port=5000:5010)
port=5000:5100
action  = iptables-multiport[name=checkmk-auth, protocol=tcp]

logpath = /omd/sites/*/var/log/web.log

maxretry = 5
  1. If needed, change the port or add additional ports at line 8 in /etc/fail2ban/jail.d/checkmk-auth.conf for your checkmk sites (each site has its own port. See the docs for more information about used ports: Ports - Ports used by Checkmk)
  2. To test your fail2ban config, run fail2ban-regex /omd/sites/*/var/log/web.log /etc/fail2ban/filter.d/checkmk-auth.conf
  3. Reload fail2ban to activate the config: fail2ban-client reload --restart checkmk-auth or systemctl reload fail2ban.service
  4. Check if fail2ban knows about the new jail: fail2ban-client status checkmk-auth

Testing

To test your fail2ban config

  1. Make some login attempts that will fail (wrong username or password)
  2. To test the filter, run fail2ban-regex /omd/sites/*/var/log/web.log /etc/fail2ban/filter.d/checkmk-auth.conf
  3. To test the jail, run fail2ban-client status checkmk-auth

Statistics

To see statistics about the checkmk-auth jail, run fail2ban-client status checkmk-auth

4 Likes

Curious as to will this - if setup - Two-Factor Auth - trigger on only failing the 2nd factor.

  • Glowsome

I just tested it with my two Yubikeys and unfortunately CheckMK doesn’t log failed 2FA attempts (with an unknown Yubikey) or entering an incorrect backup code.
So the fail2ban jail will only apply to incorrect credentials.

I had hoped that when the 1st factor (user/pass) is correct, but it fails on the 2nd factor it would (or could) also trigger.
If the information is not there then its hard to act upon it.

Question i have, is this a result of a/the loglevel or is the information not included at all.

I think this should/can be answered by CMK staff itself, so sending a ping out to @Maximilian and @Sara to hopefully give us insight in this matter.

  • Glowsome

Hey,
currently these events are not logged at all. We are planning to introduce a dedicated security.log and improve the logging for these events in the 2.3 release.
Best, Max

5 Likes