NRPE enhancement

[Dave Viner]

What about using GPG to validate the origin of the request?  On the central
Nagios server, it would sign the request using a private key, then on the
remote machine, it would verify the signature using the public key.  I don't
know exactly how that compares to check_by_ssh with respect to scalablity,
but it is one possible way of verifying the origin of a request.

dave


-----Original Message-----
From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of Dave Viner
Sent: Monday, December 30, 2002 12:43 PM
To: Carroll, Jim P [Contractor]; 'nagios-users'
Subject: RE: [Nagios-users] NRPE enhancement


Ok, so check_by_ssh doesn't scale well, and nrpe is scalable cpu-wise, but
has problems configuration-wise.  (Imagine 500 machines all of which have 5
disks, and different check_disk arguments for each.  That's 2500
configuration lines that need to be maintained over 500 machines in 500
files.)

Perhaps there is room for something more secure than the current nrpe, but
more scalable than check_by_ssh.  Does that seem reasonable?  If so, does
anyone have suggestions for low cost security implementations that could
enhance the security of nrpe without the cost of ssh?

dave


-----Original Message-----
From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of Carroll,
Jim P [Contractor]
Sent: Monday, December 30, 2002 10:49 AM
To: 'nagios-users'
Subject: RE: [Nagios-users] NRPE enhancement


The general consensus is that check_by_ssh isn't a solution which will scale
well, due to the nature of the number-crunching crypto beast.  This is where
NRPE has the advantage.

check_by_ssh has the advantage when it comes to punching through a firewall,
assuming that an appropriate port is open.  Sure, you could open port 5666
for NRPE, but has has been discussed, that doesn't quite leave the same warm
fuzzies.

HTH.

jc

> -----Original Message-----
> From: Dave Viner [mailto:dviner at yahoo-inc.com]
> Sent: Monday, December 30, 2002 12:14 PM
> To: 'Ethan Galstad'; 'nagios-users'
> Subject: RE: [Nagios-users] NRPE enhancement
>
>
> Let me ask a second question that might help me understand
> more clearly the
> situation.  Check_by_ssh allows for the passing of arbitrary
> arguments to
> arbitrary command from the centralized Nagios server to any
> remote machine
> which has sshd running.  NRPE allows for executing a specific
> command with
> specific arguments on any remote machine which has nrpe running.
>
> As someone setting up monitoring, when should I use
> check_by_ssh and when
> should I use nrpe?
>
> dave
>
>
> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net
> [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
> Dave Viner
> Sent: Monday, December 30, 2002 9:07 AM
> To: Tom Welsh; 'Ethan Galstad'; 'nagios-users'
> Subject: RE: [Nagios-users] NRPE enhancement
>
>
> I don't think that my enhancement allows an arbitrary command to be
> executed.  I think the code that I wrote will only allow one
> of the commands
> already listed in the nrpe.cfg file to be executed.  The
> arguments passed
> are arbitrary, but not the command. (The code even checks to
> ensure that the
> command requested, without any arguments, exists before
> executing it to
> prevent malicious usage of arguments.)
>
> dave
>
>
>
> -----Original Message-----
> From: Tom Welsh [mailto:twelsh at square-box.com]
> Sent: Saturday, December 28, 2002 5:02 PM
> To: 'Dave Viner'; 'Ethan Galstad'; 'nagios-users'
> Subject: RE: [Nagios-users] NRPE enhancement
>
>
> In my humble opinion an option that allows an arbitary command to be
> executed and which by "default" is switched off is an accident waiting
> to happen.
>
> It only takes 1 security breach via a plugin to completely destroy the
> good name Nagios and its associated plugins have.
>
> There is a good truism that states "good news travels fast,
> but bad news
> travels even faster"
>
> I for one would not be too happy having a command available on my
> network, trusted or not that would allow commands to be executed
> remotely pon a box. For one. It's the kind of thing im always looking
> for when im "playing on my " networks.
>
> Well that's my two cents worth
>
> Cheers
>
> Tom Welsh
> twelsh at square-box.com
>
> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net
> [mailto:nagios-users-admin at lists.sourceforge.net] On Behalf Of Dave
> Viner
> Sent: 28 December 2002 21:46
> To: Ethan Galstad; nagios-users
> Subject: RE: [Nagios-users] NRPE enhancement
>
> These are excellent arguments for not incorporating the
> enhancement I am
> suggesting.  However, I suspect that there are lots of
> installations of
> Nagios and NRPE that run on completely trusted network.  (Or
> the risk of
> network intrusion through NRPE is worth the benefit of reduced
> configuration
> management.)
>
> What do you think about incorporating this enhancement but have it
> turned
> off by default, and enabled only at configure time?
>
> dave
>
>
> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net
> [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of Ethan
> Galstad
> Sent: Friday, December 27, 2002 7:38 PM
> To: nagios-users
> Subject: RE: [Nagios-users] NRPE enhancement
>
>
> There are several reasons why I have not added support for arguments
> to checks in NRPE.  Most have been touched on in the past on the
> list, but I'll reiterate them here.  The main issue is not overruning
> the 2K packet that the check_nrpe plugin and NRPE daemon pass back
> and forth - that can be easily avoided...
>
> 1.
> Users connecting to the NRPE are not authenticated.  Sure, you can
> restrict connection based on IP address using TCP wrappers, but they
> are still not authenticated.  Also, I am not too familiar with IP
> spoofing, but I'm sure its possible for someone to fake the
> originating address of the connection and get the NRPE daemon to
> accept the packet and execute the necessary plugin without too much
> trouble.
>
> 2.
> Some plugins (like check_dhcp) may (have to) be installed suid root.
> Regardless of what user the NRPE daemon is running as, these plugins
> will be executed with higher privs.
>
> 3.
> Plugins can be made to segfault under the right conditions.  Sure, we
> can try and eliminate this possibility, but it will probably always
> exist to some extent since many plugins call system commands to get
> their data.
>
> ---
>
> Most remote exploits rely on buffer overflows/segfaults to get their
> work done, so allowing unauthenticated users to pass arbitrary
> arguments/data to plugins that might be running suid commands is a
> very bad idea indeed.
>
> Stunnel would provide some security, but there is no guarantee that
> everyone would use it.  There would undoubtably be many people that
> would put off implementing it until they finished "testing" NRPE.  In
> the worst case, they might never get around to implementing stunnel
> at all.  In the likely best case scenario, there is at least a window
> of opportunity.  I just don't want to be responsible for the possible
> carnage that happens at that point. :-)
>
> Also, incorporating native encryption into NRPE involves reinventing
> the wheel called "check_by_ssh", so I'm really interested in doing
> that.
>
>
>
> On 27 Dec 2002 at 13:46, Carroll, Jim P [Contractor] wrote:
>
> > I'm not a C programmer by profession, so I defer your query to those
> who
> > have a strong background, both in C code and system/network
> security.
> It
> > does presume that every other link in the chain is bulletproof.
> [Insert
> > ObRef to Bugtraq here.]
> >
> > At any rate, I'm curious to hear why Ethan didn't choose
> that approach
> to
> > begin with.
> >
> > jc
> >
> > > -----Original Message-----
> > > From: Dave Viner [mailto:dviner at yahoo-inc.com]
> > > Sent: Friday, December 27, 2002 12:49 PM
> > > To: Nagios-users at lists.sourceforge.net
> > > Subject: RE: [Nagios-users] NRPE enhancement
> > >
> > >
> > > This sounds interesting, but I have a question about the
> > > security implications of this code.  I'm not a security
> > > expert, so please excuse the somewhat basic question.  The
> > > struct packet as defined in common/common.h has an argv
> > > member which is a character array of length 2048.   I believe
> > > this means that if the incoming packet has an argv member
> > > whose length is greater than 2048 chars, then the
> > > 	rc=recvall(sock,(char
> > > *)&receive_packet,&bytes_to_recv,socket_timeout);
> > > should fail, should it not?
> > >
> > > However, I think your suggestions regarding stunnel, and
> > > encryption are good ones, regardless of the inclusion of
> this code.
> > >
> > > thanks
> > >
> > > dave
> > >
> > >
> > > -----Original Message-----
> > > From: Carroll, Jim P [Contractor]
> [mailto:jcarro10 at sprintspectrum.com]
> > > Sent: Friday, December 27, 2002 10:20 AM
> > > To: 'Dave Viner'; Nagios-users at lists.sourceforge.net
> > > Subject: RE: [Nagios-users] NRPE enhancement
> > >
> > >
> > > I think it's a good idea, but with the following provisions:
> > >
> > > - This should not be enabled by default.
> > >
> > > - The configure script, the Makefile and any/all NRPE docs
> > > should explicitly
> > > state the security risks in forcing the non-default
> (added feature)
> > > behaviour.
> > >
> > > - If the daemon is compiled with this option, anytime the
> > > daemon starts, it
> > > should briefly mention that it has been compiled for this
> > > behaviour, and a
> > > quick remark about the increased risks.  (Sent to stderr if
> > > standalone, else
> > > sent to syslog if running under (x)inetd).  It should scream
> > > loud and clear
> > > if it's started under root; preferably it would simply not
> > > run as root, full
> > > stop.
> > >
> > > - Perhaps a reference to implementing NRPE with stunnel (and
> > > only permitting
> > > connections from localhost, as defined in nrpe.cfg) would be
> > > desireable.
> > >
> > > I'm not a security guru, but it seems to me that facilitating
> > > this feature
> > > would open oneself up to a buffer overflow attack.  If you're
> > > on a trusted
> > > network, it's a non-issue.
> > >
> > > On a related note, I'd be much more comfy with this feature
> > > if there were a
> > > facility to enforce some level of native encryption, such as
> > > what NSCA uses.
> > > If you don't have the keys to the house, you get dropped on
> > > the floor.  (I
> > > have a similar wish for NSClient.)
> > >
> > > Food for thought.
> > >
> > > jc
> > >
> > > > -----Original Message-----
> > > > From: Dave Viner [mailto:dviner at yahoo-inc.com]
> > > > Sent: Friday, December 27, 2002 11:48 AM
> > > > To: Nagios-users at lists.sourceforge.net
> > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > >
> > > >
> > > > In order to clarify the idea that I'm proposing, I've made a
> > > > patch to the nrpe source that implements what I'm describing.
> > > >  This patch is made against the nrpe-1.5.tar.gz from
> sourceforge.
> > > >
> > > > Essentially, these changes allow us to specify in the
> > > > nrpe.cfg file lines like this:
> > > >   command[check_disk_gen]=/usr/local/libexec/nagios/check_disk
> > > >
> > > > Then when invoking check_nrpe, you can invoke it like this:
> > > >   ./check_nrpe 127.0.0.1 -V 2 -c check_disk_gen -a "-w 50000
> > > > -c 10000 -p /dev/ad0s1e"
> > > >
> > > > And the effect is that /usr/local/libexec/nagios/check_disk
> > > > is invoked with the -w 50000 -c 10000 -p /dev/ad0s1e as the
> > > > argument string.  For example:
> > > >
> > > > ~/nagios/nrpe-1.5.new/src>./check_nrpe 127.0.0.1 -V 2 -c
> > > > check_disk_gen -a "-w 50000 -c 10000 -p /dev/ad0s1e"
> > > > DISK OK - [1484108 kB (9%) free on /dev/ad0s1e]
> > > > ~/nagios/nrpe-1.5.new/src>
> > > >
> > > > I think this is really useful and would greatly reduce the
> > > > size of the nrpe.cfg and, more importantly, would reduce the
> > > > number of times you'd need to modify that configuration file.
> > > >  Instead the modifications would occur on the centralized
> > > > Nagios server's configuration file.
> > > >
> > > > What does everyone think?  Should we add this to the main
> > > > source for NRPE-1.6?
> > > >
> > > > dave
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: nagios-users-admin at lists.sourceforge.net
> > > > [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
> > > > Dave Viner
> > > > Sent: Monday, December 23, 2002 8:51 AM
> > > > To: Naios Users
> > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > >
> > > >
> > > > Hi Rue,
> > > > 	Security is a great reason for limiting the commands
> > > > that NRPE is able to execute.  But my suggested enhancement
> > > > wouldn't allow NRPE to execute any command that isn't listed
> > > > in the cfg file.  That is, the NRPE would still need to find
> > > > the path to the executable in the nrpe.cfg file, then use any
> > > > remaining information as arguments passed to the executable.
> > > > It is true that this is less secure that forcing the entire
> > > > command line (executable and arguments) in the config file.
> > > > But, so long as the executables are well authored and handle
> > > > unexpected arguments well, I think this enhancement would not
> > > > significantly decrease security.  Do you think that
> > > > specifying arguments would make NRPE significantly less secure?
> > > >
> > > >
> > > > Dave
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: nagios-users-admin at lists.sourceforge.net
> > > > [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
> > > > Rue Turner
> > > > Sent: Friday, December 20, 2002 1:33 PM
> > > > To: Naios Users
> > > > Subject: Re: [Nagios-users] NRPE enhancement
> > > >
> > > >
> > > > dave,
> > > >
> > > > I think the reson for this choice of configuration is
> > > security. If the
> > > > nrpe was allowed to run whatever it was asked it would
> be easy to
> > > > compromise your machines. This way although your configs are
> > > > hefty (mine
> > > > have almost a hundred lines in) you can only ask it to run
> > > > commands from
> > > > this library.
> > > >
> > > > rue
> > > >
> > > >
> > > > On Fri, 2002-12-20 at 17:35, Dave Viner wrote:
> > > > > Hi,
> > > > > 	I'd like to suggest an enhancement to NRPE, and if
> > > > people think this is a
> > > > > good idea, I'll try to make a patch to support my
> > > > suggestion.  Currently the
> > > > > nrpe.cfg file specifies all the commands in this fashion:
> > > > >
> > > > command[check_disk1]=/usr/local/nagios/libexec/check_disk 80
> > > > 95 /dev/hda1
> > > > > As result of this design is that if you want to check
> > > something like
> > > > > /dev/hda1 and /dev/hdb1, you need two seperate lines in the
> > > > nrpe.cfg file.
> > > > > 	So, I'd like to propose that we extend NRPE to allow
> > > > for the arguments to a
> > > > > command to be specified by the central Nagios server
> > > > instead of in the
> > > > > nrpe.cfg.  The idea is that the nrpe.cfg would have one
> > > > command line which
> > > > > maps a key, 'check_disk', to a local executable,
> > > > > '/usr/local/nagios/libexec/check_disk'.  The rest would be
> > > > specified from
> > > > > the central Nagios server in some manner.
> > > > > 	I think this would great simplify the nrpe.cfg files,
> > > > and reduce a lot of
> > > > > redundant command definitions that differ only in the
> > > arguments they
> > > > > require.  Also, it would mean that you'd need to update
> > > > your nrpe.cfg very
> > > > > rarely.  In fact, you'd only need to update it when you add
> > > > a new plugin.
> > > > > 	I don't have a concrete suggestion for implementing
> > > > this yet, because I
> > > > > want to see if the community is interested in this idea
> > > > first.  Has this
> > > > > idea been suggested previously?  Is anyone currently
> > > > interested in the idea
> > > > > or would I be the only consumer of such a service?
> > > > >
> > > > > thanks
> > > > > dave
> > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This SF.NET email is sponsored by:  The Best Geek
> Holiday Gifts!
> > > > > Time is running out!  Thinkgeek.com has the coolest gifts for
> > > > > your favorite geek.   Let your fingers do the typing.   Visit
> Now.
> > > > > T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> > > > > _______________________________________________
> > > > > Nagios-users mailing list
> > > > > Nagios-users at lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > >
> > > >
> > > >                       r u e  t u r n e r
> > > >   · t · h · i · n · l · a · y · e · r ·
> > > >
> > > > -- index, n.: Alphabetical list of words of no possible
> > > interest where
> > > > an alphabetical list of subjects with references ought to be.
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> > > > Time is running out!  Thinkgeek.com has the coolest gifts for
> > > > your favorite geek.   Let your fingers do the typing.
> Visit Now.
> > > > T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> > > > _______________________________________________
> > > > Nagios-users mailing list
> > > > Nagios-users at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Nagios-users mailing list
> > > > Nagios-users at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Nagios-users mailing list
> > > Nagios-users at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-users
> >
>
>
>
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios at nagios.org
> Website: http://www.nagios.org
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
>


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf