Spitballing IoT Security
lear at ofcourseimright.com
Thu Oct 27 05:59:00 UTC 2016
On 10/25/16 10:37 AM, Jean-Francois Mezei wrote:
> On 2016-10-25 04:10, Ronald F. Guilmette wrote:
>> If all of the *&^%$# damn stupid vacation pet feeders had originally shipped
>> with outbound rate limits hard-coded in the kernel, maybe this could have
>> been avoided.
> I view this differently.
> The problem is in allowing inbound connections and going as far as doing
> UPnP to tell the CPE router to open a inbound door to let hackers loging
> to that IoT pet feeder to turn it into an agressive DNS destroyer.
Well yes. uPnP is a problem precisely because it is some random device
asserting on its own that it can be trusted to do what it wants. Had
that assertion come from the manufacturer, at least you would know that
the device was designed to require that sort of access.**
> Then again, you need to have the owner access the pet feeder from the
> remote beach to feed the dog.
> One way around this is for the pet feeder to initiate outbound
> connection to a central server, and have the pet onwer connect to that
> server to ask the server to send command to his pet feeder to feed the dog.
> This way, there need not be any inbound connection to the pet feeder.
But if instead of a pet feeder we're talking about a home file sharing
system or a video camera where you don't want to share the feed into the
cloud? There will be times when people want inbound connections. We
need an architecture that supports them.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 481 bytes
Desc: OpenPGP digital signature
More information about the NANOG