[Xymon] Encrypted Xymon reporting over SSL using stunnel
Adam Goryachev
mailinglists at websitemanagers.com.au
Wed Mar 13 00:57:23 CET 2019
I hate top-posting... but oh well, I'm too lazy to fix the below.
IMHO, when using "security" tools, we really need to make sure we rely
on a third party "library" to do this, security/encryption is a fast
moving area, and we really don't want to be using something 5 years old
because nobody understood how to update it from TLS1.1 to TLS1.2 or from
using 3DES to using AES or whatever the issue becomes. Also, xymon may
not be updated as easily/quickly as what other system libraries might,
so again, better to let the OS (system) provide the relevant tools to do
this, and we just become another consumer.
As such, an obvious choice would be openssl, or something similar, where
it is widely supported across many platforms, well maintained, and
likely to be well maintained in the future.
I think there are two separate requirements when referring to encryption:
1) Encrypt the content so anyone listening can't see your log file
contents, process list, and other info being sent back to xymon server.
This could use SSH style encryption, where the server key stays the same
"for life" and on each connection the server/client negotiate the
encryption, this ensures the content is protected "in-transit".
2) Signature - ie, ensuring the message actually came from "one of my
clients" or taking this further it came from "this specific client". In
this case, we would need to create something specific to each server (to
verify it came from any of our clients) or specific to each client (to
verify it came from this specific client). Some ideas:
- Do we need full PGP security for this? At least during setup, we can
easily start with a known good/clean connection, or rely on the admin to
ensure that some "shared secret" is valid on both ends.
- We can already send data back to the client after the client
successfully delivers data to the server. If the "current" data the
client is sending is considered "clean/secure" then we can easily send
back a renewed "certificate".
So...
a) Start with a simple shared secret that the admin can create (or is
auto-generated) on server install.
b) The admin configures this secret onto each client that is added,
along with adding the hostname to the server (xymon-hosts file).
c) When the client connects to the server, it uses the SSH "encryption"
to protect the conversation, sends the shared key plus the normal "1st
set of data reports". The server responds with a client "certificate".
d) When the client next connects to the server, it uses the SSH
"encryption" to protect the conversation, and signs the data with the
certificate it received from the server. If the certificate is due to
expire in X days (configurable on server) then the server will provide
an updated certificate to the client. The client can continue to use the
"old" certificate until expiry, but should allow plenty of time to
transition to the new one. In reality, this could be one or two days
only, since most clients report every 5 mins.
Or... we could configure a shared secret in the xymon-hosts file for
each client (different "password" for each client) and the client simply
encrypts all data it returns with this shared secret. Advantage is
"simplicity" disadvantage is much less secure.
Anyway, starting with an agreed "wish list" of functionality (signed or
encrypted are two items), and then a protracted discussion on the best
way to achieve it, and then we can start coding it. If we just leave it
as a high level wish list, then it is always "too hard". Let's break it
down into smaller steps. Also, even if we can't provide the
functionality to satisfy everyone, at least we could provide
functionality to satisfy some people (ie, do it the easy way first, and
then it could be extended/upgraded/changed later if there really is a
need as opposed to want).
Just my thoughts on this.
PS, as for IPv6, I am yet to see any decent level of support here, I
tried to start using it years ago, and it just never happened. Turns my
routers (Cisco Meraki: www.meraki.com details at
https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility)
still don't support IPv6 either, so it still doesn't seem to be as
important as claimed by everyone 10+ years ago when they said we would
run out of IPv4 addresses.... It's hard to "change the world", I mean,
we still have SMTP and DNS ;)
Regards,
Adam
On 13/3/19 4:41 am, Bruce Ferrell 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
>> > >
>> >
>>
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
--
Adam Goryachev Website Managers www.websitemanagers.com.au
--
The information in this e-mail is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this e-mail by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you have received this message
in error, please notify us immediately. Please also destroy and delete the
message from your computer. Viruses - Any loss/damage incurred by receiving
this email is not the sender's responsibility.
More information about the Xymon
mailing list