Death of the Internet, Film at 11

Mon Oct 24 13:06:22 UTC 2016

On Monday, October 24, 2016, Eliot Lear <lear at cisco.com> wrote:

> 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
> Hammett wrote:
> >> "taken all necessary steps to insure that none of the numerous specific
> types of CCVT thingies that Krebs and others identified"
> > From https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-
> powered-todays-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 change
> >         the default usernames and passwords on a Web-based administration
> >         panel that ships with the products, those machines can still be
> >         reached via more obscure, less user-friendly communications
> services
> >         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.
> 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.
> 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
>                    ]
>                  }
>                }
>              ]
>            }
>          }
>        ]
>      }
>    }
>
>
Assuming MUD is successful in the ietf, the cpe lifecycle is 10 years
before the needle moves. At which point the target will have morphed to
something else. Also, nobody is going to pay for that feature. Just like
the early days of ipv6, the economics were misaligned.

in 10 years, the CPE will also be running PCP, where the bot tells the CPE
to ignore all of MUD and open any arbitrary port it wants.

Or, in 10 years we stopped using ipv4 (!!!!) wherein it is now unlikely to
enumerate via the entire address space to find the telnet logins.

My money is on dropping ipv4 as the most viable and most bang for the buck.
It makes many of today's problems go away. Also, stopping support for ipv4
drops off the lowest of the low (like windows xp)