Este artigo foi publicado originalmente no blog de APNIC.
O sequestro do BGP (Border Gateway Protocol) é uma das ameaças de segurança mais persistentes do protocolo. O RPKI e ROV foram padronizados para permitir a autenticação de origem e mitigar a ameaça, mas a implantação da validação de origem de rota (ROV) provavelmente continue sendo parcial na próxima década. A implantação parcial não só deixa lacunas óbvias na proteção, mas também cria uma ameaça sutil, à qual nos referimos como sequestro furtivo de BGP relacionado à ROV (ou simplesmente sequestro furtivo).
(Acesso livre, não requer assinatura)
Em um sequestro furtivo, o sistema autônomo (AS) afetado nunca vê a origem maliciosa no plano de controle, porque os vizinhos que implementam ROV descartam os anúncios inválidos. No entanto, o tráfego ainda pode ser desviado silenciosamente para um atacante por meio de AS legados (sem ROV) presentes ao longo do caminho do plano de dados. Isso faz com que o ataque evite efetivamente os mecanismos de detecção que dependem da visibilidade do plano de controle. Quer dizer, o sequestro de BGP se torna mais furtivo: as tabelas de roteamento e as verificações do RPKI da vítima parecem perfeitamente normais, mesmo quando seu tráfego está sendo desviado.
A seguir, apresentamos um caso real que representa como ocorre um sequestro furtivo.
Figura 1: Incidente de sequestro em 203.127.225.0/24 (visto pela última vez em 24 de abril de 2025). Este incidente foi provavelmente o resultado de uma configuração incorreta não intencional.
Em um sequestro furtivo, o sistema autônomo (AS) afetado nunca vê a origem maliciosa no plano de controle, porque os vizinhos que implementam ROV descartam os anúncios inválidos. No entanto, o tráfego ainda pode ser desviado silenciosamente para um atacante por meio de AS legados (sem ROV) presentes ao longo do caminho do plano de dados. Isso faz com que o ataque evite efetivamente os mecanismos de detecção que dependem da visibilidade do plano de controle. Quer dizer, o sequestro de BGP se torna mais furtivo: as tabelas de roteamento e as verificações do RPKI da vítima parecem perfeitamente normais, mesmo quando seu tráfego está sendo desviado.
A seguir, apresentamos um caso real que representa como ocorre um sequestro furtivo.
Figura 1: Incidente de sequestro em 203.127.225.0/24 (visto pela última vez em 24 de abril de 2025). Este incidente foi provavelmente o resultado de uma configuração incorreta não intencional.
Neste caso, o AS17894, o suposto sequestrador, anunciou de forma errada um prefixo /24, que faz parte de um /16 que o AS3758 possui e origina legitimamente. Tecnicamente, este é um sequestro clássico de um subprefixo.
A sutileza deste caso é como o ROV entra em ação. Na Figura 1, apenas o AS37100 aplica filtragem baseado em ROV. Como o AS37100 descartou a rota inválida do /24, apenas manteve a rota válida do /16 completa em sua tabela de roteamento. Como resultado, o AS37100 e seus clientes não tinham visibilidade da rota inválida no plano de controle. Em outras palavras, o AS37100 e seus clientes não tinham motivos para suspeitar que alguma coisa estava errada. No entanto, seu tráfego para /24 ainda era desviado para o AS17894 através do AS6762 legado, que não executa ROV e aceitou a rota /24 inválida. A menos que sejam notificados ou investiguem ativamente o /24 por algum motivo, eles permaneceriam alheios ao sequestro em andamento.
Evidência do looking glass do AS37100 confirma o incidente. Inspecionamos manualmente o estado do plano de controle e a acessibilidade do plano de dados do AS37100 usando seu looking glass público ‘g-01-ams.nl‘. Todas as observações foram capturadas em 10 de fevereiro de 2025.
Conforme mostrado na Figura 2, ao executar show ip bgp para o /16 foram obtidas duas rotas válidas, ambas originadas pelo titular legítimo AS3758:
Figura 2: Rotas do AS37100 para 203.127.0.0/16.
Para o subprefixo /24, no entanto, show ip bgp não retornou nada (veja a Figura 3), o que significa que o sequestro foi praticamente invisível para o AS37100 no plano de controle:
Figura 3: Rotas do AS37100 para 203.127.225.0/24.
O plano de dados mostrou uma história diferente. Conforme mostrado na Figura 4, um traceroute de AS37100 para 203.127.225.1 foi desviado e terminou no AS17894, confirmando que o tráfego do /24 estava de fato sendo sequestrado (Figura 4).
Figura 4: Traceroute do AS37100 para 203.127.225.1.
A principal conclusão desse incidente é que, se qualquer AS intermediário em seu caminho tiver uma visão das origens diferente da sua, o desvio de tráfego ainda poderia ocorrer, mesmo que sua própria tabela de roteamento pareça boa. E o mais importante: a implantação parcial de ROV está tornando essas inconsistências mais frequentes, o que dificulta potencialmente a detecção de sequestros de BGP.
Além deste caso, conduzimos um estudo empírico e analítico em larga escala sobre o risco de sequestros furtivos de BGP na Internet atual. Os resultados completos serão apresentados no nosso próximo paper em NDSS 2026. Também lançamos um site que publica relatórios diários dos sequestros furtivos detectados.
Com base no que aprendemos, apresentamos alguns insights operacionais e recomendações para os operadores de rede:
Em primeiro lugar, continuar promovendo a implementação do RPKI e ROV. Uma descoberta importante do nosso estudo é que o risco de sequestro furtivo segue uma curva de crescimento e subsequente declínio à medida que a implantação de ROV aumenta. A boa notícia é que os dados atuais sugerem que poderíamos estar entrando na fase de declínio, pelo que uma maior adoção pode reduzir o risco.
Em segundo lugar, prestar atenção ao que você descarta. As rotas inválidas que se filtram ainda podem conter informações valiosas. Monitorá-las e correlacioná-las pode ajudar a identificar possíveis eventos de desvio de tráfego. Uma estratégia de mitigação mais proativa (embora agressiva) poderia ser que os AS que implementam ROV não apenas descartem as rotas inválidas, mas também voltem a executar a seleção de rotas e prefiram aquelas que evitem os AS detectados nos anúncios descartados. (uma política semelhante é descrita em uma patente de Cisco).
Por último, colaborar e compartilhar visibilidade. Os recursos comunitários como RouteViews, RIPE RIS e RIPE Atlas são ferramentas poderosas para melhorar a visibilidade coletiva dos eventos de roteamento. Os AS que implementam ROV poderiam contribuir ainda mais ao compartilhar resumos de “rotas descartadas” (por exemplo, por meio de listas de discussão), fornecendo aos outros alertas antecipados sobre sequestros furtivos. Incentivamos os operadores a participar das discussões, compartilhar experiências operacionais e ajudar a moldar defesas práticas. Como primeiro passo, iniciamos um Internet Draft para documentar formalmente essa ameaça e solicitar o feedback da comunidade.
O sequestro furtivo do BGP é um risco sutil, mas real, na Internet parcialmente segura de hoje. A boa notícia é que, com uma adoção mais ampla do RPKI, melhor monitoramento e maior colaboração, podemos dificultar significativamente o sucesso desses ataques e torná-los mais fáceis de detectar.
Yihao apresentou este tema durante a Sessão Técnica n.o 2 de APNIC 60. Confira a gravação da sessão agora, incluindo o debate com o público.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
