Kevin Keane wrote: > Andreas Ericsson wrote: >> Kevin Keane wrote: >>> Christopher McAtackney wrote: >>>> 2009/3/25 Kevin Keane <subscript...@kkeane.com>: >>>> >>>>> I think you are comparing apples and oranges here, because in most >>>>> situations that I can think of, the decision is dictated by the >>>>> network >>>>> topology. If you are exclusively on a trusted private network, >>>>> check_by_ssh really doesn't offer any benefits. Conversely, if your >>>>> topology involves the Internet or some other untrusted network (WiFi), >>>>> then you wouldn't want NRPE in the first place. >>>>> >>>>> The only exception to the above that I can think of is when it >>>>> comes to >>>>> deciding between using check_by_ssh over an untrusted network, vs. >>>>> NRPE >>>>> through some other kind of tunnel or VPN. But in that case, you'd >>>>> incur >>>>> encryption overhead either way, and the comparison is very different >>>>> from the question you asked. >>>>> >>>>> All that said: I don't have any first-hand experience, but I suspect >>>>> that the impact of establishing 2200 ssh connections in a five-minute >>>>> span (assuming that you are using a five-minute check interval) is >>>>> pretty substantial. The main impact actually lies in establishing and >>>>> tearing down the connections, key negotiations etc.; the encryption >>>>> during the data phase probably has only limited impact because most >>>>> checks only transmit a few bytes back and forth. >>>>> >>>>> SSH does much better with longer-duration connections when the keys >>>>> are >>>>> already exchanged. This is even more true if you have a router-based >>>>> VPN, because in that case the overhead is offloaded to a different >>>>> machine. >>>>> >>>>> So if you have the option of sending the checks as NRPE through one >>>>> or a >>>>> few long-term VPNs: you are probably going to be better off. Of >>>>> course, >>>>> in the big picture, your mileage may vary. >>>>> >>>> Firstly, thanks for the detailed explanation of the issues involved in >>>> this choice Kevin, it's been very helpful. >>>> >>>> I'm curious though, could you elaborate on why NRPE is unsuitable if >>>> communication with my remote hosts is going to go via the Internet? Is >>>> it not sufficient that NRPE uses SSL? This may be more of a network >>>> security question than a Nagios one, but I've no real experience in >>>> either area unfortunately, so I appreciate any info you can give here. >>>> >>> No, you are right. I wasn't aware that NRPE could use SSL. In that >>> case, NRPE would be pretty much the same in terms of performance as SSL. >>> >>> That said, I am generally concerned from a security standpoint about >>> any kind of active checks going over the Internet. This is because if >>> you are monitoring, in your example, 200 hosts, you have to poke >>> holes into 200 firewalls (or into one firewall, and then set up SSL >>> or SSH keys on 200 hosts). That's 200 potential security holes all >>> over the place with little or no control, and on machines that may >>> not necessarily be hardened for access from the outside world. Worse >>> - active checks, by nature, cause a program to be launched and >>> executed on the monitored client, and usually with very high >>> permissions. You said that you check 2000 services, so that's 2000 >>> plugins (give or take a few). What if a hacker found a way to >>> compromise one of your 2000 plugins? You'd have a privilege >>> escalation issue along with remote-launch capability. On 200 clients. >>> >> Very high permissions are normally not needed. > Depends on the plugin, but I'm not sure that this is generally true. For > instance, something as simple as log file analysis either requires root > permission on Linux; log files aren't readable by anybody else, or it > requires that you relax file permissions or security somewhere else.
If you do the insane version of log analysis, yes. A sane setup is to have filters trigger on certain patterns and have the filtering program log its results somewhere that Nagios can read. The actual logs need never (and should never) be readable by the Nagios user. > On > Windows, I'm running my monitoring agent (by default) as the Local > System account (most Windows services do that anyway). That has > basically full access to everything, but nothing on the network. > Well, Windows is an aberration wrt privilege separation and that's not going to change in the near future because privilege separation makes things hard for home users. I'm sure you can create limited accounts under Windows too though. Otherwise I doubt any security- minded organization would use it. > Of course check_ping, check_tcp etc. don't usually need such high > permissions. check_ping actually requires root permissions on most systems. Or rather, the program doing the actual pinging does, since it has to open a raw socket. >> I prefer using NRPE because >> of two reasons: >> 1. It provides a rather simple way of specifying exactly which commands >> can be run, and with which arguments (don't enable argument parsing >> in nrpe if the receiving end isn't duly protected by firewalls etc) >> 2. If someone breaks into the Nagios server, he or she does not get the >> public keys required for running commands on the remote servers. > Can you explain that second statement? I'm not sure I follow what you > are trying to say here. Why would getting public keys be a bad thing? s/public/private/ The private keys have to be on the nagios server. Not on the remote server (I agree that it was confusing). -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ------------------------------------------------------------------------------ _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
