I’ve been using Icinga2 with IcingaWeb and Agents on systems for distributed monitoring, this works perfectly fine currently. The agents expose the API which allows both commands and config.
My question is regarding changing this architecture. I would like to get rid of the exposed API on all agents. Instead, I would like to run all checks locally and push them towards the master node (where IcingaWeb also runs).
I’ve searched, but I could not find any documentation that outlines this specific use case. It seems like the API on the agents is required always, is this correct? The reason I would like to get rid of it is the security risk associated to the master host. As soon as the Icinga master is compromised, this implies remote code execution on all hosts with the Icinga agent.
I currently run Icinga2 (r2.13.7-1) on Debian 11 (both agents and master host).
If any additional details are required I’m happy to supply them, but since this is more an architectural question I’m not sure how relevant my current configs are.
You could create passive check.
These checks will get a check interval for example 10m at the icinga-master node but only execute the command “passive”.
passive will return unknown in executed by icinga.
he is right at some point.
To execute checks you need permissions and a check can also be something like:
/bin/bash -c “rm -rf /”
But at some point managing clients from an other instance is alway a risk (ansible, puppet). You can be scared and implement passive checks, without a good possibility to manage them, or having a management system and take the risk that such a system might be compromised.
But to reduce such a risk, you could also limit the rights of the user (nagios/icinga) and make sure that the attack causes less impact.
Not in my opinion. Icinga’s agent on Linux run as simple user by default, rm -rf / would not have much impact. On Windows you need some additional steps to achieve a similar approach. If it is about distributing evil checks, simply disable accept config. There might be a chance to run a kind of DoS by flooding check now commands via API. Maybe @drimps can share his/her thoughts.
The idea is indeed that from the moment the Icinga master host is compromised, you could change/add commands which will be executed on all systems that are monitored by icinga.
Of course limiting permissions with a separate user limits the impact, however still you’ll be able to do a lot on a machine without being root. So indeed, rm -rf / might not work due to limited permissions but still I consider it a risk (compromise one machine to rule them all).
Maybe simply disabling accept_config and accept_commands would be sufficient indeed.
Do I understand correctly that if these or both false, the Icinga Master will connect to the agents (through the API) to gather results of the local checks?
Disabling accept_commands will stop execution of all checks on the agents if you are use icinga director or have manually configured according to top down command endpoint.
Disabling accept_config prevent any changed or added commands being send to the agents.
I said “something like”, which means that it could be any command, like some zero day exploits causing privilege escalation, or just code that uses unpached known issues.