Vazamento de rota da Rostelecom em 2017 e responsabilidade

Sumário

A BGPMon situou o evento AS12389 entre 22:36 e aproximadamente 22:43 UTC em 26 de abril de 2017. Ela contou 50 prefixos afetados em 37 sistemas autônomos. A ThousandEyes usou um quadro diferente: observou 137 prefixos originados pelo AS12389 durante a janela, tratou cerca de 100 como comuns ou associados a organizações russas e identificou 36 prefixos de empresas externas. Esses denominadores descrevem seleções diferentes e não devem ser mesclados. [1][2]
O mecanismo direto de infraestrutura foi a falsa origem e propagação de rotas. Alguns anúncios eram rotas mais específicas. A BGPMon destacou 203.112.90.0/24 contra um /23 normalmente anunciado, uma distinção que ajuda a explicar por que a seleção comum de rotas poderia preferir a rota falsa sem nenhum comprometimento do serviço afetado em si. [2]
A ThousandEyes observou peers incluindo Cogent, Hurricane Electric e Tata aceitando e propagando anúncios do AS12389. Suas medições de caminho mostraram que o tráfego para pelo menos um serviço de comércio eletrônico afetado entrava na Rostelecom e depois continuava até o destino pretendido. Isso suporta o desvio de parte do tráfego de produção, não uma alegação de que toda rota, usuário ou pacote foi desviado. [1]
Serviços financeiros, de pagamento, comércio eletrônico, segurança web e relacionados a certificados estavam representados entre os prefixos afetados. Exemplos nomeados nos relatórios incluíam Mastercard, Visa, BNP Paribas, HSBC, Symantec e GeoTrust. A evidência de roteamento não mostra que os sistemas internos dessas organizações foram comprometidos. [1][2]
A evidência confirmada consiste em observações de origem do AS12389, a curta janela do evento, alguns anúncios mais específicos, propagação por múltiplos peers e mudanças de caminho medidas. Uma falha de roteamento ou configuração é uma explicação plausível. O direcionamento deliberado e a interceptação permanecem disputados. A identidade do ator, o gatilho interno, a inspeção de pacotes, o conteúdo descriptografado, os efeitos na transação, a perda e a remediação duradoura permanecem desconhecidos.
A concentração de destinos financeiros e relacionados à segurança tornou o padrão suspeito para a BGPMon e a ThousandEyes. A BGPMon também observou anúncios envolvendo outros sistemas autônomos relacionados à Rostelecom, o que suporta uma falha interna acidental como hipótese concorrente. Nenhuma das organizações de monitoramento tinha os registros internos de mudança, autenticação ou configuração do operador. [1][2]
A responsabilidade segue o controle prático, não uma conclusão não fundamentada sobre motivo. A Rostelecom controlava a criação e exportação de rotas dentro do AS12389. Os peers aceitadores controlavam filtros, validação, aceitação de rota e propagação. Os detentores de prefixo controlavam dados de autorização, monitoramento externo e escalação. Monitores independentes controlavam a qualidade e preservação das observações externas.
O RPKI pode ajudar uma rede a avaliar se uma origem é autorizada por uma Autorização de Origem de Rota correspondente, mas não prova intenção ou o mecanismo interno. O evento também antecede a aplicação ampla da Validação de Origem de Rota. O estado histórico do ROA de cada prefixo afetado e a política de validação de cada peer teriam que ser estabelecidos antes de afirmar que o RPKI teria bloqueado uma rota específica. [11]-[14][18]
O dano suportado é uma perda temporária do controle de roteamento pretendido e exposição de parte do tráfego a um caminho de trânsito não autorizado. O registro não estabelece fraude de transação, credenciais roubadas, comprometimento de TLS, dados alterados, uma interrupção total, uma população afetada quantificada ou dano financeiro. A criptografia pode reduzir a exposição de conteúdo, mas a evidência disponível não estabelece quais sessões usaram criptografia eficaz.
Um relato decisivo exigiria registros que observações públicas de roteamento não podem fornecer: logs de mudança e autenticação do AS12389, um relatório de causa raiz, logs de filtro e seleção de rota de peers, análise reproduzível de arquivos, estado histórico do ROA, tráfego do lado do serviço e registros de TLS, capturas de pacotes, registros de incidentes de clientes e evidências sobre se os caminhos medidos transportavam tráfego de produção.

Sete minutos criaram um problema de evidência duradouro

O evento foi curto, mas sua estrutura probatória permanece importante. A BGPMon situou o início às 22:36 UTC e o fim por volta das 22:43 UTC em 26 de abril de 2017. Durante esse intervalo, coletores de rotas e sistemas de monitoramento viram o AS12389 anunciar acessibilidade para espaços de endereço associados a outros sistemas autônomos. Múltiplas redes externas aceitaram pelo menos alguns desses anúncios e os propagaram. A ThousandEyes também mediu caminhos fim a fim alterados, em vez de depender apenas de atualizações do plano de controle. [1][2]

Essas observações estabelecem mais do que uma vaga anomalia de roteamento. Elas identificam um sistema autônomo de origem, uma janela de tempo, prefixos anunciados, propagação e uma consequência de caminho. Dados de roteamento distribuídos podem, portanto, sustentar uma conclusão forte sobre o que foi informado à Internet: o AS12389 se apresentou como origem para rotas que não faziam parte de seu conjunto autorizado comum, incluindo espaço de endereço usado por organizações fora da Rostelecom.

As mesmas observações estabelecem menos do que muitas descrições implicam. Uma atualização BGP não contém o motivo do operador. Um caminho alterado não revela quem inseriu um comando, qual sistema o gerou, se uma conta foi mal utilizada ou se uma configuração planejada escapou de seu escopo pretendido. Mesmo um conjunto suspeito de destinos não revela a decisão interna que produziu o conjunto.

A distinção é importante porque as palavras usadas para descrever um incidente de roteamento podem silenciosamente importar uma conclusão. "Vazamento" pode descrever a propagação de rotas que não deveriam ter sido exportadas. "Sequestro" pode descrever falsa origem ou uma rota que desvia tráfego, mas muitas vezes é ouvido como prova de intenção hostil. O registro observável suporta anúncios de origem falsa e desvio de tráfego. Ele não estabelece, por si só, apreensão deliberada, espionagem ou um plano para atingir instituições financeiras.

Avaliações posteriores da CERT-EU e da ENISA colocaram o evento em discussões mais amplas sobre sequestro de BGP e risco de segurança de roteamento. Essas descrições são úteis como avaliações institucionais atribuídas. Elas não substituem logs não divulgados do AS12389, registros de políticas de peers ou evidências de tráfego do lado do serviço. [4]-[6]

O teste de responsabilidade apropriado começa com essa assimetria. Evidências públicas de roteamento podem ser observadas e reproduzidas de forma independente. A causa e o propósito internos dependem em grande parte de registros controlados pelo operador originador e por outras redes participantes. Quanto mais forte for a evidência externa de uma mudança de roteamento, mais específicas se tornam as perguntas internas não respondidas. No entanto, a evidência externa não deve ser esticada até respostas que ela não pode fornecer.

É por isso que um evento de sete minutos pode permanecer não resolvido anos depois. A retirada encerrou a condição imediata de roteamento. Não fechou a lacuna de evidência. A recuperação operacional e a explicação pública são deveres separados: uma restaura o roteamento, enquanto a outra mostra como a falha surgiu, que tráfego foi exposto, por que os controles não o contiveram e o que mudou depois.

Os dois contadores de prefixo respondem a perguntas diferentes

A BGPMon contou 50 prefixos afetados em 37 sistemas autônomos. A ThousandEyes relatou que o AS12389 originou 137 prefixos durante a janela relevante e, em seguida, separou cerca de 100 que pareciam comuns ou associados a organizações russas de 36 prefixos pertencentes a organizações externas. [1][2]

Os números são próximos o suficiente para tentar um número único de manchete e diferentes o suficiente para tornar essa jogada não confiável. A contagem de 50 prefixos da BGPMon diz respeito ao seu conjunto afetado em 37 sistemas autônomos. A ThousandEyes começou com todos os 137 prefixos originados pelo AS12389 observados e depois os classificou para isolar 36 prefixos de empresas externas. Cada organização usou suas próprias observações e método de seleção. O registro público fornecido aqui não define uma conversão que transforme um denominador no outro.

Isso não é um detalhe estatístico menor. As contagens fazem parte da alegação causal. Um número para todos os anúncios vistos de um sistema autônomo não é o mesmo que um número para origens falsas suspeitas. Um número para prefixos não é um número para organizações vítimas, serviços, usuários, sessões ou pacotes. Um número para sistemas autônomos não é um número para entidades legais. Combinar essas unidades pode transformar uma anomalia de rota limitada em uma estimativa populacional não fundamentada.

A formulação responsável preserva ambas as medições e nomeia o que elas medem. A BGPMon observou 50 prefixos afetados em 37 sistemas autônomos. A ThousandEyes observou 137 prefixos originados pelo AS12389, tratou cerca de 100 como provavelmente comuns ou associados à Rússia e identificou 36 prefixos de empresas externas. A diferença pode refletir pontos de vista, temporização, classificação e escolhas de contagem, mas essas explicações permanecem possibilidades a menos que uma comparação reproduzível as demonstre.

A reconstrução histórica pode melhorar essa posição. O trabalho revisado por pares de Moriano e coautores usou dados históricos do BGPStream, enquanto a CAIDA descreve o acesso do BGPStream ao material arquivado do Route Views e do RIPE RIS. Essas fontes tornam a reanálise reproduzível possível em princípio. Elas não apagam a necessidade de documentar a cobertura do coletor, limites de tempo, filtros de prefixo e regras de classificação. [7][8]

A disciplina de contagem é um controle de responsabilidade porque limita a exagero. Uma resposta de operador, um monitor externo e uma avaliação institucional devem todos divulgar seu denominador. Se seus números diferirem, a tarefa é reconciliar métodos ou preservar a diferença, não escolher o número que faz o evento parecer maior ou menor.

Rotas mais específicas explicam por que a seleção comum poderia desviar o tráfego

BGP é o sistema interdomínios através do qual as redes trocam alegações sobre acessibilidade a blocos de endereços IP. O mecanismo crucial do evento não foi meramente que o AS12389 apareceu em algum lugar em um caminho inesperado. Foi observado como a origem de rotas para espaço de endereço associado a outros sistemas autônomos. Algumas dessas rotas eram mais específicas do que as rotas de cobertura normalmente usadas para o mesmo espaço de endereço. [1][2]

A BGPMon destacou 203.112.90.0/24, enquanto o anúncio normal cobria um /23. Um /24 descreve um bloco de endereço menor que um /23. Roteadores comumente preferem a rota mais específica para tráfego cujo destino está dentro desse bloco menor. Essa preferência ocorre antes de muitas outras comparações de melhor caminho. O /24 falso poderia, portanto, atrair tráfego mesmo que o /23 legítimo permanecesse visível.

Esse mecanismo é importante para a disciplina de atribuição. Um caminho desviado não exige prova de que um banco remoto, serviço de pagamento ou provedor relacionado a certificados foi violado. O sistema de seleção de rota pode enviar tráfego em direção à origem falsa porque a rede recebeu e preferiu uma alegação de acessibilidade mais específica. A organização afetada pode continuar operando seus próprios sistemas normalmente enquanto alguns usuários alcançam esses sistemas através de um caminho de trânsito não intencional.

A observação mais específica também distingue o evento de uma alegação vaga de que o AS12389 simplesmente redistribuiu uma rota com um caminho mais longo ou incomum. O RFC 7908 fornece uma estrutura de classificação de vazamento de rota, e o RFC 7454 fornece orientação operacional de segurança e filtragem. Esses padrões ajudam os operadores a descrever falhas e controles de política de rota. Eles não determinam, a partir da evidência pública sozinha, qual ação interna gerou os anúncios de abril de 2017 ou se a ação foi intencional. [9][10]

Uma análise de responsabilidade deve separar criação, exportação, aceitação e seleção. Primeiro, uma rota foi criada ou introduzida dentro do AS12389. Segundo, o AS12389 a exportou para vizinhos. Terceiro, alguns vizinhos a aceitaram e propagaram. Quarto, roteadores downstream a selecionaram de acordo com suas informações e políticas locais. Quinto, pelo menos parte do tráfego medido seguiu o caminho resultante.

Cada etapa tem um proprietário de evidência diferente. Registros de geração e autenticação de rota estariam mais próximos da origem. Logs de política de exportação e sessão mostrariam o que o AS12389 enviou para qual vizinho. Registros de peers mostrariam aceitação, filtragem e seleção local. Arquivos de coletores mostrariam o que alcançou pontos de vista externos. Medições ativas mostrariam efeitos de caminho fim a fim. Operadores de serviço teriam evidências de tráfego e aplicação.

Essa cadeia impede uma atribuição simplista de toda responsabilidade a um lugar. O AS12389 foi a origem falsa observada e controlou a primeira exportação. Os peers não criaram a rota, mas a aceitação e propagação ampliaram seu alcance. Os detentores de prefixo não causaram o anúncio, mas sua postura de autorização e monitoramento poderia afetar a detecção e rejeição. Nenhum participante controlou toda a Internet, mas vários controlaram pontos específicos onde o evento poderia ter sido prevenido, limitado ou explicado.

Medições de caminho provam desvio, não intenção de interceptação

Observações do plano de controle mostram quais rotas foram anunciadas. Medições de caminho adicionam evidência sobre para onde o tráfego viajou. A ThousandEyes relatou que alguns peers, incluindo Cogent, Hurricane Electric e Tata, aceitaram e propagaram os anúncios do AS12389. Suas medições para pelo menos um serviço de comércio eletrônico afetado indicaram que o tráfego entrou na rede da Rostelecom e depois continuou até o destino pretendido. [1]

Essa forma de caminho é importante. Ela suporta mais do que um risco teórico de que uma rota falsa poderia atrair tráfego. Indica que o tráfego de produção medido seguiu um caminho de trânsito não autorizado. O caminho não terminou simplesmente no AS12389 no exemplo citado; o tráfego depois alcançou o destino pretendido. Isso é consistente com desvio seguido de entrega adiante.

A medição não suporta uma afirmação universal. Nem toda rede aceitou ou preferiu a rota. A ThousandEyes observou que a aceitação variou. Um caminho visto de um ou mais pontos de medição não pode ser expandido em uma alegação sobre todos os usuários, todas as redes de origem ou todos os pacotes. As decisões de roteamento variam por localização, provedor, temporização e política.

Nem a entrega adiante prova interceptação. O tráfego passando por uma rede não intencional cria uma oportunidade para observação ou interferência, mas oportunidade não é evidência de que a inspeção ocorreu. Os dados de caminho disponíveis não mostram captura de pacotes, acesso a conteúdo, modificação, coleta de credenciais ou manipulação de transações. Eles não identificam um sistema de interceptação ou um operador que o usou.

A criptografia complica ainda mais a avaliação de danos. A criptografia eficaz pode limitar o que uma rede de trânsito não intencional pode ler ou alterar, mas o registro público de roteamento não estabelece o estado de segurança de cada sessão afetada. A presença de serviços financeiros e relacionados a certificados não prova que a criptografia falhou. Também não prova que cada conexão foi protegida corretamente. Registros de TLS do lado do serviço, telemetria de sessão e evidências de pacotes seriam necessários para uma conclusão mais específica.

O dano suportado mais seguro é, portanto, uma perda de controle de caminho pretendido e exposição temporária de parte do tráfego a um caminho de trânsito não autorizado. Essa é uma consequência real de segurança de rede, mesmo sem prova de comprometimento de conteúdo. Usuários e operadores de serviço dependem do roteamento interdomínios para entregar tráfego através de relações de acessibilidade esperadas. Uma origem falsa pode quebrar esse limite de controle enquanto mantém servidores de aplicação e sessões criptografadas intactos.

Essa distinção protege tanto a responsabilidade quanto a precisão. Minimizar o evento porque nenhum roubo de dados foi provado ignora o desvio de rota demonstrado. Chamar o evento de interceptação porque o tráfego cruzou a Rostelecom trata uma capacidade possível como um ato consumado. A evidência suporta a posição intermediária: o desvio ocorreu para o tráfego medido; inspeção, descriptografia, alteração e exploração permanecem desconhecidos.

Quatro classes de evidência mantêm a atribuição honesta

O evento é melhor compreendido através de quatro classes de evidência: confirmada, provável, disputada e desconhecida. Misturar essas classes é o principal caminho de uma observação técnica para uma acusação não fundamentada.

A evidência confirmada inclui as observações de origem do AS12389, a janela de 22:36 a aproximadamente 22:43 UTC, anúncios falsos, algumas mais específicas, propagação por múltiplos peers e mudanças de caminho medidas. As categorias e exemplos de serviços nomeados também são suportados quando vinculados aos relatórios de monitoramento. Essas conclusões dependem de observações distribuídas, em vez de acesso aos sistemas privados da Rostelecom. [1][2]

Explicações prováveis devem permanecer condicionais. Uma falha interna de roteamento ou configuração é um candidato plausível de causa raiz. A BGPMon observou anúncios simultâneos envolvendo outros sistemas autônomos relacionados à Rostelecom, um padrão que pode suportar a hipótese de um erro interno mais amplo, em vez de um conjunto de alvos externos cuidadosamente limitado. A evidência não estabelece a configuração exata, comando ou sistema que falhou.

Interpretações disputadas dizem respeito ao direcionamento deliberado e à intenção de interceptação. A concentração de destinos financeiros, de pagamento, comércio eletrônico e relacionados à segurança, combinada com rotas mais específicas recém-introduzidas, tornou o padrão suspeito para a BGPMon e a ThousandEyes. Suspeita é relevante porque molda a resposta a incidentes e a preservação de evidências. Não é uma constatação de propósito.

Desconhecidos incluem quem iniciou a mudança, se essa pessoa estava autorizada, o mecanismo interno exato, a razão para os prefixos selecionados, se os pacotes foram inspecionados, se algum conteúdo foi descriptografado, se as transações foram afetadas, se os usuários perderam dados ou dinheiro, a população afetada completa sob um método de medição comum e que remediação durável ocorreu.

A CERT-EU e a ENISA posteriormente usaram enquadramentos mais fortes orientados a ameaças em suas discussões institucionais. Essas avaliações merecem atribuição precisa porque órgãos públicos usam incidentes passados para explicar o risco de roteamento. Seu enquadramento não cria acesso a logs de mudança do AS12389 ou registros de pacotes de serviço afetado. Um rótulo categórico posterior não deve ser tratado como nova evidência primária sobre a intenção de 2017 de um operador. [4]-[6]

A revisão anual de segurança de roteamento da Internet Society coloca o episódio dentro de um padrão muito maior de incidentes de roteamento e preocupações de prevenção. Esse contexto ajuda a mostrar por que o caso importa além de um operador. Não deve achatar o evento em uma estatística genérica ou responder suas perguntas de atribuição não resolvidas. [3]

Uma escada de evidência esclarece o que justificaria uma linguagem mais forte. Atualizações de rota distribuídas podem estabelecer falsa origem. Dados de propagação de múltiplos pontos de vista podem estabelecer alcance. Medições ativas de caminho podem estabelecer desvio de pontos de vista particulares. Logs de serviço podem estabelecer conexões recebidas, estado TLS e efeitos de aplicação. Capturas de pacotes podem estabelecer conteúdo de tráfego e modificação dentro de seu escopo. Logs de mudança e autenticação do operador podem identificar ação interna.

Uma investigação de causa raiz pode conectar esses registros à responsabilidade e intenção.

O registro público de abril de 2017 atinge os três primeiros níveis para partes do evento. Não atinge os níveis posteriores. Esse limite permite uma responsabilidade operacional firme sem atribuir um motivo não fundamentado. A Rostelecom pode ser responsabilizada por explicar rotas originadas e exportadas pelo AS12389, mesmo quando o direcionamento deliberado não é comprovado. Os peers podem ser solicitados a explicar aceitação e propagação, mesmo que não tenham criado as rotas. Os detentores de prefixo podem ser solicitados sobre autorização e monitoramento sem implicar que causaram o incidente.

A evidência de atribuição também deve ser simétrica. A evidência que suporta uma hipótese hostil deve ser preservada, incluindo concentração de alvos e anúncios mais específicos. A evidência que suporta uma hipótese de falha acidental também deve ser preservada, incluindo anúncios envolvendo sistemas autônomos relacionados. Um relato crível explica por que uma hipótese se encaixa melhor ou afirma que o registro disponível não pode decidir entre elas.

Essa disciplina não é indecisão. Ela atribui responsabilidade clara por ações observáveis, enquanto se recusa a inventar o estado mental por trás delas. Em incidentes de roteamento, essa é muitas vezes a diferença entre análise responsável e narrativa geopolítica.

O AS12389 controlou a evidência interna mais probatória

A Rostelecom, como operadora do AS12389, controlava o sistema que os observadores públicos viram originando e exportando as rotas. Isso não prova que a alta administração dirigiu o evento ou que um indivíduo agiu intencionalmente. Isso identifica a organização mais próxima do processo de geração de rotas e da evidência mais capaz de explicá-lo.

Os controles relevantes começam antes da exportação. Permissões de geração de rota determinam quais contas, sistemas e fluxos de trabalho podem introduzir um prefixo no processo de roteamento. A revisão de mudança pode exigir uma segunda verificação em modificações sensíveis ou incomumente amplas. Listas de permissão de prefixo podem restringir anúncios de clientes e infraestrutura ao espaço de endereço esperado. A política de saída pode parar uma rota que não deve sair do sistema autônomo. O monitoramento pode detectar uma origem inesperada ou um conjunto repentino de anúncios mais específicos.

Procedimentos de retirada podem reduzir a exposição após a detecção.

Estas são categorias de controle, não alegações sobre a configuração exata do AS12389 em abril de 2017. O registro público não divulga quais controles existiam, quais falharam ou quais foram contornados. Também não divulga se o conjunto de rotas veio de um comando manual, automação, uma sessão de cliente, um erro interno de redistribuição, credenciais comprometidas ou outro mecanismo.

A evidência do operador deve conectar as categorias. O histórico de configuração poderia mostrar o que mudou. Registros de autenticação poderiam mostrar qual conta ou sistema fez a alteração. Registros de aprovação poderiam mostrar se ela foi autorizada. Logs de sessão e exportação BGP poderiam mostrar quais rotas foram enviadas para quais vizinhos. Registros de alerta poderiam mostrar quando a equipe soube pela primeira vez. Registros de incidente poderiam mostrar quem ordenou a retirada e como o conjunto afetado foi determinado.

A velocidade sozinha não é suficiente. Os anúncios foram retirados após uma janela curta, mas uma duração de sete minutos não revela se o monitoramento funcionou, se um peer levantou um alarme, se um operador percebeu um erro ou se a condição originária terminou automaticamente. Um fim rápido reduz a exposição; não explica a eficácia da detecção ou controle.

A divulgação é o ponto de verificação final do operador de origem. Um relato público útil de incidente distinguiria os fatos de rota observados da constatação de causa raiz do operador. Declararia o escopo de exportação afetado, explicaria se os prefixos foram introduzidos por configuração, automação, um cliente ou outra fonte de rota, identificaria o controle que falhou, descreveria a contenção e daria evidências de remediação limitada. Não precisa expor credenciais, topologia confidencial do cliente ou detalhes exploráveis.

Sem esse relato, observadores externos ainda podem atribuir responsabilidade operacional pela origem e exportação. Eles não podem atribuir de forma confiável responsabilidade pessoal, intenção ou alocação de falha interna. A assimetria de evidência é em si um fato de responsabilidade: a organização que controlava o processo de rota também controlava os registros necessários para resolver a incerteza mais consequente.

Um operador não pode responder a essa lacuna apontando que o BGP é distribuído. Distribuição significa que o AS12389 não controlou quais redes remotas aceitaram a rota. Não apaga o controle sobre o que o AS12389 originou e exportou. Por outro lado, localizar a falsa origem no AS12389 não apaga o papel dos vizinhos que a propagaram. Responsabilidade prática segue cada ponto de verificação, em vez de colapsar toda a cadeia em um único ator.

Peers aceitadores controlaram o limite de propagação do evento

Uma origem falsa se torna amplamente consequente apenas quando outras redes a aceitam e propagam. A ThousandEyes observou Cogent, Hurricane Electric e Tata entre os peers carregando anúncios do AS12389. Essa observação não mostra a política completa ou processo de decisão dentro de qualquer rede nomeada. Mostra que a aceitação de peers foi parte do caminho da origem ao desvio medido. [1]

A questão de responsabilidade do peer difere da da Rostelecom. Uma rede aceitadora não sabia necessariamente que uma rota era falsa quando chegou, e não criou a alegação original. No entanto, controlava a política de importação local, filtros de cliente e peer, o uso de informações de autorização de rota, alerta de anomalia, exportação adiante e coordenação de emergência.

As responsabilidades de filtragem devem ser descritas com evidências, em vez de assumidas a partir de um rótulo comercial. Uma rede pode tratar um vizinho como cliente, peer ou provedor de trânsito sob sua própria política. As observações públicas não divulgam esses contratos ou as regras de importação de cada sessão. Também não mostram se uma rota passou porque nenhum filtro existia, uma lista de permissão era muito ampla, os dados de registro estavam incompletos, um sinal de validação estava indisponível ou a política local aceitava um aviso.

O RFC 7454, o NIST SP 800-189 e os materiais do operador MANRS fornecem referências de controle para filtragem, coordenação e troca de rotas resiliente. Eles suportam a expectativa de que as redes devem saber quais rotas um vizinho pode anunciar, rejeitar anúncios implausíveis onde informações confiáveis permitirem, monitorar anomalias e manter caminhos de contato para correção rápida. Eles não estabelecem que um peer específico violou um dever particular em abril de 2017. Essa conclusão exigiria a política histórica do peer, os registros de seleção de rota e alerta. [10][15]-[17]

A propagação cria um dever de evidência proporcional. Um peer que carregava uma rota mais específica inesperada deve ser capaz de mostrar o que recebeu, quais validações ou filtros foram executados, qual preferência local a selecionou, para onde exportou a rota e quando a retirou. A evidência retida permite uma distinção posterior entre uma limitação inevitável nos dados de autorização disponíveis e uma falha de política controlável.

A mesma evidência pode prevenir culpa injusta. Um peer pode mostrar que nenhum ROA aplicável existia, que os dados de registro não definiam um conjunto de clientes suficientemente estreito, que aceitou a rota sob uma política documentada ou que mudou de curso prontamente após um alerta. Alternativamente, os registros podem mostrar que uma restrição conhecida estava ausente ou ignorada. As observações públicas de rota identificam as redes a questionar; elas não fornecem a resposta completa.

O roteamento distribuído, portanto, produz responsabilidade distribuída. O AS12389 tem responsabilidade pela origem e exportação falsas. As redes aceitadoras têm responsabilidade pelos controles em seu próprio limite. Essas responsabilidades se sobrepõem em efeito sem se tornarem idênticas em causa.

Detentores de prefixo e monitores independentes controlaram diferentes formas de prontidão

As organizações cujo espaço de endereço apareceu no conjunto afetado não criaram os anúncios do AS12389. Sua responsabilidade diz respeito a preparação, detecção, escalação e evidência do lado do serviço, não culpa pela origem.

Os detentores de prefixo podem manter registros precisos de roteamento e autorização, organizar monitoramento de origem externa, definir contatos de escalação de provedor e preservar evidências de serviço quando um alerta ocorrer. Quando operacionalmente adequado, podem considerar anunciar uma rota mais específica mitigadora através de provedores legítimos. Qualquer mitigação deve ser avaliada cuidadosamente porque mudanças de rota feitas durante um incidente podem criar novos problemas de acessibilidade.

O contexto histórico é essencial. O evento ocorreu antes da aplicação ampla da Validação de Origem de Rota. O registro disponível não estabelece quais prefixos afetados tinham ROAs válidos em abril de 2017, quais comprimentos máximos esses ROAs autorizavam ou quais redes receptoras usavam validação. Portanto, seria errado tratar a ausência de rejeição universal como prova de que cada detentor de prefixo negligenciou o RPKI ou que cada peer ignorou um sinal inválido disponível.

As organizações de monitoramento controlavam um ponto de verificação diferente: a qualidade da evidência externa. A BGPMon forneceu uma janela de evento limitada, uma contagem de prefixos afetados, um denominador de 37 sistemas autônomos, um exemplo mais específico e hipóteses concorrentes sobre intenção. A ThousandEyes forneceu seu quadro de observação de 137 prefixos, a classificação levando a 36 prefixos de empresas externas, observações de propagação de peers, exemplos de serviços afetados e caminhos medidos. [1][2]

Esses registros são mais fortes quando seus pontos de vista, limites de tempo e métodos de classificação permanecem reproduzíveis. O acesso do BGPStream da CAIDA e a reconstrução histórica de Moriano e coautores ilustram como o material arquivado do Route Views e do RIPE RIS pode suportar análise posterior. Uma reconstrução posterior ainda precisa declarar quais coletores e intervalos de atualização foram usados e como os prefixos foram agrupados. [7][8]

Monitores independentes também têm um dever de linguagem. Eles podem descrever seleção suspeita e explicar por que rotas mais específicas levantam preocupação. Devem declarar separadamente se possuem evidência de propósito, acesso interno ou interceptação de conteúdo. Essa separação permite que um monitor alerte operadores rapidamente sem converter uma pontuação de anomalia em um veredito de atribuição.

Operadores de serviço afetado detêm a evidência necessária para avaliar danos downstream. Os logs de tráfego podem mostrar mudanças de conexão. Registros TLS podem mostrar se as sessões foram concluídas de forma segura. Registros de aplicação e transação podem mostrar erros, fraude ou nenhum efeito material. Relatórios de clientes podem identificar geografia e duração. Nenhum desses registros pode ser reconstruído de forma confiável apenas a partir de atualizações de rota.

A divisão prática é clara. Detentores de prefixo controlam prontidão e escalação. Monitores independentes controlam observação e análise externas. Operadores de serviço controlam evidência de efeitos de aplicação e cliente. Cada um pode fechar uma parte diferente do registro de incidente, e nenhum deve afirmar que a evidência de outra parte é desnecessária.

O RPKI pode restringir origens falsas, mas não pode decidir motivo

O RPKI é central para a discussão de controle porque o evento envolveu uma falsa origem. Seu papel deve ser declarado de forma restrita. A arquitetura RPKI suporta declarações criptograficamente verificáveis sobre recursos numéricos da Internet. Uma Autorização de Origem de Rota (ROA) identifica um sistema autônomo autorizado a originar prefixos especificados dentro do escopo do objeto. A Validação de Origem de Rota permite que uma rede receptora compare um anúncio de origem BGP com os dados de autorização disponíveis. [11]-[14][18]

Esse mecanismo pode dar a uma rede evidência útil de que uma origem observada não corresponde a uma autorização de cobertura. Se um prefixo afetado tivesse um ROA apropriado em abril de 2017 e uma rede receptora realizasse validação, uma origem do AS12389 poderia ter produzido um sinal que a política poderia rejeitar ou despriorizar. O resultado real dependeria da autorização histórica, comprimento do prefixo, dados de validação e política de roteamento local.

Vários limites se seguem.

Primeiro, o RPKI não prova intenção. Uma rota pode falhar na validação de origem devido a um anúncio hostil, um erro de operador, autorização desatualizada, um ROA com escopo incorreto ou outra incompatibilidade. O sinal diz respeito à autorização da origem, não ao estado mental ou identidade da pessoa por trás da atualização.

Segundo, a validação de origem não explica o gatilho interno. Pode identificar um conflito em um limite receptor, deixando sem resposta se a rota veio de configuração manual, automação, um cliente, acesso comprometido ou um caminho de redistribuição não intencional.

Terceiro, o RPKI por si só não valida o caminho AS completo. Uma declaração de origem autorizada não é uma prova criptográfica de que cada relação de trânsito ou segmento de caminho é legítimo. A classificação de vazamento de rota do RFC 7908 e a orientação de filtragem do RFC 7454 abordam preocupações de política e operacionais mais amplas que não podem ser reduzidas a uma verificação de origem. [9][10]

Quarto, uma alegação retrospectiva requer dados retrospectivos. A cobertura atual do RPKI, prática de validação ou orientação de registro não pode ser projetada para trás sem evidência. As perguntas relevantes são quais prefixos afetados tinham ROAs adequados em 26 de abril de 2017, quais comprimentos de prefixo eles autorizavam, quais dados de validação cada peer recebeu e como cada peer tratou o estado resultante.

Quinto, um controle é tão útil quanto sua integração operacional. Os registros de autorização devem ser precisos e mantidos. Validadores e distribuição de dados devem ser monitorados. A política de rota deve definir o que acontece quando um sinal está presente ou ausente. Os operadores precisam de procedimentos de exceção, reversão e contato de emergência. A orientação do MANRS e do NIST coloca filtragem, validação, coordenação e higiene global de roteamento dentro de uma prática operacional mais ampla, em vez de apresentar o RPKI como uma resposta completa. [15]-[17]

Essas limitações não enfraquecem o caso para segurança de origem de rota. Elas esclarecem o que o controle pode provar. O RPKI pode reduzir a dependência de uma alegação de origem não autenticada e pode ajudar as redes receptoras a tomar uma decisão mais informada. Não pode determinar por que o AS12389 anunciou as rotas, se o tráfego foi inspecionado ou quem deve arcar com toda a responsabilidade.

O caso de abril de 2017 é, portanto, um argumento para controles em camadas. A autorização de origem pode restringir a aceitação. Filtros de prefixo podem restringir o que um vizinho exporta. Monitoramento de mudanças de origem e mais específicas pode reduzir o tempo de detecção. Coordenação entre peers pode acelerar a retirada. Medição ativa pode mostrar impacto no caminho. Logs de serviço podem avaliar danos. Registros de operador podem explicar a causa.

Nenhuma camada fornece o relato completo. O desenho institucional mais forte faz as camadas produzirem evidências que podem ser reconciliadas após um evento.

Padrões de segurança de rota criam deveres de capacidade, não vereditos retrospectivos

Padrões e documentos de melhores práticas são mais úteis aqui como mapas de controle. O RFC 7908 fornece um vocabulário para vazamentos de rota. O RFC 7454 aborda segurança operacional e filtragem BGP. O RFC 6811 e o RFC 7115 descrevem validação de origem e seu uso operacional. O RFC 6480 e o RFC 6482 definem as fundações do RPKI e da ROA. O NIST SP 800-189 e o MANRS conectam filtragem, validação, coordenação e monitoramento a operações interdomínios resilientes. O RIPE NCC explica a Validação de Origem BGP e seus limites. [9]-[18]

Juntos, eles suportam deveres institucionais que são mensuráveis sem afirmar uma violação legal em 2017. Uma rede de origem deve restringir quais prefixos pode criar e exportar. Uma rede receptora deve manter controles de importação proporcionais e usar dados de autorização confiáveis quando disponíveis. Um detentor de prefixo deve manter registros precisos e monitorar origens inesperadas. Os operadores devem preservar logs e contatos que permitam retirada rápida e explicação posterior.

Os deveres são capacidades, não slogans. "Usamos RPKI" é incompleto sem o ROA histórico, estado de validação e resposta local. "Filtramos clientes" é incompleto sem o conjunto de prefixos permitidos e evidência de que o filtro foi executado. "Monitoramos BGP" é incompleto sem limiares de alerta, carimbos de data/hora e escalação. "A rota foi retirada" é incompleto sem o registro de detecção e decisão.

Os documentos não estabelecem que a Rostelecom ou qualquer peer nomeado falhou em um controle específico durante o evento. Isso exigiria uma comparação entre o requisito histórico, a arquitetura real do operador e a evidência do incidente. Padrões presentes ainda podem definir as perguntas que uma instituição responsável agora deve ser capaz de responder.

Essa abordagem evita dois erros. Um é o fatalismo tecnológico, no qual o desenho distribuído do BGP se torna uma razão pela qual ninguém pode ser responsável. O outro é a certeza tecnológica, na qual um controle moderno é declarado uma prevenção histórica garantida. A evidência não suporta nenhum dos dois.

A responsabilidade institucional, em vez disso, pergunta se cada ator poderia demonstrar seu controle no ponto que possuía. Esse padrão permanece válido mesmo quando o sistema global não tem operador central e o motivo original não está resolvido.

O dano deve ser medido sem inventar uma violação

O conjunto afetado incluía serviços financeiros, de pagamento, comércio eletrônico, segurança web e relacionados a certificados. Relatórios nomearam Mastercard, Visa, BNP Paribas, HSBC, Symantec e GeoTrust entre os exemplos associados aos prefixos afetados. Esses nomes explicam por que os observadores trataram o padrão com seriedade. Não provam comprometimento das organizações ou de seus clientes. [1][2]

O dano confirmado é dano de roteamento. Parte do tráfego perdeu seu caminho pretendido e cruzou uma rede de trânsito não autorizada. Isso mudou o limite de confiança para as conexões afetadas e reduziu o controle dos detentores de prefixo sobre como os usuários alcançavam seus serviços.

Possíveis danos secundários exigem evidência separada. Fraude de transação exigiria registros de transação. Roubo de credenciais exigiria evidência de autenticação, usuário ou forense. Comprometimento TLS exigiria evidência de sessão e certificado. Alteração de dados exigiria registros de pacote, aplicação ou integridade. Uma interrupção exigiria medições de disponibilidade vinculadas aos usuários afetados. Dano financeiro exigiria registros de perda e análise causal.

Nenhuma conclusão desse tipo segue meramente de uma rota passando pelo AS12389. A entrega adiante pode permitir que o serviço permaneça disponível, e a criptografia pode limitar o conteúdo legível. Nenhum fato elimina o risco. Nenhum prova segurança para cada conexão.

O relato de dano deve, portanto, usar uma escala em camadas. A perda de controle de rota está estabelecida. A exposição a um caminho de trânsito não intencional está estabelecida para o tráfego medido. A visibilidade do conteúdo é possível, mas não comprovada. A interceptação ativa é disputada e não comprovada. Comprometimento de dados, efeitos de transação e perda são desconhecidos.

Essa escala dá às organizações afetadas espaço para relatar honestamente. Podem reconhecer um evento grave de controle de rede enquanto as investigações continuam. Podem depois adicionar constatações do lado do serviço sem reescrever observações de roteamento. Se nenhum dano de aplicação for encontrado, esse resultado deve ser relatado como evidência dentro do escopo examinado, não como prova de que a falsa origem foi inócua.

A mesma disciplina se aplica a agências públicas e pesquisadores. Um enquadramento forte de ameaça pode motivar melhores controles, mas não deve transformar categorias de dano possível em fatos de incidente. A credibilidade da defesa da segurança de roteamento depende da manutenção dessa linha.

A divulgação deve responder a perguntas de controle mesmo quando a atribuição permanece não resolvida

Um relatório de incidente não precisa identificar um ator hostil para ser útil. Pode declarar o que o operador sabe sobre criação de rota, exportação, propagação, detecção e retirada, enquanto marca o motivo como não resolvido.

Para o AS12389, o relato mínimo útil identificaria a classe de origem dos anúncios, o conjunto de rotas e escopo de exportação, o canal de detecção, a decisão de retirada, o período afetado e as mudanças de controle feitas depois. Poderia explicar se o evento envolveu configuração, automação, entrada de cliente ou outro mecanismo interno sem expor comandos ou credenciais sensíveis.

Redes aceitadoras poderiam divulgar se as rotas foram tratadas como anúncios de cliente, peer ou trânsito; se verificações de prefixo, origem ou caminho foram aplicadas; se dados históricos de RPKI produziram um sinal utilizável; e como as rotas foram removidas. Detentores de prefixo poderiam divulgar quando foram alertados, quais provedores contataram e se a evidência de serviço mostrou efeitos mensuráveis no cliente.

O registro público fornecido por monitores já separa alguns fatos de interpretações. A BGPMon e a ThousandEyes documentaram temporização, conjuntos de rotas, mais específicas, propagação e efeitos de caminho, depois discutiram por que o padrão de alvo parecia suspeito. A BGPMon também preservou evidência que suporta uma hipótese de falha acidental. [1][2]

Esse é o modelo para incerteza responsável. Um relatório não deve esconder evidência suspeita para evitar risco reputacional. Não deve apresentar suspeita como intenção. Deve nomear os registros que decidiriam a questão e declarar se esses registros foram examinados.

A divulgação também precisa de um teste de remediação durável. Uma declaração de que as rotas foram retiradas descreve contenção. Não demonstra que as permissões mudaram, os filtros foram estreitados, os alertas melhoraram, os logs foram retidos ou a coordenação entre peers foi testada. Evidência de remediação deve identificar o controle que falhou, a mudança, o teste e o resultado de monitoramento.

Instituições têm diferentes restrições de divulgação. Operadores podem proteger informações sensíveis à segurança e confidenciais do cliente. Provedores financeiros e de segurança podem evitar expor padrões de tráfego. Peers podem tratar políticas como comercialmente sensíveis. Essas restrições justificam agregação e redação, não uma conclusão sem evidência.

O interesse público é mais forte no limite entre operação confirmada e propósito alegado. Um relato claro pode dizer que o AS12389 originou rotas falsas, peers propagaram algumas delas e o tráfego medido mudou de caminho. Também pode dizer que direcionamento deliberado, interceptação e espionagem não estão estabelecidos. Essa combinação é mais responsável do que negação por vagueza ou acusação por inferência.

Evidências que poderiam mudar a avaliação

Vários registros poderiam fortalecer, restringir ou reverter partes da avaliação atual.

O histórico de configuração do AS12389 poderia identificar a fonte exata da rota e a mudança. Logs de autenticação e autorização poderiam identificar a conta ou sistema envolvido e se a ação seguiu um fluxo de trabalho aprovado. Registros de exportação e sessão BGP poderiam estabelecer quais vizinhos receberam quais anúncios. Logs de alerta e resposta a incidentes poderiam mostrar como o evento foi detectado e por que a retirada ocorreu.

Um relatório de causa raiz da Rostelecom poderia conectar esses registros, distinguir erro de ação não autorizada e documentar remediação. Sua credibilidade dependeria de método, preservação de evidência e se hipóteses concorrentes foram examinadas. Uma mera afirmação de acidente ou ataque não resolveria a questão de atribuição.

Logs de filtro, validação e seleção de peers aceitadores poderiam mostrar por que rotas específicas passaram. Instantâneos históricos de política poderiam distinguir um controle ausente de dados de autorização ausentes. Registros de exportação poderiam mostrar o limite de propagação, enquanto registros de contato e ticket poderiam mostrar quando os peers coordenaram a retirada.

Uma reanálise reproduzível de atualizações arquivadas do RIPE RIS e Route Views poderia reconciliar os quadros de contagem da BGPMon e ThousandEyes ou explicar por que diferem. Também poderia mapear a propagação através do tempo e pontos de vista. A análise precisaria declarar coletores, carimbos de data/hora, deduplicação e métodos de classificação de prefixo. [7][8]

Registros históricos de ROA para cada prefixo afetado poderiam mostrar se a validação de origem teria produzido um resultado útil na época. A análise precisaria da origem autorizada relevante, prefixo e escopo de comprimento máximo, além de evidência de quais dados de validação cada rede receptora tinha e como sua política local respondeu.

Registros de tráfego, TLS, autenticação, aplicação e transação do serviço afetado poderiam estabelecer se as conexões desviadas foram concluídas, falharam ou mostraram efeitos suspeitos. Capturas de pacotes poderiam fornecer evidência mais direta dentro de seu ponto de vista e período de retenção limitados. Registros de incidente e perda do cliente poderiam conectar efeitos técnicos a pessoas ou organizações.

Evidência de que o caminho medido não transportava tráfego de produção estreitaria a conclusão de dano. Evidência de inspeção de pacotes, modificação ou uso de credenciais a expandiria. Evidência de uma mudança de rota deliberada e autenticada vinculada a um ator responsável mudaria materialmente a avaliação de atribuição. Evidência de um erro interno e controle corretivo testado fortaleceria a explicação de falha acidental.

Até que tais registros estejam disponíveis, a conclusão deve permanecer limitada. Anúncios do AS12389 e desvio de caminho estão confirmados. Uma falha de roteamento ou configuração é plausível. Direcionamento deliberado, interceptação e identidade do ator não estão resolvidos. Comprometimento de dados e perda não estão comprovados.

A responsabilidade começa onde a evidência é controlada

O evento de abril de 2017 não é principalmente uma história sobre se um rótulo alarmante derrota outro. É um teste de como a responsabilidade é atribuída em infraestrutura que é distribuída por desenho.

A Rostelecom controlava a criação de rota, política de exportação e os registros internos mais próximos da causa. Peers aceitadores controlavam filtros, validação, propagação e sua própria evidência. Detentores de prefixo controlavam dados de autorização, monitoramento e escalação. Monitores independentes controlavam observação externa e transparência analítica. Serviços afetados controlavam evidência de impacto no cliente e aplicação.

Nenhum ator controlava o caminho inteiro. Cada um controlava um ponto de verificação onde prevenção, limitação, detecção ou explicação era possível. Isso é suficiente para responsabilidade operacional mesmo quando o motivo permanece desconhecido.

O evento também mostra por que o RPKI deve ser tratado como um controle limitado. A autorização de origem pode ajudar redes receptoras a rejeitar ou reduzir a confiança em uma origem falsa quando os dados históricos e a política suportam esse resultado. Não pode identificar a pessoa por trás da atualização, provar interceptação ou substituir filtragem de exportação, coordenação entre peers, medição de caminho e investigação do lado do serviço.

A conclusão mais forte é, portanto, ao mesmo tempo firme e limitada. Observações públicas provam que o AS12389 originou rotas falsas, que múltiplos peers propagaram alguns anúncios e que o tráfego medido mudou de caminho. Não provam que a Rússia ou a Rostelecom pretendiam espionagem, que o tráfego foi inspecionado ou que dados ou dinheiro foram perdidos.

Responsabilidade não exige inventar esses fatos. Exige que os operadores que controlavam a evidência decisiva a preservem, testem e expliquem o que ela mostra.

Fontes

Verificação de acesso: 2026-07-25

ThousandEyes, mecanismo do evento, evidência de caminho e superfície de serviço afetada:https://www.thousandeyes.com/blog/rostelecom-route-leak-targets-ecommerce-services
BGPMon, temporização, contagens, exemplo de mais específica e hipóteses concorrentes:https://www.bgpmon.net/bgpstream-and-the-curious-case-of-as12389/
Internet Society, contexto anual de segurança de roteamento independente:https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/
CERT-EU, sumário institucional posterior do incidente e dano:https://cert.europa.eu/publications/threat-intelligence/threat-memo-190611-1/pdf
ENISA, análise de segurança BGP e recomendações de controle:https://www.enisa.europa.eu/sites/default/files/publications/WP%202019%20-%20O.1.2.3.P%20-%20Short%20position%20paper%20%E2%80%94%20analysis%20of%20a%20technical%20topic%20%28BGP%20security%29.pdf
CERT-EU, avaliação de ameaça atribuída posterior:https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
Moriano e coautores, reconstrução histórica revisada por pares:https://pmoriano.com/docs/COMNET21.pdf
CAIDA BGPStream, acesso a dados históricos do Route Views e RIPE RIS:https://bgpstream.caida.org/data
IETF RFC 7908, definições e classificação de vazamento de rota:https://datatracker.ietf.org/doc/html/rfc7908
IETF RFC 7454, orientação de segurança operacional e filtragem BGP:https://datatracker.ietf.org/doc/html/rfc7454
IETF RFC 6811, estados de validação de origem BGP:https://datatracker.ietf.org/doc/html/rfc6811
IETF RFC 7115, uso operacional da validação de origem RPKI:https://datatracker.ietf.org/doc/html/rfc7115
IETF RFC 6480, arquitetura RPKI:https://datatracker.ietf.org/doc/html/rfc6480
IETF RFC 6482, perfil de Autorização de Origem de Rota:https://datatracker.ietf.org/doc/html/rfc6482
NIST SP 800-189, orientação de segurança BGP e troca resiliente:https://csrc.nist.gov/pubs/sp/800/189/final
MANRS, ações de operador de rede:https://manrs.org/netops/
MANRS, orientação de implementação para operador de rede:https://manrs.org/netops/bcop/
RIPE NCC, explicação e limites da Validação de Origem BGP:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origin-validation/