Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

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.

View on HN

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

> 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

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

Reply on news.ycombinator.com