RPKI para provedor de internet: como proteger seu AS contra BGP hijacking

Um unico anuncio BGP errado pode derrubar servicos inteiros, desviar trafego para um atacante ou fazer seu provedor sumir do mapa por horas. O BGP hijacking — quando alguem anuncia prefixos que nao lhe pertencem — e uma das falhas mais antigas e mais ativas da internet, e a principal defesa tecnica contra ele se chama RPKI.

Neste guia voce entende o que e RPKI, o que e ROA, por que provedores brasileiros precisam implementar agora, como funciona a validacao de rotas BGP na pratica e como a Baronix ajuda provedores a protegerem seu AS com consultoria especializada em BGP e roteamento.

O que e RPKI e por que existe

RPKI significa Resource Public Key Infrastructure. Em termos simples, e uma infraestrutura de chaves publicas que permite comprovar, de forma criptografica, que um bloco de IPs realmente pertence ao AS (Autonomous System) que o anuncia no BGP.

O BGP, por design, confia nas rotas que recebe. Se um AS vizinho anunciar um prefixo que nao e dele, o BGP nao tem mecanismo nativo para questionar. E exatamente essa brecha que o RPKI fecha: ele cria uma camada de validacao de origem baseada em certificados digitais assinados pelos RIRs (Regional Internet Registries), como o LACNIC na America Latina.

O RPKI e definido pelos RFCs 6480 a 6492 e hoje e considerado uma boa pratica obrigatoria por grandes exchanges, CDNs e provedores de transito IP em todo o mundo.

O que e ROA (Route Origin Authorization)

O ROA e o objeto digital que o RPKI valida. Ele associa tres informacoes:

• Prefixo IP autorizado (ex.: 200.0.113.0/24);
• AS de origem autorizado a anuncia-lo (ex.: AS65500);
• maxLength: o tamanho maximo de prefixo que pode ser anunciado (ex.: /24).

O ROA e assinado pelo LACNIC e publicado em um repositorio publico. Quando seu roteador de borda recebe uma rota BGP, o validador RPKI consulta esse repositorio e classifica a rota em tres estados:

• Valid: a rota tem ROA e a origem confere — pode ser aceita;
• Invalid: a rota tem ROA, mas a origem ou o maxLength nao confere — deve ser descartada;
• NotFound: nao existe ROA para o prefixo — comportamento padrao (aceita, mas sem garantia).

A decisao de descartar rotas Invalid e o que efetivamente bloqueia o hijacking. Sem essa politica, o RPKI apenas observa o problema sem agir.

Por que provedores brasileiros precisam de RPKI agora

Tres forcas tornaram o RPKI urgente para provedores no Brasil:

1. Exposicao a hijacking. Incidentes de sequestro de rotas continuam ocorrendo globalmente, muitas vezes por configuracao errada, mas tambem por acao maliciosa. Sem RPKI, seu provedor pode tanto ser vitima quanto fonte involuntaria de um vazamento de rotas.
2. Pressao dos pares e exchanges. O IX.br (PTT) e grandes CDNs (Google, Netflix, Cloudflare) ja adotam validacao RPKI. Provedores sem ROA correm o risco de ter rotas rejeitadas por pares que operam em modo strict, perdendo peering e qualidade.
3. Boas praticas LACNIC e NIC.br. O LACNIC, responsavel pelos recursos da America Latina, mantem o sistema RPKI ativo e recomenda a adocao. O NIC.br e a comunidade brasileira de redes tambem incentivam a implementacao como padrao de maturidade operacional.

Implementar RPKI hoje e protecao, mas tambem e credibilidade: demonstra que seu AS opera com governanca de roteamento e reduz o risco de ser bloqueado por pares mais maduros.

Como implementar RPKI passo a passo

A implementacao do RPKI em um provedor segue um fluxo tecnico claro. Nao e um tutorial de comandos (cada fabricante tem sua sintaxe), mas o caminho logico e o mesmo em qualquer ambiente:

1. Inventariar prefixos e AS

Levante todos os blocos IPv4 e IPv6 que seu provedor anuncia no BGP, o ASN titular de cada bloco e os prefixos efetivamente anunciados na tabela global. Esse inventario e a base para criar os ROAs corretos.

2. Criar os ROAs no LACNIC

Acesse o portal do LACNIC com a conta do titular do recurso, na secao RPKI, e crie um ROA para cada prefixo: informe o prefixo, o AS de origem e o maxLength. O LACNIC assina e publica o objeto no repositorio RPKI. Em minutos o ROA fica visivel para os validadores do mundo todo.

Atencao ao maxLength: definir maxLength igual ao prefixo base (ex.: /24 para um /24) e mais seguro. Definir maxLength muito amplo (ex.: /24 permite /25, /26...) abre espaco para anuncios mais especificos nao autorizados.

3. Configurar a validacao nos roteadores de borda

Habilite a validacao RPKI nos roteadores de borda (Cisco IOS-XR, Juniper Junos, MikroTik RouterOS v7, Huawei VRP). O roteador precisa de um canal com o validador (RPKI-to-Router protocol, RTR) ou validacao local, dependendo do fabricante.

Configure a politica de rota para descartar rotas Invalid (reject) e aceitar Valid e NotFound. A transicao pode ser feita em modo monitor-only antes de descartar de fato, para medir o impacto.

4. Testar em homologacao antes de produzir

Antes de aplicar a politica de descarte em producao, valide em ambiente de homologacao ou em uma sessao BGP de baixo impacto. Confira quantas rotas seriam rejeitadas e se alguma rota legitima seria afetada (o que indicaria um ROA mal configurado).

5. Monitorar continuamente

RPKI nao e configurar e esquecer. Monitore a tabela BGP, os contadores de rotas Valid/Invalid/NotFound, e o repositorio RPKI. Ferramentas como observabilidade de redes (Zabbix, Grafana) ajudam a detectar mudancas de estado e incidentes de roteamento em tempo real.

RPKI e BGP: validacao de rotas na pratica

Na pratica, a validacao RPKI atua no momento em que seu roteador recebe uma rota de um peer ou upstream. O fluxo e:

1. O peer anuncia um prefixo com uma origem (AS);
2. O roteador consulta o validador RPKI (via protocolo RTR);
3. O validador retorna o estado (Valid, Invalid, NotFound);
4. A politica de rota aplica: aceita Valid e NotFound, descarta Invalid.

O resultado concreto e que rotas sequestradas sem ROA valido sao descartadas antes de entrar na sua tabela, impedindo que trafego seja desviado. Isso protege tanto seu provedor (ninguem anuncia seus prefixos sem autorizacao) quanto seus clientes (voce nao aceita rotas falsas de terceiros).

Para provedores com multihoming BGP, a validacao RPKI e ainda mais relevante: quanto mais upstreams e pares, maior a superficie de exposicao a rotas indevidas.

Erros comuns ao implementar RPKI

• maxLength amplo demais. Permitir /24 quando se anuncia /24 e mais seguro do que permitir /24 com maxLength /24 que abre para /25+. Defina o maxLength igual ao prefixo efetivamente anunciado.
• ROA para prefixo que nao se anuncia. Criar ROA para blocos que estao apenas alocados, mas nao anunciados, nao protege nada e pode confundir pares.
• Aplicar descarte sem teste. Ir direto para reject em producao sem periodo de monitoramento pode derrubar rotas legitimas se houver ROA errado. Sempre valide antes.
• Esquecer de renovar/revogar. Se um bloco for devolvido ou transferido, o ROA correspondente precisa ser revogado. ROAs obsoletos podem bloquear o novo titular.
• Nao combinar com outros mecanismos. RPKI valida origem, mas nao substitui prefix-list, max-prefix e filtros por RIR. Use em conjunto.

RPKI vs prefix-list e max-prefix

RPKI nao substitui os controles tradicionais de BGP — ele os complementa. A tabela abaixo resume o papel de cada um:

A estrategia recomendada e camadas de defesa: RPKI para validar origem, prefix-list para limitar o que cada peer pode anunciar, max-prefix para conter vazamentos em volume, e monitoramento para detectar anomalias. E exatamente essa combinacao que aplicamos em projetos de consultoria tecnica para provedores.

Como a Baronix ajuda provedores a implementar RPKI

A Baronix atua na implementacao de RPKI para provedores de internet em todo o Brasil, como parte da nossa consultoria de BGP e roteamento. Nosso trabalho inclui:

• Inventario de prefixos, AS e anuncios BGP;
• Criacao e publicacao de ROAs no LACNIC, com definicao correta de maxLength;
• Configuracao de validacao RPKI em roteadores Cisco, Juniper, MikroTik, Huawei e Fortinet;
• Definicao de politica de descarte (reject) com periodo de monitoramento antes de produzir;
• Testes em homologacao e validacao de impacto;
• Integracao com monitoramento e observabilidade para detectar mudancas de estado RPKI;
• Treinamento da equipe do provedor e documentacao da configuracao.

Atuamos em multivendor, com suporte N2/N3 especializado em BGP, e combinamos RPKI com prefix-list, max-prefix e filtros IRR para uma protecao completa. Se seu provedor ainda nao implementou RPKI, este e o momento — antes que um incidente de roteamento force a decisao.

FAQ — perguntas frequentes sobre RPKI para provedores

Conclusao

RPKI deixou de ser opcional para provedores que querem operar com seguranca e credibilidade. Com ROAs publicados no LACNIC e validacao ativa nos roteadores de borda, seu AS fica protegido contra BGP hijacking, suas rotas sao aceitas por pares mais maduros e sua operacao ganha um padrao de maturidade que o mercado de redes ja exige.

A implementacao nao e complexa quando feita com metodo: inventario, ROAs, validacao, testes e monitoramento. Se sua equipe precisa de apoio especializado em BGP e roteamento, fale com a Baronix para um diagnostico tecnico sem compromisso.