Integración de SBC con FreePBX: cómo colocar un controlador de borde de sesión frente a FreePBX

FreePBX es la IP-PBX de código abierto más ampliamente implementada en el mundo. Es una capa de interfaz gráfica sobre Asterisk que ofrece a pequeñas empresas, MSP e ITSP una plataforma de telefonía completa: extensiones, colas, IVR, correo de voz, conferencias, grabaciones y configuración de troncales SIP a través de una interfaz web. La mayoría de los servidores FreePBX se ejecutan en una VM en la nube (Vultr, Linode, DigitalOcean, AWS) con una IP pública y SIP expuesto a internet de forma predeterminada.

Esa implementación predeterminada es también la razón por la que FreePBX es uno de los objetivos VoIP más intensamente escaneados en internet público. Los escáneres automatizados conocen los puertos predeterminados, los módulos predeterminados y los patrones de respuesta predeterminados. Un servidor FreePBX recién instalado acumula miles de intentos de escaneo SIP en las primeras 24 horas de estar activo, y una sola extensión comprometida puede generar suficiente fraude telefónico de tarifa premium como para superar los $20,000 antes de que el sistema de riesgo del operador alerte a alguien.

Un controlador de borde de sesión (SBC) en el perímetro es lo que cierra esa exposición de forma limpia. El SBC absorbe el tráfico de internet público, normaliza el SIP del operador en la entrada, oculta FreePBX de cualquier elemento que no pertenezca a la ruta de la llamada y permite que la PBX se dedique a lo que realmente hace bien: extensiones, planes de marcado y control de llamadas. Este artículo cubre lo que el SBC agrega frente a FreePBX, los comportamientos SIP específicos de Asterisk que el SBC debe manejar, cómo se relaciona el módulo comercial “Session Border Controller” de Sangoma (y en qué se queda corto), y el enfoque de configuración para una implementación en producción.

Qué agrega un SBC frente a FreePBX

FreePBX ejecuta la pila SIP de Asterisk. Las extensiones, colas, IVR, correo de voz y la lógica del plan de marcado residen dentro de FreePBX. Para una sola troncal con un solo operador en una LAN privada sin exposición a internet, eso es suficiente por sí solo. El SBC se vuelve necesario en el momento en que la implementación toca internet público, termina más de un operador o transporta llamadas bajo escrutinio regulatorio.

Exposición a internet público que FreePBX hereda de forma predeterminada

La mayoría de los servidores FreePBX se ejecutan en VM en la nube con una IP pública, y la mayoría de los proveedores de troncales SIP esperan que la PBX sea alcanzable en UDP/5060 o TLS/5061 desde las direcciones de señalización del operador. El mismo puerto que usa el operador es el puerto que usa cada escáner de internet. El SBC absorbe toda esa exposición: la IP pública pertenece al SBC, el receptor SIP reside en el SBC y FreePBX se traslada a una interfaz privada que el operador y los escáneres nunca ven.

Conmutación por error multioperador y enrutamiento de menor costo

FreePBX termina una troncal por operador de forma limpia. En cuanto la implementación necesita operadores primario y secundario, o enrutamiento por tarifas entre tres proveedores, el SBC se convierte en el cerebro de enrutamiento. Cada operador se ubica detrás de su propio NAP con su propio perfil SIP y autenticación, y el orden de rutas decide qué operador transporta cada llamada. FreePBX sigue viendo una sola troncal en su lado.

Normalización SIP entre Asterisk y el operador

Asterisk tiene sus propias reglas sobre SIP. El operador tiene sus propias reglas sobre SIP. Ambos conjuntos de reglas rara vez coinciden exactamente. Los P-headers transportan información que un lado requiere y el otro rechaza, los formatos de Contact y From difieren, el orden de oferta de códecs varía y los temporizadores de sesión se comportan de manera diferente entre fabricantes. El motor de manipulación de encabezados SIP del SBC normaliza el tramo del operador sin cambiar nada de cómo Asterisk se comunica en su lado.

STIR/SHAKEN y autenticación de llamadas

FreePBX no cuenta con una ruta nativa de firma STIR/SHAKEN. Para las implementaciones en América del Norte, el control de atestación, la integración del servicio de firma y la política de derivación ante interrupciones pertenecen a la capa del SBC. ProSBC se integra con servicios de firma STIR/SHAKEN como TransNexus ClearIP y Neustar por SIP, con orden de rutas y mapeo de causa de razón (Reason Cause Mapping) que proporcionan redundancia cuando un servicio de firma no está accesible. Las consultas CNAM y las búsquedas LNP se conectan al mismo motor de enrutamiento.

Cifrado en el lado público

Asterisk es compatible con TLS y SRTP, y muchas implementaciones FreePBX habilitan ambos para el tráfico de extensiones internas. El SBC lleva el mismo requisito de cifrado en el lado del operador y conecta la diferencia por tramo. Una troncal orientada al operador en UDP/5060 con RTP sin cifrar puede coexistir con una troncal orientada a FreePBX en TLS/5061 con SRTP, mientras el SBC realiza el intercambio de claves de forma independiente en cada lado.

Puntuación de fraude que se ejecuta antes de que la llamada llegue a FreePBX

El fraude telefónico contra implementaciones de PBX de código abierto es una economía de ataque bien establecida. El SBC evalúa cada llamada según el prefijo de destino, la tarifa, la hora del día y el historial de patrones; el tráfico de alto riesgo se bloquea o redirige antes de que Asterisk asigne un canal. La detección de fraude ejecutándose en el SBC captura exactamente el patrón de abuso para el que está diseñada la puntuación de riesgo por llamada: una extensión comprometida consumiendo minutos internacionales durante la noche.

Un solo ProSBC frente a uno o varios servidores FreePBX, presentando un perímetro público controlado hacia los operadores y absorbiendo toda la exposición hacia internet. Haga clic para ampliar.

El módulo “Session Border Controller” de Sangoma no es lo mismo

Sangoma vende un módulo comercial de FreePBX bajo el nombre “Session Border Controller”. Agrega filtrado inteligente de SIP, limitación de tasa y controles de señalización dentro del servidor FreePBX. Es una capa de endurecimiento útil para la PBX en sí, y para una implementación pequeña de un solo sitio con un operador y una lista de IP permitidas conocida, resuelve parte del problema de ruido.

Lo que no puede hacer es asumir el rol de SBC en el perímetro de red. El módulo se ejecuta dentro de FreePBX, en el mismo host, detrás de la misma IP pública. No hay terminación B2BUA, no hay límite de cifrado por tramo, no hay ocultación de topología frente al operador, y no hay aislamiento entre la capa de seguridad y la capa de procesamiento de llamadas. Si un ataque SIP satura el módulo, satura FreePBX junto con él, porque comparten el sistema operativo, la pila de red del kernel y la CPU.

Un SBC real es un dispositivo o VM separado en el perímetro, con su propia IP pública, su propia pila SIP y su propio dominio de fallo. Termina cada diálogo SIP en cada lado, re-origina uno nuevo en el otro lado y controla cada encabezado, códec y opción de transporte en el proceso. Ese rol no puede ser cumplido por un módulo que se ejecuta dentro de la PBX que se supone debe proteger. El resto de este artículo trata sobre la implementación de un SBC real, como ProSBC, entre FreePBX y el operador.

Por qué Fail2ban e iptables no son suficientes

Todo administrador de FreePBX conoce Fail2ban. Escanea el registro de seguridad de Asterisk, encuentra fallos de autenticación repetidos desde una IP de origen y agrega una regla iptables que bloquea esa IP durante un período configurable. Para ataques de fuerza bruta por SSH, es exactamente la herramienta correcta. Para ataques en la capa SIP contra una PBX expuesta a internet, tiene tres deficiencias estructurales.

La temporización reactiva es la primera deficiencia, porque Fail2ban solo actúa después de que Asterisk ya ha registrado algo. El tráfico ya llegó a la PBX, fue analizado, fue comparado con una extensión y fue rechazado. Cada uno de esos pasos consume CPU. Una tasa de escaneo de 100 solicitudes por segundo por origen, multiplicada por los cientos de IP de origen que usa un escáner coordinado, es suficiente para elevar la carga promedio más allá de donde Asterisk puede atender llamadas legítimas.

Los fallos silenciosos ocurren cuando los patrones de ataque SIP nunca generan una respuesta 401 o 403 en primer lugar. Los mensajes SIP malformados, los encabezados sobredimensionados, los bloqueos de transacciones de tipo slow-loris y las inundaciones de sondeos OPTIONS nunca llegan a la etapa de autenticación. Consumen recursos del analizador SIP sin producir la línea de registro que Fail2ban está vigilando, por lo que la PBX se degrada silenciosamente mientras Fail2ban no reporta nada.

La ceguera de capa 3 es la tercera deficiencia, porque iptables ve IP y puerto pero no el método ni el contenido SIP. La limitación de tasa inteligente en SIP requiere inspeccionar el mensaje SIP en sí: limitar INVITE por origen independientemente de REGISTER, aplicar un umbral diferente a un operador conocido que a un origen desconocido, y distinguir un pico legítimo de un sondeo coordinado. iptables no puede hacer eso. La protección contra DoS SIP de un SBC sí puede, porque analiza la capa SIP y aplica políticas por método, por origen, por grupo de troncales y por umbral global.

Fail2ban sigue siendo útil en la arquitectura FreePBX más SBC: permanece en la PBX como defensa para las interfaces de administración (SSH, la interfaz de administración web de FreePBX). El SBC asume la defensa de la capa SIP en el perímetro.

Comportamientos SIP específicos de Asterisk que el SBC debe manejar

FreePBX es la interfaz gráfica. Asterisk es lo que realmente habla SIP. Cada particularidad del lado de FreePBX es un comportamiento de Asterisk con el que el SBC debe trabajar correctamente.

Identificación de endpoint en chan_pjsip

Las versiones actuales de FreePBX usan por defecto chan_pjsip, el controlador de canal moderno basado en PJSIP. chan_pjsip identifica las solicitudes entrantes contra un endpoint configurado, y el método de identificación debe coincidir con lo que el SBC está enviando. Los modos comunes son la identificación por IP de origen, por nombre de usuario de autenticación o por un encabezado personalizado. Si FreePBX espera identificación por IP y el SBC envía solicitudes desde una dirección traducida por NAT, Asterisk rechaza el INVITE sin que se ejecute ninguna lógica del plan de marcado. La solución es pequeña pero específica: configure el endpoint de la troncal FreePBX para que identifique por la dirección de envío real del SBC, o cambie el modo de identificación a autenticación por nombre de usuario y aprovisione las credenciales en ambos lados.

Reescritura de Contact y Via

Asterisk utiliza la dirección de su propia interfaz en los encabezados Contact y Via en los INVITE salientes. En una VM en la nube detrás de una IP pública, esa dirección suele ser una dirección privada RFC 1918 a la que el operador no puede enrutar de vuelta. Asterisk tiene sus propias configuraciones para la publicación de la dirección externa, pero la arquitectura más limpia es dejar que el SBC maneje la ocultación de topología para todo el tráfico saliente. FreePBX usa su dirección local; el SBC la reescribe con la dirección pública del SBC antes de que el mensaje salga a la red.

Diferencias en el método DTMF

FreePBX usa por defecto RFC 2833 (DTMF fuera de banda en el flujo RTP). Algunos operadores envían SIP INFO. Algunos equipos heredados todavía envían DTMF en banda. Asterisk puede configurarse para cualquiera de los tres por endpoint, pero la negociación se vuelve frágil cuando el operador y FreePBX no coinciden en cuál método está en uso. El SBC traduce entre métodos DTMF por tramo, de modo que el operador y FreePBX ven cada uno el método que esperan.

Manejo de REINVITE y medios directos

El comportamiento predeterminado de Asterisk es mantener los medios en el servidor, pero la opción de negociar medios directos entre terminales existe y puede interactuar negativamente con NAT, con las expectativas del operador sobre quién controla la ruta RTP y con el anclaje de medios del SBC. El patrón más limpio es deshabilitar los medios directos en el endpoint de la troncal FreePBX que se comunica con el SBC, para que el SBC retenga el control total de los medios y exista una sola ruta para RTP en lugar de dos.

Temporizadores de sesión y re-INVITE

Asterisk implementa temporizadores de sesión SIP (RFC 4028) y puede configurarse para requerir, aceptar o rechazarlos por endpoint. Una política de temporizadores desalineada entre Asterisk y el operador produce cortes silenciosos a mitad de llamada, que aparecen como aleatorios e intermitentes en el registro completo de Asterisk porque el fallo está ocurriendo un salto más allá. El SBC impone una política de temporizadores de sesión consistente en el tramo del operador sin requerir cambios en la configuración del endpoint de FreePBX.

Enfoque de configuración: FreePBX, SBC, operador

Los menús específicos varían entre fabricantes de SBC, pero la lógica de integración es la misma en cualquier SBC B2BUA.

FreePBX para MSP: un SBC, múltiples inquilinos

Los MSP que ejecutan FreePBX como servicio gestionado para muchos clientes de pequeñas empresas enfrentan un problema de escalabilidad específico: cada instancia de FreePBX es su propia PBX expuesta a internet, con su propia superficie de ataque, sus propias credenciales de operador y su propia obligación STIR/SHAKEN. Endurecer cincuenta servidores PBX individualmente es cincuenta veces el trabajo de endurecer uno.

Un solo SBC en el perímetro resuelve eso. Cada inquilino FreePBX obtiene su propio NAP en el SBC compartido, con sus propias reglas de enrutamiento, su propio mapeo de operadores y su propia política de seguridad. El SBC maneja la complejidad orientada al operador una sola vez, presenta un perímetro público controlado para todos ellos, y los servidores FreePBX de cada inquilino se trasladan a interfaces privadas donde su superficie de ataque es la red interna del MSP en lugar de internet público. El mismo modelo aplica a los ITSP que entregan PBX alojada a muchos clientes finales y a los operadores de centros de contacto que terminan múltiples campañas respaldadas por FreePBX. La página de aprendizaje sobre SBC para MSP cubre el patrón multi-inquilino en detalle.

Qué buscar en un SBC para FreePBX

• Arquitectura B2BUA es la base; un proxy no puede terminar el diálogo ni reescribir encabezados libremente, que es exactamente el trabajo que necesita un perímetro FreePBX.
• Posicionamiento independiente de la PBX importa porque el SBC debería tratar a FreePBX como un NAP ascendente más, de modo que la capa SBC sobreviva a un cambio de PBX a 3CX, NetSapiens o PortaOne en el futuro.
• Reglas de transporte, códec y encabezados por NAP otorgan a cada operador y cada inquilino su propio perfil, con transporte independiente (UDP, TCP, TLS) y listas de códecs por grupo de troncales.
• Integración abierta con socios STIR/SHAKEN mantiene al socio del servicio de firma como su elección y no la del fabricante del SBC; ProSBC se integra con TransNexus ClearIP y Neustar por SIP, el patrón de producción implementado, sin dependencia de ninguno de los dos.
• Flexibilidad en nube y virtualización cubre AWS, Azure, VMware, KVM/Proxmox o bare metal, de modo que una implementación nativa en la nube se ubica junto a un FreePBX alojado en la nube, o una virtualizada se ejecuta en el mismo hipervisor que un FreePBX local.
• Evaluación autónoma significa que una licencia de laboratorio gratuita y permanente está disponible para validar la integración contra su configuración real de FreePBX antes de cualquier compromiso comercial.
• Capacidad de grupos de troncales a escala de inquilinos se convierte en el factor decisivo para los MSP que atienden más de un puñado de inquilinos FreePBX desde un solo SBC; ProSBC admite hasta 1,024 NAP por servidor.

Seguridad en el perímetro de FreePBX

FreePBX incluye los módulos de seguridad de Sangoma, Fail2ban y el registro de seguridad de Asterisk. El SBC complementa esos mecanismos con defensas por capas que operan antes de que el tráfico llegue a FreePBX, que es la posición arquitectónica correcta para la protección de la capa SIP.

• Protección contra escaneo de registros SIP detecta patrones de escaneo, bloquea el origen automáticamente y nunca reenvía la sonda a FreePBX.
• Mitigación de DoS y DDoS aplica limitación de tasa inteligente en SIP por IP de origen, por grupo de troncales y por método SIP, algo que iptables y Fail2ban no pueden hacer.
• Detección de fraude telefónico evalúa cada llamada por prefijo de destino, tasa de llamada, hora del día e historial de patrones, con integración opcional a TransNexus y YouMail para fuentes gestionadas.
• Ocultación de topología mantiene la IP pública del SBC como la única dirección que el operador ve, y la topología subyacente del operador nunca llega a FreePBX.
• Listas de bloqueados y listas grises dinámicas automatizan la respuesta ante abusos detectados, incluyendo la lista gris basada en porcentaje de ProSBC para una respuesta graduada durante la investigación.

El modelo completo de seguridad SBC cubre las cinco capas con mayor profundidad.

Preguntas frecuentes

Conclusión

FreePBX es una IP-PBX de código abierto capaz y con una amplia base instalada. Sus fortalezas son las extensiones, las colas, el IVR, la flexibilidad del plan de marcado y el ecosistema de módulos de FreePBX. Su debilidad, estructuralmente, es que la implementación típica reside en una VM en la nube con una IP pública y absorbe todo el peso del abuso SIP proveniente de internet de forma directa. El SBC es lo que corrige eso sin reescribir cómo funciona FreePBX.

Las características decisivas al evaluar un SBC para FreePBX son: arquitectura B2BUA para control total de encabezados y cifrado, política de transporte y códec por NAP para que cada operador y cada inquilino obtengan el perfil correcto, un modelo abierto de socios STIR/SHAKEN para que la elección del servicio de firma siga siendo suya, posicionamiento independiente de la PBX para que el SBC sobreviva a cualquier cambio individual de PBX, y evaluación autónoma para que pueda confirmar que la integración funciona con su FreePBX real antes de firmar nada.