On 10/17/23 12:37?AM, Jeremy Laidman wrote:

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

I'll give that a try.

I think there is some benefit to leveraging xymonlaunch as in it's somewhat more common way to start / stop a process than modifying crontab. But that's more outside of Xymon's wheelhouse.

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

I need to try this with a couple of systems that seem to keep flapping on TLS protected services when their unencrypted counterparts don't flap. -- I think I saw a bug about a patch this year about a latency sensitive issue that may be related.

You can set XYMONNETWORK to something in the NET: tags in hosts.cfg, and only those devices will be polled. So in hosts.cfg:

Yep. I'm doing exactly this.

I've got three separate Xymon installations that I'm helping administer:

• $DAY_JOB -- has two environments, production in primary DC and DR in a secondary DC. There is incomplete communications between prod and DR. Hence the need for xymonnet, and maybe xymonproxy, in DR for things in DR to be tested properly.
• $PERSONAL -- single site, common configuration.
• $HELPING_A_FRIEND -- Now three sites; production, office, and friend's house. Where office and friend's house are basically SOHO NATing routers that port forward SSH to an internal host. So I'll be looking at xymonclient + xymonnet therein.

10.1.2.3 mywebserver.example.com # NET:enclave

Yep, I've got something like this already. It's working great.

XYMSERVERS=xymon-server-or-IP XYMONTMP=/tmp XYMONNETWORK=enclave /usr/lib/xymon/server/bin/xymonnet --loadhostsfromxymond

I'll definitely give that a try for manual debugging.

But for normal production, I think a distro package of xymon-server with a trimmed down tasks.cfg to run xymonclient and xymonnet will suffice and be clean with OS init script expectations.

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.

All very valid examples of -- what I generally consider -- Oops! type mistakes / unintentional exposures.

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.

ACK

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

I've often heard this as "business justification". Which I have heard a translation of that I like better; "what benefit does doing this provide to the business". IMHO "justification" can have negative connotation and / or baggage associated.

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.

ACK

I'm not aware of a DPI firewall that can parse Xymon packets.

I strongly suspect that I could configure an IPTables "string" match to detect requests in normal unencrypted traffic.

But your point is taken and I digress. ;-)

I actually don't know. I don't use either of these features.

I've used the config support a few times.

I like the idea of having xymonnet --loadhostsfromxymond, which I assume needs config support.

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.

I used the option to pull in a tar file using clientversion (syntax from memory) once. I can see using it to distribute additional local files and / or extensions.

We'll see.

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.

Eh ... package managers have their place. But they don't, and IMHO, shouldn't cover everything. Config and / or extensions probably don't go in custom distro packages. -- Re-using a distro distribution system for custom configuration packages may make sense. Arguably using a configuration management system makes the most sense, but they aren't always available. It's a balancing act of what works in each use case with the fewest side effects / exposures.

-- Grant. . . . unix || die