Securing NetSaint


Introduction

This is intended to be a brief overview of some things you should keep in mind when installing NetSaint, 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 NetSaint, please drop me a note at netsaint@netsaint.org

Do Not Run NetSaint as Root!

NetSaint doesn't need to run as root, so don't do it. Even if you start NetSaint 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 netsaint_user and netsaint_group directives in the main config file.

Enable External Commands Only If Necessary

By default, external commands are disabled. This is done to prevent an admin from setting up NetSaint 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/netsaint/var/rw directory. You only want a few users (probably only NetSaint and the web server) to have permissions to write to the command file. A FAQ 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 NetSaint do you?

Use Full Paths In Command Definitions

When you define service checks, event handlers, notification commands, etc in command definitions, 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 host 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 NetSaint distribution for an example of how to define $USERn$ macros.