Integração SBC com FreePBX: como colocar um Controlador de Borda de Sessão na frente do FreePBX

FreePBX é o IP-PBX de código aberto mais implantado no mundo. É uma camada de interface gráfica sobre o Asterisk que oferece a pequenas empresas, MSPs e ITSPs uma plataforma de telefonia completa: ramais, filas, IVR, correio de voz, conferência, gravações e configuração de troncos SIP por meio de uma interface web. A maioria dos servidores FreePBX roda em uma VM na nuvem (Vultr, Linode, DigitalOcean, AWS) com IP público e SIP exposto à internet por padrão.

Essa implantação padrão também é a razão pela qual o FreePBX é um dos alvos VoIP mais intensamente escaneados na internet pública. Scanners automatizados conhecem as portas padrão, os módulos padrão e os padrões de resposta padrão. Um servidor FreePBX recém-instalado acumula milhares de tentativas de varredura SIP em um dia após entrar no ar, e um único ramal comprometido pode gerar fraude telefônica suficiente em tarifas premium para ultrapassar $20,000 antes que o sistema de risco da operadora alerte alguém.

Um Controlador de Borda de Sessão (SBC) na borda é o que fecha essa exposição de forma limpa. O SBC absorve o tráfego da internet pública, normaliza o SIP da operadora na entrada, oculta o FreePBX de qualquer coisa que não pertença ao caminho da chamada e permite que o PBX volte a fazer o que realmente faz bem: ramais, planos de discagem e controle de chamadas. Este artigo cobre o que o SBC adiciona na frente do FreePBX, os comportamentos SIP específicos do Asterisk que o SBC precisa tratar, como o módulo comercial “Session Border Controller” da Sangoma se relaciona (e onde ele fica aquém), e a abordagem de configuração para uma implantação em produção.

O que um SBC adiciona na frente do FreePBX

O FreePBX roda a pilha SIP do Asterisk. Ramais, filas, IVR, correio de voz e a lógica do plano de discagem vivem dentro do FreePBX. Para um único tronco com uma única operadora em uma LAN privada sem exposição à internet, isso é suficiente por si só. O SBC se torna necessário no momento em que a implantação toca a internet pública, termina mais de uma operadora ou transporta chamadas sob escrutínio regulatório.

Exposição à internet pública que o FreePBX herda por padrão

A maioria dos servidores FreePBX roda em VMs na nuvem com IP público, e a maioria dos provedores de tronco SIP espera que o PBX seja acessível em UDP/5060 ou TLS/5061 a partir dos endereços de sinalização da operadora. A mesma porta que a operadora usa é a porta que todo scanner de internet usa. O SBC absorve toda essa exposição: o IP público pertence ao SBC, o listener SIP fica no SBC, e o FreePBX migra para uma interface privada que a operadora e os scanners nunca veem.

Failover multi-operadora e roteamento de menor custo

O FreePBX termina um tronco por operadora de forma limpa. Quando a implantação precisa de operadoras primária e secundária, ou roteamento baseado em tarifas entre três provedores, o SBC se torna o cérebro de roteamento. Cada operadora fica atrás de seu próprio NAP com seu próprio perfil SIP e autenticação, e a ordenação de rotas decide qual operadora transporta cada chamada. O FreePBX continua vendo um único tronco do seu lado.

Normalização SIP entre Asterisk e a operadora

O Asterisk tem suas próprias opiniões sobre SIP. A operadora tem suas próprias opiniões sobre SIP. Os dois conjuntos de opiniões raramente coincidem exatamente. P-headers transportam informações que um lado exige e o outro rejeita, os formatos de Contact e From diferem, a ordem de oferta de codecs varia, e os session timers se comportam de forma diferente entre fornecedores. O motor de manipulação de cabeçalhos SIP do SBC normaliza o trecho da operadora sem alterar nada sobre como o Asterisk se comunica do seu lado.

STIR/SHAKEN e autenticação de chamadas

O FreePBX não possui um caminho nativo de assinatura STIR/SHAKEN. Para implantações na América do Norte, o controle de attestation, a integração com o serviço de assinatura e a política de bypass para interrupções pertencem à camada do SBC. O ProSBC integra-se com serviços de assinatura STIR/SHAKEN como TransNexus ClearIP e Neustar via SIP, com ordenação de rotas e Reason Cause Mapping fornecendo redundância quando um serviço de assinatura está indisponível. Consultas CNAM e LNP se conectam ao mesmo motor de roteamento.

Criptografia no lado público

O Asterisk suporta TLS e SRTP, e muitas implantações FreePBX habilitam ambos para o tráfego de ramais internos. O SBC carrega o mesmo requisito de criptografia no lado da operadora e faz a ponte da diferença por trecho. Um tronco voltado para a operadora em UDP/5060 com RTP não criptografado pode coexistir com um tronco voltado para o FreePBX em TLS/5061 com SRTP, com o SBC realizando a troca de chaves de forma independente em cada lado.

Pontuação de fraude que roda antes da chamada chegar ao FreePBX

A fraude telefônica contra implantações PBX de código aberto é uma economia de ataque bem estabelecida. O SBC pontua cada chamada com base em prefixo de destino, tarifa, horário do dia e histórico de padrões; tráfego de alto risco é bloqueado ou redirecionado antes que o Asterisk aloque um canal. A detecção de fraude rodando no SBC captura o padrão de abuso para o qual a pontuação de risco por chamada foi projetada: um ramal comprometido consumindo minutos internacionais durante a madrugada.

Um único ProSBC fronteia um ou vários servidores FreePBX, apresentando uma fronteira pública controlada para as operadoras e absorvendo toda a exposição voltada para a internet. Clique para ampliar.

O módulo “Session Border Controller” da Sangoma não é a mesma coisa

A Sangoma vende um módulo comercial do FreePBX sob o nome “Session Border Controller”. Ele adiciona filtragem SIP-aware, limitação de taxa e controles de sinalização dentro do servidor FreePBX. É uma camada de endurecimento útil para o próprio PBX, e para uma pequena implantação de site único com uma operadora e uma whitelist de IPs conhecida, resolve parte do problema de ruído.

O que ele não pode fazer é assumir o papel de SBC na borda da rede. O módulo roda dentro do FreePBX, no mesmo host, atrás do mesmo IP público. Não há terminação B2BUA, não há fronteira de criptografia por trecho, não há ocultação de topologia da operadora e não há isolamento entre a camada de segurança e a camada de processamento de chamadas. Se um ataque SIP satura o módulo, satura o FreePBX junto com ele, porque compartilham o sistema operacional, a pilha de rede do kernel e a CPU.

Um SBC real é um dispositivo ou VM separado na borda, com seu próprio IP público, sua própria pilha SIP e seu próprio domínio de falha. Ele termina cada diálogo SIP em cada lado, reorigina um novo do outro lado e controla cada cabeçalho, codec e opção de transporte no caminho. Esse papel não pode ser preenchido por um módulo rodando dentro do PBX que ele deveria proteger. O restante deste artigo trata da implantação de um SBC real, como o ProSBC, entre o FreePBX e a operadora.

Por que Fail2ban e iptables não são suficientes

Todo administrador FreePBX conhece o Fail2ban. Ele varre o log de segurança do Asterisk, encontra falhas repetidas de autenticação de um IP de origem e adiciona uma regra iptables bloqueando esse IP por uma janela configurável. Para força bruta em SSH, é exatamente a ferramenta certa. Para ataques na camada SIP em um PBX exposto à internet, ele tem três lacunas estruturais.

Tempo de reação é a primeira lacuna, porque o Fail2ban só entra em ação depois que o Asterisk já registrou algo. O tráfego já alcançou o PBX, foi analisado, foi comparado com um ramal e foi rejeitado. Cada uma dessas etapas consome CPU. Uma taxa de varredura de 100 requisições por segundo por origem, multiplicada pelas centenas de IPs de origem que um scanner coordenado utiliza, é suficiente para empurrar a carga média além do ponto em que o Asterisk consegue processar chamadas legítimas.

Falhas silenciosas acontecem quando padrões de ataque SIP nunca disparam um 401 ou 403. Mensagens SIP malformadas, cabeçalhos superdimensionados, travamentos de transação estilo slow-loris e floods de OPTIONS nunca chegam ao estágio de autenticação. Eles prendem recursos do parser SIP sem produzir a linha de log que o Fail2ban está monitorando, então o PBX degrada silenciosamente enquanto o Fail2ban não reporta nada.

Cegueira de camada 3 é a terceira lacuna, porque o iptables vê IP e porta, mas não método SIP ou conteúdo. Limitação de taxa SIP-aware requer a inspeção da própria mensagem SIP: limitar INVITEs por origem independentemente de REGISTERs, aplicar um limiar diferente para uma operadora conhecida versus uma origem desconhecida e distinguir um pico legítimo de uma sondagem coordenada. O iptables não consegue fazer isso. A proteção contra DoS SIP de um SBC consegue, porque analisa a camada SIP e aplica política por método, por origem, por grupo de troncos e por limiar global.

O Fail2ban continua útil na arquitetura FreePBX-mais-SBC: ele permanece no PBX como defesa para as interfaces de gerenciamento (SSH, a GUI de administração do FreePBX). O SBC assume a defesa da camada SIP na borda.

Comportamentos SIP específicos do Asterisk que o SBC precisa tratar

O FreePBX é a interface gráfica. O Asterisk é o que realmente fala SIP. Cada peculiaridade do lado do FreePBX é um comportamento do Asterisk com o qual o SBC precisa trabalhar de forma limpa.

Identificação de endpoint no chan_pjsip

As versões atuais do FreePBX usam chan_pjsip como padrão, o driver de canal moderno baseado em PJSIP. O chan_pjsip identifica requisições de entrada comparando com um endpoint configurado, e o método de identificação precisa corresponder ao que o SBC está enviando. Os modos comuns são identificação por IP de origem, por nome de usuário de autenticação ou por um cabeçalho personalizado. Se o FreePBX espera identificação baseada em IP e o SBC está enviando requisições de um endereço traduzido por NAT, o Asterisk rejeita o INVITE sem que nenhuma lógica de plano de discagem seja executada. A correção é pequena, mas específica: configure o endpoint do tronco no FreePBX para identificar pelo endereço real de envio do SBC, ou mude o modo de identificação para autenticação por nome de usuário e provisione credenciais em ambos os lados.

Reescrita de Contact e Via

O Asterisk usa seu próprio endereço de interface nos cabeçalhos Contact e Via em INVITEs de saída. Em uma VM na nuvem atrás de um IP público, esse endereço é frequentemente um endereço privado RFC 1918 para o qual a operadora não consegue rotear de volta. O Asterisk tem suas próprias configurações para anúncio de endereço externo, mas a arquitetura mais limpa é deixar o SBC tratar a ocultação de topologia para tudo que sai. O FreePBX usa seu endereço local; o SBC reescreve para o endereço público do SBC antes que a mensagem chegue à rede.

Incompatibilidades de método DTMF

O FreePBX usa RFC 2833 (DTMF fora de banda no stream RTP) como padrão. Algumas operadoras enviam SIP INFO. Alguns equipamentos legados ainda enviam DTMF in-band. O Asterisk pode ser configurado para qualquer um dos três por endpoint, mas a negociação fica frágil quando a operadora e o FreePBX discordam sobre qual método está em uso. O SBC traduz entre métodos DTMF por trecho, então a operadora e o FreePBX veem cada um o método que esperam.

REINVITE e tratamento de mídia direta

O comportamento padrão do Asterisk é manter a mídia no próprio servidor, mas a opção de negociar mídia direta entre endpoints existe e pode interagir mal com NAT, com as expectativas da operadora sobre quem controla o caminho RTP e com a ancoragem de mídia do SBC. O padrão mais limpo é desabilitar a mídia direta no endpoint do tronco FreePBX que se comunica com o SBC, para que o SBC mantenha controle total da mídia e exista um único caminho para RTP em vez de dois.

Session timers e re-INVITEs

O Asterisk implementa session timers SIP (RFC 4028) e pode ser configurado para exigi-los, aceitá-los ou recusá-los por endpoint. Política de timer incompatível entre Asterisk e a operadora produz quedas de chamada silenciosas no meio da ligação, que parecem aleatórias e intermitentes no log completo do Asterisk porque a falha está acontecendo um salto adiante. O SBC aplica uma política de session timer consistente no trecho da operadora sem exigir mudanças na configuração do endpoint do FreePBX.

Abordagem de configuração: FreePBX, SBC, operadora

Os menus específicos diferem entre fornecedores de SBC, mas a lógica de integração é a mesma em qualquer SBC B2BUA.

FreePBX para MSPs: um SBC, muitos locatários

MSPs que rodam FreePBX como serviço gerenciado para muitos clientes de pequenas empresas enfrentam um problema de escala específico: cada instância FreePBX é seu próprio PBX exposto à internet, com sua própria superfície de ataque, suas próprias credenciais de operadora e sua própria obrigação STIR/SHAKEN. Endurecer cinquenta servidores PBX individualmente dá cinquenta vezes o trabalho de endurecer um.

Um único SBC na borda colapsa isso. Cada locatário FreePBX recebe seu próprio NAP no SBC compartilhado, com suas próprias regras de roteamento, seu próprio mapeamento de operadoras e sua própria política de segurança. O SBC trata a complexidade voltada para a operadora uma vez, apresenta uma fronteira pública controlada para todos, e os servidores FreePBX por locatário migram para interfaces privadas onde sua superfície de ataque é a rede interna do MSP em vez da internet pública. O mesmo modelo se aplica a ITSPs entregando PBX hospedado para muitos clientes finais e operadores de contact center terminando múltiplas campanhas baseadas em FreePBX. A página de aprendizado SBC para MSPs cobre o padrão multi-tenant em profundidade.

O que procurar em um SBC para FreePBX

• Arquitetura B2BUA é o requisito mínimo; um proxy não consegue terminar o diálogo ou reescrever cabeçalhos livremente, que é exatamente o trabalho que uma borda FreePBX precisa que seja feito.
• Posicionamento agnóstico de PBX importa porque o SBC deve tratar o FreePBX como apenas mais um NAP upstream, de modo que a camada SBC sobreviva a uma troca de PBX para 3CX, NetSapiens ou PortaOne no futuro.
• Regras de transporte, codec e cabeçalho por NAP dão a cada operadora e cada locatário seu próprio perfil, com transporte independente (UDP, TCP, TLS) e listas de codec por grupo de troncos.
• Integração STIR/SHAKEN aberta com parceiros mantém o parceiro do serviço de assinatura como sua escolha em vez da escolha do fornecedor do SBC; o ProSBC integra-se com TransNexus ClearIP e Neustar via SIP, o padrão de produção implantado, sem prender a nenhum dos dois.
• Flexibilidade de nuvem e virtualização cobre AWS, Azure, VMware, KVM/Proxmox ou bare metal, de modo que uma implantação cloud-native fique ao lado do FreePBX hospedado na nuvem, ou uma virtualizada rode no mesmo hypervisor que o FreePBX on-premises.
• Avaliação self-service significa que uma licença de laboratório gratuita e permanente está disponível para que a integração possa ser validada contra sua configuração FreePBX real antes de qualquer compromisso comercial.
• Capacidade de grupo de troncos em escala de locatário se torna o fator decisivo para MSPs atendendo mais do que alguns locatários FreePBX a partir de um SBC; o ProSBC suporta até 1,024 NAPs por servidor.

Segurança na borda do FreePBX

O FreePBX inclui os módulos de segurança da Sangoma, Fail2ban e o log de segurança do Asterisk. O SBC complementa esses com defesas em camadas que operam antes do tráfego alcançar o FreePBX, que é a posição arquitetural correta para proteção na camada SIP.

• Proteção contra varredura de registro SIP detecta padrões de varredura, bloqueia a origem automaticamente e nunca encaminha a sondagem ao FreePBX.
• Mitigação de DoS e DDoS aplica limitação de taxa SIP-aware por IP de origem, por grupo de troncos e por método SIP, o que iptables e Fail2ban não conseguem fazer.
• Detecção de fraude telefônica pontua cada chamada por prefixo de destino, taxa de chamada, horário do dia e histórico de padrões, com integração opcional a TransNexus e YouMail para feeds gerenciados.
• Ocultação de topologia mantém o IP público do SBC como o único endereço que a operadora vê, e a topologia subjacente da operadora nunca alcança o FreePBX.
• Lista de bloqueio e greylisting dinâmicos automatizam a resposta a abusos detectados, incluindo o greylisting baseado em porcentagem do ProSBC para resposta gradual durante investigação.

O modelo completo de segurança do SBC cobre as cinco camadas em mais profundidade.

Perguntas frequentes

Conclusão

O FreePBX é um IP-PBX de código aberto capaz, com uma vasta base instalada. Seus pontos fortes são ramais, filas, IVR, flexibilidade de plano de discagem e o ecossistema de módulos FreePBX. Sua fraqueza, estruturalmente, é que a implantação típica fica em uma VM na nuvem com IP público e absorve diretamente todo o peso do abuso SIP voltado para a internet. O SBC é o que corrige isso sem reescrever o funcionamento do FreePBX.

As características decisivas ao avaliar um SBC para FreePBX são: arquitetura B2BUA para controle total de cabeçalhos e criptografia, política de transporte e codec por NAP para que cada operadora e cada locatário receba o perfil correto, um modelo aberto de parceiro STIR/SHAKEN para que a escolha do serviço de assinatura continue sendo sua, posicionamento agnóstico de PBX para que o SBC sobreviva a qualquer escolha individual de PBX, e avaliação self-service para que você confirme que a integração funciona contra seu FreePBX real antes de assinar qualquer coisa.