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