gSOAP communication between modules/plugins

[Paul Millar]

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.

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.

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=630&v=1&t=comment%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).

Using webservices will solve your problem now; but, if the firewalls are 
altered to block all SOAP messages, then you have no solution again :-(
This is also true for other RPC-like communication (like XML-RPC).

I must confess to not being very keen on SOAP.  I've found its suffers from 
being fragile against WSDL updates and the message encapsulation is (to my 
mind) overly complex.

If you do want to implement a webservice, I'd do it as a translation service 
rather than replacing the existing TCP communication.

> Moreover, using this process, NRPE could get its config file easily when a
> process between it and nagios is established.

True, but the same could be implemented through the existing communication.  
The protocol between Nagios and NRPE is quite primitive at the moment (i.e. 
quite robust! :-), but I guess it could be extended to include downloading 
configuration files.

However, do you really want someone to be able to download a new config that 
defines the "check_pw" command as "cat /etc/passwd /etc/shadow" or 
a "check_rm" command as "rm -rf /"?

> What do you think of my idea ?

Sorry, I guess I don't fully understand what the problem is here.  Ultimately, 
if you cannot access (via TCP) the machines and cannot alter this, why are 
you trying to monitor them?

Cheers,

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20070427/8b2037a9/attachment.sig>
-------------- next part --------------
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel