Death of the Internet, Film at 11

Eliot Lear lear at cisco.com
Mon Oct 24 12:49:07 UTC 2016


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
                   ]
                 }
               }
             ]
           }
         }
       ]
     }
   }


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20161024/1a408dfa/attachment.sig>


More information about the NANOG mailing list