('binary' encoding is not supported, stored as-is) Problem: RW access to the MIB, and eventually access to the router config, using ANY (yes, ANY) community name. The following routers were tested: ubr920, ubr924, ubr925 image file for the ubr925 is as follows: ubr925-k1sv4y556i-mz.121-3a.XL1 snmp-server commands used in each router config, not just the ubr925: snmp-server engineID local 0000000...(the rest) snmp-server community hardtoguess RO no snmp-server ifindex persist snmp-server manager These SNMP community names are just a few of the many used: xyzzy agent_steal freekevin fubar Notice, that not once, was the RO community name of 'hardtoguess' used, and there was no mention in the config of any RW string. A 'sh snmp comm' turned up only the RO name, as well as the widely documented 'cable-docsis' problem. Notice that no RW community is set. Several routers were tested. Solarwinds Network Browser was used, as well as the snmpset/snmpget/snmpwalk tools available in Linux. Tests were done from different machines, using several different OS'es, and these machines being placed on several different networks. Cisco PSIRT was contacted, and also a local cable provider, where it was determined that this provider definitely uses the same make and model of routers. The cable company responded only to the second part of the message, which was a request for prices of business-grade cable service. The response from Cisco was as follows: This behaviour in SNMP access is due to DOCSIS 1.0 standards which specifies that by default, there is no restrictions on SNMP access to the device. Cisco has to comply with DOCSIS standards in order to produce a CableLabs certified product. Cisco has tried very hard to convince Cablelabs that their approach is wrong, but have had no success. Cablelabs standards provides a mechanism (via a DOCSIS config file) to automatically configure SNMP access list as the device attaches to the network. It is assumed (by Cablelabs) that prior to this time, security is not critical since the device gets its configuration (via the DOCSIS config file) before anyone can do any harm. The document is TP-OSSI-ATPv1.1-I01-011221. The specific is on 2.1.7 CM Network management Access and SNMP Co-existence (OSS-07.1), 1 Default Access. It is on page OSS-7.1 page 3 of 11. It states "The Default Access test verifies the CM agent supports full SNMP access from an NSI side NMS and from a CPE side NMS after the CM completes registration with the basic1.cfg configuration file. The term "Default Access" implies no docsDevNmAccessTable row and no SNMPv3 configuration was supplied to the CM. Any SNMP read and any SNMP write community string can be used for this test, since compliant CMs will allow open access in the Default Access condition." This document is available from Cablelabs at http://www.cablemodem.com/ . The docsis spec has explicit requirements about the implementation and it modifies what is mentioned in RFC2669. It is also explicitly stated that it overrides the RFC should any conflict arises. Cisco's implementation has been certified by CableLabs multiple times. Once Cablelabs changes its requirement Cisco would make the mdifications to its products. ----end of response from Cisco------------------ I may be wrong, but it seems to me that a cablemodem or cablerouter being used already out on the internet, would already have loaded the DOCSIS config file, and thus the SNMP access would depend only on the snmp-server commands entered into the IOS config. Possible workaround would be to create a specific RW community name, and make it accessible only from a machine on the internal network, or to stop using SNMPv1 altogether, or not to use SNMP at all. At this time, I have not tested any of these potential solutions. Regards, Scott Security Secrets Wichita, KS
This archive was generated by hypermail 2b30 : Sun Dec 30 2001 - 17:36:44 PST