Amenazas de seguridad VoIP y cómo los SBC protegen su red de voz

Las redes de voz transportan mucho más que conversaciones. Cada mensaje SIP que atraviesa la infraestructura contiene credenciales de autenticación, datos de facturación, identidad del llamante e indicios de topología integrados en los encabezados del protocolo. Para un atacante, una red de voz comprometida es un objetivo de alto valor, y muchas implementaciones en producción aún se defienden como si el tráfico SIP fuera UDP genérico.

Los números cuentan la misma historia. Los ataques de vishing aumentaron un 442% entre el primer y el segundo semestre de 2024 a medida que la síntesis de voz con AI cerró la brecha en la suplantación basada en identidad. El fraude de peaje continúa drenando más de USD 6 mil millones por año a nivel global según la Communications Fraud Control Association. Los exploits a nivel de protocolo que permiten la toma de control remota de teléfonos VoIP mediante mensajes SIP malformados se documentan regularmente en la base de datos CVE, con campañas activas dirigidas a endpoints Grandstream, Cisco y Yealink solo en los últimos 18 meses.

Los firewalls de red por sí solos no detienen ninguno de estos ataques de manera efectiva. Inspeccionan paquetes en las capas 3 y 4 y no tienen un modelo de SIP, RTP ni de los patrones de ataque específicos de voz construidos sobre ellos. Un Session Border Controller se ubica en el borde de la red con visibilidad completa de SIP y RTP, lo que lo convierte en el dispositivo que detecta, mitiga y bloquea las siete clases de ataque que se cubren en este artículo.

Por qué un firewall de red no es suficiente

Los firewalls operan en las capas 3 y 4: direcciones IP, puertos de transporte y encabezados de paquetes. Para un firewall, el tráfico VoIP es simplemente UDP en los puertos 5060 y 5061. El firewall no puede distinguir un SIP INVITE legítimo de una inundación, detectar patrones de fraude de peaje en las decisiones de enrutamiento ni identificar una identidad de llamante falsificada en el encabezado From.

Los ataques SIP viven en la capa de aplicación. Están integrados en encabezados y cuerpos de mensaje que un firewall de red nunca inspecciona. Una inundación de SIP REGISTER puede consistir en mensajes SIP perfectamente válidos transportados sobre UDP, TCP o TLS, y el firewall deja pasar cada uno. Un SBC detecta la tasa de registro anormal desde una fuente y la bloquea antes de que llegue al registrar. La guía detallada de prevención de ataques SIP DoS recorre cada tipo de inundación y la limitación de tasa a nivel de aplicación que los detiene.

El manejo de medios crea la segunda brecha. Los flujos RTP utilizan rangos de puertos negociados dinámicamente que a menudo abarcan miles de puertos UDP. Los firewalls abren el rango completo (gran superficie de ataque) o dependen de un SIP ALG para rastrear la negociación de medios (conocido por interrumpir los flujos de llamadas). Un SBC ancla los medios en puertos controlados como B2BUA, de modo que las rutas internas de medios nunca se exponen externamente. La guía de seguridad del SBC cubre cada capa de defensa con patrones de configuración.

Firewall vs SBC de un vistazo

Capacidad	Firewall tradicional	Session Border Controller
Inspección de mensajes SIP	Solo ve UDP	Análisis SIP completo
Control de ruta de medios	Pinhole de rango de puertos	Relay de medios anclado
Ocultamiento de topología		Nativo del B2BUA
Limitación de tasa por llamada		Por origen, troncal y método
Detección de fraude de peaje		Enrutamiento programable con puntuación
Terminación de cifrado	Solo paso transparente	TLS y SRTP por tramo
Normalización de protocolo		Motor de manipulación de encabezados SIP
Verificación de identidad del llamante		Firma y verificación STIR/SHAKEN

Siete amenazas críticas de seguridad VoIP

Los ataques a continuación son los que los ingenieros de red y los equipos de seguridad realmente encuentran en entornos de voz en producción. Cada uno explota una debilidad específica en la infraestructura VoIP, y cada uno tiene una defensa específica del SBC.

1. Fraude de peaje (toll fraud)

Un atacante compromete credenciales SIP mediante registro por fuerza bruta, ingeniería social o un relay abierto, y luego las utiliza para enrutar llamadas internacionales a números de tarifa premium que el atacante controla. El atacante cobra ingresos del servicio de tarifa premium. El operador factura a la víctima, a menudo por decenas de miles de dólares antes de que cierre el siguiente ciclo de facturación.

Las variantes incluyen el fraude de compartición de ingresos internacionales (IRSF), donde el atacante tiene una relación de compartición de ingresos con el proveedor del número de tarifa premium; el hackeo de PBX contra sistemas IP-PBX mal configurados o sin parches; y los esquemas wangiri (un timbre) que marcan automáticamente miles de números y esperan devoluciones de llamada a un destino de tarifa premium. El fraude de peaje se desarrolla en minutos. Un atacante puede generar miles de dólares en llamadas fraudulentas en una hora, mientras que las facturas del operador llegan semanas después y las devoluciones de cargos son difíciles de obtener.

Un SBC correctamente configurado inspecciona cada llamada antes de enrutarla. El enrutamiento programable examina más de 100 parámetros por llamada, incluyendo IP de origen, número llamante, número llamado, país de destino, hora del día y conteo de llamadas concurrentes. Los límites de llamadas concurrentes por troncal evitan que un atacante ejecute cientos de sesiones simultáneas. El bloqueo de destinos internacionales restringe las llamadas a rangos de tarifa premium. La integración con servicios de puntuación de fraude como TransNexus ClearIP y SecureLogix evalúa la puntuación de riesgo de cada llamada antes de que se conecte, bloqueando las llamadas de alto riesgo en el borde de la red antes de que se acumulen cargos.

2. Ataques de inundación SIP (DoS y DDoS)

Un atacante envía volúmenes masivos de mensajes SIP INVITE, REGISTER u OPTIONS para sobrecargar la capacidad de procesamiento de la plataforma de voz. Las llamadas legítimas no pueden conectarse, los registros existentes no se renuevan y la red experimenta una interrupción completa del servicio de voz. Las inundaciones volumétricas saturan el ancho de banda con volumen bruto de paquetes. Las inundaciones específicas de protocolo apuntan al motor de procesamiento SIP con mensajes malformados o computacionalmente costosos. Los ataques distribuidos generan tráfico desde miles de IPs de origen simultáneamente, haciendo que el bloqueo simple por IP sea ineficaz.

La limitación de tasa con reconocimiento SIP opera en múltiples niveles al mismo tiempo: por IP de origen, por grupo de troncales y por tipo de mensaje SIP. Esta granularidad significa que el SBC puede detectar que una sola IP está enviando 500 mensajes REGISTER por segundo mientras permite que el tráfico de registro normal de otras fuentes continúe sin afectación. La validación de protocolo descarta los paquetes SIP malformados antes de que lleguen al motor de procesamiento de llamadas, neutralizando las inundaciones específicas de protocolo. La lista negra dinámica bloquea automáticamente las fuentes infractoras cuando superan los umbrales configurados, con greylisting basado en porcentaje para respuesta graduada. La protección contra escaneo de registro SIP está diseñada específicamente para detectar y bloquear ataques de inundación de registro, uno de los vectores de DDoS VoIP más comunes.

3. Interceptación y escucha de llamadas

La señalización SIP sin cifrar (puerto UDP 5060) y los flujos de medios RTP son legibles por cualquier persona con acceso a la ruta de red entre los endpoints. El contenido expuesto incluye el audio completo de la llamada, las identidades del llamante y del llamado, las credenciales SIP transmitidas durante el registro y los tonos DTMF que frecuentemente transportan contraseñas, números de tarjetas de crédito y PINs. Las herramientas de captura de paquetes disponibles gratuitamente pueden extraer audio de voz inteligible de flujos RTP sin cifrar en segundos.

El SBC aplica cifrado tanto en el plano de señalización como en el de medios. SIP sobre TLS en el puerto 5061 cifra todo el tráfico de señalización, previniendo la interceptación de metadatos de llamada, credenciales e información de enrutamiento. SRTP cifra el flujo de medios, haciendo que el audio capturado sea ininteligible. El SBC también realiza conversión de RTP a SRTP: acepta RTP sin cifrar de endpoints legacy que no pueden cifrar nativamente y lo recifra hacia el destino. Esto significa que las conexiones externas pueden asegurarse de inmediato sin reemplazar cada endpoint interno. La guía de configuración de TLS y SRTP del SBC detalla los patrones de implementación.

4. Suplantación de identificador de llamadas y llamadas automatizadas

El diseño de SIP permite cualquier valor en el encabezado From. No existe autenticación integrada de la identidad del llamante. Los atacantes explotan esto para falsificar el identificador de llamadas, haciéndose pasar por bancos, agencias gubernamentales, proveedores de salud o contactos conocidos. La síntesis de voz con AI ha hecho estos ataques drásticamente más convincentes, ya que los atacantes ahora pueden clonar la voz de una persona específica a partir de unos pocos segundos de audio de muestra.

La escala es asombrosa. Miles de millones de llamadas automatizadas se realizan cada mes solo en Estados Unidos. El mandato STIR/SHAKEN de la FCC existe específicamente para abordar este problema al requerir autenticación criptográfica de la identidad del llamante en el proveedor originador.

El SBC implementa STIR/SHAKEN en el borde de la red. Para las llamadas originadas, se integra con un servicio de firma externo para crear tokens PASSporT (aserciones criptográficas de la identidad del llamante) e inyecta el encabezado Identity en el mensaje SIP. El SBC asigna niveles de atestación A (autenticación completa), B (parcial) o C (gateway) según cuánto sabe el proveedor de servicio sobre el llamante. Para las llamadas terminadas, el SBC valida los encabezados Identity entrantes verificando la firma digital contra el certificado del proveedor originador. La integración con servicios de puntuación de spam como SecureLogix y YouMail proporciona verificaciones de reputación en tiempo real sobre los identificadores de llamadas entrantes.

5. Exposición de topología y reconocimiento de red

Los mensajes SIP naturalmente contienen encabezados Via, Contact y Record-Route que revelan direcciones IP internas, nombres de host de servidores, arquitectura de red y versiones de software. Los atacantes utilizan esta información para reconocimiento: mapear la topología interna antes de lanzar ataques dirigidos contra servidores específicos o explotar vulnerabilidades conocidas en las versiones de software identificadas.

Un SBC construido sobre una arquitectura Back-to-Back User Agent (B2BUA) proporciona ocultamiento de topología inherente. Un proxy SIP reenvía mensajes y preserva las cadenas de encabezados (incluyendo detalles de la red interna), mientras que un B2BUA termina la sesión SIP completamente en un lado y origina una sesión completamente nueva en el otro. Cada encabezado SIP se reconstruye desde cero. Las direcciones IP internas, nombres de host y nombres de servidores nunca aparecen en los mensajes enviados a partes externas. El ocultamiento de topología es inherente al modelo de procesamiento B2BUA porque los mensajes SIP salientes se reconstruyen en lugar de reenviarse de forma transparente. La configuración adecuada sigue siendo necesaria para evitar exponer información a través de encabezados opcionales o personalizados.

6. Secuestro de registro (registration hijacking)

Un atacante registra su propio dispositivo con el registrar SIP usando credenciales robadas o obtenidas por fuerza bruta. El registrar actualiza su tabla de vinculaciones y el dispositivo del usuario legítimo deja de recibir llamadas. El dispositivo del atacante las recibe en su lugar. En ataques más sofisticados, el atacante se registra con una prioridad más alta, causando que las nuevas llamadas se enruten hacia él mientras el dispositivo legítimo permanece registrado pero inalcanzable.

La protección contra escaneo de registro SIP detecta patrones de registro anormales: intentos en ráfaga desde una sola fuente, intentos usando credenciales secuenciales o basadas en diccionario, o registros simultáneos para el mismo usuario desde diferentes ubicaciones. Los límites de tasa de registro por troncal evitan que los intentos de fuerza bruta superen los umbrales seguros. Las listas de control de acceso restringen qué direcciones IP y redes tienen permitido registrarse a través de cada grupo de troncales. La integración con RADIUS proporciona verificación y autorización centralizada de credenciales, de modo que los intentos de registro se autentican contra un backend confiable en lugar de aceptarse basándose solo en credenciales a nivel SIP.

7. Explotación del protocolo SIP

Los atacantes crean mensajes SIP malformados diseñados para explotar vulnerabilidades de análisis en equipos VoIP: desbordamientos de búfer, inyección de encabezados, inyección SQL a través de encabezados SIP o errores lógicos en las máquinas de estado SIP. Estos ataques apuntan al motor de procesamiento SIP en sí mismo, con el potencial de ejecución remota de código, caídas del servicio o acceso administrativo no autorizado. Los CVE recientes contra endpoints Grandstream, Cisco y Yealink demuestran que estas vulnerabilidades se descubren y explotan activamente en producción.

La arquitectura B2BUA es nuevamente la defensa crítica. Debido a que el SBC analiza y reconstruye completamente cada mensaje SIP, la entrada malformada se corrige a través del motor de manipulación de encabezados SIP, que normaliza los mensajes no estándar, o se descarta mediante la validación de protocolo que rechaza los mensajes que violan los estándares SIP. Las implementaciones B2BUA correctamente configuradas evitan que los sistemas internos vean el mensaje SIP malformado original directamente; reciben solo la reconstrucción limpia y validada del SBC. Un proxy SIP o un firewall dejaría pasar el mensaje malformado al sistema de destino.

Defensa en profundidad: cinco capas de protección

Ningún mecanismo de seguridad individual detiene todos los ataques VoIP. El fraude de peaje es un problema de la capa de enrutamiento. La interceptación es un problema de la capa de transporte. La suplantación es un problema de la capa de identidad. El DoS es un problema de la capa de capacidad. La explotación de protocolo es un problema de la capa de análisis. Cada vector de ataque requiere su propia defensa, y cada defensa captura amenazas que las demás no detectan.

Una postura de seguridad efectiva del SBC opera como cinco capas concéntricas, cada una abordando una superficie de ataque diferente en lugar de duplicar la que está debajo.

La capa 1 cubre el cifrado mediante TLS para la señalización SIP y SRTP para los medios. La capa previene la interceptación y el robo de credenciales para que, incluso si un atacante obtiene acceso a la red, el tráfico capturado sea ininteligible.

La capa 2 cubre el control de acceso mediante ACL y listas negras de IP. La capa restringe quién puede enviar tráfico a su infraestructura de voz, bloqueando actores maliciosos conocidos y fuentes no autorizadas antes de que consuman recursos de procesamiento.

La capa 3 cubre la mitigación de DoS y DDoS mediante limitación de tasa con reconocimiento SIP y listas negras dinámicas. La capa previene que los ataques de inundación volumétrica y específicos de protocolo sobrecarguen la capacidad de procesamiento de llamadas.

La capa 4 cubre la detección de fraude mediante enrutamiento programable e inspección por llamada. La capa evalúa cada llamada en tiempo real y bloquea el fraude de peaje, IRSF y el abuso de tarifa premium antes de que se incurran cargos.

La capa 5 cubre la verificación de identidad mediante firma y verificación STIR/SHAKEN, más integración opcional con servicios de puntuación de spam. La capa autentica la identidad del llamante y filtra las llamadas automatizadas, abordando los ataques de suplantación e ingeniería social que evaden las defensas puramente técnicas.

Las cinco capas son complementarias, no redundantes. Un atacante que evade el cifrado (quizás a través de un endpoint interno comprometido) aún enfrenta el control de acceso. Un atacante que pasa el control de acceso usando credenciales válidas aún enfrenta la detección de fraude. Un atacante cuyo identificador de llamadas sobrevive la verificación STIR/SHAKEN (un número legítimo usado maliciosamente) aún puede ser detectado por la puntuación de fraude conductual. La guía de seguridad del SBC cubre cada capa con ejemplos de configuración de implementación.

Qué buscar en una solución de seguridad SBC

Al evaluar SBC para la seguridad de redes de voz, las capacidades a continuación separan las soluciones adecuadas de las integrales.

• Soporte nativo de TLS y SRTP, incluyendo conversión de RTP a SRTP para entornos mixtos, no solo paso transparente.
• Granularidad de control de acceso por troncal para que cada conexión de operador aplique sus propias políticas de seguridad de forma independiente. Una sola política global no puede considerar los diferentes niveles de confianza de diferentes pares.
• Enrutamiento programable para lógica de fraude personalizada, porque las tablas de rutas estáticas no pueden detectar patrones de fraude sofisticados. Busque un SBC que le permita escribir lógica de inspección personalizada que se ejecute antes del enrutamiento, con acceso al conjunto completo de parámetros de llamada.
• Firma y verificación STIR/SHAKEN con la flexibilidad de integrarse con el servicio de firma de su elección, sin estar limitado al ecosistema de un solo proveedor.
• Integración con servicios de seguridad de terceros mediante la capacidad de consultar servicios externos de puntuación de fraude, detección de spam y reputación en tiempo real durante el establecimiento de la llamada.
• Protección integrada contra DoS y DDoS sin requerir un dispositivo separado o licenciamiento adicional. La mitigación de DoS debe ser una capacidad inherente, no un complemento.
• Ocultamiento de topología B2BUA completo que sea arquitectónico en lugar de configurable. El ocultamiento de topología configurable puede configurarse incorrectamente; el ocultamiento de topología inherente al B2BUA no puede desactivarse accidentalmente.
• Monitoreo y alertas en tiempo real para visibilidad de amenazas activas, ataques bloqueados y anomalías de tráfico. Seguridad sin observabilidad es seguridad sin conciencia situacional.

Para implementaciones sin capacidad dedicada de ingeniería SBC, un servicio de SBC gestionado cubre la configuración, las operaciones del día a día y el soporte 24×7 mientras preserva la misma programabilidad para lógica de fraude e integración STIR/SHAKEN.

Dónde encaja ProSBC

ProSBC cubre las capacidades del SBC enumeradas anteriormente en un producto de software que se ejecuta en AWS, Azure, VMware, KVM, Proxmox o bare metal. La arquitectura B2BUA maneja TLS y SRTP por tramo, normalización SIP completa, limitación de tasa por NAP y listas negras dinámicas con greylisting basado en porcentaje, protección contra escaneo de registro SIP y ocultamiento de topología arquitectónico sin carga de configuración.

La API de enrutamiento Ruby es donde reside la capa de detección de fraude. Las integraciones validadas con TransNexus ClearIP, SecureLogix y YouMail se ejecutan como filtros en la cadena de enrutamiento, consultando cada servicio durante el establecimiento de la llamada y aplicando decisiones de enrutamiento basadas en puntuación de riesgo, nivel de atestación o reputación de spam. La firma y verificación STIR/SHAKEN funcionan a través de integraciones abiertas con socios, ya sea TransNexus ClearIP o Neustar, configuradas por llamada en lugar de como una sola política de atestación estática.

ProSBC escala hasta 60,000 sesiones por servidor y soporta hasta 1,024 NAPs para implementaciones multi-tenant. Los precios comienzan desde tan solo USD 1.40 por sesión por año en suscripción, con una prueba gratuita de 30 días para evaluación comercial y una licencia permanente de ProSBC Lab que proporciona tres sesiones concurrentes para pruebas y trabajo de integración.

Preguntas frecuentes