In this recipe, we'll explore the use of basic authentication for the Nagios Core web interface, probably the single most important configuration step in preventing abuse of the software by malicious users.
By default, the Nagios Core installation process takes the sensible step of locking down the CGI scripts in its recommended Apache configuration file with standard HTTP authentication for a default user named nagiosadmin, with full privileges.
Unfortunately, some administrators take the step of removing this authentication or never installing it despite the recommendations in the installation guide. It's a good idea to install it and keep it in place even on private networks, especially if the server running Nagios Core is open to the Internet in any way (generally not advised).
Keeping authentication on is useful not just because of the security benefits, but also because it allows you to set up basic access control, allowing certain users permission to read state or run commands on certain resources, but not on others. It also has other more subtle benefits, such as recording the names of users that carry out actions for logging purposes.
You'll need access to the backend of a Nagios Core server with version 4.0 or greater to change its configuration and restart it. You'll also need a functioning web interface. Much of this recipe will assume that the web interface is running on the recommended Apache HTTPD server; you may also need to be able to edit this configuration. Some familiarity with Apache HTTPD is assumed here; the documentation available online regarding Apache is excellent if you need to consult it (https://httpd.apache.org/docs/).
This recipe will be covered in two parts: we'll first ensure that all the recommended settings are in place to properly require authentication and we'll then demonstrate how to add a user helpdesk with read-only permissions for the server's web interface; they will be able to read the states of all the hosts and services, but the user will not be able to (for example) issue commands or submit passive check results.
We can ensure that proper authentication is in place for the Nagios Core web interface by following these steps:
- Clear your browser of all cookies and saved authentication data and try to visit the web interface. If your browser does not challenge you for a username or password, as shown in the following screenshot, it's likely that your authentication is disabled or not working correctly:
- On the server, move to the Nagios Core configuration directory and open the
cgi.cfgfile. In the default installation, this is saved in/usr/local/nagios/etc/cgi.cfg:# cd /usr/local/nagios/etc # vi cgi.cfg
- Ensure that the value for
use_authenticationis uncommented and set to1:use_authentication=1
- Ensure that the
default_user_namedirective is commented out:#default_user_name=guest - In the
nagios.conffile in your Apache configuration, verify that the following lines are included to refer to thehtpasswd.usersfile:AuthName "Nagios Access" AuthType Basic AuthUserFile /usr/local/nagios/etc/htpasswd.users Require valid-user
This file should be somewhere in the configuration directory for Apache, for example,
/etc/apache2/conf-available/nagios.conf. If you need to make changes to Apache's configuration to fix this, you will need to restart Apache to have the changes take effect.We can add a read-only user named
helpdeskas given in the next step. - Add the user to the
htpasswd.usersfile using thehtpasswdcommand and the Apache HTTPD password manager. Its location will vary depending on your system; a few common locations for it are/usr/binand/usr/local/apache/bin:# htpasswd /usr/local/nagios/etc/htpasswd.users helpdesk New password: Re-type new password: Adding password for user helpdesk
You may like to make the
htpasswd.usersfile only readable using the web server user if you are concerned about the hashes being stolen by users on the system. - In
cgi.cfg, uncomment theauthorized_for_read_onlydirective and add the newhelpdeskuser to its value:authorized_for_read_only=helpdesk - Add the user to the values of the
authorized_for_all_servicesandauthorized_for_all_hostsdirectives:authorized_for_all_services=nagiosadmin,helpdesk authorized_for_all_hosts=nagiosadmin,helpdesk
Be careful not to confuse these with the
authorized_for_all_service_commandsandauthorized_for_all_host_commandsdirectives.
You don't need to restart the Nagios Core server for these changes to take effect as you normally would with other .cfg files.
With this done, you should only be able to access the Nagios Core web interface with a valid username and password. The default nagiosadmin user created on installation should have full, and the helpdesk user added in this recipe should be able to view host and service states, but it will be unable to issue any commands, such as rescheduling checks or submitting passive check results.
It's important to note that it isn't actually Nagios Core itself that is prompting for the username and password and running the authentication check; this is a function performed by the web server, as specified in the nagios.conf file recommended for installation with Apache HTTPD.
After login, however, Nagios Core uses the permissions defined in the cgi.cfg file each time one of the CGI scripts in the web interface is accessed. It does this to ensure that the user, as authenticated by the web server, has permission to view the requested page or execute the requested action.
We disable the default_user_name directive by commenting it out because this specifies a user that Nagios Core will assume for users who access the CGIs without authentication. This is a potentially dangerous setting and is best avoided in most circumstances, particularly with a server that has publicly accessible addresses.
The following directives in cgi.cfg allow us to refine permissions in order to use the CGIs to form a simple kind of access control list:
authorized_for_configuration_information: In this directive, users are allowed to view configuration information for hosts in the web interfaceauthorized_for_system_information: In this directive, users are allowed to view Nagios's process and performance informationauthorized_for_system_commands: In this directive, users are allowed to run commands that affect the Nagios process, such as shutdowns and restartsauthorized_for_all_services: In this directive, users are allowed to view status information and history for all servicesauthorized_for_all_hosts: In this directive, users are allowed to view status information and history for all hostsauthorized_for_all_service_commands: In this directive, users are allowed to run commands on all services, such as rescheduling checks or submitting passive check resultsauthorized_for_all_host_commands: In this directive, users are allowed to run commands on all hosts, such as rescheduling checks or submitting passive check resultsauthorized_for_read_only: In this directive, users with read-only rights to the CGIs cannot run commands or make comments
Furthermore, the process of refining access per service and per host is done with authenticated contacts, which is demonstrated in the Using authenticated contacts recipe in this chapter. This is highly recommended for teams with mixed responsibilities that require access to the same Nagios Core web interface.
Aside from authentication via Apache HTTPD, it's also often sensible to limit the IP addresses that are allowed access to the instance using Order and Allow Apache directives. We could extend the nagios.conf file loaded by Apache using this code snippet:
<Directory "/usr/local/nagios/sbin">
Options ExecCGI
AllowOverride None
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
<RequireAll>
Require valid-user
Require ip 192.0.2.1
</RequireAll>
</Directory>This would only allow 192.0.2.1 to access the CGIs and the user will still have to provide a username and password. The configuration will deny access with 403 Forbidden to anyone else. Similarly, we could arrange to only allow connections to HTTPS, perhaps with an SSLRequireSSL directive; in general, we can configure Apache to carefully control the access to CGIs, let alone abusing them.