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.
Nagios and the woes of hardening
Re: Nagios and the woes of hardening
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
102:106::/var/spool/nagios:/bin/bash
to
nagios
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
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
to
nagios
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