We are living at the start of a golden age of computing. Prices have plummeted on computational costs, it’s gotten much simpler to build electronic devices and we’re almost at the point where simple sensors and some compute are disposable. Just look at your favorite retailer for proof of all the things that can connect to your phone, access points and home network — you are now looking at possibly one of the greatest revolutions the world has ever seen. From doorbells to lightbulbs, your dog to your car keys — there’s very little that in reality can’t be connected anymore. Though amazing, this comes with a rather hefty downside: none of this interconnectivity is remotely secure.
Why the insecurity? There are several reasons, including:
- Vendors wanting to get the product to market quickly and move on to a replacement
- A lack of long-term insight/planning
- Planned obsolescence
- Inability to update devices remotely
- Users who are apathetic and who demand features they don’t fully understand
- Finally, an ecosystem that is fundamentally complicated, leaving most consumers struggling to properly understand how their home network works
The reasons don’t really matter in the end, and there aren’t any easy solutions either. Companies won’t spend money on resources to improve security and provide updates or long-term support until they are financially incentivized. Meanwhile, consumers aren’t going to suddenly become better informed and behaved about installing patches or locking things down, much to every system admin’s dismay. The end result is pretty clear: everyone is vulnerable given this new connected landscape. News headlines paint a bleak picture, but at some point, we have to start looking at what we can do to solve this security crisis, instead of hoping that IoT and the proliferation of the devices it brings suddenly gets more secure, updates better and becomes more usable on its own.
I tackled this security problem on my home network many years ago. My reasons may have been a bit more extreme than most consumers’, but frankly, I got bitten hard. For starters, I split my network into smaller, more targeted pieces to isolate things I knew would be problematic. This goes beyond just putting your Guest Wi-F’ on its own network (which is frankly a great idea). It goes so far, in fact, that when I started adding IP cameras to my house, I stuck them on their own VLAN and blocked their access to the public internet.Lo and behold, they were all trying to talk to some random service on AWS.
When I started adding smart switches, temperature gauges, etc., unless I had built them myself, they all tried to talk to the internet to be “helpful” to me. Every company wanted to be the center of my magical IoT house, and they all wanted to push that control back out to their central cloud services. This is great in some cases since most users don’t run servers in their houses and believe that they want to be able to turn their ovens off when they are on the other side of the planet. These features are useful to some, but it means that consumers are increasingly giving up control of their networks to centralized authorities, making them easier targets for attack. Spurred on, I kept splitting or segregating my home network into smaller and smaller pieces.
Today it’s a bit complicated, and while I’m not sure I’d recommend this setup to most, I am increasingly convinced this is the only way forward. By breaking things up, I have greater control and can limit which devices can and can’t talk to the internet and other pieces of my home network. This means that when I want to make sure the IP cameras can’t talk to the internet, I can just drop their traffic entirely. I can also make sure that the IoT devices don’t have access to the home theater equipment, and that my media streaming devices can reach the appropriate internet sites.
Is it complicated? Yes, and it’s cumbersome in some cases, too, but I can reasonably prove that my IP cameras didn’t take part in the DDoS attack, or that the vast majority of my IoT devices aren’t talking to the internet.
Does this limit some of my devices’ functionality? Absolutely. There are a number of devices that just don’t work in my setup. For example, I bought a Wi-Fi power switch thinking I’d be able to control it just fine “blocked off.” Turns out, this specific device couldn’t be controlled except through the manufacturer’s app and cloud service. I ended up giving that device away because it was useless in my network setup and wasn’t worth my investment or my time to return it.
Segmenting your home network might be a bit extreme, but it’s something we can do that helps mitigate the problems we have now. While this measure adds a lot of complexity, good UI/UX from home router manufacturers, whether it’s open or closed source, can go a long way toward making this more palatable for end users and consumers. I’d love to see some of the open source router projects like OpenWRT, DD-WRT and their ilk go so far as to make this network segmentation the default and provide landing zones for these inherently flawed devices.
If you’re interested in pursuing this network segmentation approach, here are some pointers that can help get you started. It won’t be easy and it won’t be simple, but it just might end up better and more secure:
- VLANs are your friend. While they aren’t perfect and can be vulnerable to VLAN hopping attacks, they are pretty secure overall. This does mean buying better switches, routers, access points, etc. that are VLAN-capable. Most “dumb” switches/hubs can’t do VLAN tagging internally.
- To go along with VLANs, most access points will limit you to about four SSIDs. There’s a number of technical reasons for this, so exceeding it is ill-advised, even if you seemingly can. If you are going to deploy dedicated wireless networks for your IoT devices, your main devices, your wireless guests and one more network, you’ve used up all your available SSIDs and may need to consider having more than one access point.
- Getting things to cross networks in a sane manner is possible. Avahi’s reflector support is a great way to help solve the discovery problem when you put your Chromecast-like device on a network where your phone doesn’t connect.
- The firewall matters. Normal home routers are terrible at describing their firewall rules beyond the simplest and most basic of concepts, and likely don’t include support for things like VLANs. Third-party firmware can sometimes rectify these basic problems, but as your network grows in complexity, sometimes the interfaces make it harder to manage. Look into a more dedicated device; pfSense and OPNsense are good places to start looking for open source solutions. If you are feeling more adventurous, but don’t want to learn to write your own iptables/nftables rules, take a look at something like Shorewall. It can help simplify some of the management of more complex setups, but keep in mind that you are still dealing with a variety of configuration files, which is not for the faint of heart.
- Finally, if you have other users on your network, be prepared for them to complain bitterly when things don’t work the way they are used to. It’s unlikely that this will be a project that is measured in minutes and more likely to be a project measured in hours before you get it all right. Some of this has a steep learning curve, so warning others who make use of your network is advisable.
Stay tuned to the Open Source Blog for more deep dive features like this, and be sure to follow us on Twitter (@vmwopensource).
