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.
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:
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.
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.
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:
Histórico: arquivos compactados BGP para algum intervalo de tempo no passadoa. Arquivos RouteViews e RIPE RIS BGP
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)
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.