[Pkg-nagios-devel] Bug#547092: Bug#547092: Bug#547092: nrpe ssl security problem

[Michael Friedrich]

On 08.02.2013 00:31, Markus Frosch wrote:
> Just my 2 cents (without any hat on):
>
> TLS integration in NRPE was broken from the beginning and more or less
> by design.
>
> The "real" and only security feature is to configure a appropriate
> allowed_hosts list, which might be enough security for internal
> networks in respect of TCP sessions.
>
> Question is: Do we really want to remove NRPE from testing because of
> it promising a incomplete feature?
>
> It should be pointed out that the TLS feature is broken, but still
> allowing users to use NRPE.
>
> Because the problem is: we (Debian) might not be able to change it -
> but I personally don't want users to use some self built stuff.

i've tried the idea of the ssl x509 patch in an unofficial nrpe fork.
lives in git here, until it dies, and will never get released, so 
beware: https://git.icinga.org/?p=icinga-irpe.git;a=summary

the nrpe implementation as is an entire mess, and one would rather 
rewrite it entirely than fix the ssl issue just for sanity. besides - 
the dh key gets generated on each configure run. so at least only the 
same package revisions share the same key.
you may figure, that not only nrpe is hard to maintain, but also nsca 
(and code wise, nagios is horrible, so is icinga 1.x).

so unless there's an idea about what to fix now or likewise, a 
maintainer capable of managing what upstream did and does wrong, there's 
not much chance to fix it. in the past you already had to fix broken 
upstream releases of nrpe/nsca/nagios and that's not really the job of a 
packager to take care of upstream's fuckups. thing is - people use and 
depend on nrpe, with or without ssl. rather then cutting that off now 
enforcing people to compile nrpe once again on their debian systems, i'd 
rather adapt the readme.

anyhow, for the alternatives - check_by_ssh or snmp. the checkmk agent 
is not capable of ssl itsself nor does it support ipv6 natively. you'd 
have to used xinetd with a ssh tunnel to make this work (and while at 
it, you could tunnel nrpe then too).


the future in icinga regards will introduce a new agent, based on the 
(already in dev) existing icinga2 message protocol (native v4/v6, x509, 
compression). but it's not yet implemented as it's planned for a later 
milestone this year.

kind regards,
Michael


-- 
DI (FH) Michael Friedrich

mail:     michael.friedrich at gmail.com
twitter:  https://twitter.com/dnsmichi
jabber:   dnsmichi at jabber.ccc.de
irc:      irc.freenode.net/icinga dnsmichi

icinga open source monitoring
position: lead core developer
url:      https://www.icinga.org