Cisco: CUCM DoS Vulnerabilities

Cisco Unified Communications Manager (formerly Cisco CallManager) contains multiple denial of service (DoS) vulnerabilities that if exploited could cause an interruption of voice services. The Session Initiation Protocol (SIP), Skinny Client Control Protocol (SCCP) and Computer Telephony Integration (CTI) Manager services are affected by these vulnerabilities.

To address these vulnerabilities, Cisco has released free software updates for select Cisco Unified Communications Manager versions. There is a workaround for of one the vulnerabilities.

The following products are affected by vulnerabilities that are described in this advisory:

* Cisco Unified Communications Manager 4.x
* Cisco Unified Communications Manager 5.x
* Cisco Unified Communications Manager 6.x
* Cisco Unified Communications Manager 7.x

Administrators can mitigate the SCCP- and SIP-related vulnerabilities by implementing filtering on screening devices to permit access to TCP ports 2000 and 2443, and TCP and UDP ports 5060 and 5061 only from networks that require SCCP and SIP access to Cisco Unified Communications Manager appliances.

It is possible to mitigate the CTI Manager vulnerability by disabling the CTI Manager service t is not necessary; however, this workaround will interrupt applications that reply on the CTI Manager service. Administrators can also mitigate the vulnerability by implementing filtering on screening devices to permit access to TCP port 2748 only from networks that require access to the CTI Manager service.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100303-cucm.shtml

Multiple Vulnerabilities in Cisco ASA 5500 Series

Cisco ASA 5500 Series Adaptive Security Appliances are affected by the following vulnerabilities:

* TCP Connection Exhaustion Denial of Service Vulnerability
* Session Initiation Protocol (SIP) Inspection Denial of Service Vulnerabilities
* Skinny Client Control Protocol (SCCP) Inspection Denial of Service Vulnerability
* WebVPN Datagram Transport Layer Security (DTLS) Denial of Service Vulnerability
* Crafted TCP Segment Denial of Service Vulnerability
* Crafted Internet Key Exchange (IKE) Message Denial of Service Vulnerability
* NT LAN Manager version 1 (NTLMv1) Authentication Bypass Vulnerability

These vulnerabilities are not interdependent; a release that is affected by one vulnerability is not necessarily affected by the others.

There are workarounds for some of the vulnerabilities disclosed in this advisory.

Cisco has released free software updates that address these vulnerabilities.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100217-asa.shtml

Cisco FWSM SCCP Inspection DoS Vulnerability

A vulnerability exists in the Cisco Firewall Services Module (FWSM) for the Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers that may cause the Cisco FWSM to reload after processing a malformed Skinny Client Control Protocol (SCCP) message. The vulnerability exists when SCCP inspection is enabled.

Cisco has released free software updates that address this vulnerability.

All non-fixed 4.x versions of Cisco FWSM Software are affected by this vulnerability if SCCP inspection is enabled. SCCP inspection is enabled by default.

To check if SCCP inspection is enabled, issue the show service-policy | include skinny command and confirm that the command returns output. Example output follows:

fwsm#show service-policy | include skinny
Inspect: skinny , packet 0, drop 0, reset-drop 0

If SCCP inspection is not required, this vulnerability can be mitigated by disabling it. Administrators can disable SCCP inspection by issuing the no inspect skinny command in class configuration sub-mode within the policy map configuration. If SCCP inspection is required, there are no workarounds.

Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100217-fwsm.shtml

Cisco: Frame-Relay back-to-back routers in simple steps

In one of my earlier posts I have presented how to connect 3 routers in a Hub and Spoke Frame-Relay topology. Now I want to show you how to connect 2 routers back to back, in a Frame Relay topology. With a back to back connection and without any FR switch, things are a little bit different than in the Hub and Spooke topology.

First let’s have a look to the topology:


We have 2 routers, connected back to back. The interface status on both routers:

sh run int s0/0
!
interface Serial0/0
no ip address
shutdown

First let set up the encapsulation to Frame-Relay and to bring the interfaces UP:

conf t
interface S0/0
encapsulation frame-relay
no shutdown

Everything should be fine now, but it’s not, as if you check your interfaces you will see that they are in a Up/Down status on both routers:

sh int s0/0
Serial0/0 is up, line protocol is down

Even this is messing up a little bit with our brains, the Up/Down status is normal in this phase. Why? Remember that we do not have a FR switch, both interface consider themselved DTE side and LMI is not working. You can check if LMI like this:

R1#sh frame-relay lmi

LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0             Invalid Prot Disc 0
Invalid dummy Call Ref 0              Invalid Msg Type 0
Invalid Status Message 0              Invalid Lock Shift 0
Invalid Information ID 0              Invalid Report IE Len 0
Invalid Report Request 0              Invalid Keep IE Len 0
Num Status Enq. Sent 6                Num Status msgs Rcvd 0
Num Update Status Rcvd 0              Num Status Timeouts 5
Last Full Status Req 00:00:04         Last Full Status Rcvd never

You will see Sent packages on both routers, but nothing received as there is no FR switch. In this conditions we have to disable LMI and to assign DLCIs manually. To disable LMI, issue the following command under Frame-Relay interface:

interface S0/0
no keepalive

Now interfaces should be in a Up/Up status:

sh int s0/0
Serial0/0 is up, line protocol is up

As in this moment everything looks fine, let’s start to configure the Frame-Relay back to back connections. Obvious, at least for me, when you have a back to back connection, first things that comes into your mind is a point-to-point interface. Let’s start with this configuration (we will use from diagram the black line connection with subnet 100.100.100.0 /24) . I will show only the configuration on the primary router, but it’s the same on the secondary one, just with a different IP address in the 4th octet.

interface S0/0.100 point-to-point
ip address 100.100.100.1 255.255.255.0
frame-relay interface-dlci 100

Remember DLCIs are only local significant so you can define whatever number you want there, but of course the same DLCI number on both sides. Let’s check if everything is fine:

R1#show frame-relay map
Serial0/0.100 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast

R1#show frame-relay pvc | i STATUS
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/0.100

We can see a point-to-point dlci in frame-relay map, and a static defined PVC. If you ping from R1 to R2 and viceversa it should work.

This was the straight forward solution, but going a little bit more into details, you can be required in some situations that you have to use a multipoint Frame-Relay interface. Actually what is a multipoint interface more than multiple point-to-point interfaces. Let’s take the sencond line (red one, with subnet 110.110.110.0 /24 in the topology) and configure this back to back connection using multipoint interfaces:

interface s0/0.110 multipoint
ip address 110.110.110.1 255.255.255.0
frame-relay map ip 110.110.110.2 110 broadcast
frame-relay map ip 110.110.110.1 110

As you see the configuration is different from the point-to-point interface. Actually under multipoint interface you can issue the frame-relay interface-dlci 110 command, but this will not help too much. Remember that we have disable LMI in the first steps because we do not have a FR switch. No FR switch means no automatic L3 to L2 mapping. In other words even if you specify the interface-dlci, the interface being a multipoint will not know where to forward packets. Why this didn’t happen in the point-to-point scenario, you may ask. Well, because there the keyword is interface sx/x point-to-point, so by it’s nature the interface knows that there is only one destination possible, meaning the other end (or point if you want).

In this scenario we had to manually map L3 to L2 with the command frame-relay map. Actually you only need the first frame-relay map, pointing to the other router IP address, but I add the last command just in case you want to ping your own interface.

Now maybe you ask which is the third scenario (blue line). Well, this is not very common in the real environment, but maybe you have to deal with it in a special condition like lab environment, Cisco exam and so on. Let’s say that you have a request that you need to have 3 virtual PVC connections, but only 2 subinterface. Now, you already have 2 subinterface configured, so how can you achieve the third PVC connection. The answer is that you configure the main interface with the same configuration like in multipoint subinterface scenario. By it’s nature and interface is described point to multipoint, so in a Frame Relay scenario like this you have to manually map L3 to L2:

interface Serial0/0
ip address 120.120.120.1 255.255.255.0
encapsulation frame-relay
no keepalive
frame-relay map ip 120.120.120.1 120
frame-relay map ip 120.120.120.2 120 broadcast

If you followed this tutorial, at the end you should have reachability over the 3 subnets.

New CCIE R&S Lab Opportunities: New Location Available

To increase testing opportunities and add convenience for certification candidates, Cisco® will be offering the CCIE® Routing and Switching lab exam in additional locations in April 2010, as listed below. A new location in Johannesberg/Midrand, South Africa has been added. The exams will be administered at Pearson Professional Centers which are designed for secure, high-stakes professional exams and have been used by medical, legal and other examination boards for over eight years. Cisco already uses Pearson Professional Centers to administer the practical exam for CCDE® (Cisco Certified Design Expert). More information on the centers is available at www.pearsonvue.com/cisco/ccie.