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

[Jeremy Laidman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20231017/8c17b2a5/attachment.htm>