Assine para receber notificações de novos posts:

Como detectamos vazamentos de rota e o novo serviço de vazamento de rota do Radar da Cloudflare

2022-11-23

9 min. de leitura
Este post também está disponível em English, 繁體中文, Français, Deutsch, 日本語, Español e 简体中文.

Hoje apresentamos os dados e a API de vazamento de rota do Radar da Cloudflare para que qualquer pessoa possa obter informações sobre vazamentos de rota na internet. Construímos um sistema abrangente que coleta dados de fontes públicas e a visão da internet da Cloudflare extraída de nossa enorme rede global. Agora, o sistema alimenta dados de vazamento de rota nas páginas ASN do Radar da Cloudflare e por meio da API.

How we detect route leaks and our new Cloudflare Radar route leak service

Este post do blog está dividido em duas partes. Há uma discussão sobre vazamentos de rota e BGP, seguida de detalhes de nosso sistema de detecção de vazamento de rota e como ele alimenta o Radar da Cloudflare.

Sobre BGP e vazamentos de rota

O roteamento entre domínios, ou seja, a troca de informações de acessibilidade entre as redes, é fundamental para o bem-estar e o desempenho da internet. O Border Gateway Protocol (BGP) é o protocolo de roteamento de fato que troca informações de roteamento entre organizações e redes. Basicamente, o BGP assume que as informações trocadas são genuínas e dignas de confiança, o que infelizmente não é mais uma suposição válida na internet atual. Em muitos casos, as redes podem cometer erros ou mentir intencionalmente sobre as informações de acessibilidade e propagar isso para o restante da internet. Tais incidentes podem causar interrupções significativas nas operações normais da internet. Um tipo de incidente perturbador são os vazamentos de rota.

Consideramos vazamentos de rota como a propagação de anúncios de roteamento além do escopo pretendido (RFC7908). Vazamentos de rotas podem causar interrupções significativas que afetam milhões de usuários da internet, como vimos em muitos incidentes notáveis anteriores. Por exemplo, em junho de 2019, uma configuração incorreta em uma pequena rede na Pensilvânia, EUA (AS396531 – Allegheny Technologies Inc) vazou acidentalmente um prefixo da Cloudflare para a Verizon, que passou a propagar a rota configurada incorretamente para o restante de seus peers e clientes. Como resultado, o tráfego de grande parte da internet foi espremido por meio de links de capacidade limitada de uma pequena rede. O congestionamento resultante fez com que a maior parte do tráfego da Cloudflare de e para o intervalo de IPs afetado fosse descartado.

Um incidente semelhante em novembro de 2018 causou indisponibilidade generalizada dos serviços do Google quando um provedor nigeriano (AS37282 – Mainone) vazou acidentalmente um grande número de prefixos de IP do Google para seus peers e provedores, violando o princípio valley-free.

Esses incidentes ilustram não apenas que os vazamentos de rota podem ser muito impactantes, mas também os efeitos de bola de neve que configurações incorretas em pequenas redes regionais podem ter na internet global.

Apesar da importância de detectar e corrigir vazamentos de rota imediatamente, eles geralmente são detectados apenas quando os usuários começam a relatar os efeitos perceptíveis dos vazamentos. O desafio de detectar e prevenir vazamentos de rota decorre do fato de que as relações de negócios de AS e as políticas de roteamento de BGP geralmente não são divulgadas, e a rede afetada geralmente está distante da raiz do vazamento de rota.

Nos últimos anos, algumas soluções foram propostas para evitar a propagação de rotas vazadas. Tais propostas incluem RFC9234 e ASPA, que estende o BGP para anotar sessões com o tipo de relacionamento entre as duas redes AS conectadas para permitir a detecção e prevenção de vazamentos de rota.

Uma proposta alternativa para implementar sinalização semelhante de funções de BGP é por meio do uso de Comunidades BGP; um atributo transitivo usado para codificar metadados em anúncios BGP. Embora essas direções sejam promissoras no longo prazo, elas ainda estão em estágios muito preliminares e não se espera que sejam adotadas em escala tão cedo.

Na Cloudflare, desenvolvemos um sistema para detectar eventos de vazamento de rota automaticamente e enviar notificações a vários canais para visibilidade. À medida que continuamos nossos esforços para trazer dados mais relevantes ao público, temos o prazer de anunciar que iniciamos uma API de dados aberta para nossos resultados de detecção de vazamento de rota hoje e integramos os resultados às páginas do Radar da Cloudflare.

Definição e tipos de vazamento de rota

Antes de falar sobre como projetamos nossos sistemas, vamos fazer uma introdução rápida sobre o que é um vazamento de rota e por que é importante detectá-lo.

Consultamos o documento publicado IETF RFC7908 "Problem Definition and Classification of BGP Route Leaks" para definir vazamentos de rota.

> Um vazamento de rota é a propagação de anúncios de roteamento além do escopo pretendido.

O escopo pretendido geralmente é definido de forma concreta como políticas de roteamento entre domínios com base em relacionamentos de negócios entre Sistemas Autônomos (ASes). Essas relações comerciais são classificadas de forma ampla em quatro categorias: clientes, provedores de trânsito, peers e irmãos, embora acordos mais complexos sejam possíveis.

Em um relacionamento cliente-provedor, o AS cliente tem um acordo com outra rede para transitar seu tráfego para a tabela de roteamento global. Em um relacionamento peer-to-peer, dois ASes concordam em trocar livremente o tráfego bilateral, mas apenas entre seus próprios IPs e os IPs de seus clientes. Finalmente, ASes que pertencem à mesma entidade administrativa são considerados irmãos e sua troca de tráfego geralmente é irrestrita.  A imagem abaixo ilustra como os três principais tipos de relacionamento se traduzem em políticas de exportação.

Ao categorizar os tipos de relacionamentos de nível AS e suas implicações na propagação de rotas BGP, podemos definir várias fases de anúncios de origem de um prefixo durante a propagação:

  • upward: todos os segmentos de caminho durante esta fase são do cliente para o provedor

  • peering: um segmento de caminho peer-peer

  • downward: todos os segmentos de caminho durante esta fase são do provedor para o cliente

Um caminho AS que segue o princípio de roteamento valley-free terá as fases upward, de peering e downward, todas opcionais, mas devem estar nessa ordem. Aqui está um exemplo de um caminho AS que está em conformidade com o roteamento valley-free.

No RFC7908, "Problem Definition and Classification of BGP Route Leaks", os autores definem seis tipos de vazamentos de rota e nos referimos a essas definições em nosso projeto de sistema. Aqui estão as ilustrações de cada um dos tipos de vazamento de rota.

Tipo 1: Curva em gancho com prefixo completo

> Um AS multihomed aprende uma rota de um provedor upstream e simplesmente a propaga para outro provedor upstream (a curva se assemelha a um grampo de cabelo).  Nem o prefixo nem o caminho AS na atualização são alterados.

Um caminho AS que contém um segmento provedor-cliente e cliente-provedor é considerado um vazamento tipo 1. O exemplo a seguir: AS4 → AS5 → AS6 forma um vazamento tipo 1.

O tipo 1 é o tipo de vazamento de rota mais reconhecido e é muito impactante. Em muitos casos, uma rota de cliente é preferível a uma rota peer ou de provedor. Neste exemplo, o AS6 provavelmente prefere enviar tráfego via AS5 em vez de suas outras rotas de peer ou provedor, fazendo com que o AS5 se torne involuntariamente um provedor de trânsito. Isso pode afetar significativamente o desempenho do tráfego relacionado ao prefixo vazado ou causar interrupções se o AS que vazou não for provisionado para lidar com um grande fluxo de tráfego.

Em junho de 2015, a Telekom Malaysia (AS4788), um provedor regional, vazou mais de 170 mil rotas aprendidas de seus provedores e peers para seu outro provedor Level3 (AS3549, agora Lumen). A Level3 aceitou as rotas e as propagou ainda mais para suas redes downstream, o que, por sua vez, causou problemas de rede importantes no mundo todo.

Tipo 2: Vazamento Provedor-Provedor-Provedor lateral

O vazamento do tipo 2 é definido como rotas de propagação obtidas de um peer para outro peer, criando dois ou mais segmentos de caminho peer-to-peer consecutivos.

Aqui está um exemplo: AS3 → AS4 → AS5 forma um vazamento tipo 2.

Um exemplo desses vazamentos é: mais de três redes muito grandes que aparecem em sequência. Redes muito grandes (como Verizon e Lumen) não compram trânsito umas das outras, e ter mais de três dessas redes no caminho em sequência geralmente é uma indicação de vazamento de rota.

No entanto, no mundo real, não é incomum ver várias pequenas redes de peering trocando rotas e passando umas para as outras. Existem motivos comerciais legítimos para ter esse tipo de caminho de rede. Estamos menos preocupados com esse tipo de vazamento de rota do que com o tipo 1.

Tipos 3 e 4: rotas do provedor para peer; rotas de peer para o provedor

Esses dois tipos envolvem a propagação de rotas de um provedor ou peer não para um cliente, mas para outro peer ou provedor. Aqui estão as ilustrações dos dois tipos de vazamentos:

Como no exemplo mencionado anteriormente, um provedor nigeriano que faz peering com o Google vazou acidentalmente sua rota para seu provedor AS4809 e, assim, gerou um vazamento de rota tipo 4. Como as rotas por meio de clientes geralmente são preferidas a outras, o grande provedor (AS4809) redirecionou seu tráfego para o Google por meio de seu cliente, ou seja, o vazamento de ASN, sobrecarregou o pequeno provedor e derrubou o Google por mais de uma hora.

Resumo do vazamento de rota

Até agora, examinamos os quatro tipos de vazamentos de rota definidos no RFC7908. O ponto comum dos quatro tipos de vazamentos de rota é que todos eles são definidos usando relacionamentos AS, ou seja, peers, clientes e provedores. Resumimos os tipos de vazamentos categorizando a propagação do caminho AS com base em onde as rotas são aprendidas e propagadas. Os resultados são mostrados na tabela a seguir.

Roteia de/propaga para

Routes from / propagates to To provider To peer To customer
From provider Type 1 Type 3 Normal
From peer Type 4 Type 2 Normal
From customer Normal Normal Normal

Para provedor

Para peer

Para cliente

De provedor

Tipo 1

Tipo 3

Normal

De peer

Tipo 4

Tipo 2

Normal

De cliente

Normal

Normal

Normal

Podemos resumir toda a tabela em uma única regra: rotas obtidas de um AS não cliente só podem ser propagadas para clientes.

Observação: vazamentos de rota tipo 5 e tipo 6 são definidos como re-originação de prefixo e anúncio de prefixos privados. O tipo 5 está mais relacionado aos sequestros de prefixo, para os quais planejamos expandir nosso sistema nas próximas etapas. Os vazamentos do tipo 6 estão fora do escopo deste trabalho. Os leitores interessados podem consultar as seções 3.5 e 3.6 do RFC7908 para obter mais informações.

O sistema de vazamento de rota do Radar da Cloudflare

Agora que sabemos o que é um vazamento de rota, vamos falar sobre como projetamos nosso sistema de detecção de vazamento de rota.

A partir de um nível muito alto, compartimentamos nosso sistema em três componentes diferentes:

  1. Módulo de coleta de dados brutos: responsável por coletar dados BGP de várias fontes e fornecer fluxo de mensagens BGP para consumidores downstream.

  2. Módulo de detecção de vazamentos: responsável por estabelecer se um determinado caminho de nível AS é um vazamento de rota, estimar o nível de confiança da avaliação, agregando e fornecendo todas as evidências externas necessárias para análise posterior do evento.

  3. Módulo de armazenamento e notificação: responsável por fornecer acesso a eventos de vazamento de rota detectados e enviar notificações às partes relevantes. Isso também pode incluir a criação de um painel para facilitar o acesso e a pesquisa de eventos históricos e fornecer a interface do usuário para análise de alto nível do evento.

Módulo de coleta de dados

Existem três tipos de entrada de dados que levamos em consideração:

  1. Histórico: arquivos compactados BGP para algum intervalo de tempo no passadoa. Arquivos RouteViews e RIPE RIS BGP

  2. Tempo semi-real: arquivos BGP arquivados assim que ficam disponíveis, com um atraso de 10 a 30 minutosa. Arquivos RouteViews e RIPE RIS com corretor de dados que verifica novos arquivos periodicamente (por exemplo, BGPKIT Broker)

  3. Tempo real: fontes de dados verdadeiras em tempo reala. RIPE RIS Liveb. Fontes BGP internas da Cloudflare

Para a versão atual, usamos a fonte de dados em tempo semi-real para o sistema de detecção, ou seja, os arquivos de atualizações BGP do RouteViews e RIPE RIS. Para integridade dos dados, processamos dados de todos os coletores públicos desses dois projetos (um total de 63 coletores e mais de 2.400 peers de coletores) e implementamos um pipeline capaz de lidar com o processamento de dados BGP à medida que os arquivos de dados ficam disponíveis.

Para indexação e processamento de arquivos de dados, implantamos uma instância local do BGPKIT Broker com o recurso Kafka habilitado para passagem de mensagens e um pipeline de processamento de dados MRT simultâneo personalizado com base no BGPKIT Parser Rust SDK. O módulo de coleta de dados processa arquivos MRT e converte os resultados em um fluxo de mensagens BGP em mais de dois bilhões de mensagens BGP por dia (aproximadamente 30 mil mensagens por segundo).

Detecção de vazamento de rota

O módulo de detecção de vazamento de rota funciona no nível de anúncios BGP individuais. O componente de detecção investiga uma mensagem BGP por vez e estima a probabilidade de uma determinada mensagem BGP ser resultado de um evento de vazamento de rota.

Baseamos nosso algoritmo de detecção principalmente no modelo valley-free, que acreditamos poder capturar a maioria dos incidentes de vazamento de rota notáveis. Como mencionado anteriormente, a chave para ter baixos falsos positivos na detecção de vazamentos de rota com o modelo valley-free é ter relacionamentos precisos no nível AS. Embora esses tipos de relacionamento não sejam divulgados por todos os AS, temos mais de duas décadas de pesquisa sobre a inferência dos tipos de relacionamento usando dados BGP observados publicamente.

Embora os algoritmos de inferência de relacionamento de última geração tenham se mostrado altamente precisos, mesmo uma pequena margem de erro ainda pode incorrer em imprecisões na detecção de vazamentos de rota. Para aliviar tais artefatos, sintetizamos várias fontes de dados para inferir relacionamentos de nível AS, incluindo os dados de relacionamento AS de CAIDA/UCSD e nosso conjunto de dados de relacionamento AS construído internamente. Com base nos dois relacionamentos de nível AS, criamos um conjunto de dados muito mais granular nos níveis por prefixo e por peer. O conjunto de dados aprimorado nos permite responder a perguntas como qual é a relação entre AS1 e AS2 em relação ao prefixo P observado pelo peer coletor X. Isso elimina grande parte da ambiguidade para casos em que as redes têm vários relacionamentos diferentes com base em prefixos e localizações geográficas , e assim nos ajuda a reduzir o número de falsos positivos no sistema. Além dos conjuntos de dados de relacionamentos AS, também aplicamos o conjunto de dados AS Hegemony do IHR IIJ para reduzir ainda mais os falsos positivos.

Armazenamento e apresentação de vazamento de rota

Depois de processar cada mensagem BGP, armazenamos as entradas de vazamento de rota geradas em um banco de dados para armazenamento e exploração no longo prazo. Também agregamos anúncios BGP de vazamento de rota individual e agrupamos vazamentos relevantes do mesmo ASN de vazamento em um curto período em eventos de vazamento de rota. Os eventos de vazamento de rota estarão disponíveis para consumo por diferentes aplicativos downstream, como interfaces de usuário da web, uma API ou alertas.

Vazamentos de rota no Radar da Cloudflare

Na Cloudflare, nosso objetivo é ajudar a construir uma internet melhor, e isso inclui compartilhar nossos esforços em monitorar e proteger o roteamento da internet. Hoje, lançamos nosso sistema de detecção de vazamento de rota como beta público.

A partir de hoje, os usuários que acessam as páginas ASN do Radar da Cloudflare encontram a lista de vazamentos de rota que afetam esse AS. Consideramos que um AS é afetado quando o AS que vaza está a um salto dele em qualquer direção, antes ou depois.

A página ASN do Radar da Cloudflare pode ser acessada diretamente via https://radar.cloudflare.com/as{ASN}. Por exemplo, é possível acessar https://radar.cloudflare.com/as174 para visualizar a página de visão geral do Cogent AS174. As páginas ASN agora mostram um cartão dedicado para vazamentos de rota detectados relevantes para o ASN atual dentro do intervalo de tempo selecionado.

Os usuários também podem começar a usar nossa API de dados públicos para pesquisar eventos de vazamento de rota em relação a qualquer ASN. Nossa API é compatível com a filtragem de resultados de vazamento de rota por intervalos de tempo e ASes envolvidos. Aqui está uma captura de tela da página de documentação da API de eventos de vazamento de rota no site de documentos da API recém-atualizado.

Mais informações sobre segurança de roteamento

Planejamos fazer muito mais com a detecção de vazamento de rota. Mais recursos, como uma página de visualização global, notificações de vazamento de rota, APIs mais avançadas, scripts de automação personalizados e conjuntos de dados de arquivo histórico vão ser enviados ao Radar da Cloudflare com o tempo. Seu feedback e sugestões também são muito importantes para que possamos continuar a melhorar nossos resultados de detecção e fornecer dados melhores ao público.

Além disso, vamos continuar expandindo nosso trabalho em outros tópicos importantes de segurança de roteamento da internet, incluindo detecção global de sequestro de BGP (não limitado a nossas redes de clientes), monitoramento de validação RPKI, ferramentas de código aberto e projetos de arquitetura e gateway seguro da web de roteamento centralizado. Nosso objetivo é fornecer os melhores dados e ferramentas para roteamento de segurança para as comunidades, para que possamos construir juntos uma internet melhor e mais segura.

Por enquanto, abrimos uma sala do Radar em nosso servidor Discord para desenvolvedores. Sinta-se à vontade para participar e conversar conosco; a equipe está ansiosa para receber feedback e responder perguntas.

Acesse o Radar da Cloudflare para obter mais informações sobre a internet. Você também pode nos seguir no Twitter para mais atualizações do Radar.

Protegemos redes corporativas inteiras, ajudamos os clientes a criarem aplicativos em escala de internet com eficiência, aceleramos qualquer site ou aplicativo de internet, evitamos os ataques de DDoS, mantemos os invasores afastados e podemos ajudar você em sua jornada rumo ao Zero Trust.

Acesse 1.1.1.1 a partir de qualquer dispositivo para começar a usar nosso aplicativo gratuito que torna sua internet mais rápida e mais segura.

Para saber mais sobre nossa missão de construir uma internet melhor, comece aqui. Se estiver procurando uma nova carreira para trilhar, confira nossas vagas disponíveis.
Cloudflare RadarBGPRouting Security

Seguir no X

Mingwei Zhang|@heymingwei
Vasilis Giotsas|@GVasilis
Celso Martinho|@celso
Cloudflare|@cloudflare

Posts relacionados

27 de setembro de 2024 às 13:00

Network trends and natural language: Cloudflare Radar’s new Data Explorer & AI Assistant

The Cloudflare Radar Data Explorer provides a simple Web-based interface to build more complex API queries, including comparisons and filters, and visualize the results. The accompanying AI Assistant translates a user’s natural language statements or questions into the appropriate Radar API calls....

23 de setembro de 2024 às 13:00

Network performance update: Birthday Week 2024

Since June 2021, we’ve been measuring and ranking our network performance against the top global networks in the world. We use this data to improve our performance, and to share the results of those initiatives. In this post, we’re going to share with you how network performance has changed since our last post in March 2024, and discuss the tools and processes we are using to assess network performance. ...