Introduction

This is intended to be a brief overview of some things you should keep in mind when installing Nagios, so as to not set it up in an insecure manner. This document is new, so if anyone has additional notes or comments on securing Nagios, please drop me a note at nagios@nagios.org

Do Not Run Nagios As Root!

Nagios doesn't need to run as root, so don't do it. Even if you start Nagios at boot time with an init script, you can force it to drop privileges after startup and run as another user/group by using the nagios_user and nagios_group directives in the main config file.

If you need to execute event handlers or plugins which require root access, you might want to try using sudo.

Enable External Commands Only If Necessary

By default, external commands are disabled. This is done to prevent an admin from setting up Nagios and unknowingly leaving its command interface open for use by "others".. If you are planning on using event handlers or issuing commands from the web interface, you will have to enable external commands. If you aren't planning on using event handlers or the web interface to issue commands, I would recommend leaving external commands disabled.

Set Proper Permissions On The External Command File

If you enable external commands, make sure you set proper permissions on the /usr/local/nagios/var/rw directory. You only want the Nagios user (usually nagios) and the web server user (usually nobody) to have permissions to write to the command file. If you've installed Nagios on a machine that is dedicated to monitoring and admin tasks and is not used for public accounts, that should be fine.

If you've installed it on a public or multi-user machine, allowing the web server user to have write access to the command file can be a security problem. After all, you don't want just any user on your system controlling Nagios through the external command file. In this case, I would suggest only granting write access on the command file to the nagios user and using something like CGIWrap to run the CGIs as the nagios user instead of nobody.

Instructions on setting up permissions for the external command file can be found here.

Require Authentication In The CGIs

I would strongly suggest requiring authentication for accessing the CGIs. Once you do that, read the documentation on the default rights that authenticated contacts have, and only authorize specific contacts for additional rights as necessary. Instructions on setting up authentication and configuring authorization rights can be found here. If you disable the CGI authentication features using the use_authentication directive in the CGI config file, the command CGI will refuse to write any commands to the external command file. After all, you don't want the world to be able to control Nagios do you?

Use Full Paths In Command Definitions

When you define commands, make sure you specify the full path to any scripts or binaries you're executing.

Hide Sensitive Information With $USERn$ Macros

The CGIs read the main config file and object config file(s), so you don't want to keep any sensitive information (usernames, passwords, etc) in there. If you need to specify a username and/or password in a command definition use a $USERn$ macro to hide it. $USERn$ macros are defined in one or more resource files. The CGIs will not attempt to read the contents of resource files, so you can set more restrictive permissions (600 or 660) on them. See the sample resource.cfg file in the base of the Nagios distribution for an example of how to define $USERn$ macros.

Strip Dangerous Characters From Macros

Use the illegal_macro_output_chars directive to strip dangerous characters from the $HOSTOUTPUT$, $SERVICEOUTPUT$, $HOSTPERFDATA$, and $SERVICEPERFDATA$ macros before they're used in notifications, etc. Dangerous characters can be anything that might be interpreted by the shell, thereby opening a security hole. An example of this is the presence of backtick (`) characters in the $HOSTOUTPUT$, $SERVICEOUTPUT$, $HOSTPERFDATA$, and/or $SERVICEPERFDATA$ macros, which could allow an attacker to execute an arbitrary command as the nagios user (one good reason not to run Nagios as the root user).