This section describes some explicit risks that one encounters when running MonAMI. For each section, there are a few suggested things to check. The checks are hopefully straightforward; verifying these items should greatly reduce the risk.
As stated earlier, a list of checks should not be confused with having a secure system. Following best practise should eliminate or greatly reduce the impact of these risks, but the user should be aware of them and plan accordingly.
Sending out information is MonAMI's modus operandi. However, some information is dangerous or sensitive.
Information might be sensitive for any number of reasons. Monitoring might give an indication of capacity or utilisation, or the broad direction in which activity is going. Such information might be sensitive for business. Thieves might target rooms in which computers have been idle for some time.
Dangerous information is not sensitive now, but might be sensitive in the future. Information that indicates which software and software version is being run could be correlated against databases of known vulnerabilities. Distributing software version numbers is the most obvious example of this, but other information might indicate which software is being run.
Check that...
information being sent is not sensitive,
the information systems are sufficiently secure,
no information that might identify which version of some software is being run is distributed where it might be discovered.
The danger here is that someone discovers the username-password pair needed to gain access to some system. The most likely cause is inappropriate file-system permissions.
Using the "security in depth" concepts, passwords should be created with limited functionality, ideally with only sufficient privileges to retrieve monitoring information.
Many password-based authentication systems have the option of restricting from which hosts it will accept credentials. By limiting login via monitoring credentials to be only from the MonAMI host (which is perhaps "localhost"), any stolen username-password pair is useless unless the MonAMI host is also compromised.
Check that...
the MonAMI configuration files are owned by user monami and have read-only permission for that user and no read permission for anyone else.
that user-password pairs used by MonAMI have limited functionality and (ideally) are not shared with other users.
wherever possible, the monitoring username-password pair should be restricted so it only functions from the machine on which MonAMI is running.
Any software can have bugs; MonAMI is no exception. Bugs range from the annoying (doesn't work as specified) through to the dangerous. Perhaps the most dangerous is if, through MonAMI, a remote user can control files or run commands on the local machine.
Although there are no known bugs in MonAMI, it is prudent to assume they exist and to reduce the impact of them. For this reason, MonAMI supports "dropping root privileges" to switch to running as some other user. We recommend that this feature be used and the other user be distinct (i.e. not to use some generic user "daemon" or "nobody"). Someone exploiting MonAMI (should that be possible), would then only gain the use of an unprivileged user.
To achieve monitoring activity, certain MonAMI configurations accepts some network traffic. Wherever possible, the traffic to MonAMI should be firewalled. Only network traffic from trusted machines can reach MonAMI.
Check that...
the monamid process is running as an unprivileged user,
the unprivileged user cannot cause trouble,
network traffic to MonAMI's ports is sufficiently protected; for example, it passes through a suitably configured firewall.
Monitoring impacts on the service that is to be monitored. If MonAMI is run such that it attempts to gather information with high frequency, then it might impact strongly on the service, even providing a denial-of-service attack.
If properly configured, monitoring that is triggered internally (see Section 3.6.2, “Timed sample targets”) should pose no problem. On-demand monitoring (for example, the ksysguard plugin, Section 3.5.6, “KsysGuard”) could potentially request monitoring data sufficiently quickly to saturate MonAMI-core. This might lead to problems with MonAMI and the services being monitored. To reduce this, suitable caches can be defined (see Section 3.3.2, “The cache attribute”) and access to on-demand monitoring should be limited through correctly configured firewalls.
Check that...
suitable cache values are specified, especially for any on-demand monitored targets.
any on-demand monitoring network port is suitably protected; for example, by using a suitably configured firewall.
the MonAMI configuration files are not world-writable and that any auxiliary configuration directories (as defined in a config_dir attribute) does not permit normal users to write additional monitoring configuration.