check_by_ssh question

[Paul L. Allen]

Arnold Cano writes: 

> I have successfully migrated my nagios installation completely to 
> check_by_ssh from nrpe.

I did that months ago.  And then I migrated from NRPE to NCSA. 

> I am very pleased because it allows me to have uniform and secure way
> of maintaining the installations over my windows and linux hosts.

It has its problems.  It is not uniform because the configuration of
the NRPE daemon is very different from that of NCSA itself.  It has
the advantage that you can run NRPE on a firewall (more secure, on
a machine protected by a firewall, with port forwarding from the
firewall to the NRPE box), whereas check_by_ssh seems to be unable
to be chained (or I couldn't figure out the correct syntax to do it).
The major disadvantage is it's not really secure at all, even with
tcpwappers.  Somebody who can eavesdrop your network traffic can send
spoofed requests and get the answers. 

Check_by_ssh is reasonably secure, however there are circumstances which
may not apply to most people in which you can compromise the monitoring
machine and use the password-less key to mount compromises on monitored
machines that you can't compromise any other way.  And I couldn't make
it chain through check_by_ssh on the monitoring box via check_by_ssh
on a firewall to run a plugin on a machine behind the firewall. 

NCSA is pretty secure in theory (you have to verify or trust that the
encryption has been implemented correctly and that the NCSA daemon has no
holes).  The configuration at each end uses the same syntax and the configs
themselves are almost identical barring a few predictable (and automatable)
changes. If you have hostgroups you don't want to share a password you can
run separate instances on different ports with different config files.  It
also takes a significant load off the monitoring machine.  The downside
is that if there is an exploit for the demon then somebody can take
over your monitoring box (but they can't go any further if you don't
have any passwordless ssh keys on it or other similar holes that reach
to other machines). 

You could also use VPNs, although I have yet to see a VPN technology
which is not flawed in a major way.  Some of them tunnel TCP over TCP
(leading to exponential backoffs when the network is congested, which
is a bad thing in general and a very bad thing for Nagios with 10s
timeouts).  Some (PPTP) use increadibly weak encryption.  Some (IPSec)
would be almost usable if only they had a standardized method of
recovering from network outages (there are kluges that do not require
proprietary extensions but there is a major overhead in short rekeying
intervals). 

> There doesn't seem to be much information dealing with indirect checks.

It's there, but it's scattered around amongst the docs for reduntant
monitoring, failover monitoring and passive service checks. 

> A little googling will find a new different methods/hacks to this
> problem but no "official" howto on this topic even though there is an 
> entire chapter in the nagios manual on indirect host and service checks.

The mailing list has discussed this several times, so it is in the
archives.  However, something in the documentation would be nice. 

-- 
Paul Allen
Softflare Support 




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
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