> Their research brought up an interesting question: Could attackers somehow bridge the gap between the physical IoT network (the lightbulbs) and attack even more appealing targets, such as the computer network in our homes, offices or even our smart city?
> And the answer is: Yes.
Does this surprise anyone? Was this really a question brought up by their research? A computer with a network connection is a computer with a network connection, no matter how small.
It surprised me a little. These Hue bulbs are Zigbee only. They don't speak TCP/IP. So using a bulb as the entry point to attack a home LAN requires some chaining of exploits. First to compromise the Zigbee network and gain access to the bridge, then compromise that to work your way into the rest of the network.
I mean, I didn't think it was impossible. But it's not as apparent an attack surface as a wi-fi gadget would seem.
That issue has been raised for nearly a decade now in the security community so definitely not a new question. And there have been stories like this: https://www.bbc.com/news/technology-25780908
You can be hacked from your doorbell, thermostat, or refrigerator now. Soon, hacks to vehicles will be able to propagate into home networks to install malware. It's an exciting time to be a cybercriminal...
So what's a "best practice" if you ARE going to have these things in your home? Keep them on a guest network that doesn't have access to your private network? (with a separate device to control things)
I have a separate network for my IoT stuff - this network can access the internet, but cannot initate connections to my main network[0]. My main network can initiate connections to the IoT network. The Hue bridge works fine, with the default app, in this setup.
My main control device is a VM running Home Assistant, so the underlying system (Hue and TRÅDFRI mainly) doesn't really matter much.
[0] Mostly. There's a port open for one device to do HTTP POSTs of data to one machine on the main network. MQTT is also open so that my ESP32/ESP8266 stuff can push data to the broker.
This seems really nice! May I ask how you set it up? Is it a question of configuring routing, a firewall, or both? Does it matter if you have separate or a shared subnet?
I have some router with Shibby Tomato laying around (DD-WRT is unsupported), but I'm not sure if I need some other hardware, software, or if it's just a matter of finding the right settings…
What strikes me about these IOT devices is that their value doesn't just go down as they get old/outdated/unsupported, but they can easily become a negative value that far exceeds the original price paid.
That is fairly unique (almost unknown in any simple physical device) and requires a very different purchasing/disposal/return policy.
Also consumers often just use the router their ISP provided.
Suppose your router does not have VLAN support, and you do not wish to replace it. Can you add sufficient VLAN support to your network by adding switches with VLAN support?
TP-Link has a couple of switches (TL-SG105E and TL-SG108E) [1] that are not full managed switches but do more than common unmanaged switches. They are priced about the same as unmanaged switches. I got the 8 port model for $30.
These switches have some VLAN capability, although I haven't looked into what it can do. (I got it for its port mirroring ability, not its VLAN ability).
If you are using your ISP's router/WiFi access point, and your IoT devices use WiFi then I'd guess there is not much you could do with switch-based VLANs. The Hue bulbs, though, talk to a Zigbee hub that you plug into your ethernet, so you can make all the Hue traffic go through a switch.
Another problem is that nearly all the documentation I've found on using VLANs gets real "enterprisey" real fast. For even fairly sophisticated home users it is probably really confusing, and so even if they have a router with good VLAN support they might not be able to figure out how to use it.
I think the easiest -- but not the best, of course -- ro separate these for the average home user/consumer would be to just "daisy chain" two standard consumer routers.
The first plugs into your "Internet modem/router". Connect all of your "untrusted" devices to it. Your second router also connects to the first, just like the other devices do. Your "trusted" devices will connect to this second router.
Your "trusted" devices (PCs, laptops, tablets, etc.) will be subject to double NAT and, of course, NAT is not a security feature but this second router will provide a bit of separation between your trusted and untrusted devices by way of NAT and stateful firewalling, just as it would protect your internal network if it were connected directly to your upstream ISP's network.
Again, this isn't ideal but it would work for the average home user and it eliminates the need to deal with/learn about VLANs or buy special hardware that supports them.
This VM that I'm typing in is behind at least eight NAT routers. There's the pfSense perimeter router, and at least one router between that and the ISP. And then there are three pfSense VPN-gateway VMs, each with NAT by the VPN server, and local NAT to a VBox internal network.
Those switches only work with a router that actually creates the vLANs. I use one with pfSense, running on a small box with a used Intel server NIC. So I have a mix of LANs and vLANs to keep stuff more or less isolated. If I want WiFi, I just stick an Alfa AP on one.
In any case, you're counting on the router to keep one LAN/vLAN isolated from the others.
Consumer routers do have this feature, but usually it's software-limited to single additional VLAN and called "guest network". It would be trivial to add an option for dedicated "IOT network".
Even the cheapest $20 routers are actually quite capable in terms of hardware, supporting at least 16 VLANs.
Except that many IOT devices require you to be in the broadcast domain for control and discovery....
e.g. with LIFX wifi light bulbs, you can control them with low latency (and no internet connection) via ip packets; or high latency via LIFX's cloud servers if you're not in the same subnet.
Are they using broadcast packets, or is it multicast and enabling multicast routing on your home network fixes the problem (you might need a mangle rule to bump up the TTL)
Sorry - AP manufacturers are already too busy adding RGB leds, GPU vendor branding, Gaming Acceleration and other bullshit "value" adding features that can justify a three-digit price tag instead of coming up with something useful.
Industrial equipment has this idea of a “fieldbus” that you put the manufacturer’s devices on and then have some kind of hub or controller that you completely own between it and the internet (if you decide to connect it.) I spent 4 years working for a company that makes these and it’s (IMO) the correct way to do this.
X10 had this sort of architecture, maybe if everyone started using Bluetooth or USB you could do something similar.
I’ve shopped a few times for consumer computer controlled lighting and it’s all crap (just like any consumer electronics niche) that needs to be put on a WiFi network and use the manufacture’s app (and often network services.)
If you want IOT either do it yourself or get industrial stuff.
Some of the consumer stuff can be controlled with reverse engineered protocols. I've got some TP-LINK bulbs, configured and controlled entirely with Free software. They're on an isolated network with no Internet access, of course.
DIY seems eminently possible with ESP32 etc, but mains power means I'd rather buy something off the shelf from a longstanding brand.
I doubt this will move the needle for consumer manufactures to embrace it, but it works right now (and is more responsive than X10). We're all cyber-gleaners until (hopefully) the market demands open standards.
I use unifi switches, access points etc. they may be a bit higher end than the cheapest consumer gear but they are still marketed towards home use (as well as businesses).
I have four vlans - adults, kids, IOT and guests. Only the adults vlan has unfiltered access, the others are pretty heavily locked down.
The IoT stuff also needs to communicate with other trusted machines (so that they can be controlled, e.g. turning on/off the lights or watching the videos from the cameras); putting them all on a vLAN would prevent that from working, too.
Just set firewall policy to allow new / existing connections from your trusted machine to your untrusted ones and only existing connections from your untrusted machines to your trusted one.
Granted, an average user will not be able to figure out how to do this and a standard private VLAN guest network is going to prevent this from working.
yes, and it's a pain because the protocols and ports required are usually undocumented. so it's a lot of trial and error (like getting an appleTV talking to a tradfri gateway across the vlan boundary).
there's no need to stick to dumb devices, especially when new devices have much better hardware. just dont connect them to a network unless they're VLANed, pi-holed, or even MITM'd with filtering.
Personally I don’t think the benefit of smart devices outweighs the risk of not keeping them “VLANed, pi-holed, or even MITM’d with filtering”.
What are the benefits anyways? Not having to physically get up and flick a light switch anymore? Getting a push notification from my fridge that we’re out of milk? Whyyy?
> And the answer is: Yes.
Does this surprise anyone? Was this really a question brought up by their research? A computer with a network connection is a computer with a network connection, no matter how small.