O ataque da botnet Mirai à OVH em 2016 transformou a capacidade de mitigação de DDoS em um teste de responsabilização

Resumo

A OVHcloud descreveu publicamente um ataque da botnet Mirai, em setembro de 2016, que superou um terabit por segundo. Esse pico é uma medição atribuída ao próprio operador, e não uma auditoria independente, pacote por pacote, de todos os alvos, dispositivos participantes ou efeitos sobre clientes. [1][2]
Pesquisadores que apresentaram seu trabalho na USENIX Security reconstruíram a expansão e a atividade da Mirai a partir de diferentes pontos de observação. O estudo informa que ataques contra a infraestrutura da OVH começaram em 18 de setembro de 2016, situa o episódio em uma botnet que chegou a aproximadamente 600 mil dispositivos infectados e analisa mais de 15 mil ataques durante o período observado. [3][4]
O episódio da OVH deve permanecer separado dos ataques contra o KrebsOnSecurity e contra a Dyn. A presença da mesma família de malware e de partes relacionadas do ecossistema criminoso não transforma alvos, datas, caminhos de tráfego, dependências e impactos distintos em um único incidente.
Dispositivos comprometidos pela Mirai podiam enviar tráfego diretamente ao alvo usando endereços de origem normalmente roteáveis. Isso é diferente de um ataque de reflexão e amplificação baseado em endereços falsificados. A validação de endereços de origem continua importante, mas o BCP 38, isoladamente, não teria impedido um dispositivo comprometido de transmitir uma inundação direta com o endereço que lhe havia sido atribuído. [15][16][19][20]
Para um provedor de hospedagem, capacidade de proteção contra DDoS não pode ser reduzida ao maior número de gigabits ou terabits observado. Ela depende da capacidade de medir taxa de bits e taxa de pacotes, identificar o recurso sob pressão, ativar filtragem ou desvio de tráfego sem provocar uma segunda indisponibilidade, manter um caminho suficiente para o tráfego legítimo e verificar a recuperação do serviço.
A responsabilidade é distribuída segundo o controle prático de cada ator. Fabricantes influenciam credenciais, serviços expostos, atualizações e suporte. Proprietários de equipamentos e redes de acesso podem detectar comportamento de saída anormal. Operadores de trânsito, mitigação e hospedagem controlam capacidade, encaminhamento, filtragem, telemetria e recuperação. Autoridades policiais tratam da responsabilização criminal dos operadores da botnet. [5][9]-[14]
O registro público não apresenta a topologia completa de mitigação da OVH em 2016, seus limiares privados de ativação, a quantidade exata de clientes afetados, as obrigações contratuais aplicáveis nem uma atribuição completa das redes de origem. Essas lacunas não devem ser preenchidas por suposições.
O teste central de responsabilização está no serviço em operação: a mitigação absorveu a combinação real de bits e pacotes, manteve o tráfego legítimo em movimento, limitou danos colaterais e produziu registros que clientes e operadores pudessem confrontar com o resultado observado?

Um terabit por segundo foi um alerta, não uma auditoria completa

Em setembro de 2016, a OVHcloud informou ter enfrentado tráfego superior a um terabit por segundo durante a primeira grande onda associada à Mirai. A explicação atual da empresa sobre ataques DDoS inclui o episódio na cronologia de ataques de grande escala, enquanto um texto técnico posterior da OVHcloud descreve a Mirai como a primeira botnet a gerar mais de 1 Tbps. [1][2] O número marcou uma mudança importante: equipamentos conectados de uso cotidiano, quando comprometidos em grande quantidade, podiam produzir pressão suficiente para desafiar infraestrutura de hospedagem de grande porte.

A magnitude, porém, não conta toda a história. Um pico medido pelo operador atacado não informa automaticamente em qual ponto da rede a medição ocorreu, durante quanto tempo ela se manteve, quais interfaces a registraram, quais tamanhos de pacote dominaram ou quantos destinos foram atingidos. Também não revela se o valor representa tráfego antes ou depois da filtragem, a soma de diversos locais ou um único enlace, nem quanto da inundação chegou efetivamente às redes de clientes.

Por isso, a formulação responsável é deliberadamente estreita: a OVH informou um pico superior a um terabit por segundo. O material público disponível não constitui uma verificação independente e pacote por pacote dessa medição. Reconhecer esse limite não diminui a relevância do episódio; impede apenas que um dado atribuído seja transformado em uma certeza que as fontes não sustentam.

A distinção importa porque a engenharia de DDoS depende do recurso realmente pressionado. Um ataque pode saturar um enlace físico, superar a capacidade de encaminhamento por pacotes de um roteador, esgotar uma plataforma de filtragem, consumir tabelas de estado, sobrecarregar o plano de controle ou atingir a aplicação depois de atravessar normalmente todos os equipamentos da rede. “Capacidade” não é uma reserva única e perfeitamente intercambiável.

Duas inundações com a mesma taxa de bits podem impor trabalhos muito diferentes. Pacotes grandes consomem largura de banda rapidamente, enquanto pacotes pequenos exigem muito mais decisões de análise, classificação, enfileiramento, encaminhamento ou descarte para transportar o mesmo volume de bits. Uma rede preparada para absorver certo número de gigabits por segundo pode falhar antes desse limite se sua taxa de processamento de pacotes, sua memória ou seu plano de controle atingirem o teto.

O texto técnico posterior da OVHcloud sobre ataques medidos em pacotes por segundo ajuda a definir essa superfície de controle. [2] Ele não demonstra qual equipamento, se algum, foi o gargalo do evento de 2016, nem revela a configuração privada então utilizada. Seu valor está em reforçar que uma avaliação séria precisa observar taxa de bits e taxa de pacotes, em vez de selecionar apenas a métrica mais impressionante.

Uma afirmação de capacidade deveria, portanto, responder a perguntas adicionais. Qual recurso foi medido? Em qual fronteira da rede? O pico foi instantâneo ou sustentado? Qual estado de mitigação estava ativo? Quanto tráfego legítimo continuou chegando? O que se tornou o próximo gargalo depois do desvio ou da filtragem? Quanto tempo foi necessário para retornar a uma condição estável?

É perfeitamente possível que um provedor relate com exatidão um grande pico e, ainda assim, deixe essas perguntas operacionais sem resposta pública. O número continua útil como sinal de risco e como referência histórica, mas não prova, sozinho, preparo suficiente, despreparo, negligência ou resiliência integral. Essas conclusões exigiriam registros da infraestrutura em operação, do impacto e da recuperação.

O valor de governança do episódio está justamente nessa limitação. Conselhos de administração, equipes técnicas e clientes aprenderam que pressupostos anteriores sobre escala poderiam ficar obsoletos rapidamente. A conclusão prudente não é exigir largura de banda infinita, mas exigir que os limites de cada componente sejam conhecidos, testados e ligados a evidências de continuidade do serviço.

A pesquisa independente estabelece a história da botnet, não o impacto privado da OVH

O relato técnico independente mais robusto sobre a Mirai é o estudo apresentado na USENIX Security. Seus autores reconstruíram o crescimento, a infraestrutura e a atividade de ataque da botnet usando várias fontes de dados e diferentes pontos de observação. O trabalho informa que os ataques contra a infraestrutura da OVH começaram em 18 de setembro de 2016, descreve uma população máxima de aproximadamente 600 mil dispositivos infectados e analisa mais de 15 mil ataques ao longo do período estudado. [3][4]

Esse trabalho é importante porque vai além de um gráfico divulgado por uma única empresa. A pesquisa conecta varredura, infecção, infraestrutura de comando e atividade ofensiva em uma cronologia medida. Ela mostra como dispositivos conectados e mal protegidos podiam ser recrutados em escala global e transformados em fontes distribuídas de tráfego.

A pesquisa também permite compreender melhor a diferença entre uma botnet que transmite diretamente e narrativas genéricas que tratam todos os grandes DDoS como se usassem o mesmo mecanismo. A distribuição geográfica e numérica da Mirai vinha da quantidade de dispositivos comprometidos. Ela não dependia, em sua capacidade central, de que cada pacote fosse uma resposta amplificada por um servidor intermediário.

Ainda assim, o estudo não contém o livro completo de impacto da OVH. Ele não revela todos os clientes afetados, cada intervalo de indisponibilidade, os limiares internos de filtragem, a topologia dos centros de mitigação, os contratos aplicáveis ou todos os pacotes vistos pelo operador. Também não demonstra que cada dispositivo infectado participou de cada ataque registrado.

Essa separação de evidências é essencial. Os pesquisadores observaram partes relevantes do ecossistema da botnet. A OVH controlava informações privadas sobre sua rede, decisões de mitigação e experiências de clientes. Redes de origem possuíam registros sobre conexões e dispositivos em seus próprios domínios. Provedores de trânsito detinham informações sobre caminhos, capacidade e ações tomadas nas interconexões. Nenhuma fonte, isoladamente, apresenta a cadeia inteira.

A cronologia também precisa manter separados os ataques contra KrebsOnSecurity, OVH e Dyn. A mesma família de malware apareceu em uma sequência histórica, mas os alvos e as dependências eram diferentes. O caso da Dyn tornou-se, entre outras coisas, uma questão de continuidade de DNS autoritativo. O episódio da OVH é um caso de hospedagem, absorção de tráfego hostil e preservação de conectividade para clientes. Fundir os eventos produziria uma narrativa maior, porém menos precisa.

O Departamento de Justiça dos Estados Unidos anunciou posteriormente declarações de culpa em casos relacionados à criação e à operação da Mirai. [5] Essa fonte sustenta a afirmação limitada de que réus identificados aceitaram responsabilidade criminal por condutas descritas no processo. Ela não autoriza concluir quem ordenou cada ataque observado pela OVH, qual era a intenção por trás de cada fluxo ou se proprietários de dispositivos e redes intermediárias tinham conhecimento da atividade.

Uma análise responsável distribui as fontes conforme aquilo que cada uma pode demonstrar. Materiais do operador sustentam medições e declarações atribuídas. A pesquisa independente sustenta a cronologia e a mecânica da botnet. Documentos governamentais sustentam fatos jurídicos delimitados e orientações gerais. Normas técnicas ajudam a avaliar controles. Nenhuma dessas categorias deve ser estendida para preencher evidências que pertenciam a outro participante.

Tráfego direto da Mirai não é sinônimo de reflexão e amplificação

A diferença entre tráfego direto de botnet e reflexão com amplificação determina quais controles são capazes de produzir resultado. Em um ataque refletido, o atacante envia uma solicitação a um serviço de terceiros usando como origem falsificada o endereço da vítima. O serviço responde à vítima e, em certos protocolos, a resposta pode ser muito maior que a solicitação. A infraestrutura intermediária funciona como refletor e amplificador.

Nesse cenário, a validação do endereço de origem pode impedir que a solicitação falsificada deixe a rede onde foi gerada. Restringir serviços de reflexão mal configurados também reduz a superfície de amplificação. É por isso que práticas antisspoofing são centrais em incidentes cujo mecanismo depende de endereços forjados.

A Mirai não precisava dessa arquitetura para sua capacidade fundamental. Câmeras, gravadores e outros equipamentos infectados podiam transmitir tráfego diretamente ao destino, usando endereços roteáveis comuns. A distribuição do ataque resultava da participação simultânea de muitos dispositivos comprometidos. A pesquisa da USENIX documenta a arquitetura da botnet e sua atividade, mas não implica que todos os pacotes tivessem o mesmo formato ou que cada ataque empregasse uma única combinação de vetores. [3][4]

Essa é a razão pela qual o BCP 38 é relevante, mas insuficiente para explicar o episódio. O RFC 2827 descreve filtragem de entrada destinada a restringir pacotes com endereços de origem falsificados. O RFC 3704 amplia a discussão para redes multihomed, nas quais a assimetria legítima de rotas pode tornar verificações simplistas perigosas. [15][16] O RFC 7039 e as orientações da MANRS apresentam melhorias e práticas operacionais para validação de origem. [19][20]

Esses controles reduzem ataques dependentes de falsificação, melhoram a qualidade da atribuição de rede e limitam determinadas formas de abuso. Eles não corrigem credenciais fracas em um dispositivo, não fecham um serviço de administração exposto, não aumentam a capacidade de processamento da vítima e não garantem que o tráfego legítimo sobreviva à filtragem. Sobretudo, não impedem um equipamento comprometido de enviar uma inundação direta usando o endereço que efetivamente lhe pertence naquele momento.

O diagnóstico correto muda o investimento necessário. Contra tráfego direto, operadores precisam analisar distribuição de origens, comportamento, protocolos, destinos e repetição; coordenar-se com redes de acesso; aplicar controles proporcionais; e filtrar fontes abusivas sem descartar indiscriminadamente usuários legítimos que compartilham a mesma região, operadora ou infraestrutura de endereçamento.

Em ataques refletidos, essas medidas continuam úteis, mas precisam ser combinadas com identificação dos protocolos amplificadores, redução de serviços expostos e pressão por validação de origem. Um ataque misto pode exigir ambos os conjuntos. Tratar todo DDoS como um problema exclusivamente de spoofing leva a uma política que pode funcionar muito bem contra um vetor e quase nada contra outro.

As orientações do NIST sobre troca resiliente de tráfego entre domínios tratam a defesa contra DDoS como uma combinação de segurança de roteamento, validação de origem, filtragem, blackholing remotamente acionado, FlowSpec, limitação de taxa, detecção e coordenação. [13][14] O RFC 4732 também apresenta negação de serviço como um problema amplo de engenharia e adverte que contramedidas podem produzir efeitos colaterais. [17]

Esses documentos posteriores não provam quais ferramentas a OVH utilizou em setembro de 2016. Eles servem para avaliar a lógica dos controles. A lição é que nenhuma medida deve ser promovida para além do mecanismo que consegue enfrentar. Precisão sobre a forma do ataque é, por si só, um requisito de responsabilização, pois define quem podia agir, qual ação fazia sentido e quais registros deveriam ter sido preservados.

A continuidade da hospedagem depende de uma cadeia, não de um equipamento

A responsabilidade central da OVH estava na rede de hospedagem operada para seus clientes. Diante de uma inundação distribuída, o provedor precisa observar o tráfego antes que ele provoque falha irreversível, identificar os recursos sob pressão, decidir quando ativar a mitigação e alterar o tratamento dos pacotes sem desestabilizar a própria conectividade.

Essa cadeia atravessa roteadores de borda, enlaces de trânsito e peering, backbone, sistemas de filtragem, caminhos de retorno, redes de clientes, automação, telemetria e comando do incidente. Um componente pode continuar saudável enquanto outro já está saturado. Um painel agregado pode parecer normal mesmo quando determinada região ou classe de tráfego perdeu conectividade.

A detecção começa pela telemetria, mas não pode depender de uma métrica isolada. Contadores de interface mostram taxa de bits, taxa de pacotes, erros e descartes. Registros de fluxo ajudam a observar protocolos, portas, distribuição das origens e concentração dos destinos. Contadores dos roteadores mostram pressão em filas e no plano de controle. Sistemas de mitigação indicam classificações e ações. Sondas externas revelam se transações úteis continuam sendo concluídas.

Cada visão tem limitações. Um pico pode representar ataque, lançamento legítimo de conteúdo ou falha de medição. Grande dispersão de origens pode indicar uma botnet ou demanda global autêntica. Uma plataforma de filtragem pode informar milhões de pacotes descartados enquanto os clientes permanecem indisponíveis porque o caminho de tráfego já limpo está congestionado. A responsabilização exige correlação entre sinais.

A decisão de ativar mitigação também introduz risco. Uma arquitetura sob demanda pode preservar o encaminhamento ordinário e reduzir custos, mas cria um intervalo de transição. Uma arquitetura sempre ativa elimina essa transição específica, porém adiciona dependência permanente e continua sujeita a limites de capacidade ou classificação. A escolha adequada depende da ameaça, do perfil dos serviços, da arquitetura e dos resultados de testes, não apenas de uma designação comercial.

Quando a mitigação entra em operação, o provedor precisa distinguir tráfego indesejado de pacotes necessários aos clientes. Uma assinatura estreita demais deixa parte da inundação passar. Uma regra ampla demais cria indisponibilidade autoinfligida. Limitar taxas pode proteger o núcleo da rede e simultaneamente prejudicar aplicações legítimas de alto volume. Bloquear uma região ou um ASN inteiro pode interromper fontes abusivas e usuários inocentes ao mesmo tempo.

Depois da filtragem, o tráfego legítimo ainda precisa percorrer um caminho viável até os serviços hospedados. Não basta remover pacotes hostis em um centro remoto se o enlace de retorno estiver subdimensionado, instável ou roteado de forma incorreta. Tampouco adianta filtrar localmente quando o circuito de acesso já está saturado antes do ponto de descarte.

Os materiais públicos não revelam a arquitetura completa da OVH durante o incidente. Portanto, não é possível afirmar quais centros, enlaces, roteadores ou regras compunham sua resposta privada. A avaliação defensável concentra-se naquilo que um operador deveria poder demonstrar: o caminho que permaneceu em funcionamento carregou tráfego legítimo, e os registros permitem verificar esse resultado?

Taxa de bits e taxa de pacotes expõem gargalos diferentes

Grandes ataques DDoS costumam ser descritos em bits por segundo porque a comparação com a capacidade nominal de um enlace é intuitiva. Se um circuito transporta certa quantidade de dados e a inundação se aproxima desse limite, o risco parece fácil de visualizar. A taxa de pacotes é menos conhecida fora das equipes de rede, mas pode ser igualmente decisiva.

Cada pacote precisa ser recebido, analisado, classificado, enfileirado, encaminhado ou descartado. Para a mesma quantidade total de bits, pacotes menores exigem um número muito maior dessas operações. Uma infraestrutura capaz de lidar com determinado volume em pacotes grandes pode atingir seu limite de processamento muito antes quando enfrenta milhões de pacotes pequenos por segundo.

Os limites de um roteador não formam uma única dimensão. Interfaces, circuitos integrados de encaminhamento, malha interna, buffers, processadores de rota, memória, tabelas de filtros e sistemas de telemetria podem falhar de maneiras distintas. Uma regra barata para um protocolo pode ser dispendiosa para outro. A exportação detalhada de fluxos, útil para análise, também pode consumir recursos justamente quando a rede está mais pressionada.

A discussão técnica posterior da OVHcloud sobre ataques de alta taxa de pacotes é relevante como orientação de engenharia. [2] Ela não identifica qual equipamento limitou a resposta de 2016. O ponto mais amplo é que planejamento de capacidade requer uma matriz de tamanhos de pacote, protocolos, distribuição de fontes, quantidade de destinos, número de prefixos, ações de filtragem e configurações de registro.

Os testes devem incluir a transição para o estado de mitigação. Um sistema pode absorver tráfego em regime estável e falhar quando novas regras são instaladas, rotas são desviadas ou o volume de telemetria aumenta. Também deve ser exercitada a perda parcial de capacidade, como a indisponibilidade de um local de mitigação ou o congestionamento de um caminho de trânsito.

É indispensável misturar tráfego legítimo aos testes. Um ensaio composto apenas por pacotes facilmente identificáveis como ataque demonstra capacidade de descarte, mas não mede o risco de falsos positivos nem a viabilidade do caminho limpo. A rede precisa sustentar o trabalho adicional da classificação enquanto aplicações reais continuam respondendo.

Os registros do teste devem preservar condições e pressupostos. Se uma plataforma foi validada para determinada taxa de pacotes, é necessário documentar tamanhos, protocolos, regras, quantidade de destinos e nível de telemetria. Se a capacidade é compartilhada entre regiões, deve existir uma explicação operacional de como uma crise em um local deixa reserva para os demais.

Números fornecidos por fabricantes ou laboratórios também precisam ser distinguidos de observações de produção. Condições controladas raramente reproduzem toda a diversidade de rotas, protocolos, exceções, falhas parciais e dependências existentes numa rede real. A comparação é útil, mas não substitui exercícios e dados do ambiente efetivamente operado.

Conselhos e clientes não precisam conhecer configurações sensíveis para compreender o limite de risco. Precisam saber se o provedor testa o recurso certo, se a ativação foi ensaiada, se existem domínios de falha independentes e se o resultado é medido no nível do serviço. Um único número em terabits não responde a essas perguntas.

O scrubbing só funciona quando o tráfego legítimo chega ao destino

A mitigação de DDoS possui dois resultados inseparáveis: rejeitar tráfego hostil e entregar tráfego legítimo. Provedores costumam enfatizar o primeiro porque volumes detectados e pacotes descartados são fáceis de apresentar. Clientes vivenciam o segundo. Se transações úteis não são concluídas, o caminho “limpo” não cumpriu sua finalidade.

O scrubbing, ou limpeza de tráfego, pode classificar pacotes com base em validade de protocolo, comportamento da origem, reputação, formato, destino, taxa e contexto da aplicação. Toda técnica envolve risco de falsos positivos e falsos negativos. Uma regra ampla contra UDP pode reduzir uma inundação e, ao mesmo tempo, interromper DNS, voz, jogos ou monitoramento legítimos.

Limites por origem podem penalizar usuários reunidos atrás de tradução de endereços. Desafios adequados a navegadores podem falhar para APIs ou aplicações automatizadas. Bloqueios geográficos podem atingir uma fonte concentrada de abuso e excluir mercados inteiros. Mesmo uma assinatura tecnicamente correta pode tornar-se inadequada quando o adversário muda de vetor.

O conjunto aceitável de regras depende do serviço protegido. Um provedor com muitos clientes não conhece antecipadamente cada padrão legítimo de protocolo e volume. Por isso, precisa combinar políticas gerais com controles específicos, contatos de emergência e caminhos de escalonamento. Clientes, por sua vez, precisam fornecer expectativas atualizadas sobre os serviços que realmente operam.

A prova de recuperação deve incluir sondas sintéticas e observações de uso real. Uma rota pode estar visível enquanto a origem permanece inacessível. Uma conexão TCP pode ser estabelecida, mas a aplicação não concluir a operação. Uma média global pode esconder perda regional. A mesma verificação precisa ser feita de redes e localidades diferentes.

Essas observações devem ser confrontadas com telemetria de roteadores, sistemas de mitigação e servidores de origem. Se a plataforma informa filtragem bem-sucedida, mas as sondas continuam falhando, o incidente não terminou. A divergência pode revelar congestionamento no retorno, bloqueio excessivo, problema de aplicação ou uma fronteira de medição mal compreendida.

Efeitos colaterais precisam permanecer no registro. Quais protocolos ou redes foram restringidos? Quais clientes precisaram de exceções? Uma regra protegeu um destino e transferiu pressão para outro? Por quanto tempo o serviço legítimo ficou degradado depois da queda do volume agregado? Apagar essas informações do fechamento impede que o próximo evento seja tratado melhor.

A transparência necessária não exige divulgar cada assinatura ou limiar. Detalhes operacionais podem ajudar atacantes. Um relatório público delimitado pode informar vetor, escala atribuída, período, ação principal, sinal de recuperação e incertezas. Evidências mais sensíveis podem ser preservadas para clientes, auditores ou autoridades sob condições apropriadas.

O material público da OVH demonstra a escala atribuída e a relevância da mitigação. [1][2] Ele não fornece um resultado de entrega limpa para cada cliente. Essa ausência é uma incerteza conhecida. Não prova que todos permaneceram acessíveis e tampouco prova que todos ficaram indisponíveis.

A pergunta correta não é apenas “quanto foi descartado?”, mas “qual trabalho legítimo continuou sendo concluído?”. Uma mitigação que protege os contadores internos enquanto usuários não alcançam o serviço representa sucesso documental sem sucesso operacional.

A responsabilidade começa antes de os pacotes chegarem à vítima

A Mirai transformou dispositivos comprometidos em infraestrutura distribuída para o atacante. A responsabilidade, portanto, começa antes de os pacotes atingirem o provedor de hospedagem, mas não pode ser atribuída indiscriminadamente a um único participante.

Fabricantes de equipamentos e fornecedores de software influenciam credenciais padrão, serviços de administração expostos, mecanismos de atualização, duração do suporte e possibilidade de recuperação. Credenciais únicas, interfaces restritas e atualizações autenticadas reduzem o risco de comprometimento. A ENISA chamou atenção para a possibilidade de objetos conectados de uso cotidiano se tornarem componentes de botnets. [9]

Os relatórios do período da Akamai ajudam a situar o ambiente de ataques DDoS e as preocupações de segurança observadas em 2016. [7][8] Eles oferecem contexto de ecossistema, mas não demonstram a configuração de um dispositivo específico nem identificam a composição exata de cada ataque contra a OVH.

O relatório dos departamentos de Comércio e Segurança Interna dos Estados Unidos tratou a ameaça de botnets como um problema que exige ação coordenada em todo o ecossistema tecnológico. [10][11] O trabalho do NIST sobre mitigação de DDoS baseado em dispositivos conectados também relaciona segurança dos equipamentos e resiliência da rede. [12] Essas fontes sustentam uma divisão de controles, não uma conclusão automática de culpa.

Proprietários de dispositivos controlam instalação e manutenção dentro dos limites impostos pelo produto. Podem alterar credenciais, restringir exposição, aplicar atualizações e substituir equipamentos sem suporte. Muitos não dispõem de conhecimento técnico, acesso administrativo ou atualização do fornecedor. Essa realidade afeta incentivos e soluções, mas não elimina o risco produzido por dispositivos permanentemente expostos.

Redes de acesso observam o tráfego que sai de seus clientes. Dependendo da arquitetura e das condições legais, podem detectar varredura anormal, grande dispersão de destinos ou atividade ofensiva sustentada; manter contatos de abuso úteis; notificar assinantes; e aplicar medidas proporcionais. As fontes públicas não justificam acusar uma rede específica de ter permitido conscientemente o ataque.

Um endereço visto no tráfego não identifica, por si só, a pessoa que controlava o equipamento. Pode apontar para uma conexão residencial, um gateway compartilhado, uma borda empresarial ou um endereço reassociado. Também não demonstra aquilo que o provedor de acesso conseguia observar em tempo real ou a resposta dada ao incidente.

Operadores de trânsito e mitigação podem fornecer capacidade adicional, blackholing, FlowSpec e filtragem coordenada. Sua posição permite reduzir tráfego antes que ele alcance o enlace da vítima. Essa capacidade traz riscos de autorização e dano colateral: um blackhole mal delimitado pode retirar do ar justamente o serviço que deveria proteger.

A OVH controlava sua borda de hospedagem, sua capacidade interna, a ativação de mitigação, a comunicação com clientes e os registros de recuperação. Por isso, é o operador central deste caso. Não controlava o firmware de todos os dispositivos nem cada rede de origem. O relatório do NSTAC sobre resiliência das comunicações reforça a importância da coordenação entre participantes e dependências da infraestrutura. [6]

As autoridades policiais possuíam outro tipo de controle: investigação e responsabilização criminal, não filtragem de pacotes em tempo real. O anúncio do Departamento de Justiça estabelece fatos delimitados sobre casos envolvendo a Mirai. [5] Não substitui a atuação técnica necessária durante o ataque.

A responsabilização deve acompanhar a capacidade prática de observar e modificar o sistema. Para cada participante, as perguntas são: o que podia enxergar, o que podia alterar, qual registro manteve e como sua decisão afetou o próximo elo? Essa abordagem evita concentrar toda consequência na marca mais visível e também impede que a dispersão de atores seja usada como desculpa para a ausência de ação.

Evidências da rede de origem precisam ser úteis sem virar acusação

Tráfego direto de botnet cria um problema delicado de evidência. O endereço de origem pode ser verdadeiro no sentido do roteamento, mas pode identificar uma conexão, um gateway com compartilhamento de endereços, uma borda corporativa ou um dispositivo comprometido — não a pessoa que lançou ou comandou o ataque.

Um relatório útil para a rede de origem deveria incluir horário com fuso, endereços de origem e destino, protocolo, portas, contagens de pacotes e bytes, método de amostragem, grau de confiança, ação de mitigação e avaliação sobre possível falsificação. Quando lícito e proporcional, uma pequena amostra ou assinatura pode ajudar o destinatário a distinguir o abuso do uso legítimo.

Registros de ASN e de recursos IP ajudam a identificar a rede responsável por um bloco de endereços e os contatos operacionais publicados. Eles são registros de delegação e metadados; não constituem prova de quem gerou um pacote. A origem de rota indica qual sistema autônomo anunciava alcançabilidade em determinado momento, mas não identifica o proprietário do equipamento infectado nem demonstra que a rede anunciante detectou a atividade.

O valor desses registros depende de precisão, atualização e ligação com equipes capazes de agir. Um contato desatualizado ou encaminhado a uma caixa sem atendimento transforma um registro formalmente completo em um controle operacional fraco. Da mesma forma, um ticket aberto sem dados suficientes pode não permitir que a rede encontre o assinante ou o equipamento.

A comunicação de abuso deve ser verificável e delimitada. O remetente precisa indicar lacunas de medição e evitar atribuir intenção. O destinatário precisa preservar a análise, a ação e o resultado. Relatórios repetidos e consistentes podem revelar um problema persistente; um único evento pode refletir comprometimento temporário, compartilhamento de endereço ou erro de classificação.

A MANRS traduz parte dessa responsabilidade em práticas de antisspoofing e coordenação. [20] Seu valor está em criar expectativas específicas. A adesão a uma norma, entretanto, não substitui evidência atual de filtragem, resposta e continuidade. O resultado operacional continua sendo o que a rede efetivamente observou e fez.

No caso da OVH, evidências sobre redes de origem poderiam apoiar notificações, filtragem mais precisa e redução de reincidência. O registro público não apresenta o conjunto completo de sistemas autônomos participantes nem a resposta de cada rede. A conclusão precisa parar nesse limite.

Ativar mitigação exige autoridade, ensaio e retorno seguro

O momento em que um operador modifica o tratamento do tráfego durante um grande ataque é, por si só, perigoso. Novas regras podem bloquear pacotes válidos. Uma mudança de rota pode retirar o prefixo errado. Um caminho de limpeza pode estar indisponível. Equipes diferentes podem aplicar ações conflitantes.

Uma política de ativação deve definir quem pode agir, quais prefixos e serviços estão no escopo, quais sinais justificam a intervenção e quais medições confirmam sucesso. A automação reduz o tempo de resposta, mas precisa ficar limitada a objetos e caminhos previamente aprovados. Situações inéditas podem exigir decisão humana, com um responsável claramente identificado.

Antes do incidente, o operador deveria testar autorizações de rota, sessões, comunidades BGP, listas de prefixos, caminhos de retorno e monitoramento. Precisa entender se o desvio parcial é possível e como serviços com estado se comportam sob roteamento assimétrico. O exercício deve considerar a perda de um provedor ou local de mitigação, e não apenas o cenário ideal.

Durante a resposta, cada alteração material precisa entrar em um registro comum com horário, responsável, objeto afetado, justificativa e condição de reversão. Isso não exige uma cerimônia lenta enquanto o serviço falha. Significa que todos sabem qual ação está ativa, quem responde pela próxima decisão e o que precisará ser removido posteriormente.

Observadores com acesso somente de leitura devem conseguir verificar rotas, filtros e saúde do serviço sem disputar autoridade de alteração. Essa separação reduz o risco de respostas concorrentes e cria uma linha de evidência para o fechamento do incidente.

A reversão merece o mesmo planejamento da ativação. Uma regra mantida depois do ataque pode prejudicar clientes silenciosamente. Retirar a proteção cedo demais pode expor o serviço a uma segunda onda. É necessário observar estabilidade, retornar por etapas e definir com antecedência os sinais que exigem reativação.

O RFC 4732 adverte que defesas contra negação de serviço podem produzir consequências indesejadas. [17] O RFC 4948 aborda desafios mais amplos de segurança da Internet, inclusive responsabilidades distribuídas e incentivos incompletos. [18] Esses documentos não descrevem o procedimento privado da OVH; sustentam o princípio de que uma contramedida deve ser avaliada pelos efeitos que produz em operação.

Ensaios importam porque um plano coerente no papel ainda pode falhar numa fronteira real. A rota pode não ser aceita pelo provedor. O enlace de retorno limpo pode ser pequeno demais. Uma dependência de cliente pode contornar a filtragem. Uma assinatura pode consumir mais recursos que o esperado. O fechamento persuasivo é aquele que demonstra, por exercício ou incidente, que o caminho planejado efetivamente transportou o serviço.

Um pacote de evidências defensável separa registros de resultados

O melhor fechamento pós-incidente não promete que um ataque semelhante jamais voltará a causar problemas. Ele mostra, com limites claros, o que ocorreu, quais controles foram ativados, como foram testados, qual resultado produziram e o que permanece desconhecido.

Superfície de controle	Evidência a preservar	Teste operacional	Limite importante
Detecção de tráfego	Telemetria sincronizada de interfaces, fluxos, taxa de pacotes e serviço	Vários sinais identificam a inundação antes de uma falha rígida	Amostragem e agregação podem ocultar efeitos breves ou locais
Limite de capacidade	Restrições de enlaces, encaminhamento, filtros e caminho limpo sob combinações declaradas de pacotes	Carga representativa permanece dentro dos recursos testados	Números de laboratório ou fornecedor podem divergir da produção
Autoridade de mitigação	Prefixos aprovados, responsáveis, sessões com provedores e política de ativação	Somente rotas e filtros pretendidos são alterados	Aprovação interna não prova convergência externa
Desvio de rota ou tráfego	Anúncios antes e depois, observações externas e aceitação pelo provedor	O tráfego pretendido chega ao caminho de mitigação	Coletores não enxergam todos os caminhos privados
Classificação do ataque	Protocolo, distribuição das origens, amostras e grau de confiança	As regras reduzem o vetor observado	O atacante pode mudar de vetor; assinaturas podem bloquear demais
Entrega de tráfego legítimo	Sondas regionais, sucesso da aplicação, latência e saúde da origem	Transações legítimas são concluídas durante a mitigação	Sondas sintéticas podem não representar todos os clientes
Efeitos colaterais	Classes legítimas descartadas, exceções e relatos de clientes	O dano permanece dentro de limites explícitos	Alguns usuários podem não comunicar falhas
Coordenação com redes de origem	Relatórios delimitados no tempo, contatos, ações e novas observações	A rede de origem consegue localizar e conter dispositivos comprometidos	Endereços não provam identidade humana ou intenção
Retorno ao estado normal	Registro das mudanças, responsável, critérios e reversão em etapas	O roteamento ordinário retorna sem recorrência imediata	Uma nova onda pode exigir reativação
Durabilidade da correção	Exercícios, exceções, revisões de capacidade e procedimentos atualizados	Os controles continuam aprovados ao longo do tempo	Um incidente bem-sucedido não é garantia permanente

A tabela separa documentação de resultado. Um ticket registra intenção. Um plano de capacidade registra pressupostos. Um registro de ASN identifica um domínio de roteamento. Uma configuração registra a regra aplicada. Nenhum desses itens, isoladamente, prova que usuários concluíram suas operações durante o ataque.

A reconciliação é o princípio central. Contadores de interface precisam ser compatíveis com a telemetria de mitigação. Mudanças de rota devem corresponder às observações externas disponíveis. A filtragem deve ser comparada com a saúde da origem e da aplicação. Relatos de clientes devem ser confrontados com sondas regionais.

Quando duas medições divergem, a resposta não deveria ser escolher aquela que produz a narrativa mais favorável. A diferença indica uma fronteira que precisa ser entendida: amostragem, atraso, agregação, caminho privado, visibilidade regional ou outro recurso sob pressão.

O pacote também deve separar material público de evidências protegidas. A divulgação pública pode apresentar período, escala atribuída, vetor, principais ações, recuperação e incertezas. Clientes, auditores ou autoridades, em condições apropriadas, podem examinar topologia detalhada, limiares, amostras, contratos e decisões internas.

Informações sensíveis não precisam ser expostas a atacantes para serem preservadas e revisáveis. O requisito de prestação de contas é que alguém autorizado consiga confrontar a afirmação do operador com o registro correspondente e com o resultado do serviço.

Uma evidência de recuperação também precisa ter duração. O primeiro teste bem-sucedido pode ocorrer enquanto filas ainda drenam, rotas ainda convergem ou filtros continuam mudando. O operador deve observar uma janela estável, regiões diferentes e os efeitos da reversão. Recuperação é um estado demonstrado, não o primeiro ponto verde de um painel.

O que o registro público não demonstra

As fontes sustentam que houve atividade significativa da Mirai contra a infraestrutura da OVH e que a empresa informou um pico superior a um terabit por segundo. [1]-[4] Sustentam também uma botnet distribuída de grande porte e a importância de controles em dispositivos, redes, roteamento, mitigação e resposta.

Elas não revelam os alvos exatos dentro da OVH, o número de clientes afetados, a duração do impacto para cada um, a topologia privada de scrubbing, as regras aplicadas, o limiar de ativação, a capacidade de reserva ou o caminho integral do tráfego legítimo.

O registro não oferece auditoria independente, pacote por pacote, do pico informado. Não estabelece perda financeira, créditos de serviço, violação contratual, negligência ou um padrão jurídico de responsabilidade. Também não identifica todos os dispositivos e sistemas autônomos que participaram de cada ataque contra a OVH.

Materiais posteriores da OVH ajudam a explicar preocupações com taxa de pacotes e roteadores. [2] Orientações posteriores da ENISA, NTIA, NIST, IETF e MANRS explicam controles em camadas. [9]-[20] Nenhuma dessas fontes demonstra que um controle específico estava implantado, na forma descrita posteriormente, na rede privada da OVH em setembro de 2016.

O documento do Departamento de Justiça estabelece fatos limitados sobre declarações de culpa em casos relacionados à Mirai. [5] Ele não demonstra quem ordenou cada fluxo observado pela OVH nem autoriza atribuir todos os pacotes aos réus identificados.

Esses limites não tornam o caso inútil. Eles definem a tese que pode ser defendida. É possível avaliar quais controles um operador de hospedagem e seus parceiros deveriam conseguir demonstrar. Não é possível fabricar um relatório privado de incidente a partir de resumos públicos.

Perguntas para operadores, clientes e revisores

Operadores de hospedagem, trânsito e mitigação deveriam perguntar:

As linhas de base incluem taxa de bits, taxa de pacotes, protocolos, destinos e sucesso do serviço?
Qual componente se torna o gargalo sob pacotes pequenos, pacotes grandes e tráfego misto?
Quais prefixos, locais e clientes podem ser desviados ou filtrados de forma independente?
Sessões de mitigação, autorizações de rota e caminhos limpos de retorno são exercitados?
Os responsáveis conseguem enxergar, durante o ataque, a capacidade dos provedores e o estado da filtragem?
Quais classes de tráfego legítimo estão protegidas contra regras amplas?
Existe um responsável inequívoco pela ativação e pela reversão?
Relatórios às redes de origem contêm evidência precisa, proporcional e delimitada?
A recuperação depende de sistemas que também podem estar sobrecarregados?
Sondas externas e relatos de clientes são reconciliados com painéis internos?

Fabricantes e proprietários de dispositivos deveriam perguntar:

As credenciais são únicas e os serviços de administração ficam restritos por padrão?
O equipamento recebe atualizações autenticadas durante sua vida útil?
O encerramento do suporte é informado antes que o dispositivo se transforme em infraestrutura permanentemente vulnerável?
O proprietário consegue observar varredura ou tráfego de saída anormal?
É viável isolar ou substituir um equipamento que não pode mais ser corrigido?
As configurações inseguras podem ser alteradas sem conhecimento especializado indevido?

Clientes de hospedagem deveriam perguntar:

Quais escalas e combinações de pacotes o provedor testou em condições realistas?
A mitigação é permanente, sob demanda ou híbrida, e quais sinais acionam a mudança?
Quais protocolos do cliente podem ser restringidos durante uma filtragem emergencial?
Como o provedor demonstrará entrega limpa e recuperação regional?
Quais evidências e formas de comunicação estarão disponíveis depois do incidente?
Provedores, rotas e origens alternativos são realmente independentes e foram testados?
O contrato distingue capacidade de absorção, disponibilidade da aplicação e dano colateral?

Auditores e reguladores deveriam perguntar:

Afirmações de capacidade estão ligadas a interfaces, combinações de pacotes, regras e datas específicas?
A evidência demonstra conclusão de serviço, ou apenas descarte de tráfego hostil?
Autoridade de mitigação e reversão estão limitadas aos recursos aprovados?
Evidências privadas de pacotes ou topologia podem ser examinadas sem divulgação pública insegura?
Afirmações de correção possuem resultados atuais de exercícios e registros de exceções?
Cadastros de recursos e contatos de abuso estão conectados a uma resposta operacional real?
Incertezas e conflitos entre medições foram preservados no fechamento?

Essas perguntas não exigem capacidade infinita nem prometem ausência total de falhas. Elas verificam se o operador conhece seus limites, detecta uma classe conhecida de ameaça, atua dentro de autoridade controlada, preserva o serviço essencial e consegue explicar o resultado.

Conclusão: a capacidade se torna responsável quando o tráfego legítimo sobrevive

O relato da OVHcloud sobre um ataque da Mirai superior a um terabit por segundo continua sendo um marco na história da escala dos DDoS. A pesquisa independente mostra como uma grande população de dispositivos comprometidos podia gerar tráfego direto e distribuído. Fontes técnicas, governamentais e setoriais demonstram por que a resposta atravessa segurança dos dispositivos, redes de origem, trânsito, hospedagem, filtragem e responsabilização criminal. [1]-[20]

A conclusão central não é que um provedor deveria comprar uma quantidade ilimitada de largura de banda. Nenhuma rede pode prometer absorver toda inundação concebível. O requisito é ligar cada afirmação de capacidade a evidências da infraestrutura em funcionamento.

Essas evidências incluem taxa de bits e de pacotes em fronteiras identificadas, limiar documentado de ativação, autoridade controlada para filtros e rotas, capacidade suficiente no caminho limpo, sondas de serviço, registros de dano colateral, coordenação com redes de origem e reversão ensaiada.

A análise também precisa distinguir tráfego direto de botnet de reflexão e amplificação. A validação de origem deve ser aplicada onde seu mecanismo produz efeito, e não tratada como solução universal. Cada ator deve responder pelos controles que efetivamente possuía e pelas evidências que podia produzir.

Registros de ASN, gráficos de tráfego, planos de capacidade, configurações e tickets são documentos importantes. Eles não são o serviço. A prova decisiva é se pacotes legítimos chegaram ao destino enquanto o tráfego hostil era contido, se o recurso restritivo permaneceu dentro de limites conhecidos e se outra parte autorizada poderia verificar a recuperação.

Fontes

OVHcloud, “What is a DDoS attack?”: https://www.ovhcloud.com/en-gb/security/anti-ddos/ddos-definition/
OVHcloud, “The rise of packet rate attacks: when core routers turn evil”: https://blog.ovhcloud.com/en/posts/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/
USENIX Security 2017, “Understanding the Mirai Botnet”, página da apresentação: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis
Antonakakis et al., “Understanding the Mirai Botnet”: https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf
Departamento de Justiça dos Estados Unidos, acusações e declarações de culpa relacionadas à Mirai: https://www.justice.gov/archives/opa/pr/justice-department-announces-charges-and-guilty-pleas-three-computer-crime-cases-involving
National Security Telecommunications Advisory Committee, relatório sobre resiliência da Internet e das comunicações: https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20President%20on%20ICR%20FINAL%20%2810-12-17%29%20%281%29-%20508%20compliant_0.pdf
Akamai, resumo executivo do relatório State of the Internet Security do terceiro trimestre de 2016: https://www.akamai.com/site/en/documents/state-of-the-internet/q3-2016-state-of-the-internet-security-executive-summary.pdf
Akamai, anúncio do relatório State of the Internet Security do terceiro trimestre de 2016: https://www.akamai.com/content/akamai/it/newsroom/press-release/akamai-releases-third-quarter-2016-state-of-the-internet-security-report1
ENISA, “The Internet of Things: when your washing machine and blood pressure monitor become a target for cyberattacks”: https://www.enisa.europa.eu/news/enisa-news/the-internet-of-things-when-your-washing-machine-and-blood-pressure-monitor-become-a-target-for-cyberattacks
NTIA, anúncio do relatório dos departamentos de Comércio e Segurança Interna sobre botnets: https://www.ntia.gov/press-release/2018/us-departments-commerce-homeland-security-release-report-president-promoting-action-against-botnets
Departamentos de Comércio e Segurança Interna dos Estados Unidos, relatório sobre botnets: https://www.ntia.gov/sites/default/files/publications/eo_13800_botnet_report_for_public_comment_0.pdf
NIST, “Mitigating IoT-Based DDoS”: https://csrc.nist.gov/pubs/pd/2017/12/14/mitigating-iotbased-ddos/final
NIST, “Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation”: https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation
NIST Special Publication 800-189: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
IETF, RFC 2827 / BCP 38, Network Ingress Filtering: https://datatracker.ietf.org/doc/rfc2827/
IETF, RFC 3704 / BCP 84, Ingress Filtering for Multihomed Networks: https://datatracker.ietf.org/doc/rfc3704/
IETF, RFC 4732, Internet Denial-of-Service Considerations: https://datatracker.ietf.org/doc/rfc4732/
IETF, RFC 4948, Internet Security Challenges: https://datatracker.ietf.org/doc/rfc4948/
IETF, RFC 7039, Source Address Validation Improvement: https://datatracker.ietf.org/doc/html/rfc7039
MANRS, Network Guide: Anti-Spoofing: https://docs.manrs.org/docs/network-guide/anti-spoofing/