Chapter 4. Security

Table of Contents

4.1. General comments
4.2. Risks arising from running MonAMI
4.2.1. Information distributed too readily.
4.2.2. Passwords being stored insecurely
4.2.3. A bug in MonAMI is exploitable
4.2.4. MonAMI tricked into providing a Denial-of-Service attack

When running any software some consideration must be made towards the security impact of that software. MonAMI, like any software, will have an effect on a machine's security risk. This section aims to give a brief overview of the likely security risks and what can be done to to reduce them.

4.1. General comments

It is worth pointing out that running MonAMI does not, in and of itself, provide any greatly increased security risk. There are no known vulnerabilities in the software and the dangers described here are common for any software that attempts the monitoring activity MonAMI undertakes.

Although this section gives information on running MonAMI it is not, nor can it be, exhaustive. Many of the security issues will arise from site-specific details so a full analysis can only be done in knowledge of the MonAMI configuration in use along with other factors: technical factors (firewalls, network topology, information storage configuration, ..), usage policies (who else uses the machines MonAMI runs on?) and other issues ("what information is considered secret?").

Security as a process, not a check list.

One cannot express security as solely a list of things to check or actions to undertake; this includes the comments in this section. Best-practice (once established) is a guide: a minimal set of activities or configuration. There will always be aspects too general (e.g. management processes) or too site-specific (e.g. has software X been configured with option Y disabled) to be included within best-practice. Security will always require thinking, not just following procedure.

Security in depth.

One cannot rely on any one technology or process to fully protect a site. Limitations in software (or understanding of that software) may lead to a vulnerability in what is thought to be a perfectly protected system. Moreover, local policies might require running software so there are additional vectors of attack: risks might have to be balanced against inconvenience.

An effective way of reducing the impact of security exposure is to provide multiple barriers one must penetrate before a system is compromised. Although each barrier may be imperfect, each will provide a sufficient challenge that either the attacker will give up (and look for an easier target) or the attack is discovered and counter-measures taken.

To illustrate this, consider the mysql monitoring plugin (Section 3.4.8, “MySQL”). This plugin needs a MySQL account with which it can log into the database server. The login credentials could be any valid MySQL user. Although strongly discouraged, this could be the MySQL root user, which has all administrative privileges.

Whatever MySQL user is used, one would try to ensure no one can discover the username-password pair. But, if MonAMI is using a MySQL user with no unnecessary privileges, should someone discover the username-password pair they would gain little without subsequently defeating the user-privilege separation within the MySQL server. The barriers they would have to overcome would be:

  1. gaining access to the machine (presumably as some user other than user monami)

  2. defeating the server's file-system permissions (to read the MySQL password)

  3. defeat the MySQL server permissions (to gain privileges)

Each barrier is formidable yet potentially vulnerable (either through software bug or from being misconfigured). Together, the steps required to obtain full access to the database is much harder, sufficiently hard that an attacker would most likely use some other route.