Xor encrypt not working when sending with send_nsca

[Seb-Solon]

From : ubuntu / debian repository
Version : 2.7.2 / 2.9.1

To reproduce :

echo "host;serv;0;OUTPUT" | send_nsca -H IP -d ";" -c /etc/send_nsca.cfg

with encryption enabled in the config file

[mohierf]

My NSCA configuration works perfectly with Windows NSClient and no encryption. I made a test with XOR encryption and everything is also fine.

I made a test with a Debian client and your command and everything is also ok.

I suppose you know it but it is important to be sure that password are the same on server and client ...

With my NSCA testings, I observed something quite strange and probably buggy !
We receive more data than necessary ... The first bytes are detected as a valid NSCA check and the module tries to deal with the remaining data ... and sometimes it detects something quite valid !

I suppose we should stop buffer analysis when something matches ... I will make a try.

Here are the receiver log file (I added some logs) when I use your command :

=> Detected valid NSCA :
2014-02-27 07:55:58,622 [1393484158] Info : [receiver-master] [NSCA] databuffer : 4304
2014-02-27 07:55:58,623 [1393484158] Info : [receiver-master] [NSCA] command : [1393484158] PROCESS_HOST_CHECK_RESULT;fvc318;0;OUTPUT

=> Still something in the buffer ...
2014-02-27 07:55:58,625 [1393484158] Info : [receiver-master] [NSCA] databuffer : 3584
2014-02-27 07:55:58,626 [1393484158] Info : [receiver-master] [NSCA] Dropping packet with stale timestamp - packet was 1110679463.63 seconds old.
2014-02-27 07:55:58,628 [1393484158] Info : [receiver-master] [NSCA] databuffer : 2864
2014-02-27 07:55:58,629 [1393484158] Info : [receiver-master] [NSCA] Dropping packet with stale timestamp - packet was 1322066983.63 seconds old.

=> Still something in the buffer ...
2014-02-27 07:55:58,630 [1393484158] Info : [receiver-master] [NSCA] databuffer : 2144

=> Matching !
2014-02-27 07:55:58,631 [1393484158] Info : [receiver-master] [NSCA] command : [2491568240] PROCESS_SERVICE_CHECK_RESULT;��G�n$^�*�]�����Ȑ�q!-�E�y�h5�lS����m�\�צet��f7�!^1~�Pf�)�c�51;��W��e}m8��4�:�{wR�x�Q}�֥��:��b��*���77�����!D����ފ�NV���eJ=���F�K\����q��`���ҁ�wV=�\������eL����ntpʹ�[K.�3���9�b�~B�W�d�-6;5059;x�zg�CP|7��c�2�kdo'I6C
2014-02-27 07:55:58,632 [1393484158] Info : [receiver-master] [NSCA] databuffer : 1424
2014-02-27 07:55:58,634 [1393484158] Info : [receiver-master] [NSCA] command : [2312146125] PROCESS_SERVICE_CHECK_RESULT;�'�_�����0����.D��ǻ�{�=-�����3[��n����X�
�����"G��.w�����َ�l�;�RzN��ڑ�)��ǐ:gW����C�/kE��ЩM���3��e�uM��'.SZ~ �k��[�L����
��R~L�c����i��,E�������0vA�`�5iďk����W�]��B}8Tv��]����m������;4546;�J=b������
����b�����j�+HE�g��H��$٩��G�T+Ϩ(8&m}��R,�[�o����6��u*K�8߾�%c`��'HU��ې[� !D�{ՌA���:����k�Q��M�
{)��E.�F������'��p'g�����
3$��a���в��0^D�I��0y��⑰�n�p��":-a+>�v����b����$��)8F��Ӿ�1'���0n
����h�Gyi�bٟcy��9ރ��>��0��� �Vx��_y���}���o��b�A�=���7�jڊ�p#���Y��Qo�x�MA���Ԥ�T�v�����[>�&�B+���G����
��'yW�<�ǡ!?9�������ړ��'hP�q��cw�� ����d�E�ɥ$�_F
��Ws�d�D����j��|!N�#���~�l̟$�����v�6Ty��Ɖcv��"祊�V�z��8

[mohierf]

After more investigation, I found out that our NSCA module do not care about NSCA messages longer than 720 bytes ... in fact, the recent send_nsca use a NSCA payload of 4096 bytes, upon which you add 208 bytes for timestamp, host, service and other fields. Than, you get 4304 bytes sent from your client to our server.

The NSCA module takes care of received data on a 720 bytes packet size ... so you have several check result readings (one per each 720 bytes). In almost every case, your check is considered and you have several rotten check results ...

I am currently trying to change NSCA module behavior for dealing with short (512 bytes) and long (4096 bytes) payload .

Probably, it should explain your problem with Xor encryption ?

[Seb-Solon]

Well, I opened thi issue while at a customer's office. I'll try to reproduce it with my own configuration. It may also be send_nsca specific because it's not the first time I use NSCA without issue :(

In my case the output was pretty short, so maybe it's not related to length. However this can be nother bug :D

[mohierf]

I will soon commit a new version of NSCA module that I am testing since this morning with a Windows NS Client agent and a Debian send_nsca, both of them with two different payloads (512 or 4095 bytes).

[naparuba]

one day we will just put curl on every windows/linux box, and we
will be able to drop all nsca from this world :D </off topic>

On Thu, Feb 27, 2014 at 3:05 PM, Frédéric MOHIER
notifications@github.comwrote:

I will soon commit a new version of NSCA module that I am testing since
this morning with a Windows NS Client agent and a Debian send_nsca, both of
them with two different payloads (512 or 4095 bytes).

Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-36244371
.

[mohierf]

:D

I just commited a version that accepts NSCA 512 or 4096 bytes. I tested with Windows and Debian clients, 512 or 4096 bytes, with and without Xor encryption.

[naparuba]

you rocks

[mohierf]

Thanks