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