[192275] in North American Network Operators' Group
Re: Death of the Internet, Film at 11
daemon@ATHENA.MIT.EDU (Eliot Lear)
Mon Oct 24 08:49:20 2016
X-Original-To: nanog@nanog.org
To: nanog@nanog.org
From: Eliot Lear <lear@cisco.com>
Date: Mon, 24 Oct 2016 14:49:07 +0200
In-Reply-To: <20161022125335.GA84013@ussenterprise.ufp.org>
Errors-To: nanog-bounces@nanog.org
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--O5JtRQlXKDoWcHP5ohUgifQW5eQGwx5QG
From: Eliot Lear <lear@cisco.com>
To: nanog@nanog.org
Message-ID: <b453f392-5984-0c5f-609f-cfab546e6954@cisco.com>
Subject: Re: Death of the Internet, Film at 11
References: <85864.1477115622@segfault.tristatelogic.com>
<430335629.3600.1477139691877.JavaMail.mhammett@ThunderFuck>
<20161022125335.GA84013@ussenterprise.ufp.org>
In-Reply-To: <20161022125335.GA84013@ussenterprise.ufp.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Leo and all,
Well, here we are together again ;-) Please see below.
On 10/22/16 2:53 PM, Leo Bicknell wrote:
> In a message written on Sat, Oct 22, 2016 at 07:34:55AM -0500, Mike Ham=
mett wrote:
>> "taken all necessary steps to insure that none of the numerous specifi=
c types of CCVT thingies that Krebs and others identified"=20
> From https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-to=
days-massive-internet-outage/#more-36754
>
> The part that should outrage everyone on this list:
>
> That's because while many of these devices allow users to chang=
e
> the default usernames and passwords on a Web-based administrati=
on
> panel that ships with the products, those machines can still be=
> reached via more obscure, less user-friendly communications ser=
vices
> called "Telnet" and "SSH."
>
> "The issue with these particular devices is that a user cannot
> feasibly change this password," Flashpoints Zach Wikholm told
> KrebsOnSecurity. "The password is hardcoded into the firmware,=
and
> the tools necessary to disable it are not present. Even worse, =
the
> web interface is not aware that these credentials even exist."
>
> As much as I hate to say it, what is needed is regulation. It could
> be some form of self regulation, with retailers refusing to sell
> products that aren't "certified" by some group. It could be full
> blown government regulation. Perhaps a mix.
We we discussed the last time, this is an opportunity. Let's not miss
again. People have been mentioning BCP38. That BCP needs a dust-off.=20
as mentioned, simply masking an address in a BOTNET attack is a
relatively small component of the problem that often gets solved by
accident with NATs. We have a broader set of issues to address, and
anyone looking for a single silver bullet will be disappointed.
The questions that need asking are these:
* What is the responsibility of the end system (either side) and its
developer/manufacturer? What are the things Thing developers should
be doing?
* What is the responsibility of the home router? How can home routers
enable appropriate access for a device while stopping unwanted
traffic? I won't repeat the ENTIRE thread, but
draft-ietf-opsawg-mud-01.txt can help and I'll provide an example
MUD file as a postscript to this message that would have stopped
infection of some DVRs.
* What is the responsibility of the provider access router? {You fill
in this part}
* What is the responsibility of the provider peering router? BCP38
filtering, use of ROAs, BGPSEC, and other fighting words ;-)
* What is the responsibility of the consumer? Less is more, here, I
think.
* What is the responsibility of government?
I would suggest that we have two or three documents to be written, which
combined could be an update to BCP38. And the answers to each of these
questions are going to evolve over time. That's okay. BCPs should be
living documents.
>
> It's not a problem for a network operator to "solve", any more than
> someone who builds roads can make an unsafe car safe. Yes, both
> the network operator and rood operator play a role in building safe
> infrastructure (BCP38, deformable barriers), but neither can do
> anything for a manufacturer who builds a device that is wholely
> deficient in the first place.
>
Yes.
Eliot
ps: here's that MUD file. It's possible to write it in more specific
language. Probably not necessary. What is important is that someone
fill in the class "http://dvr264.example.com/controller". That's not
hard, but needs doing. What happens next is that the class gets
expanded and access lists get installed, preferably on the home router.=20
And this means that the home router needs to play a bigger role of
limiting ingress even in the home. That can prevent reflection attacks,
for instance.
{
"ietf-mud:meta-info": {
"lastUpdate": "2016-10-23T14:11:52+02:00",
"systeminfo": "DVR H.264",
"cacheValidity": 1440
},
"ietf-acl:access-lists": {
"ietf-acl:access-list": [
{
"acl-name": "mud-10387-v4in",
"acl-type": "ipv4-acl",
"ietf-mud:packet-direction": "to-device",
"access-list-entries": {
"ace": [
{
"rule-name": "clout0-in",
"matches" : {
"ietf-mud:direction-initiated" : "from-device"
},
"actions": {
"permit": [
null
]
}
},
{
"rule-name": "entin0-in",
"matches": {
"ietf-mud:controller":
"http://dvr264.example.com/controller",
"ietf-mud:direction-initiated" : "to-device"
},
"actions": {
"permit": [
null
]
}
}
]
}
},
{
"acl-name": "mud-10387-v4out",
"acl-type": "ipv4-acl",
"ietf-mud:packet-direction": "from-device",
"access-list-entries": {
"ace": [
{
"rule-name": "clout0-in",
"matches": {
"ietf-mud:direction-initiated" : "from-device"
},
"actions": {
"permit": [
null
]
}
},
{
"rule-name": "entin0-in",
"matches": {
"ietf-mud:controller": "http://dvr264.example.com/controller",
"ietf-mud:direction-initiated" : "to-device"
},
"actions": {
"permit": [
null
]
}
}
]
}
}
]
}
}
--O5JtRQlXKDoWcHP5ohUgifQW5eQGwx5QG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
iQEcBAEBCAAGBQJYDgNEAAoJEIe2a0bZ0noz+JEH/1V6BhLSOzAX3H4kd/SnVg0y
eq4Y4lRo5eANokALxLJkis4O49QGQ9rkOSGtjPw9fP2dssItf/PVVwL8R3V5bngI
L4rkLkjOR02j0lJFXK90FtDmVR14qynwCQhfN00D0UXYqItzC2v8pJL9d0QKjY9/
8qcV0wdSb9BOgiAch8kT6i4hEfNJyQic4LGQMxvNa6kfO9S+s17CmrQ3JIOCZMY2
sfEfW+7iiuzvNaDORHgMNqcpf65bitDzX+mv/dhou7/i1CvxosdiywlMfsOqsfkG
vUUg3XHluTl2ciTEAvAJguKiRGc1PCDEgrBOgq7OsNqCVHrwEc8hDjyt8TdqVSM=
=q8mJ
-----END PGP SIGNATURE-----
--O5JtRQlXKDoWcHP5ohUgifQW5eQGwx5QG--
