The effectiveness of any workarounds is dependent on specific customer
situations such as product mix, network topology, traffic behavior and
organizational mission. Due to the variety of affected products and releases,
customers should consult with their service provider or support organization to
ensure any applied workaround is the most appropriate for use in the intended
network before it is deployed.
The following workarounds should only be considered as a long term
solution if anti-spoofing methods consistently prevent spoofed source attacks
from entering the network and access-lists provided below are configured on
every potentially affected device.
Disable the SNMP Server
If the SNMP server is not used for any legitimate purposes on the
device, it is a best practice to disable it by issuing the following commands
in configure mode:
Removing the public community string with the configure command
no snmp-server community <string> ro is not
sufficient as the SNMP server will still be running and the device will be
vulnerable. The command no snmp-server must be used
instead. The SNMP server status may be verified by using the enable command
show snmp. You should see a response of "%SNMP agent
Note that this workaround may only be viable if SNMP is not used in
any way for managing the device.
Restrict Access via a Community-map
The ability to create a community-map was introduced in Cisco IOS
versions 12.0(23)S, 12.2(25)S and 12.3(2)T. This feature adds the ability to
create a mapping between an SNMP community and an SNMP context, Engine ID, or
security name that is different from the default settings.
When an SNMP community is associated with an SNMP context, whenever a
request is made from this community, it is applied to the context specified.
This feature can also be used to specify the source address validation for an
Consider the following example:
Router(config)#access-list 65 remark Deny access to community string
Router(config)#access-list 65 deny any
Router(config)#snmp-server community no-access RO 65
Router(config)#snmp mib community-map cable-docsis security-name no-access
The above creates a new community named "no-access". The authorization
to use the community "no-access" is controlled by an access-list, which in this
case denies all hosts from using it. With the addition of the snmp
mib community-map command, the current community string of
"cable-docsis" is then under the access restrictions of the new community
string "no-access" preventing any use of the "cable-docsis" community string.
Control Plane Policing
Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T
support Control Plane Policing (CoPP) which may be configured to protect the
device from attacks that target the management and control planes. The
following example can be adapted to your network. This example assumes that all
SNMP access is to be restricted to a management station with the IP address of
10.1.1.1, and that the management station need only communicate with router's
IP address 192.168.10.1:
access-list 111 deny udp host 10.1.1.1 host 192.168.10.1 eq snmp
access-list 111 permit udp any any eq snmp
access-list 111 deny ip any any
class-map match-all drop-snmp-class
match access-group 111
service-policy input drop-snmp-policy
Please note that in the 12.0S, 12.2S, and 12.2SX Cisco IOS trains the
policy-map syntax is different:
police 32000 1500 1500 conform-action drop exceed-action drop
In the above CoPP examples the ACL entries that match the exploit
packets with the "permit" action result in these packets being discarded by the
policy-map "drop" function, while packets that match the "deny" action are not
affected by the policy-map drop function.
Additional information on the configuration and use of the CoPP
feature can be found at the following URL:
Restrict Access to Trusted Hosts Only
Access Control Lists (ACLs) can be used to deny traffic to the device.
Although Cisco IOS devices have community-string access lists which check the
source address of SNMP requests per community string, they will not work in
this case as the cable-docsis community string is not able to be modified or
deleted via configuration options.
It is possible to permit UDP traffic to the router from trusted IP
addresses with interface ACLs.
Note: Because SNMP is based on UDP, it is possible to spoof the sender's
IP address, which may defeat ACLs that permit communication to these ports from
trusted IP addresses.
The following extended access-list can be adapted to your network.
This example assumes that the router has IP addresses 192.168.10.1 and
172.16.1.1 configured on its interfaces, that all SNMP access is to be
restricted to a management station with the IP address of 10.1.1.1, and that
the management station need only communicate with IP address 192.168.10.1:
access-list 101 permit udp host 10.1.1.1 host 192.168.10.1 eq snmp
access-list 101 deny udp any host 192.168.10.1 eq snmp
access-list 101 deny udp any host 172.16.1.1 eq snmp
access-list 101 permit ip any any
The access-list must then be applied to all interfaces using the
following configuration commands:
interface FastEthernet 0/0
ip access-group 101 in
Note that UDP traffic to port 161 (SNMP) must be explicitly blocked to
each IP address on the router to prevent the router from accepting and
processing the SNMP packets. Blocking traffic to port 161 from unknown hosts is
considered a best practice. All devices that need to communicate directly with
the router on port 161 will need to be specifically listed in the above access
For devices that have many IP addresses configured, or many hosts that
need to communicate with the router, this may not be a scalable solution.
Infrastructure ACLs (iACL)
Although it is often difficult to block traffic transiting your
network, it is possible to identify traffic which should never be allowed to
target your infrastructure devices and block that traffic at the border of your
network. Infrastructure ACLs are considered a network security best practice
and should be considered as a long-term addition to good network security as
well as a workaround for this specific vulnerability. The white paper entitled
"Protecting Your Core: Infrastructure Protection Access Control Lists" presents
guidelines and recommended deployment techniques for iACLs: