Validação de origem de rotas: guia prático para provedores
Validação de origem de rotas: é o roteador de borda conferir cada rota recebida contra os ROAs publicados no RPKI e descartar as inválidas. O provedor instala um ou dois validadores, liga os roteadores a eles e aplica a política de recusar o que vier com origem errada.
Resumo
- O validador baixa e confere os ROAs do mundo todo e entrega ao roteador uma lista simples de prefixo, tamanho e ASN.
- O roteador marca cada rota recebida como válida, inválida ou não encontrada, e a política decide o que fazer.
- A conversa entre validador e roteador usa o protocolo RTR, e dois validadores evitam depender de um servidor só.
- Antes de recusar qualquer rota, alguns dias só marcando as inválidas mostram o impacto real na sua base.
O que a validação de origem de rotas confere
Ela confere se a rede que originou um anúncio tinha autorização para anunciar aquele prefixo com aquele tamanho. O resultado é um estado para cada rota, que a política de entrada transforma em aceitar ou recusar.
Um programa validador baixa os ROAs do mundo inteiro, confere as assinaturas e entrega ao roteador uma lista simples de prefixo, tamanho e ASN. O roteador compara cada rota recebida via BGP com essa lista e dá a ela um estado.
Esse trabalho acontece inteiro no seu equipamento e nos seus servidores, sem passar por portal nenhum. A implantação de RPKI para provedores junta essa parte com a publicação dos ROAs dos seus blocos.
| Estado | Significado | Política |
|---|---|---|
| Válido | Existe ROA e o ASN e o tamanho batem | Aceitar |
| Inválido | Existe ROA, mas o ASN ou o tamanho não batem | Recusar |
| Não encontrado | Não existe ROA para o prefixo | Aceitar |
Publicar ROAs e validar rotas são tarefas diferentes
Publicar ROAs no RPKI protege os seus blocos dos erros e ataques dos outros; validar protege os seus assinantes de rotas sequestradas que chegam até você. Uma não substitui a outra, e muitos provedores fazem só a primeira.
Se os seus prefixos ainda não têm ROA, comece pela criação de ROAs, que acontece no portal do registro. Este guia trata só do lado do roteador.
Como funciona a validação de origem de rotas?
Os validadores montam a lista de origens autorizadas a partir dos repositórios públicos e a entregam aos roteadores pelo protocolo RTR. Cada roteador aplica essa lista às rotas que recebe, sessão por sessão.
1 · Repositórios
ROAs publicados
Os registros de cada região publicam os ROAs assinados pelos titulares dos blocos.
2 · Validador
Confere as assinaturas
O validador baixa tudo em ciclos, descarta o que não fecha a cadeia e monta a lista de origens.
3 · RTR
Entrega a lista
O roteador recebe a lista e as atualizações seguintes pela sessão RTR com cada validador.
4 · Política
Decide o que entra
Cada rota ganha um estado, e a política de entrada recusa as inválidas.
O roteador nunca baixa certificados nem confere assinaturas. Ele só compara rotas com uma lista pronta.
A validação de origem de rotas faz uma pergunta só: o ASN de origem e o tamanho do prefixo batem com alguma autorização publicada? O caminho que a rota percorreu até chegar não entra na conta.
Por que uma rota fica inválida?
Imagine uma autorização para 198.51.100.0/22, tamanho máximo 22, origem AS 64500. A tabela mostra como o roteador classifica anúncios diferentes desse mesmo bloco.
| Anúncio recebido | Origem | Estado | Motivo |
|---|---|---|---|
| 198.51.100.0/22 | AS 64500 | Válido | Prefixo e origem conferem |
| 198.51.100.0/22 | AS 64666 | Inválido | Origem diferente da autorizada |
| 198.51.101.0/24 | AS 64500 | Inválido | Mais específico que o tamanho máximo |
| 203.0.113.0/24 | AS 64777 | Não encontrado | Nenhum ROA cobre esse bloco |
Rota válida não quer dizer rota legítima
O estado válido diz só que a origem confere. Um atacante que forja o caminho e coloca o ASN certo no fim dele passa pela validação, e por isso ela convive com filtros de prefixo e limites por vizinho.
Na prática, a validação elimina os incidentes mais frequentes, que são erros de configuração em outras redes anunciando blocos que não são delas. Ataques mais elaborados pedem outras camadas além desta.
Qual validador instalar?
Qualquer um dos três validadores livres mais usados resolve, e a escolha pesa menos que a redundância. O que importa é rodar dois, fora do roteador e em lugares diferentes.
O validador roda num servidor ou máquina virtual, fora do roteador. Use dois, em POPs distintos, para que a falha de um não deixe a borda sem lista.
- Routinator: mantido pela NLnet Labs, com interface web e protocolo RTR.
- rpki-client: do projeto OpenBSD, leve e muito usado.
- FORT: desenvolvido com apoio do LACNIC e do NIC México.
Os roteadores conversam com o validador pelo protocolo RTR, normalmente na porta 3323 ou 8282. Libere essa porta só para os roteadores.
Relógio e monitoramento do servidor
Certificado é conferido contra a data, e um servidor com relógio atrasado ou adiantado passa a recusar assinaturas boas. Sincronize o validador com NTP e inclua a hora dele no monitoramento.
Acompanhe também a quantidade de registros que cada validador entrega e a idade da última atualização. Uma queda brusca no número de registros costuma indicar falha de download, e não mudança real na internet.
Onde rodar os dois validadores?
O lugar ideal é perto das bordas, mas sem depender da mesma energia ou do mesmo link. A tabela compara as opções mais comuns num provedor regional.
| Opção | Vantagem | Cuidado |
|---|---|---|
| VM em cada POP principal | Falha de um POP não leva os dois | Precisa de acesso à internet para baixar os repositórios |
| Dois servidores no mesmo POP | Instalação e manutenção mais simples | Queda de energia ou de link derruba os dois juntos |
| Contêiner no servidor de monitoramento | Aproveita máquina que já existe | Disputa recursos com outros serviços e some junto com eles |
Configuração de referência no roteador de borda
O exemplo liga o roteador a dois validadores e recusa rotas inválidas vindas do trânsito. As rotas válidas e as não encontradas seguem para a próxima regra da política.
router bgp 64500
bgp rpki server tcp 192.0.2.10 port 3323 refresh 600
bgp rpki server tcp 192.0.2.11 port 3323 refresh 600
address-family ipv4
neighbor 192.0.2.1 route-map TRANSITO-IN in
!
route-map TRANSITO-IN deny 10
match rpki invalid
route-map TRANSITO-IN permit 20As duas linhas bgp rpki server criam as sessões RTR com os validadores. No route-map, a entrada 10 recusa o que vier marcado como inválido, e a 20 deixa passar o restante para os filtros que já existem no roteador de borda.
Comece observando
Antes de recusar, rode alguns dias só marcando as inválidas. Assim você vê quantas rotas seriam descartadas e confirma que nenhum cliente seu está entre elas.
Prefere ativar com acompanhamento?
Na implantação de RPKI, um Especialista instala os validadores no seu ambiente, liga cada borda e conduz a fase de observação até a política de descarte entrar.
A política em cada tipo de sessão
A mesma regra entra nas sessões de trânsito, nas do IX.br e nas de clientes com ASN próprio. Cliente que anuncia prefixo inválido para você estaria espalhando um erro, e a recusa protege o resto da sua base.
Nas sessões com os servidores de rotas do ponto de troca, a validação também vale, mesmo que eles já filtrem do lado deles. Veja a configuração de sessões com route servers para os detalhes dessas sessões.
E as sessões IPv6?
A lista entregue pelo validador já traz as origens IPv6, mas a política precisa ser aplicada também na família IPv6 de cada sessão. No exemplo acima, isso significa repetir o route-map na address-family ipv6.
É um esquecimento comum porque o tráfego IPv6 costuma ser menor. Mesmo assim, uma rota IPv6 sequestrada leva os assinantes para o lugar errado do mesmo jeito.
Validação de origem de rotas passo a passo, sem susto
A ordem abaixo evita derrubar destinos legítimos no primeiro dia. A recusa é a última etapa, e só entra depois de a observação mostrar que nenhuma rota importante seria perdida.
- Crie os seus ROAs primeiro: veja a criação de ROAs.
- Instale os validadores: dois servidores, com monitoramento.
- Ligue os roteadores: confira se a sessão RTR sobe e se a lista chega.
- Observe: marque inválidas sem recusar e analise a lista.
- Recuse: aplique a política nas sessões de trânsito, IX.br e clientes.
Validação de origem não segura ataque volumétrico. Para conter um ataque sem descartar todo o tráfego do destino, veja a configuração de FlowSpec.
Exemplo: o que a fase de observação revela
Durante a observação, um provedor encontra entre as inválidas um prefixo de um cliente corporativo que anuncia com ASN próprio. O cliente tinha criado o ROA com tamanho máximo menor do que o anúncio.
Se a recusa estivesse ligada, esse cliente perderia a conexão com toda a sua base no mesmo instante. Com a observação, o provedor avisa o cliente, espera a correção e só então liga a política.
Erros comuns na validação de origem
Os erros mais comuns têm a ver com depender de uma peça só ou com aplicar a política de forma incompleta. Quase nenhum aparece no primeiro dia, e por isso passam despercebidos.
Evite
- Um único validador sem monitoramento.
- Validador com relógio errado, que rejeita certificados válidos.
- Recusar rotas não encontradas, o que derruba boa parte da internet.
- Esquecer de aplicar a política nas sessões IPv6.
- Ligar a recusa sem passar pela fase de observação.
- Aplicar a política só no trânsito e esquecer IX.br e clientes.
Validador parado e proteção perdida em silêncio
Quando os dois validadores param de responder, o roteador mantém a lista por um tempo e depois a descarta. As rotas passam a não encontradas e são aceitas, e a rede segue funcionando sem proteção nenhuma.
Como nada cai, ninguém percebe sem alerta. Monitore a sessão RTR em cada borda e trate a queda dela como incidente, do mesmo jeito que uma sessão BGP fora do ar.
Checklist depois de ativar a validação
Confira o funcionamento logo depois de ativar e depois de qualquer atualização dos validadores. O teste final é ver uma rota inválida de verdade sendo recusada.
Marque o que já foi conferido na borda
- As sessões RTR estão ativas nos dois validadores.
- O número de registros recebidos é parecido nos dois.
- Rotas inválidas aparecem recusadas no roteador.
- A política está aplicada em IPv4 e IPv6, em todas as sessões externas.
- Existe alerta para queda da sessão RTR.
- Um teste público de validação mostra o provedor como protegido.
Item sem marca deixa a borda aceitando origem falsa em algum caminho. Corrija antes de considerar a implantação encerrada.
A Táquion Tech instala os validadores no ambiente do provedor, configura cada borda e acompanha a fase de observação até a política de recusa entrar, seguindo as ações de filtragem recomendadas pelo MANRS.
Perguntas frequentes sobre validação de origem de rotas
O que acontece se o validador cair?
Depois de um tempo, as rotas passam a não encontradas e são aceitas. A rede não para, mas perde a proteção até um validador voltar.
Recusar inválidas derruba clientes meus?
Só se algum destino legítimo estiver com ROA errado. A fase de observação mostra isso antes, e dá tempo de avisar o dono do bloco.
Meu roteador suporta validação de origem?
Os principais fabricantes suportam em versões recentes de software. Confira a versão instalada e as notas do fabricante antes de planejar a janela.
Validação de origem impede todo sequestro?
Não. Ela barra origem errada, mas não caminho forjado com a origem certa. É uma camada importante, e não a única.
Validar rotas pesa no processamento do roteador?
O roteador só compara cada rota com uma lista guardada em memória, e o trabalho pesado fica no validador. O consumo extra de memória depende do modelo [CONFIRMAR consumo no equipamento do provedor].
Serviços ligados a este guia
- Monitoramento de BGP para provedores NOC e operação de rede
- Unificação de ASN para provedores Fusões e aquisições
- Assessoria para transferência de blocos IPv4 para provedores IPv6, CGNAT e BNG
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 6811, BGP Prefix Origin Validation: estados válido, inválido e não encontrado.
- RFC 8210, The RPKI to Router Protocol: protocolo entre validador e roteador.
- MANRS, Mutually Agreed Norms for Routing Security: ações recomendadas de segurança de rotas.
