[Nagiosplug-devel] NRPE Protocol

[Michael Wyraz]

Hi,

because I wanted to integrate some of our own monitoring tasks to 
nagios, I spent some time with the NRPE protocol. Since it's almost 
impossible to find some documentation, I gathered my informations from 
the source.

Here's what I found out about it:
- any numbers are stored in big-endian notation (highest bytes first)
- a packet consists of exactly 1036 Bytes
  - 2 byte integer: version of the protocol (currently 1,2,3)
  - 2 byte integer: type of the packet (1=request, 2=response)
  - 4 byte long integer: crc32 checksum of the message
  - 2 byte integer: return code of the remote command (in requests it's 
filled with a random number)
  - 1024 byte data: the command or response text, filled with zero-bytes
  - 2 byte of garbage: this is because the c structure is sent "as it 
is" over the wire. When creating messages, it's fine to set it to zero.
- the crc32 checksum is calculated from the whole message (including the 
2 bytes of garbage). the 4 bytes reserved for the crc are set to zero 
for calculation the crc. The default crc32 algorithm is used.

Additionally the communication may be secured by ssl (anonymous dh). 
This fact is well documented ;-)
SSLv3 is used as Protocol. The cipher suite used is one of:
- SSL_DH_anon_WITH_RC4_128_MD5
- SSL_DH_anon_WITH_RC4_128_MD5
- SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
- SSL_DH_anon_WITH_DES_CBC_SHA
- SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
- SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
(This information is from a java implementation of the server and might 
be wrong - but for me it works)

In my opinion the protocol has a few disadvantages:
- the "garbage" is part of the protocol (i.e. things will not work 
without) but it is only there because of an implementation bug
- there's encryption but no kind of authentication
- the payload size is fixed to 1024 bytes

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).

Regards,
Michael.