Dieser Artikel wird nicht mehr gepflegt und ist unter Umständen nicht mehr gültig!
1. Security Considerations
2. Security by Architecure
With Check_MK we try to make several things different compared to other existing monitoring solutions. In the Nagios world it is a common setup that the monitoring host is the system which asks the monitored systems for their status information to get the current state for example using NRPE, SSH or proprietary protocols. In most cases, the monitoring host needs to have several credentials to access the monitored systems, for example SSH-keys for accessing hosts or database credentials to get data from a database to be monitored. These approaches have in common, that you connect to the target system, authenticate with it and issue some sort of command to get the information you want. This might be a problem, by design, because there might be bugs in the code which processes your request which then might allow a possible attacker to get access to the system.
When using Check_MK you normally install an agent on the target system which does not receive any input data from the monitoring system. There is not a single byte which can be inserted while fetching the monitoring data from the agent. So there is no chance to inject anything - by architecture.
To use the example above, when you like to monitor an Oracle database, the Check_MK approach is to perform the communication with the database on the database server itselfs. The monitoring server connects to the Check_MK agent on the database server, the agent knows how to connect to the database and which data to fetch, fetches the data and outputs the answer to the monitoring server. The database connection and authentication is only done on the database server, the database does not need to be directly reachable over the network for the monitoring server.
You see, in such a setup the monitoring server is still a critical system, because it gathers critical information for you, but there is a lot smaller chance for an attacker to get deeper into monitored systems when using Check_MK.
3. Best Practices to Secure your Installation
Besides our task to ensure a secure software, there are several things which can or should be done to increase the security of a Check_MK setup. The following list is a non complete list of things you should consider to realize for your Check_MK installation. It is totally individual whether or not you should realize these things, e.g. dependending on the installation you have and the network you are operating in.
4. Reporting Security Issues
Please let us know when you discovered any security related problems affecting Check_MK. If you discovered a real security issue which might affect other users of Check_MK, we please you to first share the information with us and give us some time to analyze and fix the issue. When a fixed release is available it is totally ok, from our point of view, to publish such security issues. We will always try to check out these problems as soon as possible. But please keep in mind that we can not always take care about everything immediately.
Please send us an e-mail to our security address.
5. Information about Security Issues
You can find security related changes to Check_MK in our list of werks. Security related changes are marked as Security Fix in this list.
You can also subscribe to the security werk related mailinglist to get informed about these changes immediately. Another option is to subscribe to the announcement mailinglist to get infomed once official releases are available. The announcement mails contain the changelog of the releasese, where security related changes are prefixed with the text SEC:.