Prevenção de ataques DoS SIP: como um SBC bloqueia ataques de inundação antes que alcancem sua rede de voz

No mundo da voz, não existe interrupção silenciosa. Quando uma rede cai, todos percebem instantaneamente. Não há degradação gradual ou fallback em cache para se apoiar; as chamadas simplesmente falham. Os clientes encontram silêncio total ou um sinal de ocupado rápido, os call centers ficam no escuro e a receita para imediatamente. Essa visibilidade total é exatamente o motivo pelo qual a infraestrutura SIP é um alvo tão valioso para ataques DoS. Os invasores sabem que inundar uma plataforma de voz cria uma crise imediata e mensurável, e contam com o fato de que você estará muito mais focado em restaurar o serviço do que em rastrear a origem.

A escala da ameaça está claramente se acelerando; a Cloudflare reportou o bloqueio de 20,5 milhões de ataques DDoS somente no Q1 de 2025, o que representa um aumento impressionante de 358% em relação ao ano anterior. A infraestrutura VoIP permanece diretamente na mira porque os ataques de inundação SIP são projetados para explorar a mecânica fundamental do protocolo. Cada INVITE força um servidor a alocar recursos para um diálogo, enquanto cada REGISTER aciona uma consulta de credenciais, e mensagens malformadas testam constantemente a resiliência do parser. O cerne do problema é que um firewall de rede padrão normalmente enxerga tudo isso como tráfego UDP genérico em uma única porta, sem nenhuma forma real de distinguir uma configuração de chamada legítima de um ataque malicioso.

Um Controlador de Borda de Sessão (SBC) é o único elemento de rede projetado especificamente para inspecionar, limitar a taxa e bloquear tráfego SIP na camada de aplicação. Este guia aborda cada tipo principal de ataque de inundação SIP, explica como um SBC detecta e mitiga cada um, e fornece orientações de arquitetura de implantação para construir redes de voz resilientes a DoS.

Por que a infraestrutura SIP é particularmente vulnerável

Entender por que o SIP é um alvo DoS tão eficaz exige analisar o design do protocolo. O SIP foi construído para confiabilidade e interoperabilidade em redes confiáveis, não para ambientes adversários.
O SIP é um protocolo baseado em texto e com estado. Cada chamada começa com uma transação INVITE que cria um diálogo, e o servidor deve rastrear o estado desse diálogo ao longo da configuração, toque, atendimento e encerramento. Essa natureza com estado significa que cada mensagem de entrada consome recursos do servidor: ciclos de CPU para análise, memória para estado do diálogo e consultas em banco de dados para roteamento e autenticação. Diferente de requisições web sem estado que podem ser absorvidas por um CDN ou balanceador de carga, o estado de chamada SIP é em tempo real e sensível a latência. Mesmo alguns segundos de atraso no processamento se traduzem em chamadas falhas e registros perdidos.
O SIP normalmente funciona sobre UDP. Sem o three-way handshake do TCP, não há mecanismo integrado para verificar se o endereço IP de origem em um pacote SIP é genuíno. A falsificação de IP de origem é trivial, o que significa que os invasores podem gerar tráfego de inundação que parece vir de milhares de endereços diferentes simultaneamente, derrotando a limitação de taxa simples por IP.
O mecanismo de registro agrava o problema. Os terminais SIP (telefones, softphones, troncos) devem enviar periodicamente mensagens REGISTER para manter sua conexão. Cada requisição REGISTER força o servidor a consultar credenciais, validá-las e responder. Esse processamento de autenticação é intensivo em CPU e normalmente atinge o componente mais restrito na arquitetura: o registrar.
Finalmente, o plano de mídia adiciona outra superfície de ataque. O RTP (Real-time Transport Protocol) transporta o áudio de voz real em faixas de portas alocadas dinamicamente, o que significa que os firewalls devem deixar faixas amplas de portas abertas para permitir a passagem do tráfego de mídia. Essas portas abertas se tornam pontos de entrada para inundações de mídia que consomem largura de banda e capacidade de processamento sem jamais estabelecer uma chamada legítima.
A combinação de tratamento de chamadas com estado, transporte UDP, autenticação intensiva em recursos e alocação dinâmica de portas torna a infraestrutura SIP um alvo DoS ideal.

Os quatro tipos de ataque de inundação SIP

Os ataques de negação de serviço SIP se dividem em quatro categorias, cada uma explorando um aspecto diferente do protocolo. Uma defesa eficaz deve abordar todas as quatro.

Inundações INVITE

Uma inundação INVITE é o ataque DoS SIP mais comum. O invasor envia volumes massivos de mensagens SIP INVITE ao alvo, cada uma solicitando que o servidor configure uma nova chamada.
Cada INVITE força o servidor receptor a analisar os cabeçalhos SIP, consultar regras de roteamento, alocar memória para um diálogo de chamada e tentar encaminhar a requisição ao próximo salto. Mesmo que as chamadas nunca sejam concluídas (e em um ataque, normalmente não são), o processamento da transação para cada INVITE consome CPU e memória. Em volume suficiente, o servidor esgota sua capacidade de processamento e não consegue mais lidar com requisições legítimas de configuração de chamada.
Inundações INVITE são particularmente eficazes porque os servidores SIP são projetados para ser generosos com recursos durante a configuração de chamada. O protocolo assume que, se um INVITE chega, um chamador real está esperando. Não há uma forma leve de rejeitar um INVITE sem pelo menos processá-lo parcialmente.
Quando os IPs de origem são falsificados (o que é comum sobre UDP), o bloqueio simples por IP se torna ineficaz porque o ataque parece vir de milhares de endereços únicos.
O impacto é imediato: chamadores legítimos recebem sinais de ocupado, ouvem silêncio ou recebem erros de timeout. Se o alvo for um tronco SIP conectando uma empresa à sua operadora, todas as chamadas de entrada e saída dessa organização param.

Inundações REGISTER

Uma inundação REGISTER tem como alvo o subsistema de autenticação. O invasor envia altos volumes de requisições SIP REGISTER, normalmente com credenciais aleatórias ou inválidas, ao SBC ou registrar.
Cada mensagem REGISTER força o servidor a realizar uma consulta de credenciais e um ciclo de desafio/resposta de autenticação. Isso é mais custoso computacionalmente por mensagem do que o processamento de INVITE porque envolve consultas em banco de dados e, em muitas implementações, cálculo de autenticação digest.
Inundações REGISTER podem servir a um propósito duplo: o objetivo principal é a exaustão de recursos (negar serviço a usuários legítimos tentando se registrar), mas a inundação pode funcionar simultaneamente como um ataque de credential-stuffing se nomes de usuário reais forem incluídos com senhas de força bruta.
O impacto atinge o plano de registro especificamente. Terminais legítimos que não conseguem se registrar perdem sua presença na rede, o que significa que não podem receber chamadas de entrada e podem não conseguir fazer chamadas de saída. Para organizações com trabalhadores remotos dependendo do registro SIP para conectividade via softphone, uma inundação REGISTER pode desconectar silenciosamente toda a força de trabalho remota.

Inundações OPTIONS e BYE

Mensagens SIP OPTIONS são sondas leves de keepalive. Os servidores devem respondê-las rapidamente, tornando-as um vetor eficiente para exaustão de recursos com esforço mínimo do invasor. Uma inundação OPTIONS pode não derrubar um servidor diretamente, mas degrada o desempenho ao consumir capacidade de processamento de transações que de outra forma lidaria com chamadas reais.
Inundações BYE são mais direcionadas e mais disruptivas. Ao enviar mensagens BYE forjadas que referenciam identificadores de diálogo de chamadas ativas, um invasor pode encerrar chamadas legítimas em andamento. Se o invasor conseguir observar ou adivinhar valores de call-ID (que às vezes são previsíveis), ele pode desconectar chamadas específicas seletivamente ou varrer uma faixa de valores possíveis para interromper todas as sessões ativas.
Inundações OPTIONS causam degradação gradual de desempenho. Inundações BYE causam desconexões de chamadas ativas, que são visíveis aos usuários finais imediatamente e podem ser confundidas com instabilidade de rede em vez de um ataque ativo.

Ataques de mensagens SIP malformadas

Em vez de sobrecarregar o servidor com volume, ataques de mensagens malformadas visam o parser SIP em si. O invasor envia mensagens SIP com cabeçalhos deliberadamente quebrados, campos superdimensionados, codificações de caracteres inválidas ou estruturas sintaticamente impossíveis.
O objetivo é acionar uma vulnerabilidade do parser: um estouro de buffer, um vazamento de memória, uma exceção não tratada ou comportamento indefinido na pilha SIP. Se o parser travar, todo o serviço SIP cai. Mesmo que não trave, um parser que consome recursos excessivos ao tentar processar entrada malformada pode ser explorado para um ataque DoS de baixo volume que escapa completamente da limitação de taxa.
Essa categoria inclui ataques de “fuzzing” onde ferramentas automatizadas geram milhares de variações de mensagens malformadas para descobrir bugs exploráveis no parser. Um único payload de fuzzing bem-sucedido pode ser mais danoso do que uma inundação volumétrica porque pode precisar de apenas uma mensagem para derrubar o alvo.
O impacto varia de instabilidade do serviço (vazamentos de memória causando degradação gradual) a falha completa do serviço (travamento do parser) a possíveis violações de segurança se a vulnerabilidade do parser permitir execução de código.

Como um SBC bloqueia ataques de inundação SIP

Um SBC oferece cinco mecanismos distintos de detecção e mitigação para ataques DoS SIP. Esses mecanismos operam em camadas diferentes e se complementam para criar uma postura de defesa em profundidade.

Limitação de taxa com reconhecimento SIP

A proteção DoS mais fundamental do SBC é a limitação de taxa na camada de aplicação que entende os tipos de mensagem SIP. Diferente de um firewall, que só consegue limitar o tráfego por endereço IP e número de porta, um SBC pode definir limites de taxa independentes para cada método SIP.
Isso significa que um operador pode configurar limiares separados para mensagens INVITE, mensagens REGISTER, mensagens OPTIONS e outros métodos SIP. Um tronco de operadora legítimo pode enviar 500 INVITEs por segundo durante horários de pico, mas nunca deveria enviar 500 REGISTERs por segundo. A limitação de taxa com reconhecimento SIP pode bloquear a inundação REGISTER enquanto permite que o tráfego INVITE flua normalmente.
Os limites de taxa podem ser aplicados em múltiplos escopos. Limites por IP de origem limitam o tráfego de qualquer endereço de origem individual. Limites por grupo de troncos (configurados por Ponto de Acesso de Rede no ProSBC) limitam o tráfego total de cada conexão de operadora independentemente da distribuição de IPs de origem. Limites globais protegem a capacidade de processamento do próprio SBC como último recurso.
A vantagem principal sobre a limitação de taxa na camada de rede é a precisão. Um firewall que limita todo o tráfego UDP para a porta 5060 bloqueará chamadas legítimas junto com o tráfego de ataque. Um SBC que limita apenas mensagens REGISTER de fontes não confiáveis enquanto permite tráfego INVITE de peers de operadora conhecidos preserva o serviço durante um ataque.

Validação de protocolo e filtragem de mensagens

Cada mensagem SIP que alcança o SBC passa por um motor de validação de protocolo antes de ser autorizada a alcançar o núcleo de processamento de chamadas. O SBC verifica a mensagem contra a especificação SIP (RFC 3261 e padrões relacionados), verificando que os cabeçalhos estão corretamente formados, que os campos obrigatórios estão presentes, que os comprimentos dos campos estão dentro dos limites e que a estrutura geral da mensagem é sintaticamente válida.
Mensagens que falham na validação são descartadas imediatamente. Elas nunca alcançam o motor de processamento de chamadas, a lógica de roteamento ou o registrar. Isso elimina toda a classe de ataques de mensagens malformadas e exploração de parser em uma única camada.
Além da validação estrita, o motor de normalização SIP do SBC pode corrigir problemas comuns de formatação de terminais legítimos mas não conformes. Essa função dupla, rejeitar malformação maliciosa enquanto corrige não-conformidade benigna, significa que a camada de validação melhora tanto a segurança quanto a interoperabilidade simultaneamente.

Blacklisting dinâmico e classificação de confiança

Listas de controle de acesso (ACLs) estáticas são um ponto de partida, mas exigem manutenção manual e não conseguem responder a ataques em tempo real. O blacklisting dinâmico automatiza a resposta.
O SBC monitora padrões de tráfego de cada IP de origem em tempo real. Quando uma fonte excede os limiares configurados (por exemplo, 50 tentativas de REGISTER falhas em 10 segundos, ou 200 INVITEs por segundo sem chamadas concluídas), o SBC adiciona automaticamente essa fonte a uma lista negra. O tráfego subsequente da fonte na lista negra é descartado na camada de rede sem consumir recursos de processamento na camada de aplicação.
O ProSBC estende isso com greylisting baseado em porcentagem. Em vez de tomar uma decisão binária de bloquear/permitir, um operador pode configurar o SBC para passar apenas uma porcentagem do tráfego de uma fonte suspeita. Por exemplo, bloquear 90% do tráfego de uma faixa de IP enquanto permite 10% para monitoramento. Isso é particularmente útil durante a fase de investigação de um DDoS suspeito, quando o operador ainda não tem certeza se a fonte de tráfego é maliciosa ou uma operadora legítima experimentando um pico de tráfego.
A classificação de confiança adiciona outra camada. Peers de operadora conhecidos podem ser classificados como confiáveis, recebendo limites de taxa mais altos e ignorando certas verificações. Fontes desconhecidas ou da internet pública são classificadas como não confiáveis e sujeitas a escrutínio mais rigoroso. O SBC pode reclassificar fontes dinamicamente com base em seu comportamento, promovendo fontes bem-comportadas e rebaixando as abusivas.

Proteção contra varredura de registro SIP

Inundações de registro merecem detecção dedicada por causa de seu impacto desproporcional no subsistema de autenticação. O ProSBC inclui um motor de proteção contra varredura de registro SIP construído especificamente para monitorar tráfego REGISTER.
Esse motor distingue entre comportamento de registro legítimo (periódico, temporização previsível, credenciais válidas) e padrões de ataque (tráfego em rajada, tentativas sequenciais de credenciais, nomes de usuário aleatórios ou inválidos). Terminais SIP legítimos se re-registram em intervalos configurados (tipicamente 60 a 3600 segundos) com credenciais consistentes. Scanners de registro e ferramentas de inundação geram rajadas de mensagens REGISTER com credenciais variadas ou sequenciais em taxas que nenhum terminal legítimo produziria.
Quando o motor de detecção identifica um padrão de varredura de registro ou inundação, ele bloqueia a fonte antes que o tráfego alcance o registrar. Isso protege o componente mais restrito em recursos na arquitetura sem afetar o tráfego de registro legítimo de terminais conhecidos.

Ocultação de topologia como prevenção de DoS

A ocultação de topologia é frequentemente discutida como um recurso de privacidade ou segurança, mas também é um mecanismo direto de prevenção de DoS.
Um SBC operando como um Agente de Usuário Back-to-Back (B2BUA) termina cada sessão SIP no lado externo e re-origina uma nova sessão no lado interno. Partes externas nunca veem os endereços IP, nomes de host ou topologia de rede dos servidores SIP internos, gateways de mídia ou sistemas PBX.
Isso importa para prevenção de DoS porque um invasor não pode atacar o que não consegue ver. Sem o SBC, um invasor que descobre o endereço IP de um PBX ou registrar interno pode inundá-lo diretamente, contornando quaisquer defesas de perímetro. Com o SBC em modo B2BUA, todo o tráfego externo termina no próprio SBC, e a infraestrutura interna é arquiteturalmente inalcançável a partir da internet.
A arquitetura B2BUA completa do ProSBC (não um proxy SIP leve) cria uma quebra total no diálogo SIP entre as redes externa e interna. As mensagens SIP no lado interno são transações inteiramente novas geradas pelo SBC, não cópias encaminhadas de mensagens externas. Um invasor inundando a interface externa do SBC não consegue injetar mensagens malformadas ou requisições BYE forjadas nas pernas de chamada internas porque essas pernas são sessões SIP independentes controladas inteiramente pelo SBC.

Por que um firewall de rede não substitui um SBC para proteção DoS SIP

Firewalls de rede e SBCs desempenham papéis complementares, e nenhum substitui o outro. A distinção importa porque organizações que dependem apenas de um firewall para segurança VoIP têm uma lacuna significativa em sua defesa contra DoS.
Um firewall opera na camada de rede (Camada 3) e na camada de transporte (Camada 4). Ele pode filtrar por endereço IP de origem e destino, tipo de protocolo e número de porta. Pode aplicar limites de taxa ao volume total de tráfego de uma determinada fonte. Alguns firewalls oferecem um recurso de SIP Application Layer Gateway (ALG), mas SIP ALGs são amplamente conhecidos por causar problemas significativos em redes de voz: reescrevendo cabeçalhos SIP de formas que quebram fluxos de chamada, interferem na travessia NAT e produzem roteamento imprevisível. A maioria dos engenheiros VoIP desabilita o SIP ALG como primeiro passo de resolução de problemas.
O que um firewall não consegue fazer é inspecionar mensagens SIP na camada de aplicação. Ele não consegue distinguir um INVITE legítimo de um ataque de inundação. Não consegue limitar a taxa de mensagens REGISTER independentemente de mensagens INVITE. Não consegue detectar que uma mensagem SIP é malformada de forma projetada para explorar uma vulnerabilidade do parser. Não consegue identificar padrões de varredura de registro. Não consegue ocultar a topologia de rede interna de reconhecimento no nível SIP.
A arquitetura correta usa ambos. Um firewall (ou serviço upstream de limpeza DDoS) lida com ataques volumétricos nas Camadas 3/4: inundações TCP SYN, ataques de amplificação UDP, inundações ICMP. O SBC lida com ataques SIP na camada de aplicação que passam pela camada de rede sem serem detectados porque usam endereços IP válidos, portas válidas e pacotes UDP corretamente formados.
Para implantações em nuvem, esse modelo em camadas funciona particularmente bem. Provedores de nuvem como AWS e Azure incluem proteção DDoS na camada de rede como parte de sua infraestrutura. Um SBC rodando nessas plataformas se beneficia desse escudo na camada de rede automaticamente, e então adiciona proteção SIP na camada de aplicação por cima, cobrindo ambas as categorias de ataque sem exigir que o operador construa infraestrutura separada de mitigação DDoS.

Implantando um SBC para proteção máxima contra DoS

Prevenção eficaz de DoS não é apenas um conjunto de recursos. Também depende de onde e como o SBC é implantado.
O SBC deve ficar na borda da rede, entre as conexões voltadas para a internet ou operadoras e a infraestrutura de voz interna. Cada conexão SIP externa deve terminar no SBC. Sistemas PBX internos, registrars, servidores de mídia e pontes de conferência devem estar em um segmento de rede separado sem exposição direta à internet. Se um servidor SIP interno tiver um endereço IP público que partes externas possam alcançar diretamente, a proteção DoS do SBC é completamente ignorada para esse servidor.
Alta disponibilidade importa para resiliência contra DoS. Uma configuração de SBC ativo/standby 1+1 (como a opção HA do ProSBC) garante que, se um nó SBC for sobrecarregado ou precisar de reinicialização, o nó standby assume. Isso evita que um ataque DoS se torne uma interrupção total de voz. Para implantações de grau de operadora, o SBC deve suportar capacidade de sessão suficiente para absorver picos de tráfego sem atingir limites de recursos em condições normais. O ProSBC suporta até 60.000 sessões simultâneas por servidor e 350.000 registros de terminais, fornecendo margem significativa acima das cargas operacionais típicas.
Para organizações enfrentando campanhas DDoS persistentes ou sofisticadas, a distribuição geográfica adiciona outra camada. Implantar instâncias de SBC em múltiplas regiões ou zonas de disponibilidade significa que um ataque direcionado a um ponto geográfico não afeta os outros. Combinado com balanceamento de carga baseado em DNS ou redirecionamento SIP, o tráfego pode ser desviado de um SBC sob ataque para instâncias saudáveis.
O ponto de integração entre defesa na camada de rede e na camada de aplicação merece atenção específica. Se você usa um serviço upstream de limpeza DDoS (Cloudflare, AWS Shield ou similar), esse serviço lida com ataques volumétricos na borda da rede. O SBC lida com ataques específicos de SIP que o serviço de limpeza deixa passar porque parecem tráfego UDP legítimo. Esse modelo de duas camadas oferece cobertura abrangente: o serviço de limpeza absorve o ataque de largura de banda bruta, e o SBC filtra o ataque na camada de aplicação que sobrevive.

Perguntas frequentes