So, you could; buy lots of these. Take the bulbs and hub and modify the software further. Since they come in a 'box'; you can put them back in the box and then give them to people as gifts or promotional items.
You are now behind their firewall.
If you are a hacker and you manage to get into a factory in China or Taiwan or wherever that is making these; you swap out the base firmware with one of your own that dials home. You are now behind the firewall of all customers.
Assuming the box is resealable you could just return it to the store in selling condition. Or little more unlikely you could by 10 from a different store, hax 'em, go to another store and put them back on the shelf
IoT is yet another reason firewalls are obsolescent as a security measure. A device is secure or it is not. There is no such thing as a safe network. Never really was, but now there really ain't.
Uh, pretty sure firewalls are exactly how we can fix this. Use your firewall to enforce each device can only talk to what it needs to and can't do any harm internally.
Without firewall: Here's direct access to everything on my network.
With firewall: Oh no, you can hack all my smart lightbulbs and change their colours.
This kind of thing is exactly you need firewalls for. Without a firewall this could pose a serious threat, with a firewall it's probably a good practical joke at best.
If your systems have a local firewall, services are jailed, OS is patched, etc. then direct access to it is not dangerous.
Somewhere we decided to accept crap system and device security as normal because oh we'll just firewall it. That was never a good idea but the more cloud connected things we deploy it becomes completely untenable.
Large corporate networks are already hostile territory due to BYOD. The only way to maintain the firewall as anything other than security theater is to lock everything down so much that nobody can get anything done.
The whole approach is braindead. We don't see how stupid it is because it's grandfathered in.
Haven't read TFA yet, but I think you're expecting too much from your firewall here. These bulbs are hosts, and they're inside the perimeter. They have been hacked, so they send malicious traffic to other inside hosts. What the hell is a firewall going to do about that?
I'm not talking about an edge firewall - I'm talking internally, firewalls are able to trivially stop traffic from reaching the hosts which they could attack. Now, depending on your network configuration this may need to be done partially by the switch (ie: separate VLAN for such devices) and edge firewall, by separate NATs or by firewalls on the hosts themselves.
EDIT: My simple solution (the one I had in mind) is to make a firewall box - a cheap linksys router with custom firmware can be set up to act as a switch but will also follow iptables rules. This serves the same sort of purpose as a hardware firewall in the middle of a corporate network but at lower performance. Bulbs connect to switch/WAP outside of firewall, hosts connect inside it. Everything behind it is then restricted from accessing the bulbs or viceversa.
Haha that's not what I thought of when reading a response to api's comment. If you want to call it a "firewall on the host" after 'api called it a "secure device", then perhaps the disagreement is merely one of terms. Either way, the host uses some method to ignore unwanted packets. I don't think this new "on the host" version of "firewall" is very much in keeping with etymology, which is probably why I was confused.
Well as I mentioned there it doesn't necessarily have to be on the host, that's just one option. At home I use the linksys based solution I mentioned in my edit which was more the way I was thinking - and probably more comparable to commercial firewall appliances like you might be thinking of but deployed internally and on a cheaper scale.
WiFi networks already have to have substantial smarts in the router. Adding firewall logic to that wouldn't take much. On simple networks it's typically the same device already.
I agree that defense in depth is a good idea, but one key factor to consider is cost. Having a basic firewall makes sense, if for no reason other than “documenting” your public services in one place, but many places are either lulled into a sense of complacency or spend inordinate amounts of time managing tons of rules trying to segregate internal hosts, update for every new network app, etc.
It's that latter group which really needs to hear the truth that they should invest in endpoint security instead unless they have a high security threat and enough resources to do both.
I believe that at this point in time any network traversal should be considered an ultrahazardous activity. As most networks are beyond the control of the users and have little to no change control, it makes little sense to apply risk mitigation controls to them. When you consider the fact that users demand their information be available at all times, it makes much more sense, from a risk mitigation perspective, to focus on the elements you do have a semblance of control over -- the endpoints where the sensitive data is stored and processed and the protocols by which they communicate. There are well known and trusted means of securing data in transit. There is no excuse for relying on policy for mitigation where your policy can have no effect.
But... As soon as your bridge for the lights is on some sort of guest AP/network, your client on your phone can't reach it anymore, and thus has to be on that same network. And that will annoy you quick enought to not try to install the extra or guest AP at all...
Depends on the IoT device, some only have web interface that is controlled via manufacturers website, so as long as the actual device has internet connectivity you can do everything. Or maybe you can setup a "thorwaway" PC as a sort of proxy? Or maybe just one of the old (and sad) tablets/phones, depends on what you need/want to do and what kind of interfaces your IoT devices offer
Using a device that is controlled by an external "cloud" server is even worse - you've just given an untrusted 3rd party root access to a device on your lan.
Plus, devices like that are almost guaranteed to become garbage very rapidly when the vendor decides to stop operating that central command server, wherever it is. And unless you're paying a maintenance fee, they're going to cut that off pretty quickly once they stop selling new units of that particular model.
It's the biggest reason why I'm skeptical about all things IoT: too much "cloud" without an SLA or any guarantee of longevity on the service side.
Just as dumb as 2000 mile data path to a doorbell or security camera, but that still exists.
I personally haven't really thought about getting a IoT light bulb, but I would imagine you would program them to turn on when sun goes down, that shouldn't need direct connectivity and the bulbs can't tracks your phone moving aruond the house (or at least I doubt they can), so you either have to turn them on with your phone as you move along or just flip the switch or install actual movement sensors.
I'm probably completely missing the point of smart light bulbs, maybe you have actual use cases?
When you say firewall, do you mean a firewall on the edge of a home LAN? Because I still see a firewall on each individual networked machine as being extremely important.
You don't need a firewall on individual machines either; just don't run network-facing services in the first place.
At most, as a belt-and-braces security measure, you might want a system-wide prohibition preventing programs from listening on non-localhost (with exceptions for intentional servers, which should almost never happen on a client system). But that prohibition should primarily exist to catch programs misconfigured to listen on non-localhost, rather than leaving those programs running and just using a firewall to block them.
"with exceptions for intentional servers, which should almost never happen on a client system"
But these light bulbs _are_ servers. With IoT, everything becomes a server. Your home system will have to be able to query your couch and your smart watch whether someone still is there and awake, and control the tv, the lights, the curtains, your fridge/microwave/phone (to call emergency services, if needed) accordingly.
The current thought is that IoT devices should only be clients, mainly for security reasons. If your fridge needs to talk to your TV, both should be clients with a secure connection to a, often cloud based, server.
(In the wild, things are less well though through...)
This sounds wonderful for a) people who want to run said service and charge you money for something you don't need and b) people engaged in mass surveillance.
So, will all of my light bulbs poll that server to see whether they need to execute a state change? Will my doorbell poll the server to check whether it has to ring? Will my fridge poll the server for spot electricity prices and the weather forecast so that it can decide whether to raj the freezer now or in 5 minutes? Will the fire alarm poll the server to check whether one of the heat and smoke detectors triggered?
Some of these will have to poll fairly frequently. For example, users expect lights to go on the moment they flip a switch, not 0.1 seconds later.
Possible? Yes, but taking duty cycle into account, that 5W lightbulb may use more power while switched off than while switched on.
This problem has been solved for a long time. You can use long polling, websockets, server sent events or some of the older hacks that preceded those mechanisms. Heck, you don't have to use HTTP, you can just use a long lived TCP connection.
Maybe if your fridge has a touchscreen that will work. But how on earth can the user configure a client light bulb? (More realistically, a client light fixture, but TFA seems focused on bulbs...) Don't tell me that the bulb will just connect to the bulb company's server, because then I have to choose between buying bulbs from only one company or having to deal with nine different light bulb servers. My choice will be bulbs from a different light bulb company.
For initial setup, there's tons of different methods, though I don't know about light bulbs specifically, but the different IoT devices I've set up have included:
* WiFi direct
* Setup over Bluetooth
* Device broadcasts for autoconfig, get settings from a gateway or local master node.
* Static configuration entered in the IoT gateway based on
the physical port the device is plugged into.
* Dip switches
* Initial configuration needs to plug into a PC via USB or serial port and a custom windows program.
* Cryptic sequence entered via IRDA remote control.
Thanks, I can see these would be relevant for many different devices. Actually you've reminded me how many VoIP phones use DHCP for this, which would be great for any device that supported it.
> You don't need a firewall on individual machines either; just don't run network-facing services in the first place
I disagree. Firewalls fail closed under user error. The solution you proposed (we'll call it conscientious-wall) fails open under user error. That's to say, once a firewall is set up it will protect me from outside intruders unless I specifically tell it not to. A "conscientious-wall" will not protect me from outside intruders unless I specifically remember to apply it whenever I install an application or download a software update.
I'm still firmly in the camp of having at least an inbound firewall on every machine.
It's just yet another nail in the firewall's coffin. I cringe now when I read security people still talking about them as a first or really any meaningful line of defense.
I wasn't proposing illegal activity. I was in an obscure way, pointing out how badly insecure devices are actually a double threat. They are a threat in their own right, but they are also a threat in that you can't assume they haven't been tampered with.
I didn't down vote your comment or anything; but I think the general idea is to add to the conversation. Short quips generally turn gray... the rest of the thread under mine is mostly discussions of security options/concerns in regards to firewalls and networks.
Didn't mean to imply you were - just a saying in the locksmithing community. If you look below, I have contributed a tad more than a short quip. No worries.
I didn't know it was a locksmithing term, that's actually interesting and I'll have to Google a bit. It also puts the comment into context; but I was probably not the only one to miss the whooshing sound.
No worries -- there are times I feel I reside under a flight path so I'm sorry I sent a jet your way. Regarding the saying, I've probably heard it more often in the locksport community, actually. That's probably what I meant to say instead of locksmithing.
I just started watching videos on opening locks, and I instantly caught the reference. It really reinforces the old hacker mentality, I think, where you're doing kiiiinda in the grey area, but just because it's interesting. Whitehat-ish, I guess.
If you are after some cheap 'ok' wireless bulbs take a look at MiLight / LimitlessLED (they have various brand names). You can pick up bulbs for under $15 and the bridge for about the same from AliExpress.
They have the same issue as these in that white and RGB are seperate modes (so you can't control the saturation), but other than that they work fine and don't have any cloud "features".
The protocol of the bridge / app has been reverse engineered, and there are various libraries on GitHub:
Beware: the bridge for Milight bulbs also communicates outbound to a mystery server for Internet control of the bulbs. The actual RF protocol has been documented and implemented as Arduino code, though, which is what I use for my installation.
I have one of these and this is why I blocked the wifi bridge from any outgoing network access. The mystery server then just uses the MAC address of the bridge as the "authentication" of where you get to control the lights via the app.
Having a separate wifi network (and separate VLAN for wired) IoT devices sounds like a good idea, and is something that I'll be doing this weekend...
(Also will port-scan the MiLight bridge to see if it's got any other interesting services on it)
Last time I looked into the MiLight devices, it seemed like the protocol didn't support RGB but instead converted it into a more constrained space - is that accurate?
This is correct, if you want to use these for mood lighting you probably also want RGB+saturation as the effect will be much nice. For a cheap bulb that can be controlled programatically these are great though.
The biggest risks to my home network are my kid's friends. They bring their gaming laptops over and connect to the house network. No telling what is going on within my perimeter!
I used to run several internal networks, each with their own static external IP addresses, all mediated by pf on OpenBSD. There was a network for the kids, one for my wife and a couple for me. That was so much work and my wife always teased me that my machines always had better quality of service so I've gotten lazy and don't enforce security in the internal networks like I should--I'm even thinking about putting in a Ring doorbell.
I've had some of the Hue bulbs for a year or so, and I definitely wouldn't go back.
I now see two distinct kinds of lighting: task and ambient. For task lighting, I still want fast manual control, for which dumb bulbs are fine. But for ambient lighting, I want it to be almost entirely automatic.
In the morning, my lights gradually come on, starting very dim and warm. In the middle of the day, they're bright and like daylight in color. In the evening, they slowly dim and shift toward red. They go out on their own about when I want to go to bed.
One good part is that I don't have to mess with lightswitches all the time. But the much more valuable part is that it helps me establish a strong diurnal body clock. I now wake up on time without an alarm, I get enough sleep, and my mood is more even.
One alternative would be to put the smarts in the switches, as early home automation had it. But my old wiring isn't compatible with that. And even if it were, that at best gets you brightness control, not color temperature control.
Wow, I did something similar with the Hue bulbs, but I just used the rules api on the bridge combined with the virtual 'sunlight sensor' (and really long transition times) to trigger the light shifts. Similar setup to yours in effect though.
Ah, cool. I think they added the rules API later, otherwise I could well have done that. That's in some ways better; last year when my router died, my lights stuck on.
For what it's worth, I avoided tying the lights to actual daylight hours. In winter I tend to get a bit gloomy, and so part of my goal was to make my brain think that it was never really winter. It seemed to help this winter, although it's hard to say for sure.
Pretty good. My first pass at this did a very similar thing where I had a script running on a raspi to change the lights. Completely fair point about wanting to extend the lights during the winter. They switch to evening mode way too early lately and I kind of wish the rules api allowed you to do date based conditionals. That said, I have to do exactly 0 maintenance on it since I got the rules configured, so overall its pretty solid.
Fab. If you're interested in collaborating, drop me a note. I wrote my current software in Scala as an experiment, but I'm unlikely to do future work in Scala. I've been meaning to rewrite sunrise in something else, and I'm open to suggestion.
I was skeptical of this, but voice control of my lights has turned out to be incredibly useful. I can turn on the main lights while I'm taking my shoes off, before I'm in reach of the switches. I can dim lights from the sofa while watching TV. I can turn off individual lights. It's nothing earth-shattering in terms of importance, but it's something that does make my life better.
I can see the use, but what confuses me is why there's so much emphasis on putting the smarts in the bulbs. It would make a lot more sense to me to use normal bulbs and put the smarts in the switches. I'm sure there are switches out there like that, it's just not what people talk about.
There are modules like this: http://aeotec.com/z-wave-in-wall-switches/170-micro-smart-ap... that work with hubs like wink or smarthings, but home electrical wiring isn't consistent, so the installation isn't like the 1-2-3 easy setup you get from something like Hue.
Others have chimed in on the ease of bulb installation VS ease of switch installation. One other point is that the most you can get from a remote switch-only installation is variance in brightness, no RGB control.
Eh, it's a little easier. With the switch, when the lighting bits die (less common with LEDs now, but it still happens) you don't have to toss all the expensive switch electronics.
You are now behind their firewall.
If you are a hacker and you manage to get into a factory in China or Taiwan or wherever that is making these; you swap out the base firmware with one of your own that dials home. You are now behind the firewall of all customers.
Just some random thoughts before bed.