RPKI e filtros de prefixo: a segurança do BGP

Atualizado em 16/10/2026

Ilustração de uma caixa de terminação de fibra óptica com conectores verdes na parede, ao lado de um rack de rede de escritório
Imagem ilustrativa

O protocolo BGP, que sustenta as rotas de toda a internet mundial, foi concebido originalmente com base em uma premissa de confiança mútua irrestrita, o que historicamente abriu margem para sequestros de rotas (BGP Hijacking) e vazamentos acidentais de prefixos capazes de desviar tráfego de bancos e serviços essenciais. A tecnologia RPKI (Resource Public Key Infrastructure) ajuda a mitigar essa vulnerabilidade estrutural ao introduzir certificados digitais criptografados que atestam, por assinatura digital, qual Sistema Autônomo tem autorização legítima para anunciar cada bloco de endereços IP. Implementar RPKI e filtros rígidos de prefixos é uma medida técnica indispensável para qualquer organização que opere com ASN próprio.

A anatomia de um sequestro de rota (BGP Hijacking)

No funcionamento tradicional do BGP, quando um roteador anuncia para seus vizinhos que possui o caminho para um bloco IP específico, os roteadores vizinhos aceitam esse anúncio sem checagem de propriedade e o propagam para o restante da internet.

Isso cria brechas críticas:

  • Erros de configuração (route leaks): um operador, em outro país, configura mal os seus filtros e repropaga rotas além do escopo pretendido, ou passa a anunciar como seus os blocos de IP da sua empresa (origem indevida, parecida com um sequestro de prefixo). Em ambos os casos, o tráfego pode ser desviado.
  • Ataques deliberados de sequestro: criminosos virtuais anunciam um bloco de IP com uma máscara de sub-rede mais específica (por exemplo, um prefixo /24 enquanto o anúncio legítimo é um /22). Pela regra da rota mais longa do BGP, o tráfego do mundo inteiro passa a ser direcionado para o servidor do invasor, permitindo interceptação de dados confidenciais ou interrupção completa de serviços.

Como o RPKI funciona na prática

O RPKI estabelece uma Infraestrutura de Chaves Públicas ancorada diretamente nos registros regionais de alocação de IPs (como o Registro.br no Brasil e o LACNIC na América Latina).

O sistema opera em duas frentes complementares:

1. Criação do ROA (Route Origin Authorization)

O detentor legítimo do bloco IP acessa o painel do registro oficial e assina digitalmente um documento criptográfico chamado ROA. O ROA declara explicitamente: "O bloco IP 203.0.113.0/24 só pode ser originado pelo ASN 65530, com comprimento máximo de máscara /24". Esse certificado assinado é publicado em repositórios públicos distribuídos e atualizados constantemente.

Essa proteção é igualmente indispensável para blocos IPv6 (RFC 6482). Ao assinar um ROA para o seu prefixo IPv6 alocado pelo Registro.br (exemplo: 2001:db8:cafe::/48 com comprimento máximo /48 para o seu ASN), anúncios espúrios ou vazamentos de prefixos mais específicos passam a ser classificados como Invalid, permitindo que operadoras e pontos de troca com validação ROV ativa descartem as rotas ilegítimas na internet global (veja o artigo Quando a empresa precisa de ASN próprio).

2. Validação de Origem (ROV — Route Origin Validation)

Os roteadores de borda de provedores e empresas em todo o mundo consultam servidores validadores locais que sincronizam esses certificados. Ao receber um anúncio BGP de uma rota, o roteador classifica o anúncio em três estados possíveis:

  • Valid (Válido): o ASN de origem e o tamanho do prefixo coincidem perfeitamente com o ROA assinado.
  • Invalid (Inválido): o anúncio conflita frontalmente com um ROA registrado (por exemplo, outro ASN tentando anunciar o mesmo IP ou anúncio com máscara proibida). O roteador descarta a rota imediatamente, impedindo o sequestro.
  • NotFound (Não Encontrado): o proprietário do bloco IP ainda não gerou o ROA correspondente, de modo que a rota segue as regras tradicionais sem validação criptográfica.

Exemplo de configuração de validação no roteador de borda

Roteadores corporativos conectam-se a validadores RPKI locais (como Routinator ou StayRTR) via protocolo RTR (RPKI-to-Router):

rpki server 192.168.10.5
  port 8282
  refresh 3600
!
route-map BGP-IN deny 10
  match rpki invalid
!
route-map BGP-IN permit 20

Com essa política ativa, tentativas de anunciar seus prefixos de forma espúria passam a ser rejeitadas pelas redes que validam RPKI, hoje uma parte crescente dos grandes provedores.

A defesa em profundidade: Filtros IRR e MANRS

O RPKI é indispensável, mas atua em conjunto com outras camadas de segurança essenciais:

  • Bancos de Dados IRR (Internet Routing Registry): registros textuais padronizados (como RADB, TC e Registro.br) onde as empresas documentam suas políticas de trânsito e listas de prefixos autorizados.
  • Iniciativa MANRS (Mutually Agreed Norms for Routing Security): programa global de governança de segurança de roteamento que estabelece quatro pilares obrigatórios: filtragem rigorosa de prefixos, prevenção de spoofing com validação de endereço de origem (uRPF), coordenação facilitada de contatos técnicos e implantação ampla de RPKI.

Adotar esses mecanismos assegura que a sua infraestrutura corporativa não seja apenas uma consumidora da internet, mas uma cidadã digital responsável que fortalece a estabilidade da malha global.

Precisa de ajuda?

Para auditar o roteamento BGP da sua empresa, emitir seus certificados ROAs no Registro.br e configurar validação RPKI no seu roteador de borda, consulte nossas soluções na página de arquiteturas.

Fontes

Tecnologias com que trabalhamos

Ver todas

Imprimir ou salvar em PDF

Papel ideal: A4 retrato

Para baixar o arquivo, escolha "Salvar como PDF" na janela de impressão.