NSClient++ Help (#1) - NSClient++ and nsca (#53) - Message List
I'm looking for a way to use NSClient with passive checks (because of several firewalls between the systems) - basically, I need a way to get NSClient to generate strings that I can then feed into send_nsca. I do not have a Linux box available on the NSClient++ side of the system, so I can't use check_nt, and NRPE is also out because of the firewall.
Is there a Windows binary of check_nt, or something equivalent, that I could use to access the data from NSCP?
Thank you!
-
Message #73
I know that nc_net(?) works with nsca. As for "this project" myself I have not had any use for it so I have not implemented it but if there is an interest I could be persuaded to add support for it.
MickeM
MickeM10/28/07 22:05:03 (6 years ago)-
Message #78
Thanks for pointing me to nc_net! My situation is actually slightly more complex, so I prefer to actually get the strings and feed them into send_nsca myself. The reason is that I want to be able to SSH-encrypt the transmission and already have the infrastructure to do that - but it currently relies on having the actual check strings (I'm actually sending the check strings through SSH, rather than have send_nsca do it).
How much persuation does it take to add support for it? ;-) Hopefully, I'm not the only one with this kind of need.
Or alternatively, is there any documentation for the protocol between NSCP and check_nt? In that case, I could probably write it myself. The source code for check_nt looked simple enough.
Kevin Keane10/31/07 05:48:51 (6 years ago)-
Message #79
Feel free to describe "how" you tunnel the stuff (if it is something simple like putty:like thingy maybe it could be added). Sounds interesting so if there is a "twist" to it I would probably be interested in adding it :)
As for the protocols nothing magic, the "check_nt" is pretty much telnet in: <password>&<command number>&<arguments> IIRC (if you enable debug I think you can see the raw data with nsclient++ /test. I would opt for "NRPE" as that is a a better "protocol" but it is slightly more complex (but barring the optional encryption not overly so).
If you want details I could probably point you in the right direction but am at work now so don't have time to look it up at the moment...
Another option is ofcource to run the nrpe binary on your windows box and use things "as is" (I thought that was how you used the "regular" NSCA daemon?)
MickeM
MickeM10/31/07 13:03:41 (6 years ago)-
Message #80
How I tunnel the stuff? It's actually quite trivial. Let's look at now NSCA normally works when both boxes are Linux: you run a standard Nagios plugin, and pipe it's stdout into send_nsca.
When the monitored system is a Windows box, it works basically the same way. Instead of a standard Nagios plugin, you use any NRPE-compatible plugin, and pipe it's stdout into a Windows version of send_nsca.
The problem with both approaches is that send_nsca has very limited security, only a single password, weak encryption, etc. It's designed for a LAN, not for a WAN. To wrap this in an encrypted connection, I added one sneaky trick: my send_nsca does not run on the monitored system, but rather on the monitoring server. I configured one user account to use send_nsca as a shell. Then I configured SSH with the appropriate private/public keys.
On the monitored system, the Nagios plugin will now simply pipe its output into SSH - and send_nsca accepts it at the other end. If the monitored system is a Windows box, I was going to use Putty's plink.exe as the SSH client.
As a fringe benefit, I don't have to worry about properly configuring send_nsca on each individual network; I just configure SSH.
BTW, I also thought about doing the almost exactly same thing using SSL instead of SSH. But that would be quite a bit more complex.
So in my network, what goes across the network is actually the stdout from the Nagios plugin - and neither NSClient, NSClient++ nor nc_net give me access to that on the Windows box. NC_net comes closest, but since it implements the NSCA protocol directly, it, too, does not work for me.
Thus the need to run check_nt (or something similar) on the Windows box. I'll look into using either the check_nt or the NRPE protocol.
BTW, generally active checks are of course better, but NRPE is not an option in my setup. The problem is security. I am monitoring multiple completely disconnected networks. With NRPE, I would allow my network to actually run a program - the plugin - on each of my customer's networks. Now imagine that, god forbid, my network gets compromised - in that case, *all* of my customer networks are compromised.
On the other hand, if I use passive checks with NSCA, if my network is compromised, basically nothing happens to my customers. If one of my customer's network is compromised, an attacker could submit bad data to Nagios, but still couldn't get into any of the other networks.
This is why NRPE is not an option; I can only use passive checks/NSCA.
Does all of this make any sense at all?
Kevin Keane11/03/07 10:35:53 (6 years ago) -
Message #90
Just a quick update... I decided to port check_nt to Windows. The ported version is on Sourceforge.net under the name check_nt_win. It isn't thoroughly tested yet, so it's still very much in beta.
Kevin Keane11/18/07 07:25:48 (6 years ago)
-
-
-
-
Message #235
Hello,
I have the same problem that you.
I need to use a check_nt installed on my windows Server and not on my linux Box. Have you found a solution for your problem ?
Thanks
pgabert@…02/14/08 18:01:03 (5 years ago)
