nrpe and nrpe_nt development

[local.coder]

2 points then.

I will look at my code changes for the ssl and look into 2 options and hope the
nt conversion doesn't have alot of changes.

First the ability to gen a nagios server x.509 cert from make that can then be
put with the clients for validation.

Second (not sure if this is needed) an option for client side certs that can
then be specified on the nagios server so he can validate the client.

Point 2.

The man in the middle attack is a bit difficult. The server and the client
generate an ssl session useing a keyless ike setup. This means that once the
two have changed keys the man in the middle is unable to work the session. The
arp cache poison issue would really only work if you are local to the client
system or local net to the nagios server, and can take the nagios server
offline. This goes back to if your not on the local net with the nt client then
you can't poison his arp table since he will only have the local router arp
entry.

I can understand the IP only issue. I use nrpe primarily in a unix wolrd with
tcp_wrappers or filter tables, so I can see the validity in some cert exchange
setup for additional authentication.

I also agree that including BF would not be a bad idea at all as I am a huge fan
of the blowfish code, my only concern there is the static passwords in config
files. But having several choices in implementation is part of what nagios is
all about. I don't see why anyone would complain about having the BF code in
the cvs version with a simple --with-blowfish if you want it enabled otherwise
disable by default like the ssl.

Also I agree that there should be a seperate set of nt plugins, both source and
compiled but they should follow the same names of the unix counterparts and
carry the same arguments and eventual performance reporting.

Give me a day or two and I will see how long I think the ssl certs will take to
get into the cvs code.

Thanks,
Derrick

Quoting Stephen Strudwick <sas at pipex.net>:

>
> I've been thinking about this a lot last night, about different ways to
> implement private/public keys with open ssl to verify the nagios server is
> the real one etc.
>
> Ive decided in the end that for me the easiest approach is just to code in
> a blowfish compile time option as I have BF code tried and tested that can
> easily be added.
>
> Im going to code this up over the next week or two, then the nagios
> developers can then decide if they want to include it or not.
>
> On a side note..
>
> I had a minor arguement with someone at pipex who thought IP restrictions
> should be enough, but I done some research and im pretty sure I could
> spoof an IP using poisoned arp packets to pretend I am the nagios server,
> (effectivly a man in the middle attack, ideally I would need to be on
> the same lan to do this).
>
> once I do that I could execute plugins on the server we are monitoring
> and dos it or possibly exploit a plugin (although unlikely if not passing
> arguements).
>
> I might try this next week as an experiment.
>
> Adding some kind of authentication option to the security design would
> just make it that bit harder for anyone to exploit.
>
> I have to be really careful because we tend to be under constant attack
> from malicous people being a fairly big UK isp.
>
> -
> Stephen Strudwick
> Advanced Development Engineer
> Development Group, Product Development
> PIPEX Communications
> http://www.pipexcommunications.net/
>
> Mobile: 07906 191256
> Direct: 020 8957 1217
>
> On Thu, 18 Dec 2003, Subhendu Ghosh wrote:
>
> > A nice balancing act is what is needed :)
> >
> > my 2 cents.
> >
> > I like the configure time option of including blowfish even at the risk of
> > additional conifguration requirements.  Since check_nrpe is only available
> > thru the NRPE distribution, blowfish doesn't add an extra requirement for
> > the general plugin dist.
> >
> > I like being able to send ARGx to the remote plugins via NRPE.
> >
> > Lastly - if nrpe_nt is to flourish, we need a repository for the Windows
> > specific plugins. My feeling is that this should be both a binary and a
> > source repository as not all windows system will have the requisite
> > toolset.
> >
> > -sg
> >
> >
> > On Thu, 18 Dec 2003, Stephen Strudwick wrote:
> >
> > >
> > > > This also goes back to whether you are allowing check_nrpe to execute
> argument$
> > > > For security we don't we only allow defined checks to run with no
> arguments and
> > > > most agree that is the safer option. If there is a feeling that the
> server
> > > > should be authenticated by the clients using a cert then that is
> something I
> > > > can work on putting in place without much heartache and we would just
> need to
> > > > automate the creation of self signed certs in the make process to
> simplify the
> > > > procedure.
> > >
> > > When we have run netsaint in the past with nrpep we had command line
> > > arguements, but I planned to stop doing this with nagios mainly because I
> > > thought it wes unecessary complication as well as a security risk.
> > >
> > > We do need more security than the basic IP checks here at pipex because
> we
> > > cant be sure our servers will have tcp wrappers on them (mainly NT is the
> > > problem here) or be behind a firewall.
> > >
> > > we have to be as sure as we can (to the poiht of maybe being too zealous)
> > > that the servers are not compromised in any way.
> > >
> > > > If there is a feeling that the server
> > > > should be authenticated by the clients using a cert then that is
> something I
> > > > can work on putting in place without much heartache and we would just
> need to
> > > > automate the creation of self signed certs in the make process to
> simplify the
> > > > procedure.
> > >
> > > something like this would be really good, if you point me in the right
> > > direction im willing to code something over xmas, because im working to a
> > > early jan deadline :(
> > >
> > > I really want to make sure whatever is done is accepted into the code
> base
> > > so that our operations people can always download the latest version from
> > > the site and not use a hacked about version that instantly becomes
> > > static in development.
> > >
> > > -
> > > Stephen Strudwick
> > > Advanced Development Engineer
> > > Development Group, Product Development
> > > PIPEX Communications
> > > http://www.pipexcommunications.net/
> > >
> > > Mobile: 07906 191256
> > > Direct: 020 8957 1217
> > >
> > > On Thu, 18 Dec 2003, local.coder wrote:
> > >
> > > >
> > > > Stephen,
> > > >
> > > > When coding in the encyrption the idea was to secure the data between
> the nagios
> > > > server and the remote client. The use of passwords and other options
> were
> > > > specifically removed to keep out problems with plaintext password
> management
> > > > and other fun. This is meant as a data protection scheme only and not
> an
> > > > authentication scheme. The IP Address restriction for us is enough to
> limit
> > > > remote hosts. With some minor changes the openssl part could be setup
> to use
> > > > pre-shared certs but when talking with others that went to a level of
> > > > complexity that seemed overwhelming for large server bases and updates.
> I
> > > > originally was working with the blowfish encryption but at Ethan's and
> plugin
> > > > people's request moved to openssl since it is already included in other
> plugins
> > > > as a requirement and there was a concern to keep external requirements
> to a
> > > > minimum if possible.
> > > >
> > > > This also goes back to whether you are allowing check_nrpe to execute
> arguments.
> > > > For security we don't we only allow defined checks to run with no
> arguments and
> > > > most agree that is the safer option. If there is a feeling that the
> server
> > > > should be authenticated by the clients using a cert then that is
> something I
> > > > can work on putting in place without much heartache and we would just
> need to
> > > > automate the creation of self signed certs in the make process to
> simplify the
> > > > procedure.
> > > >
> > > > Like I say I didn't want to have static passwords in the config files
> for
> > > > authentication because to me that gave a false sense of bad security.
> > > >
> > > > Derrick
> > > >
> > > >
> > > > Quoting Stephen Strudwick <sas at pipex.net>:
> > > >
> > > > >
> > > > > I also forgot to add that I've written a load of plugins for nrpe_nt
> in C
> > > > > such as check disk, eventlog, cpu load, mem load, services etc.
> > > > >
> > > > > I will release the source and binaries as soon as we have finished
> testing
> > > > > on them.
> > > > >
> > > > > -
> > > > > Stephen Strudwick
> > > > > Advanced Development Engineer
> > > > > Development Group, Product Development
> > > > > PIPEX Communications
> > > > > http://www.pipexcommunications.net/
> > > > >
> > > > > Mobile: 07906 191256
> > > > > Direct: 020 8957 1217
> > > > >
> > > > > On Thu, 18 Dec 2003, Stephen Strudwick wrote:
> > > > >
> > > > > > hello all,
> > > > > >
> > > > > > This is my first post to this list and I want to ask some questions
> > > > > > about my company (Pipex) doing some development for nrpe and
> nrpe_nt.
> > > > > >
> > > > > > We have been using netsaint for a while and are upgrading to nagios
> and
> > > > > > have decided to use nrpe for nt and unix boxes.
> > > > > >
> > > > > > I noticed the encryption using openssl is not really that secure,
> as far
> > > > > > as I can tell it only encrypts the session between the client and
> server
> > > > > > and dosnt stop anyone else with the nrpe client querying the
> server.
> > > > > >
> > > > > > The only protection the demon has as far as I can tell is the IP
> > > > > > restrictions.
> > > > > >
> > > > > > We have some internal code we have been using for several years
> here that
> > > > > > provides Blowfish encryption using shared keys, username pass
> > > > > > authentication and all kinds of handshaking and security.
> > > > > >
> > > > > > The code is in C, and we have modules for *nix and NT.
> > > > > >
> > > > > > we also have an implementation as a Perl module (with C backend
> code).
> > > > > >
> > > > > > I would like to add this code to nrpe as a compile time option (say
> > > > > > --use-blowfish on ./configure).
> > > > > >
> > > > > > And also to the NT version.
> > > > > >
> > > > > > If I add this code I would like if possible to be integrated into
> the
> > > > > > current releases of nrpe so we dont create a static fork inside our
> > > > > > company).
> > > > > >
> > > > > > Basically im looking for feedback as to whether this is
> neccessary/right
> > > > > > thing to do, or have I misunderstood the openssl encryption.
> > > > > >
> > > > > > I envisage the shared key encryption working like nrpep with a -s
> > > > > > <secret> option being used for a secret on the nagios server.
> > > > > >
> > > > > > Thanks in advance for any feedback.
> > > > > >
> > > > > > -
> > > > > > Stephen Strudwick
> > > > > > Advanced Development Engineer
> > > > > > Development Group, Product Development
> > > > > > PIPEX Communications
> > > > > > http://www.pipexcommunications.net/
> > > > > >
> > > > > >
> > > > > >
> >
> > --
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Nagios-devel mailing list
> > Nagios-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-devel
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click