gSOAP communication between modules/plugins

Mathieu Grzybek grzybek.mathieu at ig2i.fr
Fri Apr 27 22:14:34 CEST 2007


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=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).
>   
This problem is everywhere. Buffer overflows are dangerous for socket 
connections. Nothing is perfect.
> 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.
>
>   
Do you mean encapsulating the actual protocol ?
>> 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 /"?
>
>   

NRPE can be run with limited privileges and use sudo for some event 
handlers. In large structures I think it's more convient than creating a 
new deployment process with OCS Inventory.

>> 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?
>
>   

The IT boss doesn't want to control the servers but wants to know if it 
runs.

> Cheers,
>
> Paul.
>
>   

Cheers,

Mathieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20070427/385d6826/attachment.html>
-------------- 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


More information about the Developers mailing list