Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi Mathieu,
I'm a little confused by what you're saying, so my apologies if we're talki=
ng=20
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 communica=
te
> 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?
=46rom what I understand, ndoutils' ndo2db listens on a TCP port (port 5668=
, by=20
default) for incoming TCP connections. However, this is contengent on the=
=20
remote server's being on a routable part of the network: it must be possibl=
e=20
for IP packets from the Nagios server to traverse the network and end up on=
=20
the remote server.
I guess this could not happen for a number of reasons. The two that I can=
=20
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=20
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. T=
he=20
only communication with this machine is via a web-proxy.
Yes, using web-services is certainly one way to proceed. There are some ot=
her=20
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 prob=
lem=20
here is TCP connections not going through.
Perhaps drifting slight off-topic (and perhaps a slightly contentious=20
point-of-view), but web-services exist because of contention between=20
sys-admins (trying to lock down access to a machine) and programmers (wanti=
ng=20
to allow remote communication). If you allow someone to tell a remote=20
machine to do something, that machine is potentially vulnerable.
Now, practically the only ports you're pretty much guaranteed to have open =
is=20
for web traffic (ports 80 and 443, maybe ports 8080 and 8443). So,=20
to "bypass" the firewalls, RPC communication is now done via a web port.
But, the underlying problem remains: allowing someone to tell a remote mach=
ine=20
to "do something" results in a potential security vulnerability. And, of=20
course, people have noticed this. See (for example)
http://www.xmlhack.com/read.php?item=3D ... 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).
Using webservices will solve your problem now; but, if the firewalls are=20
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=
=20
being fragile against WSDL updates and the message encapsulation is (to my=
=20
mind) overly complex.
If you do want to implement a webservice, I'd do it as a translation servic=
e=20
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 implement
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]