If the affected Cisco IOS device 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 anti-spoofing 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 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:
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 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 connections
, show tcp brief all
, and show control-plane host open-ports
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 Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T 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 what traffic needs to be dropped by a control plane
!– policy (the CoPP feature): if the access list matches (permit)
!– then traffic will be dropped and if the access list does not
!– match (deny) then 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
!– 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-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. Additional information about Unicast Reverse Path Forwarding is at http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html
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 (not shown) are not affected by the policy map drop
function. Additional information about the configuration and use of the CoPP feature is at http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html