Nagios Support Forum

I'm implementing XI for the first time in our production environment, and I'm getting push back from our security team on the sudoers entries that NagiosXI requires. I'm listing them at the bottom of this post, having removed the backwards compatibility entries (we're using a Centos 7 based scripted installation).

So far I've found that the self-monitoring status entries for monitoring engine and graphing engine give faults, that the Core Config utility is not functional because/and restarts from the web utility are not possible. I believe all of that is related to the last entry below (/usr/local/nagiosxi/scripts/manage_services.sh *). Is there anything I can do to work around the sudo access for these and other utilities that are relying on sudo? I tried (at security's suggestion) putting a bash script running simply $@ without permission elevation earlier in the $PATH - this worked for the status issues, but the Core Config utility still fails. If I had to run some sort of job command line as root to apply config, but could offer the option of modifying config through the Core Config utility that would be sufficient for my needs?

The crux of the issue is this; Enterprise security doesn't support the idea of running php with elevated privileges and is uncomfortable with running scripts that are user editable with elevated privileges - especially when they are configured to accept arguments. I've got to admit, I see their point - especially when one of those users is the web daemon owner. I have a meeting scheduled with them Monday afternoon to try and restate my case - and I'm going to try to make any concessions they require to get whatever subset of sudo entries in place that I can - but it would be exceedingly helpful to know what other people are doing to work around these security considerations before I walk into that meeting.

User_Alias NAGIOSXI=nagios
User_Alias NAGIOSXIWEB=apache
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/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 *

Nagios XI requires the sudoers settings. Removing or modifying them would lead to a Nagios XI instance that is NOT supported.

Trying to work with our security team to get these changes implemented in a way that makes everyone comfortable, I had some specific follow up questions asked of me - I'd love any insight you can provide. I've included some of my thoughts on possible responses...

1) are these commands required to execute on the nagios server, or on a server that the nagios application is monitoring?
- I believe the answer here is that it’s the Nagios XI server. The reason he’s asking is for sudoers syntax. The requested entry is (example below) allowed on all hosts by the sudoers syntax:
o NAGIOSXI ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/send_to_nls.php *
- And we want to modify it to read as follows: I’m wondering if this is acceptable (will we still be supported?):
o NAGIOSXI NAGIOSXI_HOSTNAME = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/send_to_nls.php *

2) are these commands intended to run interactively or is it executed by the application?

3) can we restrict permissions on /usr/local/nagios ( or wherever nagios is installed ) to 770 or 700 or 750
- I believe the answer to this is yes, 750 is fine, with the caveat that nagios and apache are both members of the group owning the directory – correct?
- So would this work (I believe it will)? Would this be supported?:

o [root@NAGIOSXI_HOSTNAME nagios]# id apache
o uid=48(apache) gid=48(apache) groups=48(apache),1003(nagiostest),1005(nagios),1006(nagcmd)
o [root@NAGIOSXI_HOSTNAME nagios]# id nagios
o uid=1005(nagios) gid=1005(nagios) groups=1005(nagios),1006(nagcmd)
o [root@NAGIOSXI_HOSTNAME nagios]# ls -ald /usr/local/nagios
o drwxr-x---. 8 root nagios 73 Aug 17 18:01 /usr/local/nagios

4) do the php scripts open and listen on any ports?
- Specifically these two php scripts:
o /usr/local/nagiosxi/scripts/components/autodiscover_new.php *
o /usr/local/nagiosxi/scripts/send_to_nls.php *

despeyre wrote:Trying to work with our security team to get these changes implemented in a way that makes everyone comfortable, I had some specific follow up questions asked of me - I'd love any insight you can provide. I've included some of my thoughts on possible responses...

1) are these commands required to execute on the nagios server, or on a server that the nagios application is monitoring?
- I believe the answer here is that it’s the Nagios XI server. The reason he’s asking is for sudoers syntax. The requested entry is (example below) allowed on all hosts by the sudoers syntax:
o NAGIOSXI ALL = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/send_to_nls.php *
- And we want to modify it to read as follows: I’m wondering if this is acceptable (will we still be supported?):
o NAGIOSXI NAGIOSXI_HOSTNAME = NOPASSWD:/usr/bin/php /usr/local/nagiosxi/scripts/send_to_nls.php *

2) are these commands intended to run interactively or is it executed by the application?

3) can we restrict permissions on /usr/local/nagios ( or wherever nagios is installed ) to 770 or 700 or 750
- I believe the answer to this is yes, 750 is fine, with the caveat that nagios and apache are both members of the group owning the directory – correct?
- So would this work (I believe it will)? Would this be supported?:

o [root@NAGIOSXI_HOSTNAME nagios]# id apache
o uid=48(apache) gid=48(apache) groups=48(apache),1003(nagiostest),1005(nagios),1006(nagcmd)
o [root@NAGIOSXI_HOSTNAME nagios]# id nagios
o uid=1005(nagios) gid=1005(nagios) groups=1005(nagios),1006(nagcmd)
o [root@NAGIOSXI_HOSTNAME nagios]# ls -ald /usr/local/nagios
o drwxr-x---. 8 root nagios 73 Aug 17 18:01 /usr/local/nagios

4) do the php scripts open and listen on any ports?
- Specifically these two php scripts:
o /usr/local/nagiosxi/scripts/components/autodiscover_new.php *
o /usr/local/nagiosxi/scripts/send_to_nls.php *

Hi @despeyre,

First, let me say that I understand the position that you're in, and how frustrating it can be. Hopefully the answers I can give you are good enough that you can move forward with your installation process.

Before I start with answering questions, it looks to me like you're concerned primarily with the autodiscover_new and send_to_nls scripts. These are both fairly niche, and you may not need to use them at all in your environment. If that's the case, you may just want to disable them.

send_to_nls.php is intended for integration with Nagios Log Server - specifically, for forwarding your Nagios XI Audit Log into an NLS cluster. If you don't have an NLS cluster, or if you don't think you'll use it to monitor Nagios XI, then you don't need this.

autodiscover_new.php is part of the Autodiscovery component, which essentially scans portions of your network for devices that you may be able to monitor. If you anticipate that you'll be adding devices mostly manually (or at least, that you know exactly which devices you'll want to monitor), you probably won't need this. Based on what your security team has said so far, I doubt they'll want you to make use of this functionality (since you're effectively portscanning your own network). So you may be able to disable this script as well.

1) Correct, these commands only run on the Nagios XI server. If there are commands that need to be run under sudo on a remote host, those will be configured separately when you install an agent (e.g. NRPE, NCPA) on that host.

2) It's a mix of both. For the most part, you won't run the scripts yourself from the terminal environment, unless one of our support technicians specifically asks you to do so. You may end up running some of them via submitting forms in the application, but even this is mostly restricted to administrator accounts.

3) This is kind of complicated. My personal experience is that yes, you can do this, and at least the core part of the application (monitoring and alerting) shouldn't be affected. However, there are a lot of individual components that perform unique tasks, and I haven't personally tested all of them.

Also, a lot of scripted environments (python, php, perl) don't always seem to handle secondary group permissions correctly, so even a user with "correct" permissions in a terminal environment may not be able to interact properly when running PHP or one of these other runtimes.

As far as "supported configurations" are concerned, I just want to clarify that our support technicians will always try to assist you with keeping your environment running. However, if they narrow the issue down to these permissions changes, and they can't find a workaround, that may be a dead end. So, it won't be a supported configuration, but you'll still be able to ask our support team for help, and you should usually get it.

4) Neither of these scripts listens for a TCP connection. As mentioned above, send_to_nls configures rsyslog to forward a log file to a a Nagios Log Server cluster, and autodiscover_new runs a network scan.
For the rest of the scripts, I looked at them briefly and can't see a reason that they would listen for connections, but I didn't read over each one to verify.

Let me know if you need further clarification or discussion on any of these points.

Swolf,

Thank you very much, this response arms me appropriately to submit my sudoers update request today. I really appreciate you taking the time to respond as thoughtfully as you have. I'm now fairly confident that we can make this work without just petulantly stamping our feet and whining at security that "the vendor says we have to or they won't support us".

@despeyre, is it OK to close this topic now or you have any further questions? Thanks!

You are welcome to close this topic, thanks again.