[Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?)

[J.C. Cleaver]

On Mon, August 14, 2023 19:55, Jeremy Laidman wrote:

>
> I agree with others on the need for SSL/TLS these days, or at least some
> form of encryption. Many organisations now require comms to be encrypted,
> or at least authenticated, using robust, modern cryptography. In my case,
> we're periodically asked about our comms, and receive raised eyebrows when
> we respond.
>
> I am also sympathetic to the notion that if we have to rely on
> encryption on our network, then we have bigger problems. But there are
> still reasons why encryption is desirable. For example, when monitoring a
> device connected via someone else's network. Or even just to slow down an
> attacker that has made her way onto our network, and perhaps even set off
> alarm bells when she tries to talk BB in cleartext and without
> authenticating, with the attempts generating log messages. Another way to
> view it is, "perfect is the enemy of good". I'd prefer to have encryption
> and authentication on a network that has an APT ferreting around, than
> not.

I tend to agree with this as well. Although the interaction is what it is,
having anything unencrypted on networks can be a red flag and a barrier to
implementation.

>
> The work-arounds are not ideal for a few reasons. But I suspect the main
> one is that there is no consistent and standardised workaround, that every
> deployment that requires it tends to use. If everyone simply used the
> stunnel solution, then it would end up being well supported by the
> community, with lots of help, documented experiences, how-tos and best
> practice guides. But I find myself not wanting to make a poor choice, so I
> haven't made any choice. I suspect the stunnel option is probably the best
> option, but I have a feeling there will be a performance impact.

Indeed. Performance comes into play with all the options here.

- Setup and teardown for small TCP connections hitting xymond directly
- Signing and authenticating messages received asynchronously (combo
messages, xymonproxy, or messages read in from the BFQ), which should be
tossed if invalid

As it currently stands, xymon is already very efficient, so it's worth
pointing out that the complexity really doesn't have to come in until you
start hitting things at scale. If you're on a modern core and handling 90
msg/s, xymond is going to be just fine. If you're trying to push 9000
msg/s, more needs to be taken into consideration.

Furthermore, ensuring that one-way messages are submitted asynchronously
to the daemon means that SSL termination and/or authentication can still
pretty easily be off-loaded architecturally, even while SSL features are
still in development. (HTTPS message submission in particular, with apache
handling the ugly part.)

I think a community solution and best practices can be drawn up, but it
probably calls for something of a working group among those who are
pushing the limits now (or still) and have already worked through some of
the kinks in their SSL implementation.

(Memories of stunnel-wrapping qmail-smtpd coming into play here...)


>
> Not wanting to de-rail the conversation, the main point is that
> encryption/authentication is an important factor for me, and the missing
> feature is present in alternatives to Xymon. Some of the proposed
> alternatives are inadequate, but are still given credence due to the
> ticking the "security" boxes. If Xymon had this one feature built-in (or
> standardised), and had the occasional bug fix, then it would be treated
> with much less scepticism.
>

Agreed.

-jc