The effectiveness of any workaround 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.
Affected devices that must run ITS, CME or SRST are vulnerable, and
there are not any specific configurations that can be used to protect them.
Applying access lists on interfaces that should not accept ITS, CME or SRST
traffic and putting firewalls in strategic locations may greatly reduce
exposure until an upgrade can be performed.
The IP Telephony Security in Depth SAFE paper at the URL below
discusses a variety of best practices that should keep your voice network
isolated from the Internet. These best practices may help to reduce the risk of
exposure, although attacks from within the local network should always be
considered a potential risk.
It is possible to restrict SCCP communications to the IP specified in
the ip source-address configuration command by using
information on this command can be found at the following URL:
Using Access Lists
Where possible, it is recommended to block SCCP traffic at the network
edge with an Infrastructure Access Control List (iACL) or a Transit Access
Control List (tACL).
For more information on iACLs, refer to "Protecting Your Core:
Infrastructure Protecton Access Control Lists":
For more information on tACLs, refer to 'Transit Access Control Lists:
Filtering at Your Edge":
Below is an example of an access list to block SCCP traffic from
anywhere but a permitted network.
Note: In SRST deployments the SCCP packets are not addressed directly to
the SRST device. The SCCP packets will be addressed to the call control devices
(typically Cisco CallManager).
In this example, the permitted telephony devices are on the
172.16.0.0/16 network and the SCCP port being used is the default, TCP port
2000. If the specific IP addresses of the telephony devices are known, then the
access list can be made to restrict traffic from only those devices.
!--- Permit access from any IP address in the 172.16.0.0/16
!--- to TCP port 2000.
access-list 101 permit tcp 172.16.0.0 0.0.255.255 any eq 2000
!--- Deny all traffic to port 2000.
access-list 101 deny tcp any any eq 2000
!--- Permit all other traffic.
access-list 101 permit ip any any
Using Control Plane Policing
The Control Plane Policing (CoPP) feature may be used to mitigate this
vulnerability. In the following example SCCP traffic is permitted to and from
the 192.168.10.0/24 subnet. All other TCP port 2000 traffic destined to the
device is blocked.
access-list 140 deny tcp 192.168.10.0 0.0.0.255 any eq 2000
access-list 140 deny tcp any 192.168.10.0 0.0.0.255 eq 2000
access-list 140 permit tcp any any eq 2000
access-list 140 deny ip any any
class-map match-all sccp-class
match access-group 140
police 8000 1500 1500 conform-action drop exceed-action drop
service-policy input control-plane-policy
CoPP is available in IOS release trains 12.2S and 12.3T. Additional
information on the configuration and use of the CoPP feature can be found at
the following URL: