- Na rede CANTV (AS8048) da Venezuela, ocorreram várias vazamentos de rota BGP (route leak), fazendo com que alguns caminhos de rede fossem propagados de forma anormal
- Segundo dados do Cloudflare Radar, 11 eventos de vazamento foram identificados desde dezembro, e há grande chance de se tratar de um erro técnico causado por políticas de roteamento insuficientes
- Neste caso, o AS8048 retransmitiu para outro provedor, AS52320 (V.tal GlobeNet), rotas recebidas de seu provedor upstream AS6762 (Sparkle), formando uma estrutura típica de vazamento hairpin Tipo 1
- A validação de origem de rota (ROV) baseada em RPKI não é eficaz neste caso, e novos padrões como ASPA (Autonomous System Provider Authorization) e RFC9234 são necessários para evitar esse tipo de vazamento
- Devido à estrutura de confiança do BGP, esse tipo de incidente é comum, e a adoção de tecnologias como ASPA, Peerlock e RFC9234 é fundamental para uma operação segura da Internet
Conceito de vazamento de rota BGP
- BGP (Route Gateway Protocol) é o protocolo que troca rotas entre sistemas autônomos (AS) na Internet
- As relações entre redes são formadas como cliente-provedor (customer-provider) ou peer (peer-peer)
- Vazamento de rota (route leak) é definido na RFC7908 como “a propagação de informações de roteamento além do escopo pretendido”
- Ex.: quando um cliente repassa a outro provedor rotas recebidas de seu provedor
- Esse tipo de vazamento viola a regra de valley-free routing, fazendo com que o tráfego siga caminhos anormais
- Como resultado, podem surgir problemas como congestionamento de rede, latência e perda de tráfego
Caso de vazamento de rota do AS8048 (CANTV)
- O Cloudflare Radar confirmou que o AS8048 (CANTV) retransmitiu para o AS52320 (V.tal GlobeNet) rotas recebidas do AS6762 (Sparkle)
- Trata-se claramente de um vazamento de rota
- A origem das rotas vazadas era o AS21980 (Dayco Telecom), uma rede cliente do AS8048
- A relação entre os dois AS é confirmada como provedor-cliente nos dados do Cloudflare Radar e do bgp.tools
- Nas rotas, o AS8048 aparecia com múltiplos prepends
- Prepend é uma técnica usada para tornar a rota menos atrativa e induzir o tráfego a seguir outros caminhos
- Portanto, a possibilidade de um MITM (ataque man-in-the-middle) intencional é baixa
- O vazamento ocorreu várias vezes entre 15:30 e 17:45 UTC de 2 de janeiro de 2026, e provavelmente foi causado por erro de política de rede ou problema de convergência
- Segundo os registros do Cloudflare Radar, 11 vazamentos semelhantes se repetiram desde dezembro, indicando uma falha contínua de política
Causas técnicas e problemas de política
- É possível que o AS8048 tenha configurado de forma relaxada a política de exportação de roteamento para o provedor AS52320
- Se estiver usando apenas prefix lists baseadas em IRR em vez de tags de comunidade BGP para clientes, pode ocorrer retransmissão incorreta de rotas
- Esse tipo de erro de política pode ser evitado por meio do atributo Only-to-Customer (OTC) da RFC9234
- O OTC define explicitamente os papéis no BGP (cliente, provedor, peer), bloqueando a propagação incorreta de rotas
Papel do RPKI e do ASPA
- A Sparkle (AS6762) não implementou completamente o RPKI Route Origin Validation (ROV),
- mas este incidente é uma anomalia de caminho (path), portanto não pode ser evitado com ROV
- O ASPA (Autonomous System Provider Authorization) fornece validação baseada em caminho
- Cada AS declara a lista de provedores upstream autorizados, permitindo o bloqueio automático de caminhos anormais
- Ex.: se o AS6762 declarar “sem provedor upstream”, outras redes podem rejeitar caminhos incorretos que incluam o AS6762
- O ASPA opera com base em RPKI e tem efeito direto na prevenção de vazamento de rotas
Propostas para construir um BGP mais seguro
- O BGP é, por natureza, um protocolo baseado em confiança, por isso vazamentos causados por erros de política ou falhas operacionais são frequentes
- Se tecnologias como ASPA, RFC9234 e Peerlock/Peerlock-lite forem aplicadas em conjunto, é possível
- fortalecer a validação de caminhos
- bloquear a propagação incorreta de rotas
- melhorar a estabilidade da rede
- O RIPE já oferece suporte à criação de objetos ASPA,
- e os operadores devem encaminhar aos fornecedores de equipamentos de rede pedidos de implementação da RFC9234
- A adoção colaborativa desses padrões é o principal meio de prevenir incidentes de BGP como o caso da Venezuela
1 comentários
Comentários no Hacker News
Achei o rumo dos comentários meio inesperado. Todo mundo fala de medo de empresas americanas, mas isso não parece ter muito a ver com o conteúdo da matéria
O texto da Cloudflare só explica como o BGP funciona e aponta que vazamentos de rota em um ISP venezuelano aconteceram com frequência
Claro, a Cloudflare pode estar errada ou escondendo algo, mas em nenhum ponto o texto diz que eles intervieram diretamente. Fico curioso para saber em que as pessoas estão se baseando para ter tanta certeza
Dito isso, ao olhar para casos como Stuxnet e Dual EC DRBG, não dá para subestimar a capacidade de governos de explorar 0-days
Um amigo meu trabalhou em uma empresa FAANG e disse ter visto o governo receber fluxos de dados diretamente. Backdoors em ISP também são reais (Room 641A)
Se a Cloudflare tivesse cooperado por força de mandado, será que eles poderiam publicar legalmente um texto negando isso?
Então entendo por que existe esse ceticismo de base. A conclusão da Cloudflare de que “isso é um problema antigo e nada demais” parece meio fraca
Também queria saber se existe alguma razão estrutural no BGP para os EUA conseguirem fazer esse tipo de coisa com mais facilidade do que outros países
Hoje a opinião pública sobre o governo americano está tão cínica que até incidentes pequenos viram motivo de suspeita
Ou talvez sejam só contas sociais da Rússia ou da China, mas vai saber
E a reportagem da CNN dizia que Trump mencionou a possibilidade de ação militar até contra aliados
Com o governo atual, eu até acharia mais provável que tivessem se gabado publicamente de um ataque desses. Por isso, por enquanto acredito mais na hipótese de “simples erro de configuração”
Ainda assim, é natural que a desconfiança aumente quando os EUA só aparecem nas notícias falando de ameaça, retirada ou sanção
Eu estava com sono, mas achei o texto interessante. A análise de AS path prepending sustenta bem a hipótese de “acidente”
Se um Estado estivesse tentando interceptar tráfego, não faria sentido alongar a rota de propósito
Provavelmente foi só um erro de configuração de roteamento. O BGP ainda é um sistema baseado em confiança, então um errinho de digitação pode ter impacto global
Um filtro de export ausente parece uma explicação mais plausível do que má intenção
Na prática, também existem atores não estatais tentando manipular tráfego de anúncios
Mesmo assim, do ponto de vista de quem opera rede, esse tipo de erro é comum, e scripts automatizados de ajuste de tráfego às vezes ampliam o problema
No fim, o problema é a fragilidade estrutural do BGP. Segurança e BGP ainda são palavras que não combinam bem
Vale consultar NSA Network Shaping 101, um dos documentos do Snowden
É um documento escrito em 2007 que explica ASIN e controle de tráfego em camada 3
Ele só descreve a estrutura em que o tráfego enviado para certos IPs passa por aquele link
Depois de ler o texto, me deu calafrio perceber de novo o quão profunda é a integração entre empresas americanas e o governo
Eu já sabia disso havia muito tempo, mas desta vez parece que a confiança ruiu de vez. Isso parece um ponto de virada da era atual
Essa infraestrutura de vigilância existe há muito tempo, e o Japão já fazia monitoramento de tráfego em tempo real em 2003
Hoje a tecnologia de DPI é fácil demais de implementar
Quem entra no setor começa de forma ingênua, mas acaba percebendo a proximidade entre governo e empresas e perde a confiança
Depois passa o tempo e uma nova geração repete o mesmo processo
A ideia central do texto é a navalha de Hanlon: suspeitar primeiro de erro, não de malícia
Claro, se a Cloudflare distorceu os fatos, merece crítica, mas ainda não há evidência disso
Pensando na infraestrutura envelhecida da Venezuela, nem parece que seria necessário um ciberataque sofisticado
A realidade é que contratadas corruptas entregaram sistemas ruins
A estrutura de corrupção é um problema muito maior do que ciberataques
No fim, resolvi pagando um técnico que estava trabalhando na rua, mas o número que recebi era de uma empresa de táxi
Nesse ambiente, discutir ataque de BGP parece até meio vazio
Este texto foi uma boa revisão de BGP
Quando eu trabalhava como engenheiro de redes, usava muito BGP community magic,
e talvez tudo fosse bem mais simples se o BGP expressasse só três tipos: provider, customer e peer
É como tirar informações de trânsito e semáforos do Google Maps: o cálculo fica mais fácil, mas o resultado fica péssimo
Uma vez o Google Maps me tirou da rodovia, me fez passar por um estacionamento do Walmart e entrar em outra rodovia
Na época achei que era só um erro de algoritmo, mas se tivesse me mandado passar num drive-thru do McDonald’s eu talvez suspeitasse de conspiração
Neste caso, também parece mais convincente supor um erro simples
Dá um pouco de medo ver a infraestrutura central da internet sendo operada em torno de empresas americanas
Agora outros países também precisam construir estruturas independentes
A pergunta é: quem deveria administrar isso no lugar?
Observo incidentes de BGP há muito tempo, e sempre acho difícil distinguir entre mudança intencional, erro e falha estrutural
Por isso, primeiro faço três perguntas: o escopo do impacto foi crescendo, as rotas mudaram de forma simétrica, e a recuperação foi limpa?
Depois olho primeiro para mudanças em AS-path prepending e comparo a visibilidade por região
Por fim, tento rastrear “quem se beneficiou”. Fico curioso para saber que indicadores os outros usam para detectar esse tipo de problema
A cobertura global da Cloudflare é realmente impressionante
Só que eles são uma organização muito orientada por engenharia, então fazem bem esse tipo de análise pública