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

[Grant Taylor]

On 10/16/23 9:51 PM, Jeremy Laidman wrote:
> 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").

Okay.  That sounds very promising.

I had naively assumed that xymonnet used some sort of IPC to xymond and 
was thus dependent on it.

Now I get the impression that it's more that xymonnet needs a properly 
configured environment and that the easiest way to do that is to use 
Xymon / xymonlaunch to manage that for you.  But it sounds like it's 
quite possible to crate said environment and call xymonnet directly.

> 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

Very good to know.

I ran into a situation this evening where I need to duplicate the 
firewalled environment behind another host that is currently a stand 
alone client.

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

Yep.

I suspect that I'll be installing the distro provided xymon-server and 
tweaking tasks.cfg to run the client, xymonnet, and xymonnet-again.  But 
not the xymond / display server.

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

Good to know.

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

Noted.

> 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 aware of them and I've skimmed (parts of) their manual pages.  I've 
not yet needed to go to -- what I call -- the poll methodology. 
Currently, -- ... -- the push methodology has been sufficient to get 
data from clients to the server.

The biggest hiccup I've had is running xymonnet inside the firewalled 
network.

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

Interesting idea.

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

Understood and appreciated.

But if Xymon is running as anything other than root, it's chances of 
reading the /etc/shadow file are -- dare I say -- exceedingly small.

But I completely get that Xymon coding errors could make it possible to 
read any file that the user that Xymon is running as can read.

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

Yep.

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

Yep.

I fully understand that the capability can be used by a bad actor, even 
if I don't use it myself.

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

I should investigate that.

I assume that a firewall also helps here.

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

Doesn't the download feature also have a more lax mode where it will 
allow you to download things that aren't config files?  Or am I 
conflating config and download?

I also wonder where the command comes into play to have clients download 
updated (tar files) from the central server and install them.



-- 
Grant. . . .
unix || die