[Xymon] Looking for clarification on Xymon client / server hierarchy.

[Jeremy Laidman]

On Tue, 17 Oct 2023 at 12:34, Grant Taylor via Xymon <xymon at xymon.com>
wrote:

> The scenario that I'm working with can be described as a primary Xymon
> (display) server in one network with a small lab network behind a NATing
> / SPI firewall.  Clients on the inside side / opposite of the Xymon
> server are free to send outgoing packets.  It's just that xymonnet
> running on the Xymon server can't send probes into the clients.
>
> > You can run xymonnet stand-alone, and set environment variables to tell
> > it where to send its messages. If you already have a xymon client
> > installed on the client host, you can execute xymonnet from
> > clientlaunch.cfg and it should then know where to send packets due to
> > the environment that is setup.
>
> Oh!  This is promising.
>
> I misinterpreted comments in the tasks.cfg file to mean that xymonnet
> depended on xymond.  Now it sounds like xymonnet can be satisified by
> the xymon client.
>

Indeed. Perhaps more precisely, it can be satisfied by xymonlaunch, which
also runs the main Xymon client script (xymonclient.sh). It's also possible
to run xymonnet from cron, or set it up as a systemd service, or even
trigger its execution by running from a remote ssh session (something like
"ssh client-host /usr/local/bin/xymonnet
--env=/usr/local/etc/xymonnet.conf"). In most cases, running from within a
xymoncmd environment (which is implied when run by xymonlaunch) takes away
the need to explicitly set all of the required options. So you could have a
cron job like so:
*/5 * * * * xymon /usr/lib/xymon/client/bin/xymoncmd
/usr/local/bin/xymonnet >>/var/log/xymon/xymonnet.log 2>&1

But it's worth taking a look at the xymonnet entries in the tasks.cfg file
on the Xymon server. There is a xymonnet-again (I think) task that runs
more frequently but only performs probes for failed tests. In this way when
a fault is detected, the polling rate increases so that you can more
quickly see when a service is restored, and SLA times are more accurate.

Running xymonproxy + xymonnet + xymonclient on a system inside of the
> firewall might do what I'm wanting to do.
>

I don't think xymonproxy is required for this. If your clients can talk
directly to your xymon server on TCP/1984, then that's all xymonclient.sh
and xymonnet need to be able to do. I think xymonproxy is only required if
your clients can't connect directly to your server. And it will add delays,
and become an extra point of failure.

If you haven't already, look into msgcache and xymonfetch. These can be
used to bridge networks in a slightly different way to xymonproxy.

I'm quite okay with '${XYMON} ${XYMSRV} "config hosts.cfg" > hosts.cfg'
> on the internal system running xymonnet.
>

Makes sense, and should work fine.

I actually like "xymongrep" for its ability to do searches. By default it
looks for hosts.cfg, but if given the --loadhostsfromxymond switch, it'll
connect to the Xymon server and send a "config hosts.cfg" command and
filter for the tags you're interested in. So you could do something like:

xymoncmd xymongrep "NET:behindfirewall" > hosts.cfg

(multiple search strings can be used, and lines that match any of them will
be returned)

This brings up a possible issue for some installations and security
postures. In a multi-network multi-security-level environment, some
consider the "config" command to be a feature that's not worth the
potential risk. For example, if there's a coding error in Xymon, there
might be a way to request the config file /etc/shadow. Or if someone
doesn't realise that hosts.cfg is potentially exposed outside the Xymon
server in this way, they might put a password or private key in the
hosts.cfg file (eg in a tag for a custom extension). An example of this is
that the "devmon" add-on uses the DEVMON: tag to specify SNMP parameters,
including community string, and the operator might not realise that the
community strings are accessible by any Xymon client.

If this is of concern to you, then you should consider ways to mitigate
this. Choosing to not use this feature in your scripts doesn't mean an
attacker can't do so.

I don't know if there's a way to prevent "config" messages from being
honoured by the xymond process. It's possible to have xymond ignore
messages (including config) from IP addresses that aren't in hosts.cfg, so
this will minimise any exposure.

There's a similar feature where you can send a "download" message and
receive a copy of the named file. The download feature can be disabled by
adding "--no-download" to the xymond command line arguments.

Cheers
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20231017/aa4c0fe7/attachment.htm>