[Nagiosplug-devel] NRPE Protocol

[Michael Wyraz]

When deploying nagios to our servers (using nrpe) I found that the 
current implementation using ssl with anonymous dh has some 
disadvantages in security (missing authentication) so that extra setup 
it required (e.d. stunnel or ssh) which makes deployment to clients more 
complex. Since the manual says "there's ssl", most users would not even 
notice that there might be a problem.

Later when I developed my own server implementation to connect Nagios to 
one of our applications, I found that it's really hard to find a 
documentation of the protocol (in fact there's only the source code) and 
that the protocol is very simple, restricted and tied to the c language.

These where the reasons for me to start this discussion ;-)


Meanwhile I discovered one interesting thing that made me re-thing my 
suggestion to the protocol: http://hessian.caucho.com/ - this is a more 
or less standardized binary protocol that is simple, efficient, 
well-documented 
(http://hessian.caucho.com/doc/hessian-serialization.html) and 
availiable for most languages. So I would recommend to use this as base 
for the new protocol.

To the plain protocol different levels of encryption and/or signing 
could be added. This could either be done using a shared secret (simples 
way) or by using certificates (IMO the best way; but has the 
disadvantage that for each node a certificate must be created).
Another interesting approach it to use a splitted shared secret that 
consists of one part that is put to the command definition (or to an 
external file to prevent that it's read via web interface) plus an 
second part that is defined in the host configuration. Both together 
would build the really used shared secret. This would it allow to use 
different shared secrets for each host while keeping the setup simple 
and without exposing the secrets to the Nagios web interface.


If you have more suggestions to this, let it discuss here. If there are 
some crypto experts in this list, please take in the discussion how the 
nrpe communication can be secured while keeping things easy.

Unfortunately I'm not a C programmer, so I cannot do these changes on 
Nagios in a good quality. But if we reach a final "spec", I can document 
it somewhere and I could provide a reference implementation in Java.


Regards,
Michael.



Hiren Patel wrote:
> Michael Wyraz wrote:
>
>   
>> If there's interest I'd like to discuss how the protocol could be 
>> improved. My suggestions are:
>> - document it somewhere ;-)
>> - change the structure to make it more flexible: 2 byte version, 2 byte 
>> packed, 2 byte response code, 2 byte payload length, the payload with a 
>> variable length instead of null-terminated
>> - move the checksum to the end. this makes the implementation in other 
>> languages more easy since it's not necessary to add a placeholder while 
>> constructing the message or calculating the checksum.
>> - use a HMAC checksum based on a shared secret. This seems to be the 
>> easiest way to add secure authentication to the protocol. When using a 
>> "default secret" it has the same functionality as a normal checksum
>> - add some "nonce" to the protocol to prevent reply attacks. This adds 
>> more security even if ssl is not used: client connects, server sends a 
>> random sequence, this sequence is included on the client side to 
>> calculate the checksum. The client adds his own "nonce" to the response 
>> so it can check that the server's answer is not a replay. A disadvantage 
>> is that this requires 1 more step in the communication but when the 
>> initial nonce is set to a fixed length, it's really easy to implement.
>>
>> Please tell me if you have feedback to this suggestions or to the 
>> protocol description (I'll add this description to one of the wikis 
>> these days).
>>
>>     
>
> I have no experience with the protocol, but what you're saying sounds 
> interesting. I'd say make the changes and submit the patches, if the 
> changes do improve the protocol and work better, I don't see why it 
> would not be accepted.
> many nagios users use nrpe, if these improve it in ways, I don't see why 
> a new major release with the protocol redo (if it's not backward 
> compatible) would not be considered.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________________
> Nagios Plugin Development Mailing List Nagiosplug-devel at lists.sourceforge.net
> Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20090810/6be96116/attachment.html>