Resumo

  • A intensificação de ataques motivou a manutenção anti-DDoS, mas um ataque DDoS não causou a interrupção; o mecanismo comprovado foi uma mudança planejada de roteamento em produção.
  • Segundo a OVHcloud, um roteador interpretou incorretamente um comando de redistribuição do BGP para o OSPF, anunciou a tabela inteira da internet ao IGP, encheu a tabela OSPF, sobrecarregou RAM e CPU e produziu um ciclo de convergência que tornou o roteamento IPv4 inoperante.
  • O registro detalhado situa o início da mudança às 09h05 CET, o problema por volta de 09h20, o rollback já fracassado até 09h30, o desligamento do roteador às 10h18, os primeiros serviços de volta às 10h20 e o fim da crise técnica às 10h57.
  • CAB, MOP e revisão por pares existiam. A pergunta de responsabilidade é por que semântica do comando, contenção do raio de impacto, validação, observabilidade, acesso fora de banda e rollback efetivo não impediram que uma mudança revisada alcançasse toda a rede.
  • O dano comprovado foi de alcance de rede: o IPv4 falhou enquanto o IPv6 permaneceu acessível. Não há base para afirmar perda de dados, incêndio, destruição física de servidores ou datacenters, nem para inventar um total exato de clientes, serviços ou prejuízos.

A ameaça explica a prioridade da mudança, não a origem da pane

A OVHcloud vinculou a intervenção ao reforço de sua defesa anti-DDoS durante um período de maior intensidade de ataques. Essa informação ajuda a entender por que a empresa considerava a manutenção necessária. Ela não transfere a causa técnica do incidente para um agente externo. O elo causal sustentado pelo registro público começa na mudança de configuração executada na rede de produção.

Separar motivação e causa é mais do que uma precisão de linguagem. Se a indisponibilidade for descrita como resultado de um ataque, desaparecem da análise as decisões sobre redistribuição de rotas, validação, limites do plano de controle e autoridade para interromper a mudança. Se a pressão criada pelos ataques for apagada, perde-se o contexto operacional em que a decisão foi tomada. A responsabilidade exige manter as duas dimensões visíveis sem confundi-las.

Essa distinção também protege a comunicação de crise contra uma narrativa conveniente. Uma organização pode estar respondendo a uma ameaça legítima e, ao mesmo tempo, executar de forma insegura uma alteração destinada a combatê-la. Urgência não elimina a obrigação de testar o comportamento real do equipamento, limitar o alcance e preservar um caminho de recuperação independente.

Uma redistribuição levou a escala da internet ao protocolo interno

O BGP transporta informações de alcance entre redes. O OSPF calcula caminhos dentro de um domínio operacional. Redistribuir rotas de um para o outro cria uma fronteira de alto risco: é preciso decidir quais prefixos entram, quais atributos permanecem, quais filtros se aplicam e quanto estado o protocolo interno pode processar com segurança.

No relato pós-incidente da OVHcloud, o roteador não interpretou corretamente um comando ligado a essa redistribuição. A consequência foi o anúncio da tabela inteira da internet para o IGP da empresa. O número exato de rotas, o modelo do equipamento, o fornecedor e a versão de software não foram publicados. Mesmo sem esses detalhes, a sequência operacional está delimitada.

A tabela OSPF ficou cheia. Memória RAM e CPU do roteador foram sobrecarregadas. Um ciclo de convergência entre BGP e OSPF tornou o roteamento IPv4 inoperante. Em vez de permanecer circunscrita ao dispositivo ou ao conjunto de rotas pretendido, a alteração contaminou o mecanismo usado pela rede para calcular seus próprios caminhos.

É aqui que a realidade do código em execução prevalece sobre a intenção documentada. Uma solicitação de mudança podia descrever um reforço de segurança, conter aprovações e prever um resultado limitado. O estado operacional, porém, foi definido pelas rotas que o equipamento aceitou e propagou. A governança precisa ser capaz de provar esse estado, e não apenas a qualidade formal da justificativa.

Para uma redistribuição desse tipo, a validação deve observar o conjunto autorizado de prefixos, limites máximos, ritmo de crescimento da tabela, consumo de memória e CPU, estabilidade das adjacências e possibilidade de realimentação entre protocolos. Um teste com poucas rotas pode confirmar a sintaxe e ainda deixar invisível a falha que aparece quando a escala cresce. Se o ambiente de teste não reproduz a dimensão ou a interpretação do equipamento em produção, essa diferença precisa ser assumida como risco explícito.

A cronologia contém várias medidas de recuperação

O relato detalhado registra o início da mudança às 09h05 CET. Às 09h18, houve isolamento do BGP e ações de configuração. O problema de rede surgiu às 09h20; um minuto depois, a degradação de desempenho do roteador foi detectada e escalada. Até 09h30, a tentativa de rollback não havia funcionado e a resposta passou a depender de isolamento físico.

O roteador com falha foi desligado às 10h18. Depois da convergência da rede, os primeiros serviços retornaram às 10h20. A OVHcloud marcou o encerramento da crise técnica às 10h57. Portanto, dizer apenas que a pane durou “cerca de uma hora” ou escolher o último horário como se nada tivesse voltado antes apaga a natureza escalonada da recuperação.

A formulação mais fiel é que o alcance IPv4 deixou de funcionar por volta de 09h20, os primeiros serviços reapareceram às 10h20 e a estabilização técnica continuou até 10h57. Um comunicado anterior do mesmo dia usou horários mais aproximados: 09h12 para a intervenção e 10h15 para o isolamento. Essa diferença não autoriza uma falsa precisão; mostra que mensagens produzidas durante a crise e uma reconstrução posterior têm graus distintos de detalhe.

Os vários relógios servem a perguntas diferentes. O primeiro mede quando a mudança começou. O segundo mostra quando o efeito de configuração apareceu. O terceiro registra quando a equipe reconheceu que o rollback havia fracassado. O quarto mede quanto tempo foi necessário para retirar fisicamente o equipamento. O quinto indica quando algum serviço voltou. O último mostra quando a organização considerou encerrada a crise técnica. Uma avaliação madura não reduz esses marcos a uma única duração conveniente.

O contraste entre IPv4 e IPv6 delimita a falha

A OVHcloud descreveu perturbação em toda a sua rede e incapacidade de processar corretamente tráfego IPv4 para seus sites. Veículos independentes observaram servidores e sites de clientes inacessíveis, erros na página pública da empresa e indisponibilidade da própria página de status. Para usuários, o efeito era o desaparecimento de serviços que dependiam daquela conectividade.

O IPv6, no entanto, permaneceu alcançável. Essa diferença é uma pista técnica decisiva. Ela aponta para uma falha de roteamento associada ao IPv4, não para a destruição indiscriminada de servidores, prédios ou dados. Uma tela de erro pode parecer igual ao público, mas a fronteira entre famílias de endereços revela qual camada deixou de cumprir sua função.

O caso de outubro também não deve ser misturado ao incêndio de março de 2021 no datacenter de Estrasburgo. Não há base, neste incidente, para imagens ou alegações de fogo, dano físico às instalações ou perda de dados de clientes. A evidência sustenta uma quebra de alcançabilidade. Confundir os episódios produz diagnóstico errado e transforma um problema de controle de rotas em uma narrativa de desastre físico.

O impacto foi amplo, mas não oferece um total auditado

Relatos independentes documentaram sites de clientes fora do ar, a página pública da OVHcloud devolvendo erros e a página de status inacessível. A imprensa francesa informou que milhares de sites foram afetados e apresentou exemplos de páginas públicas e comerciais. Esses registros demonstram alcance social e econômico além de um componente interno isolado.

Ao mesmo tempo, exemplos observados não compõem um inventário completo. O registro oficial não publica um número exato de clientes, serviços, regiões, rotas ou equipamentos afetados. Também não fixa perda financeira. Uma manchete sobre milhares de sites não pode ser convertida automaticamente em milhares de clientes distintos, contratos ou bases de dados perdidas.

Indisponibilidade e perda de dados são danos diferentes. Não conseguir alcançar um serviço é uma falha séria de continuidade; não prova que o conteúdo armazenado desapareceu. Preservar essa fronteira torna a conclusão mais confiável. O peso do incidente está na dependência que numerosos serviços tinham do mesmo plano de alcance, e não em um número inventado para aumentar a dramaticidade.

O processo estava presente, mas seus controles não contiveram o estado perigoso

A OVHcloud informou que a mudança havia sido preparada por meio de CAB, MOP e revisão por pares. É incorreto concluir que não houve revisão. O caso é mais instrutivo justamente porque as instâncias formais existiam e, ainda assim, a rede aceitou um estado capaz de esgotar seu plano de controle.

Um CAB pode avaliar necessidade, risco, horário e responsáveis. Um MOP pode definir a sequência operacional, verificações e rollback. A revisão por pares pode procurar erros de comando e de desenho. Nenhum desses mecanismos, sozinho, garante que o equipamento interpretará a alteração como esperado, que um conjunto excessivo de rotas será bloqueado ou que a reversão continuará disponível depois que CPU e memória estiverem pressionadas.

Contar aprovações é uma forma fraca de medir segurança. Revisores podem compartilhar a mesma hipótese errada. Um laboratório pode não reproduzir a escala da produção. Uma lista de rollback pode depender do mesmo caminho de gestão afetado pela pane. O teste real do processo é saber se o sistema recusa o estado perigoso, o detecta cedo, reduz seu alcance e preserva meios de recuperar o controle.

Isso muda também a forma de investigar. A pergunta não é apenas quem digitou um comando. É preciso saber quais invariantes deveriam ter impedido a tabela completa de entrar no OSPF, quais sinais estavam disponíveis, quem tinha autoridade para interromper a execução e por que o plano de reversão não restaurou o estado. Individualizar culpa sem examinar esses controles deixa a organização vulnerável à repetição.

Um rollback escrito não equivale a uma reversão comprovada

Até 09h30, a tentativa de rollback havia falhado. A restauração exigiu que uma equipe isolasse fisicamente o roteador e o desligasse às 10h18. Só então a rede convergiu e os primeiros serviços reapareceram. A sequência revela uma dependência importante: o caminho lógico usado para consertar a rede não conseguiu recuperar controle sobre o estado criado pela mudança.

Um rollback não termina quando o comando inverso é enviado ou aceito. É necessário comprovar que os anúncios perigosos cessaram, que a base OSPF retornou ao conjunto esperado, que adjacências estabilizaram, que CPU e memória saíram da zona de saturação e que a alcançabilidade externa se recuperou. Se essas verificações não aparecem, há uma tentativa de rollback, não uma reversão operacional.

O isolamento físico pode ser uma última barreira válida. Sua eficácia depende, porém, de acesso ao local, identificação inequívoca do equipamento, autoridade para desligá-lo e comunicação entre equipes. Esses elementos precisam estar planejados antes da crise. Quando cada minuto de espera mantém a rede em convergência instável, o tempo entre a decisão de isolar e o desligamento se torna uma medida de resiliência.

Também importa proteger a gestão e a comunicação de incidente fora do mesmo domínio de falha. A indisponibilidade observada da página de status mostra o custo de perder a voz pública junto com o serviço. Se telemetria, acesso administrativo e comunicação dependem integralmente do roteamento afetado, a organização fica com menos visão e menos capacidade de orientar clientes exatamente quando ambas são mais necessárias.

Os limites do registro impedem uma causa simples demais

Os documentos públicos não identificam modelo do roteador, fornecedor, firmware ou parser do comando. Tampouco atribuem a decisão a uma pessoa abaixo do nível empresarial ou de liderança. Uma explicação de liderança mencionou erro humano, enquanto o registro técnico posterior descreveu a interpretação do comando e seus efeitos sem nomear um indivíduo.

Houve reportagem sobre uma publicação apagada que sugeria erro de copiar e colar. A reconstrução oficial posterior não estabeleceu essa hipótese como causa raiz final. Ela não deve ser apresentada como fato. Uma narrativa curta pode ser atraente, mas reduzir a pane a um gesto individual obscurece por que filtros, limites, revisão, observabilidade e rollback não impediram a propagação.

A incerteza não elimina a responsabilidade. Ela muda o tipo de conclusão permitido. É possível afirmar que a mudança revisada introduziu a tabela inteira no IGP, exauriu recursos, interrompeu IPv4, resistiu ao rollback e exigiu isolamento físico. Não é possível completar as lacunas com suposições sobre dispositivo, intenção individual, dados perdidos ou prejuízo financeiro.

O que operadores precisam demonstrar antes da próxima mudança

Uma redistribuição entre BGP e IGP deveria ter uma lista explícita de rotas permitidas, limite máximo de prefixos, alertas sobre aumento anormal e uma resposta segura quando a entrada excede o previsto. O controle não pode depender apenas de uma pessoa perceber visualmente uma linha perigosa. O equipamento e a automação precisam rejeitar estados incompatíveis com o desenho aprovado.

O ensaio deve usar escala representativa, a mesma combinação relevante de hardware e software e verificações separadas para IPv4 e IPv6. Também deve testar o pior momento do rollback: quando CPU e memória estão sob pressão, adjacências oscilam e o acesso comum de gestão está degradado. Um procedimento que funciona apenas antes do incidente não é um mecanismo confiável de recuperação.

Durante a execução, contagem e taxa de crescimento de rotas, estado das adjacências OSPF, atualizações BGP, memória, CPU, tempo de convergência e alcance externo precisam formar uma visão única. Cada passo deve ter condição de parada. Se o número de rotas divergir do plano, se recursos ultrapassarem o limite ou se sondas externas perderem IPv4, a próxima ação padrão deve ser interromper e conter, não continuar o roteiro.

Por fim, o acesso fora de banda e a capacidade de isolamento físico precisam de responsáveis, tempos-alvo e exercícios. A empresa deve saber quem pode ordenar o desligamento, quem chega ao equipamento, como confirma sua identidade e como informa clientes enquanto a rede principal está instável. A continuidade é comprovada pelo comportamento do sistema sob falha, não pela existência de um documento de mudança.

Fontes