freebsd-security Digest, Vol 634, Issue 3

Walter Parker walterp at gmail.com
Wed Oct 18 20:52:43 UTC 2017


>
>
>
> Message: 3
> Date: Tue, 17 Oct 2017 21:00:11 -0700
> From: "Ronald F. Guilmette" <rfg at tristatelogic.com>
> To: freebsd-security at freebsd.org
> Subject: Re: WPA2 bugz - One Man's Quick & Dirty Response
> Message-ID: <32999.1508299211 at segfault.tristatelogic.com>
>
>
> In message <49252eda-3d48-f7bc-95e7-db716db4ed91 at whitewinterwolf.com>,
> "WhiteWinterWolf (Simon)" <freebsd.lists at whitewinterwolf.com> wrote:
>
> >Ideally, you would use a specific protection for each of these layers,
> >so that an vulnerability affecting one layer would be compensated by
> >other layers.
>
> A good point.
>
> Right about now, I wish that I knew one hell of a lot more about both
> NFS and SMB than I do... and also SSH and TLS.  I suspect that the
> file sharing protocols I am most concerned about (NFS & SMB) could
> perhaps be run in a manner such that both initial volume mounts and
> also data blocks (to & from) the share volumes would be additionally
> encrypted, so that I could be running everything securely, even if
> some attacker managed to do maximally evil things to my WiFi/WPA2
> network.
>
> Do NFS and/or SMB have their own built-in encryption?  I have to ask,
> because I honestly don't know.  If not, is it easily possible to add
> or attach some additional encryption layer to those?  And if I did so,
> would it even help any?  (I'm guessing that it might, just on the basis
> of what little I know about SSH.  I don't even really know how SSH works.
> The only think I do know is that it is possible to use it to both start
> up and continue a secure connection, even in the presence of utterly
> compromised data links.  And I gather than this is also -the- fundamental
> and inherent feature of TLS also.)
>
> Please note that I am asking only about what is -easily- possible.  I
> wish that I had time to learn in depth about all things crypto (starting
> from my very low starting point) but I don't.  And I'm just running a
> little home network here, not a network for, say, a huge corporation
> or for a sprawling factory floor.  So I just doesn't make sense for me
> to spend, say, 200 man hours to get something working.  I just don't
> have that kind of time to devote to this.
>
> Basically if there is an -eay- crypto-protected way of mounting volumes
> and then accessing them, either for NFS or for SMB (or both) then I do
> think I'd like to try that.
>
> >What you did is secure only the lowest layers and put no security on the
> >higher ones, the security of the complete stack relying on the lowest
> >layer security.
>
> Yea, I think that I sort of got that.
>
> >All sensitive operations should be done using secure channels.
> >The most versatile secure channel is setting-up a custom VPN within your
> >LAN...
>
> Frankly, I must sheepishly admit that have no idea how to even begin to
> do that.  Pointers to tutorials would be appreciated.
>
> Note also that whatever I do in this regard, I have to be able to entice
> or coerce at least one of (a) OpenELEC/LibreELEC and/or (b) Windoze7
> to follow suit.
>
> >At last remains Internet access. There are two threats there:
> >
> >1) An attacker may intercept your connection. He will not be in measure
> >to bypass HTTPS security though, so assertion such a "hacker can now
> >steal your passwords and credit card numbers" as heard this morning in
> >the news is bullshit as long as you ensure that your connection is
> >indeed secure through HTTPS thanks to the little padlock.
>
> Well, as I mentioned earlier, my Amazon Fire TV box doesn't need to
> access anything from my local file server, but it *does* somehow
> (and mostly automagically) access protected content off the Internet,
> via my local WiFi network.  At the moment, I don't even know if
> whatever credentials of mine that are stored in, and transmitted from
> that box are at risk, and I have even less of an idea of how to
> secure them if they are indeed at risk.
>
> >There are paid VPN services available on the Internet, some of them even
> >proposing smartphone apps. They are commonly and effectively used on
> >public WiFi network which are by definition untrusted, and would be an
> >easy way to secure your Internet access through an untrusted WiFi
> >without having to learn to setup a VPN server yourself.
>
> Right, but how do I entice the Fire TV box to use such a thing?  That's
> the enigma, I think... at least for me.
>
> >2) An attacker may use your Internet access for his own purposes.
>
> Yea, I've gathered at least that much.  It is a worrying possibility,
> but as I have pretty crappy (low) bandwidth, I think that if bad guys
> show up in my neighborhood, they will easily find much better pickings
> from some of my neighbors.  So for the moment, I'm not going to worry
> about this, but of course, I'm going keep my ear to the ground, and will
> patch my router and my WiFi clients the minute patches or these things
> are available.
>
> >Your WiFi access point firewall may offer the possibility to restrict
> >outgoing connections to only the VPN server. This would effectively
> >restrict Internet access to hosts and devices able to authenticate
> >against the VPN server.
>
> It doesn't. :-(
>
> >I hope these few elements help you to see things a bit clearer and,
> >maybe, give you some useful ideas.
>
> Yes, thanks.
>
> I feel sure that I am probably speaking for a few hundred million people,
> all over the world, when I say that this whole WPA2 debacle is really
> rather entirely annoying.  But with helpful folks like you around, even
> the dunderheads like me will probably manage to make it through this mess
> without too much pain.
>
> Thanks for your thoughts.
>
>
> Regards,
> rfg
>
>
SMB has supported authentication signing for a long time (more than a
decade). That can be used for basic security.
SMB3 supports encryption. To work with SMB3 encryption you will need at
least Windows 8.
The Samba project supports SMB3 and many of the security features in it,
but not share level encryption. Password authentication works with signing
and encryption. Until Samba supports the new share encryption in SMB3, you
will need to use something like stunnel (or an encrypted VPN) to enable the
privacy features that come with encryption.

What that means is that the newest versions of Samba can talk to newer
Windows boxes with the authentication pieces (the username/password
exchange) done with encryption to make exploitation much harder.

Encryption on NFS appears to be by using stunnel or SSH to encrypt the data
(or using a VPN).



Walter



-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis


More information about the freebsd-security mailing list