Beruflich Dokumente
Kultur Dokumente
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.
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).
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
(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+
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.
ephone-dn 1
number 2000
cor incoming user
ephone-dv 2
number 2001
cor incoming superuser
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
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
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.
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
!
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
ephone-dn 1
number 2000
cor incoming user
Ephone-dn 2
number 2001
cor incoming superuser
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.
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.
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.
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.
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.
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.
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
• 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. Configure las credenciales del servidor TFTP (trustpoint) que se usan para firmar los archivos de
configuración:
tftp-server-credentials trustpoint tftp-server
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
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
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_book09186
a 00805b6c70.html
Tabla 10-2 Puertos de uso común para datos en Cisco Unified CME