Cómo los controladores de borde de sesión protegen las redes de voz

Cada troncal SIP, cada IP-PBX y cada conexión UCaaS que toca la Internet pública es una superficie de ataque. Solo el fraude telefónico le cuesta a la industria de las telecomunicaciones más de $10 mil millones anuales, según la Communications Fraud Control Association (CFCA). Los ataques de denegación de servicio distribuido (DDoS) contra la infraestructura VoIP pueden dejar fuera de línea a una organización entera en minutos. Y sin cifrado, el tráfico de voz viaja en texto claro, legible para cualquiera que tenga un analizador de paquetes en la ruta de red.

Un controlador de borde de sesión (SBC) es el elemento de red diseñado para ubicarse en el perímetro de una red de voz y defenderse exactamente contra estas amenazas. Pero la “seguridad del SBC” no es una sola función. Es un conjunto de capas de defensa complementarias que protegen la señalización, los medios y la infraestructura de red central contra distintas categorías de ataque.

Esta guía desglosa las cinco capas de seguridad que un SBC correctamente implementado proporciona, explica por qué los firewalls tradicionales no pueden reemplazar a un SBC para el tráfico de voz y cubre las capacidades de seguridad configurables que separan a los SBC modernos de los dispositivos heredados con reglas estáticas.

Por qué las redes de voz necesitan seguridad dedicada

El tráfico de voz sobre IP (VoIP) utiliza una arquitectura de protocolo fundamentalmente distinta a la del tráfico web. SIP se encarga de la señalización (configuración de llamadas, finalización, registro), mientras que RTP transporta el audio real. Estos dos protocolos usan puertos diferentes, mecanismos de transporte diferentes y estructuras de encabezado diferentes, y ambos necesitan protección.

Los firewalls de red tradicionales operan en la capa de red (direcciones IP) y la capa de transporte (puertos TCP/UDP). Pueden bloquear o permitir tráfico según la IP de origen/destino y el número de puerto, pero no pueden inspeccionar ni comprender los mensajes SIP que pasan por esos puertos. Un firewall no puede distinguir entre un SIP INVITE legítimo y una inundación de solicitudes REGISTER maliciosas diseñadas para saturar su registrar. No puede detectar que un mensaje SIP intenta enrutar una llamada a un número internacional de tarifa premium a través de sus troncales.

Algunos firewalls ofrecen una función de SIP Application Layer Gateway (ALG), pero SIP ALG es conocido por causar más problemas de los que resuelve: reescribiendo encabezados SIP de formas que rompen los flujos de llamadas, interfiriendo con el recorrido de NAT y generando un comportamiento de enrutamiento impredecible. La mayoría de los ingenieros VoIP desactivan SIP ALG como primer paso de resolución de problemas.

La superficie de ataque de una red de voz abarca tres planos: el plano de señalización (mensajes SIP), el plano de medios (flujos de audio RTP) y el plano de gestión (interfaces de administración web, API, SNMP). Un SBC proporciona seguridad diseñada específicamente para los tres.

Las cinco capas de seguridad de un SBC

La seguridad del SBC se puede entender como una arquitectura de defensa en profundidad. Cada capa aborda una categoría específica de amenaza, y las cinco capas funcionan juntas para crear una postura de seguridad integral.

Capa 1: cifrado de señalización con SIP sobre TLS

El protocolo de inicio de sesión (SIP) fue diseñado sin cifrado integrado. Por defecto, los mensajes SIP viajan sobre UDP o TCP en texto claro, exponiendo los metadatos de las llamadas (quién llama a quién, desde qué dirección IP, con qué credenciales) a cualquiera que monitoree la red.

Transport Layer Security (TLS) cifra el canal de señalización SIP. Cuando SIP opera sobre TLS, todos los mensajes de señalización entre el SBC y sus pares están cifrados, previniendo la interceptación y los ataques de intermediario durante la configuración de llamadas.

Mutual TLS (mTLS) va un paso más allá al requerir que ambos lados de la conexión presenten certificados válidos. Esto impide que dispositivos no autorizados establezcan conexiones SIP con su SBC, incluso si conocen la dirección IP y el puerto correctos. Mutual TLS es particularmente importante para entornos regulatorios y para la mayoría de los sistemas de telefonía SIP expuestos a la Internet pública, incluyendo Enrutamiento directo de Microsoft Teams, que exige TLS para todas las conexiones SBC.

ProSBC admite SIP sobre TLS (configurable por punto de acceso de red, o NAP), lo que permite señalización cifrada para cada grupo de troncales de forma independiente. Esto significa que puede exigir TLS en conexiones de interconexión mientras mantiene SIP sin cifrar para terminales internos que no lo admiten.

Capa 2: cifrado de medios con SRTP

Cifrar la señalización protege los metadatos de las llamadas, pero el audio de voz real viaja por separado a través del Real-time Transport Protocol (RTP). Sin cifrado de medios, un atacante que capture paquetes RTP puede reconstruir la conversación completa.

Secure RTP (SRTP) cifra el flujo de medios. Un SBC compatible con SRTP puede operar en dos modos: retransmisión SRTP, donde pasa los medios cifrados sin descifrarlos (preservando el cifrado de extremo a extremo), y conversión RTP a SRTP, donde acepta RTP sin cifrar de un lado y lo cifra como SRTP hacia el otro. Esta capacidad de conversión es fundamental en entornos mixtos donde algunos terminales admiten SRTP y otros no.

ProSBC proporciona compatibilidad nativa con SRTP, incluyendo retransmisión SRTP y conversión RTP a SRTP, lo que permite a los operadores exigir cifrado de medios incluso al conectar equipos heredados que solo admiten RTP con infraestructura moderna que requiere SRTP.

Capa 3: control de acceso y filtrado de tráfico

El cifrado protege el contenido de las comunicaciones legítimas. El control de acceso determina quién tiene permitido comunicarse.

Las capacidades de control de acceso de un SBC típicamente incluyen listas de control de acceso (ACL) basadas en IP que permiten o bloquean direcciones IP y rangos específicos, filtrado de números de origen y destino que bloquea el tráfico hacia o desde números telefónicos específicos, y controles de registro que limitan qué dispositivos pueden registrarse a través del SBC.

La granularidad de estos controles importa. Un SBC que solo admite ACL globales obliga a aplicar las mismas reglas a cada troncal. Un SBC que admite ACL por grupo de troncales permite aplicar políticas diferentes a distintos operadores, segmentos de clientes o regiones geográficas.

ProSBC implementa listas de bloqueados dinámicas con listas grises basadas en porcentaje. Se puede configurar para bloquear el 100 % de las llamadas de un actor malicioso conocido, o bloquear un porcentaje configurable de una fuente sospechosa mientras se investiga. Su control de acceso opera tanto a nivel global como por NAP (punto de acceso de red), e incluye protección contra escaneo de registros SIP para detectar y bloquear ataques de inundación de registros antes de que consuman recursos del sistema.

Capa 4: mitigación de DoS y DDoS

Un ataque de denegación de servicio contra una red de voz no necesita ser sofisticado para ser efectivo. Una inundación de SIP INVITE (miles de solicitudes de configuración de llamadas por segundo desde direcciones IP falsificadas) puede agotar la capacidad de sesiones de un SBC, la memoria de un registrar o la potencia de procesamiento de una IP-PBX.

La mitigación de DoS y DDoS a nivel del SBC funciona aplicando límites de tasa por IP de origen, por grupo de troncales y por tipo de mensaje. Cuando un SBC detecta que una fuente está enviando mensajes SIP a una tasa que supera los umbrales configurados, puede limitar, desafiar o bloquear esa fuente, sin afectar el tráfico legítimo de otras fuentes.

La ventaja clave de manejar la denegación de servicio en la capa del SBC (en lugar del firewall de red) es el reconocimiento del protocolo. El SBC comprende que una ráfaga de 500 mensajes SIP REGISTER desde una sola IP en 10 segundos es anormal, aunque cada mensaje individual sea una solicitud SIP válida que un firewall dejaría pasar sin cuestionar.

ProSBC incluye reglas de protección contra DoS y DDoS integradas que son configurables por grupo de troncales (NAP). Esta granularidad por NAP significa que puede establecer umbrales agresivos en troncales expuestas al público mientras mantiene límites relajados en conexiones internas de confianza.

Capa 5: prevención de fraude telefónico y spam

El fraude telefónico es el ataque con mayor impacto financiero contra las redes de voz. Los atacantes obtienen acceso a una troncal SIP o PBX (a través de credenciales robadas, secuestro de registros o manipulación de mensajes SIP) y enrutan llamadas a números internacionales de tarifa premium que ellos controlan. La víctima recibe la factura; el atacante cobra la participación en los ingresos del servicio de tarifa premium.

Un SBC combate el fraude telefónico mediante múltiples mecanismos: bloqueo de llamadas a rangos de números de tarifa premium conocidos, imposición de límites de llamadas simultáneas por troncal, detección de patrones de llamadas anormales (como un aumento repentino de tráfico internacional a las 3 AM) e integración con bases de datos externas de detección de fraude para calificación en tiempo real.

La prevención de spam y llamadas automáticas (robocalls) sigue un patrón similar: el SBC consulta bases de datos externas de reputación antes de admitir una llamada, y la enruta o bloquea según la puntuación de riesgo devuelta.

ProSBC aborda el fraude telefónico y el spam a través de varias capacidades integradas. Su API de enrutamiento Ruby configurable permite a los operadores implementar lógica personalizada de detección de fraude que inspecciona más de 100 parámetros de llamada por llamada y se ejecuta antes de que la llamada sea enrutada. Se integra con SecureLogix para la calificación de riesgo de spam, YouMail para la evaluación de riesgo de llamadas automáticas y TransNexus ClearIP para detección de fraude combinada y verificación STIR/SHAKEN. La función de listas grises basadas en porcentaje permite a los operadores limitar el tráfico sospechoso sin bloquearlo completamente, lo cual es útil cuando una fuente es dudosa y bloquear todo el tráfico afectaría a llamantes legítimos.

Ocultación de topología: la función de seguridad silenciosa del SBC

Una de las funciones de seguridad más importantes que proporciona un SBC es también la menos visible: la ocultación de topología. Cada mensaje SIP contiene encabezados Via, Contact y Record-Route que revelan direcciones IP internas, nombres de host y la arquitectura de red. Sin ocultación de topología, un atacante externo puede mapear su red interna simplemente examinando las respuestas SIP.

Una arquitectura de agente de usuario back-to-back (B2BUA) es el habilitador clave de una ocultación de topología efectiva. A diferencia de un proxy SIP, que reenvía mensajes SIP y agrega su propio encabezado Via mientras preserva los encabezados originales, un B2BUA termina completamente la sesión SIP en un lado y origina una sesión completamente nueva en el otro. Esto significa que toda la información de la red interna se elimina y reemplaza antes de que cualquier mensaje SIP salga de la red.

ProSBC implementa una arquitectura B2BUA completa, proporcionando una ocultación de topología total que oculta las direcciones IP de la red interna de las partes externas y viceversa. Esta no es una opción configurable que se pueda dejar desactivada accidentalmente. Es una propiedad inherente del diseño B2BUA.

Seguridad configurable: por qué las reglas estáticas no son suficientes

Las listas de control de acceso estáticas y los límites de tasa fijos eran suficientes cuando las amenazas VoIP eran poco sofisticadas. Las operaciones de fraude telefónico actuales usan direcciones IP rotativas, credenciales SIP de apariencia legítima y patrones de llamadas diseñados para mantenerse justo por debajo de los umbrales de detección estáticos.

Un SBC configurable permite a los operadores implementar lógica de seguridad adaptativa que consulta sistemas externos en tiempo real, aplica reglas personalizadas basadas en el contexto completo de cada llamada y evoluciona a medida que las amenazas cambian, sin requerir actualizaciones de firmware ni tickets de soporte del fabricante.

La API de enrutamiento Ruby de ProSBC proporciona esta configurabilidad a través de una arquitectura de cadena de filtros. Los scripts de enrutamiento extienden una clase base y definen métodos before_filter, after_filter y after_remap_filter que se ejecutan en diferentes etapas del procesamiento de llamadas. Dentro de estos filtros, los operadores pueden consultar servicios HTTP externos (bases de datos de fraude, servicios de reputación de números, sistemas de lógica de negocio internos), inspeccionar cualquiera de los más de 100 parámetros de llamada disponibles para el motor de enrutamiento y tomar decisiones de enrutamiento o bloqueo basadas en los resultados combinados.

Esto significa que un operador de ProSBC puede implementar lógica como: “Para cada llamada desde el NAP ‘carrier-x’ con un destino que coincida con patrones internacionales de tarifa premium, consultar TransNexus ClearIP para obtener una puntuación de fraude. Si la puntuación supera el umbral configurado, bloquear la llamada y registrar el evento. Si la puntuación es moderada, enrutar la llamada pero establecer una duración máxima de 60 segundos.” Este tipo de lógica de decisión contextual y multifuente es imposible solo con ACL estáticas.

STIR/SHAKEN: autenticación de la identidad del llamante en el SBC

La suplantación de identidad del llamante (spoofing) es tanto una amenaza de seguridad como una preocupación regulatoria. STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENS) es el marco de la industria para verificar criptográficamente que el número de la parte llamante no ha sido falsificado.

El SBC desempeña un papel central en STIR/SHAKEN: como SBC de origen, se integra con un servicio de firma para adjuntar un encabezado Identity criptográfico a las llamadas salientes; como SBC de terminación, verifica el encabezado Identity en las llamadas entrantes y toma medidas según el nivel de atestación.

Los tres niveles de atestación indican la relación del proveedor de origen con el llamante: la atestación completa (A) significa que el proveedor autenticó a la parte llamante y está autorizada para usar ese número; la atestación parcial (B) significa que el proveedor sabe de dónde se originó la llamada pero no puede verificar el derecho del llamante a usar el número; la atestación de pasarela (C) significa que la llamada ingresó a la red desde una fuente no confiable.

Para un análisis más profundo sobre la implementación de STIR/SHAKEN, los niveles de atestación y los requisitos de cumplimiento de la FCC, consulte nuestra guía dedicada de STIR/SHAKEN.

Lista de verificación de seguridad del SBC: cómo evaluar un SBC

Al evaluar un SBC para los requisitos de seguridad de su red, utilice esta lista de verificación para garantizar una cobertura integral.

Requisito de seguridad	Qué buscar	ProSBC
SIP sobre TLS	Compatibilidad con TLS 1.2+, configurable por troncal, opción de Mutual TLS (mTLS)	TLS por NAP
SRTP	Compatibilidad nativa con SRTP, conversión RTP a SRTP, modo de retransmisión SRTP	Retransmisión + conversión
Listas de control de acceso	Granularidad por grupo de troncales, basadas en IP y en números, actualizaciones dinámicas	Por NAP + listas grises
Protección DoS/DDoS	Integrada (no como complemento), configurable por troncal, limitación de tasa con reconocimiento SIP	Integrada por NAP
Ocultación de topología	Arquitectura B2BUA completa (no proxy SIP), reescritura total de encabezados	B2BUA completo
Prevención de fraude telefónico	Bloqueo de llamadas internacionales, límites de llamadas simultáneas, detección de patrones	API + integraciones con socios
Configurabilidad	API de scripting para lógica personalizada de enrutamiento/seguridad, consultas a sistemas externos	API de enrutamiento Ruby
STIR/SHAKEN	Compatibilidad con firma y verificación, manejo de niveles de atestación	Vía servicio de firma
Integraciones con terceros	Integraciones nombradas y validadas con socios para detección de fraude/spam	SecureLogix, YouMail, TransNexus
Alta disponibilidad	HA 1+1 sin pérdida de servicio, continuidad de seguridad durante la conmutación por error	ProSBC+ HA 1+1

Seguridad del SBC vs. firewall tradicional: por qué necesita ambos

Una pregunta frecuente en la planificación de seguridad de red es si un firewall con capacidad SIP ALG puede reemplazar a un SBC. La respuesta corta es no. Cumplen funciones complementarias en diferentes capas del stack de red.

Capacidad	Firewall de red	SBC
Filtrado IP/puerto	Configuración global, escalabilidad limitada	Por grupo de troncales
Inspección de mensajes SIP	Solo SIP ALG, sin configurabilidad	Completa, con reconocimiento de capa de aplicación
Manipulación de encabezados SIP	No	Sí
Manejo de medios RTP	No	Sí
Terminación TLS para SIP	No	Sí
Cifrado/descifrado SRTP	No	Sí
Limitación de tasa con reconocimiento SIP	No	Sí
Detección de fraude telefónico	No	Sí
Ocultación de topología (B2BUA)	No	Sí
Negociación de codec	No	Sí
STIR/SHAKEN	No	Sí

La implementación recomendada es defensa en profundidad: el firewall de red maneja los ataques volumétricos a nivel de red y aplica políticas amplias de acceso por IP en las capas de red y transporte, mientras que el SBC se encarga de la seguridad SIP/RTP a nivel de aplicación, las políticas de tráfico y la detección de amenazas específicas de voz. El firewall protege al SBC; el SBC protege la aplicación de voz.

Proteger su red de voz comienza en el perímetro

La seguridad del SBC no es una sola función que se marca en una tabla comparativa de proveedores. Es una arquitectura de defensa multicapa que protege la señalización, los medios, la topología de red y los ingresos del negocio contra distintas categorías de amenaza. Las cinco capas (cifrado de señalización, cifrado de medios, control de acceso, mitigación de DoS/DDoS y prevención de fraude telefónico) funcionan juntas como un stack de defensa en profundidad que ningún firewall tradicional puede replicar.

Las amenazas modernas requieren más que reglas estáticas. Un SBC configurable con consultas a sistemas externos en tiempo real, calificación de fraude por llamada y una cadena de filtros extensible brinda a los operadores la capacidad de adaptar su postura de seguridad a medida que las amenazas evolucionan, sin esperar actualizaciones de firmware del fabricante.