RPKI vs engenharia social: como proteger seu BGP quando o firewall humano falha
Em 2025, um ISP latino-americano sofreu um sequestro de rotas BGP que durou quase 40 minutos. O curioso — e preocupante — é que esse provedor tinha RPKI implementado. Tinha ROAs publicados. Tinha filtros em ordem.
O que não tinha era um processo de onboarding seguro para novos clientes BGP.
É o caso documentado pela APNIC no blog no fim de março de 2026, e é leitura obrigatória para qualquer time que opere sessões BGP na América Latina.
O que aconteceu exatamente?
Um atacante se passou por um novo cliente legítimo de trânsito BGP. Passou pelo processo de onboarding do provedor, obteve credenciais válidas e passou a anunciar prefixos que não lhe pertenciam. Como o provedor não validava corretamente a identidade do cliente nem a origem real dos prefixos durante o cadastro, os anúncios passaram pelos filtros iniciais.
O RPKI estava lá. Os ROAs existiam. Mas o atacante não precisou violar o RPKI: explorou a lacuna entre o processo humano e o sistema técnico.
O problema real: o RPKI protege a rota, não o processo
O RPKI (Resource Public Key Infrastructure) é hoje a ferramenta mais robusta que temos para validar se quem anuncia um prefixo tem autorização para fazê-lo. Quando implementado corretamente, um ROA inválido é rejeitado pelos roteadores que praticam Origin Validation.
Mas o RPKI valida a autorização técnica de um AS para anunciar um prefixo. Não valida se a pessoa que configurou essa sessão BGP no seu roteador é quem diz ser.
Essa distinção, aparentemente óbvia, é exatamente o vetor explorado pelo ataque documentado.
Três passos para fechar o ciclo
1. Validação de identidade out of band no onboarding
Todo processo de cadastro de um novo peer ou cliente BGP deve incluir verificação de identidade fora de banda: confirmação por canais separados (e-mail corporativo verificado, videoconferência, ligação para número registrado no RIR correspondente). Não basta receber um formulário web.
2. Correlação entre o AS declarado e os registros do RIR
Antes de ativar qualquer sessão BGP, verifique que:
- O AS-NUMBER declarado pelo cliente está registrado na LACNIC, ARIN, RIPE ou no RIR correspondente
- O contato técnico do registro coincide com quem está fazendo o onboarding
- Os prefixos que o cliente vai anunciar têm ROAs criados antes do processo de cadastro (não depois)
3. Período de carência com monitored-only
Nos primeiros dias de uma sessão BGP nova, configure o peer em modo monitored-only: os anúncios são recebidos e registrados, mas não propagados até o time do NOC revisar manualmente. É uma fricção operativa mínima com alto retorno em segurança.
O estado do RPKI na América Latina
Segundo dados da LACNIC de 2025, a adoção de RPKI na região segue crescendo, mas a validação de origem (ROV — Route Origin Validation) nos roteadores dos provedores ainda é irregular. Muitos ISPs têm ROAs criados mas não praticam ROV ativo, ou seja, mesmo com RPKI parcialmente implementado, um anúncio inválido pode se propagar.
O mapa de adoção de RPKI na América Latina mostra avanços importantes no Brasil, Argentina e Colômbia, mas lacunas significativas no restante da região.
O que a Ayuda.LA pode fazer pela sua rede
Na Ayuda.LA trabalhamos com ISPs e empresas hiperconectadas na implementação e auditoria de segurança de roteamento:
- Auditoria BGP: revisamos sua configuração de filtros, ROAs e políticas de roteamento para identificar lacunas antes que um atacante as encontre
- Implementação de RPKI end-to-end: desde a criação de ROAs até a ativação de ROV nos seus roteadores de borda
- Desenho de processo de onboarding seguro: ajudamos a construir um processo de cadastro de clientes BGP que combine validação técnica com verificação humana
Se sua rede opera sessões BGP e você ainda não auditou o processo de onboarding, este é o momento.
Quer saber como sua rede está configurada frente a esse tipo de ataque? Fale com nosso time para uma auditoria de roteamento BGP.
Referências: