<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> 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: <a class="moz-txt-link-freetext" href="http://hessian.caucho.com/">http://hessian.caucho.com/</a> - this is a more or less standardized binary protocol that is simple, efficient, well-documented (<a class="moz-txt-link-freetext" href="http://hessian.caucho.com/doc/hessian-serialization.html">http://hessian.caucho.com/doc/hessian-serialization.html</a>) 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: <blockquote cite="mid:4A7C461E.2070103@gmail.com" type="cite"> <pre wrap="">Michael Wyraz wrote: </pre> <blockquote type="cite"> <pre wrap="">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). </pre> </blockquote> <pre wrap=""> 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. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/bobj-july">http://p.sf.net/sfu/bobj-july</a> _______________________________________________________ Nagios Plugin Development Mailing List <a class="moz-txt-link-abbreviated" href="mailto:Nagiosplug-devel@lists.sourceforge.net">Nagiosplug-devel@lists.sourceforge.net</a> Unsubscribe at <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel">https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel</a> ::: Please include plugins version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null </pre> </blockquote> </body> </html>