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