Seguramente muchos de vosotros utilizáis Lync como sustituto de vuestras antiguas PBX, y en vez de utilizar las líneas RTB/RDSI/PRI tenéis un SIP Trunk con un ITSP (Internet Telephony Service Provider) para realizar vuestras llamadas a la PSTN. ¿Pero cuantos de vosotros os preocupa la seguridad del SIP TRUNK? ¿Qué medidas estáis adoptando? Desde mi punto de vista es algo que debemos tener muy en cuenta, sobre todo en entornos en los cuales atravesamos la WAN para conectarnos con nuestro ITSP (Lync Server: Direct SIP, Trunk SIP e Inter-Trunk Routing). En el poder capturar tráfico SIP y digitalizarlo es un proceso sencillo, teniendo las herramienta adecuada es casi cuestión de segundos.
Tenemos múltiples herramientas de análisis de tráfico de red, y que encima son capaces de convertir esos paquetes RTP en ficheros de audio (wav, mp3, etc..) para que podamos reproducirlos con total claridad. Aquí os muestro una captura (el audio me lo reservo) de Wireshark (www.wireshark.org). La captura se realiza interceptando tráfico RTP de un SIP TRUNK sin TLS, por lo que para el wireshark será una tarea sencilla:
Una vez que tenemos el tráfico deseado capturado, solo tenemos que convertir estos paquetes en ficheros de audio o reproducirlos directamente, para ello vamos al menú Telephony – VoIP Calls
y aquí tenemos las llamadas de VoIP detectadas
Si queremos revisar flujo de las comunicaciones de esta llamada, pulsamos en Flown y mirad que "bonito"
Y si queremos escuchar la conversación de esa llamada, pulsamos en Player y luego en Decode
ya tenemos la conversación preparada para se reproducirla, pulsamos en la pista que queremos reproducir y se habilitará el botón de Play
Aquí lo único "complicado" ha sido interceptar el SIP Trunk y que desde una tercera máquina (mi portátil) he podido capturar el tráfico de red. Si implementamos un SIP TRUNK vía TCP, esto es lo que puede ocurrir si alguien nos intercepta este tráfico de red y es capaz de capturarlo. Por desgracia muchos ITSP es como os van a entregar el SIP TRUNK, así que siempre que sea posible solicitarles alguna de estas medidas de seguridad:
– Establecer una VPN con IPSec Site-to-Site
– Protocolo de Transport SIP mediante TLS
En el caso de que no podamos obtener un SIP Trunk mediante alguno de los dos escenarios comentados, deberíamos realizar ciertas configuraciones (igualmente siempre recomendadas):
-
Añadir una segunda tarjeta de red al mediation server, para configurar el SIP Trunk mediante esa tarjeta y situarla en una DMZ.
-
Crear una subred lo más pequeña posible en el número de direcciones disponibles para hosts (/30), de tal forma que solo exista conectivdad "local" entre el dipositivo de seguridad y el mediation server. Ni hay que decir que la subred debe ser diferente a la de la red local
-
Establecer una puerta de enlace solo en la interface de red que utilizaremos para conectarnos al ITSP, y para el resto de redes utilizar rutas estáticas con interface de salida (
Edge Lync: Configuración de Red (Parte I), mirad el esquema de host seguro)
-
Deshabilitar protocolos innecesarios o más bien solo dejar los necesarios: Protocolo de Internet versión 4 o 6, Programador de Paquetes QoS (si se ha implementado)
-
Configurar el filtrado de IP Origen (IP del ITSP) en la regla de publicación de vuestro dispositivo de seguridad
-
Definir únicamente los puertos necesarios en la regla de publicación, tanto de entrada como de salida
-
En la regla de publicación del SIP Trunk, definir la franja horaria en la que la regla estará activa y permitirá que se pueda utilizar el SIP Trunk
-
Habilitar la inspección del protocolo SIP siempre que sea posible y vuestro dispositivo de seguridad lo soporte
-
Habilitar registro de LOGS y configurar ciertas alertas (las justas y necesarias, porque sino luego se terminarán no revisando) a un servidor de recolección de registros (Syslog)
Como ya sabéis existen varias formas de conectar a Lync a una PBX o ITSP o Gateway de Voz, mediante SIP Trunk o Direct SIP. En este artículo de hace unas semanas había explicado las diferencias: Lync Server: Direct SIP, Trunk SIP e Inter-Trunk Routing. En todo caso por resumir aquí os dejo la explicación de las diferencias entre ambos términos:
Trunk SIP: Conexiones SIP entre dos dispositivos independientes, por ejemplo nuestro servidor Lync y un ITSP o enlaces SIP entre dos sedes conectadas mediante VPN, MPLS, etc.
Direct SIP: Son conexiones SIP entre dos dispositivos que se conectan de forma directa en la misma red local, por ejemplo nuestro servidor Lync y un enlace de red telefónica conmutada (RTC) o un sistema IP-PBX. Pero siempre de forma local, en ningún momento se conecta fuera de la red local
Teniendo en cuenta esta, veamos que debemos hacer si configuramos un Direct SIP entre Lync y una IP-PBX:
- Configurar en nuestros switch L2 o L3 una VLAN de Voz
-
Añadir una segunda tarjeta de red al mediation server y conectarla a la VLAN de Voz
-
Conectar la tarjeta de red de la IP-PBX la VLAN de Voz
- Deshabilitar protocolos innecearios o más bien solo dejar los necesarios: Protocolo de Internet versión 4 o 6, Programador de Paquetes QoS (si se ha implementado)
-
Crear una subred lo más pequeña posible en el número de direcciones disponibles para hosts (/30) si solo disponemos de un Mediation y una IP-BPX
-
Configurar Port-Security en los puertos del switch si lo soporta
-
-
Evitar subir la VLAN por algún puerto troncal configurado en el Switch
Estas son algunas de las mediadas que creo que se deberían adoptar como básicas, pero entiendo que también es cuestión del hardware del que dispongáis. Sobre todo en entornos en los que no podemos utilizar TLS, que es lo que utiliza Lync por defecto. Además, como veis en las capturas de Wireshark se utilizan RTP (Real Time Protocol) pero en Lync por defecto utiliza SRTP (Secure Real Time Protocol). Aquí os dejo una tabla resumen de la utilización de TLS o SRTP:
|
Entre servidores
|
MTLS
|
|
De cliente a servidor
|
TLS
|
|
Mensajería instantánea y presencia
|
TLS (si se ha configurado para TLS)
|
|
Audio, vídeo y uso compartido de escritorio
|
SRTP
|
|
Uso compartido de escritorio (señalización)
|
TLS
|
|
Conferencia web
|
TLS
|
|
Descarga del contenido de las reuniones, descarga de la libreta de direcciones y expansión de grupos de distribución
|
HTTPS
|
Como podemos apreciar el tráfico de las conversaciones de audio serán encriptadas por defecto. Podemos cambiar este comportamiento (NO RECOMENDADO) con el siguiente cmdlet:
Set-CsMediaConfiguration [-EncryptionLevel <SupportEncryption | RequireEncryption | DoNotSupportEncryption>]
Si queremos ver la configuración actual escribimos el siguiente cmdlet:
Get-CsMediaConfiguration
Más info: http://technet.microsoft.com/es-es/library/gg398580.aspx
Como podéis observar yo he actualizado el EncryptionLevel a SupportEncryption porque es necesario para poder comunicase con sistemas de mensajeria pública (MSN). Para ello se tienen que ejecutar los dos siguientes cmdlets:
Set-CsMediaConfiguration -EncryptionLevel SupportEncryption
Set-CsExternalAccessPolicy Global -EnablePublicCloudAccess $true -EnablePublicCloudAudioVideoAccess $true
Más info: http://technet.microsoft.com/es-es/library/gg398177(v=ocs.14).aspx
Además en cada configuración de puerta de enlace IP/RTC es donde especificaremos el protocolo de transporte SIP: TCP o TLS
Siempre que sea posible, claramente debemos utilizar TLS. Si bien también es cierto, que no todos los Gateway de Voz o IP-PBX a los que nos queremos conectar soportan TLS de ahí que busquemos alternativas que nos permitan garantizar el aislamiento del tráfico de red de posibles escuchas o llamadas fraudulentas. Se pueden aplicar más medidas de seguridad, pero para ello se necesaria hardware específico y más carga administrativa en algunos casos, la idea inicial del artículo era dar una visión sencilla de lo que debemos hacer como mínimo para proteger vuestro sistema. Si bien es cierto que Lync ya tiene implementado sus mecanismos de seguridad, pero cuando queremos conectarlos con otros sistemas ya habéis visto que puede ser vulnerable.
Debemos ser conscientes que existen múltiples formas de atacar a los sistemas de telefonía, por lo menos debemos tener claro ciertos conceptos antes de implementar este tipo de servicios en cualquier cliente.
Espero que os sea de utilidad!!!
