Nagios and the woes of hardening

This support forum board is for support questions relating to Nagios XI, our flagship commercial network monitoring solution.
Post Reply
werly1988
Posts: 1
Joined: Fri Jun 28, 2024 2:12 am

Nagios and the woes of hardening

Post by werly1988 »

Hello all,

I wanted to find out how many Sysadmins are running Nagios XI or Nagios Core in their enterprise? Then see if anyone took on the task of hardening the underlying OS with either CIS or STIG benchmarks?

A company I work for recently purchased Nagios XI and was unaware (nor I) that they do not support FIPS, fapolicyd, SELinux, or even antivirus being loaded/enabled on the system during install or product operation. (Usually technologies in builds that are “restricted” such as this, are considered an appliance and come in an ova or physical system, but not this product. You install the OS. You then install the product.)

My challenge is the company I work for, follows very strict security controls, and I don’t blame them. I’m having a hard time with any vendor who supplies a product that requires the entire OS be open in 2024, this isn’t 2010 anymore.

Nagios basically said I should get a security waiver, which I know isn’t going to happen, but on the other side my company doesn’t want to feel the waste of tens of thousands of dollars in products either.

Does anyone have any recommendations on hardening Nagios installs? I have seen their documentation on hardening Nagios itself, which is fine (SSL, Two factor authentication, and etc), but defense in depth is a requirement and they missed the mark.
gregbeyer
Posts: 174
Joined: Fri Sep 11, 2020 2:13 pm

Re: Nagios and the woes of hardening

Post by gregbeyer »

I too stumbled into the requirement for NO security policies, when I attempted to use the migrate server wizard last year. And their answer to me was also "get a waiver". I think the guidance to turn off all security on a server lazy and foolhardy. Initially, Nagios tried to just wash their hands of dealing with security issues.

I persisted, finally got this specific guidance on what different components of XI need to run. It may be helpful to you, and may be acceptable in your environment. To mitigate these measures, perhaps you want to limit access to the Nagios server to specific IP addresses/ranges/subnet Of course, it reduces XI's value proposition if it has to be locked down so much that non-priviledged users can't even view it.

We use AD authentication for Nagios accounts (see LDAP Integration in Admin), better than local account. XI's LDAP / AD integration leave much to be desired, but we found a way to make it work. XI Also does not support SSO/CAS so 2FA which is required for everything else around here can't be used on Nagios.

Nagios XI is really behind the curve as far as modern security practices are concerned. <scratches head> Do they want to be the next SolarWinds? Admittedly, SW was a software supply chain attack, but once the monitoring platform was pwned, the enterprises that used SW were pwned.

/etc/access/conf -- include the + : nagios : ALL line

# access.conf-compute
<snip>
+ : nagios : ALL
- : ALL : ALL

Pardon the formatting -- that's what came across in my ticket response.

Post Details:
It looks like the server is not a clean install of Redhat but a corporate install that has security policies that are causing nagios to not run correctly.

I do suggest creating a new operating system install without any security policies so that ensures that what is done on the existing server will not effect the XI install and functionality.

The profile build failure and the checks failing for localhost are typically caused by changes done to the /etc/sudoers file or a PAM policy changed to not allow the nagios user account to run the checks because the PAM policy is blocking it from functioning.

Talk to your security team to see if they added or changed a PAM policy in the server.

These are the messages from the log files that show a PAM policy is blocking the nagios process.
PAM account management error: Permission denied

You can also look in the /var/log/secure file and there may be more details to look at.

The Profile Build failure. Here are instructions for updating the /etc/sudoers file to the settings needed for XI.

Make sure the following settings are in the /etc/sudoers file and if they are missing or not updated, add them to the file.
User_Alias NAGIOSXI=nagios
User_Alias NAGIOSXIWEB=apache NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios start NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios stop NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios restart NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios reload NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios status NAGIOSXI ALL = NOPASSWD:/etc/init.d/nagios checkconfig NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd start NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd stop NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd restart NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd reload NAGIOSXI ALL = NOPASSWD:/etc/init.d/npcd status NAGIOSXI ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/components/autodiscover_new.php * NAGIOSXI ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/send_to_nls.php * NAGIOSXI ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/migrate/migrate.php * NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/components/getprofile.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/upgrade_to_latest.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/change_timezone.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_services.sh * NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/reset_config_perms.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_ssl_config.sh * NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/backup_xi.sh * NAGIOSXIWEB ALL = NOPASSWD:/etc/init.d/snmptt restart NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/tail -100 /var/log/messages NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/tail -100 /var/log/httpd/error_log NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/tail -100 /var/log/mysqld.log NAGIOSXIWEB ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/components/autodiscover_new.php * NAGIOSXIWEB ALL = NOPASSWD:/usr/local/nagiosxi/scripts/components/getprofile.sh NAGIOSXIWEB ALL = NOPASSWD:/usr/local/nagiosxi/scripts/repair_databases.sh NAGIOSXIWEB ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_services.sh *

Also, the home folder for the nagios account needs to be changed in the /etc/passwd file so edi that file and change it from
nagios:x:102:106::/var/spool/nagios:/bin/bash
to
nagios:x:102:106::/home/nagios:/bin/bash

Save the change.

The PAM security policy blocked the server migration tool because I do not see the files that are created when it runs.

To fix the Migration status in the XI interface, run the following in a root ssh session in the server.
mysql -uroot -pnagiosxi nagiosxi -e "UPDATE xi_options SET value = 0 WHERE name = 'migration_running';"
Then, after fixing the PAM policy, try running the Migrate Server tool.

Thank You.

Best Regards,

Customer Support Team, Nagios
Post Reply