[192293] in North American Network Operators' Group
Re: Spitballing IoT Security
daemon@ATHENA.MIT.EDU (Jared Mauch)
Mon Oct 24 16:41:45 2016
X-Original-To: nanog@nanog.org
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <1722.1477340699@segfault.tristatelogic.com>
Date: Mon, 24 Oct 2016 16:41:39 -0400
To: "Ronald F. Guilmette" <rfg@tristatelogic.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
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=E2=80=99t read NANOG, so they also won=E2=80=99t=
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=E2=80=99t 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=E2=80=99s =
rebooted.
- Jared
> On Oct 24, 2016, at 4:24 PM, Ronald F. Guilmette =
<rfg@tristatelogic.com> wrote:
>=20
>=20
> In message <e364fcea-7105-b3b9-63a9-7d22ab83516c@nuclearfallout.net>,=20=
> John Weekes <jw@nuclearfallout.net> wrote:
>=20
>> 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?
>>=20
>> For the IoT botnets, most of the emails are ignored or rejected, =
because=20
>> most go to providers who either quietly bitbucket them or flat-out=20
>> reject all abuse emails. Most emails sent to mainland China, for=20
>> instance, are in that category (Hong Kong ISPs are somewhat =
better)...
>=20
> 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.
>=20
> 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.
>=20
> 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.)
>=20
> So anyway, here are the assumptions/assertions, perhaps wrong, which =
are my
> starting point:
>=20
> 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.)
>=20
> 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.
>=20
> (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.)
>=20
> So, based on the above perhaps flawed assumptions, here is my idea. =
It is
> composed of two simple parts:
>=20
> 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.)
>=20
> 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.
>=20
> 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.
>=20
>=20
> Regards,
> rfg
