Newbie: setting up swap space monitoring on a remote system

Paul L. Allen pla at softflare.com
Wed Mar 10 23:13:42 CET 2004


Marc Powell writes: 

> In order of simplicity: check-by-ssh, NRPE, or NSCA.

Simplicity is not the only consideration. 

NSCA works when the monitored system does not have a fixed IP because it
sends to the monitoring host.  With the other two you need some sort of
dynamic DNS solution to keep them working (also you get reported down-time
until the dynamic DNS updates if the IP address changes).  NRPE and
check_by_ssh work when the monitoring system does not have a fixed IP
but NSCA requires a dynamic DNS solution if the monitoring system does not
have fixed IP. 

Check_by_ssh is secure, and if you're really paranoid you can use a
different key file for every machine you connect to that way.  NSCA is
secure, but unless you run several daemons configured to use different
passwords and respond on different ports, a user with sufficient privileges
on one monitored machine could submit bogus results for other machines
that you monitor.  NRPE uses encryption to prevent people eavesdropping
on responses, but relies completely upon tcpwrappers to prevent black
hats submitting their own queries to machines that are monitored (which
is fine, unless your monitoring machine does not have fixed IP, then you
have to allow queries from a large subnet that may have black hats on it). 

> I'm quite sure those three options are not an exhaustive list of
> possibilities.

Another method is to use VPN technology.  I see that SuperFreeSwan
(various patches to the FreeSwan implementation of IPSEC) now implements
the Cisco method of checking that tunnels are still up.  The heartbeat
extensions previously used were not just incapable of scaling well, they
were horrible kludges.  Now there is a sensible method of re-establishing
tunnels after connectivity outages, I'll be looking at IPSEC as a
replacement for the pptp technology we currently use (frighteningly
insecure, because it's a Microsoft protocol, but it was designed on the
basis that the internet suffers outages, which IPSEC wasn't). 

I still think that IPSEC is not a camel resulting from a horse being
designed by a committee but a camel resulting from an ant designed by a
committee.  I still worry that Bruce Schneier states that pptp is
provably insecure but IPSEC is so badly designed it's impossible to
analyse the security in full.  But my main problem with IPSEC to date is
the lack of a mechanism to detect when one end of a tunnel goes away
(for whatever reason - network outage, machine reboot, or whatever).  ASDL
links in the UK are very unreliable, so without a sensible mechanism
to rapidly detect and recover from outages, IPSEC was a non-starter. 

-- 
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





More information about the Users mailing list