Compreendendo o risco de sequestro furtivo de BGP na era da validação de origem de rota (ROV)
03/11/2025
Por Yihao Chen, 16 de outubro de 2025
Coautores:Qi Li, Ke Xu, Zhuotao Liu, Jianping Wu
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).
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.
(Acesso livre, não requer assinatura)
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.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.