|Anonymous | Login | Signup for a new account||2013-05-18 13:08 EDT|
|Main | My View | View Issues | Change Log | Roadmap|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000125||[NRPE] * Feature Request *||minor||have not tried||2010-01-11 09:59||2012-03-18 21:23|
|Summary||0000125: nagios-nrpe-server: Insecure 'SSL' option, key identical for all debian systems|
The SSL option of the NRPE plugin and server does not perform any kind of authentication. It has no certificates, only a DH key, which is generated at compile time.
This means that the nrpe key is identical to all debian systems, but subject to change every time the package maintainer uses the ./configure script.
My patch adds full SSL certificate verification to nrpe. Note that this breaks backwards commandline compatibility, because the previous mode was insecure. This means that the check_nrpe rules must be edited in the nagios configuration as well.
|Tags||No tags attached.|
|Attached Files||fullssl.patch [^] (11,994 bytes) 2010-01-11 09:59|
|I am very excited about zulcss patch and findings. Please fix...|
|This bug is related/duplicate to bug 0000090, can someone with the appropriate rights set the relationship? :)|
Some side notes from my site: I recently tried to discuss this downstream at Debian, with basically just obstacles but no success.
I strongly wonder why Nagios doesn't apply this patch, or the one in bug 0000090.
Currently, SSL in NRPE is absolutely useless (unless you consider wasting CPU cycles usefulness).
Compiling the packages with one’s own DH parameters doesn’t make it secure at all. It's still anon-DH and you can connect to just any NRPE that you can reach.
So it's not like secure with one-shared-secret.
The only "argument" that speaks against removing the current SSL usage and replacing it by something better is that people think it would break compatibility.
This is just not true. Why?
If you have a homogeneous setup with then all fixed NRPE clients/servers, you're save anyway.
If not, you can still simply disable (the old) SSL.
And you can do this on a per-host basis.
Just define a check_by_nrpe and check_by_nrpe_no_ssl command and use it depending on whether the remote host is already fixed or still vulnerable.
On the remote side(s), either just disable the SSL in the NRPE daemon. You won't loose a single bit of security but actually you'll gain CPU resources.
In the unlikely case, that the remote host is monitored by different check_by_nrpes, where one is already fixed and one still vulnerable and you cannot tell the vulnerable side to upgrade... simply run two NRPE daemons on different ports.
As you can see, no real compatibility breakage (even in the most obscure setups), just a tiny bit of work that is simply required in order to become secure and have this issue fixed.
So again, please have a look at this issue and decide, and don't let it sleep here for ever :-)
|2010-01-11 09:59||zulcss||New Issue|
|2010-01-11 09:59||zulcss||File Added: fullssl.patch|
|2010-01-11 09:59||zulcss||OS||=> Linux|
|2010-01-11 09:59||zulcss||OS Version||=> Ubuntu/Debian|
|2011-05-04 14:13||davegarvey||Note Added: 0000279|
|2011-05-04 14:13||davegarvey||Issue Monitored: davegarvey|
|2012-03-18 21:02||calestyo||Issue Monitored: calestyo|
|2012-03-18 21:03||calestyo||Note Added: 0000382|
|2012-03-18 21:23||calestyo||Note Added: 0000383|
|Mantis 1.1.7[^] Copyright © 2000 - 2008 Mantis Group|