Resumo

  • BGPMon situou o evento AS12389 entre 22:36 e aproximadamente 22:43 UTC em 26 de abril de 2017. Contou 50 prefixos afetados em 37 sistemas autônomos. ThousandEyes usou um quadro diferente: observou 137 prefixos originados pelo AS12389 durante a janela, tratou aproximadamente 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 de rota e propagação. Alguns anúncios eram rotas mais específicas. BGPMon destacou 203.112.90.0/24 contra um /23 normalmente anunciado, uma distinção que ajuda a explicar por que a seleção de rota comum poderia preferir a rota falsa sem qualquer comprometimento do serviço afetado em si. [2]
  • ThousandEyes observou pares, incluindo Cogent, Hurricane Electric e Tata, aceitando e propagando os 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 alcançava o destino pretendido. Isso suporta 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 da web e relacionados a certificados estavam entre os prefixos afetados. Exemplos nomeados nos relatórios incluíram 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 vários pares e mudanças de caminho medidas. Uma falha de roteamento ou configuração é uma explicação plausível. A segmentação deliberada e a interceptação permanecem disputadas. A identidade do ator, o gatilho interno, a inspeção de pacotes, o conteúdo descriptografado, os efeitos nas transações, as perdas e a remediação duradoura permanecem desconhecidos.
  • A concentração de destinos financeiros e de segurança tornou o padrão suspeito para BGPMon e ThousandEyes. 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 suportada sobre motivo. A Rostelecom controlava a criação de rota e exportação dentro do AS12389. Os pares aceitadores controlavam filtros, validação, aceitação de rota e propagação. Os titulares de prefixo controlavam dados de autorização, monitoramento externo e escalação. Os monitores independentes controlavam a qualidade e preservação das observações externas.
  • RPKI pode ajudar uma rede a avaliar se uma origem é autorizada por uma Route Origin Authorization correspondente, mas não prova intenção ou o mecanismo interno. O evento também antecede a aplicação generalizada de Route Origin Validation. O estado histórico de ROA de cada prefixo afetado e a política de validação de cada par teriam que ser estabelecidos antes de afirmar que 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 em transações, credenciais roubadas, comprometimento de TLS, dados alterados, uma interrupção completa, uma população afetada quantificada ou dano financeiro. A criptografia pode reduzir a exposição do 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 alteração e autenticação do AS12389, um relatório de causa raiz, logs de filtro e seleção de rota de pares, análise reproduzível de arquivos, estado histórico de ROA, tráfego e registros de TLS do lado do serviço, capturas de pacotes, registros de incidentes de clientes e evidência sobre se os caminhos medidos transportavam tráfego de produção.

Sete minutos criaram um problema duradouro de evidência

O evento foi curto, mas sua estrutura probatória permanece importante. 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ço de endereço associado a outros sistemas autônomos. Múltiplas redes externas aceitaram pelo menos alguns desses anúncios e os propagaram. 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, suportar uma forte conclusão sobre o que a Internet foi informada: o AS12389 representou a si mesmo como uma 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 de um operador. Um caminho alterado não revela quem inseriu um comando, qual sistema o gerou, se uma conta foi usada indevidamente 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 importa porque as palavras usadas para descrever um incidente de roteamento podem importar silenciosamente 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 é frequentemente 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 do CERT-EU e ENISA colocaram o evento em discussões mais amplas de 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ítica de pares ou evidência de tráfego do lado do serviço. [4]-[6]

O teste de responsabilidade apropriado começa com essa assimetria. A evidência pública de roteamento pode ser observada e reproduzida independentemente. A causa interna e o propósito dependem amplamente de registros controlados pelo operador de origem e outras redes participantes. Quanto mais forte 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 para fornecer respostas que não pode dar.

É 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: um restaura o roteamento, enquanto o outro mostra como a falha surgiu, que tráfego foi exposto, por que os controles não a contiveram e o que mudou depois.

As duas contagens de prefixos respondem a perguntas diferentes

BGPMon contou 50 prefixos afetados em 37 sistemas autônomos. ThousandEyes relatou que o AS12389 originou 137 prefixos durante a janela relevante, depois separou aproximadamente 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 único número 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. ThousandEyes começou com todos os 137 prefixos observados originados pelo AS12389 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 suspeitas de origens falsas. 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 suportada.

A formulação responsável preserva ambas as medições e nomeia o que elas medem. BGPMon observou 50 prefixos afetados em 37 sistemas autônomos. 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 observação, 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 a arquivos Route Views e 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]

Disciplina de contagem é um controle de responsabilidade porque limita o exagero. Uma resposta do 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 tráfego

BGP é o sistema interdomínio 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. Ele 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]

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. Os roteadores comumente preferem a rota mais específica para tráfego cujo destino cai 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 requer 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 de política de rota e controles. Eles não determinam, a partir apenas da evidência pública, 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, 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ítica locais. Quinto, pelo menos parte do tráfego medido seguiu o caminho resultante.

Cada passo 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 pares mostrariam aceitação, filtragem e seleção local. Arquivos de coletores mostrariam o que alcançou pontos de observação externos. Medições ativas mostrariam efeitos de caminho fim a fim. Operadores de serviço teriam evidência de tráfego e aplicação.

Essa cadeia impede uma atribuição simplista de toda responsabilidade a um lugar. AS12389 foi a origem falsa observada e controlou a primeira exportação. Os pares não criaram a rota, mas a aceitação e propagação ampliaram seu alcance. Os titulares 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 onde o tráfego viajou. ThousandEyes relatou que alguns pares, 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 para o destino pretendido. [1]

Essa forma de caminho importa. Ela suporta mais do que um risco teórico de que uma rota falsa possa atrair tráfego. Indica que o tráfego medido de produção seguiu um caminho de trânsito não autorizado. O caminho não simplesmente terminou 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 declaração universal. Nem toda rede aceitou ou preferiu a rota. ThousandEyes notou que a aceitação variou. Um caminho visto de um ou mais pontos de medição não pode ser expandido para 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. 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 toda conexão foi protegida corretamente. Registros de TLS do lado do serviço, telemetria de sessão e evidência de pacotes seriam necessários para uma conclusão mais específica.

O dano mais seguro suportado é, portanto, uma perda do controle de caminho pretendido e exposição temporária de algum 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ínio 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 intactas.

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 suportada.

Evidência confirmada inclui as observações de origem do AS12389, a janela de 22:36 a aproximadamente 22:43 UTC, anúncios falsos, alguns mais específicos, propagação por vários pares 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. 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 à segmentação deliberada e intenção de interceptação. A concentração de destinos financeiros, de pagamento, comércio eletrônico e segurança, combinada com rotas mais específicas recém-introduzidas, tornou o padrão suspeito para BGPMon e ThousandEyes. Suspeita é relevante porque molda a resposta ao incidente e a preservação de evidência. 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 comum de medição e que remediação duradoura ocorreu.

CERT-EU e ENISA usaram posteriormente uma estruturação mais forte orientada 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. Sua estruturação não cria acesso a registros de alteração do AS12389 ou a registros de pacotes de serviços afetados. Um rótulo posterior e categórico não deve ser tratado como nova evidência primária sobre a intenção de um operador em 2017. [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 não resolvidas de atribuição. [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 observação podem estabelecer alcance. Medições de caminho ativas podem estabelecer desvio de pontos de observação particulares. Logs de serviço podem estabelecer conexões recebidas, estado de 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 alteração e autenticação do operador podem identificar ação interna.

Uma investigação de causa raiz pode conectar esses registros a 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 responsabilidade operacional firme sem atribuir um motivo não suportado. A Rostelecom pode ser responsabilizada por explicar rotas originadas e exportadas pelo AS12389 mesmo quando a segmentação deliberada não é comprovada. Os pares podem ser questionados sobre aceitação e propagação mesmo quando não criaram as rotas. Os titulares de prefixo podem ser questionados sobre autorização e monitoramento sem implicar que causaram o incidente.

A evidência de atribuição também deve ser simétrica. Evidência que suporta uma hipótese hostil deve ser preservada, incluindo concentração de alvos e anúncios mais específicos. 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 credível explica por que uma hipótese finalmente se encaixa melhor ou afirma que o registro disponível não pode decidir entre elas.

Essa disciplina não é indecisão. 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 é frequentemente a diferença entre análise responsável e narrativa geopolítica.

AS12389 controlava a evidência interna mais probatória

A Rostelecom, como operadora do AS12389, controlava o sistema que observadores públicos viram originar e exportar as rotas. Isso não prova que a alta gerência dirigiu o evento ou que um indivíduo agiu intencionalmente. Identifica a organização mais próxima do processo de geração de rota 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 súbito de anúncios mais específicos.

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

Essas 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 de redistribuição interno, 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 mudança. Registros de aprovação poderiam mostrar se foi autorizada. Logs de sessão BGP e exportação poderiam mostrar quais rotas foram enviadas para quais vizinhos. Registros de alerta poderiam mostrar quando a equipe soube pela primeira vez. Registros de incidentes poderiam mostrar quem ordenou a retirada e como o conjunto afetado foi determinado.

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

A divulgação é o ponto de verificação final do operador de origem. Um relato de incidente público útil distinguiria 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ência 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. Não podem atribuir de forma confiável responsabilidade pessoal, intenção ou alocação interna de falha. 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. A distribuição significa que o AS12389 não controlava quais redes remotas aceitavam a rota. Não apaga o controle sobre o que o AS12389 originou e exportou. Por outro lado, localizar a origem falsa no AS12389 não apaga o papel dos vizinhos que a propagaram. A responsabilidade prática segue cada ponto de verificação em vez de colapsar toda a cadeia em um único ator.

Pares aceitadores controlavam o limite de propagação do evento

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

A questão de responsabilidade do par 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 par, o uso de informações de autorização de rota, alerta de anomalias, exportação adiante e coordenação de emergência.

As responsabilidades de filtragem devem ser descritas com evidência em vez de assumidas a partir de um rótulo comercial. Uma rede pode tratar um vizinho como cliente, par 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 eram incompletos, um sinal de validação não estava disponível ou a política local aceitou um aviso.

RFC 7454, NIST SP 800-189 e os materiais de 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 permitem, monitorar anomalias e manter caminhos de contato para correção rápida. Eles não estabelecem que um par específico violou um dever específico em abril de 2017. Essa conclusão exigiria a política histórica do par, registros de seleção de rota e alerta. [10][15]-[17]

A propagação cria um dever de evidência proporcional. Um par que carregava uma rota mais específica inesperada deve poder mostrar o que recebeu, que validação 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 par pode mostrar que nenhuma ROA aplicável existia, que os dados de registro não definiam um conjunto de clientes suficientemente restrito, que aceitou a rota sob uma política documentada ou que mudou rapidamente de curso após um alerta. Alternativamente, os registros podem mostrar que uma restrição conhecida estava ausente ou foi ignorada. As observações públicas de rota identificam as redes a questionar; não fornecem a resposta completa.

O roteamento distribuído, portanto, produz responsabilidade distribuída. O AS12389 tem responsabilidade pela origem falsa e exportação. 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.

Titulares de prefixo e monitores independentes controlavam 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 à preparação, detecção, escalação e evidência do lado do serviço, não à culpa pela origem.

Os titulares de prefixo podem manter registros precisos de roteamento e autorização, organizar monitoramento externo de origem, definir contatos de escalação de provedor e preservar evidência de serviço quando ocorre um alerta. 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 generalizada de Route Origin Validation. O registro disponível não estabelece quais prefixos afetados tinham ROAs válidas em abril de 2017, quais comprimentos máximos essas ROAs autorizavam ou quais redes receptoras usavam validação. Seria, portanto, errado tratar a ausência de rejeição universal como prova de que cada titular de prefixo negligenciou RPKI ou que cada par 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. 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. 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 pares, exemplos de serviços afetados e caminhos medidos. [1][2]

Esses registros são mais fortes quando seus pontos de observação, limites de tempo e métodos de classificação permanecem reproduzíveis. O acesso a dados do BGPStream da CAIDA e a reconstrução histórica de Moriano e coautores ilustram como o material arquivado do Route Views e 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]

Os monitores independentes também têm um dever de linguagem. 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 afetados possuem a evidência necessária para avaliar danos downstream. Logs de tráfego podem mostrar mudanças de conexão. Registros de TLS podem mostrar se as sessões foram concluídas com segurança. Registros de aplicação e transação podem mostrar erros, fraude ou nenhum efeito material. Relatos 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. Titulares 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 do incidente, e nenhum deve afirmar que a evidência de outra parte é desnecessária.

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

RPKI é central para a discussão de controle porque o evento envolveu uma origem falsa. Seu papel deve ser declarado de forma restrita. A arquitetura RPKI suporta declarações criptograficamente verificáveis sobre recursos numéricos da Internet. Uma Route Origin Authorization identifica um sistema autônomo autorizado a originar prefixos especificados dentro do escopo do objeto. Route Origin Validation permite que uma rede receptora compare um anúncio de origem BGP com 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 uma ROA apropriada em abril de 2017 e uma rede receptora realizasse validação, uma origem 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, 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, uma 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 enquanto deixa 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, RPKI não valida por si só o caminho AS completo. Uma declaração de origem autorizada não é uma prova criptográfica de que toda relação de trânsito ou segmento de caminho é legítima. A classificação de vazamento de rota do RFC 7908 e as orientações de filtragem do RFC 7454 abordam preocupações operacionais e de política 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 de RPKI, prática de validação ou orientação de registro não podem ser projetadas para trás sem evidência. As perguntas relevantes são quais prefixos afetados tinham ROAs adequadas em 26 de abril de 2017, quais comprimentos de prefixo elas autorizavam, quais dados de validação cada par recebeu e como cada par tratou o estado resultante.

Quinto, um controle é tão útil quanto sua integração operacional. 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. MANRS e NIST colocam filtragem, validação, coordenação e higiene global de roteamento dentro de uma prática operacional mais ampla, em vez de apresentar 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. RPKI pode reduzir a dependência de uma alegação de origem não autenticada e pode ajudar 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. O monitoramento de mais específicos e mudanças de origem pode reduzir o tempo de detecção. A coordenação entre pares pode acelerar a retirada. A medição ativa pode mostrar o impacto no caminho. Logs de serviço podem avaliar danos. Registros do operador podem explicar a causa.

Nenhuma camada fornece o relato inteiro. O design institucional mais forte faz com que as camadas produzam evidência que possa ser reconciliada após um evento.

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

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 de BGP e filtragem. RFC 6811 e RFC 7115 descrevem validação de origem e seu uso operacional. RFC 6480 e RFC 6482 definem as fundações RPKI e ROA. NIST SP 800-189 e MANRS conectam filtragem, validação, coordenação e monitoramento a operações interdomínio resilientes. 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 de 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 titular 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 limites de alerta, timestamps e escalação. "A rota foi retirada" é incompleta sem o registro de detecção e decisão.

Os documentos não estabelecem que a Rostelecom ou qualquer par 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. Os padrões atuais ainda podem definir as perguntas que uma instituição responsável deve agora poder responder.

Essa abordagem evita dois erros. Um é o fatalismo tecnológico, no qual o design 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 da web e relacionados a certificados. Relatórios nomearam Mastercard, Visa, BNP Paribas, HSBC, Symantec e GeoTrust entre exemplos associados aos prefixos afetados. Esses nomes explicam por que os observadores trataram o padrão seriamente. Não provam comprometimento das organizações ou 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 titulares de prefixo sobre como os usuários alcançavam seus serviços.

Danos secundários possíveis requerem evidência separada. Fraude em transações exigiria registros de transação. Roubo de credenciais exigiria evidência de autenticação, usuário ou forense. Comprometimento de 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 a usuários afetados. Dano financeiro exigiria registros de perda e análise causal.

Nenhuma tal conclusão 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 toda conexão.

O relato de dano deve, portanto, usar uma escala em camadas. A perda de controle de rota é estabelecida. A exposição a um caminho de trânsito não intencional é estabelecida para 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 em transações 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 posteriormente 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 origem falsa foi inofensiva.

A mesma disciplina se aplica a agências públicas e pesquisadores. Uma estruturação 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 advocacia de segurança de roteamento depende da manutenção dessa linha.

Divulgação deve responder 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, par 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. Titulares 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. BGPMon e ThousandEyes documentaram temporização, conjuntos de rotas, mais específicos, propagação e efeitos de caminho, depois discutiram por que o padrão de alvos parecia suspeito. BGPMon também preservou evidência suportando 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 de reputação. 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 duradoura. 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 pares foi testada. A evidência de remediação deve identificar o controle que falhou, a mudança, o teste e o resultado do monitoramento.

As 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. Pares 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, pares as propagaram em parte e o tráfego medido mudou de caminho. Também pode dizer que segmentação deliberada, interceptação e espionagem não estão estabelecidas. Essa combinação é mais responsável do que negação através de vagueza ou acusação através de inferência.

Evidência que poderia mudar a avaliação

Vários registros poderiam fortalecer, estreitar ou reverter partes da avaliação atual de forma material.

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 do 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 de par aceitador, validação e seleção 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 pares 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. Poderia também mapear a propagação através do tempo e pontos de observação. A análise precisaria de coletores declarados, timestamps, 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, escopo de prefixo e 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 de serviço afetado, TLS, autenticação, aplicação e transação 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 observação e período de retenção limitados. Registros de incidentes e perdas de clientes 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 são confirmados. Uma falha de roteamento ou configuração é plausível. Segmentação deliberada, interceptação e identidade do ator não estão resolvidas. 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 design.

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

Nenhum ator controlava todo o caminho. 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 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 pares, medição de caminho e investigação do lado do serviço.

A conclusão mais forte é, portanto, firme e limitada. Observações públicas provam que o AS12389 originou rotas falsas, que vários pares 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 financeiros ou dinheiro foram perdidos.

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

Fontes

Acesso verificado: 25/07/2026

  1. 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
  2. BGPMon, temporização do evento, contagens, exemplo mais específico e hipóteses concorrentes:https://www.bgpmon.net/bgpstream-and-the-curious-case-of-as12389/
  3. Internet Society, contexto anual independente de segurança de roteamento:https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/
  4. CERT-EU, resumo institucional posterior do incidente e dano:https://cert.europa.eu/publications/threat-intelligence/threat-memo-190611-1/pdf
  5. 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
  6. CERT-EU, avaliação de ameaça atribuída posterior:https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
  7. Moriano e coautores, reconstrução histórica revisada por pares:https://pmoriano.com/docs/COMNET21.pdf
  8. CAIDA BGPStream, acesso a dados históricos Route Views e RIPE RIS:https://bgpstream.caida.org/data
  9. IETF RFC 7908, definições e classificação de vazamento de rota:https://datatracker.ietf.org/doc/html/rfc7908
  10. IETF RFC 7454, orientação operacional de segurança BGP e filtragem:https://datatracker.ietf.org/doc/html/rfc7454
  11. IETF RFC 6811, estados de validação de origem BGP:https://datatracker.ietf.org/doc/html/rfc6811
  12. IETF RFC 7115, uso operacional da validação de origem RPKI:https://datatracker.ietf.org/doc/html/rfc7115
  13. IETF RFC 6480, arquitetura RPKI:https://datatracker.ietf.org/doc/html/rfc6480
  14. IETF RFC 6482, perfil de Route Origin Authorization:https://datatracker.ietf.org/doc/html/rfc6482
  15. NIST SP 800-189, orientação de segurança BGP e troca resiliente:https://csrc.nist.gov/pubs/sp/800/189/final
  16. MANRS, ações de operador de rede:https://manrs.org/netops/
  17. MANRS, orientação de implementação para operador de rede:https://manrs.org/netops/bcop/
  18. 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/