Hacker News Reader

Comment by pmontra | Hacker News Reader

That would mean blocking the ISP, and every ISP, so it's the end of blocking because there won't be any legitimate traffic left.

The manufacturers must be both sued for selling exploitable devices and educated about how to write secure software.

There is another post on the home page of HN about the security of the Linux kernel https://news.ycombinator.com/item?id=12589894 That's very important for this kind of issues because many of those devices are probably running on some Linux distribution.

View on HN

This is why a proper and solid patch routine is of utmost importance.

I'm a devops guy so I'm basically a sysadmin and I've been an advocate for patch routines for many years now. In a climate where people are almost offended when you tell them they need to patch their servers regularly.

So if IoT is really the Internet of things and not the Intranet of things, then they need solid routines for patching their software.

Yeah, and having an automatic, secure, reliable patching routine for embedded devices is not trivial (and thus really expensive). What's even worse, we already have millions of deployed devices, and some of these probably don't support upgrading the firmware at all, or require manual intervention from users who have no idea they are part of the botnet.

> Yeah, and having an automatic, secure, reliable patching routine for embedded devices is not trivial (and thus really expensive).

Roku (and others) seems to have figured that out. They cryptographically sign each update.

Roku legitimately needs to initiate connections outside the home. Can the same be said for e.g. a light bulb? If switches don't drop these packets, then routers should, and if they don't, then ISPs should. Is there a field in DHCP that could be used to communicate the fact that a particular host should generate no outside traffic?

My first thought would be to set the default gateway to 127.0.0.1. It should mean that they can't route packets to anything outside their LAN?

I meant that the light bulb could tell the router "I'm IoT so assume I'm pretty dumb", to which information the router could respond in any number of ways. I don't think your setting would have the effect we want, however. The light bulbs have to talk to whatever is supposed to control them, so they have to be able to see the LAN.

The gateway is needed to route outside of the local subnet, so if the bulb is 192.168.1.17, it can talk to anything in 192.168.1.0/24 (presuming a standard home user setup), but anything else would get 'no route to host' errors on initial connection attempts.

You'd need to configure the DHCP to hand out these kinds of leases by MAC address though, as I can't see vendors agreeing on a way to easily restrict the devices net access! :-/

Perhaps your average router needs a button to 'add device', only allowing new devices access via something like the WPS button with a term second window for new DHCP request incoming? Otherwise the DHCP ignores any incoming request, just sleeps. Adds one step in the quickstart guide.

Don't assign the device a default gateway (or set it to 0.0.0.0 if one is "required").

I have thought for a long time that we'll one day get to the point where the best thing one can do for a host's security is to not allow it to generate traffic that can reach the Internet.

Just like we have default deny on incoming traffic, we need to start using a default deny on outgoing traffic as well.

>so it's the end of blocking

not really, ISP gets dropped, goes into panic mode and FINALLY fixes its own shit, finds the endpoint originating illegitimate traffic and blocks it, reports back upstream about the fix, gets reinstated, finally starts monitoring for ip spoofing.

Another problem: video service A runs on server farm X which blocks IPs of ISPs known for being the origin of DOSes. Video service B runs on server farm Y which doesn't. Who makes more money between the two video services and between the two server farms? As long as Y is not hit, I bet on B and Y.

Furthermore, but I'm a noob at this, isn't the upstream Internet provider that should block traffic instead of the server farm? Otherwise it would get all the load anyway. Am I wrong? (probably yes)

Just filter the BGP AS of the offending ISP. That's how it should be done. Block the whole ISP at AS level. Maybe automated time based threshold filters w/ distributed banlist. Just like fail2ban but for BGP and with a distributed banlist (AS + timestamp of exceeded threshold).

In many cases there is no vulnerability. The box has default credentials of admin:admin and someone puts it on the internet and never changes the password.

Reply on news.ycombinator.com