nanog mailing list archives

Re: Spitballing IoT Security


From: Eliot Lear <lear () ofcourseimright com>
Date: Thu, 27 Oct 2016 07:59:00 +0200

Hi Jean-Francois,


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.

Precisely so.

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.

Eliot

Attachment: signature.asc
Description: OpenPGP digital signature


Current thread: