O DDoS do Great Cannon contra o GitHub em 2015 transformou a inje

Resumo

O GitHub informou que o ataque distribuído de negação de serviço começou por volta das 02h00 UTC de 26 de março de 2015 e combinou vetores conhecidos com técnicas que fizeram navegadores de pessoas não envolvidas enviarem tráfego ao serviço. [1]
A GreatFire relatou uma ofensiva anterior contra seus próprios serviços e afirmou posteriormente que JavaScript malicioso havia substituído recursos associados ao Baidu Analytics. A organização atribuiu a atividade às autoridades chinesas; o Baidu negou que seus produtos tivessem sido comprometidos. [7][8]
Pesquisadores do Citizen Lab e de instituições colaboradoras descreveram um sistema posicionado na rede que podia interceptar solicitações HTTP selecionadas, inserir respostas substitutas e induzir navegadores fora da China a realizar chamadas repetidas contra alvos definidos. [2][3][4][5]
A avaliação de que o provável operador era ligado ao governo chinês pertence aos pesquisadores citados. Ela não constitui decisão judicial, prova pública de uma ordem individual nem identificação completa da cadeia de comando.
O mecanismo não foi reflexão com endereço de origem falsificado e não correspondeu ao funcionamento convencional de uma botnet formada por dispositivos previamente invadidos. Os navegadores emitiram conexões reais depois de executar código recebido no caminho. [6]
Validação de endereço de origem continua essencial contra tráfego forjado, mas não bloqueia diretamente solicitações genuínas iniciadas por navegadores com endereços plausíveis. [11][12][13][14][17]
Criptografia autenticada reduz drasticamente a oportunidade de substituição silenciosa da resposta, embora não elimine bloqueio, comprometimento de pontas, manipulação de rotas, análise de tráfego ou outras modalidades de DDoS. [15][16]
A responsabilidade precisa ser distribuída conforme o controle efetivo de operadores de trânsito, publicadores de recursos externos, sites incorporadores, navegadores, GitHub e fornecedores de mitigação.
A lição duradoura é a primazia do que a rede realmente executou: registros administrativos descrevem a intenção, mas somente observações verificáveis de entrega, rota, integridade e comportamento demonstram o resultado operacional.

Um ataque cuja característica decisiva estava no caminho

Em março de 2015, o GitHub se tornou o alvo mais visível de uma ofensiva cuja importância não pode ser medida apenas pela palavra “DDoS”. O aspecto decisivo estava na forma como o tráfego teria sido produzido. Pessoas acessavam páginas comuns, seus navegadores buscavam um recurso externo por HTTP sem proteção criptográfica autenticada e, em determinados trajetos, recebiam JavaScript diferente daquele esperado. Esse código fazia o navegador enviar repetidamente solicitações contra conteúdo hospedado no GitHub.

A conexão resultante era real. O endereço do cliente era real. O navegador funcionava como havia sido instruído pelo conteúdo que aceitara. O que faltava era a intenção do usuário. Quem operava o computador não havia escolhido participar da ofensiva, não precisava ter instalado um programa malicioso persistente e não necessariamente tinha conhecimento de que sua capacidade de rede estava sendo empregada contra outra organização.

Essa diferença impede que o episódio seja tratado como apenas mais um caso genérico de ataque digital. Em uma reflexão tradicional, o agressor pode falsificar o endereço da vítima para que serviços intermediários enviem respostas ao alvo. Em uma botnet convencional, dispositivos previamente comprometidos recebem comandos de uma infraestrutura de controle. Na reconstrução pública do Great Cannon, porém, o ponto decisivo era a alteração de uma resposta web durante seu trânsito.

O navegador era recrutado temporariamente pelo código recebido, não por uma falsificação simples do endereço nem, necessariamente, por uma invasão persistente da máquina.

Quando o controle está no caminho, o mapa de responsabilidade muda. O GitHub administrava a disponibilidade do destino, mas não controlava a entrega remota do recurso adulterado. O publicador do recurso e os sites que o incorporavam controlavam escolhas relativas a HTTP, HTTPS e dependências executáveis. Desenvolvedores de navegadores controlavam parte das regras de conteúdo misto, validação de transporte e contenção de comportamento abusivo. Operadores de acesso e trânsito controlavam segmentos distintos da rota, seus equipamentos e seus registros. O usuário final quase nada controlava nessa cadeia.

É justamente por isso que o caso se tornou um teste de responsabilização da infraestrutura de rede. A pergunta central não é apenas “quem atacou?”, mas “quem podia observar, alterar, impedir, registrar ou comprovar cada transformação entre o recurso solicitado e o código executado?”.

O que o registro público permite afirmar

O comunicado do GitHub é o ponto inicial mais seguro para delimitar o evento. A empresa declarou que a ofensiva começou aproximadamente às 02h00 UTC de 26 de março de 2015 e que, naquele momento, era o maior DDoS já enfrentado pelo serviço. Também informou que a atividade reunia diferentes vetores e incluía técnicas sofisticadas capazes de levar navegadores pertencentes a pessoas sem relação com o caso a inundar o site com tráfego. Segundo o GitHub, os relatos disponíveis indicavam uma tentativa de pressionar a plataforma a remover determinada classe de conteúdo. [1]

Esse comunicado estabelece a observação operacional da vítima e sua interpretação do objetivo aparente. Não estabelece, por si só, o volume completo da ofensiva, a quantidade exata de navegadores envolvidos, perdas financeiras, impactos específicos para cada cliente ou o momento preciso da recuperação. Tampouco identifica uma pessoa que tenha dado uma ordem, administrado cada componente ou decidido cada alvo.

A GreatFire apresentou uma cronologia a partir de sua posição de organização afetada. Relatou que seus serviços vinham recebendo uma grande enxurrada de solicitações desde 17 de março e afirmou depois que JavaScript malicioso, substituído em recursos associados ao Baidu Analytics, direcionava navegadores a material da GreatFire e a duas páginas hospedadas no GitHub. A GreatFire atribuiu a ação às autoridades chinesas. O Baidu, por sua vez, negou que seus produtos tivessem sido comprometidos. [7][8]

As duas posições precisam permanecer visíveis. A alegação da GreatFire é relevante, assim como sua cronologia, mas continua sendo a atribuição de uma parte afetada. A negativa do Baidu também não resolve sozinha o mecanismo. Comprometimento do servidor de origem, participação consciente do publicador, uso indevido de um recurso legítimo e substituição no caminho são hipóteses factualmente distintas. O próprio valor técnico da reconstrução está em não confundi-las.

A base pública mais forte sobre o funcionamento veio do Citizen Lab, do International Computer Science Institute, da Universidade da Califórnia em Berkeley, de pesquisadores de Princeton e de colaboradores. Os estudos diferenciaram o sistema denominado Great Cannon do Great Firewall, embora tenham apontado semelhanças de código e de localização na rede. Por meio de medições e características observáveis, os pesquisadores descreveram a interceptação seletiva de solicitações HTTP e a inserção de conteúdo que levava navegadores a enviar tráfego aos alvos. [2][3][4][5]

Os autores sustentaram uma avaliação de provável operação governamental chinesa, preservando limites de confiança. Essa formulação importa. Uma inferência técnica baseada em posição na rede, comportamento e semelhanças de implementação pode ser forte sem equivaler a uma sentença, a uma confissão ou à exposição completa de uma cadeia institucional. A linguagem responsável deve acompanhar a qualidade da evidência.

Assim, o registro público sustenta uma conclusão delimitada: houve um grande ataque de disponibilidade contra o GitHub; a GreatFire descreveu uma fase anterior e uma conexão com páginas hospedadas na plataforma; medições independentes documentaram um mecanismo capaz de substituir conteúdo HTTP e recrutar navegadores; as atribuições vieram de partes nomeadas e de pesquisadores; detalhes fundamentais sobre implementação interna, comando e extensão dos danos não foram divulgados.

Como a injeção transformou visitantes em fontes de tráfego

O mecanismo começa com uma aparente banalidade da web: uma página incorpora um recurso externo, como um script de análise, entregue por HTTP em texto claro. O navegador solicita esse recurso e espera receber determinado conteúdo do publicador indicado pelo endereço. Sem autenticação criptográfica do canal, entretanto, o navegador não possui uma prova robusta de que a resposta atravessou o caminho sem alteração.

Um sistema em posição adequada pode observar a solicitação e tentar inserir uma resposta própria. Se essa resposta for aceita antes da legítima, o navegador poderá executar o conteúdo substituto como se viesse do recurso esperado. No caso reconstruído pelos pesquisadores, o código fazia o cliente disparar repetidas solicitações a destinos selecionados.

Há pelo menos três identidades diferentes nessa sequência. A primeira é a identidade administrativa do recurso: o nome, o endereço e o serviço que o usuário pretendia alcançar. A segunda é a origem efetiva dos bytes aceitos pelo navegador. Em HTTP sem autenticação, ambas podem divergir sem que o cliente tenha uma prova criptográfica imediata da adulteração. A terceira é a identidade da conexão posterior contra o GitHub: o endereço do navegador que executou o código.

Confundir essas identidades produz erros graves. O endereço do cliente não comprova intenção hostil. O nome do recurso não comprova que seu servidor gerou o conteúdo adulterado. Um registro DNS correto não comprova integridade de resposta. Uma rota observada não localiza, sozinha, o ponto de inserção. E uma solicitação HTTP válida contra o GitHub pode ter sido provocada por código recebido sem conhecimento do usuário.

A reconstrução exige, portanto, uma cadeia verificável: qual recurso foi solicitado; por qual esquema de transporte; em quais redes; quais respostas chegaram a diferentes pontos de observação; que conteúdo foi executado; quando as chamadas ao alvo começaram; e quais sistemas registraram a sequência. A responsabilidade nasce da possibilidade concreta de responder a essas perguntas.

Primazia do código em execução: o eixo Heng.lu

O princípio Heng.lu da primazia do código em execução oferece a lente adequada para compreender o episódio. Registros de DNS, alocações de endereços, nomes de repositórios, contratos de hospedagem e relações de trânsito documentam identidades e poderes pretendidos. São peças essenciais de um livro-razão operacional. Não são, porém, soberanos sobre aquilo que a rede efetivamente entregou.

Em 2015, um navegador podia resolver o nome esperado, procurar o recurso esperado e atravessar uma rota aparentemente compatível com os registros disponíveis, mas ainda executar bytes inseridos no trajeto. O plano administrativo continuava reconhecível; a realidade operacional havia divergido.

A primazia do código em execução não diminui o valor dos registros. Ela exige que registros sejam reconciliados com observações. DNS e informações de roteamento ajudam a reconstruir a expectativa. Certificados e propriedades do transporte mostram se havia autenticação. Horários, hashes de conteúdo, respostas coletadas em redes distintas e comportamento do navegador mostram o resultado. Evidência de mitigação mostra como o serviço reagiu. Nenhum desses elementos, isoladamente, deve ser convertido em veredicto absoluto.

Essa é também a camada da realidade que evita transformar o caso em defesa automática de qualquer governo, plataforma, organização ativista ou política tecnológica. O ponto não é exigir que toda análise adote uma posição política comum. O ponto é determinar quem detinha controle sobre o caminho, quais bytes foram entregues, quais registros poderiam comprovar a operação e como a disponibilidade foi preservada.

As superfícies de peering, trânsito e interconexão são centrais porque definem os domínios administrativos atravessados. A identidade de hospedagem é central porque estabelece o recurso que o cliente acreditava acessar. A continuidade operacional é central porque o GitHub precisava manter o serviço e o conteúdo disponível sob pressão. Se esses elementos forem removidos, sobra apenas uma narrativa genérica de ataque; com eles, aparece a questão específica de responsabilidade sobre infraestrutura.

Por que BCP 38 não resolveria esse mecanismo sozinho

A validação de endereço de origem é uma proteção indispensável contra formas de DDoS que utilizam endereços falsificados. A prática descrita pelo BCP 38 e por documentos posteriores procura impedir que uma rede envie tráfego com origens que não deveriam ser alcançáveis por aquela interface. Métodos mais recentes de validação por caminho viável tratam dos desafios de redes com múltiplas rotas. As orientações do NIST inserem esse controle em uma estratégia mais ampla que também envolve segurança de roteamento e mitigação de negação de serviço. [12][13][14][17]

Quando um agressor falsifica o endereço da vítima e envia consultas a serviços amplificadores, a filtragem de origem pode interromper uma parte fundamental da ofensiva. A resposta deixa de ser direcionada com tanta facilidade a quem nunca iniciou a solicitação. A implantação correta desses controles por redes de acesso, hospedagem e trânsito continua sendo uma responsabilidade coletiva de grande importância.

No Great Cannon, entretanto, os navegadores teriam aberto conexões verdadeiras a partir de seus próprios endereços. Para um filtro de origem, o tráfego podia parecer topologicamente legítimo. O problema não estava em um campo de origem fabricado, mas no código que havia induzido o cliente a iniciar a comunicação.

Dizer isso não reduz a importância do BCP 38. Um ataque pode combinar vetores, e a redução de tráfego falsificado preserva capacidade de resposta para outros componentes. A validação também aumenta o valor probatório do endereço observado, desde que ninguém confunda localização de conexão com intenção do usuário.

A lição é de correspondência entre controle e propriedade protegida. Validação de origem combate falsificação. Criptografia autenticada protege integridade e autenticidade do conteúdo em trânsito. Restrições do navegador limitam execução e abuso. Capacidade de borda, filtragem e distribuição de carga defendem disponibilidade. Segurança de roteamento reduz outras formas de desvio ou origem indevida de rotas. Não existe um único controle capaz de resolver todas essas dimensões.

O que a criptografia autenticada muda — e o que ela não muda

HTTP em texto claro permite que um intermediário veja a solicitação e tente substituir a resposta sem produzir uma prova criptográfica inevitável da adulteração. Essa exposição foi a condição técnica decisiva no mecanismo atribuído ao Great Cannon.

Um canal TLS corretamente autenticado altera a situação. O navegador espera negociar proteção com o destino pretendido e validar a identidade apresentada. Dentro do seu escopo de segurança, o TLS protege contra leitura, modificação e falsificação das mensagens. A formulação posterior do TLS 1.3 torna claros esses objetivos, enquanto o RFC 7258 trata a vigilância disseminada e a subversão do tráfego como ataques que o desenho de protocolos deve enfrentar. [15][16]

Se a autenticação funcionar, um sistema no caminho não pode simplesmente trocar o JavaScript e apresentar o resultado como uma resposta válida sem atacar a autenticação, comprometer uma ponta ou explorar outra dependência de confiança. A adulteração tende a se transformar em falha visível, em vez de código silenciosamente aceito.

Mas a conclusão precisa permanecer delimitada. HTTPS não impede que a rede bloqueie uma conexão, injete um reset, manipule alcance, pressione intermediários ou lance um DDoS por outro vetor. Não protege um servidor já comprometido. Não garante que código legítimo de terceiros seja seguro. Não elimina análise de tráfego nem corrige toda configuração defeituosa. Também não transfere automaticamente a responsabilidade por disponibilidade ao operador do canal criptográfico.

A alegação adequada é mais precisa: a criptografia autenticada eleva substancialmente o custo da substituição simples de respostas no caminho e fornece ao cliente um critério de integridade. Ela reduz uma oportunidade específica; não encerra toda a classe de riscos de rede.

Evidência a partir de vários pontos de observação

Um sistema de injeção pode agir seletivamente. Pode reagir apenas a um nome, caminho, origem, destino, horário ou expressão da solicitação. Pode aparecer em uma rota e não em outra. Pode enviar uma resposta adulterada em alguns momentos e deixar a legítima prevalecer em outros. Uma observação isolada dificilmente distingue servidor comprometido, alteração no trânsito, interferência local e comportamento normal de um terceiro.

A medição distribuída reduz essa ambiguidade. Investigadores podem solicitar o mesmo recurso por redes diferentes, registrar horários, comparar o conteúdo recebido, preservar hashes, verificar autenticação e observar diferenças de latência. Se uma rede recebe uma resposta alterada e outra recebe a versão esperada, o conjunto de pontos possíveis se estreita. Se o servidor de origem não registra o conteúdo estranho, a hipótese de alteração no caminho ganha força, embora isso não exclua automaticamente todas as demais possibilidades.

O tempo precisa ser tratado como evidência. Relacionar a busca do recurso, a chegada do conteúdo, sua execução e o início das solicitações contra o GitHub depende de relógios comparáveis. Desvio de horário, atraso de coleta e conversão de fuso podem criar uma sequência enganosa. Uma cronologia confiável registra essas limitações.

Dados de roteamento ajudam a descrever por quais sistemas autônomos a conectividade observada passou e quais anúncios eram públicos no período. Não demonstram sozinhos o local exato da alteração. Caminhos internos, políticas privadas e equipamentos intermediários podem não aparecer em coletores públicos. Da mesma forma, registros de endereço indicam alocação e contato administrativo, não necessariamente o dispositivo que realizou determinada ação.

A coleta também deve respeitar a privacidade. Conteúdo de navegação e registros detalhados podem revelar informações pessoais. Preservar evidência exige minimização, controle de acesso, integridade dos artefatos e retenção proporcional. Privacidade não justifica apagar a realidade técnica, mas investigação tampouco autoriza a acumulação irrestrita de dados alheios ao evento.

O limite de controle do GitHub

O GitHub era o operador da infraestrutura atingida. Sua responsabilidade imediata abrangia disponibilidade, integridade do conteúdo hospedado, classificação do tráfego, proteção de aplicações, coordenação com fornecedores de mitigação e comunicação com os usuários. A empresa não podia corrigir diretamente uma resposta remota alterada em outra rede, mas controlava como sua borda reagia às solicitações resultantes.

Um relato anterior do próprio GitHub sobre defesa contra DDoS descreveu medidas em camadas, como ajustes da pilha de rede, limites em balanceadores, equipamentos de filtragem e cooperação com um fornecedor externo. [9] Esse material oferece contexto de arquitetura, não comprovação de que todos os controles estavam ativos, iguais ou eficazes em março de 2015.

Para demonstrar resposta responsável, um operador na posição do GitHub deveria preservar a distribuição das origens, os caminhos requisitados, o comportamento das conexões, o estado de caches e aplicações, as mudanças de filtragem, as entregas ao fornecedor de mitigação e os efeitos observados. Também deveria registrar falsos positivos, usuários legítimos afetados e o custo operacional de cada medida.

O fato de as solicitações parecerem válidas torna a classificação delicada. Bloquear todo endereço que produziu uma rajada poderia prejudicar pessoas que compartilhavam uma rede ou desconheciam a atividade do navegador. Desafios agressivos poderiam impor barreiras de acessibilidade. Respostas caras poderiam ampliar o consumo de recursos. Retirar o conteúdo visado poderia aliviar uma pressão imediata, mas também permitir que o agressor interferisse na política de hospedagem.

Nada disso autoriza inventar uma sequência precisa de recuperação ou avaliar como heroica ou negligente uma decisão não documentada. O comunicado público não apresenta todos os controles empregados nem a duração exata de cada etapa. O padrão de responsabilização deve reconhecer o desconhecido e, ao mesmo tempo, definir quais evidências um operador deveria manter.

Operadores de trânsito e o dever de manter controle verificável

Uma posição no caminho confere poder técnico. Sistemas capazes de inspecionar ou alterar conteúdo podem selecionar fluxos, responder a solicitações e modificar o que um cliente recebe. Quem administra uma capacidade dessa natureza deveria manter registros capazes de demonstrar sua finalidade, autorização, configuração e uso.

Esse dever inclui identificar os componentes que implementam a função, as funções organizacionais autorizadas a modificá-los, os controles contra uso indevido, os momentos de ativação e as mudanças realizadas. Quando uma organização nega participação, registros verificáveis são mais persuasivos do que uma declaração ampla sem suporte operacional.

Isso não significa responsabilizar todo provedor que transportou o tráfego. Rotas da internet atravessam diversos domínios. Alguns operadores podem não ter visibilidade do conteúdo; outros podem não estar no trecho relevante no momento observado. A responsabilidade deve acompanhar a capacidade real de agir e a qualidade da evidência, não apenas proximidade geográfica, propriedade formal de um endereço ou associação política.

Relações de peering e trânsito introduzem desafios adicionais. Contratos podem limitar divulgação, e operadores têm razões legítimas para não expor detalhes defensivos. Ainda assim, confidencialidade comercial não elimina o dever de manter internamente instantâneos de rotas, identificadores de interfaces, aprovações de mudança e registros íntegros. É possível publicar conclusões delimitadas sem expor toda a topologia.

Essa separação entre registro e realidade é central à tese Heng.lu. O sistema de numeração e os registros de rede funcionam como livro-razão: devem oferecer unicidade, precisão, histórico de transferência, metadados de segurança e continuidade operacional. Eles não são prova autossuficiente sobre os bytes entregues por uma sessão específica. Sua legitimidade prática depende de conexão com evidência observável.

Publicadores de recursos externos e sites que os incorporam

O mecanismo descrito dependia da busca de recursos externos por HTTP. Isso coloca publicadores e sites incorporadores no mapa de responsabilidade, mas não os transforma automaticamente em autores da adulteração.

O publicador controla a oferta de transporte autenticado, políticas de redirecionamento, configuração de cache e investigação de respostas inconsistentes. O site que incorpora o recurso decide se uma dependência externa poderá executar código e se aceitará uma origem não autenticada. O navegador define como tratar conteúdo misto e quais restrições aplicar.

No caso do Baidu, a negativa de comprometimento deve ser mantida junto com a hipótese de substituição no caminho. [8] Uma das características mais perigosas dessa técnica é fazer um serviço legítimo parecer responsável por bytes que ele afirma não ter enviado. A resposta correta não é escolher antecipadamente entre acusação e negativa, mas comparar registros do servidor, resultados obtidos em redes distintas, propriedades do transporte e conteúdo preservado.

Inventários de dependência são essenciais. Uma organização deveria saber quais scripts externos suas páginas carregam, quem os administra, por qual protocolo são entregues, como recebem atualizações e o que acontece quando falham. Recursos capazes de executar código exigem controle mais rigoroso do que elementos estáticos.

Mecanismos como restrições de conteúdo e verificação de integridade podem ajudar em algumas arquiteturas, mas possuem limites. O navegador precisa receber um valor confiável, a página precisa aplicá-lo e recursos dinâmicos podem dificultar a implantação. Não existe atalho que substitua transporte autenticado, gestão de dependências e observação da entrega.

Sobretudo, não se deve transferir ao usuário uma responsabilidade que ele não podia exercer. A pessoa cujo navegador foi temporariamente recrutado não escolheu a rota, não administrava o recurso de terceiros e possivelmente nem viu o código. Recomendações genéricas de “navegação segura” não corrigem uma alteração praticada em infraestrutura compartilhada.

Navegadores como fronteira de execução

O navegador conecta conteúdo recebido a ações na rede. Ele decide se executa scripts, como aplica política de mesma origem, se permite conteúdo misto, como valida certificados e até onde uma página pode produzir atividade em segundo plano.

Distinguir uso legítimo de abuso é difícil. Aplicações web modernas fazem diversas chamadas assíncronas, atualizam dados e utilizam recursos distribuídos. Um limite excessivamente rígido pode quebrar serviços normais; um limite frouxo pode permitir que código transformado no caminho consuma a conexão do usuário e pressione um alvo remoto.

Controles úteis incluem bloqueio consistente de conteúdo executável inseguro em contextos protegidos, transporte autenticado por padrão, contenção de atividade repetitiva, visibilidade de padrões inesperados entre origens e mecanismos de diagnóstico que preservem evidência sem expor dados irrelevantes.

A responsabilidade do navegador, contudo, tem fronteiras. Ele não consegue impedir que uma rede descarte comunicações, nem garantir a honestidade de toda origem autenticada, nem absorver o tráfego destinado ao GitHub. Seu papel é reduzir a facilidade com que conteúdo adulterado converte silenciosamente um usuário em fonte de chamadas.

Uma análise operacional deveria registrar quais versões e políticas aceitaram o conteúdo, quais bloquearam a execução e como o comportamento mudou ao longo do tempo. Proteções introduzidas depois não podem ser projetadas retroativamente sobre o ambiente de março de 2015.

Mitigação de DDoS sem equivalências falsas

A orientação do IETF sobre negação de serviço trata de exaustão de recursos, amplificação, desenho de protocolos e defesa operacional. [11] Esse contexto explica a necessidade de limites, capacidade, filtragem e coordenação, mas não prova qual foi a implementação específica do Great Cannon.

Solicitações geradas por navegadores se parecem mais com tráfego normal de aplicação do que com reflexão falsificada. A mitigação precisa, portanto, combinar camadas. A borda pode distribuir ou absorver carga. O transporte pode limitar pressão de conexões. A aplicação pode identificar caminhos caros e padrões repetitivos. Caches podem reduzir trabalho interno. Operadores podem colaborar com provedores de trânsito e serviços de limpeza.

Cada medida cria efeitos colaterais. Filtragem agressiva bloqueia usuários legítimos. Limitação por endereço pune redes compartilhadas. Desafios podem prejudicar acessibilidade e privacidade. Deslocar tráfego pode sobrecarregar outra região. Remover conteúdo pode transformar coerção em política editorial. Uma resposta verificável registra essas escolhas e seus resultados, em vez de simplesmente declarar sucesso.

Fornecedores de mitigação também acumulam poder e evidência. Podem observar o tráfego antes e depois da filtragem, alterar anúncios, classificar solicitações e operar capacidade limpa. Contratos deveriam assegurar ao cliente acesso aos registros relevantes, integridade de horários, condições de retenção e suporte à análise posterior. Terceirizar a mitigação não terceiriza a responsabilidade.

Testes realistas importam. Exercícios de mesa confirmam contatos e autoridade decisória, mas não provam que filtros, rotas, caches e aplicações se comportarão corretamente sob pressão. Exercícios controlados devem medir tempo de classificação, margem de capacidade, falsos positivos, saturação e condições de reversão.

Separar atribuição de contenção

Uma organização precisa conter efeitos antes que a atribuição esteja madura. O GitHub tinha de responder ao tráfego independentemente da identidade final do operador. Pesquisadores puderam estudar posteriormente localização, comportamento e semelhanças técnicas. As duas linhas do tempo se relacionam, mas não devem ser fundidas.

Decisões de mitigação devem se apoiar em propriedades observáveis: destinos, padrões de conexão, frequência, distribuição de origem, custo de resposta e saúde do serviço. Não deveriam depender exclusivamente de uma conclusão geopolítica ainda contestável. Da mesma forma, o êxito de um filtro não prova quem patrocinou a atividade.

A atribuição pode combinar infraestrutura, características de código, posição de implantação, seleção de alvos, horários e contexto histórico. Cada dimensão admite alternativas. Uma avaliação forte explica por que o conjunto favorece determinada hipótese e quais novas evidências poderiam alterá-la.

A contribuição do Citizen Lab está justamente em descrever mecanismo e medição, não apenas um rótulo político. [2][3] Trabalhos acadêmicos e apresentações técnicas ampliaram o escrutínio. [4][5][6] Ainda assim, esse corpo de pesquisa não deve ser reescrito como decisão judicial.

A atribuição da GreatFire expressa a posição de uma organização afetada. [7][8] A interpretação do GitHub expressa a leitura da plataforma sobre a pressão sofrida. [1] A negativa do Baidu trata de seus próprios produtos. Preservar essas vozes separadamente evita fabricar um consenso maior do que o registro permite.

Um conjunto mínimo de evidências para resposta responsável

Um incidente comparável deveria produzir um conjunto interligado de evidências capaz de sustentar análise independente e afirmações públicas delimitadas.

1. Identidade e tempo do evento

É preciso manter um identificador estável, horários em UTC, fontes de relógio, desvios conhecidos e atrasos de coleta. Primeira observação, confirmação, mudança de controle, estabilização e encerramento são momentos distintos.

2. Identidade do recurso e do transporte

Devem ser registrados esquema, nome solicitado, resultado de resolução, origem esperada, propriedades de autenticação, cabeçalhos, hash do conteúdo e decisão tomada pelo navegador. Quando possível e legítimo, preservam-se amostras autênticas e adulteradas.

3. Contexto de múltiplas redes

Cada observação precisa identificar rede, região aproximada, contexto de rota, comportamento do resolvedor e tempo de resposta. Dados públicos de BGP e instantâneos mantidos por operadores auxiliam a reconstrução sem, sozinhos, determinar o local da inserção.

4. Evidência de execução no navegador

É necessário documentar o comportamento do script, os destinos chamados, a repetição, a versão do navegador, as políticas de segurança aplicadas e a necessidade — ou ausência — de ação do usuário. Execução temporária não deve ser descrita como comprometimento persistente sem prova.

5. Evidência do serviço atacado

O alvo deve preservar distribuição de solicitações, caminhos atingidos, estado da borda e da aplicação, mudanças de filtragem, transferências ao fornecedor de mitigação, erros, latência e efeitos colaterais.

6. Evidência de controle do operador

Sistemas capazes de inspeção ou alteração devem possuir autorização documentada, configuração versionada, registros de acesso, identificadores de implantação e trilhas de integridade. Uma negativa ampla não substitui evidência sobre o limite real de controle.

7. Avaliação de atribuição

Fatos observados, inferências, confiança e hipóteses alternativas precisam aparecer separadamente. Alegações externas devem ser atribuídas a quem as fez. O que permanece desconhecido deve continuar explícito.

8. Retenção e divulgação

A política deve equilibrar verificabilidade, privacidade e segurança. Dados pessoais podem ser reduzidos sem destruir a sequência técnica. Novas evidências devem gerar correções claras, não uma reescrita silenciosa da história.

Esse conjunto transforma responsabilização em reprodutibilidade. Permite testar se o que uma organização afirma corresponde ao que controlava e ao que a rede entregou.

Incentivos econômicos e continuidade

Os custos e os controles estão distribuídos de forma desigual. Um publicador de recurso externo pode manter uma opção legada em HTTP enquanto usuários e alvos assumem o risco de alteração. Um operador de trânsito pode não perceber retorno comercial em reter dados detalhados. Uma plataforma pode pagar para absorver solicitações geradas por navegadores que não administra.

Contratos podem reduzir parte dessa assimetria. Acordos de hospedagem e mitigação podem garantir acesso a dados do evento, histórico de mudanças de rota, retenção, apoio a testes e cooperação na divulgação. A aquisição de recursos externos pode exigir transporte autenticado e inventário. Ainda assim, uma cláusula contratual registra obrigação; não prova que o controle funcionou. A prova vem da camada em execução.

Classificações amplas também distorcem incentivos. Chamar toda ofensiva de “botnet” simplifica formulários, mas pode esconder o mecanismo que recrutou navegadores sem comprometimento convencional. Métricas agregadas devem preservar a propriedade técnica essencial, ou deixam de orientar o controle correto.

A continuidade do GitHub acrescenta outra dimensão. Se o custo de indisponibilidade puder obrigar uma plataforma a remover conteúdo, a capacidade de rede passa a influenciar decisões de hospedagem. Isso não torna qualquer política de conteúdo incontestável. Apenas impede que a escolha de hospedar material seja descrita como causa técnica da injeção praticada no caminho.

Recorrências posteriores são eventos separados

Análises posteriores discutiram novas utilizações de ferramentas denominadas Great Cannon. [10][18] Esse histórico reforça a utilidade de detecção duradoura, transporte autenticado e intercâmbio de evidências entre operadores. Não demonstra que todos os episódios compartilharam infraestrutura, alvos, operadores ou comando.

O evento de março de 2015 possui sua própria identidade: datas, vítimas, recursos, medições e declarações. Ocorrências posteriores podem mostrar que uma técnica permaneceu relevante ou ajudar a formular hipóteses, mas não devem ser fundidas retroativamente com o ataque ao GitHub.

Manter essa separação evita que um nome conhecido substitua diferenças observáveis. Narrativas históricas tendem a ficar mais simples com o tempo; a responsabilização exige o movimento contrário — preservar incerteza, versão das conclusões e fronteiras entre eventos.

Um padrão de responsabilidade para injeção no caminho

O caso permite formular um padrão prático para redes, plataformas e dependências web.

Primeiro, recursos executáveis devem usar transporte autenticado. Dependências externas precisam ser inventariadas, e caminhos mistos ou não autenticados devem ser removidos sempre que possível.

Segundo, a entrega deve ser medida a partir de mais de uma rede. Registros de origem não revelam necessariamente o que todos os clientes receberam.

Terceiro, o controle deve ser mapeado por camada: publicação do recurso, DNS, roteamento, peering, trânsito, execução no navegador, borda do alvo e mitigação. A marca mais visível não controla automaticamente toda a cadeia.

Quarto, ações operacionais precisam estar ligadas a evidência. Uma mudança de filtro ou rota deve ter responsável, horário, motivo, efeito esperado, resultado observado e condição de reversão.

Quinto, a confiança da atribuição deve continuar explícita. Localização técnica e semelhança de código podem sustentar uma avaliação provável sem provar uma cadeia individual de ordens.

Sexto, usuários recrutados pelo navegador devem ser tratados como fontes involuntárias, não como agressores conscientes. Medidas defensivas precisam reduzir danos colaterais e respeitar privacidade.

Sétimo, a continuidade deve ser testada sem entregar decisões de conteúdo à coerção por indisponibilidade. A plataforma deve saber como manter serviço e integridade quando solicitações comuns são transformadas em pressão.

Oitavo, registros administrativos precisam ser conciliados com execução observada. DNS, certificados, anúncios e contratos definem expectativas; o tráfego efetivamente entregue demonstra se essas expectativas se sustentaram.

Conclusão

O DDoS contra o GitHub em 2015 foi um teste de responsabilização da rede porque o ponto de controle relevante estava entre o recurso pretendido e o código que o navegador executou. A ofensiva utilizou clientes comuns, endereços reais e caminhos compartilhados. Com isso, expôs os limites de tratar nomes de serviço, registros administrativos ou origens de conexão como descrições completas do comportamento da infraestrutura.

A conclusão sustentada pelo registro público é cuidadosa. O GitHub enfrentou uma grande ofensiva de disponibilidade direcionada a conteúdo. A GreatFire relatou uma sequência anterior e atribuiu a atividade às autoridades chinesas. Pesquisadores mediram um sistema capaz de injetar seletivamente respostas HTTP e avaliaram um provável operador. O Baidu negou que seus produtos tivessem sido comprometidos. Volume completo, prejuízo financeiro, número de usuários, instante exato de recuperação e cadeia individual de comando permanecem desconhecidos.

A responsabilidade acompanha o controle real. Operadores no caminho devem preservar evidência verificável sobre sistemas capazes de alterar tráfego. Publicadores e sites incorporadores devem administrar dependências executáveis e autenticação. Navegadores devem reduzir o recrutamento silencioso. GitHub e seus parceiros de mitigação devem relacionar ações de borda a resultados observados. Pesquisadores e autoridades devem manter observação, inferência e atribuição em categorias distintas.

O princípio duradouro é exigente, mas direto: a rede deve ser avaliada pelo conteúdo, pelos caminhos e pelo comportamento de serviço que efetivamente produziu. Registros indicam a autoridade pretendida. A execução demonstra se essa autoridade prevaleceu. Quando o incidente nasce da distância entre as duas coisas, responsabilizar começa por tornar essa distância visível.

O DDoS do Great Cannon contra o GitHub em 2015 transformou a injeção de código no caminho em um teste de responsabilização da rede