On Tue, 17 Oct 2023 at 14:19, Grant Taylor via Xymon <xymon at xymon.com> wrote:
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.
Correct. The man page for xymonnet should cover the various env vars that it supports. I think the only ones that might be required are some combination of (XYMSRV, XYMONSERVERS, XYMSERVERS) as per doco to specify the display servers, and access to the hosts.cfg file, and XYMONTMP. In fact if you run xymonnet with the --loadhostsfromxymond switch, it doesn't even need a local copy of hosts.xfg. Try something like this from a device in your enclave, and see if the output looks OK, then drop the --no-update to run it for real:
XYMSERVERS=xymon-server-or-IP XYMONTMP=/tmp /usr/lib/xymon/server/bin/xymonnet --no-update --loadhostsfromxymond
Optionally, try the --debug and/or --dump switches. You can specify the FQDN of a target server if you just want to probe one device (eg for testing).
You can set XYMONNETWORK to something in the NET: tags in hosts.cfg, and only those devices will be polled. So in hosts.cfg:
10.1.2.3 mywebserver.example.com # NET:enclave
XYMSERVERS=xymon-server-or-IP XYMONTMP=/tmp XYMONNETWORK=enclave /usr/lib/xymon/server/bin/xymonnet --loadhostsfromxymond
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.
Yep, agreed. And if that's the only exposure, then we're golden. Might be a private key that the Xymon user accesses to authenticate for one of its probes to an HTTPS server with client auth. Might be /var/tmp/ps-dump that someone is running from their cron, to diagnose some fault, not realising that someone else's process has "--with-password=M0nkey", because that user didn't realise that args are visible to all. Might be a core dump that someone copied to /tmp/, without knowing that they can contain passwords and private keys.
Of course most possible exploits are really unlikely, and require a bit of stupidity and a bit of mis-fortune. I'm not trying to suggest likely exposures, just possible exposures under some circumstances. We can't mitigate all of them, but we can address the likely ones even if it takes effort, and we also should address the unlikely ones where it takes very little effort.
I suppose my point here is, if a client doesn't need to access an arbitrary file on a server, then it shouldn't be able to. If a client doesn't need to access any file on a server, then it shouldn't be able to. And a feature that permits this, and is on by default, and is seldom used or necessary, and is possibly not known about by the sysadmin, probably should be addressed, or at least assessed.
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.
Only for some threat models. Every xymon client has to be able to connect to the xymon server on TCP/1984[*]. A firewall can allow or deny that. But a firewall can't allow status and data messages while blocking config messages. I'm not aware of a DPI firewall that can parse Xymon packets.
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 actually don't know. I don't use either of these features.
I also wonder where the command comes into play to have clients download
updated (tar files) from the central server and install them.
Yes. If my memory serves, the original BigBrother, on which Xymon was based, was often deployed so that it could upgrade itself. This process required that the BB server had tarballs of the various clients. The clients would periodically check their versions with the latest available, and if there was an updated, the client would fetch it and untar over itself.
This mechanism was in place when compiling from source code was the only way to deploy open source. So it seemed like a good idea at the time. And it has merit. But these days, we're all used to using packages, and we make good use of the additional features a package manage can bring. So the way I see the download command is that it's a relic from a previous generation, that most people won't ever use. Might come in handy, but if there's another way to do it, probably use the nother way.
J