VitalPBX + SBC: protección de la infraestructura de voz

VitalPBX es una empresa de software con sede en Panamá y Estados Unidos cuya IP-PBX funciona sobre Linux y Asterisk, y se comercializa bajo un modelo freemium con un nivel Enterprise de pago y una edición Multi-Tenant para ISP y MSP. Está desplegada en más de 100 países, con una adopción especialmente fuerte en hotelería, centros de contacto, educación y empresas pequeñas y medianas. La interfaz web de VitalPBX y sus complementos Sonata Suite (Sonata Switchboard para recepcionistas, Sonata Recording para captura de llamadas con cumplimiento normativo, Sonata Stats para analítica de colas y Sonata Dialer para campañas de salida) se apoyan sobre Asterisk, ofreciendo a los operadores una plataforma telefónica completa sin necesidad de escribir código de dial-plan.

VitalPBX también es un cliente de larga data de TelcoBridges. Ante la misma economía de escáneres SIP que ataca a todo despliegue de Asterisk expuesto a internet, VitalPBX seleccionó ProSBC para su propio sistema interno y lo recomendó a su canal de distribución. El cofundador y CEO Rodrigo Cuadra resumió la decisión en el caso de estudio publicado: VitalPBX necesitaba un verdadero controlador de borde de sesión (SBC) que defendiera contra los escáneres SIP, soportara reenvío de registros y reenvío de suscripciones para extensiones remotas, y operara como agente de usuario back-to-back (B2BUA) para que tanto la señalización como los medios pudieran controlarse de forma limpia. ProSBC cumplió los tres requisitos a un precio acorde con el modelo comercial freemium-a-pago de VitalPBX.

Este artículo cubre lo que cambia cuando ProSBC se coloca frente a VitalPBX: las dos formas de despliegue en producción (troncal SIP hacia operadores y acceso público de trabajadores remotos), qué aportan realmente el reenvío de registros y el reenvío de suscripciones, cómo interactúa el SBC con las propias herramientas de seguridad de VitalPBX, y qué implica la edición Multi-Tenant para la arquitectura del SBC. La configuración detallada paso a paso para ambas formas de despliegue se encuentra en la documentación oficial de interoperabilidad de ProSBC para VitalPBX.

Las dos formas de despliegue en producción para VitalPBX + ProSBC

Un despliegue al estilo FreePBX con “una PBX y un troncal de operador” es la forma más simple de VitalPBX, pero rara vez es la que los clientes ejecutan en la práctica. La base instalada de VitalPBX se concentra en dos patrones, ambos documentados directamente en la documentación oficial de interoperabilidad de VitalPBX de ProSBC. El rol del SBC difiere ligeramente en cada uno, y las dos formas suelen coexistir en el mismo servidor VitalPBX.

Forma 1: troncal SIP desde VitalPBX hacia uno o más ISP

VitalPBX termina las extensiones internamente y enruta las llamadas salientes hacia un ISP u operador a través de un troncal SIP. Sin un SBC, ese troncal se establece directamente entre VitalPBX y las direcciones de señalización del operador, lo que significa que VitalPBX debe manejar directamente los requisitos de transporte, códec, encabezados y autenticación del operador. Si se agrega un segundo operador para conmutación por error (failover) o enrutamiento por menor costo, VitalPBX debe gestionar simultáneamente dos conjuntos de criterios SIP distintos.

Con ProSBC en el borde, cada operador obtiene su propio NAP con su perfil SIP, lista de códecs y reglas de encabezados. VitalPBX ve un solo NAP interno y deja de preocuparse por la normalización por operador. El ordenamiento de rutas en el SBC decide qué operador transporta cada llamada, y si un operador deja de responder, el failover automático se activa sin que VitalPBX lo perciba.

Forma 2: acceso de trabajadores remotos a VitalPBX desde la internet pública

La segunda forma es la que VitalPBX destacó en el caso de estudio como el impulsor de seguridad: oficinas remotas y usuarios de trabajo desde casa que registran extensiones a través de la internet pública. Sin un SBC, esas extensiones se registran directamente en VitalPBX por UDP/5060 o TLS/5061, lo que significa que el listener SIP de VitalPBX queda expuesto a todos los escáneres SIP de la internet pública. En menos de una hora después de activarse, los intentos de escaneo comienzan a llegar.

Con ProSBC en el borde, la extensión remota se registra en el SBC, el SBC reenvía el REGISTER a VitalPBX en una interfaz privada, y el SBC devuelve los NOTIFY por proxy. La PBX nunca ve los escáneres. El SBC absorbe los escaneos, aplica protección contra escaneo de registros y limitación de tasa, y solo reenvía el tráfico que coincide con una extensión legítima y un patrón de autenticación válido. Las suscripciones para presencia BLF e indicación de mensajes en espera viajan por el mismo canal, de modo que la consola del operador y las luces de los teléfonos de escritorio siguen funcionando para los agentes remotos.

La mayoría de los despliegues de VitalPBX en producción ejecutan ambas formas en el mismo servidor. Un solo ProSBC maneja ambas: NAP orientados al operador en un lado, NAP orientados a extensiones remotas en el otro, con VitalPBX en el medio sobre una interfaz privada.

Un solo ProSBC maneja ambas formas de despliegue simultáneamente: NAP orientados al operador en un lado para troncales SIP, NAP de extensiones remotas en el otro lado para trabajadores distribuidos, con VitalPBX y Sonata Suite ejecutándose en una interfaz privada en el medio. Haga clic para ampliar.

El reenvío de registros y suscripciones es lo que hace funcionar las extensiones remotas

Cuando VitalPBX evaluó SBC, el reenvío de registros y el reenvío de suscripciones surgieron como requisitos explícitos, no como funciones deseables. La razón es estructural: sin ellos, la forma de trabajadores remotos simplemente no funciona.

Un SIP REGISTER de una extensión remota es lo que le dice a la PBX “soy la extensión 1023, actualmente estoy disponible en esta IP y puerto públicos, por favor envíeme los INVITE”. Si el SBC simplemente termina SIP en el borde y no reenvía el REGISTER hacia VitalPBX, la PBX nunca detecta que la extensión existe y las llamadas entrantes no llegan a ningún destino. El reenvío de registros es el mecanismo que hace transparente al SBC para el registro: el punto final remoto se registra en la dirección pública del SBC; el SBC re-origina el REGISTER hacia VitalPBX desde la interfaz privada del SBC; VitalPBX acepta el registro como si proviniera de la red interna; el SBC mantiene el mapeo y lo utiliza para enrutar los INVITE entrantes de vuelta al punto final público correcto.

El reenvío de suscripciones cumple la misma función para los diálogos SUBSCRIBE/NOTIFY. La consola Sonata Switchboard depende de la presencia BLF para mostrar qué extensiones están en llamada. Los teléfonos de escritorio y los softphones utilizan suscripciones de indicación de mensajes en espera para encender la luz de correo de voz. Los despliegues de hotelería usan suscripciones de eventos de diálogo para integraciones de estado de habitaciones. Si el SBC bloquea o descarta el tráfico SUBSCRIBE en el límite de red, todas esas funcionalidades dejan de operar para los puntos finales remotos mientras siguen funcionando para los que están en la LAN, que es el peor tipo de falla parcial para diagnosticar.

ProSBC maneja ambos modos de reenvío de forma nativa y por NAP, con el mismo NAP transportando registros, suscripciones y señalización de llamadas para un inquilino o grupo de extensiones dado.

¿Qué sucede con el firewall integrado y los complementos de VitalPBX?

VitalPBX incluye un módulo de firewall integrado e integra Fail2ban de fábrica. Ambos están presentes en la edición Community y ambos cumplen una función útil. El módulo de firewall ofrece al operador una interfaz gráfica para reglas de iptables; Fail2ban monitorea el registro de seguridad de Asterisk y bloquea las IP de origen después de intentos repetidos de autenticación fallida. Para un despliegue de un solo sitio con un operador conocido en una LAN privada y sin trabajadores remotos, estas dos herramientas juntas cubren la mayor parte de lo que un operador pequeño necesita.

El panorama cambia en el momento en que el despliegue toca la internet pública. Las herramientas integradas de VitalPBX comparten el mismo sistema operativo, la misma pila de red del kernel y la misma CPU que la PBX. Un ataque a nivel SIP que llega en volumen satura los tres al mismo tiempo. Fail2ban actúa solo después de que Asterisk ya ha registrado algo, lo que significa que el tráfico ya llegó al analizador SIP, fue comparado contra una extensión y fue rechazado, todo lo cual consume CPU a velocidades de escaneo. Los ataques de mensajes malformados, inundaciones de OPTIONS y bloqueos de transacción estilo slow-loris nunca producen el 401 o 403 que Fail2ban está vigilando, por lo que la PBX se degrada silenciosamente mientras el registro de seguridad permanece en calma. Y el módulo de firewall opera en capa 3 y capa 4, sin visibilidad sobre si un paquete entrante es un REGISTER de una extensión real o una sonda de un escáner.

Un SBC en el borde es un dispositivo o VM separado, con su propia IP pública, su propia pila SIP y su propio dominio de falla. Analiza cada mensaje SIP a nivel de la capa SIP, aplica políticas por método y por origen, y absorbe todo el ruido antes de que llegue a VitalPBX. El firewall de VitalPBX y Fail2ban permanecen en la PBX y protegen el plano de gestión (SSH, la interfaz de administración de VitalPBX, las interfaces web de Sonata); el SBC se encarga del plano SIP en el borde de la red. Las dos capas se complementan entre sí; ninguna reemplaza a la otra. La página sobre protección contra ataques DoS SIP en el SBC cubre la mecánica de la capa SIP con mayor profundidad.

Qué cambia para Sonata Suite cuando el SBC está en el borde

Sonata Switchboard, Sonata Recording, Sonata Stats y Sonata Dialer comparten una propiedad estructural: todos leen y escriben en el mismo motor Asterisk con el que el SBC ahora se conecta del lado interno. Ninguno de ellos habla SIP directamente con el operador ni con el punto final remoto. Esa separación es lo que hace que agregar un SBC sea limpio en lugar de disruptivo.

Los indicadores de presencia y BLF de Sonata Switchboard siguen funcionando siempre que el SBC reenvíe correctamente las suscripciones entre el punto final remoto y VitalPBX. Sonata Recording captura los medios del lado Asterisk de la llamada; como ProSBC es un B2BUA y los medios se anclan en cada tramo de forma independiente, el módulo de Recording ve el mismo flujo de medios que siempre vio, independientemente de si el perfil de cifrado era diferente en el tramo del operador. Sonata Stats consume los CDR de Asterisk y las estadísticas de colas, que son completamente internas de la PBX y no se ven afectadas por el SBC. Sonata Dialer origina llamadas salientes; el SBC maneja la normalización y la firma del lado del operador para esas llamadas en la misma ruta que utiliza para cualquier otro tráfico saliente.

El principio arquitectónico es el mismo que le permite a VitalPBX recomendar ProSBC a sus clientes en el caso de estudio: el SBC se ubica de forma limpia fuera del límite de la PBX, termina SIP en cada lado como B2BUA, y no requiere ningún cambio en la configuración interna de VitalPBX, Sonata o los módulos Asterisk subyacentes. La PBX sigue siendo la PBX. Sonata Suite sigue siendo Sonata Suite. El SBC es el nuevo límite público.

VitalPBX MT y un solo SBC para muchos inquilinos

La edición Multi-Tenant de VitalPBX aloja inquilinos aislados en una sola instancia, cada uno con sus propias extensiones, troncales, IVR, alcance de administración y (con los complementos adecuados) módulos Sonata. Los ISP y los proveedores de servicios gestionados la utilizan para entregar PBX alojada a muchos clientes finales desde una sola plataforma. La forma que produce es estructuralmente idéntica al patrón multi-tenant que un MSP ejecuta con una instancia VitalPBX MT y muchos inquilinos detrás.

Un solo ProSBC en el borde consolida la capa SBC de la misma manera en que VitalPBX MT consolidó la capa PBX. Cada inquilino obtiene su propio NAP en el SBC compartido, con sus propias reglas de enrutamiento, su propio mapeo de operadores, su propia política de seguridad y su propio perfil de atestación STIR/SHAKEN. ProSBC soporta hasta 1,024 NAP por servidor, lo cual ofrece margen suficiente para cantidades de inquilinos que exceden lo que la mayoría de las instalaciones de VitalPBX MT realmente alojan. La complejidad orientada al operador permanece en el SBC una sola vez; el enrutamiento por inquilino en el SBC refleja la configuración por inquilino en VitalPBX MT de forma uno a uno.

Una consecuencia específica del patrón MT es que el aislamiento ante compromisos importa. Un solo inquilino comprometido en una PBX multi-tenant es un evento mucho mayor que una sola extensión comprometida en una PBX de inquilino único, porque el atacante ahora ve las credenciales de troncal por inquilino, el enrutamiento por inquilino y los CDR por inquilino. La puntuación de fraude telefónico por NAP del SBC, la limitación de tasa por NAP y la firma STIR/SHAKEN por NAP operan de forma independiente por inquilino, lo que significa que un compromiso en la extensión de un inquilino no puede generar tráfico fraudulento por los troncales de otros inquilinos. La página sobre SBC para MSP cubre el patrón de SBC multi-tenant con mayor profundidad.

Patrones verticales: hotelería, centro de contacto, educación

VitalPBX tiene una adopción inusualmente fuerte en tres verticales donde el SBC en el borde resuelve un problema específico del sector.

Hotelería: los despliegues ejecutan integraciones PMS contra la PBX para check-in de huéspedes, estado de habitaciones, llamadas de despertador y facturación por habitación. Los teléfonos de las habitaciones son extensiones; las estaciones de trabajo de back-of-house y PMS están en la misma red o en una red de confianza adyacente. El rol del SBC es mantener limpios los troncales orientados al operador y selladas las interfaces de gestión remota, permitiendo que los teléfonos de las habitaciones se registren internamente sin cruzar el límite público. El fraude telefónico contra PBX de hotelería es un patrón de ataque bien establecido; la puntuación de fraude por llamada en el SBC detecta la ráfaga de tarifa premium fuera de horario antes de que la recepción del hotel la descubra a la mañana siguiente.

Centro de contacto: las implementaciones combinan VitalPBX con Sonata Switchboard, Sonata Stats y Sonata Dialer a escala pequeña y mediana. El despliegue combina agentes internos (que pueden estar en la LAN o remotos) y tráfico saliente hacia operadores que debe cumplir con la atestación STIR/SHAKEN en Norteamérica. El SBC maneja ambos aspectos: reenvío de registros para agentes remotos, y firma STIR/SHAKEN por llamada a través de un socio como TransNexus ClearIP, Neustar u otros para cada llamada saliente.

Educación: los despliegues cubren escuelas y campus que ejecutan VitalPBX para teléfonos en aulas, megafonía y notificación de emergencias, frecuentemente con enrutamiento E911 a través de un ISP regional. El SBC mantiene limpia la interconexión con el operador y absorbe el tráfico de escaneo SIP que de otro modo llegaría directamente a la PBX a través de la IP pública de la escuela. Cuando múltiples campus comparten una sola PBX, el aislamiento por NAP del SBC otorga a cada campus su propio enrutamiento y límite de seguridad en la misma instancia.

Mecánicas de la capa Asterisk que importan en el límite del SBC

VitalPBX es una interfaz web sobre Asterisk, y toda interacción con el SBC ocurre en la capa SIP de Asterisk por debajo. Cinco comportamientos de Asterisk aparecen consistentemente en el límite del SBC y merecen atención durante la integración.

Identificación de endpoint en chan_pjsip es el primer comportamiento a definir correctamente. Las versiones actuales de VitalPBX utilizan por defecto chan_pjsip, el channel driver moderno basado en PJSIP, y el modo de identificación en el lado de VitalPBX (por IP de origen, por nombre de usuario de autenticación o por un encabezado personalizado) debe coincidir con lo que el SBC está enviando, o Asterisk rechaza el INVITE antes de que se ejecute cualquier lógica de dial-plan. Defina el modo una sola vez durante la planificación y documéntelo; el resto de la integración seguirá a partir de ahí.

Reescritura de encabezados Contact y Via: Asterisk utiliza su propia dirección de interfaz en los encabezados Contact y Via de los INVITE salientes. En una VM en la nube con IP pública, esa dirección suele ser una dirección privada RFC 1918 a la que el operador no puede responder. El patrón más limpio deja que el SBC se encargue de la ocultación de topología para que la dirección local de Asterisk nunca llegue al operador ni al punto final remoto.

Traducción de método DTMF: se vuelve necesaria cuando el operador envía SIP INFO mientras Asterisk usa por defecto RFC 2833 (DTMF fuera de banda en el flujo RTP), o cuando equipos heredados todavía envían DTMF en banda. El SBC traduce entre métodos por tramo, de modo que el operador y VitalPBX ven cada uno el método que esperan.

Manejo de REINVITE y direct-media: puede interactuar negativamente con NAT y con el anclaje de medios del SBC, aunque el comportamiento predeterminado de Asterisk es mantener los medios en el propio equipo. El patrón más limpio deshabilita direct media en el endpoint del troncal de VitalPBX que habla con el SBC, para que el SBC retenga el control total de los medios.

Política de session-timer bajo RFC 4028: previene los cortes silenciosos a mitad de llamada que surgen de una discrepancia de políticas entre Asterisk y el operador. Esos cortes aparecen como aleatorios e intermitentes en el registro completo de Asterisk porque la falla está ocurriendo a un salto de distancia. El SBC aplica una política de session-timer consistente en el tramo del operador sin requerir cambios en la configuración del endpoint de VitalPBX.

La documentación oficial de interoperabilidad de ProSBC para VitalPBX cubre las capturas de pantalla y configuraciones campo por campo para cada uno de estos en el lado de VitalPBX, bajo el menú Network → Trunks y Settings → Technology Settings (PJSIP) del panel de VitalPBX.

Enfoque de configuración para VitalPBX + ProSBC

La configuración detallada paso a paso se encuentra en la documentación oficial de interoperabilidad de ProSBC para VitalPBX, que cubre ambas formas de despliegue (troncal SIP y trabajadores remotos) con capturas de pantalla de cada menú en ambos productos. La lógica de integración, a un nivel alto, es la misma en cualquier SBC B2BUA:

Seguridad en el borde de VitalPBX

VitalPBX incluye su propio módulo de firewall y configuración de Fail2ban, ambos permanecen en su lugar después de agregar el SBC. El SBC agrega las defensas que deben operar antes de que el tráfico llegue a VitalPBX, que es la posición arquitectónica correcta para la protección a nivel SIP.

• Protección contra escaneo de registros SIP: detecta patrones de escaneo en el SBC y bloquea el origen automáticamente, de modo que las sondas nunca llegan a la pila PJSIP de VitalPBX.
• Mitigación de DoS y DDoS: aplica limitación de tasa con reconocimiento SIP por IP de origen, por NAP y por método SIP.
• Puntuación de fraude telefónico por llamada: se ejecuta en cada llamada saliente evaluando prefijo de destino, tarifa, hora del día e historial de patrones. Compatible con los Alliance Partners de TelcoBridges, TransNexus y JeraSoft.
• Ocultación de topología: garantiza que la IP pública del SBC sea la única dirección que el operador y el punto final remoto vean.
• Lista de bloqueados dinámica y greylisting: automatiza la respuesta al abuso detectado y se complementa con el Fail2ban propio de VitalPBX para el plano de gestión.
• Firma STIR/SHAKEN: se ejecuta en la capa del SBC, ya que ni VitalPBX ni Asterisk realizan firma STIR/SHAKEN de forma nativa. ProSBC se integra con TransNexus ClearIP y Neustar a través de SIP.

El modelo de seguridad del SBC más amplio cubre las cinco capas de seguridad de borde con mayor profundidad.

Preguntas frecuentes

Conclusión

VitalPBX es una IP-PBX basada en Asterisk cuya base instalada se concentra en las formas de despliegue que la internet abierta penaliza más: trabajadores remotos registrándose a través del límite público, alojamiento multi-tenant estilo ISP, y verticales (hotelería, centro de contacto, educación) donde el fraude telefónico y el abuso de escáneres SIP tienen un costo financiero real. La respuesta de VitalPBX a ese problema, cuando la empresa lo enfrentó en su propio sistema interno, fue colocar un controlador de borde de sesión frente a la PBX y recomendar la misma arquitectura a su base de clientes.

Las características decisivas al evaluar un SBC para VitalPBX son: arquitectura B2BUA para control total de los tramos de señalización y medios, reenvío de registros y suscripciones para que la forma de trabajadores remotos realmente funcione, aislamiento de transporte y políticas por NAP para que la forma de troncal SIP se mantenga limpia entre operadores, aislamiento por inquilino que coincida con el patrón de despliegue de la edición Multi-Tenant, un modelo abierto de socios STIR/SHAKEN para que la elección del servicio de firma quede en manos del operador, y evaluación autoservicio para que la integración pueda confirmarse contra un VitalPBX real antes de cualquier compromiso de compra.