[Xymon] Encrypted Xymon reporting over SSL using stunnel

[Stephane Bakhos]

I just make sure I have a VPN or a private LAN between whatever machine 
runs the xymon client and the xymon server.

On Fri, 8 Mar 2019, Bruce Ferrell wrote:

> Date: Fri, 8 Mar 2019 18:10:15 -0800
> From: Bruce Ferrell <bferrell at baywinds.org>
> To: xymon at xymon.com
> Subject: Re: [Xymon] Encrypted Xymon reporting over SSL using stunnel
> 
>
> 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
>