check_by_ssh vs nrpe discussion (was check_by_ssh)

[mark.potter at academy.com]

"mark redding" <mwjredding at gmail.com> wrote on 12/13/2007 10:36:16 AM:

> Hi,
> 
> On 13/12/2007, mark.potter at academy.com <mark.potter at academy.com> wrote:
> >
> > Currently I know of no risk associated with running NRPE however any 
service
> > that opens a port on a system can become a risk. After much debate and
> > discussion we have decided to use check_by_ssh in our environment for 
this
> > very reason. It may not be a risk at the moment but it could become a 
risk
> > in the future. I am not a hacker so I can't say what could happen with 
the
> > existing code to cause a risk but the possibility remains. Our 
decision was
> > based in simplicity as there is less to install on each system, fewer
> > configurations to maintain, less risk as no new daemons are 
introduced.
> > Everyone else may have different mileage in their own environments.
> 
> I can see that a poorly implemented "check_by_ssh" based system (ie.
> where the remote end fails to have extremely tight control on what can
> be run) can be less secure that using nrpe (where the remote nrpe.cfg
> file specifies who can communicate with it and exactly which commands
> (inc params) it can run) given that there is a password-less key
> exchange taking place and therefore anyone gaining access to the
> account with the key is then able to gain shell level access to the
> remote machine.
> 
> For example, if the local host does not have it's private key
> protected properly, or indeed if the root password on the localhost is
> weak then :-
> 
> $ ssh -i /home/nagios/.ssh/id_rsa -l nagios remote-host
> 
> gets you straight onto "remote-host". Just because it has the letters
> 'ssh' in it does not make it un-exploitable.
> 
> Anyway, It's horses for courses I suppose.
> 

It all depends on your ssh setup. When you have tight controls for ssh in 
place, which you should to begin with, then check_by_ssh isn't an issue. 
The situation which you describe already has one box being rooted by a 
weak password and improper permissions on the private key file. SSH is a 
service already running on most Linux boxes and if the sysadmin has it 
that borked to begin with then it really isn't going to matter which is 
more secure (nrpe or check_by_ssh) because the overall system is at risk 
from the ground up. 

Nothing is un-exploitable but we all try to make sure our systems are 
secure. In our case it made sense to go with check_by_ssh for the reasons 
listed and not to mention we had just overhauled our ssh policies and 
implemented even more access controls. It also allowed us to not have to 
drop configurations onto multiple servers and in that way made managing 
the overall system easier.

That said I have worked for a webhost where we used nrpe and I never had 
any problems. In most cases it's six in one hand and a half dozen in the 
other. It all boils down to the environment into which you walk when 
implementing Nagios. If you walk into one with a well setup ssh security 
policy and a paranoid security team the check_by_ssh is likely how you 
will end up going but in a lot of other cases nrpe is not an issue. I have 
done both and will likely end up doing both again.

Horses for courses indeed!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20071213/182da0ce/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at 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