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 :
>
> 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
> > sour
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]