Spitballing IoT Security

Tue Oct 25 11:26:21 UTC 2016

In message <580F19BF.2070002 at vaxination.ca>, 
Jean-Francois Mezei <jfmezei_nanog at vaxination.ca> wrote:

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

Right.  And even that one outbound connection (from the pet feeder to
the central server) isn't going to need much in the way of bandwidth.

So if the kernel wakes up and notices "Whoa!  Wait a minute here!
This box is sending out in excess of 100 kilobits per second!" then
something is REALLY wrong here.  Time to let that ethernet interface
take a little nap.

Likewise if the kernel notices that the box has just sent out in excess
of, say, 100 outbound UDP packets with destination port set to 53 in the
last 60 seconds.  Time to send DNS to its room for a little "bad behavior"
time out!  Because in practice, for most or all of the kinds of IoT devices
I can think of, (a) they shouldn't be sending out DNS -responses-, ever,
and (b) if they are sending out more than, say, 100 outbound DNS -queries-
per minute, then the only possible reason they would be doing so is that
the box itself has been enslaved and is participating in a DNS reflection
attack.

The point is that for many (most?) types of IoT devices the engineers
who designed the box should be able to tell... or at least predict...
what the maximum theoretical outbound bandwidth usage and/or the maximum
theoretical outbound packets per second for various protocols and ports
ought to be... assuming that the box is functioning "normally", as the
original design engineers intended, and not as some miscreant's slave.
So then they, the original design engineers, can hard code limits into
the kernel... limits that are, say, 25% above these worst case "normal
operation" limits, thus allowing for a healthy margin of error.

The result would be a box that can't be turned into a weapon, no matter
what, at least not without loading up all new (and malicious) firmware,
a task which should require at least some direct, hands-on manually
fiddling (such as pressing and holding the reset button) in any event.

I refer again to the Ford Pinto, and also to the Apollo 1 fire.  I don't
think that there's really a problem with engineering belt-and-suspenders
safeguards into the firmware of IoT things.  The only real problem is
providing both companies and engineers with the motivation necessary to
insure they will do so.

Let's hope that nobody has to die before we find a way to manufacture
that motivation.  (A little temporary bad press for one Chinese manu-
facturer of CCTV cameras isn't going to be sufficient, I'm afraid.)

Regards,
rfg