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