NRPE enhancement
Carroll, Jim P [Contractor]
jcarro10 at sprintspectrum.com
Mon Dec 30 19:49:04 CET 2002
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
More information about the Users
mailing list