56026849 07 05 Cisco Call Manager Express c10 Practicas Seguras

Prácticas recomendadas de seguridad de Cisco Unified CallManager Express

Cisco Unified CallManager Express (Cisco Unified CME) ofrece comunicaciones IP integradas en los routers Cisco IOS. Por lo tanto, también se aplican a Cisco Unified CME las mismas prácticas recomendadas de seguridad de todos los routers Cisco IOS con habilitación de voz. Además, se deben implementar las prácticas recomendadas de Cisco Unified CME específicas del sistema para proporcionar una protección de seguridad adicional.

Este capítulo describe cómo se puede configurar Cisco Unified CME mediante el CLI para evitar que los usuarios obtengan, intencional o accidentalmente, el control a nivel del sistema desde la GUI o el acceso local o remoto a la CLI. Las secciones específicas que se presentan en este capítulo describen las siguientes consideraciones de seguridad de Cisco Unified CME:

• Seguridad del acceso GUI, página 10-1

• Uso de HTTPS para la administración GUI de Cisco Unified CME, página 10-2

• Configuración de seguridad de acceso básico a Cisco Unified CME, página 10-3

• Seguridad de Cisco Unified CME para telefonía IP, página 10-8

• Cisco Unified CME con NAT y Firewall, página 10-13

• Seguridad de la señalización SCCP mediante TLS, página 10-19

• Puertos de uso común de Cisco Unified CME, página 10-23

Nota Para obtener información adicional, consulte la sección “Documentos relacionados y referencias” en la página xii.

Seguridad del acceso GUI Un router Cisco IOS autentica el inicio de sesión CLI de un administrador únicamente con respecto a la contraseña, y la configuración predeterminada para el acceso HTTP es ip http authentication enable. Si el administrador del sistema, el administrador del cliente o el usuario del teléfono tienen la misma contraseña que la contraseña de habilitación del router, obtendrán acceso con el nivel de privilegios 15 EXEC al software Cisco IOS a través de HTTP. Un usuario normal de teléfono IP podría entonces cambiar de forma accidental la configuración de Cisco Unified CME, borrar Flash o recargar el router si inicia una sesión en esta dirección URL:

http://cme-ip-address/

Se deben configurar los siguientes comandos para que Cisco Unified CME utilice AAA o la autenticación local, a fin de evitar que un usuario normal obtenga acceso a la contraseña de habilitación y, de ese modo, acceda a la página del administrador del sistema:

Capítulo 10

Capítulo 10 Prácticas recomendadas de seguridad de Cisco Unified Call manager Express

Guía de diseño de red – Referencia de solución Cisco Unified CallManager Express OL-10621-01 10-2

ip http authentication aaa

o

ip http authentication local

Autenticación de la cuenta del administrador del sistema mediante AAA

Cisco Unified CME permite que el nombre de usuario/la contraseña del administrador del sistema se autentique mediante AAA. Use la siguiente configuración para utilizar AAA para el inicio de sesión de usuario del administrador del sistema: ip http authentication aaa new-model aaa authentication login default group tacacs+ local tacacs-server host 10.1.2.3

Note El nombre de usuario / la contraseña normal no se autentica mediante AAA.

Uso de HTTPS para la administración GUI de Cisco Unified CME HTTP a través de SSL (HTTPS) ofrece compatibilidad con Secure Socket Layer (SSL) versión 3.0 para el servidor HTTP 1.1 y el cliente HTTP 1.1 en el software Cisco IOS. SSL proporciona autenticación de servidor, cifrado e integridad de mensajes para obtener comunicaciones HTTP seguras. SSL también ofrece autenticación de cliente HTTP. Esta característica sólo se admite en las imágenes del software Cisco IOS que incluyen la función SSL. En concreto, SSL se admite en las imágenes Advanced Security, Advanced IP Services y Advanced Enterprise Services. Use las imágenes de Cisco IOS Advanced IP Services o Advanced Enterprise Services para disponer de las características Cisco Unified CME y SSL.

Los teléfonos IP no sirven como clientes HTTPS. Si se habilita HTTPS en el router Cisco Unified CME, los teléfonos IP seguirán intentando conectarse a HTTP a través del puerto 80. Debido a que el puerto predeterminado SSL es 443, los teléfonos no pueden mostrar el directorio local ni la marcación rápida del sistema. Los teléfonos IP que usan HTTP pueden funcionar con un sistema configurado para SSL habilitando tanto HTTP como HTTPS, como se muestra en el siguiente ejemplo. ip http server ip http secure-server ip http secure-port port_number !if https port is changed from default 443 ip http authentication AAA | TACACS | local

Use el siguiente comando para generar una pareja de claves de uso RSA con una longitud de 1024 bits o superior:

crypto key generate rsa usage 1024

Si no se genera una pareja de claves de uso RSA, se generará automáticamente una pareja de claves de uso RSA de 768 bits cuando se conecte por primera vez al servidor HTTPS. Estas claves RSA de generación automática no se guardan en la configuración de inicio; por lo tanto, se perderán cuando se reinicie el dispositivo, a menos que se guarde manualmente la configuración.

Debe obtener un certificado digital X.509 con capacidades de firma digital para el dispositivo de una autoridad de certificación (CA). Si no obtiene previamente un certificado digital, el dispositivo crea un certificado digital autofirmado para autenticarse a sí mismo.

Si se cambia el nombre de host del dispositivo después de obtener un certificado digital de dispositivo, se obtendrá un error en las conexiones HTTPS al dispositivo ya que el nombre de host no coincidirá con el nombre especificado en el certificado digital. Para resolver este problema, obtenga un nuevo certificado de dispositivo utilizando un nuevo nombre de host.



El comando ip http secure-server impide que las contraseñas no cifradas viajen a través de la red cuando un administrador de Cisco Unified CME inicia una sesión en la GUI de Cisco Unified CME. Sin embargo, las comunicaciones entre el teléfono y el router permanecen sin cifrar.

Los siguientes puntos son prácticas recomendadas para el uso del acceso interactivo HTTP al router Cisco Unified CME:

• Use el comando ip http access-class para permitir que sólo determinadas direcciones IP puedan obtener acceso a la GUI de Cisco Unified CME, de esta forma se restringirá la conexión de paquetes IP no deseados a Cisco Unified CME.

• Use el comando ip http authentication con un servidor central TACACS+ o RADIUS a efectos de autenticación. La configuración de autenticación para los servidores HTTP y HTTPS agrega seguridad a la comunicación entre los clientes y los servidores HTTP y HTTPS en el dispositivo.

• No use la contraseña de habilitación en el router como una contraseña de inicio de sesión a Cisco Unified CME (a fin de evitar que un usuario normal pueda obtener privilegios de administrador).

Configuración de seguridad de acceso básico a Cisco Unified CME

Esta sección resume las medidas disponibles para asegurarse de que sólo usuarios y sistemas autorizados puedan tener acceso a los recursos basados en el sistema de Cisco Unified CME. En esta sección se describen los siguientes temas:

• Configuración del acceso local y remoto al sistema, página 10-3

• Restricción del acceso tty, página 10-5

• Configuración del acceso SSH, página 10-5

• Uso de las ACL para el acceso SNMP, página 10-5

• Deshabilitación del protocolo CDP (Cisco Discovery Protocol), página 10-6

• Configuración de COR para llamadas entrantes y salientes, página 10-6

• Restricción de patrones de llamadas salientes, página 10-8

Configuración del acceso local y remoto al sistema En el modo de privilegios EXEC, los comandos configure terminal y telephony-service llevan a un usuario al modo de configuración de Cisco Unified CME. Los comandos show running-config y show telephony-service muestran todos los teléfonos y usuarios registrados, números de extensiones y contraseñas para el acceso GUI de Cisco Unified CME. Un paso inicial para el control de la seguridad se encuentra en el nivel de acceso al sistema. El cifrado de contraseña, la autenticación de usuario y la auditoría de comandos son todos factores cruciales para evitar las brechas de seguridad.

Habilitación de contraseñas cifradas y secretas

La contraseña de habilitación se presenta sin cifrado para proporcionar control de acceso al modo de privilegios EXEC del router. Use Enable Secret para cifrar la contraseña de habilitación.

El siguiente ejemplo ilustra esta configuración: enable secret secretword1 no enable password

El comando enable secret tiene precedencia sobre el comando enable password si ambos están configurados; no se pueden utilizar de forma simultánea.



Para incrementar la seguridad del acceso, las contraseñas se deben cifrar para evitar que usuarios no autorizados puedan ver las contraseñas cuando los paquetes se examinan mediante analizadores de protocolos:

El siguiente ejemplo ilustra esta configuración: Service password-encryption

Creación de varios niveles de privilegio

De forma predeterminada, el software Cisco IOS tiene dos niveles de acceso a los comandos: el modo de usuario EXEC (nivel 1) y el modo de privilegios EXEC (nivel 15). Pueden configurarse hasta 16 niveles de privilegios (de 0, el nivel más restrictivo, al 15, el nivel menos restrictivo) para proteger el sistema de los acceso no autorizados. Use el comando privilege mode level.

El siguiente ejemplo ilustra esta configuración: privilege exec level 14 enable secret level 2 secretword2

Restricción del acceso VTY

Permita que sólo algunos usuarios/ubicaciones puedan hacer Telnet al router mediante la definición y aplicación de una lista de acceso para permitir o denegar las sesiones Telnet remotas.

El siguiente ejemplo ilustra esta configuración: line vty 0 4 access-class 10 in access-list 10 permit 10.1.1.0 0.0.0.255

Uso de AAA para el acceso seguro

Se puede usar un servidor de autenticación para validar el acceso de usuarios al sistema. Los siguientes comandos permiten que un servidor AAA o un servidor TACACS+ se puedan usar para servicios de autenticación.

El siguiente ejemplo ilustra esta configuración: aaa new-model aaa authentication login default tacacs+ enable aaa authentication enable default tacacs+ enable ip tacacs source-interface Loopback0 tacacs-server host 10.17.1.2 tacacs-server host 10.17.34.10 tacacs-server key xyz ! Defines the shared encryption key to be xyz

Configuración de contabilidad y auditoría en AAA

Los siguientes comandos usan un servidor TACACS+ a efectos de contabilidad y auditoría. aaa new-model aaa authentication login default tacacs+ enable

(el inicio de sesión usa TACACS+; si no está disponible, use la contraseña de habilitación) aaa authentication enable default tacacs+ enable aaa accounting command 1 start-stop tacacs+

(ejecute la contabilidad para los comandos en el nivel 1 de privilegios especificado) aaa accounting exec start-stop tacacs+ ip tacacs source-interface Loopback0 tacacs-server host 10.17.1.2



tacacs-server host 10.17.34.10 tacacs-server key xyz (defines the shared encryption key to be xyz)

El siguiente registro de comando muestra la información que incluye un registro de contabilidad de comando TACACS+ para los privilegios de nivel 1. Wed Jun 25 03:46:47 1997 192.168.25.15 fgeorge tty3 5622329430/4327528 stop task_id=3 service=shell priv-lvl=1 cmd=show version <cr> Wed Jun 25 03:46:58 1997 192.168.25.15 fgeorge tty3 5622329430/4327528 stop task_id=4 service=shell priv-lvl=1 cmd=show interfaces Ethernet 0 <cr> Wed Jun 25 03:47:03 1997 192.168.25.15 fgeorge tty3 5622329430/4327528 stop task_id=5 service=shell priv-lvl=1 cmd=show ip route <cr>

Configuración de autenticación de usuario local cuando AAA no está disponible

Siempre debe requerirse la autenticación basada en inicio de sesión de los usuarios, incluso cuando el servidor externo AAA no está accesible.

El siguiente ejemplo ilustra esta configuración: username joe password 7 045802150C2E username jim password 7 0317B21895FE ! line vty 0 4 login local

Restricción del acceso tty Puede permitir el acceso Telnet al router sólo a algunos usuarios y ubicaciones mediante el uso de las líneas de terminal (tty) o de terminal virtual (vty). Defina y aplique una lista de acceso para permitir o denegar sesiones Telnet remotas al router Cisco Unified CME, tal como se muestra en el siguiente ejemplo. line vty 0 4 access-class 10 in access-list 10 permit 10.1.1.0 0.0.0.255

Configuración del acceso SSH Use el siguiente comando para generar una pareja de claves RSA para el router:

crypto key generate rsa

De forma predeterminada, el transporte vty es Telnet. El siguiente comando deshabilita Telnet y sólo admite SSH para las líneas vty. line vty 0 4 transport input ssh

Uso de las ACL para el acceso SNMP Se puede configurar la cadena de acceso de asociación para permitir el acceso a SNMP (Simple Network Management Protocol). El siguiente ejemplo asigna la cadena changeme-rw a SNMP, permitiendo el acceso de lectura- escritura y especifica que la lista de acceso IP 10 pueda utilizar la cadena de asociación: access-list 10 remark SNMP filter access-list 10 permit 10.1.1.0 0.0.0.255 snmp-server community changeme-rw RW 10 snmp-server community changeme-ro RO 10



Debido a que lectura y escritura son dos cadenas de asociación comunes para el acceso de lectura y escritura respectivamente, cambie las cadenas de asociación a otras diferentes.

Deshabilitación del protocolo CDP (Cisco Discovery Protocol) Debido a que el protocolo CDP (Cisco Discovery Protocol) descubre de forma automática los dispositivos de red adyacentes que admiten CDP, deshabilite CDP en un dominio no fiable, de forma que los routers Cisco Unified CME no aparezcan en la tabla CDP de otros dispositivos. Deshabilite CDP con el siguiente comando:

no cdp run

Si se necesita CDP, considere la deshabilitación de CDP por cada interfaz, como se muestra en el ejemplo siguiente: Interface FastEthernet0/0 no cdp enable

Configuración de COR para llamadas entrantes y salientes Uno de los métodos para restringir las llamadas entrantes y salientes no autorizadas es usar los comandos COR (Class o Restriction) La configuración que aparece en el siguiente ejemplo define dos grupos de usuarios: user y superuser. Superuser puede hacer cualquier tipo de llamada, incluyendo locales, de larga distancia, consultas al directorio telefónico y llamadas a números de emergencia. User no puede hacer llamadas a números 900, de directorios telefónicos e internacionales. dial-peer cor custom name 911 name 1800 name local-call name ld-call name 411 name int-call name 1900 ! dial-peer cor list call911 member 911 ! dial-peer cor list call1800 member 1800 ! dial-peer cor list calllocal member local-call ! dial-peer cor list callint member int-call ! 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 !



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 ! dial-peer voice 911 pots corlist outgoing call911 destination-pattern 9911 port 1/0 prefix 911 ! dial-peer voice 11 pots corlist outgoing callint destination-pattern 9011T port 2/0 prefix 011 ! dial-peer voice 732 pots corlist outgoing calllocal destination-pattern 9732....... port 1/0 prefix 732 ! 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 prefix 1877 ! dial-peer voice 805 pots corlist outgoing call1800 destination-pattern 91888....... port 1/0 prefix 1888 ! dial-peer voice 411 pots corlist outgoing call411 destination-pattern 9411 port 1/0 prefix 411 ! 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-dv 2 number 2001 cor incoming superuser

Restricción de patrones de llamadas salientes Es posible usar el comando after-hours block para restringir las llamadas entrantes y salientes después de determinadas horas. También se puede usar el bloqueo para horario extendido a fin de restringir las llamadas a números o códigos de área que se corresponden con patrones de llamadas fraudulentas. Los comandos que se muestran en el siguiente ejemplo bloquean todas las llamadas en todos los horarios para los patrones 2 a 66. El patrón 7 sólo se bloquea durante el periodo de horario extendido configurado. telephony-service after-hours block pattern 2 .1264 7-24 after-hours block pattern 3 .1268 7-24 after-hours block pattern 4 .1246 7-24 after-hours block pattern 5 .1441 7-24 after-hours block pattern 6 .1284 7-24 after-hours block pattern 7 9011 after-hours day Sun 19:00 07:00 after-hours day Mon 19:00 07:00 after-hours day Tue 19:00 07:00 after-hours day Wed 19:00 07:00 after-hours day Thu 19:00 07:00 after-hours day Fri 19:00 07:00 after-hours day Sat 19:00 07:00

Seguridad de Cisco Unified CME para telefonía IP

En esta sección se describen los siguientes temas:

• Control de registro de teléfono IP, página 10-8

• Supervisión de registro de teléfono IP, página 10-9

• Supervisión de actividad de llamadas y registro de historial de llamadas, página 10-10

• COR para llamadas entrantes y salientes para evitar el fraude telefónico, página 10-10

• Bloqueo en horario extendido para restringir los patrones de llamadas salientes-fraude telefónico, página 10-12

Control de registro de teléfono IP Configure Cisco Unified CME para permitir el registro de los teléfonos IP del dominio de confianza. Suponiendo que el segmento local sea un dominio de confianza, use la opción strict-match del comando ip source-address, de forma que sólo los teléfonos IP conectados podrán registrarse en el router Cisco Unified CME y obtener servicios telefónicos. CME-3.0(config-telephony)# ip source-address 10.1.1.1 port 2000 strict-match



Puede agrupar un conjunto de teléfonos IP en una VLAN (como, por ejemplo, 10.1.1.0/24), de forma que sólo los teléfonos IP de la VLAN especificada puedan registrarse para Cisco Unified CME.

Bloquee el acceso al puerto 2000 del lado de la WAN a fin de evitar que teléfonos SCCP externos puedan registrarse con Cisco Unified CME. Use el comando access-list para bloquear el acceso al puerto 2000 desde las interfaces WAN. El siguiente ejemplo ilustra esta configuración: access-list 101 deny tcp any any eq 2000

También puede evitar que teléfonos IP desconocidos o no configurados se registren mediante la deshabilitación del registro automático utilizando el siguiente comando: CME-4.0(config-telephony)# no auto-reg-ephone

Nota La deshabilitación del registro automático también desactiva el aprovisionamiento de la GUI de ephone y el repliegue SRST de Cisco Unified CME. Con Cisco Unified CME 3.x y versiones anteriores, se deben aprovisionar los ephones antes de configurar la dirección IP de origen a fin de omitir provisionalmente el comportamiento de registro automático.

Antes de Cisco Unified CME 4.0, los teléfonos desconocidos o los teléfonos que no se habían configurado en Cisco Unified CME podían registrarse con Cisco Unified CME de forma predeterminada para facilitar la administración, pero estos teléfonos no proporcionan un tono de marcado hasta que los configure mediante la asociación de los botones con los ephone-dns o con la configuración auto assign (del modo de configuración telephony-service).

Los siguientes comandos ilustran la configuración ephone-dns con el comando ephone-dn. ephone-dn 1 number 1001 ephone-dn 2 number 1002 ephone 1 mac-address 1111.2222.3333 button 1:1 2:2

Los siguientes comandos ilustran la configuración del comando auto assign: CMEtest4-3745(config)# telephony-service CMEtest4-3745(config-telephony)# auto assign 1 to 500

Con Cisco Unified CME 4.0, se puede configurar no auto-reg-ephone en el modo de configuración telephony-service, de forma que los teléfonos IP que nos están explícitamente configurados con las direcciones MAC en el modo de configuración ephone no pueden registrarse de forma automática con el sistema Cisco Unified CME.

Supervisión del registro del teléfono IP Cisco Unified CME 3.0 ha agregado los siguientes mensajes syslog para generar y mostrar todos los eventos de registro/cancelación de registro: %IPPHONE-6-REG_ALARM %IPPHONE-6-REGISTER %IPPHONE-6-REGISTER_NEW %IPPHONE-6-UNREGISTER_ABNORMAL %IPPHONE-6-REGISTER_NORMAL

El siguiente mensaje indica que un teléfono se ha registrado y que no es parte de la configuración explícita del router (la configuración ephone no se ha creado o la dirección MAC no ha sido asignada):



%IPPHONE-6-REGISTER_NEW: ephone-3:SEP003094C38724 IP:10.4.170.6 Socket:1 DeviceType:Phone has registered.

Nota Con Cisco Unified CME 4.0 y versiones posteriores, si ha configurado el comando no auto-reg-

ephone, no se genera el mensaje precedente.

Cisco Unified CME permite que los teléfonos no configurados se registren a fin de hacer el aprovisionamiento más conveniente del sistema Cisco Unified CME. De forma predeterminada, los teléfonos designados como “nuevos” no tienen asignadas líneas telefónicas y no pueden realizar llamadas.

Puede usar la siguiente configuración para habilitar syslogging para el búfer/la consola de un router o un servidor syslog: logging console | buffered logging 192.168.153.129 ! 192.168.153.129 is the syslog server

Supervisión de actividad de llamadas y registro de historial de llamadas

La GUI de Cisco Unified CME ofrece una tabla de información del historial de llamadas, de forma que un administrador de red pueda supervisar la información del historial de llamadas de personas desconocidas y usar esta información para desestimar las actividades de llamadas basándose en determinados patrones. El registro del historial de llamadas se debe configurar para que se lleve a cabo el análisis y la contabilidad detallados, y para permitir al administrador hacer un seguimiento de los patrones de llamadas fraudulentas. Configure los siguientes comandos para el registro de actividad y el historial de llamadas: dial-control-mib retain-timer 10080 dial-control-mib max-size 500 ! gw-accounting syslog

COR para llamadas entrantes/salientes para prevenir el fraude telefónico

El siguiente ejemplo de configuración ilustra COR. Hay dos clases de servicio en la configuración: user y superuser junto con varios permisos admitidos como llamadas locales, llamadas de larga distancia, acceso al número de emergencia y acceso a directorios telefónicos. En este ejemplo, superuser tiene acceso a todo y user tiene acceso a todos los recursos con la excepción de las llamadas a los números 1900, directorios telefónicos y llamadas internacionales. dial-peer cor custom name 911 name 1800 name local-call name ld-call name 411 name int-call name 1900 dial-peer cor list call911 member 911 ! dial-peer cor list call1800 member 1800



! dial-peer cor list calllocal member local-call ! dial-peer cor list callint member int-call ! 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 ! 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 ! dial-peer voice 911 pots corlist outgoing call911 destination-pattern 9911 port 1/0 prefix 911 ! dial-peer voice 11 pots corlist outgoing callint destination-pattern 9011T port 2/0 prefix 011 ! dial-peer voice 732 pots corlist outgoing calllocal destination-pattern 9732....... port 1/0 prefix 732 ! 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 prefix 1877 ! dial-peer voice 805 pots corlist outgoing call1800 destination-pattern 91888....... port 1/0 prefix 1888 ! dial-peer voice 411 pots corlist outgoing call411 destination-pattern 9411 port 1/0 prefix 411 ! 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

Bloqueo en horario extendido para restringir los patrones de llamadas salientes-fraude telefónico

El bloqueo en horario extendido se puede agregar para la restricción de llamadas salientes después de determinadas horas. También se puede usar el bloqueo para horario extendido para restringir las llamadas a números o códigos de área que se corresponden con patrones de llamadas fraudulentas. El siguiente ejemplo de configuración se puede usar para restringir llamadas a determinados códigos de área: telephony-service after-hours block pattern 1 .1242 after-hours block pattern 2 .1264 after-hours block pattern 3 .1268 after-hours block pattern 4 .1246 after-hours block pattern 5 .1441 after-hours block pattern 6 .1284 after-hours block pattern 7 .1345 after-hours block pattern 8 .1767 after-hours block pattern 9 .1809 after-hours block pattern 10 .1473 after-hours block pattern 11 .1876 after-hours block pattern 12 .1664 after-hours block pattern 13 .1787 after-hours block pattern 14 .1869 after-hours block pattern 15 .1758 after-hours block pattern 16 .1900 after-hours block pattern 17 .1976 after-hours block pattern 18 .1868 after-hours block pattern 19 .1649



after-hours block pattern 20 .1340 after-hours block pattern 21 .1784 after-hours block pattern 22 .1684 after-hours block pattern 23 .1590 after-hours block pattern 24 .1456 after-hours day Sun 00:00 23:59 after-hours day Mon 00:00 23:59 after-hours day Tue 00:00 23:59 after-hours day Wed 00:00 23:59 after-hours day Thu 00:00 23:59 after-hours day Fri 00:00 23:59 after-hours day Sat 00:00 23:59

Cisco Unified CME con NAT y Firewall En esta sección se describen los siguientes temas:

• Cisco Unified CME con NAT, página 10-13

• Teléfonos remotos con direcciones IP públicas, página 10-14

• Teléfonos remotos con direcciones IP privadas, página 10-14

• Teléfonos remotos a través de VPN, página 10-15

• Consideraciones sobre la implementación Cisco Unified CME con Cisco IOS Firewall, página 10-16

Cisco Unified CME con NAT Por lo general, la interfaz LAN del router Cisco Unified CME (interfaz Ethernet) se usa como una dirección IP de origen que utilizan los teléfonos IP y el router Cisco Unified CME para comunicarse entre sí. Sin embargo, cuando un módulo de conmutación interno se usa para conectar teléfonos IP, la dirección IP de la VLAN se puede usar como una dirección IP de origen. Otra opción como dirección IP de origen es la dirección IP de la interfaz de un bucle de prueba.

La dirección IP de los teléfonos IP son direcciones internas para el router Cisco Unified CME y están en un segmento diferente que no es visible para los dispositivos externos o las personas que llaman. Otros dispositivos, incluyendo el gateway o gatekeeper Cisco, usan la dirección IP del router Cisco Unified CME para comunicarse en lugar de comunicarse directamente con los teléfonos IP. Los routers Cisco Unified CME convierten las direcciones IP de ida y vuelta para enrutar el tráfico a los teléfonos IP o fuera del área de red. Por lo tanto, no se requiere configuración NAT para la voz/audio de dos vías desde/hacia los teléfonos IP conectados localmente al router Cisco Unified CME. Se recomienda que NAT se implemente sólo para el tráfico de datos con Cisco Unified CME.

Es posible que NAT sea necesario para los teléfonos IP implementados de forma remota que no tienen direcciones IP enrutables.

Nota La dirección IP de Cisco Unified CME que se usa como dirección IP de origen necesita ser enrutable

y puede ser una dirección IP de bucle de prueba en todos los escenarios descritos en esta sección. Además, se deben abrir los puertos UDP/TCP entre los teléfonos IP remotos y la dirección de origen de Cisco Unified CME.



Teléfonos remotos con direcciones IP públicas El soporte telefónico remoto que se ha incorporado en Cisco Unified CME 4.0 permite que los teléfonos IP se conecten a Cisco Unified CME a través de un enlace WAN como, por ejemplo, Frame Relay, DSL y cable. La ilustración 10-1 muestra un escenario típico de esta disposición de conectividad. Ilustración 10-1: Teléfonos remotos con direcciones IP públicas

En este escenario de la ilustración 10-1, ephone 3 es una VLAN privada y usa Cisco Unified CME para tener acceso a ephone 1 y ephone 2 en las ubicaciones remotas con direcciones IP públicas. Sin embargo, debido a que las transmisiones de medios se envían entre los teléfonos conectados al mismo Cisco Unified CME, MTP (Media Termination Point) se debe configurar en los teléfonos remotos a fin de que Cisco Unified CME termine la transmisión de medios; de ese modo, se garantiza un audio de doble vía entre ephone 3 y ephone 1 o ephone 2. Los teléfonos remotos requieren el codec G729r8. La configuración en ephone 1 o ephone 2 es la siguiente: ephone 1 mtp codec g729r8

La opción MTP bajo ephone 1 hace que el router Cisco Unified CME actúe como un proxy. Cisco Unified CME envía los paquetes de medios a otros teléfonos IP con la dirección del router Cisco Unified CME en el campo de dirección de origen. Si otros teléfonos de la llamada no son un teléfono IP, Cisco Unified CME envía los paquetes de medios.

Nota Si todos los teléfonos tienen direcciones IP públicas, no se requiere la configuración MTP y los datos

de medios fluirían entre los teléfonos (en lugar de hacerlo a través de Cisco Unified CME). Recomendamos que no use MTP, a menos que se requiera. Como en el escenario anterior, se deben abrir los puertos UDP/TCP entre los teléfonos IP remotos y la dirección de origen de Cisco Unified CME.

Teléfonos remotos con direcciones IP privadas La ilustración 10-2 ilustra un escenario típico cuando se implementan teléfonos IP con direcciones IP privadas en la ubicación remota.



Ilustración 10-2: Conexión telefónica remota con direcciones IP privadas

Los teléfonos remotos se pueden conectar a través de un router Cisco tradicional (como el Cisco 87x o el Cisco PIX) o mediante un dispositivo de enrutamiento alternativo (como el router Linksys). Ambas implementaciones requieren que NAT se configure si los teléfonos remotos no usan direcciones IP enrutables. Se requiere la compatibilidad NAT SCCP para implementar audio de doble vía entre los teléfonos IP conectados al Cisco Unified CME. Al admitir NAT la conversión de las direcciones IP incrustadas y los números de puertos presentados en los mensajes SCCP, se puede crear una entrada NAT completa para permitir el tráfico RTP al flujo entre los teléfonos IP. Como resultado, se admite el audio de doble vía de voz/audio entre los teléfonos IP cuando están conectados a través de NAT. Para un dispositivo como el router Linksys, que no reconoce SCCP, existe el audio de una sola vía entre los dos extremos de teléfono IP. Un forma de evitar el problema del audio de una sola vía es conectar el teléfono IP remoto conectado al Linksys a través de un puerto DMZ con direcciones IP enrutables, o establecer una conexión VPN al router Cisco Unified CME.

Advertencias:

• La compatibilidad con NAT SCCP está disponible en Cisco IOS Release 12.3(11)T y versiones posteriores, en los routers Cisco IOS.

• Se requiere que MTP se configure en los teléfonos remotos.

• Los teléfonos remotos conectados a través de un router de Cisco con compatibilidad SCCP NAT también requieren la configuración de MTP a fin de dar soporte al audio de doble vía.

• Los teléfonos remotos conectados a un router SCCP NAT no Cisco encontrarán el problema de audio de una sola vía, incluso si se configura MTP en los teléfonos remotos. Una forma de solventar este problema temporalmente es usar VPN entre Cisco Unified CME y un router SCCP NAT no Cisco u obtener direcciones IP públicas para los teléfonos remotos.

Nota Como en los ejemplos anteriores, se deben abrir los puertos UDP/TCP entre los teléfonos IP remotos y

la dirección de origen de Cisco Unified CME.

Teléfonos remotos a través de VPN Los teléfonos remotos con direcciones IP privadas se pueden conectar a los teléfonos conectados a un Cisco Unified CME usando un router no Cisco. Sin embargo, a fin de dar soporte al audio de doble vía entre estos teléfonos remotos con direcciones privadas y los teléfonos conectados a Cisco Unified CME (que tienen direcciones IP públicas), se debe establecer un túnel VPN IP Sec entre Cisco Unified CME y el router no Cisco.

También se puede usar una VPN para conectar Cisco Unified CME y los routers Cisco SCCP NAT (como Cisco 87x/PIX) admitiendo así las conexiones compatibles con la aceleración QoS y VPN.

La ilustración 10-3 muestra ejemplos de estos entornos relacionados con VPN.



Nota Como en los ejemplos anteriores, se deben abrir los puertos UDP/TCP entre los teléfonos IP remotos y la dirección de origen de Cisco Unified CME.

Ilustración 10-3 Conexión telefónica remota mediante VPN

Consideraciones sobre la implementación Cisco Unified CME con Cisco IOS Firewall

Esta descripción de la implementación Cisco Unified CME con Cisco IOS Firewall describe los siguientes temas:

• Información general sobre Cisco IOS Firewall con Cisco Unified CME, página 10-16

• Problemas anteriores en Cisco Unified CME con Cisco IOS Firewall, página 10-16

• Cisco Unified CME y Cisco IOS Firewall en el mismo router, página 10-17

• Otras alternativas para garantizar la seguridad de Cisco Unified CME, página 10-19

Información general de Cisco IOS Firewall con Cisco Unified CME

Cisco IOS Firewall, ejecutándose en los routers Cisco IOS, ofrece una solución firewall basada en red con la funcionalidad de control de acceso basado en contexto (CBAC) o inspección de protocolos, sistema de detección de intrusiones (Cisco IDS), proxy de autenticación y filtrado URL. Un firewall proporciona control de acceso entre las redes internas y externas. Identifica las redes como internas (privada) o externas (pública) donde los paquetes pueden obtenerse desde fuera o dentro, bloquearse de forma predeterminada desde el interior o el exterior, y en las que se admite el paso de los paquetes asociados con una conexión originada en el interior. Muchos firewalls sólo funcionan si todo el tráfico externo se origina desde zócalos bien conocidos y no gestionan tráfico asimétrico (como el de medios UDP). Los firewalls de Cisco IOS permiten que los paquetes pasen basándose en las direcciones IP de origen y destino, y la directiva de firewall configurada.

Cisco Unified CME es una característica de software agregada a los routers Cisco IOS que proporciona procesamiento de llamadas para teléfonos IP usando Skinny Client Control Protocol (SCCP) para PYME/delegaciones y entornos SP gestionados. Pueden haber instancias de implementaciones en PYME o delegaciones donde sólo se requiere un solo router para suministrar acceso a Internet, servicio telefónico IP y funciones de Cisco IOS Firewall. Cisco Unified CME requiere que todos los teléfonos IP estén conectados localmente al Cisco Unified CME —antes de la introducción del soporte telefónico remoto.

Por lo tanto, se necesita que Cisco IOS Firewall sea compatible con H.323 y SCCP para el tráfico generado localmente.

Problemas anteriores en Cisco Unified CME con Cisco IOS Firewall

SCCP es una pequeña versión propietaria de Cisco de H.323. El tráfico H.323 se puede clasificar en señalización de llamada, control de llamada y comunicación de medios. H.323 usa Q.931, H.225 y



H.245 para configurar, gestionar/controlar y terminar llamadas. Los siguientes puntos describen cómo la señalización y los flujos de medios se ven afectados por el firewall de Cisco IOS.

Flujo de señalización

Una llamada H.323 requiere una conexión TCP para la señalización H.245 que no tienen asociado un puerto bien conocido. El puerto H.245 se asigna dinámicamente. Debido a que este puerto no se conoce previamente y no se puede configurar cuando se define la directiva del firewall, Cisco IOS Firewall bloqueará el mensaje H.245 y el procedimiento de señalización de llamada generará un error. Cuando se use NAT en la ruta de señalización H.323, se usará una dirección IP interna (que está detrás del NAT y el resto del mundo no conoce) como el elemento de información de la parte que realiza la llamada en el flujo de señalización H.225. Como resultado, la llamada entrante (los intentos de volver a crear una conexión H.225 a esa dirección) generará un error.

Flujos de medios (flujos RTP)

Los flujos RTP se ejecutan sobre UDP y no tienen ningún puerto fijo asociado a ellos. Cada tipo de flujo de medio tiene uno o más canales con números de origen, destino y puerto asignados, que no se conocen previamente y no se pueden preconfigurar en la directiva firewall. Para que el flujo de medios atraviese el firewall, éste debe abrir muchos puertos UDP con parejas de origen y destino para cada sesión de llamadas. Esto puede causar vulnerabilidades en la red detrás del firewall.

Debido a que Cisco IOS Firewall no permite el tráfico externo atraviese en dirección a los destinos internos, las llamadas VoIP (llamadas internas) generarán un error. Además, los puertos dinámicos RTP/RTCP que usan los extremos no se abren automáticamente y no se admiten sin modificación de la directiva de seguridad. Los problemas se pueden resumir de la siguiente forma:

• El firewall sólo examina las direcciones de Capa 3.

• Los protocolos de señalización VoIP incrustan direcciones IP en la Capa 4 y superiores.

- RTP/RTCP funciona en la Capa 5.

- De forma predeterminada, los firewalls no admiten el tráfico de fuera hacia dentro.

- El conjunto de características del firewall de Cisco IOS, NAT y PIX disponen de una funcionalidad de aplicación denominada Application Layer Gateway (ALG), o protocolo de resolución que ayuda a resolver estos problemas.

• La aplicación VoIP se compone de un conjunto dinámico de protocolos.

- SIP, MGCP, H.323 y SCCP para la señalización.

- SDP, H.225 y H.245 para el intercambio de capacidad.

- RTP/RTCP para el control y los medios de audio

- RTP/RTCP usan un puerto dinámico para los datos de audio que se sitúa en el intervalo de 16384 a 32767 para todos los productos de Cisco.

Nota Cisco IOS Firewall no admitía anteriormente la inspección Skinny, debido a que los paquetes salientes

se convierten a H323 o SIP. Como resultado, no hay necesidad de inspección Skinny. Sin embargo, las ACL se pueden usar para filtrar los paquetes/el tráfico no deseado como una forma de admitir la inspección Skinny de paquetes entrantes. Cisco IOS Firewall ha agregado soporte de inspección H.323 para cualquier tráfico generado localmente; de este modo, es posible implementar Cisco Unified CME e IOS Firewall en el mismo router.

Cisco Unified CME y Cisco IOS Firewall en el mismo router

Siempre que Cisco IOS Firewall no se aplique a las interfaces que tiene tráfico de voz (señalización y medios) entrante, Cisco Unified CME y Cisco IOS Firewall pueden coexistir en el mismo router. La



inspección del tráfico generado por el router, disponible en Cisco Release IOS 12.3(14) T y posteriores, mejora la funcionalidad de Cisco IOS Firewall para inspeccionar las conexiones TCP, UDP y H.323 que tienen un router o firewall como uno de los extremos de la conexión. La inspección de los canales TCP y UDP iniciados desde el router habilita la apertura dinámica de los “pinholes” de la lista de control de acceso (ACL) de la interfaz, para permitir el tráfico de retorno. La inspección de las conexiones H.323 hace posible la implementación de Cisco Unified CME y Cisco IOS Firewall en el mismo router. Esto también simplifica la configuración de ACL en la interfaz de Cisco Unified CME a través de la cual se realizan las conexiones H.323. Antes de esta característica, se requerían varias ACL para permitir que todos los canales de datos y de medios se negociasen dinámicamente; además de las ACL necesarias para permitir las conexiones H.323 en un puerto estándar como el 1720. Con esta característica, puede configurar las ACL para permitir los canales de control H.323 en el puerto 1720. Cisco IOS Firewall inspecciona todo el tráfico en el canal de control y abre “pinholes” para admitir canales de datos y medios negociados dinámicamente.

El siguiente procedimiento ilustra la configuración de ACL que da soporte a esta capacidad:

Paso 1 Crear la ACL. En este ejemplo, se permite el tráfico TCP desde la subred 10.168.11.1, 192.168.11.50 y 192.168.100.1. access-list 120 permit tcp host 10.168.11.1 any eq 1720 access-list 121 permit tcp host 192.168.11.50 host 10.168.11.1 eq 1720 access-list 121 permit tcp host 192.168.100.1 host 10.168.11.1 eq 1720

Paso 2 Crear la regla de inspección LOCAL-H323 de Cisco IOS Firewall. Esto permite la inspección del tráfico del protocolo especificado por la regla. Esta regla de inspección establece el valor del tiempo de inactividad en 180 segundos para cada protocolo (excepto para RPC). El valor del tiempo de inactividad define el periodo máximo que una conexión de un determinado protocolo puede permanecer activa sin que pase a través de ella tráfico alguno al router. Cuando se alcanzan estos tiempos de inactividad, se eliminan las ACL dinámicas que están insertadas para permitir el tráfico de retorno, y los paquetes subsiguientes (incluso los válidos, posiblemente) no se admitirán. ip inspect name LOCAL-H323 tftp timeout 180 ip inspect name LOCAL-H323 h323 router-traffic timeout 180

Paso 3 Aplicar la regla de inspección y la ACL. En este ejemplo, se aplica la regla de inspección LOCAL-H323 al tráfico en la interfaz Serial0/3/0: interface Serial0/3/0 ip address 10.168.11.2 255.255.255.0 ip access-group 121 in ip access-group 120 out ip inspect LOCAL-H323 in ip inspect LOCAL-H323 out encapsulation frame-relay frame-relay map ip 10.168.11.1 168 broadcast no frame-relay inverse-arp frame-relay intf-type dce

Paso 4 Cisco IOS Firewall sólo admite la versión 2 del protocolo H.323. Configure el siguiente comando en

Cisco Unified CME para admitir únicamente las características de la versión 2: voice service voip h323 session transport tcp calls-per-connection 1 h245 tunnel disable h245 caps mode restricted h225 timeout tcp call-idle value 0



Otras alternativas para garantizar la seguridad de Cisco Unified CME

Estas son cuatro soluciones alternativas que puede usar para proporcionar seguridad a los usuarios de Cisco Unified CME:

• Ejecutar Cisco IOS Firewall en otro router: no es necesario que esté en el mismo Cisco Unified CME.

• Configurar un número máximo de conexiones en el Cisco Unified CME. Esto está disponible con la implementación normal de H.323 en el software Cisco IOS y puede ayudar a controlar el número máximo de llamadas H.323 (Entrantes + salientes con configuración H225) que se procesarán (por ejemplo, dial-peer voice 10 voip; max-conn 5 limita las llamadas a cinco conexiones).

• Configurar las ACL para que admitan conexiones H.225 únicamente desde el gatekeeper (GK) si el GK de la red está usando la señalización enrutada.

• Usar la seguridad H.235 para autenticar a las personas que llaman y ofrecer seguridad de llamada.

Señalización SCCP segura mediante TLS Cisco Unified CME 4.0 incluido en Cisco IOS Release 12.4(4)XC ofrece autenticación telefónica y señalización SCCP segura con TLS (Transport Layer Security).

La autenticación telefónica es una infraestructura de seguridad para proporcionar SCCP segura entre Cisco Unified CME y los teléfonos IP. La autenticación telefónica gestiona las siguientes necesidades de seguridad:

• Establecer la identidad de cada extremo del sistema.

• Autenticar los dispositivos.

• Proporcionar privacidad de sesión de señalización

• Proporcionar protección a los archivos de configuración

Nota RTP seguro no se admite en Cisco Unified CME 4.0.

La característica de autenticación telefónica segura se admite en los siguientes conjuntos de características de Cisco IOS:

• Advanced IP Services (como c3725-advipservicesk9-mz.124-4.XC.bin)

• Advanced Enterprise Services (c3725-adventerprisek9-mz.124-4.XC.bin)

Los teléfonos compatibles son los teléfonos IP unificados de Cisco 7911G, Cisco 7941G, Cisco 7961G y 7970/71G-GE.

Las principales consideraciones para la señalización SCCP segura a través de TLS son las siguientes:

• Se usa el cliente CTL (Certificate Trust List) para crear el archivo CTL y hacerlo disponible en el directorio TFTP. El archivo CTL (CTLfile.tlv) contiene la información de clave pública de todos los servidores con los cuales interactúa el teléfono IP.

• Se crea un archivo de configuración firmado digitalmente (SEP<MAC-addr>.cnf.xml.sgh) por el módulo telephony-service en el software Cisco IOS. Se usa la clave privada del router para firmar el documento.

• Certificate Authority Proxy Function (CAPF), un proxy entre el teléfono IP y la autoridad de certificación (CA): se usa para solicitar un certificado en nombre del teléfono. A través del protocolo CAPF el servidor CAPF obtiene toda la información necesaria del teléfono (incluyendo la clave pública y el identificador del teléfono). El estado de la configuración CAPF reside en el archivo CNF.



• La autenticación telefónica tiene lugar entre el Cisco Unified CME y un dispositivo compatible cuando cada entidad acepta el certificado de la otra entidad, y cuando se establece una conexión segura entre las entidades. La autenticación telefónica depende de la creación de un archivo CTL.

• La autenticación de archivo valida los archivos firmados digitalmente que un teléfono descarga desde un servidor TFTP: archivos config, ringist, CTL y de configuración regional. Cuando se reciben este tipo de archivos, el teléfono valida las firmas de los archivos para verificar que no se hayan manipulado después de su creación.

• La autenticación de señalización, también denominada integridad de señalización, usa el protocolo TLS para validar que los paquetes de señalización no se hayan manipulado durante la transmisión. La autenticación de señalización depende de la creación del archivo CTL.

Siga el siguiente procedimiento para configurar el soporte para la señalización SCCP mediante TLS:

Paso 1 Configure NTP o configure manualmente el reloj del software usando el comando clock set como en el siguiente ejemplo: clock timezone PST -8 clock summer-time PDT recurring ntp clock-period 17247042 ntp server 171.68.10.80 ntp server 171.68.10.150

Paso 2 Configure una autoridad de certificación (CA) de Cisco IOS: certificados emitidos por la CA para las funciones de servidor Cisco Unified CME, CAPF, TFTP y SAST:

La CA puede estar en el mismo router Cisco Unified CME o en un router externo. El siguiente ejemplo ilustra la configuración de una CA en el mismo router Cisco Unified CME: crypto pki server laverda-ca grant auto database url flash: ! crypto pki trustpoint laverda-ca enrollment url http://192.168.1.1:80 revocation-check crl rsakeypair laverda-ca

Paso 3 Certifique el aprovisionamiento para las funciones de Cisco Unified CME: capf server, cme server, tftp server, sast1 y sast2 como se muestra en los siguientes ejemplos de configuración.

a. Obtenga un certificado para capf server: !configuring a trust point crypto pki trustpoint capf-server enrollment url http://192.168.1.1:80 revocation-check none !authenticate w/ the CA and download its certificate crypto pki authenticate capf-server ! enroll with the CA and obtain this trustpoint's certificate crypto pki enrollment capf-server

b. Obtenga un certificado para cme server: crypto pki trustpoint cme-server enrollment url http://192.168.1.1:80 revocation-check none crypto pki authenticate cme-server crypto pki enrollment cme-server

c. Obtenga un certificado para tftp server: crypto pki trustpoint tftp-server enrollment url http://192.168.1.1:80 revocation-check none



crypto pki authenticate tftp-server crypto pki enrollment tftp-server

d. Obtenga un certificado para sast1: crypto pki trustpoint sast1 enrollment url http://192.168.1.1:80 revocation-check none crypto pki authenticate sast1 crypto pki enrollment sast1

e. Obtenga un certificado para sast2: crypto pki trustpoint sast2 enrollment url http://192.168.1.1:80 revocation-check none crypto pki authenticate sast2 crypto pki enrollment sast2

Paso 4 Configure el servicio de telefonía con los siguientes pasos:

a. Configure la etiqueta trustpoint que se usa para la señalización segura: secure-signaling trustpoint cme-server

b. Configure las credenciales del servidor TFTP (trustpoint) que se usan para firmar los archivos de configuración: tftp-server-credentials trustpoint tftp-server

c. Configure el modo de seguridad para los extremos: server-security-mode secure device-security-mode authenticated

La opción authenticated instruirá al dispositivo para que establezca una conexión TLS sin cifrado. En este modo, no hay SRTP en la ruta de los medios.

La opción encrypted instruirá al dispositivo para que establezca una conexión TLS cifrada para asegurar la ruta de los medios mediante SRTP.

Nota Use la opción authenticated hasta que SRTP sea compatible en el futuro.

d. Configure el sistema para generar los archivos XML de configuración telefónica para cada extremo: cnf-file perphone

e. Configure los ephone. Por ejemplo: ephone 1 device-security-mode authenticated

Paso 5 Configure el cliente CTL en un Cisco Unified CME local a fin de crear un archivo CTL que contenga una lista de los certificados y tokens fiables y conocidos.

El cliente CTL puede ejecutarse en el mismo router Cisco Unified CME u otro router independiente. Este es un ejemplo de un cliente CTL en un router Cisco Unified CME local: ctl-client server capf 192.168.1.1 trustpoint capf-server server tftp 192.168.1.1 trustpoint tftp-server server cme 192.168.1.1 trustpoint cme-server sast1 trustpoint sast1 sast2 trustpoint sast2

Una vez que haya configurado toda la información anterior, use el comando regenerate para crear el archivo CTL:

regenerate



Paso 6 Configure el servidor CAPF server: capf-server port 3804 auth-mode null-string cert-enroll-trustpoint laverda-ca password 1 1511021F07257A767B trustpoint-label capf-server source-addr 192.168.1.1 !

Solución de problemas y depuración Use los siguientes comandos para la resolución de problemas y la depuración de la señalización SCCP segura a través de la configuración TLS:

• show ephone registered

• show ctl-client

• show capf-server sessions

• show capf-server auth-strings

• show capf-server summary

• debug ctl-client

• debug credentials

• debug capf-server all|messages|error|events

Nota Para obtener detalles sobre estos comandos de diagnóstico, consulte la referencia de los comandos de Cisco Unified CallManager Express. El siguiente es un ejemplo: http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_command_reference_book09186a 00805b6c70.html



Puertos de uso común de Cisco Unified CME Las tablas 10-1 y 10-2 muestran los puertos de uso común de Cisco Unified CME. Tabla 10-1 Puertos de uso común para voz en Cisco Unified CME

Protocolo Puerto Uso

SCCP TCP 2000 Control de llamadas para teléfonos SCCP SIP TCP 5060 Control de llamadas para extremos SIP RTP UDP 16384-32767 Medios desde Cisco Unified CME al extremo

H.323/SIP, incluyendo Cisco Unity Express RTP UDP 2000 Medios desde Cisco Unified CME al teléfono

SCCP H.225 TCP 1720 Configuración de llamada H.323 H.245 TCP 11000-65535 Control de llamadas H.323, asignación

aleatoria de puerto H.323 RAS UDP 1718 Descubrimiento de GK H.323 RAS UDP 1719 Control de llamadas de GK H.323 RAS UDP 223.0.1.4 Descubrimiento multidifusión de GK TLS TCP 3804 Solicitud de autenticación de CAPF TLS TCP 2443 Control seguro de llamadas para teléfonos

SCCP

Tabla 10-2 Puertos de uso común para datos en Cisco Unified CME

Protocolo Puerto Uso

DHCP UDP 67 Direccionamiento IP para teléfonos IP HTTP TCP 80 Acceso a GUI de Cisco Unified CME, acceso

a directorio local de teléfono IP HTTPS/SSL TCP 443 Acceso seguro a GUI de Cisco Unified CME NTP UDP 123 Sincronización temporal para Cisco Unity

Express, teléfonos IP Radius UDP 1645 Autenticación para usuarios de CLI/GUI de

Cisco Unified CME Radius UDP 1646 Contabilidad CDR SNMP UDP 161 Interrupciones para supervisión de Cisco

Unified CME SSH TCP 22 Acceso seguro a CLI de Cisco Unified CME Syslog UDP 514 Supervisión de sistema, contabilidad CDR Telnet TCP 23 Acceso a CLI de Cisco Unified CME

Documents

56026849 07 05 Cisco Call Manager Express c10 Practicas Seguras