Prevención de ataques DoS SIP: cómo un SBC detiene los ataques de inundación antes de que alcancen su red de voz

En el mundo de la voz, no existe una caída “silenciosa”. Cuando una red se cae, todos lo saben al instante. No hay degradación progresiva ni respaldos en caché a los que recurrir: las llamadas simplemente fallan. Los clientes se encuentran con aire muerto o una señal de ocupado rápida, los centros de contacto se oscurecen y los ingresos se detienen de inmediato. Esta visibilidad total es exactamente lo que convierte a la infraestructura SIP en un objetivo de alto valor para los ataques DoS. Los atacantes saben que inundar una plataforma de voz genera una crisis inmediata y medible, y apuestan a que usted estará mucho más enfocado en restaurar el servicio que en rastrear la fuente.

La escala de la amenaza se está acelerando claramente; Cloudflare reportó haber bloqueado 20.5 millones de ataques DDoS solo en el Q1 de 2025, lo que marca un asombroso aumento del 358 % interanual. La infraestructura VoIP sigue en la mira porque los ataques de inundación SIP están diseñados para explotar la mecánica fundamental del protocolo. Cada INVITE obliga a un servidor a asignar recursos para un diálogo, mientras que cada REGISTER activa una búsqueda de credenciales y los mensajes malformados constantemente prueban la resiliencia del parser. El núcleo del problema es que un firewall de red estándar típicamente ve todo esto como tráfico UDP genérico en un solo puerto, sin ninguna forma real de distinguir una configuración de llamada legítima de un ataque malicioso.

Un controlador de borde de sesión (SBC) es el único elemento de red construido específicamente para inspeccionar, limitar la tasa y bloquear el tráfico SIP en la capa de aplicación. Esta guía cubre cada tipo principal de ataque de inundación SIP, explica cómo un SBC detecta y mitiga cada uno, y proporciona orientación de arquitectura de implementación para construir redes de voz resilientes ante denegación de servicio.

Por qué la infraestructura SIP es especialmente vulnerable

Comprender por qué SIP es un objetivo tan efectivo para DoS requiere analizar el diseño del protocolo. SIP fue construido para la confiabilidad e interoperabilidad en redes confiables, no para entornos adversarios.

SIP es un protocolo basado en texto y con estado. Cada llamada comienza con una transacción INVITE que crea un diálogo, y el servidor debe rastrear el estado de ese diálogo a través de la configuración, el timbre, la respuesta y la finalización. Esa naturaleza con estado significa que cada mensaje entrante consume recursos del servidor: ciclos de CPU para el análisis, memoria para el estado del diálogo y búsquedas en base de datos para el enrutamiento y la autenticación. A diferencia de las solicitudes web sin estado que pueden ser absorbidas por un CDN o balanceador de carga, el estado de llamada SIP es en tiempo real y sensible a la latencia. Incluso unos pocos segundos de retardo en el procesamiento se traducen en llamadas fallidas y registros caídos.

SIP típicamente se ejecuta sobre UDP. Sin el handshake de tres vías de TCP, no hay un mecanismo integrado para verificar que la dirección IP de origen en un paquete SIP sea genuina. La falsificación de IP de origen es trivial, lo que significa que los atacantes pueden generar tráfico de inundación que parece provenir de miles de direcciones diferentes simultáneamente, derrotando la simple limitación de tasa por IP.

El mecanismo de registro agrava el problema. Los terminales SIP (teléfonos, softphones, troncales) deben enviar periódicamente mensajes REGISTER para mantener su conexión. Cada solicitud REGISTER obliga al servidor a buscar credenciales, validarlas y responder. Este procesamiento de autenticación consume mucho CPU y típicamente afecta al componente con más restricciones en la arquitectura: el registrar.

Finalmente, el plano de medios agrega otra superficie de ataque. RTP (Real-time Transport Protocol) transporta el audio de voz real en rangos de puertos asignados dinámicamente, lo que significa que los firewalls deben dejar rangos amplios de puertos abiertos para permitir el paso del tráfico de medios. Esos puertos abiertos se convierten en puntos de entrada para inundaciones de medios que consumen ancho de banda y capacidad de procesamiento sin establecer nunca una llamada legítima.

La combinación de manejo de llamadas con estado, transporte UDP, autenticación que consume muchos recursos y asignación dinámica de puertos convierte a la infraestructura SIP en un objetivo ideal para denegación de servicio.

Los cuatro tipos de ataques de inundación SIP

Los ataques de denegación de servicio SIP se clasifican en cuatro categorías, cada una explotando un aspecto diferente del protocolo. Una defensa efectiva debe abordar las cuatro.

Inundaciones INVITE

Una inundación INVITE es el ataque DoS SIP más común. El atacante envía volúmenes masivos de mensajes SIP INVITE al objetivo, cada uno solicitando que el servidor configure una nueva llamada.

Cada INVITE obliga al servidor receptor a analizar los encabezados SIP, buscar reglas de enrutamiento, asignar memoria para un diálogo de llamada e intentar reenviar la solicitud al siguiente salto. Incluso si las llamadas nunca se completan (y en un ataque, típicamente no lo hacen), el procesamiento de transacciones para cada INVITE consume CPU y memoria. A un volumen suficiente, el servidor agota su capacidad de procesamiento y ya no puede manejar las solicitudes legítimas de configuración de llamadas.

Las inundaciones INVITE son particularmente efectivas porque los servidores SIP están diseñados para ser generosos con los recursos durante la configuración de llamadas. El protocolo asume que si llega un INVITE, un llamante real está esperando. No hay una forma ligera de rechazar un INVITE sin al menos procesarlo parcialmente.

Cuando las IP de origen son falsificadas (lo cual es común sobre UDP), el bloqueo simple por IP se vuelve inefectivo porque el ataque parece provenir de miles de direcciones únicas.

El impacto es inmediato: los llamantes legítimos reciben señales de ocupado, escuchan silencio u obtienen errores de tiempo de espera. Si el objetivo es una troncal SIP que conecta a una empresa con su operador, todas las llamadas entrantes y salientes de esa organización se detienen.

Inundaciones REGISTER

Una inundación REGISTER apunta al subsistema de autenticación. El atacante envía altos volúmenes de solicitudes SIP REGISTER, típicamente con credenciales aleatorias o inválidas, al SBC o registrar.

Cada mensaje REGISTER obliga al servidor a realizar una búsqueda de credenciales y un ciclo de desafío/respuesta de autenticación. Esto es computacionalmente más costoso por mensaje que el procesamiento de INVITE porque involucra consultas a la base de datos y, en muchas implementaciones, el cálculo de autenticación digest.

Las inundaciones REGISTER pueden tener un doble propósito: el objetivo principal es el agotamiento de recursos (negar el servicio a los usuarios legítimos que intentan registrarse), pero la inundación puede funcionar simultáneamente como un ataque de relleno de credenciales si se incluyen nombres de usuario reales con contraseñas de fuerza bruta.

El impacto apunta específicamente al plano de registro. Los terminales legítimos que no pueden registrarse pierden su presencia en la red, lo que significa que no pueden recibir llamadas entrantes y pueden no poder realizar llamadas salientes. Para las organizaciones con trabajadores remotos que dependen del registro SIP para la conectividad de softphones, una inundación REGISTER puede desconectar silenciosamente a toda la fuerza laboral remota.

Inundaciones OPTIONS y BYE

Los mensajes SIP OPTIONS son sondas de keepalive ligeras. Se espera que los servidores respondan rápidamente, convirtiéndolos en un vector eficiente para el agotamiento de recursos con mínimo esfuerzo del atacante. Una inundación OPTIONS puede no hacer que un servidor colapse directamente, pero degrada el rendimiento al consumir capacidad de procesamiento de transacciones que de otro modo manejaría llamadas reales.

Las inundaciones BYE son más dirigidas y más disruptivas. Al enviar mensajes BYE falsificados que hacen referencia a identificadores de diálogos de llamadas activas, un atacante puede desconectar llamadas legítimas en curso. Si el atacante puede observar o adivinar los valores de Call-ID (que a veces son predecibles), puede desconectar selectivamente llamadas específicas o barrer un rango de valores posibles para interrumpir todas las sesiones activas.

Las inundaciones OPTIONS causan degradación gradual del rendimiento. Las inundaciones BYE causan desconexiones de llamadas activas, que son visibles para los usuarios finales inmediatamente y pueden confundirse con inestabilidad de la red en lugar de un ataque activo.

Ataques de mensajes SIP malformados

En lugar de abrumar al servidor con volumen, los ataques de mensajes malformados apuntan al parser SIP en sí. El atacante envía mensajes SIP con encabezados deliberadamente rotos, campos sobredimensionados, codificaciones de caracteres inválidas o estructuras sintácticamente imposibles.

El objetivo es activar una vulnerabilidad del parser: un desbordamiento de búfer, una fuga de memoria, una excepción no manejada o un comportamiento indefinido en el stack SIP. Si el parser colapsa, todo el servicio SIP se cae. Incluso si no colapsa, un parser que consume recursos excesivos al intentar procesar entradas malformadas puede ser explotado para un ataque DoS de bajo volumen que evade la limitación de tasa por completo.

Esta categoría incluye ataques de “fuzzing” donde herramientas automatizadas generan miles de variaciones de mensajes malformados para descubrir errores explotables del parser. Una sola carga útil de fuzzing exitosa puede ser más dañina que una inundación volumétrica porque puede requerir solo un mensaje para hacer colapsar al objetivo.

El impacto va desde la inestabilidad del servicio (fugas de memoria causando degradación gradual) hasta la falla completa del servicio (colapso del parser) hasta posibles brechas de seguridad si la vulnerabilidad del parser permite la ejecución de código.

Cómo un SBC detiene los ataques de inundación SIP

Un SBC proporciona cinco mecanismos distintos de detección y mitigación para ataques DoS SIP. Estos mecanismos operan en diferentes capas y se complementan entre sí para crear una postura de defensa en profundidad.

Limitación de tasa con reconocimiento SIP

La protección DoS más fundamental del SBC es la limitación de tasa en la capa de aplicación con comprensión de los tipos de mensajes SIP. A diferencia de un firewall, que solo puede limitar el tráfico por dirección IP y número de puerto, un SBC puede establecer límites de tasa independientes para cada método SIP.

Esto significa que un operador puede configurar umbrales separados para mensajes INVITE, mensajes REGISTER, mensajes OPTIONS y otros métodos SIP. Una troncal de operador legítima podría enviar 500 INVITE por segundo durante las horas pico, pero nunca debería enviar 500 REGISTER por segundo. La limitación de tasa con reconocimiento SIP puede bloquear la inundación REGISTER mientras permite que el tráfico INVITE fluya normalmente.

Los límites de tasa se pueden aplicar en múltiples alcances. Los límites por IP de origen limitan el tráfico de cualquier dirección de origen individual. Los límites por grupo de troncales (configurados por punto de acceso de red en ProSBC) limitan el tráfico total de cada conexión de operador independientemente de la distribución de IP de origen. Los límites globales protegen la propia capacidad de procesamiento del SBC como último recurso.

La ventaja clave sobre la limitación de tasa en la capa de red es la precisión. Un firewall que limita todo el tráfico UDP al puerto 5060 bloqueará llamadas legítimas junto con el tráfico de ataque. Un SBC que limita solo los mensajes REGISTER de fuentes no confiables mientras permite el tráfico INVITE de pares de operadores conocidos preserva el servicio durante un ataque.

Validación de protocolo y filtrado de mensajes

Cada mensaje SIP que llega al SBC pasa por un motor de validación de protocolo antes de que se le permita alcanzar el núcleo de procesamiento de llamadas. El SBC verifica el mensaje contra la especificación SIP (RFC 3261 y estándares relacionados), verificando que los encabezados estén correctamente formados, que los campos obligatorios estén presentes, que las longitudes de los campos estén dentro de los límites y que la estructura general del mensaje sea sintácticamente válida.

Los mensajes que fallan la validación se descartan inmediatamente. Nunca alcanzan el motor de procesamiento de llamadas, la lógica de enrutamiento ni el registrar. Esto elimina toda la clase de ataques de mensajes malformados y explotación de parsers en una sola capa.

Más allá de la validación estricta, el motor de normalización SIP del SBC puede corregir problemas comunes de formato de terminales legítimos pero no conformes. Esta doble función, rechazar la malformación maliciosa mientras corrige la no conformidad benigna, significa que la capa de validación mejora tanto la seguridad como la interoperabilidad simultáneamente.

Listas de bloqueados dinámicas y clasificación de confianza

Las listas de control de acceso (ACL) estáticas son un punto de partida, pero requieren mantenimiento manual y no pueden responder a los ataques en tiempo real. Las listas de bloqueados dinámicas automatizan la respuesta.

El SBC monitorea los patrones de tráfico de cada IP de origen en tiempo real. Cuando una fuente supera los umbrales configurados (por ejemplo, 50 intentos fallidos de REGISTER en 10 segundos, o 200 INVITE por segundo sin llamadas completadas), el SBC agrega automáticamente esa fuente a una lista de bloqueados. El tráfico posterior de la fuente bloqueada se descarta en la capa de red sin consumir recursos de procesamiento en la capa de aplicación.

ProSBC extiende esto con listas grises basadas en porcentaje. En lugar de tomar una decisión binaria de bloqueo/permiso, un operador puede configurar el SBC para pasar solo un porcentaje del tráfico de una fuente sospechosa. Por ejemplo, bloqueando el 90 % del tráfico de un rango de IP mientras permite el paso del 10 % para monitoreo. Esto es particularmente útil durante la fase de investigación de un DDoS sospechado, cuando el operador aún no tiene certeza de si la fuente de tráfico es maliciosa o un operador legítimo que experimenta un pico de tráfico.

La clasificación de confianza agrega otra capa. Los pares de operadores conocidos pueden clasificarse como confiables, recibiendo límites de tasa más altos y omitiendo ciertas verificaciones. Las fuentes desconocidas o de Internet público se clasifican como no confiables y están sujetas a un escrutinio más estricto. El SBC puede reclasificar dinámicamente las fuentes según su comportamiento, promoviendo las fuentes que se comportan bien y degradando las abusivas.

Protección contra escaneo de registros SIP

Las inundaciones de registro merecen detección dedicada debido a su impacto desproporcionado en el subsistema de autenticación. ProSBC incluye un motor de protección contra escaneo de registros SIP construido específicamente que monitorea el tráfico REGISTER de forma específica.

Este motor distingue entre el comportamiento de registro legítimo (periódico, con temporización predecible, credenciales válidas) y los patrones de ataque (tráfico en ráfagas, intentos secuenciales de credenciales, nombres de usuario aleatorios o inválidos). Los terminales SIP legítimos se re-registran a intervalos configurados (típicamente de 60 a 3600 segundos) con credenciales consistentes. Los escáneres de registro y las herramientas de inundación generan ráfagas de mensajes REGISTER con credenciales variadas o secuenciales a tasas que ningún terminal legítimo produciría.

Cuando el motor de detección identifica un patrón de escaneo o inundación de registros, bloquea la fuente antes de que el tráfico alcance al registrar. Esto protege al componente con más restricciones de recursos en la arquitectura sin afectar el tráfico de registro legítimo de terminales conocidos.

Ocultación de topología como prevención de DoS

La ocultación de topología se discute frecuentemente como una función de privacidad o seguridad, pero también es un mecanismo directo de prevención de DoS.

Un SBC que opera como agente de usuario back-to-back (B2BUA) termina cada sesión SIP en el lado externo y reorigina una nueva sesión en el lado interno. Las partes externas nunca ven las direcciones IP, nombres de host o la topología de red de los servidores SIP internos, pasarelas de medios o sistemas PBX.

Esto importa para la prevención de DoS porque un atacante no puede apuntar a lo que no puede ver. Sin el SBC, un atacante que descubre la dirección IP de una PBX o registrar interno puede inundarlo directamente, evitando cualquier defensa perimetral. Con el SBC en modo B2BUA, todo el tráfico externo termina en el propio SBC, y la infraestructura interna es arquitectónicamente inalcanzable desde Internet.

La arquitectura B2BUA completa de ProSBC (no un proxy SIP ligero) crea una separación total en el diálogo SIP entre las redes externa e interna. Los mensajes SIP en el lado interno son transacciones completamente nuevas generadas por el SBC, no copias reenviadas de mensajes externos. Un atacante que inunda la interfaz externa del SBC no puede inyectar mensajes malformados o solicitudes BYE falsificadas en los tramos de llamada internos porque esos tramos son sesiones SIP independientes controladas enteramente por el SBC.

Por qué un firewall de red no puede reemplazar a un SBC para la protección DoS SIP

Los firewalls de red y los SBC cumplen roles complementarios, y ninguno reemplaza al otro. La distinción importa porque las organizaciones que dependen solo de un firewall para la seguridad VoIP tienen una brecha significativa en su defensa contra DoS.

Un firewall opera en la capa de red (capa 3) y la capa de transporte (capa 4). Puede filtrar por dirección IP de origen y destino, tipo de protocolo y número de puerto. Puede aplicar límites de tasa al volumen total de tráfico de una fuente dada. Algunos firewalls ofrecen una función de SIP Application Layer Gateway (ALG), pero los SIP ALG son ampliamente conocidos por causar problemas significativos en las redes de voz: reescribiendo encabezados SIP de formas que rompen los flujos de llamadas, interfieren con el recorrido de NAT y producen enrutamiento impredecible. La mayoría de los ingenieros VoIP desactivan el SIP ALG como primer paso de resolución de problemas.

Lo que un firewall no puede hacer es inspeccionar los mensajes SIP en la capa de aplicación. No puede distinguir un INVITE legítimo de un ataque de inundación. No puede limitar la tasa de mensajes REGISTER independientemente de los mensajes INVITE. No puede detectar que un mensaje SIP está malformado de una manera diseñada para explotar una vulnerabilidad del parser. No puede identificar patrones de escaneo de registros. No puede ocultar la topología de red interna del reconocimiento a nivel SIP.

La arquitectura correcta utiliza ambos. Un firewall (o servicio de depuración DDoS aguas arriba) maneja los ataques volumétricos de capa 3/4: inundaciones TCP SYN, ataques de amplificación UDP, inundaciones ICMP. El SBC maneja los ataques SIP en la capa de aplicación que pasan a través de la capa de red sin ser detectados porque usan direcciones IP válidas, puertos válidos y paquetes UDP correctamente formados.

Para implementaciones en la nube, este modelo por capas funciona particularmente bien. Los proveedores de nube como AWS y Azure incluyen protección DDoS en la capa de red como parte de su infraestructura. Un SBC que se ejecuta en esas plataformas se beneficia automáticamente de ese escudo en la capa de red, y luego agrega protección SIP en la capa de aplicación encima, cubriendo ambas categorías de ataque sin requerir que el operador construya infraestructura de mitigación DDoS separada.

Implementación de un SBC para máxima protección DoS

La prevención efectiva de DoS no es solo un conjunto de funciones. También depende de dónde y cómo se implementa el SBC.

El SBC debe ubicarse en el perímetro de la red, entre las conexiones que dan a Internet o a los operadores y la infraestructura de voz interna. Cada conexión SIP externa debe terminar en el SBC. Los sistemas PBX internos, los registrars, los servidores de medios y los puentes de conferencia deben estar en un segmento de red separado sin exposición directa a Internet. Si un servidor SIP interno tiene una dirección IP pública que las partes externas pueden alcanzar directamente, la protección DoS del SBC se evita por completo para ese servidor.

La alta disponibilidad importa para la resiliencia ante DoS. Una configuración de SBC activo/en espera 1+1 (como la opción HA de ProSBC) garantiza que si un nodo SBC es sobrecargado o requiere un reinicio, el nodo en espera asume. Esto previene que un ataque DoS se convierta en una interrupción total de voz. Para implementaciones de nivel operador, el SBC debe admitir suficiente capacidad de sesiones para absorber picos de tráfico sin alcanzar los límites de recursos en condiciones normales. ProSBC admite hasta 60 000 sesiones simultáneas por servidor y 350 000 registros de terminales, proporcionando un margen significativo por encima de las cargas operativas típicas.

Para las organizaciones que enfrentan campañas DDoS persistentes o sofisticadas, la distribución geográfica agrega otra capa. Implementar instancias de SBC en múltiples regiones o zonas de disponibilidad significa que un ataque dirigido a un punto geográfico no afecta a los demás. Combinado con balanceo de carga basado en DNS o redireccionamiento SIP, el tráfico puede desviarse del SBC bajo ataque hacia instancias saludables.

El punto de integración entre la defensa en la capa de red y en la capa de aplicación merece atención específica. Si utiliza un servicio de depuración DDoS aguas arriba (Cloudflare, AWS Shield o similar), ese servicio maneja los ataques volumétricos en el perímetro de la red. El SBC maneja los ataques específicos de SIP que el servicio de depuración deja pasar porque parecen tráfico UDP legítimo. Este modelo de dos niveles proporciona cobertura integral: el servicio de depuración absorbe el ataque de ancho de banda bruto, y el SBC filtra el ataque en la capa de aplicación que sobrevive.

Preguntas frecuentes