If the affected Cisco device running Cisco IOS Software or Cisco IOS XE Software requires SIP for VoIP services, SIP cannot be disabled, and no workarounds are available. Users are advised to apply mitigation techniques to help limit exposure to the vulnerability. Mitigation consists of allowing only legitimate devices to connect to affected devices. To increase effectiveness, the mitigation must be coupled with antispoofing measures on the network edge. This action is required because SIP can use UDP as the transport protocol.
Additional mitigations that can be deployed on Cisco devices within the network are available in the Applied Mitigation Bulletin companion document Identifying and Mitigating Exploitation of the Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability
, which is available at the following link: http://tools.cisco.com/security/center/viewAMBAlert.x?alertId=35259
Disabling SIP Listening Ports
For devices that do not require SIP to be enabled, the simplest and most effective workaround is to disable SIP processing on the device. Some releases of Cisco IOS Software and Cisco IOS XE Software allow administrators to disable SIP with the following commands:
no transport udp
no transport tcp
no transport tcp tls
When applying this workaround to devices that are processing Media Gateway Control Protocol (MGCP) or H.323 calls, the device will not stop SIP processing while active calls are being processed. Under these circumstances, this workaround should be implemented during a maintenance window when active calls can be stopped briefly.
The show udp
and show tcp brief all
commands can be used to confirm that the SIP UDP and TCP ports are closed after applying this workaround.
Depending on the Cisco IOS Software release in use, when SIP is disabled the output from the show ip sockets
command may still show the SIP ports open, but sending traffic to them will cause the SIP process to display the following message:
*Nov 2 11:36:47.691: sip_udp_sock_process_read: SIP UDP Listener is DISABLED
Control Plane Policing
For devices that need to offer SIP services, it is possible to use Control Plane Policing (CoPP) to block SIP traffic to the device from untrusted sources. Cisco IOS Software and Cisco IOS XE Software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, 12.4T and newer support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to specific network configurations:
!– The 192.168.1.0/24 network and the 172.16.1.1 host are trusted.
!– Everything else is not trusted. The following access list is used
!– to determine which traffic needs to be dropped by a control plane
!– policy (the CoPP feature): if the access list matches (permit),
!– traffic will be dropped and if the access list does not
!– match (deny), traffic will be processed by the router.
access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060
access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060
access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061
access-list 100 deny udp host 172.16.1.1 any eq 5060
access-list 100 deny tcp host 172.16.1.1 any eq 5060
access-list 100 deny tcp host 172.16.1.1 any eq 5061
access-list 100 permit udp any any eq 5060
access-list 100 permit tcp any any eq 5060
access-list 100 permit tcp any any eq 5061
!– Create a class map for traffic to be policed by
!– the CoPP feature.
class-map match-all drop-sip-class
match access-group 100
!– 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
service-policy input control-plane-policy
Because SIP can use UDP as a transport protocol, it is possible to spoof the source address of an IP packet, which may bypass access control lists that permit communication to these ports from trusted IP addresses. Information about Unicast Reverse
Path Forwarding to help prevent spoofing is available at Understanding Unicast Reverse Path Forwarding
In the preceding CoPP example, the access control entries that match the potential exploit packets with the permit
action cause these packets to be 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 about the configuration and use of the CoPP feature is available at Control Plane Policing Implementation Best Practices
and the Control Plane Policing chapter
of the QoS Policing and Shaping Configuration Guide