Provisioning de IP Phones de forma segura over wan

Muy buenas,

Este artículo la verdad es que lo teníamos pendiente de hace mucho. En las últimas semanas, debido a la situación mundial, hemos recibido muchos correos preguntándonos por el tema, hay muchas empresas que han publicado en Internet su IP PBX de forma rápida y esto lo tenían pendiente.

Del tema de publicar en Internet sistemas corporativos de VozIP y los temas de seguridad relacionados nos da para un post entero largo, así que no navegaremos por dichos mares hoy.

¿Provisioning?

Si, entendiéndola por provisión automática como tal, es decir, un terminal arranca, recibe sus datos de IP por DHCP y se autoconfigura de forma mágica sin tener que tocarlo (zero touch provisioning).

Conceptos de seguridad: PKI

Antes de entrar en materia, una breve explicación de las bases de la seguridad en materia de provisión.

La provisión segura se basa en el standard de facto en confianza en Internet: PKI, o lo que es lo mismo: Infraestructura de Clave Pública y Privada.

De este tema, hay mucha documentación disponible en Internet, por explicarlo en 2 frases: Mediante clave pública y privada es posible establecer una comunicación entre 2 partes por medio de un canal inseguro sin que hayan tenido que intercambiar una contraseña previamente. Todo ello con una jerarquía de confianzas (lo mismo que hacen nuestros navegadores con las CA’s conocidas).

Es decir, el terminal recién sacado de la caja tiene que poderse comunicar con nosotros de forma segura y nosotros lo mismo, poder comunicarnos con el terminal de forma segura. Es importante esta dualidad, porque en este campo entendemos que en materia de seguridad necesitamos:

• Confidencialidad: Las contraseñas SIP que vamos a mandar al terminal no queremos que nadie las pueda leer, obviamente.
• Integridad: No queremos que nadie altere nuestros mensajes y le diga al terminal que el Proxy SIP es otro y se hagan un MiTM como contaba Pepelux en su charla.
• Autenticidad: Este punto lo dejamos para el final y es casi el mas importante: queremos que cuando un terminal nos dice que es un SNOM y que su MAC es XX:XX:XX:XX:XX:XX , estar seguros de ello, o al menos tan seguros como la confianza que tengamos en SNOM y en la seguridad con la que guardan su CA.

 

¿Cómo se perfilan los fabricantes en esta materia?

De los 3 principales con los que más solemos trabajar: Cisco SMB, SNOM y YEALINK las posturas son diferentes, pero la buena noticia es que es posible con todos ellos. Con el resto de fabricantes del mercado, que hay muchos, el escenario es similar.

 

Cisco SMB

Para el caso de los terminales Cisco SMB nos encontramos con la peculiaridad de que el certificado que enviemos al terminal debe estar firmado por la propia Cisco. Para ello, el fabricante nos facilita una web donde poder generar dicho certificado firmado por Cisco en la siguiente URL:

https://software.cisco.com/software/edos/home

Es importante tener en cuenta que deberemos tener cuenta partner con tipo de rol «Certificate Management User».

Como vemos en la captura hemos indicado que nos genere un certificado para los modelos más nuevos y 5XX, con una duración de 5 años y de tipo SHA256.

El certificado entonces tiene a Cisco como issuer para firmar nuestro certificado, quedando tal que asi:

 

SNOM

Los terminales Snom vienen con multitud de certificados CA de las principales entidades certificadoras preinstalados. Además, nos permite añadir certificados CA para que los terminales puedan confiar en nosotros.

Como vemos en la imagen, los terminales vienen con multitud de certificados preinstalados, donde podemos ver los datos de los mismos. Al subir nuestro certificado pasaremos a poder verlo en la pestaña Custom Certificates.

 

Yealink

Con Yealink, nos ocurre lo mismo que con los terminales Snom y es que además de venir con algunos certificados preinstalados, nos permite subir nuestro propio certificado CA para, de nuevo, que así pueda confiar en nosotros.

Como vemos en la imagen, el certificado CA queda reflejado en el apartado de Seguridad del terminal.

 

Detalle de configuraciones por fabricante

A la hora de gestionar la entrega de dichos certificados CA, cada fabricante tiene su sintaxis. Para el caso de Cisco, no es necesario hacerle llegar ningún certificado CA, ya que, al haber firmado nuestro certificado a través de su herramienta, el terminal pasa a confiar en nosotros.

Para Snom la sintaxis sería la siguiente:

<certificates>
  <certificate url=»http://IP_DEL_HOST/cert.pem» />
</certificates>

Para Yealink:

trusted_certificates.url = http://IP_DEL_HOST/cert.pem
security.trust_certificates = 0
security.cn_validation = 0
security.ca_cert = 1

 

Arquitectura recomendada: ¿Frontal de provisión?

La arquitectura que recomendamos utilizar para este proceso se apoya principalmente en Nginx ya que nos permite gestionar las peticiones que nos realizan dichos terminales, teniendo además gestión multidominio.

Mediante un firewall frontal, podemos realizar un NATeo que se encarga de redireccionar los puertos hacia el frontal de provisión. En este frontal, es en el que mediante Nginx nos encargamos en primera instancia de redireccionar las peticiones que llegan en texto plano al puerto 80 hacia la instancia de la centralita deseada pero redirigida hacia un script que se encarga de la gestión de las peticiones recibidas.

Paso 1: Por un canal inseguro, sin que sea un problema que nos intercepten, provisionamos la confianza en nuestra CA y el profile rule con el que el terminal solicitará el siguiente fichero de manera segura.

Paso 2: A partir de este punto, nuestro terminal puede provisionarse de manera segura  y autenticada ya que tenemos una sesión TLS mutua.

Los certificados CA de los terminales se pueden encontrar en las siguientes URLs de los propios fabricantes:

• Yealink:http://support.yealink.com/forward2download?path=ZIjHOJbWuW/DFrGTLnGypmEoAu3CMt1rA0YplusSymbol7yQkzplusSymbol1DnApKho/YDz8WZErjpKfplusSymbolr3u8fy0j3svhnzEh2XQFISOTMPvyL85c0xI8eeh6CgbEe1gKbsyTvRdxDv7Led0VArcLgDl68qw=

• Snom:http://downloads.snom.net/documentation/certs.crt (DECT) / http://downloads.snom.net/documentation/phone1-256.crt (DESKTOP)

• Cisco:https://software.cisco.com/software/edos/dist/docs/combinedcaBE.crt.zip (es necesario acceder con una cuenta partner)

Nginx se encargará, como indicábamos, de presentar el certificado que hará que los terminales pasen a confiar en nosotros gracias al envío de el certificado CA realizado en la primera petición o paso «0» y también de verificar que los terminales estén validados revisando su certificado concreto.

ssl_certificate /etc/nginx/ssl/irontec_provision.cert;
ssl_certificate_key /etc/nginx/ssl/irontec_provision.key;
ssl_client_certificate /etc/nginx/ssl/yealinkca.cert;
ssl_verify_client on;

 

En esta imagen podemos ver una captura en la que es posible ver toda la secuencia completa en la que se validan ambas partes mediante sus certificados de confianza.

Como vemos, esto nos permite un amplio abanico de parametrizaciones personalizadas que podremos realizar en el script al que redigirimos las peticiones desde nuestro Nginx.

Ahora todo este proceso es seguro y sin riesgos 🙂 .