Just like everybody else on this list, I guess, I'm rather less than happy about the WPA2 story that has emerged within the past 24 hours. Due to the announcement that WPA2 is, apparently, badly broken, I'm trying now to figure out how to lock down my home network a little better... as, I suspect, are many others all over the world... at least until the equipment vendors get around to issuing firmware patches. Up untill last night, when I read the WPA2 news, I just blindly trusted everything on my local network, with the result being that I've got and /etc/exports file, and also its Samba equivalent, that are making each of the several top-level directories that hold most of the stuff on my central FreeBSD "file server" machine available, without restriction, to the local subnet as follows: #/etc/exports /home/mini-me -alldirs -network 192.168.1.0 -mask 255.255.255.0 /one -alldirs -network 192.168.1.0 -mask 255.255.255.0 /two -alldirs -network 192.168.1.0 -mask 255.255.255.0 /three -alldirs -network 192.168.1.0 -mask 255.255.255.0 (There's basically equivalent stuff also in my Samba config files.) In light of the recent WPA2 disclosures, it has occured to me that as of today it may be a Bad Idea for me to be exporting all of this stuff, read/write, to all of 192.168.1.0/24. I'm fortunate, because I just have a simple little home network, and there are only, at most, a handful of devices on it. I've already taken the step of (re-)configuring all of my hardwired devices so that they are all using static IPs within just the 192.168.1.16/28 sub-block. These machines... my hardwired ones... are the ones I intend to continue to trust completely. They will continue to have read/write access to all of the directories mentioned above. I've also just diddled my router config so as to have it issue local IP addresses to DHCP clients within just the 192.168.192.0/26 range. This is going to be a range that I only trust marginally from now on, i.e. just enough to have read-only access to -just- my content directories /one, /two, and /three. Basically, I'm just arranging things so that all my hardwired stuff is on static IPs, within a limited little subnet, and all of my WiFi stuff will continue to do DHCP, also within a limited, but different subnet. So, based on all of the foregoing, my new /etc/exports file will look something like this: # trusted /home/mini-me -alldirs -network 192.168.1.16 -mask 255.255.255.240 /one -alldirs -network 192.168.1.16 -mask 255.255.255.240 /two -alldirs -network 192.168.1.16 -mask 255.255.255.240 /three -alldirs -network 192.168.1.16 -mask 255.255.255.240 # semi-trusted /one -ro -alldirs -network 192.168.1.192 -mask 255.255.255.192 /two -ro -alldirs -network 192.168.1.192 -mask 255.255.255.192 /three -ro -alldirs -network 192.168.1.192 -mask 255.255.255.192 ... and I'll make similar adjustments also in my Samba config files. Well, anyway, this is my plan at the moment. I'd be happy to have any critiques or helpful suggestions. Of course, none of this is optimal... not like having real working WiFi security would be. But in my specific case, if somebody manages to get in and fiddle, in arbitrary ways, with the communications between my WiFi devices... which mostly consist of just "home theater" type stuff in the living room... then it will be no biggie, just as long as whoever is doing it will, at worst, just have read-only access to my content files. I can live with that, I think, at least until the firmware cavalry arrives. Regards, rfg
Ronald F. Guilmette wrote this message on Mon, Oct 16, 2017 at 15:13 -0700:> Just like everybody else on this list, I guess, I'm rather less than > happy about the WPA2 story that has emerged within the past 24 hours. > > Due to the announcement that WPA2 is, apparently, badly broken, I'm > trying now to figure out how to lock down my home network a little > better... as, I suspect, are many others all over the world... at > least until the equipment vendors get around to issuing firmware patches. > > Up untill last night, when I read the WPA2 news, I just blindly trusted > everything on my local network, with the result being that I've got > and /etc/exports file, and also its Samba equivalent, that are making > each of the several top-level directories that hold most of the stuff > on my central FreeBSD "file server" machine available, without restriction, > to the local subnet as follows: > > #/etc/exports > /home/mini-me -alldirs -network 192.168.1.0 -mask 255.255.255.0 > /one -alldirs -network 192.168.1.0 -mask 255.255.255.0 > /two -alldirs -network 192.168.1.0 -mask 255.255.255.0 > /three -alldirs -network 192.168.1.0 -mask 255.255.255.0 > > (There's basically equivalent stuff also in my Samba config files.) > > In light of the recent WPA2 disclosures, it has occured to me that > as of today it may be a Bad Idea for me to be exporting all of this > stuff, read/write, to all of 192.168.1.0/24.Doesn't matter, if your network is compromized, only strong encryption and authentication will save you.. For this you need NFSv4+kerberos, SMBv3 (which I have no clue how to ensure things are auth/enc'd) or WebDAV over https for file sharing. Restricting what hosts doesn't solve the problem. Also, w/ your config, you have to make sure your router does ingress filtering, as many times you can spoof packets between subnets too...> Of course, none of this is optimal... not like having real working > WiFi security would be. But in my specific case, if somebody manages > to get in and fiddle, in arbitrary ways, with the communications between > my WiFi devices... which mostly consist of just "home theater" type > stuff in the living room... then it will be no biggie, just as long as > whoever is doing it will, at worst, just have read-only access to my > content files.Best way to assume is that the network is always compromized, and that it's up to the nodes to protect the data... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
WhiteWinterWolf (Simon)
2017-Oct-17 08:27 UTC
WPA2 bugz - One Man's Quick & Dirty Response
Hi Ronald, I have yet to investigate this WPA2 thing on my side, too much contradictory informations depending on the sources yet. Let me however add my two cents regarding your issue: A network can be divided in several logical layers: the data link layer (here WiFi), the networking layer (here TCP/IP), and the application with the data it manipulates, both in transit and at rest. 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. But this "ideal solution" is not always feasible. 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. This is usually weak and prone to be vulnerable (if it wasn't due to this WPA2 weakness, it would be something else). There are however techniques allowing to secure higher layers without having to trust the lower ones. That's how, for instance, HTTPS work for online payment: neither you nor the bank or merchant trusts the Internet network, but all sensitive operations are done within a secure tunnel created between you and the remote party and isolating you form any threat affecting networks in between. This WPA2 crisis strongly reminds me WEP (even-though I don't know yet if it is really as scary: again different source gives completely different information). But nevertheless at that time it was simply assumed that the Wi-Fi was just to be considered as an untrusted network, the same way as you (should) consider Internet. A sane approach which was usually recommended was as follow: 1) Sensitive accesses must be properly secured. As you cannot trust lower layers, use something like a VPN, which is able to authenticate both the source and destination hosts and create a secure tunnel between them. At the time of the WEP issue, there was a movement to completely drop any kind of WiFi "security" and use plain, open WiFi instead but rely on VPN to authenticate the hosts and provide appropriate access and security. This was maybe an extreme position, but still this shows the idea and remains secure indeed, as long as all your hosts support VPN of course. 2) Non-sensitive accesses *may* use lower security if needed. In particular, I don't think that your Amazon TV supports any kind of VPN tunneling, but also I don't know if it requires write access to your network share or if it uses it only to read non-sensitive media files. A common scenario is to allow read-only access limited to non-sensitive documents over the untrusted WiFi network. Yes, an attacker can take over your network and copy your movies and musics, but is this really problem for you? IT security is always a question of trade-offs depending on your particular situation, but for the "few zillions" you mentioned this is usually not a problem (and actually the attacker will most likely not even care of such files). All sensitive operations should be done using secure channels. The most versatile secure channel is setting-up a custom VPN within your LAN, but there are other alternatives. For instance, to update the content of your shared directories, you can use SFTP instead (the SSH file transfer protocol) instead of a writable share: this is very easy to setup (FileZilla is an easy to use and well-known SFTP client) and the whole communication will be secured by SSH. 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. 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. 2) An attacker may use your Internet access for his own purposes. At the peak of the WEP crisis, maps of location of weak WEP Internet access points were shared (for a fee, I guess, everything is a matter of business) on shady forums (typically pedo-pornographic forums) so their users can take advantage of such unsecured networks to access illegal content anonymously. 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. Not the ideal solution in case of a public VPN server (where everyone can subscribe), but enough to deter such low-tech attackers who just seek for ready-made available Internet accesses. So, to summarize: - Unsecure shares must be read-only and offer access to only non-sensitive files. - Write accesses and access to sensitive files must be done through secure channels authenticating both the server and the client. SFTP is a common solution, with FileZilla a widely used client. - If an Internet access is needed over the WiFi, public VPN services offer ready-to-use solutions. - Restricting outgoing access to the VPN server will prevent casual attackers from taking advantage of your Internet connection. None of this requires high amount of technical knowledge and allows to provide a good level of security independently of your WiFi security level. I hope these few elements help you to see things a bit clearer and, maybe, give you some useful ideas. Regards, Simon. -- WhiteWinterWolf https://www.whitewinterwolf.com