Command Argument Processing in nrpe (Linux)


(Thomas Speck) #1

Hi all

In the nrpe.cfg in the Comments for Command Argument Processing it is written that enabling that option (that is setting dont_blame_nrpe=1) is a security risk and to read the SECURITY file. Unfortunately, in the file I found on github, it says mor or less the same:

“NRPE 2.0 includes the ability for clients to supply arguments to commands which should be run. Please note that this feature should be considered a security risk, and you should only use it if you know what you’re doing!”

Is there some information online of the possible impact of enabling this (we won’t enable Bash Command Substitution), and what did you do there?

Kind regards, Thomas


(Michael Friedrich) #2

AFAIK the Debian package removes that entirely in its binary sources, so you cannot use it there. Reasoning is found in CVEs (Google has some of them, e.g. http://legalhackers.com/advisories/nagios-nrpe.txt)

One reason against this is that you cannot control the default parameters, e.g. limiting the scope of passing thresholds or additional execution parameters. “-a” just overrides anything you’ve specified locally. This is pretty harmful if you expose NRPE not only to your monitoring master, but allow customers to use that as a remote ping service for example.

The upstream readme is pretty useless, it hides the critical stuff. If you really care about security, you don’t use NRPE these days. The TLS encryption uses anonymous DH, which is predictable and shared on each binary build (meaning to say, the same binary build trust each other). allowed_hosts with IP addresses is pretty weak, IP spoofing is always a thing. IIRC v3.0 introduced the ability to use x509 certificates, still it only validates the trust chain with the same CA signing method. There’s no additional security involved with checking the certificates CN with the current connecting FQDN, and no local white/blacklist either (as one has with Icinga 2 and endpoint object configuration, or browsers which do enforce SubjectAltName checks).

A good read from a security guy: https://archive.cert.uni-stuttgart.de/bugtraq/2014/02/msg00054.html


(Thomas Speck) #3

Thanks, that was exactly the information I needed.

Are there potential succesors for nrpe with less of the problems mentioned in your second link?


(Michael Friedrich) #4

Depends on your monitoring system. If you are using Icinga 2, just go with the Icinga 2 client.


(Thomas Speck) #5

At the moment still Icinga 1 :wink:


(Michael Friedrich) #6

Hmm, then more or less check_by_ssh. I’d suggest to plan a migration to Icinga 2 though, as 1.x has gone EOL, whereas future development only targets Icinga 2, Icinga Web 2 and so on.


(Thomas Speck) #7

Regarding the move to Icinga 2, we are searching for a replacment for nagiosql at the moment. But I’m trying to come to Nürnberg in September (the Heise Icinga 2 Event) and hope to learn something there :wink:


(Michael Friedrich) #8

tt definitely helps to learn and understand the Icinga 2 DSL before jumping into any abstraction layer like a GUI or automation tools. In case of errors or wrong configuration, such a knowledge saves lots of time. For the heise workshop, this is held by Dirk, a professional trainer and fellow colleague for many years :slight_smile: