[Xymon] Encrypted Xymon reporting over SSL using stunnel
SebA
spah at syntec.co.uk
Tue Mar 12 18:49:04 CET 2019
Yeah, I've come across issues to do with library package conflicts or
incompatibilities with Python, just like with Perl and Ruby. Sometimes
it's difficult to get all the right versions of packages. (The way
SaltStack deal with this issue is to put the packages they use in their
repo, but it can still mess up your system if you already had versions
installed.) Let's just leave that point of discussion there.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 17:41, Bruce Ferrell <bferrell at baywinds.org> wrote:
> SebA,
>
> We agree on a lot, including the licenses. We do NOT agree on taking
> risks. Again, the concepts for secure transport ARE actually served in the
> good old, "pull from the client
> via ssh using keys" method, rather than the client push to the server.
> Yes, you DO actually have to do SOME setup for that to work. The fact that
> it's NOT well known isn't a good
> reason to add a LOT of additional code to xymon.
>
> I've had to cope with WAY too many issues around Python to have ANY trust
> of it.
>
> I've had to deal far too often with Python code that "works on your
> machine, but not on mine" WAY too may times then had experts look and say
> "I'll have dig into it for a day to
> figure out why it does that... It's not supposed to do that". It's not
> inherent in the language, but in practices around the language.
>
> I can, and do code in it if I absolutely must, but avoid it when I can.
> Yes, many, many other people like that complicated things can be built with
> it quickly and I didn't mean
> this to become bike shed discussion around language.
>
> The kinds of issues I spoke of give ME the heebie jeebies when it comes to
> tools I use regularly.
>
>
> On 3/12/19 10:16 AM, SebA wrote:
> > Hi Bruce,
> >
> > Yes, I've been using the same since 2002 as well, but I disagree on the
> legal issue. The Apache licence is very free and so long as it is complied
> with (which is mainly to do
> > with trademarks) there are no problems with it. Many commercial
> products integrate OS software that uses the Apache OS licence, and Xymon
> is not commercial, it's open source too!
> >
> > Look, I don't know if it's worth using their code or not - I happen to
> like Python and can program in it (when I can't in C), but as you said,
> it's a different language, it might
> > not integrate well. I have seen some communication issues with the Salt
> Stack, but they're mostly due to not having the right firewall ports open.
> Anyway, the key generation
> > and encryption stuff is separate to the communication - Xymon
> communication could still use the normal Xymon channel, but use key
> generation and encryption ideas or code or
> > libraries from somewhere else.
> >
> > Kind regards,
> >
> > SebA
> >
> >
> >
> > On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <bferrell at baywinds.org
> <mailto:bferrell at baywinds.org>> wrote:
> >
> > SebA
> >
> > I think mentioned this in another thread. I've been using
> BB/xymon/"that thing we can't say because an estate disliked it" since 2002.
> >
> > I think many of us went through the demise of BB when Quest/Dell/EMC
> absorbed/smothered it.
> >
> > Using code from a commercial entity (even with an apache license)
> raises the spector/risk of past debacles and in my opinion potentially puts
> a tool I really like and find
> > useful
> > at risk.
> >
> > Integrating functionality that already exists through well
> understood, more general mechanisms makes it special purpose functionality
> and THAT makes it less reliable...
> > Especially
> > in that SaltStack is really "just" an orchestrator written in Python
> (Py, in and of itself is enough for me to give it a pass... Very long story
> and ask me outside of this
> > discussion about that). The difference in the codebase alone should
> cause someone to think very hard about that kind of merge.
> >
> > Looking more closely at SaltStack, I see it would add addition
> transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable
> transport to increase
> > security/reliability?!). MQ per the docs, uses HTTP/SSL and now
> we're back to certs and even further integration of some form HTTP server
> to do that!
> >
> > Maybe better documentation of secure message distribution? There
> used to be one on how to pull client updates via ssh. That's secure AND
> simple. It doesn't sign the updates but
> > that could be a reasonable add-on to the documentation.
> >
> > For this purpose, SaltStack looks to me like that old Milton Bradley
> board game Mouse Trap.
> >
> >
> > On 3/12/19 8:55 AM, SebA wrote:
> > > There is a commercial version, but this code is open source:
> https://github.com/saltstack/salt
> > > I wasn't saying we use their code - although if the licence says
> that other open source projects can use it, then it is worth considering.
> It looks like it's using the
> > Apache
> > > licence.
> > >
> > > Kind regards,
> > >
> > > SebA
> > >
> > >
> > >
> > > On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org
> <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:
> bferrell at baywinds.org>>> wrote:
> > >
> > > ...And looking even closer at saltstack, it's a commercial
> product, leading to a possible trigger of "that's ours! cross our palms
> with MUCH silver" (probably based on
> > OSS, but
> > > thats' never stopped anyone).
> > >
> > > Taking me back to "do it outside of xymon" for cleanliness
> sake.
> > >
> > >
> > > 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> <mailto:
> bferrell at baywinds.org <mailto:bferrell at baywinds.org>>
> > <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>
> <mailto: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> <mailto:
> abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>
> > <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:
> 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> <
> http://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> <mailto:
> Xymon at xymon.com <mailto:Xymon at xymon.com>> <mailto:Xymon at xymon.com <mailto:
> Xymon at xymon.com> <mailto: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/730deda2/attachment.html>
More information about the Xymon
mailing list