8 ms·

Jesus I was just thinking about the consequences of no patch routine in the IoT device world. And, here it is. :) Imagine having to internationally co-ordinate

Jesus I was just thinking about the consequences of no patch routine in the IoT device world. And, here it is. :) Imagine having to internationally co-ordinate patching of 150000 devices. Because the alternative is that 150000 homes will have their NATed IP-addresses blocked from each service being attacked. Just wow...

pmontra 10y ago
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 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.
- INTPenis 10y ago
  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.
  - ge0rg 10y ago
    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.
    - bcook 10y ago
      > 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.
      - jessaustin 10y ago
        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?
        tehmaco 10y ago
        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?
        jessaustin 10y ago
        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.
        tehmaco 10y ago
        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! :-/
  - deleted 10y ago
    [deleted]
- rasz_pl 10y ago
  >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.
  - pmontra 10y ago
    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)
    - petre 10y ago
      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).
- justinsaccount 10y ago
  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.
rasz_pl 10y ago
you dont have to coordinate any patching, just null route end users who are the source of DOS and let them deal with it. Its them who opted for $25 with free shippintg 720p 'Cloud based, works with your iphone' nanny cam.

pmontra 10y ago

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

INTPenis 10y ago
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.
- ge0rg 10y ago
  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.
  - bcook 10y ago
    > 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.
    - jessaustin 10y ago
      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?
      - tehmaco 10y ago
        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?
        jessaustin 10y ago
        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.
        tehmaco 10y ago
        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! :-/
- deleted 10y ago
  [deleted]
rasz_pl 10y ago
>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.
- pmontra 10y ago
  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)
  - petre 10y ago
    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).
justinsaccount 10y ago
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.

rasz_pl 10y ago

you dont have to coordinate any patching, just null route end users who are the source of DOS and let them deal with it. Its them who opted for $25 with free shippintg 720p 'Cloud based, works with your iphone' nanny cam.