Designing a Home Network for Hostile Devices | Hacker News Reader

Designing a Home Network for Hostile Devices

shkspr.mobi

51 pointsedent37 comments

I guess we're beyond even considering that having an internet-connected smoke detector isn't necessary or desirable.

I like the idea that it can send me a message if I'm away from home. And it's not particularly easy for me to reach up to the ceiling to shut it down - much simpler to remote control it from my phone.

That said, the Nest really isn't that great!

You want something safety-critical to have as few parts as possible to keep one from affecting the other. That would be a nice feature. Best way to do it safely would be two devices: smoke detector with tiny component that sends RF waves whenever speaker sends sound; separate device w/ a radio and WiFi/Ethernet to notify you once detected. Means smoke detector can stay dumb and safe.

or just have a standard smoke detector, and an external sensor that waits for the sound the smoke detector makes.

This seems like the right approach--airgapped with redundancy. Not only is it more dependable and secure, it's also cheaper. You already have a smoke detector, so keep the parts that work.

That raises an interesting question: what other "dumb" devices can we connect to the internet safely through that same method?

Note that my RF method is extremely simple, dirt cheap, and has decades of field use. All kinds of industrial plants used that trick for local monitoring systems. Plus, it's strictly one-way transmission: can't hack it.

Devices on receiving end are simple enough to be made as secure (or not) as you'd like.

Anything that puts out simplistic PDUs, ideally one way only. A smoke alarm sends one one-way one-bit message, which can be done with a broadcast in any medium.

You could even achieve similar isolation even with an optoisolated RS-232 port if the protocol is auditable, non-general, and non-extensible. But good luck actually guaranteeing those things!

Internet access is akin to Turing completeness for programming languages - seemingly beneficial, easy to accidentally obtain, and ultimately a curse.

Your profile statement is interesting given Im going opposite route: from high-assurance security in software to learning hardware cuz software cant free us on subverted, inherently-insecure hardware. Gotta tweak tge hardware a la crash-safe.org or Cambridge's CHERI cpu to make job tractablw. Im still looking for EE's to run my tooling ideas and risk assessments by but those that help are uncommon. Send me an email if your interested in talking secure HW/SW architecture or methods.

Talk to the lowRISC folks?

That's on my TODO.

THAT is a good idea! Good out of the box thinking!

The only problem I see is that some kitchen appliances have high-pitched beeps that sound really similar. It would take some pattern recognition or something to ensure false alarms. I mean, "You're house is on fire!" is a more serious false alarm than most to get at an important meeting. ;)

This exists on the market now, but I can't remember the name.

just make sure it's off when the TV/streaming is running...

You mean like this one?

http://www.getroost.com/

A friend has one, and tells me that when his infant daughter screams, it sometimes notifies him that the house is on fire. I wonder if she's learned to game that system...

Or that automatic software updates are a security problem. "Software will eat the world," and every device around you will be controlled by software downloaded from somewhere on the internet.

They're the least bad alternative. Without automatic software updates, you instead have permanently-vulnerable devices (like most old home routers are today—they can be updated, but it's a manual process so users don't bother.)

I think they're a wash. Without them, you don't get patches unless you explicitly check for them. With them, you might not get patches anyways (like many Android phones), and are forever vulnerable to server-side breaches, or the manufacturer going out of business. Worst of all, an attacker only has to compromise the update server to compromise every associated device, rather than having to hack said devices one at a time.

No software updates mean your device is vulnerable to e.g. Heartbleed forever.

IP alias - multiple IP subnets on one physical interface

http://www.openbsd.org/faq/faq6.html#Setup.aliases

and a firewall to control them with

http://www.openbsd.org/faq/faq6.html#PF

Not OpenBSD only, Linux with IP aliasing and IPtables will do the same.

btw. you have PHP misconfigured, it is spewing its error log

Warning: Missing argument 2 for polldaddy_show_rating_comments(), called in /var/sites/s/shkspr.mobi/public_html/blog/wp-includes/plugin.php on line 235 and defined in /var/sites/s/shkspr.mobi/public_html/blog/wp-content/plugins/polldaddy/rating.php on line 6

This is a good start, but since they are on the same wifi channel and encryption, a lightbulb could go promiscuous and listen to all the traffic on other subnets, and interrogate them in turn.

I don't know if we need secure lightbulbs that only communicate with strong encryption..

As always, there is no use in just depending on "gateway" defense of networks, and you should always assume that any network is open to the internet in one way or another.

hmm, yeah, the wifi angle does confuse things. One wifi AP in a lead box with every device !

Lead is for ionizing radiation. Simple chicken wire, or tinfoil for 5GHz will suffice.

Thanks for the info. I guess it means building a box which will can act as a router like that.

Will look into that polldaddy issue, much obliged.

You don't need to build a box. Someone has done it for you. Get a Ubiquity EdgeRouter Lite for < $100.

If you buy a business type router, a similar wireless AP, and some "smart" switches, you can actually segregate things pretty well.

Examples:

Ubiquiti EdgeRouter Lite https://www.ubnt.com/edgemax/edgerouter-lite/

Ubiquiti UniFi AP AC Lite https://www.ubnt.com/unifi/unifi-ap-ac-lite/

Netgear Web Managed Plus switches http://www.netgear.com/business/products/switches/unmanaged-...

$238.98 on Amazon (before tax/shipping) for the ER Lite, UniFi AC Lite, and the GS108E 8-port switch.

The key here is to have network gear that supports VLANs and VLAN trunking (802.1q).

On the ER Lite, you setup separate VLANs (networks) for each class of device just as you said. You can control what traffic can go from one network to the others via firewall rules. So, just as you said, your laptop can access everything, while your wall switches can't get anywhere.

Each VLAN will have a number associated with it, I recommend starting at 100 or something and going up from there (the netgear switches treat vlans 1-3 as special). There are up to 4096 vlans available.

Tell each switch about which VLANs are coming and going on each port. For actual devices (eg. an IP camera hard-wired) you want to have the port Untagged with the PVID and Untagged vlan being the vlan for that class of device. For traffic between switches and the AP, mark every VLAN in use as Tagged on those ports.

Tagging puts an extra header on the Ethernet frames so that the devices on either end know the traffic is for a different network.

On the wireless AP, send all the VLANs into it as tagged. Then create separate SSIDs for each VLAN with separate credentials. I recommend hiding the SSIDs (disable SSID broadcast) for this, not for security, but for sanity.

With all that setup, you can set arbitrarily broad or specific rules on your router as to which traffic will be routed between vlans and the internet.

As said in another comment, you can use "dumb" switches still, but they won't understand VLAN traffic. So every device on the switch will have access to the same network(s).

One important caveat about separation like this is that devices normally discover each other via broadcast traffic. Since each VLAN is a separate broadcast domain, only devices on one VLAN with discover each other. This may or may not matter for your devices. For example, you probably connect to an IP camera directly rather than via discovery. However, for a Chromecast there would be discovery needed.

For many devices, they use mDNS for discovery. There is a mDNS reflector service on the Edgerouter that can be used to replicate discovery packets on another network. That way your laptop can discover devices on other VLANs.

All that said, while it isn't outrageously expensive to accomplish this, it will be time consuming to configure properly. ;-)

I tried this. I have a reasonable ap and a reasonable switch (don't remember brand ans type by heart) but getting vlans and wifi nets configured correctly and so that all devices work correctly, and easy enough to use is very hard. I'm no networking expert but I like to think I know the basics, but I gave up on vlanning after several days of getting nowhere.

You can do it with a capable (read enterprise grade) router that does packet filtering. You can do it with a linux box and a lot of ethernet network cards as well, but your speed will suffer because every packet needs to be inspected before being forwarded. Hardware assist in packet inspection makes a major difference. See also Software Defined Networking[1].

You probably won't need "deep packet inspection" for a few years, until the IoT people get smarter about hiding their traffic. That was sarcasm. Maybe. The fact that they cannot do secure networking competently implies they won't be able to hide their traffic competently either, but the incentives are much stronger for the latter.

Anyway...

Step 1: FORCE ALL THE TRAFFIC THROUGH THE ROUTER. Shouting here because, if the traffic does not go through the router, you cannot control (block) it. Forcing the traffic through the router can be difficult. You need to "home-run" all ethernet (wired and wireless) to the router.

1a) Hard-wired ethernet is simple. Home run it to the router.

1b) Do not permit any small network switches on any of the ethernets (this principle is breakable if you understand that all units on the satellite switch will be unprotected from each other).

1c) Best: Do not allow any wireless. This is unrealistic today. Better: have a separate wireless access point (with WPA encryption and good passwords) for every group (class) of wireless devices that then gets home-runned to the filtering router. The filtering router can then prevent your light bulbs on the light bulb[2] WiFi AP from talking to the refrigerator on the kitchen appliance AP. "Better than nothing" is to have multiple SSIDs on one WiFi AP.

Step 2: Create a shitload of subnets by either using all of the Class C networks 192.168.0.0/16 or subnetting 10.0.0.0/8[3] Put each device or logical grouping (class) of devices on a separate subnetwork.

Step 3: Disallow all packet routing by default. Bask in the glory of a perfectly secured (albeit perfectly useless) network. Crack open a beer. Drink it fast... the local residents won't let you finish it because they will impress on you their pain of not being able to "facebook" because your network is too secure.

Step 4: Re-allow all packet routing to tamp down the mutiny.

Step 5: Write a shitload (more) routing rules defining which device (class of devices) can talk to which other device on which physical ethernet ports on which ethernet IP addresses (subnets) and IP ports (i.e. whitelist only the necessary traffic).

Step 6: Re-enable the packet filtering in the router. Crack open a beer, you deserve it.

Step 7: Goto step 4.

After a few iterations, you might be able to finish your beer in step 6. After a few weeks, you might even get enough time to enjoy your beer.

[1] https://en.wikipedia.org/wiki/Software-defined_networking

[2] Most light bulbs are not directly on WiFi but are instead on a low power network like Zigbee or Z-Wave. They come with a ethernet-to-Z* gateway. This is actually pretty good, because you can plug the gateway into your filtering firewall and be in pretty good shape because you can treat all of your lightbulbs as a device class and filter them with their ethernet attachment to your router.

[3] Subnetting 10.0.0.0/8 can be a problem because your internet provider thinks that they need to use 10.0.0.0/8 for the two IP networks on your side of their internet attachment point. This is really stupid because their ToS probably specify that you can have only one computer on their precious network (that was sarcasm again. maybe.), so they are blocking 16777214 IP addresses so that they can have one for themselves (10.0.0.1) and provide 1 for you.

Yes, but what sort of beer? ;-)

Any suggestions for hardware which can accomplish this? Might scour eBay for some company discards.

Good point about the light bulbs, although the Lifx ones I have are direct WiFi connections. Was wary of Hue after their compatibility shenanigans, but there's a certain simplicity in having them all hang off a central hub.

I have an EnGenius EAP600 as my access point which allows for up to 8 SSIDs, each of which can be mapped to a different VLAN. It also supports a feature called client isolation, which prevents clients from talking directly to each other. These features make what gvb suggests a little easier. My router is simply a Linux box running Debian (currently a Supermicro SYS-5018A-TN4, previously I had a Soekris net4801, then a Dreamplug).

All of my ethernet switches are Netgear SOHO models that support most enterprise features (I use RSTP, VLANs and LACP). I have a couple GS108Ts, a GS716T and a S3300-28X. With these switches I can maintain isolation via VLANs even with multiple switches, and most of the VLANs go into my router via a cheap 10Gbe SFP+ card I got on eBay.

Currently, I've got the following "smart" devices:

WiFi Scale

Smart TV (ethernet)

Roku (ethernet)

PS3 (ethernet)

PS2 (ethernet)

Raspberry Pi 2 running OpenELEC (ethernet)

None of them are allowed to talk to each other.

If you don't take this Internet of Treachery seriously, you will end up with a fridge full of Keystone Light, locked exits to make you personally drink it, and no way of taking pictures to salvage any irony.

Old Cisco routers (e.g. C4507s) are very cheap and very capable. They are also very large and very noisy (serious trays of fans).

You can get them with various combinations of cards for $300++ (plus $150++ shipping) for something that probably cost $20,000-$70,000 new.

They have more than their share of limitations, but for the money they are hard to beat. The 4507 has dual redundant power supplies. The "R" model has dual redundant supervisor cards, and the "7" indicates it has seven card slots for plug in modules. You can get 48 port PoE (be careful you get standard PoE, not the earlier non-standard Cisco PoE) for around $100.

Random examples

* $50 + ??? S/H: http://www.ebay.com/itm/Cisco-Catalyst-4507R-2-Power-Supplie...

* $450 and "free" S/H: http://www.ebay.com/itm/Cisco-WS-C4507R-E-Cat4500-E-Series-7...

Non comprehensive list of limitations:

* The switches and software are no longer supported. Cisco won't talk to you (but that's OK, you cannot afford to talk to Cisco).

* They (should) come with software (and likely the previous owner's switch configuration :-O), but the software will not be properly licensed to you. Getting a proper license (and thus upgrading) ain't happening. There are also several different capability levels of software, the more expensive versions having more capabilities. Better sellers will give you a clue about what you are getting software-wise.

* Cisco's OS security has lots of known holes. If you are using it for security purposes, you want the console on a serial port (or the dedicated ethernet port on the supervisor card) that has physical restrictions, do not put it on a network port that one of your malicious IoT devices can reach.

* Very annoying: the 48 port GigE cards that are remarkably cheap don't support jumbo frames. :-( There are GigE cards that support jumbo frames. Some are 6(?) port, there may be 48 port ones.

You've described both a subset of a guard and how to configure that subset. Here's guards:

https://en.wikipedia.org/wiki/Guard_%28information_security%...

Guards were and are used for this purpose in the past in terms of military embedded. So, you're on the right track. :) Just need them for the higher assurance of design and implementation security.

Seems like it'd be easier to keep things on the same subnet and use ebtables instead of iptables.

Get ethernet switches with vlan/trunking. Then either control talk groups based on vlan, or centralize config for low bandwidth devices that can handle a full backhaul to the brouter.

I think proper wifi APs can create multiple ssids based on vlans as well? I don't know, wifi is currently an afterthought for me for laptops/phones only.

What I've been pondering lately is untrusted egress. Keeping those "smart" devices from associating persistent identifiers with my uplink IP address. Also being able to resume sharing an open wireless network, without worrying about shakedowns by suit-wearing goons. (Obviously the solution is various VPNs, but it's the thinking about how integrate the rest of the network so the config remains simple)

Of course the real tricky part / solution is doing all this in such a way that the configuration is grokkable, maintainable, and perhaps even the least bit reproducible.

ebtables would be the "linux and a bunch of ethernet cards" version of the solution.

On the VLANs, yes, I should have been explicit. Having multiple subnets on a single shared ethernet is mostly useless security-wise, you need to use VLANs to segregate the traffic. With router/switches, you would set up the physical ethernet ports on different VLANs and then control the packet routing between the VLANs (switch ports).

Proper WiFi APs support multiple SSIDs on different VLANs. YMMV, but the reviews I've read indicate the WiFi's actual communications speed takes a hit when it has to support multiple SSIDs (probably has to go to software encryption/decription). If you pay more for the AP, maybe not.

Linux and one ethernet card will get the job done, using VLAN trunking.

devA --notag-> switchA --tag100-> linux.eth0.100 -> ebtables (linux.br0) -> linux.eth0.101 --tag101-> switchA --notag-> devB

Obviously there's a bandwidth bottleneck, but we're mostly concerned about piddly devices that exchange control messages or in the worst case stream video, not gigabit file transfers. And the latter case can obviously be scaled up with a quad port card on the Linux brouter, and/or more than one device on each VLAN.

After that's setup, what's the point of the complexity of separate subnets? You don't really need to route between IP subnets when ebtables / brouting will give you the same filtering functionality, transparent to level 3.

All that assumes these devices are purely relying on your own Internet connection to begin with. Many digital power meters, for one, have an embedded 3G SIM and antenna, so they can talk directly to the Internet without your help. I can imagine many future IoT devices using that approach, and then forming a mesh network over the public Internet and "discovering" your other devices on that mesh network. It basically boils down to the same problem, with the constraint that you don't control the router...

Can Tomato do this?

Reply on news.ycombinator.com