[Xymon] Encrypted Xymon reporting over SSL using stunnel

Tue Mar 12 16:52:28 CET 2019

Right, but I think it's easier and more reliable when it is integrated, and
you can add it to the feature list: 'secure client-server communication'.
That's a selling point and it's something people will look for in a
monitoring system.  If it involves other software like stunnel or a VPN,
you can't put it on the feature list.

Kind regards,

SebA

On Tue, 12 Mar 2019 at 15:00, Bruce Ferrell <bferrell at baywinds.org> wrote:

> SebA,
>
> You're right, saltstack is doing the same as using ssh keys.... For all
> intents and purposes an ssh connection/tunnel or an stunnel.
>
> No need to build that into xymon.  Just do it externally and call it a
> day. And it still has the key distribution/management issue.
>
> That said, if/when tunnels go down... And they do, then reporting is lost
> and intervention is often required.
>
> The itch to "build in" what can be done outside, in my experience, should
> almost never be scratched.
>
> It's too easy to make things over complicated for little to no pay off.
>
>
>
> On 3/12/19 6:50 AM, SebA wrote:
> > The way Salt Minions authenticate and their keys have to be accepted on
> the Salt Master works pretty well.  I don't believe they expire.  It's been
> a while since I looked at it,
> > so I couldn't tell you exactly how it works, but there's some
> information here:
> > https://docs.saltstack.com/en/getstarted/system/communication.html
> > Anyway, that model would probably work pretty well for Xymon, so long as
> the reporting client is not ephemeral.
> >
> > Kind regards,
> >
> > SebA
> >
> >
> >
> > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org
> <mailto:bferrell at baywinds.org>> wrote:
> >
> >
> >     I'm not sure which standard is in use here, so I'll just top post
> like Richard did.  Please don't shoot me.
> >
> >
> >     People always go for certs... And then they expire and stuff starts
> breaking or alerting right and left all at once.  GACK!
> >
> >     For real hilarity, make them expire ten years out.  By that time, no
> one even remembers that certs were even installed or what they're for.  As
> the home loan industry said right
> >     before the big crash, IBG, UBG (I be gone, you be gone).
> >
> >      From one who has had to deal with such mass silliness, take it from
> me, it's NO FUN and REALLY tedious to fix.
> >
> >     "But I'll just use the cert for tunnel authentication" I hear you
> say... If in-authentic communication (even self signed) isn't denied, do we
> care if it's signed really?   If
> >     we do
> >     care then we deny communication/ignore messages. Now we've lost
> reporting links and visibility.
> >
> >     Some form of message authentication is probably a good idea though.
> Just something that doesn't expire and can be revoked as needed.  gpg/pgp
> keys maybe, but then we get the
> >     issue
> >     of gpg/pgp key distribution/signing.  Key per monitored system...
> Anyone want to manage THAT?
> >
> >
> >
> >
> >     On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
> >     > In the ideal, esp. when the client may have a dynamic IP address
> (DHCP without reserved addresses, or mobile clients, for example), it would
> IMO also be really good if the
> >     client reports could optionally be signed, with a certificate the
> server could verify, to give some confidence as to their actually coming
> from the client...not that that
> >     assures that the actual client wasn't compromised, but it's better
> than nothing insofar as it at least gives good odds that misleading (or
> maliciously crafted) data from
> >     elsewhere isn't being provided.
> >     >
> >     >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org
> <mailto:abe at deuxchevaux.org>> wrote:
> >     >>
> >     >> Hi Ralph,
> >     >>
> >     >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
> >     >>> I'd still like to see encrypted connections for Xymon client
> messages going
> >     >>> to the server.
> >     >> Yeah, this definitely is a feature which would be very nice to
> >     >> available out of the box.
> >     >>
> >     >> Nevertheless you can do that already now with stunnel as I
> mentioned:
> >     >>
> >     >>>> (And yes, I'm still hoping and waiting for IPv6 support, too,
> >     >>>> especially in xymonnet-based checks. Reporting to IPv6-only
> servers is
> >     >>>> no issue though, if you anyways use stunnel to encrypt the
> >     >>>> client-reporting traffic.)
> >     >> Debian's xymon package ships
> /usr/share/doc/xymon/README.encryption
> >     >> with hints how to implement encrypted reporting with Xymon.
> >     >>
> >     >> The current version can be found in our packaging git repository
> at
> >     >>
> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
> >     >> although I'm thinking about renaming it to README.encryption.md <
> http://README.encryption.md> as I
> >     >> wrote it in Markdown syntax.
> >     >>
> >     >> It also refers to this more detailed documentation:
> >     >>
> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling
> >     >>
> >     >> HTH!
> >     >>
> >     >>              Kind regards, Axel
> >
> >     _______________________________________________
> >     Xymon mailing list
> >     Xymon at xymon.com <mailto:Xymon at xymon.com>
> >     http://lists.xymon.com/mailman/listinfo/xymon
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190312/ed0311a8/attachment.html>