Resumo

  • O incidente combinou uma conta comprometida, ROAs hostis, atualizações assíncronas de validadores e a decisão local de redes que rejeitavam rotas Invalid; por isso, a perda e a volta da conectividade ocorreram em etapas.
  • A expansão segura do RPKI exige autorização no momento da operação, segunda aprovação conforme o raio de impacto, aviso protegido, recibo verificável, estado seguro conhecido e exercícios cuja conclusão seja medida na validade e no alcance das rotas.

Quando o cadastro passa a comandar a produção

Segundo a reconstrução da Kentik, a atividade RPKI ligada aos recursos da Orange España começou por volta de 09h28 UTC de 3 de janeiro. Às 09h42, três autorizações relevantes já haviam surgido. A queda pronunciada de tráfego, porém, seria percebida somente horas mais tarde.

Essa distância revela a verdadeira natureza do controle. Uma Route Origin Authorisation não carrega pacotes. Ela declara, com assinatura, qual sistema autônomo pode originar determinados prefixos e qual comprimento máximo pode ser aceito. Validadores coletam esse material; cada operador decide como usar o resultado em sua política BGP.

Quem controlou indevidamente a conta não precisou entrar em milhares de roteadores. Bastou modificar a evidência compartilhada que esses roteadores poderiam consultar. A AS12479 podia continuar anunciando suas rotas legítimas, mas elas deixaram de coincidir com a nova autorização e passaram a receber o estado Invalid.

O RFC 6811 define Invalid justamente assim: existe uma carga validada que cobre o prefixo, mas nenhuma autorização combina com a origem observada. O mesmo documento deixa claro que o resultado não impõe uma ação universal. Descartar a rota é uma decisão configurada localmente pelo operador.

Portanto, o RPKI não “desligou” sozinho a Orange España. A cadeia de assinatura distribuiu um estado criado com uma autoridade aceita. Os validadores calcularam o resultado esperado. Redes que haviam escolhido rejeitar Invalid executaram sua defesa contra sequestro de origem. O ponto fraco estava antes da assinatura: a prova exigida para exercer um poder com tamanho raio de impacto.

Uma ocorrência, três relógios

As fontes públicas registram janelas diferentes. A Kentik observou forte redução do tráfego de entrada para a AS12479 aproximadamente entre 14h20 e 18h00 UTC. A Cloudflare situou sua queda entre 16h45 e 19h45 no horário local e viu diminuir de forma relevante o espaço IPv4 anunciado pela Orange España.

Já a bgp.tools acompanhou um prefixo afetado perdendo visibilidade por volta de 14h11 UTC e recuperando-a a partir de 17h47. A maior parte dos feeds observados levou cerca de mais uma hora para voltar. Cada plataforma mede uma parcela diferente; nenhuma representa um censo completo da Internet.

O primeiro relógio marca a escrita: quando o ROA foi criado ou modificado. O segundo marca a validação: quando cada sistema buscou e processou o novo estado. O terceiro marca a operação: quando a política local transformou uma rota Invalid em caminho inutilizável. A interrupção aparece no encontro desses relógios, não em um instante central.

A visibilidade caiu em degraus. Alguns validadores se atualizaram antes; outros, depois. Algumas redes rejeitavam Invalid; outras não. Interconexões diretas ou relações específicas podiam preservar alcance limitado. A divergência entre horários reforça, em vez de enfraquecer, a explicação distribuída.

Essa assincronia também define a recuperação. Corrigir um objeto não apaga imediatamente cópias e resultados derivados. Há caches, ciclos de atualização e decisões locais. A propagação gradual oferece uma janela para conter um erro antes do efeito total, mas também mantém resíduos depois que a conta já foi recuperada.

Uma assinatura não reconhece intenção

A criptografia confirma que um conteúdo veio da cadeia esperada e não foi alterado no transporte. Ela não sabe se a pessoa por trás de uma sessão reconhecida age corretamente, comete um erro, sofre coerção ou perdeu o controle da conta. Uma operação hostil pode, portanto, produzir uma assinatura perfeitamente válida.

A análise de Ben Cartwright-Cox torna esse paradoxo explícito: algo pode estar assinado e ainda assim não estar seguro. Uma revisão acadêmica das superfícies de ataque do RPKI também separa identidade, publicação, software validador e implantação operacional. A segurança depende do conjunto, não apenas da matemática da assinatura.

O mesmo problema existe em registros de domínio, emissão de certificados e controles de nuvem. Uma interface de aparência burocrática pode alimentar decisões automáticas de terceiros. O usuário não está simplesmente atualizando um cadastro; está exercendo autoridade de produção sobre uma dependência compartilhada.

A autenticação em dois fatores é indispensável. Relatos públicos informaram que ela se tornou obrigatória na RIPE NCC após o caso. Mas autenticar uma sessão e autorizar uma transação de grande impacto são tarefas distintas. Sessões roubadas, recuperação fraca, abuso interno e permissões excessivas continuam possíveis depois do login.

Quatro perguntas precisam de respostas próprias. Quem abriu a sessão? Essa pessoa pode executar esta operação específica? Outro responsável viu a diferença e aprovou o efeito previsto? Quem confirma depois que o estado publicado coincide com o BGP real? A resposta única “usuário autenticado” não cobre mais esse encadeamento.

Recuperar a identidade não recupera o alcance

A linha do tempo da Kentik indica recuperação de controle e ROAs corretivos antes de 18h00 UTC, enquanto alguns Invalid ainda apareciam depois. Encerrar a invasão no nível da conta não encerra o incidente nas dependências que já consumiram o estado hostil.

Uma restauração completa começa pelo inventário de toda criação, alteração e exclusão durante o período comprometido. Em seguida, compara os ROAs atuais com os anúncios BGP pretendidos. Depois acompanha Valid, Invalid e NotFound em mais de um validador, além da visibilidade dos prefixos e do tráfego em observadores independentes.

Também é preciso definir antecipadamente um estado seguro. “Desfazer a última mudança” não funciona se o atacante fez uma sequência de operações ou se a versão anterior já estava inconsistente. O retorno deve apontar para uma versão identificada, verificada e acompanhada dos anúncios esperados.

Os exercícios de crise precisam atravessar organizações. Detentor de recursos, serviço RPKI hospedado, suporte do registro, operadores de validadores e redes que aplicam ROV enxergam evidências diferentes. Colocar escrita, publicação, validação, BGP e tráfego na mesma linha do tempo permite atribuir quem detecta, quem bloqueia, quem corrige e quem comprova o fim do impacto.

Controles acionados pelo raio de impacto

Não seria sensato submeter todo ajuste cotidiano a uma longa fila de aprovação. Redes mudam, e lentidão excessiva incentiva atalhos. A saída é graduar a exigência segundo o efeito provável da operação, preservando velocidade para o trabalho normal.

O raio pode considerar a quantidade de endereços, um ASN de origem nunca usado, um agregado incomumente amplo, um maxLength mais restritivo que os anúncios vivos, a remoção em massa de autorizações e a previsão de que rotas observadas mudarão de Valid ou NotFound para Invalid.

No primeiro nível, uma operação excepcional exige nova autenticação naquele momento. Uma verificação feita horas antes não basta. No segundo, um aprovador independente recebe a diferença estruturada, os prefixos afetados e o estado de validação esperado. Um botão genérico de confirmação não apresenta informação suficiente para decidir.

No terceiro, uma notificação sai por canal protegido, cujo destinatário não possa ser trocado pela mesma sessão. No quarto, um recibo mostra antes e depois, executor, aprovador, horário, efeito previsto e caminho de reversão. O detentor precisa conseguir verificar esse recibo sem depender do painel suspeito.

No quinto, operações raras podem esperar uma breve contestação; urgências usam uma via mais forte, limitada e revisada. No sexto, objetos temporários e exceções expiram automaticamente. O remédio criado para uma hora de crise não deve sobreviver como autoridade esquecida.

As recomendações da CENIC após o incidente destacam autenticação forte, alertas e preparação de recuperação. Para a liderança, resta perguntar se esses controles cercam a escrita perigosa, se o alerta é independente da conta e se a recuperação foi ensaiada com validadores e observação BGP reais.

O limite do Running-Code Primacy

O princípio de Running-Code Primacy defendido publicamente por Heng Lu funciona aqui como posição normativa, não como fonte factual da cronologia. Ele sustenta que a ordem efetiva da Internet reside nos protocolos públicos, no código implantado e na interconexão operacional; registros institucionais não devem virar título de propriedade sobre a rede global.

Reforçar a custódia das escritas respeita esse limite. O registro ou provedor hospedado protege melhor o exercício do próprio poder. O operador mantém a decisão local sobre ROV. O detentor conserva evidência portátil e verificável. Nenhuma instituição central ganha o direito de comandar todas as rotas.

Também seria errado usar o caso para relaxar amplamente a rejeição de Invalid. Isso reduziria o dano imediato de uma autorização hostil, mas reabriria espaço para sequestros verdadeiros. A defesa distribuída deve permanecer; a entrada assinada da qual ela depende é que precisa de autorização mais rigorosa.

Limites do que sabemos

As medições não demonstram que todo cliente, prefixo ou parceiro sofreu a mesma interrupção. Plataformas têm visibilidade e intervalos diferentes. O mecanismo é sustentado pela convergência das fontes, mas nenhuma amostra pode ser promovida a medida exata da Internet inteira.

As informações públicas também não estabelecem toda a técnica usada para obter a conta. Há base para afirmar acesso indevido, mudança hostil de ROA e efeitos posteriores de alcance. Não há base suficiente para escolher uma cadeia específica de malware, participação interna ou furto de credenciais.

Por fim, a obrigação de 2FA precisa ser avaliada em partes. Cobertura, resistência a phishing, proteção da recuperação, revogação de sessão, separação de papéis e aprovação transacional são métricas distintas. Confundir uma delas com solução completa repetiria o problema entre identidade e intenção.

A segurança começa antes da assinatura

O episódio da Orange España não mostra um RPKI fazendo algo anormal. Mostra um mecanismo de confiança executando fielmente um estado produzido por autoridade de conta mal protegida. Escrita, validação e política local funcionaram segundo suas regras; a combinação produziu uma interrupção séria.

A maturidade futura não pode ser medida apenas por quantos prefixos têm ROA ou quantas redes rejeitam Invalid. É preciso medir quem pode escrever, quando surge uma segunda aprovação, se o aviso é independente, quanto demora o retorno ao estado seguro e quanto demora o desaparecimento do Invalid em vários observadores.

A assinatura responde se uma afirmação veio do sistema confiável. A governança de infraestrutura precisa responder outra pergunta: a autoridade que produziu essa afirmação era proporcional às consequências que ela poderia desencadear?

Fontes