[Xymon] Encrypted Xymon reporting over SSL using stunnel

[SebA]

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> 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> 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 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
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190312/bc175cc0/attachment.html>