La implementación de pares Expressway-C y Expressway-E permite hacer y recibir llamadas de Internet utilizando tecnologías transversales de firewall. Esta implementación es lo que toma en forma segura su control de llamadas local y lo vincula a Cisco Webex.

Ni el Expressway-C ni el Expressway-E requieren que se abra ningún puerto entrante en la zona desmilitarizada (DMZ) debido a la arquitectura transversal del firewall. Pero se deben abrir los puertos de señales SIP de TCP y los de medios de UDP que ingresan al firewall de Internet para permitir el paso de las llamadas entrantes. Debe reservar cierto tiempo para abrir el puerto correcto en su firewall empresarial.

La arquitectura transversal del firewall se muestra en el siguiente diagrama:

Por ejemplo: en el caso de llamadas interempresas (B2B) entrantes en las que se utilice el protocolo SIP, se deben abrir los puertos 5060 y 5061 (5061 se utiliza para SIP TLS) de TCP en el firewall externo, junto con los puertos para medios UDP que se utilizan para servicios como voz, vídeo, uso compartido de contenido, vídeo doble y demás. Los puertos para medios que se deban abrir dependerán de la cantidad de llamadas concurrentes y de la cantidad de servicios.

Puede configurar el puerto para escuchar SIP en Expressway en cualquier valor dentro del rango de 1024 a 65534. Al mismo tiempo, este valor y el tipo de protocolo deben informarse en los registros de SRV de DNS, y se debe abrir ese mismo valor en el firewall de Internet.

Aunque el estándar para SIP TCP es 5060 y para SIP TLS es 5061, nada impide el uso de otros puertos, tal como se indica en el siguiente ejemplo.

Ejemplo

En este ejemplo, suponemos que el puerto 5062 se utiliza para llamadas SIP TLS entrantes.

El registro de SRV de DNS correspondiente a un grupo de dos servidores Expressway tiene dice lo siguiente:

_sips._tcp.example.com SRV service location:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

Estos registros significan que las llamadas se redireccionan a us-expe1.example.com y a us-expe2.example.com con carga compartida equivalente (prioridad y peso) utilizando TLS como el tipo de transporte y 5062 como el número de puerto de escucha.

Un dispositivo que sea externo a la red (en Internet) y que realice una llamada SIP a un usuario del dominio corporativo (usuario1@ejemplo.com) deberá consultar al DNS para saber qué tipo de transporte usar, el número de puerto, cómo equilibrar la carga del tráfico y a qué servidores SIP enviar la llamada.

Si la entrada de DNS incluye _sips._tcp, está especificando SIP TLS.

TLS es un protocolo cliente-servidor y, en las implementaciones más comunes, utiliza certificados para la autenticación. En una situación de llamadas interempresas, el cliente TLS es el dispositivo que hace la llamada, y el servidor TLS es el dispositivo al que se realiza la llamada. Con TLS, el cliente comprueba el certificado del servidor y, si falla la comprobación del certificado, se desconecta. El cliente no necesita un certificado.

En el siguiente diagrama se muestra el protocolo de enlace TLS:

Sin embargo, la especificación TLS establece que el servidor también puede comprobar el certificado del cliente enviándole un mensaje de Solicitud de certificado durante el protocolo de enlace TLS. Este mensaje es útil en una conexión entre servidores, tal el caso de una llamada que se establece entre Expressway-E y la nube Cisco Webex. Este concepto se llama TLS con autenticación mutua y es obligatorio para la integración con Cisco Webex.

Tanto la parte que realiza la llamada como la que la recibe comprueban el certificado de la otra, tal como se indica en el siguiente diagrama:

La nube comprueba la identidad del Expressway, y el Expressway comprueba la identidad de la nube. Por ejemplo: si la identidad de la nube incluida en el certificado (CN o SAN) no coincide con la configurada en Expressway, se interrumpe la conexión.

Si la autenticación mutua está activada, el Expressway-E siempre solicita el certificado del cliente. Como consecuencia de ello, Mobile and Remote Access (MRA) no funcionará porque, en la mayoría de los casos, no se implementan certificados en clientes Jabber. En una situación interempresas, la llamada se desconecta si la entidad que realiza la llamada no puede proporcionar ningún certificado.

Le recomendamos que no elija 5061 para TLS con autenticación mutua; puede elegir, por ejemplo, el puerto 5062. Cisco Webex Los Servicios híbridos utilizan el mismo registro TLS de SIP que para B2B. En el caso del puerto 5061, tampoco funcionarán otros servicios que no puedan proporcionar un certificado de cliente TLS.

Acceso entre empresas, móvil y remoto y tráfico de Cisco Webex en el mismo par Expressway

En las llamadas con acceso entre empresas, móvil y remoto se utiliza el puerto 5061 para SIP TLS, y el tráfico de Cisco Webex utiliza el puerto 5062 para SIP TLS con autenticación mutua.

La comprobación de la titularidad de los dominios es parte de la verificación de identidades. La verificación de dominios es una medida de seguridad y una comprobación de la identidad que implementa la nube Cisco Webex para probar que usted es quien dice ser.

La comprobación de identidad se realiza en dos etapas:

1. Comprobación de la titularidad del dominio. Este paso implica a tres tipos de dominios y es una comprobación de verificación que se realiza una sola vez:

   • Dominio de correo electrónico

   • Dominio DNS de Expressway-e

   • Dominio URL de directorio

2. Comprobación de la titularidad de nombres DNS en Expressway-E. Este paso se realiza por medio de la implementación de TLS con autenticación mutua e implica el uso de certificados públicos, tanto en la nube como en el Expressway. A diferencia de la comprobación de identidades de dominios, este paso se realiza durante cualquier llamada hecha a la nube o recibida de la nube.

Un relato para mostrar la importancia de la comprobación de la titularidad de un dominio

La nube Cisco Webex realiza la comprobación de la titularidad del dominio para aplicar la seguridad. El robo de identidad es una posible amenaza si no se realiza esta comprobación.

En el siguiente relato se detalla lo que podría suceder si no se realiza una comprobación de la titularidad de un dominio.

Una empresa con dominio DNS definido en "hacker.com" compra los Servicios híbridos de Cisco Webex. Otra empresa, con su propio dominio definido en "ejemplo.com", también está usando los servicios híbridos. Una de los gerentes generales de la empresa Example.com se llama Jane Roe y su URL de directorio es jane.roe@example.com.

La administradora de la empresa Hacker.com define una de sus URL de directorio en jane.roe@example.com y la dirección de correo electrónico en jane.roe@hacker.com. Ella puede hacer so porque la nube no comprueba el dominio SIP URL en este ejemplo.

Luego inicia sesión en Cisco Webex Teams con jane.roe@hacker.com. Como ella es la titular del dominio, se lee y responde el correo electrónico de verificación, y puede iniciar sesión. Finalmente, hace una llamada a uno de sus colegas (John Doe); para ello marca john.doe@ejemplo.com desde su aplicación Cisco Webex Teams. John está sentado en su oficina y ve una llamada en su dispositivo de vídeo proveniente de jane.roe@ejemplo.com; esa es la URl de directorio asociada con esa cuenta de correo electrónico.

"Está fuera del país", piensa. "Tal vez necesite algo importante." Contesta el teléfono, y la falsa Jane Roe le solicita documentos importantes. Ella le explica que su dispositivo no funciona y, como está de viaje, le pide que le envíe los documentos a su dirección de correo electrónico privada: jane.roe@hacker.com. De esta manera, la empresa recién se da cuenta de que hubo una fuga de información importante recién cuando Jane Roe vuelve a la oficina.

La compañía Ejemplo.com tiene muchas maneras de protegerse contra llamadas fraudulentas que provienen de Internet, pero una de las responsabilidades de la nube Cisco Webex es asegurarse de que la identidad de que cualquier persona que llame desde Cisco Webex sea correcta y no esté falsificada.

Para comprobar la identidad, Cisco Webex requiere que la empresa demuestre que es la titular de los dominios que se utilizan en llamadas híbridas. Si no lo hace, no funcionará.

Para asegurar esta titularidad, se requieren los dos pasos de verificación de dominios:

1. Demostrar que la empresa es titular del dominio de correo electrónico, del dominio del Expressway-E y del dominio de la URL de directorio.

   • Todos estos dominios deben poder enrutarse y ser conocidos por servidores DNS públicos.

   • Para demostrar la titularidad, la administradora de DNS debe introducir un registro de texto (TXT) de DNS. Un registro TXT es un tipo de registro de recursos en el DNS que se utiliza para poder asociar un texto arbitrario y sin formato a un host u otro nombre.

   • La administradora de DNS debe introducir el registro TXT en la zona en la que se deba demostrar la titularidad. Después de ese paso, la nube Cisco Webex realiza una consulta de registros TXT para ese dominio.

   • Si la consulta TXT arroja un resultado positivo y este resultado coincide con el token que se generó desde la nube Cisco Webex, se verifica el dominio.

   • A modo de ejemplo, la administradora debe demostrar que es la titular del dominio "ejemplo.com" si quiere que los Servicios híbridos de Cisco Webex funcionen en su dominio.

   • A través de https://admin.webex.com, inicia el proceso de verificación al crear un registro TXT de modo que coincida con el token que generó la nube Cisco Webex:

     

   • Entonces, la administradora de DNS crea un registro TXT para este dominio con el valor definido en 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, tal como se indica en el siguiente ejemplo:

     

   • En este momento, la nube puede verificar que el registro TXT correspondiente al dominio example.com coincide con el token.

   • La nube realiza una búsqueda de TXT en DNS:

     

   • Como el valor del TXT coincide con el del token, esta coincidencia demuestra que la administradora agregó el registro TXT correspondiente a su propio dominio al DNS público, y que ella es la titular del dominio.

2. Comprobación de la titularidad de nombres DNS en Expressway-E.

   • La nube debe comprobar que el Expressway-E tiene una identidad confirmada por una de las autoridades de emisión de certificados en las que confía. El administrador del Expressway-E debe solicitar un certificado público para su Expressway-E a una de las autoridades de emisión de certificados. Para emitir el certificado, la autoridad realiza un proceso de verificación de la identidad sobre la base de una comprobación de validación del dominio (para los certificados validados del dominio) o de una comprobación de validación de la organización (para certificados validados de la organización).

   • Las llamadas entrantes y salientes de la nube dependen del certificado que se haya emitido al Expressway-E. Si el certificado no es válido, la llamada se interrumpe.

El host de conectores Expressway-C se debe registrar en Cisco Webex para que funcionen los servicios híbridos.

Expressway-C se implementa en la red interna, y la forma en la que se inscribe en la nube es a través de una conexión HTTP saliente: el mismo tipo que se utiliza para cualquier navegador que se conecta a un servidor web.

La inscripción y comunicación a la nube Cisco Webex emplea TLS. El Expressway-C es el cliente TLS y la nube Cisco Webex es el servidor TLS. De esta manera, el Expressway-C comprueba en el certificado del servidor.

La autoridad de emisión de certificados firma un certificado de servidor con su propia clave privada. Cualquier persona que posea la clave pública puede decodificar esa firma y demostrar que la misma autoridad de emisión de certificados firmó ese certificado.

Si el Expressway-C tiene que validar el certificado provisto por la nube, debe utilizar la clave pública de la autoridad de emisión de certificados que firmó ese certificado para decodificar la firma. Hay una clave pública en el certificado de la autoridad de emisión de certificados. Para establecer una relación de confianza con las autoridades de emisión de certificados que utiliza la nube, la lista de certificados de estas autoridades de confianza debe estar incluida en el almacén de confianza de Expressway. Al hacerlo, el Expressway puede verificar que la llamada realmente proviene de la nube Cisco Webex.

Con la carga manual, puede cargar todos los certificados de autoridades de emisión de certificados relevantes al almacén de confianza de Expressway-C.

Con la carga automática, la propia nube carga esos certificados al almacén de confianza de Expressway-C. Le recomendamos que utilice la carga automática. La lista de certificados podría cambiar, y la carga automática le garantiza que siempre tendrá la más reciente.

Si permite la instalación automática de certificados de autoridades de emisión de certificados, será redireccionado a https://admin.webex.com (el portal de administración). El propio Expressway-C realiza el redireccionamiento sin intervención del usuario. En su carácter de administrador de Cisco Webex, usted debe autenticarse por medio de una conexión HTTPS. Poco después, la nube reenviará los certificados de las autoridades de emisión de certificados al Expressway-C.

Mientras los certificados no estén cargados en el almacén de confianza del Expressway-C no se podrá establecer la conexión HTTPS.

Para evitar este problema, el Expressway-C se preinstala con certificados de autoridades de emisión de certificados de confianza para Cisco Webex. Esos certificados se utilizan solamente para configurar y validar la conexión HTTPS inicial, y no aparecen en la lista de confianza del Expressway-C. Una vez que los certificados de las autoridades de emisión de certificados de confianza se descarguen de la nube a través de esta conexión HTTPS inicial, estarán disponibles para ser usados en toda la plataforma; luego, aparecerán en la lista de confianza del Expressway-C.

En esta lista se muestran los certificados de autoridades de emisión de certificados que utiliza la nube Cisco Webex actualmente. Esta lista podría cambiar en el futuro:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - Solo para uso autorizado, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

También se requiere una lista de certificados de autoridades de emisión de certificados para el Expressway-E del par transversal. El Expressway-E se comunica con la nube Cisco Webex por medio de SIP con TLS, impuesto por autenticación mutua. El Expressway-E confía en las llamadas hacia y desde la nube solo si el CN o el SAN del certificado presentado por la nube durante la configuración de la conexión TLS coincide con el nombre de sujeto configurado para la zona de DNS en Expressway ("callservice.webex.com"). La autoridad de emisión de certificados emite un certificado solo después de una comprobación de identidad. Se debe demostrar la titularidad del dominio callservice.webex.com para obtener un certificado firmado. Como nosotros (Cisco) somos ese dominio, el nombre DNS "callservice.webex.com"es una evidencia directa de que el par remoto realmente es Cisco Webex.

Conector de calendario integra Cisco Webex con Microsoft Exchange 2010, 2013 y 2016, o con Office 365, por medio de una cuenta de suplantación. La función de administración de suplantación de aplicaciones de Exchange permite que las aplicaciones suplanten a los usuarios de una organización para realizar tareas en su nombre. La función de suplantación de aplicaciones se debe configurar en Exchange y se utiliza en el Conector de calendario como parte de la configuración de Exchange en la interfaz del Expressway-C.

La cuenta de suplantación de Exchange es el método que recomienda Microsoft para esta tarea. Los administradores de Expressway-C no necesitan conocer la contraseña, porque un administrador de Exchange puede introducir el valor en la interfaz de Expressway-C. La contraseña no se hace evidente, incluso si el administrador del Expressway-C tiene acceso de raíz al cuadro del Expressway-C. La contraseña se almacena cifrada utilizando el mismo mecanismo de cifrado de credenciales que el de las otras contraseñas en el Expressway-C.

Para mayor seguridad, siga los pasos de la Guía de implementación para el Servicio de calendario híbrido de Cisco Webex para habilitar TLS a fin de asegurar conexiones EWS en el cable.