...
| Status | ||||
|---|---|---|---|---|
|
Table of Contents
Communication between Server and Agent
- Default
Classical operating systems: Checkmk Server triggers Checkmk Agent on Port 6556
An agent reads no data from the network — full stop.Consequently, it is quite impossible that an attacker could sneak any type of command or script element over the monitoring port 6556
- Network devices and other hardware: SNMP v1/v2/v3
- Secure
- Encrypt the agent output → https://docs.checkmk.com/latest/en/agent_linux.html#encryption
- TLS connection between server and agent → https://checkmk.com/werk/14089
- Restrict access over IP addresses (https://docs.checkmk.com/latest/en/agent_linux.html#security)
- Can be solved with xinetd and systemd
- Invoke agent over ssh https://docs.checkmk.com/latest/en/agent_linux.html#ssh
- Push the data from the agent to the server. (https://docs.checkmk.com/latest/en/datasource_programs.html)
- Dedicated CA for agent certificates → https://checkmk.com/werk/14965
Password Store
The password store holds the passwords you use in your checks and special agents in a central place. Please note that this password store is no kind of password safe. Your passwords will not be encrypted.
All the passwords you store in your monitoring configuration, including this password store, are needed in plain text to contact remote systems for monitoring. So all those passwords have to be stored readable by the monitoring.
- With Checkmk 2.1, the password store is storing the passwords obfuscated, which still is no encryption → https://checkmk.com/werk/13633
User and role concept
Within Checkmk, you can define your own roles and restrict them to specific permissions (https://docs.checkmk.com/latest/en/wato_user.html#roles)
Distributed Monitoring
Distributed Monitoring
- Communication from the central to a remote site via TLS is possible and recommended.
- Centralized configuration via HTTPS is possible and recommended
- Restriction of IP addresses allowed querying remote sites is possible and recommended
- If your remote site is not directly accessible via the central Server, you can push the data from the remote to the central Server (https://docs.checkmk.com/latest/en/distributed_monitoring.html#cmcdump)
- This is only for viewing. No actions/Notifications are possible on the central site for this remote site
Distributed Notifications
- The slave and (notification-)master notification spoolers communicate with each other via TCP. Notifications are sent from slave to master. The master acknowledges to the slaves that the notifications have been received, which prevents notifications from being lost even if the TCP connection is broken.
There are two alternatives for the construction of a TCP-connection:
A TCP-connection is configured from the central site to a remote site: Here, the remote site is the TCP-server.
A TCP-connection is configured from a remote site to the central site: Here, the central site is the TCP-server.
- Notification spooler connections can be encrypted with Checkmk 2.1 → https://checkmk.com/werk/13610
...