Como o DDoS contra a Spamhaus em 2013 transformou a recursão DNS

Resumo

Entre 18 e 27 de março de 2013, a Cloudflare observou uma campanha que primeiro saturou a conexão da Spamhaus e depois alcançou infraestrutura de provedores e interconexão, sem demonstrar uma indisponibilidade global da Internet. [1][2]
As taxas de aproximadamente 10, 75–90, 120 e 300 Gbit/s pertencem aos pontos de observação descritos pela Cloudflare; não constituem uma medição universal do tráfego da Internet. [1][2]
O caminho executável combinou endereço de origem falsificado, resolvedor recursivo aberto, resposta amplificada e enlaces compartilhados até a vítima ou a infraestrutura de mitigação. [4][10]
DNS recursivo e DNS autoritativo exercem funções diferentes: restringir recursão indevida não significa retirar da Internet os servidores que publicam dados autoritativos. [4][10]
O RFC 5358 e os BCP 38 e 84 já documentavam, antes do incidente, controles distintos para restringir recursão e validar endereços de origem nas bordas de acesso e de redes multihomed. [4][5][6]
A interrupção do site e de redes de apoio não demonstra que os dados distribuídos das listas de bloqueio da Spamhaus tenham deixado de estar disponíveis em escala global. [3]
Anycast, BGP, peering e trânsito distribuíram ou deslocaram a pressão, mas não autorizam atribuir uma falha a uma bolsa de tráfego, um sistema autônomo ou um operador sem evidência específica do caminho. [2][16][18]
O teste de responsabilidade é operacional: identificar o controle efetivo, registrar a observação, corrigir recursão ou falsificação, documentar mudanças de rota e capacidade e verificar externamente se o reparo permaneceu válido.

Um incidente de infraestrutura, não uma lenda sobre a Internet

O episódio envolvendo a Spamhaus em março de 2013 costuma ser resumido por um número enorme e por uma frase dramática sobre a Internet ter estado perto de quebrar. Essa síntese perde justamente o aspecto mais instrutivo do caso.

O incidente foi possível porque vários componentes, administrados por organizações diferentes, formaram um caminho executável: alguém enviou consultas DNS por UDP com o endereço de origem falsificado; resolvedores recursivos acessíveis a clientes arbitrários aceitaram essas consultas; as respostas, maiores que os pedidos, foram remetidas ao endereço falsificado; e redes de trânsito, peering e mitigação carregaram o volume agregado até os pontos em que havia capacidade limitada.

A campanha deve ser delimitada ao período de 18 a 27 de março de 2013 e às superfícies descritas nos registros disponíveis: primeiro a conexão e o site da Spamhaus, depois partes da infraestrutura de provedores e interconexão usadas no esforço de mitigação. Os relatos contemporâneos da Cloudflare sustentam essa sequência e as taxas observadas em sua própria visibilidade [1][2]. Eles não transformam a empresa em um observador onisciente da Internet, nem provam que todos os enlaces, regiões ou serviços enfrentaram a mesma carga.

Essa distinção é essencial para a responsabilidade de rede. Uma taxa medida na interface de um cliente não equivale à taxa recebida por todos os pontos de uma rede anycast. Um pico registrado perto de uma infraestrutura de mitigação não equivale ao volume total que atravessou a Internet pública. Uma conexão saturada não prova que todos os serviços dependentes da organização ficaram indisponíveis. E a passagem de tráfego por um ambiente de interconexão não demonstra, por si só, a falha de toda uma bolsa de tráfego.

O caso interessa porque mostra a primazia do sistema em funcionamento. A avaliação não depende de concordar ou discordar da atuação da Spamhaus no combate ao abuso. Depende de perguntar quem tinha capacidade prática para alterar cada condição técnica, quais registros poderiam provar o estado dessa condição e se a correção reduziu o risco sem apenas deslocá-lo. A responsabilidade começa no pacote, na configuração e no enlace efetivamente observados, não no prestígio institucional nem na força de uma narrativa pública.

O registro delimitado de 18 a 27 de março

Segundo o primeiro relato da Cloudflare, a Spamhaus procurou mitigação depois que um ataque de negação de serviço saturou sua conexão e tornou o site inacessível. A empresa descreveu uma taxa inicial em torno de 10 Gbit/s e, posteriormente, ondas na faixa de 75 a 90 Gbit/s, em grande parte associadas à reflexão por resolvedores DNS recursivos abertos [1]. O relato seguinte descreveu uma escalada para aproximadamente 120 Gbit/s e uma mudança da pressão: em vez de permanecer limitada ao endereço original do cliente, parte do tráfego passou a alcançar provedores e enlaces voltados à interconexão [2].

O número de 300 Gbit/s, repetido muitas vezes desde então, pertence à narrativa da Cloudflare sobre essa fase observada do lado do provedor [2]. Ele deve ser apresentado dessa forma. O registro não oferece uma série uniforme, medida simultaneamente em todos os pontos relevantes, que permita tratar 300 Gbit/s como o pico universal da Internet. As taxas de 10, 75–90, 120 e 300 Gbit/s correspondem a momentos, superfícies e perspectivas diferentes dentro da descrição da Cloudflare.

Essa separação evita uma cronologia artificial. Não há base para combinar todos os números como se fossem estágios de um único medidor instalado em um ponto invariável. A interface voltada ao cliente, a borda de uma rede de mitigação, um enlace de trânsito e uma conexão de peering observam partes diferentes do fluxo. Também podem usar métodos distintos de amostragem, agregação e contabilização. Uma medição pode representar tráfego recebido; outra, tráfego encaminhado, filtrado ou visto antes de uma mudança de rota. Sem conhecer o ponto, o intervalo e o método, a taxa não explica sozinha o domínio de falha.

A Cloudflare informou ainda que observou mais de 30 mil resolvedores participantes e uma relação de amplificação próxima de cem para o formato de consulta e resposta empregado na campanha [1][2]. Esses valores ajudam a demonstrar o mecanismo de agregação. Não são um censo de todos os resolvedores existentes, de todos os pacotes ou de todos os sistemas autônomos de origem. Tampouco revelam o que cada operador sabia naquele momento.

A expressão segundo a qual o ataque “quase quebrou a Internet” deve permanecer no campo do enquadramento publicitário, inclusive por ter aparecido no título de um relato da própria Cloudflare [2]. O material disponível não comprova uma interrupção global, uma falha universal de roteamento ou a indisponibilidade generalizada da Internet. A dimensão observada foi relevante; a conclusão precisa continuar proporcional ao alcance da evidência.

O que foi medido — e a partir de onde

Um número de tráfego só se torna evidência útil quando vem acompanhado de observador, localização lógica, janela temporal e método de cálculo. No caso da Spamhaus, a Cloudflare é a fonte atribuída para as taxas divulgadas e para a contagem superior a 30 mil resolvedores [1][2]. Isso sustenta a afirmação de que a empresa observou uma campanha volumétrica expressiva em seus ambientes. Não sustenta a generalização de que toda a Internet registrou o mesmo pico ou enfrentou o mesmo risco de indisponibilidade.

A diferença de perspectiva também afeta a interpretação de um ataque anycast. Em uma arquitetura distribuída, o mesmo endereço pode ser anunciado a partir de diversos locais. A seleção de rotas conduz partes do tráfego a pontos distintos. Um valor agregado pelo provedor pode reunir observações de vários locais, enquanto a falha percebida por um usuário pode resultar da saturação de um único enlace. Sem telemetria por site, interface e rota, um pico global da plataforma não identifica qual recurso se tornou limitante.

Medições úteis deveriam separar tráfego oferecido, recebido, descartado, filtrado e entregue ao serviço protegido. Deveriam registrar alterações de anúncio BGP, deslocamentos entre trânsito e peering, decisões de limpeza e diferenças de capacidade entre pontos de presença. Também deveriam explicar a deduplicação de amostras. Um mesmo episódio visto em camadas diferentes não pode ser somado indiscriminadamente como se representasse tráfego adicional.

A atribuição aos resolvedores exige cuidado semelhante. Um pacote de resposta mostra que algum serviço DNS enviou dados ao endereço falsificado. Ele não identifica automaticamente o host que originou a consulta fraudulenta. O endereço visível ao resolvedor é, por definição, o endereço forjado da vítima. Para localizar a origem real, seriam necessários registros e observações nos pontos pelos quais a consulta entrou, especialmente nas bordas em que uma rede conhecia os prefixos válidos de seu cliente.

A literatura de medição e os materiais operacionais posteriores ajudam a formular perguntas melhores sobre exposição, amplificação e defesa [16][17][18][19]. Eles não preenchem retroativamente lacunas do registro de março de 2013. A distribuição completa por sistema autônomo, a carga sofrida por terceiros não observados, o conhecimento interno de cada operador e a parcela causal de cada caminho continuam sem resposta conclusiva. Reconhecer esses limites não reduz o episódio; impede que uma estimativa de provedor seja transformada em uma alegação sobre toda a rede mundial.

O caminho executável da reflexão DNS

O caminho técnico começou com uma informação falsa no cabeçalho IP. Uma consulta DNS pequena foi enviada por UDP, mas o campo de origem carregava o endereço da Spamhaus ou, nas fases posteriores, um endereço pertencente à infraestrutura que recebia o tráfego mitigado. Como o UDP não estabelece uma conexão antes da resposta, o servidor consultado não precisava concluir uma negociação de sessão com o remetente real. Ele respondia ao endereço apresentado no pacote.

O intermediário decisivo era um resolvedor recursivo aberto. Esse serviço aceitava uma pergunta de um cliente externo não autorizado, realizava ou reutilizava a resolução necessária e enviava a resposta ao suposto solicitante. A Cloudflare descreveu consultas relacionadas a dados de ripe.net, mais de 30 mil resolvedores participantes e uma amplificação próxima de cem no formato observado [1][2]. O atacante fornecia o estímulo pequeno; os resolvedores produziam e transmitiam as respostas maiores.

A amplificação não precisa ser idêntica em todos os pacotes para que o mecanismo funcione. Ela depende do tamanho da consulta, do tipo e do conteúdo da resposta, da existência de dados em cache, das extensões negociadas, de limites do servidor e de eventual fragmentação. O EDNS(0), documentado no RFC 6891, ampliou a capacidade de transportar mensagens DNS maiores sobre UDP e é relevante para compreender como o tamanho das respostas pode afetar a superfície de amplificação [11]. Isso não torna o EDNS(0) a causa isolada da campanha.

A condição central continuava sendo a combinação entre origem falsificável e serviço recursivo acessível a clientes arbitrários.

Dispositivos de tradução de endereços também influenciam o comportamento do UDP e a duração dos mapeamentos, tema tratado no RFC 4787 [12]. Ainda assim, não se pode deduzir do uso de UDP que uma rede específica, um equipamento específico ou uma política específica de NAT tenha participado do ataque. O ponto relevante é que a ausência de uma confirmação de origem antes da resposta permite que o destino seja falsificado quando a rede de origem não valida o endereço usado.

Depois de deixar o resolvedor, a resposta seguia a rota selecionada até a vítima, um ponto anycast ou um enlace usado pelo provedor de mitigação. O congestionamento podia ocorrer antes de o pacote alcançar qualquer aplicação. Por isso, aumentar a capacidade do servidor web não resolveria uma saturação no trânsito ou no peering. O caminho executável atravessava controles independentes e, ao fazê-lo, distribuía a responsabilidade: o operador do resolvedor controlava a recursão; a rede próxima da origem controlava a validação do endereço; provedores intermediários controlavam rotas, capacidade e resposta operacional.

Recursão e autoridade não são a mesma função

A precisão sobre os papéis do DNS é indispensável. Um servidor autoritativo publica respostas referentes às zonas pelas quais é responsável. Um resolvedor recursivo recebe a pergunta de um cliente, percorre a hierarquia do DNS quando necessário, usa dados em cache e devolve o resultado ao cliente. Esses papéis são descritos na arquitetura fundamental do DNS [10]. Uma mesma máquina pode executar os dois, mas isso não elimina a separação funcional.

A campanha explorou recursão disponível para solicitantes externos arbitrários. Não basta dizer que “servidores DNS” participaram, porque essa formulação atribui a mesma condição a serviços com funções e políticas distintas. Um servidor autoritativo precisa permanecer acessível para que os dados de sua zona possam ser consultados. Um resolvedor destinado a uma empresa, residência, universidade ou provedor normalmente deve limitar a recursão à população autorizada. Fechar a recursão indevida não significa retirar a autoridade pública do ar.

O RFC 5358, publicado em 2008, já descrevia ataques de reflexão e amplificação baseados em servidores recursivos e recomendava restringir o serviço aos clientes pretendidos [4]. Portanto, a necessidade de uma fronteira de acesso para a recursão não foi inventada depois do ataque à Spamhaus. O documento também separava esse controle da filtragem de pacotes com endereços de origem falsificados. Um reduz a população de refletores; o outro impede que a consulta fraudulenta saia da rede de origem.

O operador do resolvedor escolhe software, interfaces de escuta, listas de controle de acesso, intervalos autorizados, política de cache e comportamento de resposta. Quando recursão e autoridade estão no mesmo host, o operador precisa demonstrar como as funções são separadas e quais interfaces ou clientes podem usar cada uma. A simples existência de uma configuração combinada não transfere a responsabilidade para outra parte.

Mecanismos posteriores podem reforçar a defesa. DNS Cookies podem dificultar certas trocas baseadas em origem falsificada quando há suporte compatível [7]. Respostas mínimas a consultas do tipo ANY podem reduzir um formato atraente de amplificação [8]. Limites de taxa podem conter emissões abusivas. Nenhum deles substitui a decisão básica de não fornecer recursão irrestrita a qualquer endereço da Internet.

A prova de correção deve ser externa e repetível. Não basta exibir uma linha de configuração. É necessário inventariar todas as instâncias, testar interfaces IPv4 e IPv6, verificar UDP e TCP, confirmar o comportamento após reinicialização e failover e demonstrar que uma origem não autorizada deixou de obter respostas recursivas. A responsabilidade está no serviço que realmente responde, não apenas na intenção descrita pelo operador.

Falsificação de origem e responsabilidade na borda

A outra metade do caminho era a possibilidade de enviar consultas com um endereço de origem que não pertencia ao emissor. O BCP 38, publicado como RFC 2827, atribui um controle prático à rede próxima da origem: descartar, na borda de cliente ou de acesso, tráfego cujo endereço declarado não seja legitimamente alcançável pela interface correspondente [5]. Sob a perspectiva do provedor, isso é filtragem de ingresso. Para o restante da Internet, o efeito é impedir que pacotes falsificados escapem.

Essa localização importa porque é na borda do cliente que o operador costuma conhecer melhor a relação entre interface e prefixos autorizados. Quanto mais longe o pacote avança, mais difícil pode ser determinar, apenas pela rota corrente, se o endereço de origem é legítimo. Um provedor de trânsito não se torna automaticamente responsável por todo pacote falsificado que atravessa sua malha. Sua obrigação mais demonstrável está nas interfaces em que mantém uma relação conhecida com o cliente e controla a política de aceitação.

Redes multihomed introduzem complexidade. Um pacote legítimo pode sair por um provedor diferente daquele que aparece como melhor caminho de retorno. Uma verificação estrita de caminho reverso pode então produzir bloqueios indevidos. O BCP 84, publicado como RFC 3704, trata dessa situação e descreve opções ajustadas à topologia, como listas por interface e formas de verificação de caminho reverso com propriedades diferentes [6]. Assimetria de rota não é justificativa para abandonar toda validação; é motivo para escolher um método compatível com os caminhos legítimos.

Uma política verificável precisa registrar os prefixos permitidos por cliente, as interfaces cobertas, o método usado, as exceções e o motivo técnico de cada exceção. Testes autorizados com endereços inválidos devem confirmar se os pacotes conseguem sair. Contadores de descarte, alterações de configuração e resultados de reteste ajudam a demonstrar que a proteção permaneceu ativa após mudanças de rota ou de conexão.

A dificuldade persistente de implantar validação de endereços de origem, discutida posteriormente pela iniciativa MANRS, reforça a necessidade de medir cobertura real em vez de aceitar declarações genéricas de conformidade [15]. Dizer “seguimos o BCP 38” não informa quais clientes, famílias de endereço, produtos de acesso ou ambientes multihomed foram testados.

Recursão restrita e validação de origem protegem extremidades diferentes. Um operador de resolvedor não controla a rede distante onde o pacote foi falsificado. Um provedor de acesso não controla a lista de clientes autorizados de um resolvedor remoto. Quando ambas as funções pertencem à mesma organização, as duas obrigações continuam separadas e exigem provas diferentes.

Como pequenas falhas se tornaram uma externalidade

Vista isoladamente, uma recursão aberta pode parecer um erro modesto. Um único resolvedor talvez envie poucos megabits por segundo e não ultrapasse os limites que acionariam um alarme local. Da mesma forma, uma rede de acesso pode deixar passar consultas falsificadas em baixa taxa, dispersas entre muitos clientes. O efeito muda quando milhares dessas decisões locais são reunidas contra o mesmo destino.

A Cloudflare informou ter observado mais de 30 mil resolvedores e uma relação de amplificação próxima de cem para a forma de consulta e resposta usada na campanha [1]. Esses valores não são constantes universais, mas ilustram a assimetria econômica e operacional do ataque. O emissor produz pedidos pequenos; redes e resolvedores distribuídos fornecem a largura de banda das respostas; a vítima e seus provedores recebem o agregado.

Essa estrutura é uma externalidade de rede. O operador que deixa a recursão exposta pode economizar o trabalho de inventariar e corrigir o serviço. A rede que não valida endereços pode evitar o custo de manter políticas por cliente. Entretanto, o custo do tráfego resultante aparece em outro lugar: no serviço atacado, na plataforma de mitigação, em um enlace de trânsito, em uma porta de peering ou em uma infraestrutura de apoio sem relação direta com a disputa.

A responsabilidade não pode depender apenas da indispensabilidade de cada participante. Nenhum resolvedor isolado precisava ser decisivo. Nenhuma rede de origem precisava emitir um fluxo enorme. O fator relevante é se o operador controlava uma condição que, repetida em escala, tornava o ataque executável. Corrigir um resolvedor altera pouco uma campanha em andamento; manter todos os resolvedores de uma rede fechados reduz a população de refletores. Bloquear um pacote falsificado parece insignificante; validar as origens em todas as bordas elimina um pré-requisito em escala.

Também não se deve confundir participação técnica com intenção ou conhecimento. Uma resposta refletida mostra que um serviço respondeu. Não demonstra que seu operador conhecia a campanha, aprovava o ataque ou pretendia atingir a Spamhaus. Da mesma forma, a passagem de um pacote por um provedor não estabelece culpa legal. O registro permite avaliar controle e exposição; não autoriza inventar estado mental, identidade do atacante ou responsabilidade jurídica.

A saída prática é relacionar cada externalidade a uma ação verificável: limitar recursão, testar falsificação, reduzir respostas abusivas, registrar notificações, coordenar rotas e repetir a medição depois do reparo. A responsabilidade de rede torna-se concreta quando a organização consegue demonstrar que a capacidade involuntariamente oferecida ao ataque deixou de existir.

Anycast, BGP, peering e trânsito

A entrada da Cloudflare na mitigação alterou o domínio de falha. A Spamhaus já não dependia apenas de uma conexão voltada diretamente ao seu site; o tráfego passava a ser recebido por uma plataforma distribuída. Com anycast, o mesmo endereço de serviço pode ser anunciado em diferentes locais, e o BGP conduz os pacotes conforme as rotas selecionadas pelos sistemas autônomos. Isso permite repartir carga, mas não cria capacidade infinita.

A eficiência do anycast depende da distribuição geográfica dos pontos, do alcance dos anúncios, da preferência de rotas, da capacidade de filtragem e dos enlaces de peering e trânsito disponíveis em cada local. Uma plataforma pode ter grande capacidade agregada e ainda encontrar um ponto estreito em um provedor, uma porta ou um caminho específico. Uma mudança de anúncio pode aliviar um local e transferir pressão para outro. O resultado precisa ser avaliado por site e por interface.

A Cloudflare descreveu a progressão para cerca de 120 Gbit/s e, em sua narrativa posterior, um pico de aproximadamente 300 Gbit/s enquanto a pressão alcançava provedores e superfícies de interconexão [2]. Esses números indicam o que o provedor disse observar. Eles não demonstram que uma bolsa de tráfego específica ficou indisponível, que todo membro de um ponto de troca sofreu o mesmo volume ou que a Internet global esteve perto de uma falha total.

A expressão “voltado à interconexão” precisa permanecer deliberadamente ampla quando faltam dados. Um pacote pode chegar a um ponto de presença por trânsito, peering privado, porta compartilhada em uma bolsa, ou uma combinação de caminhos alterada pelo BGP. A saturação de um enlace conectado a uma bolsa não prova que a malha inteira da bolsa falhou. Atribuir uma interrupção exigiria contadores de porta, registros do fabric, anúncios e retiradas de rota, alarmes de congestionamento e uma janela temporal correlacionada.

Peers, provedores de trânsito e operadores de interconexão controlavam suas interfaces, políticas, capacidade e resposta coordenada. A Cloudflare controlava seus anúncios, decisões de limpeza, distribuição anycast e precisão das medições publicadas. Esses controles não tornam qualquer parte automaticamente responsável pelo volume criado em resolvedores remotos. Eles definem, porém, o tipo de evidência que cada parte deveria preservar.

Um relato operacional confiável mostraria quais locais anunciavam o serviço, por onde o tráfego entrou, quais rotas mudaram, onde a utilização cresceu, quais contatos ocorreram e qual alteração reduziu a pressão. Materiais posteriores de RIPE e DNS-OARC ajudam a estruturar essa observação [16][17]. O princípio permanece simples: o BGP seleciona caminhos reais, e a responsabilidade sobre esses caminhos deve ser demonstrada com registros reais, não presumida a partir de um diagrama institucional.

Site, redes de apoio e dados distribuídos

A indisponibilidade inicial descrita pela Cloudflare foi específica: a conexão da Spamhaus foi saturada e seu site deixou de ser alcançável [1]. As fases posteriores alcançaram infraestrutura usada por provedores e outros serviços de apoio [2]. A Spamhaus afirmou posteriormente que seus dados distribuídos de combate a spam permaneceram disponíveis enquanto seu site, hosts, parceiros de DNS e serviços de suporte eram atacados [3].

Essas afirmações não são contraditórias porque “o serviço da Spamhaus” não era uma unidade indivisível. O site público oferecia páginas, contato, explicações e comunicação operacional. As listas de bloqueio baseadas em DNS dependiam de outros endpoints, réplicas, rotas e mecanismos de consulta. A perda da presença web podia prejudicar suporte e informação pública sem eliminar todos os caminhos pelos quais sistemas de correio consultavam os dados distribuídos.

A continuidade dos dados também não prova que todos os usuários, regiões e redes tiveram acesso perfeito. Um serviço distribuído pode permanecer amplamente disponível enquanto determinados caminhos enfrentam latência, perda ou falha. O registro sustenta a conclusão mais estreita de que a interrupção do site não demonstrou uma paralisação global das listas. Ele não permite afirmar que nenhum usuário sofreu degradação.

Uma avaliação de disponibilidade deveria separar alcance HTTP, saúde do DNS autoritativo, sucesso das consultas às listas, atualização dos dados, latência e taxa de erro. Os testes precisariam indicar origem, destino, horário e rota aproximada. Uma única luz verde em um painel não pode representar simultaneamente o site, os nameservers, parceiros de hospedagem e a distribuição dos dados.

O RFC 8767, publicado anos depois, descreve o uso de respostas expiradas em determinadas condições para aumentar a resiliência de resolução [13]. Ele oferece uma referência posterior para pensar sobre continuidade, mas não prova que esse mecanismo estava disponível ou implantado de forma idêntica durante o incidente de 2013. O mesmo cuidado vale para orientações posteriores sobre grandes serviços autoritativos [9].

A Spamhaus controlava a arquitetura de seus serviços, dependências, recuperação e precisão das comunicações públicas. A Cloudflare controlava a mitigação nos endereços e rotas que aceitava. Nenhuma das duas controlava os resolvedores remotos nem as redes que admitiam consultas falsificadas. Preservar essas fronteiras impede tanto a minimização do dano ao site e às redes de apoio quanto a inflação do episódio para uma interrupção global de filtragem de e-mail.

Responsabilidade por capacidade de controle

A distribuição da responsabilidade deve acompanhar aquilo que cada participante podia configurar, observar e reparar. O operador de um resolvedor decidia quem podia usar a recursão, em quais interfaces o serviço escutava, como respondia e quais limites aplicava. Sua prova relevante inclui inventário, política de acesso, teste externo, telemetria e confirmação de que a correção resistiu a reinicializações e failover.

A rede de acesso ou hospedagem controlava a validação de origem nas interfaces de clientes. Sua evidência inclui prefixos autorizados, cobertura IPv4 e IPv6, método de filtragem, exceções para multihoming, testes de falsificação e contadores de descarte. Uma política escrita sem denominador de cobertura não demonstra que todos os pontos relevantes estavam protegidos.

Provedores de trânsito controlavam as bordas de clientes sob sua administração, a engenharia de tráfego, a capacidade contratada e a coordenação com outras redes. Não é razoável atribuir a eles todo pacote falsificado que tenha percorrido uma rota plausível, especialmente quando faltam dados sobre a origem. É razoável exigir prova das interfaces em que conheciam a relação entre cliente e prefixo, bem como registros das ações tomadas quando receberam notificações.

Operadores de peering e de bolsas de tráfego controlavam portas, políticas e resposta a congestionamento dentro de seus domínios. Não se pode inventar uma interrupção de bolsa nem atribuir volume a um membro sem dados específicos. A passagem perto de uma infraestrutura de troca não substitui contadores, alarmes e registros de rota.

A Cloudflare controlava a arquitetura anycast, decisões de filtragem, anúncios BGP, coordenação com peers e provedores, capacidade por local e precisão das declarações sobre taxas observadas [1][2]. A empresa podia explicar o que mediu e onde, mas não determinar, apenas por suas amostras, a distribuição completa dos sistemas autônomos de origem.

A Spamhaus controlava desenho de serviço, redundância, dependências e comunicação de recuperação. Não controlava a configuração dos resolvedores usados como refletores nem as políticas de origem das redes que encaminharam as consultas falsificadas. Sua posição como alvo não elimina a necessidade de distinguir os serviços que continuaram operando daqueles que sofreram interrupção.

Nenhuma dessas alocações decide responsabilidade jurídica. O aviso posterior sobre uma prisão oferece contexto, mas não resolve a identidade técnica de todos os participantes nem estabelece a autoria legal de cada ação dentro desta análise [3]. Capacidade operacional, intenção, conhecimento e responsabilidade legal são questões diferentes. O registro disponível sustenta uma avaliação de controles; não uma sentença sobre atores não comprovados.

Evidência para resolvedores e bordas de acesso

Um programa de verificação começa por saber quais serviços existem. O operador deveria manter um inventário datado de todos os listeners recursivos, com endereço, interface, família IP, finalidade, proprietário, software, origem da configuração e faixas de clientes autorizadas. Ambientes adquiridos, redes de laboratório, interfaces secundárias e serviços implantados automaticamente precisam entrar no mesmo universo de teste.

A verificação externa deve partir de redes não autorizadas. O resultado esperado é a recusa de recursão, enquanto testes internos confirmam que os clientes legítimos continuam resolvendo nomes. UDP e TCP devem ser avaliados separadamente; IPv4 e IPv6 também. Um serviço fechado em uma interface, mas aberto em outra, continua oferecendo uma superfície utilizável.

Registros de consultas e fluxos amostrados podem indicar nomes solicitados, tipos de consulta, tamanho das respostas, truncamento e atuação de limites de taxa. A retenção deve ser proporcional e não precisa coletar dados de usuários além do necessário para comprovar o comportamento. O objetivo é responder se o resolvedor estava acessível, o que produziu, quando a exposição foi corrigida e se o reteste externo confirmou o encerramento.

Na borda de acesso, o inventário muda de forma. Para cada cliente, segmento, classe de serviço ou ambiente de hospedagem, deve haver uma relação entre interface e prefixos válidos. A política pode usar ACLs, validação por caminho reverso ou outra técnica compatível com a topologia. O BCP 84 é especialmente importante quando a assimetria torna inadequada uma regra estrita [6]. Exceções precisam de responsável, justificativa, prazo e controle compensatório.

Testes autorizados com origens impossíveis fornecem evidência mais forte do que uma declaração de política. Eles devem ser repetidos após mudanças de roteamento, novos provedores, alterações de multihoming ou migração de equipamentos. Um controle correto ontem pode falhar depois que a relação entre interfaces e caminhos válidos muda.

Notificações de abuso também precisam ser acionáveis. Um aviso por sistema autônomo deveria trazer intervalo de tempo, protocolo, destino, endereço aparente, amostra representativa, método de observação e identificador para acompanhamento. Uma lista de endereços sem contexto pode ajudar na triagem, mas não demonstra qual interface permitiu a consulta nem se o reparo funcionou.

O fechamento só deve ocorrer depois de um novo teste. Uma alteração de configuração registrada, sem observação posterior, prova intenção de reparar, não o resultado. A responsabilidade operacional se completa quando o comportamento externo muda de forma mensurável.

Evidência para mitigação e interconexão

Plataformas de mitigação precisam documentar o ataque de modo compatível com a arquitetura distribuída que operam. A telemetria deve identificar locais anycast, interfaces de entrada, capacidade disponível, volume recebido, volume descartado, tráfego entregue e alterações de rota. Sem essa separação, um único número agregado pode ocultar tanto um gargalo local quanto diferenças relevantes de método.

Registros BGP são parte da evidência. Anúncios, retiradas, comunidades e mudanças de preferência ajudam a explicar por que o tráfego passou a chegar por determinado peer ou provedor. A correlação com utilização de interface e alarmes mostra se uma decisão distribuiu carga ou deslocou o problema. Horários de contatos com upstreams e peers completam a sequência operacional.

Provedores de trânsito deveriam preservar dados suficientes para mostrar as bordas de cliente cobertas por validação, os enlaces que enfrentaram pressão e as ações coordenadas. Um provedor não deve receber automaticamente a parcela causal de todo o fluxo observado em sua rede. A contribuição precisa ser vinculada à interface, política e janela em que tinha controle ou visibilidade.

Operadores de troca devem limitar suas conclusões ao que mediram em portas e no fabric sob sua administração. O fato de uma rota alcançar um participante por uma bolsa não demonstra que a bolsa inteira sofreu indisponibilidade. Uma conclusão forte exigiria registros de capacidade, perda, estado das portas e alcance do problema. O material disponível sobre a campanha não oferece base para inventar uma falha abrangente desse tipo [2][16][18].

A precisão das declarações públicas também é um controle. Taxas devem ser acompanhadas pelo local lógico, intervalo, método e distinção entre tráfego bruto e tráfego entregue. A Cloudflare ofereceu os números que estruturam o registro contemporâneo [1][2]; justamente por isso, eles devem continuar atribuídos à observação da empresa.

Uma avaliação pós-incidente deveria reconstruir detecção, mitigação, mudança de rota, contato externo, pressão de capacidade e recuperação. A pergunta não é apenas se o site voltou. É se a correção preservou a continuidade, evitou deslocar dano desnecessário e deixou evidência suficiente para auditoria independente.

Esse padrão transforma engenharia de tráfego em responsabilidade verificável. Anycast e peering não são rótulos mágicos de resiliência; são mecanismos cujos resultados dependem de rotas, capacidade e coordenação. O reparo passa quando outra observação confirma que o domínio de falha foi reduzido, não quando uma organização apenas declara o incidente encerrado.

Controles anteriores e referências posteriores

A avaliação histórica precisa separar o que já estava documentado em março de 2013 daquilo que foi padronizado ou consolidado depois. O RFC 5358 havia descrito em 2008 o problema de reflexão com resolvedores recursivos públicos e origens falsificadas [4]. O BCP 38 estava publicado desde 2000, e o BCP 84 oferecia orientação para redes multihomed [5][6]. Portanto, restringir recursão e validar origem eram categorias de controle conhecidas antes da campanha.

Isso não prova implantação. Um padrão publicado não demonstra que determinado operador o aplicava, que conhecia uma exposição específica ou que um pacote concreto atravessou uma interface sem proteção. A passagem da recomendação para a responsabilidade exige evidência do sistema efetivamente operado.

Documentos posteriores oferecem comparações valiosas. DNS Cookies acrescentam resistência a certas falsificações quando as partes dão suporte ao mecanismo [7]. Respostas mínimas a ANY reduzem uma forma de resposta historicamente atraente para amplificação [8]. Orientações para grandes serviços autoritativos ajudam a estruturar distribuição, resiliência e continuidade [9]. O uso de dados expirados sob condições controladas pode contribuir para disponibilidade de resolução [13].

O EDNS(0) é relevante para entender tamanhos de mensagem e comportamento sobre UDP [11], enquanto requisitos para NAT em UDP ajudam a analisar como mapeamentos e temporizadores interferem na comunicação [12]. Esses elementos explicam aspectos da operação do DNS e do transporte; não substituem a distinção entre recursão autorizada e recursão aberta, nem provam uma configuração particular na campanha.

Materiais de RIPE, MANRS e DNS-OARC e estudos de medição posteriores fornecem métodos para inventariar exposição, acompanhar amplificação, testar validação e avaliar defesas [14][15][16][17][18][19]. Eles mostram como uma garantia moderna pode ser mais rigorosa. Não devem ser projetados para trás como se todos os mecanismos posteriores estivessem disponíveis, implantados ou operacionalmente idênticos em 2013.

A comparação justa pergunta se os controles já conhecidos foram considerados, quais limitações foram registradas e como a correção foi verificada. Não pergunta se operadores de 2013 anteciparam todos os RFCs futuros. A temporalidade preserva a responsabilidade sem recorrer à certeza retrospectiva.

Um programa de reparo auditável

O reparo deve começar pelo controle mais próximo da condição observada. Se um teste externo encontra recursão aberta, o operador precisa identificar a instância, limitar os clientes, revisar interfaces e repetir o teste. Se uma rede permite origem falsificada, deve localizar a borda, corrigir a política, validar rotas legítimas e executar novo teste. Se um enlace satura, a resposta deve registrar a rota, capacidade, decisão de mitigação e efeito mensurado.

Cada falha precisa de proprietário, prazo e critério de encerramento. A correção não pode ser definida apenas como uma alteração aplicada. O critério deve descrever o comportamento esperado visto de fora: uma rede não autorizada deixa de receber recursão; um pacote com origem impossível deixa de atravessar a borda; uma mudança de anúncio distribui a carga sem criar nova indisponibilidade; o serviço protegido volta a responder a partir de pontos de observação definidos.

Denominadores são importantes. Relatar cem resolvedores corrigidos pouco diz se a organização administra cento e dez ou dez mil. A cobertura deve indicar quantos endereços, interfaces, clientes e famílias de protocolo foram testados, quais exceções permanecem e quais áreas ainda estão fora da visibilidade.

Aquisições, mudanças de topologia, novos provedores e atualizações de software devem acionar retestes. Uma rede estável no papel pode ganhar uma interface esquecida ou um resolvedor implantado com configuração padrão. O controle não é um selo permanente; é uma propriedade do sistema em execução.

Exercícios de failover precisam abranger DNS, anycast, trânsito e comunicação pública. Um serviço pode sobreviver ao tráfego em um local e perder sua dependência de suporte em outro. A arquitetura de continuidade deve distinguir o plano de dados distribuído, o site público, nameservers, canais de contato e provedores auxiliares.

A auditoria também deve preservar incertezas. Quando não houver visibilidade sobre a origem real, o relatório deve dizer isso. Quando uma taxa se limitar a um ponto de observação, ela deve continuar limitada. Quando o efeito sobre terceiros não tiver sido medido, ele não deve ser estimado como fato. Um reparo tecnicamente bom perde credibilidade se vier acompanhado de causalidade exagerada.

A responsabilidade de rede, nesse sentido, não é uma cerimônia de culpa. É a capacidade de ligar um pacote ou comportamento a um controle, ligar o controle a um operador, registrar a correção e demonstrar que o resultado mudou.

Limites do registro público

O mecanismo de reflexão está mais bem sustentado do que a dimensão total da campanha. Os relatos da Cloudflare estabelecem as taxas aproximadas observadas, a participação de mais de 30 mil resolvedores e a amplificação próxima de cem para o padrão descrito [1][2]. Eles não fornecem a distribuição completa dos sistemas autônomos de origem nem uma medição universal.

Também não é possível determinar integralmente o impacto sobre terceiros. Tráfego dirigido à infraestrutura de provedores e caminhos de interconexão poderia impor custos a redes alheias à disputa. Entretanto, não há base suficiente para quantificar toda a congestão de terceiros ou atribuir uma indisponibilidade específica a uma bolsa de tráfego.

O conhecimento dos operadores permanece desconhecido. Um resolvedor aberto pode ter sido produto de configuração antiga, implantação automática ou decisão consciente, mas o pacote observado não revela qual hipótese é correta. Uma rede pode ter tido proteção incompleta sem saber que uma interface estava exposta. Essas possibilidades não devem ser convertidas em fatos.

A identidade técnica e a responsabilidade legal do atacante também não podem ser completadas por inferência. A referência posterior da Spamhaus a uma prisão fornece contexto, não uma adjudicação abrangente de todas as ações, origens e consequências técnicas analisadas aqui [3]. Não se deve nomear um responsável definitivo além do que a evidência jurídica citada sustenta.

A parcela causal de cada operador igualmente não pode ser calculada. O ataque dependia da combinação de falsificação, recursão, amplificação e transporte. A remoção de qualquer condição reduziria o caminho, mas isso não permite atribuir percentuais de culpa sem dados de volume, tempo, cobertura e controle por participante.

Por fim, não há demonstração de que a Internet global tenha ficado perto de uma interrupção. “Quase quebrou a Internet” foi um enquadramento de divulgação, não uma descoberta de indisponibilidade mundial [2]. A conclusão defensável é mais precisa: uma campanha volumétrica explorou controles distribuídos, pressionou serviços e infraestrutura de provedores e revelou como falhas locais podem se combinar em um risco compartilhado.

Manter esses limites faz parte da responsabilidade. O espaço não preenchido por registros deve continuar identificado como desconhecido, em vez de ser ocupado por uma narrativa conveniente.

O teste de responsabilidade de rede

O episódio da Spamhaus transforma responsabilidade em uma sequência de perguntas técnicas. O operador controlava a condição observada? Havia um mecanismo disponível para reduzi-la? Qual registro demonstra o estado anterior? A correção foi aplicada ao componente certo? Uma observação independente confirmou que o comportamento mudou? O serviço permaneceu funcional sem exportar um custo evitável?

Para operadores de resolvedores, o teste consiste em demonstrar que apenas clientes autorizados obtêm recursão, que os papéis recursivo e autoritativo são diferenciados e que respostas abusivas são acompanhadas e limitadas. Para redes de acesso, consiste em provar que endereços impossíveis não saem das bordas cobertas e que a política continua correta em ambientes multihomed.

Para provedores de mitigação, trânsito e peering, o teste exige registros de capacidade, rotas, pontos de entrada, filtragem e coordenação. Para operadores de interconexão, exige limitar afirmações ao fabric e às portas efetivamente observados. Para a Spamhaus, exige distinguir a disponibilidade do site, dos serviços auxiliares e dos dados distribuídos, comunicando a recuperação com precisão.

O teste não depende da posição moral de cada organização. Não é necessário endossar as listas da Spamhaus para reconhecer que recursão aberta e falsificação de origem criaram uma externalidade. Também não é necessário condenar todo operador intermediário para exigir evidência sobre os controles sob sua administração.

A infraestrutura é o centro da conclusão. Se forem removidos recursão exposta, origem falsificável, amplificação, anycast, seleção BGP, peering, trânsito e continuidade de serviço, desaparece a explicação do incidente como falha distribuída. Esses elementos não são cenário; são o próprio objeto da responsabilidade.

O êxito de um reparo não está em prometer conformidade com boas práticas. Está em mostrar a configuração, o escopo testado, a observação externa, a mudança e o resultado persistente. Quando o registro não permite responder, a conclusão correta é “desconhecido”. Quando o operador tinha controle prático, a resposta correta é uma ação auditável.

Conclusão

A campanha de 18 a 27 de março de 2013 não precisa de exagero para ser relevante. A Cloudflare observou taxas aproximadas de 10, 75–90, 120 e 300 Gbit/s em diferentes etapas e superfícies, além de mais de 30 mil resolvedores participantes [1][2]. Esses números mostram escala dentro da visibilidade do provedor; não medem universalmente a Internet.

O aspecto duradouro do episódio é a forma como condições pequenas e distribuídas produziram um grande custo externo. Consultas com endereços falsificados atravessaram redes sem validação suficiente. Resolvedores aceitaram recursão de solicitantes arbitrários. Respostas ampliadas convergiram sobre a vítima e a infraestrutura que a protegia. Anycast e BGP distribuíram o tráfego, enquanto peering, trânsito e capacidade determinaram onde a pressão se tornou crítica.

Cada participante controlava uma parte diferente. O operador do resolvedor podia fechar a recursão. A rede de acesso podia validar a origem. A plataforma de mitigação podia alterar rotas, filtrar tráfego e documentar medições. Provedores e operadores de interconexão podiam agir sobre suas próprias interfaces e coordenar resposta. A Spamhaus podia estruturar redundância e distinguir a disponibilidade de seu site da continuidade dos dados distribuídos.

O registro não permite inventar uma interrupção de bolsa, a distribuição completa por sistema autônomo, todo o impacto sobre terceiros, o conhecimento interno dos operadores, a identidade definitiva de cada ator ou a divisão causal e jurídica do dano. Também não sustenta a frase “quase quebrou a Internet” como resultado técnico global.

A conclusão defensável é operacional: a reflexão DNS aberta tornou a responsabilidade mensurável. Quem controla a recursão deve provar que ela está restrita. Quem controla a borda deve provar que origens falsas não escapam. Quem controla rotas e mitigação deve documentar onde o tráfego entrou e como o domínio de falha mudou. Quem opera o serviço deve distinguir cada camada de disponibilidade. Em todos os casos, a correção só termina quando um novo teste demonstra que o sistema em funcionamento deixou de oferecer a mesma capacidade ao ataque.

Como o DDoS contra a Spamhaus em 2013 transformou a recursão DNS aberta em um teste de responsabilidade de rede