NRPE enhancement
Carroll, Jim P [Contractor]
jcarro10 at sprintspectrum.com
Mon Dec 30 18:32:34 CET 2002
As much as I'm concerned with the increased risks of the proposed NRPE
enhancement, I'd like to add some perspective.
Tom Welsh wrote:
> 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.
Giving a newbie a Linux distro on CD-ROM and letting him install it and
connect it to an untrusted network is an accident waiting to happen.
Arguably a much bigger accident.
I would argue that having the 'enhanced' version squawk with something like:
WARNING!!!! You have started a non-default version of
NRPE which is considered less secure than the default
version! Unless this is being run on a trusted network,
it is STRONGLY recommended you recompile NRPE with the
default options! (Refer to the README included in the
original tarball.)
each and every time it's started will tend to be noticed by most
somewhat-security-aware sysadmins, I would think.
> It only takes 1 security breach via a plugin to completely destroy the
> good name Nagios and its associated plugins have.
Hmm. 'Via a plugin'? Yeah alright, I can see that, if it's running with
suid. I don't see that as an inherent risk with check_by_ssh, since that
would depend on the SSH installation. (If you really wanted to, you could
get pretty lame with SSH.) Security of the Nagios host itself would depend
on locking it down, of course, and making sure you're not running a 'Swiss
cheese' http server. The Nagios processes (if the docs are followed to the
letter) run under user nagios, not root, or any other UID 0 account.
What about NSClient? No crypto, no SSH option, no restrict-by-IP option in
the client's config. Sure, you can use stunnel, but you still have to have
a port open on the Windows client, and there's no way to restrict it to
127.0.0.1, short of adding a software firewall solution. (My apologies to
the Windows gurus on the list if such a feature currently exists.)
> There is a good truism that states "good news travels fast,
> but bad news
> travels even faster"
"Everything in moderation, even moderation." -- Buddha
> 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.
We have at least one command available for executing commands remotely.
It's called ssh.
Alright, I'm being the devil's advocate here. :^)
All I'm saying is, perhaps it should be the sysadmin's choice whether he/she
wants to install something considered more secure or less secure than what
his/her bretheren/sisters are using. I still cringe when I find out someone
wishes to enable telnetd. If the application boldly states that it's
running in a less secure configuration than can be had and the sysadmin
boldly accepts that risk, so be it. Nothing's stopping anyone from running
rshd/rlogind/rexecd with "+" in hosts.equiv, for example, and unless you
pick up a book on UNIX security, it may not occur to you what the risks are.
Certainly the r-daemons don't give you any such warning.
I personally wouldn't implement the 'enhanced' version of NRPE, but so long
as the appropriate caveats were in place, I don't see why someone else
shouldn't be given the chance.
If it appears that I'm sitting on the fence, that's because I am.
Creativity means growth; stifling creativity would eventually sound the
death knell of any software development. There will always be some risk if
a system is powered up and connected to a network. Security holes come
about as the results of poor coding or design oversights, a.k.a. 'bugs'.
Any non-trivial piece of code will have bugs. I seem to recall reading
somewhere that it's not possible to prove that a given piece of code is
bug-free; failure to find a bug does not constitute proof that the code is
clean, whereas finding a bug proves the trivial case that at least one bug
exists.
It might be an interesting exercise to continue to enhance NRPE, even adding
trivial security such as password authentication, rot13, identd support....
*shrug* Perhaps Mr. Viner would rise to the challenge...?
> Well that's my two cents worth
Add my $0.015 to the pile. :^)
jc
> 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
More information about the Users
mailing list