NRPE security

[mhixson2]

Hello,

We are new to Nagios XI and through various conversations, a training session, and lots of questions and research, we landed on using the NSClient++ (NSCP-0.4.3.143-x64.msi) with NRPE for our Windows hosts.

Along the way, we've trimmed and customized nsclient.ini until we landed on the configuration below.

Code: Select all

[/settings/default]
;A comma separated list of allowed hosts. You can use netmasks (/ syntax) or * to create ranges.
	allowed hosts=[IP.OF.NAGIOS.SERVER]

[/modules]
;Various system related checks, such as CPU load, process state, service state memory usage and PDH counters.
	CheckSystem=1
;Various file and disk related things.
	CheckDisk=1
;Listens for incoming NRPE connection and processes incoming requests.
	NRPEServer=1
;Execute external scripts
	CheckExternalScripts=enabled

[/settings/NRPE/server]
	allowed ciphers=ADH
;Allow characters in command definitions
	allow nasty characters=1
;Allow -a arguments in command definitions
	allow arguments=1

[/settings/external scripts]
;Allow arguments to be passed to external scripts
	allow arguments=1

[/settings/log]
;Enable debug level logging
	;file name = nsclient.log
	;level = debug

All is working well so far, but security has become the topic around here. Specifically around the vulnerabilities raised by setting both "allow nasty characters" and "allow arguments" in the NRPE section of the config to true. This article directly notes serious vulnerability concerns with this configuration. That data is over a year old, so I'm hoping things have changed. My questions are:

1. Have things changed? Are these vulnerabilities still around?
2. The Windows hosts we are monitoring are public servers that are behind an external firewall. They are also separated from the rest of our environment by an internal firewall that only has port 5667 open from the monitored server to the Nagios server. What kind of exploits, if any, are we open to with this configuration?
3. For security concerns alone, should we be considering another agent/server/check? NCPA? check_nt?

Thanks!
Mike

[jdalrymple]

That exploit is targeted on Linux hosts, not Windows hosts. I'm not saying for sure that it doesn't apply, but it sounds like Windows is the platform you're concerned with. I'd encourage you to try to recreate the attack in your windows environment.

That subject case is a Linux host, not a Windows host. I'm not saying for sure that it doesn't apply, but it sounds like Windows is the platform you're concerned with. I'd encourage you to try to recreate the attack in your windows environment since the NRPE daemon on nsclient++ is 100% unrelated to the NRPE daemon distributed by Nagios.

Regardless, proper security of your nsclient.ini, network and the login security of your Nagios server makes that vulnerability a non-issue.

** EDIT ** -- replace the first paragraph for clarity's sake

[tmcdonald]

The problem with that article is that we make it very clear ourselves that allowing arguments makes your NRPE install vulnerable.

What you are doing when you allow arguments is, on the surface, making configuration easier. Instead of defining warning and critical levels on the remote machine's config, you can define them in Nagios. That's great and all, but under the surface you are allowing basically any arguments regardless of their intent. So in a Linux example, your intent might be to have a check that runs check_load and pass in -w 2 -c 5 from Nagios, but nothing is stopping you from passing in -w 2 -c 5 && rm -rf / and hosing your system.

As such, I can't call this a vulnerability as much as I can call it a dangerous feature.

So to answer your questions directly:

1.) The feature is still around, but with arguments disabled it is not exploitable (barring, of course, any 0-day attacks)
2.) Ideally you are only letting certain IP addresses query port 5667 (did you mean to say 5666?), so any attacks (short of an exploit on your firewall) would need to come from the Nagios machine. That being said, if you have arguments enabled then you will still face the possibility of malicious arguments.
3.) Disabling arguments will make NRPE more secure, but increase the configuration time required. Security never simplifies anything, and NRPE is no exception. NCPA is only a bit more locked down (requiring an auth token), but the argument parsing is somewhat broken at the moment.

[mhixson2]

That subject case is a Linux host, not a Windows host. I'm not saying for sure that it doesn't apply, but it sounds like Windows is the platform you're concerned with. I'd encourage you to try to recreate the attack in your windows environment since the NRPE daemon on nsclient++ is 100% unrelated to the NRPE daemon distributed by Nagios.

Regardless, proper security of your nsclient.ini, network and the login security of your Nagios server makes that vulnerability a non-issue.

Yes, the far majority of our servers are running Windows, but we have a handful of public-facing Linux servers that will be monitored by Nagios. In light of this information, I believe our decision will be to allow arguments for the Windows hosts and look into disabling them for the Linux hosts and define our check arguments manually on those boxes. We haven't deployed Nagios on a Linux box yet, so hopefully that's possible.

I'll be reviewing our network config again with our network guys, but I know things are pretty locked down. Hopefully locked down enough.

Thanks for the input!

[jolson]

We haven't deployed Nagios on a Linux box yet, so hopefully that's possible.

It definitely is - let us know if you need any help with that.

Are we good to close this thread?

[jdalrymple]

We haven't deployed Nagios on a Linux box yet, so hopefully that's possible.

It's easier!

A lot of people will argue that not allowing arguments makes configuration a bear. I would argue otherwise - automate your config updates with the likes of puppet or even just cron jobs that pull the configs down, then centralize them and their still easy to maintain in one spot. You can even use the same nrpe.cfg for every Linux host and the same nsclient.ini for every windows host and just create separate command definitions for the various different hosts.

tmcdonald was right - security is a burden, but it doesn't have to make your life miserable. We're happy to help find the balance.

[mhixson2]

I think my questions are answered. Close away.
I'll be reviewing our firewall config again and looking into automating config deployments. We already reuse the same nsclient.ini for each Windows host, so that concept is one we like.
Thanks everyone.