Re: [Nagios-devel] gSOAP communication between modules/plugins

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

Re: [Nagios-devel] gSOAP communication between modules/plugins

Post by Guest »

This is a multi-part message in MIME format.
--------------070300080607080208060406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Paul,


Paul Millar a écrit :
> Hi Mathieu,
>
> I'm a little confused by what you're saying, so my apologies if we're talking
> at cross-purposes.
>
> On Friday 27 April 2007 14:01, Mathieu Grzybek wrote:
>
>> Concerning communication between remote modules/plugins I found a
>> problematic infrastructure: servers behind proxies. How can you communicate
>> through a proxy server?
>>
>
> OK, I'm a bit confused about what the problem here is actually.
>
> You mention "remote modules/plugins". Are we talking about:
> a. NPRE (on a remote machine) and Nagios trying to communicate,
> or
> b. log2dno, file2sock or ndomod trying to communicate with ndo2db
> (or perhaps both)?
>
> I'm confused because you mention both NDOutils and NPRE below.
>
>

In fact I thought of ndomod/ndoutils. I must have written too fast !

> I'm also confused why a proxy is the problem?
>
> From what I understand, ndoutils' ndo2db listens on a TCP port (port 5668, by
> default) for incoming TCP connections. However, this is contengent on the
> remote server's being on a routable part of the network: it must be possible
> for IP packets from the Nagios server to traverse the network and end up on
> the remote server.
>
> I guess this could not happen for a number of reasons. The two that I can
> think of are:
> if the remote server has a private IP address and routed through a NAT box,
> if the remote server is behind a firewall that blocks port 5668.
>
> So, I'm guessing some firewall/NAT-box is the real issue here: that all
> external traffic is blocked.
>
>
>> To solve this problem I began to replace the socket-based communication
>> process of NDOutils by gSOAP services (HTTP+XML).
>>
>
> So, the machine running ndo2db is behind a firewall, blocking all ports. The
> only communication with this machine is via a web-proxy.
>
>
This is a company with a HQ and several independant sites. The
monitoring database is hosted in the HQ. The servers running
Nagios+ndomod in the other sites are behind a firewall and the only way
to communicate with the world is a web proxy server. This case is very
common. Everyone can't rent a wide intranet connection and/or a VPN.
In most cases there is a website hosting by the HQ. No new port needed,
just mod_soap and ndo2db.

> Yes, using web-services is certainly one way to proceed. There are some other
> solutions that spring to mind:
> XML-RPC (a more light-weight solution, which gSOAP supports),
> embedding webserver (e.g. lighttpd) for a more RESTful approach,
> implement a proxy relay for NDOutils communication,
> get your sys-admin to allow the TCP connections you need.
>
> The last one isn't flippant. (If I've understood correctly) your real problem
> here is TCP connections not going through.
>
> Perhaps drifting slight off-topic (and perhaps a slightly contentious
> point-of-view), but web-services exist because of contention between
> sys-admins (trying to lock down access to a machine) and programmers (wanting
> to allow remote communication). If you allow someone to tell a remote
> machine to do something, that machine is potentially vulnerable.
>
> Now, practically the only ports you're pretty much guaranteed to have open is
> for web traffic (ports 80 and 443, maybe ports 8080 and 8443). So,
> to "bypass" the firewalls, RPC communication is now done via a web port.
>
> But, the underlying problem remains: allowing someone to tell a remote machine
> to "do something" results in a potential security vulnerability. And, of
> course, people have noticed this. See (for example)
> http://www.xmlhack.com/read.php?item=63 ... ment%3A623
> This has led to products to "protect" against this sort of problem:
> http://www.xtradyne.com/products/ws-dbc/ws-dbc.htm
> (this was just the first one Google found, I'm sure there's more out there).
>
This problem is everywhere. Buffer overflows are dangerous for socket
connection

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Locked