[lug] Security - Wireguard

[Bear Giles]

On the broader issue - I've tried different approaches on my AWS instances,
e.g., having the webserver listening on the usual ports and an SSH daemon
listening on a OpenVPN IP address, but I've eventually settled on having
the SSH daemon listening to the internal network address. I have a 'nano'
instance that listens on SSH and that I can use to tunnel between the world
and the internal network (not *masquerading*) and I keep that instance shut
down unless I have a specific need for it. I debated limiting access to
this daemon to OpenVPN - you would need to connect to its VPN before you
could ssh into it - but ultimately decided against it since I couldn't
guarantee that I would always have my OpenVPN credentials if I'm traveling.

A similar problem applies to my home network... except I'm even more likely
to need access from outside and to be accessing it via a chromebook or
tablet. I run a personal instance of Confluence and have a lot of notes on
it. I tried running it on AWS but couldn't justify the cost since it has
high minimum hardware requirements even if it has light use, and $10/year
is a lot cheaper than $10/month for a hosted account. (If I routinely
accessed it from away from home I would go with the hosted account but
since I work from home it's harder to justify.) It would be nice to require
OpenVPN to access my home network but it would limit my options.

In my case I'm using nginx (with LE certs) as a front-end. At the moment
it's running on one of my systems but I'll migrate it to a RPi running in
the DMZ soon. Well, "soon".  Ditto the SSH daemon running on a nonstandard
port - I'll move it the DMZ and it will be like the AWS setup.



On Sun, Jun 30, 2019 at 10:38 AM Bear Giles <bgiles at coyotesong.com> wrote:

> Re conf - one of my "I should do this!" projects - which has been in that
> state for years - is to have a simple web interface where you select a few
> options and then download a zip file of zip files (since that's a bit more
> Windows-friendly) where the lower level zip files contain the configuration
> and crypto material for each node and the top level zip file bundles them.
> It could be accessed via website or REST API. The latter would let an
> installer package handle the query behind the scenes.
>
> Think LetsEncrypt. And, thinking of LetsEncrypt, it would probably be a
> good idea (now) to write it then contribute it to them so people would have
> confidence I wasn't keeping a copy of their crypto material. (Just how long
> this idea has been on the backburner - at the core is the same
> functionality as LetsEncrypt but it predates LE by years. In fact the
> implementation today would probably work as a front-end to LE although that
> would mean that the client-side installer would need to be smart enough to
> periodically update crypto material.)
>
> The motivation is that OpenVPN has some good stuff but 1) it doesn't have
> a clear list of "business problems" to solve, 2) a clear description of the
> best solution for each, complete with a bit of a "step up/step down" in
> security, including a checklist, and 3) it can be a pain to do manually if
> you want the strongest security since you have to create, distribute, and
> maintain a bunch of client keys.
>
> Hell, I still haven't gotten around to implementing one of those things
> myself. We have a corporate VPN and I know it's possible to set up my
> system so any connection to given IP address ranges will go through it
> instead of the default route... and that this supercedes me setting up a
> default VPN. I know the general approach - routing tables, entries in
> /etc/network/if-post-up.d, etc., but I've never gotten around to setting it
> up. There's probably several blog entries describing this... or if not I
> should write my own.
>
> On Sat, Jun 29, 2019 at 1:21 PM Bucky Carr <bcarr at purgatoire.org> wrote:
>
>>
>>
>> On 6/29/2019 1:06 PM, Zan Lynx wrote:
>> >
>> > With UDP there's no connection so NAT routers need to have a timeout
>> > or they'd just fill up with UDP tracking entries. They have to time
>> > out TCP also but they can use a longer timeout since most TCP
>> > connections mark themselves closed one way or another.
>> >
>> > I went and read some stuff about Wireguard and searched around. As
>> > best I can tell it defaults to 10 second heartbeat packets. So are
>> > you *sure* it's idle in the background? Because you'd have needed to
>> > set something for that.
>>
>> By "idle" I meant that I left the ssh window open and didn't have any
>> activity in it after logging in. Wireguard allows for keepalive
>> packets if you need them, time selectable with 25 (seconds)
>> recommended. I have that functionality turned off.
>>
>> So I dunno. The VPN client software I'm using (TunSafe for Windows)
>> has a window which shows the time since the last "handshake" and it
>> refreshes about every 2 minutes, but I'm thinking that is the key
>> re-negotiation time.
>>
>> Admittedly, I don't know much about this.
>>
>> I still need to use tcpdump to look at the traffic to be sure it is
>> encrypted, though many others have done this and report that it is.
>>
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20190630/7591d0a8/attachment.html>