Checkmk
to checkmk.com

This article will be completed in the near future to provide a central overview on all aspects of security measures implemented in Checkmk and aids on further improving security.

First the Good News: Since its beginning Checkmk has used an architecture that considers security needs and — wherever possible — applies these to its standard settings. There are however aspects where user intervention is required, for example when keys or certificates have to be generated or imported.

1. Agent output

Since version 2.1.0, Checkmk has used TLS encryption for communication between the server and the agents on Linux and Windows hosts. Detailed information on this communication are covered in the following articles:

However there are some environments where TLS encryptions for Linux or Unix clients cannot be setup. In such cases you might use encrypted tunnels, for example with SSH:

2. HTTP(S) communication

On many places within Checkmk communication is realized over HTTP. This applies to internal communication and configurations such as distributed monitoring. Switch to HTTPS where possible:

3. Access control

Checkmk supports connections to various authentication protocols and is also able to enforce two-factor authentication for even higher security:

4. Logging

The log file security.log facilitates the detection of security-relevant events. Events from the categories of authentication, user administration, services (e.g. the starting and stopping of sites), and application errors are logged here. You can find this log file in the site directory, and the following shows some examples of typical log entries:

~/var/log/security.log
2024-04-02 19:12:33,891 [cmk_security.service 269382] {"summary": "site stopped", "details": {}}
2024-04-03 08:55:46,480 [cmk_security.service 5652] {"summary": "site started", "details": {}}
2024-04-03 09:21:18,830 [cmk_security.auth 8798] {"summary": "authentication succeeded", "details": {"method": "login_form", "user": "cmkadmin", "remote_ip": "127.0.0.1"}}
2024-04-03 15:41:20,499 [cmk_security.user_management 8798] {"summary": "user created", "details": {"affected_user": "myuser", "acting_user": "cmkadmin"}}
2024-04-03 16:36:04,099 [cmk_security.auth 1882076] {"summary": "authentication failed", "details": {"user_error": "Incorrect username or password. Please try again.", "method": "login_form", "user": "myuser", "remote_ip": "127.0.0.1"}}
2024-04-03 18:19:05,640 [cmk_security.application_errors 1882076] {"summary": "CSRF token validation failed", "details": {"user": "cmkadmin", "remote_ip": "127.0.0.1"}}

Each line is structured as follows:

  • Date and time (local time) when the log entry was created.

  • Security domain (e.g. cmk_security.auth ) and process ID.

  • The message itself as a summary (summary) and in detail (details), each in JSON format. The content of the details varies depending on the security domain.

Note that the contents of the log file may change in the future, for example due to the addition of additional security domains, logged events or the information provided in the details.

On this page