Hacker News Reader

Comment by api | Hacker News Reader

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.

View on HN

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?

Just don't route packets from the bulbs to your other devices.

That's a good idea, but that logic has to be on the switch. Unless one has a very simple network, the firewall is somewhere else.

VLANs can be used to achieve this goal with a non-trivial network too.

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'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.

"All or nothing" is not how risk management works in the real world.

P.S. 'Network security' is just a specific case of risk management.

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.

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.

How about completely separated WiFi network for all IoT junk?

Good idea. A lot of high end routers have an option for a "guest network" these days. Or just invest in a cheapo access point just for IoT devices.

Depends on your paranoia level if you trust something like that, but most people have old wifi enabled routers just laying around

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.

Not if you keep IoT devices on a separate network

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.

Does a 2000 mile data path to a light bulb seem dumb to anyone else?

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.

These days it's just as important to monitor and filter outgoing traffic to detect trojans and unfriendly devices trying to phone home.

> 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.

Sounds like we need a firewall in the switch/AP

"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.

And for people who get paid to hack cloud-based servers so they can control the domestic appliances of entire countries.

Sounds comical, but turning up a few million fridge or aircon thermostats would cause serious load issues on most local and/or national power grids.

... or flush every toilet in New York at once. Barrels of fun.

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.

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.

IoT isn't the issue, cellular and long-range wifi networking is the problem -- there is no network boundaty anymore.

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 think there's an important distinction between firewalls for client security and firewalls for server security.

Luckily, our devices have beefier security now. It`s much harder to spoof gmail or facebook or paypal these days.

Reply on news.ycombinator.com