Cerrar
InicioComunicaciones UnificadasLync ServerLync Server: Recomendaciones para Securizar un Trunk SIP o Direct SIP

Lync Server: Recomendaciones para Securizar un Trunk SIP o Direct SIP

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:

vpn_con_certificados_ndes_35.png

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 Callsvpn_con_certificados_ndes_36.png
y aquí tenemos las llamadas de VoIP detectadas

vpn_con_certificados_ndes_37.png
Si queremos revisar flujo de las comunicaciones de esta llamada, pulsamos en Flown y mirad que “bonito”

vpn_con_certificados_ndes_39.png
Y si queremos escuchar la conversación de esa llamada, pulsamos en Player y luego en Decode

vpn_con_certificados_ndes_38.png

ya tenemos la conversación preparada para se reproducirla, pulsamos en la pista que queremos reproducir y se habilitará el botón de Play

vpn_con_certificados_ndes_40.png

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
  • Si tenemos un switch L3 filtremos el Inter-VLAN Routing con ACL u otro mecanismo
  • 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:

Tipo de tráfico Protegido por
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 cifradaspor 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

vpn_con_certificados_ndes_41.png

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 mensajería 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

vpn_con_certificados_ndes_42.png

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!!!

Exchange Server 2013
Cliente Lync: Cambia

sbuytrago@asirsl.com

NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This