[192294] in North American Network Operators' Group
RE: Spitballing IoT Security
daemon@ATHENA.MIT.EDU (Steve Mikulasik)
Mon Oct 24 16:44:46 2016
X-Original-To: nanog@nanog.org
From: Steve Mikulasik <Steve.Mikulasik@civeo.com>
To: "Ronald F. Guilmette" <rfg@tristatelogic.com>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Mon, 24 Oct 2016 20:42:53 +0000
In-Reply-To: <1722.1477340699@segfault.tristatelogic.com>
Errors-To: nanog-bounces@nanog.org
May as well throw in my idea here too. Can ISPs just block their clients fr=
om being reached by CNC servers? If we could get a service like Spamhaus fo=
r botnets and have service providers automatically blackhole those CNC IPs.=
Having this done at the tier 1 level would probably cause some pain to the=
botnets out there. Rather than pushing customers to secure their stuff (i=
mpossible), how about we try to stop communication to the CNC. For example=
, these guys https://zeustracker.abuse.ch/monitor.php keep track of Zeus, i=
f we automatically blackholed those IPs as they get updated it could put a =
big dent in the effectiveness of Zeus.
It won't solve the problem, but it could put a dent in it. ISP's might like=
to implement it since it could cut down on transit costs due to DDoS traff=
ic.=20
-----Original Message-----
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ronald F. Guilmet=
te
Sent: Monday, October 24, 2016 2:25 PM
To: nanog@nanog.org
Subject: Spitballing IoT Security
In message <e364fcea-7105-b3b9-63a9-7d22ab83516c@nuclearfallout.net>,
John Weekes <jw@nuclearfallout.net> wrote:
>On 10/23/2016 4:19 PM, Ronald F. Guilmette wrote:
jw>>> ... The ISPs behind those IP addresses have received notifications=20
jw>>> via email...
rfg>> Just curious... How well is that working out?
>
>For the IoT botnets, most of the emails are ignored or rejected,=20
>because most go to providers who either quietly bitbucket them or=20
>flat-out reject all abuse emails. Most emails sent to mainland China,=20
>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 t=
hey 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 D=
DoS type problems.
Maybe there just plain isn't any such thing as a general solution to the pr=
oblem, 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 The=
ory 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 a=
nd tell me what an idiot I am, for this or that perfectly sound technical r=
eason. (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 n=
ever even heard of SSDP until yesterday. So I can't and won't begrudge any=
body 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 expect=
ed.
Other than that however, I don't see a compelling need. If you wan=
t
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 TC=
P
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- sel=
ected target, then we're gonna have a problem.
Regards,
rfg
