Spitballing IoT Security

Matthias Waehlisch m.waehlisch at fu-berlin.de
Mon Oct 24 22:09:26 UTC 2016

IoT is not a well-defined term.
IoT implementations depend on system constraints.
These constraints may relate to security (problems/solutions).
It would be helpful to be more specific.
See https://tools.ietf.org/html/rfc7228, for example.


On Mon, 24 Oct 2016, Jared Mauch wrote:

> Top posting to provide some clarity:
> 1) Many IoT devices are connected via some cloud service, think Nest (for example)
> 2) Many IoT devices have cloud management, think of Ruckus, UBNT UniFi, etc that
>    phone out to a site via DHCP option or otherwise.
> 3) Many IoT devices are something like a set top box, these need access to a CDN
>    or similar to get the content for the users.
> 4) Many IoT consumers don’t read NANOG, so they also won’t set up a firewall other
>    than to know it is a service impairing tool that must be disabled for their
>    devices to work.
> 5) There are few/no new lessons here compared to the default install of Redhat 3.0.3
>    from the late-1990s.  I recall it by default installed INN a usenet news server.
>    As a usenet operator, this baffled me as they had insufficient memory, storage
>    etc to do this task, and left security surface quite wide.
>    We must promote secure by default.  This means some sort of secondary authentication
>    such as a sticker on the device with default password or requiring the entering of
>    a serial number or basic setup information to work.
> 6) Devices need to prompt for updates.
>    Apple has sorted this nicely, people are prompted for supported upgrades, disjoint
>    from carriers and other issues.  Contrast this with other ecosystems where upgrades
>    require extra steps or have a non-OEM partner involved (eg: Cell Carrier, Cable Co).
>    These devices get less frequent updates, ostensibly for testing but also leave known
>    issues exposed for months or years.
> 7) Malware can damage systems making them require extra steps to recover them.  Whitehats
>    may know some mitigation techniques, but can’t protect you either.  Some people have
>    taken a more aggressive approach, eg: https://gitlab.com/rav7teif/linux.wifatch
>    They will block others from infecting your device until it’s rebooted.
> - Jared
> > On Oct 24, 2016, at 4:24 PM, Ronald F. Guilmette <rfg at tristatelogic.com> wrote:
> > 
> > 
> > In message <e364fcea-7105-b3b9-63a9-7d22ab83516c at nuclearfallout.net>, 
> > John Weekes <jw at nuclearfallout.net> wrote:
> > 
> >> On 10/23/2016 4:19 PM, Ronald F. Guilmette wrote:
> > jw>>> ... The ISPs behind those IP addresses have
> > jw>>> received notifications via email...
> > rfg>> Just curious... How well is that working out?
> >> 
> >> For the IoT botnets, most of the emails are ignored or rejected, because 
> >> most go to providers who either quietly bitbucket them or flat-out 
> >> reject all abuse emails. Most emails sent to mainland China, for 
> >> instance, are in that category (Hong Kong ISPs are somewhat better)...
> > 
> > So, given the apparently impracticality of trying to clean up all of these
> > kinds of messes via the good old-fashioned tedious and laborious method
> > of emailing the relevant providers and then just sort-of vaguely hoping
> > that they will -do something- responsible with it, I am just sitting here
> > trying to dream up some sort of generalized long-term fix for -all- of
> > these IoT DDoS type problems.
> > 
> > Maybe there just plain isn't any such thing as a general solution to the
> > problem, because it may perhaps be just technically too complex.  But I hope
> > no one will begrudge me if I yearn for some sort of Grand Unified Field
> > Theory of IoT security.
> > 
> > So, I have a thought... probably worth what you paid for it... and I'm just
> > brave enough to throw it out on the table and then everybody can pile on
> > and tell me what an idiot I am, for this or that perfectly sound technical
> > reason.  (I'll say up front that I don't even pretend to understand many
> > of the protocols in use these days, in particular UPnP, and to be frank,
> > I'd never even heard of SSDP until yesterday.  So I can't and won't begrudge
> > anybody who tells me that I have my head up... ummm... in the clouds.)
> > 
> > So anyway, here are the assumptions/assertions, perhaps wrong, which are my
> > starting point:
> > 
> >    1)  I am not persuaded that IoT devices have a compelling need to them-
> >        selves initiate outbound TCP sessions, ever.  (If I'm wrong about
> >        this, then I'm sure people here will tell me.)
> > 
> >    2)  Likewise, I am not persuaded that IoT devices have an absolute and
> >        compelling need to do very much in the way of UDP.  Yes, I would
> >        like my smart XYZ device to always know what time it is, so, you
> >        know, a modest amount of NTP traffic is reasonable and to be expected.
> >        Other than that however, I don't see a compelling need.  If you want
> >        to either control or get data out of your IoT device, you can make
> >        an inbound TCP connection to it.
> > 
> >        (Somebody will probably say "Oh, no.  We need to stream real-time
> >        video out of some of these things, and for that we absolutely have
> >        to send the stuff via outbound high-bandwidth UDP." but I am not
> >        persuaded that this is either absolutely necessary or even Good,
> >        i.e. from the point of view of the legitimate security concerns of
> >        the owner of the device.)
> > 
> > So, based on the above perhaps flawed assumptions, here is my idea.  It is
> > composed of two simple parts:
> > 
> >   1)  First, I will successfully complete my campaign to be elected King
> >       of the World.  (Given the current poltical climate, worldwide, this
> >       should not be a problem, because I lie a lot.)
> > 
> >   2) Second, once elected I will decree that in future all new IoT devices,
> >      and also all updates to firmware for existing IoT devices will have,
> >      BUILT IN TO THE KERNEL, code/logic which (a) prevents all outbound TCP
> >      session initiation and which also (b) strictly rate-limits all other
> >      protocols to some modest value.
> > 
> > Remember, we're going to have a few billion of these devices online in the
> > coming years.  If even and modest subset of these can ever be tricked by an
> > attacker into spewing non-rate-controlled traffic towards an attacker-
> > selected target, then we're gonna have a problem.
> > 
> > 
> > Regards,
> > rfg

Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

More information about the NANOG mailing list