Giving up on NRPE, willing to try check_by_ssh...

[Paul L. Allen]

Flak Magnet writes: 

> Yes, from what I've seen primarily because a vulnerability on one machine 
> becomes a vulnerability on all pk authenticated machines.

Not quite.  If your monitoring machine is vulnerable to external attack
X but your monitored machines are not (things are usually the other
way around with monitored machines running additional services to the
ones run on the monitoring machine), and external attack X allows the
attacker to become the Nagios user then he can use the PK vulnerability
to get onto other machines as the Nagios user. 

So, in most cases if there's an external attack X that affects your
monitoring machine it will also affect your monitored machines and
the attacker doesn't need the PK exploit.  Only if the monitoring machine
runs services that the monitoring machines don't, or has other
vulnerabilities, is this a potential problem.  The attacker may then
be able to access confidential data on the monitored machines, if you
are foolish enough to leave it readable by Nagios.  The attacker may
also be able to use one or more local exploits to gain root on the
monitored machines, but only needs the PK attack to do so if the
monitored machines are not vulnerable to external attack X. 

> I gave NRPE a last-ditch retry last night and figured out my mistake.  

I have used NRPE but abandoned it mainly because the NRPE config file
is nothing like the Nagios config file so it's a real pain configuring
many machines with many services.  Even worse if you need to use NRPE
to talk to a firewall to make it use NRPE to monitor several machines
behind the firewall.  I was also slightly unhappy about the fact that
somebody who could sniff traffic to a monitored box could send NRPE
checks with a spoofed IP of the monitoring machine) and get answers
(unlikely they'd want to, though). 

Then I tried check_by_ssh.  It works for remote machines, but I couldn't
get it to chain so that I could use it to talk to a firewall to get it
to invoke check_by_ssh on the firewall to check a machine behind the
firewall.  I was probably doing something wrong, but I gave up on that
approach too.  Yes, I could have made it work by port forwarding on the
firewalls, but I was annoyed with check_by_ssh by then. 

So I switched to NSCA.  That takes quite a load off the monitoring machine.
Machines behind firewalls and which don't have an external IP can still
be monitored as long as they are masqueraded.  The major downside is that
it's a service running on the monitoring machine that isn't running on
the monitored machines and might be vulnerable.  But as long as you're
not also using check_by_ssh then it doesn't let people get at the
monitored machines through the PK vulnerability.  It's also a problem
if you're monitoring several untrusted machines with different customers
because you have to run separate instances of the daemon on separate ports
to be able to give them different passwords. 

Another way of monitoring remote machines would be to use a VPN.  That
means the authentication overhead happens infrequently rather than with
each service check.  The trouble is that the only VPN technology that
copes reasonably well with network outages is PPTP (and even that sometimes
needs to be restarted after it gets confused) but the authentication is
weak.  IPSec with the Cisco extensions might be robust against network
outages but I haven't played with it. 

All of the approaches have advantages and disadvantages. 

-- 
Paul Allen
Softflare Support 




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&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