The following identification mechanisms exist for this vulnerability:
Embedded Event Manager
A Cisco IOS Embedded Event Manager (EEM) policy that is based on Tool Command Language (Tcl) can be used on vulnerable Cisco IOS devices to identify and detect an interface queue wedge that is caused by this vulnerability. The policy allows administrators to monitor the interfaces for Cisco IOS device and detect when the interface input queues are full. When Cisco IOS EEM detects potential exploitation of this vulnerability, the policy can trigger a response by sending an alert to the network administrator, who could then decide to implement an upgrade, implement suitable mitigations or reload the device to clear the input queue.
The Tcl script is available for download at the "Cisco Beyond: Embedded Event Manager (EEM) Scripting Community" at the following link: https://supportforums.cisco.com/docs/DOC-19337
Also see the Cisco Security Blog "Cisco IOS Queue Wedges Explained" at the following link: http://blogs.cisco.com/security/cisco_ios_queue_wedges_explained/
The following mitigations exist for this vulnerability:
IP RSVP Listener
It is possible to mitigate this vulnerability under affected configurations by applying the global configuration command ip rsvp listener vrf vrf-name ip-address udp 1698 announce
, where the IP address is one that does not exist on the device or in the routing tables.
Infrastructure Access Control Lists (iACL) and Unicast Reverse Path Forwarding (uRPF)
Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. In addition to ACLs, administrators should enable uRPF, a security feature of Cisco IOS Software that verifies the reachability of the source address in packets being forwarded. The combination of these two technologies offers a stronger migration than iACLs alone.
Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure ACLs (iACLs) are 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 iACL example below should be included as part of the deployed infrastructure access-list, which will help protect all devices with IP addresses in the infrastructure IP address range:
!---!--- Feature: RSVP over UDP!---
access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD
INFRASTRUCTURE_ADDRESSES WILDCARD eq 1698
!--- Deny RSVP over UDP traffic from all other sources destined !--- to infrastructure addresses.
access-list 150 deny udp any
INFRASTRUCTURE_ADDRESSES WILDCARD eq 1698
!--- Permit/deny all other Layer 3 and Layer 4 traffic in !--- accordance with existing security policies and !--- configurations. Permit all other traffic to transit the!--- device.
access-list 150 permit ip any any
!--- Apply access-list to all interfaces (only one example!--- shown)
interface fastEthernet 2/0
ip access-group 150 in
The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists and is available at the following link http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml
Control Plane Policing
Because the feature in this vulnerability utilizes UDP as a transport, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. Unicast RPF should be considered to be used in conjunction to offer a better mitigation solution.
Control Plane Policing (CoPP) can be used to block untrusted UDP traffic to the device. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be configured on a device to help protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. The CoPP example below should be included as part of the deployed CoPP, which will help protect all devices with IP addresses in the infrastructure IP address range.
!--- Feature: RSVP over UDP
access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD
any eq 1698
!--- Deny RSVP over UDP traffic from all other sources destined !--- to the device control plane.
access-list 150 permit udp any any eq 1698
!--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and !--- Layer4 traffic in accordance with existing security policies !--- and configurations for traffic that is authorized to be sent !--- to infrastructure devices !--- Create a Class-Map for traffic to be policed by!--- the CoPP feature
class-map match-all drop-udp-class
match access-group 150
!--- Create a Policy-Map that will be applied to the !--- Control-Plane of the device.
!--- Apply the Policy-Map to the !--- Control-Plane of the device
service-policy input drop-udp-traffic
In the above CoPP example, the access control list entries (ACEs) that match the potential 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 (not shown) are not affected by the policy-map drop function. Please note that the policy-map syntax is different in the 12.2S and 12.0S Cisco IOS software trains:
police 32000 1500 1500 conform-action drop exceed-action drop
Additional information on the configuration and use of the CoPP feature can be found in the documents, "Control Plane Policing Implementation Best Practices" and "Control Plane Policing" at the following links: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html