Protecting Cisco Unified Communications Manager Express CME

As previously discussed in this chapter, the Cisco Unified CME is an entry-level VoIP solution that runs on Cisco IOS Software routers. It is designed for small businesses and autonomous small enterprise branch offices. CME enables you to provide voice, data, and IP telephony services on a single platform. Because it is an integrated solution within Cisco IOS Software routers, all the best practices of router security that you learned in Chapter 2 apply when securing the Cisco Unified CME solution. These best practices include the following:

• Configure enable secret passwords or encrypted passwords within the configuration.

• Configure administrator access privileges within Cisco IOS Software.

• Restrict access to VTY lines for remote administration access.

• Use RADIUS or TACACS+ servers for authentication and authorization of administrative sessions.

Configure RADIUS or TACACS+ accounting.

• Configure a fallback user account for administrative access when the external authentication server is not available.

• Configure Secure Shell (SSH) access instead of Telnet.

• Control the access of Simple Network Management Protocol (SNMP) sessions.

• Use all other best practices listed in Chapter 2 that protect the control plane and management plane.

In addition to the common infrastructure protection best practices, you should only allow IP phones in the trusted domain for registration. You can use the strict-match option in the ip source-address command if your local segment is a trusted domain. This allows only locally attached IP phones to register, as demonstrated in the following example:

CME(config-telephony)#ip source-address 192.168.10.1 port 2000

Another good practice is to block port 2000 (from external untrusted networks) to prevent unauthorized Skinny Call Control Protocol (SCCP) phones from registering to your Cisco Unified CME. You can use an ACL as demonstrated in the following example:

access-list 100 deny tcp any any eq 2000

Always use Secure Socket Layer (SSL) and HTTPS to access the web-based admin console, as shown in the following:

ip http server ip http secure-server

TIP You can also use ip http authentication to perform external RADIUS or TACACS+ server for HTTPS authentication.

Configure Class of Restrictions (COR) is used to prevent toll fraud. Typically, it is recommended that you configure different classes of service to control the destinations that users can call. For example, you can configure different levels of permissions that allow specific users to dial only local numbers and 911 for any emergencies. In the following example, two different types of users are configured (users and superusers). Superusers are allowed to dial any numbers, and regular users have access to all resources with the exception of toll (1-900 numbers), directory assistance (411), and international calling. This is achieved with the configuration shown in Example 9-4.

Example 9-4 Protecting Against Toll Fraud Using COR

dial-peer cor custom name 911 name 1800 name local-call name ld-call name 411 name int-call name 1900

!different dial-peer names are assigned for the different services; additionally, different COR

!lists for each service are configured below. !

dial-peer cor list call911

dial-peer cor list call1800

dial-peer cor list calllocal member local-call !

dial-peer cor list callint member int-call

Example 9-4 Protecting Against Toll Fraud Using COR (Continued) !

dial-peer cor list callld member ld-call

dial-peer cor list call411

member 411

dial-peer cor list call1900

member 1900

dial-peer cor list user member 911 member 1800 member local-call member ld-call

!the previous COR list allows regular users (user) to access/use 911, 1800, local calls, and !caller ID services

dial-peer cor list superuser member 911

member 1800

member local-call member ld-call member 411

member int-call member 1900

dial-peer voice 9 pots corlist outgoing callld destination-pattern 91

port 1/0 prefix 1

!the previous COR list allows superusers to access/use all available services !

dial-peer voice 911 pots corlist outgoing call911 destination-pattern 9911 port 1/0

dial-peer voice 11 pots corlist outgoing callint destination-pattern 9011T port 2/0

dial-peer voice 732 pots corlist outgoing calllocal destination-pattern 9732

port 1/0

continues

Example 9-4 Protecting Against Toll Fraud Using COR (Continued)

dial-peer voice 800 pots corlist outgoing call1800

destination-pattern 91800

port 1/0 prefix 1800 !

dial-peer voice 802 pots corlist outgoing call1800

destination-pattern 91877

port 1/0

dial-peer voice 805 pots corlist outgoing call1800

destination-pattern 91888

port 1/0

dial-peer voice 411 pots corlist outgoing call411 destination-pattern 9411 port 1/0

dial-peer voice 806 pots corlist outgoing call1800

destination-pattern 91866

port 1/0 prefix 1866 ephone-dn 1 number 2000 cor incoming user Ephone-dn 2 number 2001

cor incoming superuser

You can configure the Cisco IOS Software Firewall on the same router that runs Cisco Unified CME. On the other hand, you must pay attention to certain requirements needed for Cisco Unified CME to work in your environment. For example, SCCP support is needed for locally generated Skinny traffic. SCCP is a Cisco proprietary lite-version of H.323 for call signaling, control, and media communication. H.323 uses Q.931, H.225, and H.245 for call setup, management, and control. H.323 requires a TCP connection for H.245 signaling that does not have a well-known port associated with it. The H.245 port is dynamically negotiated. NAT and stateful firewalls can break H.323.

NOTE Cisco IOS Software supports unidirectional firewall policy configurations between groups of interfaces which have been known as zones since Version 12.4(6)T. Previously, all inspect rules had to be applied to specific interfaces on routers running the Cisco IOS Firewall feature set. All inbound and outbound traffic was inspected based on the direction to which the inspect rule was applied.

Since Version 12.4(11)T, Cisco IOS Software Firewalls have supported H.225 Registration, Admission, and Status (RAS) signaling. H.323 uses the H.225 standard for call setup.

Continue reading here: Protecting Cisco Unity Express

Was this article helpful?

0 0