Um olhar mais atento sobre uma anomalia do BGP na Venezuela

À medida que se desenrolam as notícias em torno da captura e prisão do líder venezuelano Nicolás Maduro pelos EUA, um boletim informativo sobre segurança cibernética examinado Radar Cloudflare dados e tomou nota de um vazamento de roteamento na Venezuela em 2 de janeiro.

Nós investigamos os dados. Desde o início de dezembro ocorreram onze eventos de vazamento de rota, impactando múltiplos prefixos, onde AS8048 é o vazador. Embora seja impossível determinar definitivamente o que aconteceu no dia do evento, este padrão de fugas de rotas sugere que a rede CANTV (AS8048), um fornecedor de serviços de Internet (ISP) popular na Venezuela, tem políticas de exportação e importação de rotas insuficientes. Em outras palavras, as anomalias do BGP observadas pelo pesquisador podem estar ligadas a práticas técnicas inadequadas do ISP, e não a prevaricação.

Nesta postagem, discutiremos brevemente o Border Gateway Protocol (BGP) e os vazamentos de rota BGP e, em seguida, nos aprofundaremos na anomalia observada e no que pode ter acontecido para causá-la.

Primeiro, vamos revisitar o que é Vazamento de rota BGP é. Vazamentos de rota BGP causam comportamento semelhante a pegar a saída errada de uma rodovia. Embora você ainda possa chegar ao seu destino, o caminho pode ser mais lento e apresentar atrasos que você não teria ao viajar em uma rota mais direta.

Os vazamentos de rota receberam uma definição formal em RFC7908 como “a propagação de anúncios de roteamento além do escopo pretendido”. O escopo pretendido é definido usando aos pares relações comerciais entre redes. As relações entre redes, que no BGP representamos usando Sistemas Autônomos (ASes)pode ser um dos seguintes:

• cliente-provedor: um cliente paga a uma rede de provedor para conectá-lo e a seus próprios clientes downstream ao resto da Internet

• peer-peer: Duas redes decidem trocar tráfego entre si, para os clientes uma da outra, sem liquidação (sem pagamento)

Em um relacionamento cliente-provedor, o fornecedor anunciará todas as rotas até o cliente. O cliente, por outro lado, anunciará apenas as rotas de seus próprios clientes e originados diretamente de sua rede.

Em um relacionamento entre pares, cada par anunciará um para o outro apenas as suas próprias rotas e as rotas dos seus clientes a jusante.

Esses anúncios ajudam a direcionar o tráfego de maneiras esperadas: dos clientes upstream para as redes dos provedores, potencialmente através de um único link de peering, e então, potencialmente, de volta aos clientes na extremidade do caminho de seus provedores.

Um caminho válido seria semelhante ao seguinte, que obedece ao roteamento sem vale regra:

UM vazamento de rota é uma violação do roteamento sem vale, onde um AS pega rotas de um provedor ou peer e as redistribui para outro provedor ou peer. Por exemplo, um caminho BGP nunca deve passar por um “vale” onde o tráfego sobe para um provedor, desce para um cliente e depois sobe novamente para um provedor. Existem diferentes tipos de vazamentos de rota definidos no RFC7908, mas um simples é o Tipo 1: vazamento de rota em gancho entre duas redes de provedores por um cliente.

Na figura acima, o AS64505 pega rotas de um de seus provedores e as redistribui para o outro provedor. Isto é inesperado, pois sabemos que os provedores não devem usar seus clientes como uma rede intermediária de trânsito IP. O AS64505 ficaria sobrecarregado com o tráfego, por ser uma rede menor, com um conjunto menor de backbone e links de rede do que seus provedores. Isso pode se tornar muito impactante rapidamente.

Agora que nos lembramos do que é um vazamento de rota no BGP, vamos examinar a hipótese em a postagem do boletim informativo. A postagem chamou a atenção para um poucas anomalias de vazamento de rota no Cloudflare Radar envolvendo AS8048. No Página de radar para este vazamento, vemos esta informação:

Vemos o vazador AS, que é AS8048 – CANTV, o provedor estatal de serviços de telefonia e Internet da Venezuela. Observamos que as rotas foram retiradas de um de seus provedores AS6762 (Sparkle, uma empresa italiana de telecomunicações) e depois redistribuídas para AS52320 (V.tal GlobeNet, um provedor de serviços de rede colombiano). Este é definitivamente um vazamento de rota.

O boletim informativo sugere “travessuras do BGP” e postula que tal vazamento poderia ser explorado para coletar informações úteis para entidades governamentais.

Embora não possamos dizer com certeza o que causou esse vazamento de rota, nossos dados sugerem que sua causa provável foi mais mundana. Isso ocorre em parte porque vazamentos de rotas BGP acontecem o tempo todo e sempre fizeram parte da Internet – na maioria das vezes por motivos que não são maliciosos.

Para entender mais, vamos examinar mais de perto os prefixos e redes impactados. Os prefixos envolvidos no vazamento foram todos originados pela AS21980 (Dayco Telecom, empresa venezuelana):

Os prefixos também são todos membros do mesmo 200.74.224.0/20 sub-redeconforme observado pelo autor do boletim informativo. Muito mais intrigante do que isso, porém, é a relação entre a rede de origem AS21980 e a rede com vazamento AS8048: AS8048 é um provedor de AS21980.

A relação cliente-provedor entre AS8048 e AS21980 é visível em ambos Radar Cloudflare e bgp.ferramentas Dados de interferência no relacionamento AS. Também podemos obter uma pontuação de confiança do relacionamento AS usando a ferramenta monocle de BGPKITcomo você vê aqui:

➜  ~ monocle as2rel 8048 21980
Explanation:
- connected: % of 1813 peers that see this AS relationship
- peer: % where the relationship is peer-to-peer
- as1_upstream: % where ASN1 is the upstream (provider)
- as2_upstream: % where ASN2 is the upstream (provider)

Data source: https://data.bgpkit.com/as2rel/as2rel-latest.json.bz2

╭──────┬───────┬───────────┬──────┬──────────────┬──────────────╮
│ asn1 │ asn2  │ connected │ peer │ as1_upstream │ as2_upstream │
├──────┼───────┼───────────┼──────┼──────────────┼──────────────┤
│ 8048 │ 21980 │ 9.9%   │ 0.6% │ 9.4%    │ 0.0%         │
╰──────┴───────┴───────────┴──────┴──────────────┴──────────────╯

Embora apenas 9,9% dos coletores de rotas vejam esses dois ASes como adjacentes, quase todos os caminhos que os contêm refletem o AS8048 como um provedor upstream para o AS21980, o que significa que a confiança é alta no relacionamento fornecedor-cliente entre os dois.

Muitas das rotas vazadas também foram fortemente anexadas ao AS8048, o que significa que teria sido potencialmente menos atraente para roteamento quando recebido por outras redes. Anexando é o preenchimento de um AS mais de uma vez em um anúncio de saída feito por um cliente ou peer, para tentar desviar o tráfego de um circuito específico para outro. Por exemplo, muitos dos caminhos durante o vazamento do AS8048 ficaram assim: “52320,8048,8048,8048,8048,8048,8048,8048,8048,8048,23520,1299,269832,21980”.

Você pode ver que o AS8048 enviou seu AS várias vezes em um anúncio para o AS52320, porque por meio da prevenção de loop BGP o caminho nunca entraria e sairia do AS8048 várias vezes seguidas. Um caminho sem prefixo ficaria assim: “52320,8048,23520,1299,269832,21980”.

Se o AS8048 estivesse intencionalmente tentando se tornar um homem do meio (MITM) para o tráfego, por que eles tornariam o anúncio do BGP menos atraente em vez de mais atraente? Além disso, por que vazar prefixos para tentar o tráfego MITM quando você está já um provedor para o AS downstream, afinal? Isso não faria muito sentido.

Os vazamentos do AS8048 também surgiram em vários anúncios separados, cada um com cerca de uma hora de intervalo em 2 de janeiro de 2026, entre 15h30 e 17h45 UTC, sugerindo que eles podem estar tendo problemas de rede que surgiram em um problema de política de roteamento ou em um acidente baseado em convergência.

Vale ressaltar também que esses eventos de vazamento começam mais de doze horas antes do Ataques militares dos EUA na Venezuela. Vazamentos que impactam redes sul-americanas são comunse não temos motivos para acreditar, com base no momento ou em outros fatores que discuti, que o vazamento esteja relacionado à captura de Maduro várias horas depois.

Na verdade, olhando para os últimos dois meses, podemos ver muitos vazamentos do AS8048 que são exatamente como este, o que significa que esta não é uma nova anomalia do BGP:

Você pode ver acima, na história do pipeline de alerta de vazamento de rota do Cloudflare Radar, que o AS8048 não é estranho aos vazamentos de rota curva Tipo 1. Só desde o início de Dezembro houve onze eventos de vazamento de rota onde AS8048 é o vazador.

Disto podemos extrair uma possível explicação mais inocente sobre o vazamento de rota: o AS8048 pode ter configurado políticas de exportação muito flexíveis diante de pelo menos um de seus provedores, o AS52320. E por causa disso, as rotas redistribuídas pertencem ao seu cliente mesmo quando as rotas BGP do cliente direto estavam faltando. Se a sua política de exportação em relação ao AS52320 correspondesse apenas em Gerado por TIR lista de prefixos e não uma cliente BGP comunidade tag, por exemplo, faria sentido porque um caminho indireto em direção ao AS6762 foi vazado de volta ao upstream pelo AS8048.

Esses tipos de erros políticos são algo RFC9234 e o atributo Only-to-Customer (OTC) ajudaria consideravelmente, acoplando o BGP de forma mais estreita às funções cliente-provedor e peer-peer, quando suportado por todos os fornecedores de roteamento. Guardarei os detalhes mais técnicos sobre RFC9234 para uma postagem de acompanhamento no blog.

O boletim informativo também chama de “notável” que Sparkle (AS6762) não implementa RPKI (Infraestrutura de Chave Pública de Recursos) Validação de origem de rota (ROV). Embora seja verdade que o AS6762 parece ter um implantação incompleta do ROV e é sinalizado como “inseguro” em isbgpsafeyet.com por causa dissoa validação da origem não teria evitado esta anomalia do BGP na Venezuela.

É importante separar as anomalias do BGP em duas categorias: origens incorretas de rota e anomalias baseadas em caminho. Saber a diferença entre os dois ajuda a entender a solução de cada um. Originações incorretas de rota, muitas vezes chamadas de sequestros de BGP, devem ser corrigidas pela Validação de Origem de Rota (ROV) RPKI, garantindo que o originador de um prefixo seja quem o possui por direito. No caso da anomalia BGP descrita neste post o AS de origem estava correto como AS21980 e apenas o caminho era anômalo. Isso significa que o ROV não ajudaria aqui.

Sabendo disso, precisamos de validação baseada em caminho. Isto é o que Autorização de provedor de sistema autônomo (ASPA)um futuro rascunho de padrão na IETF, irá fornecer. A ideia é semelhante às autorizações de origem de rota (ROAs) e ROV RPKI: criar um objeto ASPA que defina uma lista de provedores autorizados (upstreams) para nosso AS, e todos usarão isso para invalidar vazamentos de rota na Internet em vários pontos de vantagem. Usando um exemplo concreto, AS6762 é um Camada 1 rede livre de trânsito, e eles usariam o membro especial reservado “AS0” em seu objeto assinado pela ASPA para comunicar ao mundo que não têm provedores upstream, apenas pares laterais e clientes. Então, o AS52320, o outro provedor do AS8048, veria as rotas de seu cliente com “6762” no caminho e as rejeitaria executando um processo de verificação ASPA.

A ASPA é baseada no RPKI e é exatamente o que ajudaria a evitar vazamentos de rotas semelhantes ao que observamos na Venezuela.

Achamos importante oferecer uma explicação alternativa para o vazamento da rota BGP pelo AS8048 na Venezuela que foi observado no radar Cloudflare. É útil entender que os vazamentos de rota são um efeito colateral esperado do BGP, historicamente baseado inteiramente na confiança e na intenção orientada para o relacionamento comercial cuidadosamente executado.

Embora os vazamentos de rotas possam ter sido feitos com intenções maliciosas, os dados sugerem que este evento pode ter sido um acidente causado pela falta de políticas de exportação e importação de rotas que o impediriam. É por isso que, para termos um BGP e uma Internet mais seguros, precisamos trabalhar juntos e impulsionar a adoção do ASPA baseado em RPKI, para o qual RIPE lançou recentemente a criação de objetosna ampla Internet. Será um esforço colaborativo, assim como o RPKI tem sido para validação de origem, mas valerá a pena e evitará incidentes de BGP como o da Venezuela.

Além da ASPA, todos podemos implementar mecanismos mais simples, como Peerlock e Peerlock-lite como operadores, cujas verificações de sanidade receberam caminhos para vazamentos óbvios. Uma iniciativa especialmente promissora é a adoção de RFC9234que deve ser usado em adição ao ASPA para evitar vazamentos de rotas com o estabelecimento de funções BGP e um novo atributo Only-To-Customer (OTC). Se você ainda não solicitou aos seus fornecedores de roteamento que uma implementação do RFC9234 esteja em seu roteiro: por favor fazer. Você pode ajudar a fazer uma grande diferença.