VitalPBX + SBC: proteção da infraestrutura de voz

VitalPBX é uma empresa com sede no Panamá e nos Estados Unidos, cujo IP-PBX roda em Linux e Asterisk, comercializado em modelo freemium com uma versão paga Enterprise e uma edição Multi-Tenant para ISPs e MSPs. Está implantado em mais de 100 países, com forte adoção nos setores de hotelaria, call centers, educação e empresas de pequeno e médio porte. A interface web do VitalPBX e seus complementos Sonata Suite (Sonata Switchboard para recepcionistas, Sonata Recording para captura de chamadas em conformidade, Sonata Stats para análise de filas, Sonata Dialer para campanhas de chamadas ativas) operam sobre o Asterisk, oferecendo aos operadores uma plataforma completa de telefonia sem necessidade de escrever código de plano de discagem.

VitalPBX também é um cliente de longa data da TelcoBridges. Diante da mesma economia de scanners SIP que atinge toda implantação Asterisk exposta à internet, a VitalPBX selecionou o ProSBC para seu próprio sistema interno e o recomendou ao seu canal de parceiros. O cofundador e CEO Rodrigo Cuadra resumiu a decisão no estudo de caso publicado: a VitalPBX precisava de um Controlador de Borda de Sessão (SBC) real que defendesse contra scanners SIP, suportasse encaminhamento de registro e assinatura para ramais remotos, e operasse como B2BUA para que tanto a sinalização quanto a mídia pudessem ser controladas de forma limpa. O ProSBC atendeu a todos os três requisitos com um preço compatível com o modelo comercial freemium-to-paid da própria VitalPBX.

Este artigo aborda o que muda quando o ProSBC é colocado na frente do VitalPBX: as duas topologias de produção (SIP Trunking voltado para operadoras e acesso de trabalhadores remotos pela internet pública), o que o encaminhamento de registro e assinatura realmente proporcionam, como o SBC interage com as ferramentas de segurança nativas do VitalPBX, e o que a edição Multi-Tenant implica para a arquitetura do SBC. A configuração detalhada passo a passo para ambas as topologias está na documentação oficial de interoperabilidade do ProSBC para VitalPBX.

As duas topologias de produção para VitalPBX + ProSBC

Uma implantação estilo FreePBX com “um PBX, um tronco de operadora” é a topologia mais simples do VitalPBX, mas raramente é a que os clientes realmente utilizam. A base instalada do VitalPBX está concentrada em dois padrões, ambos documentados diretamente na documentação oficial de interoperabilidade do ProSBC para VitalPBX. O papel do SBC difere ligeiramente em cada uma, e as duas topologias frequentemente coexistem no mesmo servidor VitalPBX.

Topologia 1: SIP Trunking do VitalPBX para um ou mais ISPs

O VitalPBX termina ramais internamente e roteia chamadas de saída para um ISP ou operadora através de um tronco SIP. Sem um SBC, esse tronco fica diretamente entre o VitalPBX e os endereços de sinalização da operadora, o que significa que o VitalPBX precisa lidar diretamente com os requisitos de transporte, codec, cabeçalho e autenticação da operadora. Adicione uma segunda operadora para failover ou roteamento de menor custo, e o VitalPBX precisa lidar com dois conjuntos de opiniões sobre SIP ao mesmo tempo.

Com o ProSBC na borda, cada operadora recebe seu próprio NAP com seu próprio perfil SIP, lista de codecs e regras de cabeçalho. O VitalPBX enxerga um único NAP interno e deixa de se preocupar com normalização por operadora. A ordenação de rotas no SBC decide qual operadora transporta cada chamada, e a queda de uma operadora aciona failover automático sem que o VitalPBX perceba.

Topologia 2: acesso de trabalhadores remotos ao VitalPBX pela internet pública

A segunda topologia é a que a VitalPBX destacou no estudo de caso como motivador de segurança: escritórios remotos e usuários em home office registrando ramais pela internet pública. Sem um SBC, esses ramais se registram diretamente no VitalPBX em UDP/5060 ou TLS/5061, o que significa que o listener SIP do VitalPBX fica exposto a todos os scanners SIP da internet pública. Em poucas horas após a ativação, as tentativas de varredura começam a chegar.

Com o ProSBC na borda, o ramal remoto se registra no SBC, o SBC encaminha o REGISTER para o VitalPBX em uma interface privada, e o SBC faz proxy dos NOTIFYs de volta. O PBX nunca vê os scanners. O SBC absorve as varreduras, aplica proteção contra varredura de registro e limitação de taxa, e só encaminha tráfego que corresponda a um ramal legítimo e padrão de autenticação. As assinaturas para presença BLF e indicação de mensagem em espera seguem pelo mesmo canal, então o console de operador e os indicadores luminosos do telefone continuam funcionando para agentes remotos.

A maioria das implantações VitalPBX em produção executa ambas as topologias no mesmo servidor. Um único ProSBC gerencia ambas: NAPs voltados para operadoras de um lado, NAPs voltados para ramais remotos do outro, com o VitalPBX no meio em uma interface privada.

Um único ProSBC gerencia ambas as topologias simultaneamente: NAPs voltados para operadoras de um lado para SIP Trunking, NAPs voltados para ramais remotos do outro lado para trabalhadores distribuídos, com o VitalPBX e o Sonata Suite rodando em uma interface privada no meio. Clique para ampliar.

Encaminhamento de registro e assinatura são o que fazem os ramais remotos funcionarem

Quando a VitalPBX avaliou SBCs, o encaminhamento de registro e o encaminhamento de assinatura surgiram como requisitos nomeados, não como diferenciais opcionais. O motivo é estrutural: sem eles, a topologia de trabalhadores remotos simplesmente não funciona.

Um SIP REGISTER de um ramal remoto é o que diz ao PBX “Eu sou o Ramal 1023, estou atualmente acessível neste IP público e porta, por favor me envie INVITEs.” Se o SBC simplesmente termina o SIP na borda e não encaminha o REGISTER para o VitalPBX, o PBX nunca descobre que o ramal existe e as chamadas de entrada não chegam a lugar nenhum. O encaminhamento de registro é o mecanismo que torna o SBC transparente para o registro: o endpoint remoto se registra no endereço público do SBC; o SBC reorigina o REGISTER em direção ao VitalPBX a partir da interface privada do SBC; o VitalPBX aceita o registro como se tivesse vindo de dentro da rede; o SBC mantém o mapeamento e o utiliza para rotear INVITEs de entrada de volta ao endpoint público correto.

O encaminhamento de assinatura faz o mesmo trabalho para diálogos SUBSCRIBE/NOTIFY. O console Sonata Switchboard depende da presença BLF para mostrar quais ramais estão em chamada. Telefones de mesa e softphones usam assinaturas de indicação de mensagem em espera para acender o indicador de correio de voz. Implantações no setor hoteleiro usam assinaturas de eventos de diálogo para integrações de status de quarto. Se o SBC bloqueia ou descarta tráfego SUBSCRIBE na fronteira, todos esses recursos param de funcionar para endpoints remotos enquanto continuam funcionando para endpoints na LAN, o que é o pior tipo de falha parcial para diagnosticar.

O ProSBC lida com ambos os modos de encaminhamento nativamente e por NAP, com o mesmo NAP transportando registros, assinaturas e sinalização de chamadas para um determinado tenant ou grupo de ramais.

E quanto ao firewall integrado e aos complementos do VitalPBX?

O VitalPBX vem com um módulo de firewall integrado e Fail2ban pronto para uso. Ambos estão presentes na edição Community, e ambos fazem um trabalho útil. O módulo de firewall oferece ao operador uma interface gráfica para regras iptables; o Fail2ban monitora o log de segurança do Asterisk e bloqueia IPs de origem após falhas repetidas de autenticação. Para uma implantação de site único com uma operadora conhecida em LAN privada e sem trabalhadores remotos, esses dois juntos cobrem a maior parte do que um pequeno operador precisa.

O cenário muda no momento em que a implantação toca a internet pública. As ferramentas integradas do VitalPBX compartilham o mesmo sistema operacional, pilha de rede do kernel e CPU do PBX. Um ataque na camada SIP que chega em volume satura os três ao mesmo tempo. O Fail2ban só entra em ação depois que o Asterisk já registrou algo, o que significa que o tráfego já chegou ao parser SIP, foi comparado com um ramal e foi rejeitado, tudo isso consumindo CPU em volumes de varredura. Ataques com mensagens malformadas, floods de OPTIONS e stalls de transação estilo slow-loris nunca produzem o 401 ou 403 que o Fail2ban monitora, então o PBX degrada silenciosamente enquanto o log de segurança permanece vazio. E o módulo de firewall opera na Camada 3 e Camada 4, sem visibilidade sobre se um pacote de entrada é um REGISTER de um ramal real ou uma sonda de um scanner.

Um SBC na borda é um dispositivo ou máquina virtual separada, com seu próprio IP público, sua própria pilha SIP e seu próprio domínio de falha. Ele analisa cada mensagem SIP na camada SIP, aplica política por método e por origem, e absorve todo o ruído antes que ele chegue ao VitalPBX. O firewall e o Fail2ban do VitalPBX permanecem no PBX e protegem o plano de gerenciamento (SSH, a interface administrativa do VitalPBX, as interfaces web do Sonata); o SBC assume o plano SIP na borda da rede. As duas camadas se complementam; nenhuma substitui a outra. A página sobre proteção contra ataques DoS SIP no SBC aborda os mecanismos da camada SIP em mais detalhes.

O que muda para o Sonata Suite quando o SBC está na borda

Sonata Switchboard, Sonata Recording, Sonata Stats e Sonata Dialer compartilham uma propriedade estrutural: todos leem e escrevem no mesmo motor Asterisk com o qual o SBC agora se conecta internamente. Nenhum deles fala SIP com a operadora ou com o endpoint remoto diretamente. Essa separação é o que torna a adição de um SBC limpa, em vez de disruptiva.

Os indicadores de BLF e presença do Sonata Switchboard continuam funcionando desde que o SBC encaminhe as assinaturas corretamente entre o endpoint remoto e o VitalPBX. O Sonata Recording captura mídia do lado Asterisk da chamada; como o ProSBC é um B2BUA e a mídia é ancorada em cada perna independentemente, o módulo de gravação vê o mesmo fluxo de mídia de sempre, independentemente de o perfil de criptografia diferir na perna da operadora. O Sonata Stats consome CDRs e estatísticas de filas do Asterisk, que são inteiramente internas ao PBX e não são afetadas pelo SBC. O Sonata Dialer origina chamadas de saída; o SBC lida com a normalização e assinatura do lado da operadora para essas chamadas no mesmo caminho que usa para qualquer outro tráfego de saída.

O princípio arquitetônico é o mesmo que permitiu à própria VitalPBX recomendar o ProSBC aos seus clientes no estudo de caso: o SBC se posiciona de forma limpa fora do perímetro do PBX, termina o SIP de cada lado como B2BUA, e não exige nenhuma alteração na configuração interna do VitalPBX, do Sonata ou dos módulos Asterisk subjacentes. O PBX continua sendo o PBX. O Sonata Suite continua sendo o Sonata Suite. O SBC é a nova fronteira pública.

VitalPBX MT e um SBC para muitos tenants

A edição Multi-Tenant do VitalPBX hospeda tenants isolados em uma única instância, cada um com seus próprios ramais, troncos, IVR, escopo administrativo e (com os complementos adequados) módulos Sonata. ISPs e provedores de serviços gerenciados a utilizam para entregar PBX hospedado para muitos clientes finais a partir de uma única plataforma. A topologia resultante é estruturalmente idêntica ao padrão multi-tenant que um MSP executa com uma instância VitalPBX MT e muitos tenants por trás.

Um único ProSBC na borda consolida a camada SBC da mesma forma que o VitalPBX MT consolidou a camada PBX. Cada tenant recebe seu próprio NAP no SBC compartilhado, com suas próprias regras de roteamento, mapeamento de operadora, política de segurança e perfil de atestação STIR/SHAKEN. O ProSBC suporta até 1.024 NAPs por servidor, o que proporciona margem suficiente para contagens de tenants que excedem o que a maioria das instalações VitalPBX MT realmente hospeda. A complexidade voltada para operadoras permanece no SBC uma única vez; o roteamento por tenant no SBC espelha a configuração por tenant do VitalPBX MT de forma proporcional.

Uma consequência específica do padrão MT é que o isolamento de comprometimento importa. Um único tenant comprometido em um PBX multi-tenant é um evento muito maior do que um único ramal comprometido em um PBX single-tenant, porque o atacante agora vê credenciais de tronco por tenant, roteamento por tenant e CDR por tenant. A pontuação de fraude telefônica por NAP, a limitação de taxa por NAP e a assinatura STIR/SHAKEN por NAP do SBC operam independentemente por tenant, o que significa que um comprometimento no ramal de um tenant não pode gerar tráfego fraudulento pelos troncos de outros tenants. A página SBC para MSPs aborda o padrão SBC multi-tenant em mais profundidade.

Padrões verticais: hotelaria, contact center, educação

O VitalPBX tem adoção excepcionalmente forte em três verticais onde o SBC na borda resolve um problema específico do setor.

Hotelaria possui implantações que executam integrações PMS com o PBX para check-in de hóspedes, status de quarto, chamadas de despertar e cobrança por quarto. Os telefones dos quartos são ramais; as estações de trabalho de backoffice e PMS estão na mesma rede ou em uma rede vizinha confiável. O papel do SBC é manter os troncos voltados para operadoras limpos e as interfaces de gerenciamento remoto protegidas, enquanto permite que os telefones dos quartos se registrem internamente sem cruzar a fronteira pública. Fraude telefônica contra PBXs de hotelaria é um padrão de ataque bem estabelecido; a pontuação de fraude por chamada no SBC detecta a explosão de chamadas de tarifa premium fora do horário comercial antes que a recepção do hotel descubra na manhã seguinte.

Contact center combina VitalPBX com Sonata Switchboard, Sonata Stats e Sonata Dialer em escala pequena a média. A implantação combina agentes internos (que podem estar na LAN ou remotos) e tráfego de saída para operadoras que precisa passar pela atestação STIR/SHAKEN na América do Norte. O SBC gerencia ambos: encaminhamento de registro para agentes remotos e assinatura STIR/SHAKEN por chamada através de um parceiro como TransNexus ClearIP ou Neustar, entre outros, para cada chamada de saída.

Educação abrange escolas e campi que executam VitalPBX para telefones de sala de aula, pageação e notificação de emergência, frequentemente com roteamento E911 através de um ISP regional. O SBC mantém a interconexão com a operadora limpa e absorve o tráfego de varredura SIP que, de outra forma, alcançaria o PBX diretamente através do IP público da escola. Onde múltiplos campi compartilham um PBX, o isolamento por NAP do SBC dá a cada campus seu próprio roteamento e perímetro de segurança na mesma instância.

Mecânicas da camada Asterisk que importam na fronteira do SBC

O VitalPBX é uma interface web refinada sobre o Asterisk, e toda interação do SBC acontece na camada SIP do Asterisk por baixo. Cinco comportamentos do Asterisk surgem consistentemente na fronteira do SBC e merecem atenção durante a integração.

Identificação de endpoint chan_pjsip é o primeiro comportamento a ser definido. As versões atuais do VitalPBX utilizam chan_pjsip como padrão, o driver de canal moderno baseado em PJSIP, e o modo de identificação no lado do VitalPBX (por IP de origem, por nome de usuário de autenticação ou por cabeçalho personalizado) precisa corresponder ao que o SBC está enviando, ou o Asterisk rejeita o INVITE antes que qualquer lógica de plano de discagem seja executada. Defina o modo uma vez durante o planejamento e documente-o; o restante da integração segue a partir daí.

Reescrita de cabeçalhos Contact e Via importa porque o Asterisk usa seu próprio endereço de interface nos cabeçalhos Contact e Via em INVITEs de saída. Em uma máquina virtual na nuvem com 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 padrão mais limpo permite que o SBC faça o ocultamento de topologia para que o endereço local do Asterisk nunca chegue à operadora ou ao endpoint remoto.

Tradução de método DTMF se torna necessária quando a operadora envia SIP INFO enquanto o Asterisk usa RFC 2833 (DTMF fora de banda no fluxo RTP) como padrão, ou quando equipamentos legados ainda enviam DTMF inband. O SBC traduz entre métodos por perna, para que a operadora e o VitalPBX vejam o método que esperam.

Tratamento de REINVITE e direct-media pode interagir negativamente com NAT e com o ancoramento de mídia do SBC, mesmo que o padrão do Asterisk seja manter a mídia na caixa. O padrão mais limpo desabilita direct media no endpoint de tronco do VitalPBX que se comunica com o SBC, para que o SBC mantenha controle total da mídia.

Política de session-timer sob RFC 4028 previne as quedas silenciosas no meio da chamada que resultam de políticas incompatibilizadas entre o Asterisk e a operadora. Essas quedas aparecem como aleatórias e intermitentes no log completo do Asterisk porque a falha está acontecendo a um salto de distância. O SBC aplica uma política de session-timer consistente na perna da operadora sem exigir alterações na configuração do endpoint VitalPBX.

A documentação oficial de interoperabilidade do ProSBC para VitalPBX cobre as capturas de tela e configurações campo a campo para cada um destes no lado do VitalPBX, sob o menu Network → Trunks e Settings → Technology Settings (PJSIP) do painel do VitalPBX.

Abordagem de configuração para VitalPBX + ProSBC

A configuração detalhada passo a passo está na documentação oficial de interoperabilidade do ProSBC para VitalPBX, que cobre ambas as topologias (SIP Trunking e trabalhadores remotos) com capturas de tela de cada menu em ambos os produtos. A lógica de integração, em alto nível, é a mesma em qualquer SBC B2BUA:

Segurança na borda do VitalPBX

O VitalPBX inclui seu próprio módulo de firewall e configuração Fail2ban, ambos permanecem ativos após a adição do SBC. O SBC adiciona as defesas que precisam operar antes que o tráfego chegue ao VitalPBX, que é a posição arquitetural correta para proteção na camada SIP.

• Proteção contra varredura de registro SIP detecta padrões de varredura no SBC e bloqueia a origem automaticamente, para que as sondas nunca alcancem a pilha PJSIP do VitalPBX.
• Mitigação de DoS e DDoS aplica limitação de taxa compatível com SIP por IP de origem, por NAP e por método SIP.
• Pontuação de fraude telefônica por chamada é executada em cada chamada de saída contra prefixo de destino, tarifa, horário e histórico de padrões. Compatível com os parceiros da TelcoBridges Alliance TransNexus e JeraSoft.
• Ocultamento de topologia garante que o IP público do SBC é o único endereço que a operadora e o endpoint remoto vêem.
• Lista de bloqueio e greylisting dinâmicas automatizam a resposta a abusos detectados e se combinam de forma limpa com o Fail2ban do VitalPBX para o plano de gerenciamento.
• Assinatura STIR/SHAKEN é executada na camada do SBC, já que nem o VitalPBX nem o Asterisk realizam assinatura STIR/SHAKEN nativamente. O ProSBC se integra com TransNexus ClearIP e Neustar via SIP.

O modelo de segurança do SBC aborda as cinco camadas de segurança de borda em mais detalhes.

Perguntas frequentes

Conclusão

O VitalPBX é um IP-PBX baseado em Asterisk capaz, cuja base instalada se concentra nas topologias que a internet aberta mais penaliza: trabalhadores remotos registrando através da fronteira pública, hospedagem multi-tenant estilo ISP, e verticais (hotelaria, contact center, educação) onde fraude telefônica e abuso de scanners SIP têm custo financeiro real. A própria resposta da VitalPBX a esse problema, quando a empresa o enfrentou em seu próprio sistema interno, foi colocar um Controlador de Borda de Sessão na frente do PBX e recomendar a mesma arquitetura para sua base de clientes.

Os recursos decisivos ao avaliar um SBC para VitalPBX são: arquitetura B2BUA para controle total de ambas as pernas de sinalização e mídia, encaminhamento de registro e assinatura para que a topologia de trabalhadores remotos realmente funcione, isolamento de transporte e política por NAP para que a topologia de SIP Trunking permaneça limpa entre operadoras, isolamento por tenant que corresponda ao padrão da edição Multi-Tenant, modelo de parceiros STIR/SHAKEN aberto para que a escolha do serviço de assinatura permaneça com o operador, e avaliação autoatendimento para que a integração possa ser confirmada contra um VitalPBX real antes de qualquer compromisso de compra.