Dyn mostrou que a terceirização de DNS pode se tornar uma falha de modo comum

Resumo

• Confirmado:Em 21 de outubro de 2016, a Dyn relatou ataques DDoS contra sua infraestrutura DNS gerenciada. Sua declaração pública disse que a primeira onda começou por volta das 7h00, horário do leste, afetou usuários direcionados aos servidores Dyn na costa leste dos EUA e foi mitigada cerca de duas horas depois. Uma segunda onda, mais global, começou pouco antes do meio-dia e foi mitigada em pouco mais de uma hora. A Dyn disse que uma terceira tentativa foi mitigada sem impacto ao cliente.
• Observado:A ThousandEyes mediu altas taxas de falha de consulta DNS de seus pontos de observação globais e relatou que cerca de 75% de seus pontos de observação enviaram consultas que não foram respondidas pelos servidores da Dyn no auge do ataque. Também observou aproximadamente 1.200 sites e serviços afetados entre aqueles que seus clientes monitoravam e descobriu que muitos clientes vulneráveis usavam apenas servidores de nome da Dyn, em vez de vários provedores de DNS.
• Atribuição limitada:A Dyn disse que a análise da Flashpoint e da Akamai confirmou que uma fonte do tráfego eram dispositivos infectados pelo Mirai. O DOJ anunciou posteriormente confissões de culpa dos criadores do Mirai e uma confissão de culpa separada de um indivíduo cujo ataque de botnet variante do Mirai em 21 de outubro de 2016 impactou a Dyn e tornou sites como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix e Southern New Hampshire University inacessíveis ou intermitentes por várias horas. O registro público não prova que um ator, uma botnet ou um vetor de ataque explica todo o tráfego que a Dyn viu naquele dia.
• Avaliação:O incidente foi uma falha de dependência de modo comum. A Dyn controlava sua plataforma DNS gerenciada, parceiros de mitigação, comunicações e arquitetura de infraestrutura. Os clientes controlavam se o DNS autoritativo era diversificado entre provedores e se as práticas de TTL, failover e monitoramento correspondiam às suas próprias reivindicações de disponibilidade. Os vendedores de IoT, proprietários, ISPs, reguladores e atacantes controlavam partes separadas do problema da botnet.

O DNS falhou antes do aplicativo web

Um usuário geralmente experimenta o DNS apenas quando ele quebra. O nome do site parece normal. O navegador está funcionando. A conexão do usuário pode estar saudável. O aplicativo de destino ainda pode estar em execução. No entanto, se o caminho DNS autoritativo não puder responder, o serviço pode desaparecer como se os próprios servidores tivessem sumido. Isso é o que tornou o incidente da Dyn tão desorientador. Muitos serviços não estavam necessariamente quebrados em sua própria camada de aplicação. Seus nomes não podiam ser resolvidos de forma confiável o suficiente para que os usuários os alcançassem.

O incidente de outubro de 2016 fica na interseção de duas formas de terceirização. Primeiro, muitas empresas digitais terceirizaram o DNS autoritativo para um provedor gerenciado porque esse provedor poderia oferecer alcance anycast global, direcionamento de tráfego, experiência operacional e preparação para DDoS que muitos clientes não poderiam construir economicamente sozinhos. Segundo, milhões de residências e organizações colocaram dispositivos conectados inseguros na internet pública, geralmente com credenciais padrão fracas ou caminhos de atualização ruins.

O Mirai converteu essa segunda escolha de terceirização em tráfego de ataque contra a primeira.

A própria declaração da Dyn, preservada em uma cópia pública em PDF daDeclaração da Dyn sobre o Ataque DDoS de 21/10/2016, disse que a empresa sofreu ataques DDoS contra sua infraestrutura DNS gerenciada. Descreveu uma primeira onda começando por volta das 7h00, horário do leste, uma restauração cerca de duas horas depois, uma segunda onda mais global pouco antes do meio-dia, restauração por volta das 13h00 e uma terceira tentativa que a Dyn disse ter sido mitigada sem impacto ao cliente. A Dyn também disse que não sofreu uma interrupção em todo o sistema a qualquer momento e que alguns usuários, como aqueles que acessavam sites afetados da costa oeste dos EUA durante a primeira onda, teriam tido sucesso.

Esse detalhe é importante. O incidente não foi uma interrupção binária limpa onde todo cliente da Dyn desapareceu em todos os lugares. Foi uma falha de disponibilidade moldada por geografia, anycast, comportamento do resolvedor, tempo de vida, configuração de domínio do cliente e a intensidade variável do tráfego DDoS. Isso tornou a comunicação difícil. Um cliente poderia testar de uma rede e ver sucesso enquanto usuários em outro lugar viam falha. Um proprietário de plataforma poderia ter servidores de aplicação saudáveis e ainda receber reclamações de que o serviço estava fora do ar.

Um usuário poderia esperar até que uma resposta DNS em cache expirasse e de repente perder o acesso.

A dependência compartilhada era visível nas medições

A análise da ThousandEyes,O Ataque DDoS na Infraestrutura DNS da Dyn, fornece a explicação pública mais clara da dependência do lado do cliente. Seu monitoramento viu três fases: impacto inicial concentrado na costa leste dos EUA, um impacto global mais amplo e, mais tarde, mitigação com ataques persistentes ou blackholing. No auge do ataque, aproximadamente três quartos de seus pontos de observação globais enviaram consultas DNS que não foram respondidas pelos servidores da Dyn. Também relatou aproximadamente 1.200 sites e serviços afetados entre os domínios que seus clientes monitoravam.

O ponto técnico era simples, mas severo. A Dyn operava servidores autoritativos para domínios de clientes. Se um resolvedor já não tivesse uma resposta em cache fresca e não pudesse alcançar os servidores autoritativos da Dyn, não poderia obter o endereço necessário para conectar. Valores de tempo de vida mais curtos podem tornar o gerenciamento de tráfego mais ágil em operações normais, mas também fazem com que os usuários dependam mais frequentemente de resolução autoritativa bem-sucedida. Um TTL baixo não é ruim por si só; é uma troca.

Durante um evento DDoS no provedor de DNS, pode encurtar o tempo entre "o cache ainda sabe para onde ir" e "o resolvedor deve perguntar à autoridade indisponível novamente".

A ThousandEyes também descreveu a popularidade da Dyn para direcionamento de tráfego. O DNS gerenciado não era meramente uma lista telefônica estática. Ajudava grandes serviços a rotear usuários para data centers próximos, deslocar tráfego e otimizar o desempenho. Isso significa que o produto que melhorava a resiliência e a velocidade em condições normais também se tornou uma dependência cuja degradação poderia afetar muitos clientes de uma só vez. Quanto mais forte a proposta de valor do provedor, mais atraente ele se tornava como um plano de controle compartilhado.

A descoberta mais importante da ThousandEyes para responsabilidade foi a arquitetura do cliente. Muitos clientes afetados da Dyn usavam apenas os servidores de nome da Dyn, em vez de diversificar entre vários provedores de DNS. A análise contrastou clientes com um único provedor de DNS gerenciado com a Amazon.com, que usava mais de um provedor e sofreu tempos de carregamento mais lentos, em vez do mesmo padrão de indisponibilidade completa visto por muitos outros. Isso não significa que todo cliente poderia ter ativado DNS multiprovedor da noite para o dia.

Significa que o risco era arquitetural, visível e parcialmente controlado pelos clientes.

Ahistória da AP espelhada pelo Chicago Sun-Timescapturou a experiência pública: efeitos em cascata para usuários tentando acessar sites populares nos Estados Unidos e na Europa, com Twitter, Netflix e a PlayStation Network da Sony entre os serviços aparentemente afetados. Orelatório contemporâneo do Guardianlistou Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News e grandes jornais entre os serviços relatados como offline ou prejudicados. Esses relatórios são úteis para escopo e percepção pública; não são prova de que cada serviço nomeado experimentou o mesmo modo de falha técnica ou a mesma duração.

O modo comum de falha se esconde dentro do DNS "redundante"

O DNS tem redundância incorporada em seu design. Domínios listam vários servidores de nome. Os resolvedores podem tentar alternativas. Servidores autoritativos podem ser geograficamente dispersos. O problema é que a redundância pode ser formal sem ser independente de falha.

RFC 2182diz desde 1997 que uma das principais razões para múltiplos servidores DNS é manter a informação de zona disponível mesmo quando um servidor está inacessível, e que servidores secundários devem ser geográfica e topologicamente dispersos. Ela adverte contra configurações onde todos os servidores compartilham o mesmo modo de falha local. Em linguagem comum: múltiplos servidores de nome não são suficientes se falham juntos.

O caso Dyn traduziu esse princípio de localização física para dependência de provedor. Um cliente poderia listar vários servidores de nome da Dyn e ainda ter um provedor, um relacionamento comercial, um caminho de suporte operacional, um conjunto de credenciais de gerenciamento DNS e uma exposição a um grande ataque contra esse provedor. Da perspectiva do domínio, esses servidores de nome podem parecer diversos. Da perspectiva da responsabilidade, ainda fazem parte de uma dependência comum de provedor.

O artigoA Falta de Redundância na Resolução DNS por Grandes Sites e Serviçosexaminou concentração e diversificação no DNS após o incidente Dyn. Ele encontrou uma concentração crescente entre um pequeno número de provedores de DNS e uma forte tendência para os domínios não usarem múltiplos provedores de gerenciamento de DNS. Em sua amostra, a proporção de domínios usando apenas um provedor era de aproximadamente 91% a 93% antes do ataque, e caiu de 92,2% para 89,4% entre outubro de 2016 e novembro de 2016. Entre os clientes Dyn, a participação de domínios não diversificados caiu bruscamente após o incidente e continuou caindo até maio de 2017.

Esses números devem ser tratados como resultados de pesquisa dentro de um conjunto de dados específico, não como um censo exato de toda a internet. Ainda assim, eles apoiam a lição prática. O DNS tornou possível a diversificação de provedores, mas muitos clientes escolheram a simplicidade operacional em vez da independência de falha. Isso não é irracional.

O DNS autoritativo multiprovedor introduz complexidade: dados de zona consistentes, assinatura DNSSEC e gerenciamento de chaves, comportamento de verificação de integridade, diferenças de direcionamento de tráfego, atrasos de propagação, risco de split-brain, monitoramento e responsabilidade contratual. O custo da diversidade é real. O ataque Dyn mostrou que o custo de não diversificar também pode se tornar real, e pode chegar através de um fornecedor em vez da infraestrutura do próprio cliente.

Anycast é poderoso, mas não é mágica

A infraestrutura da Dyn, como muitas plataformas globais de DNS, usava anycast. Anycast permite que múltiplos locais anunciem o mesmo endereço IP para que o roteamento da internet possa enviar um resolvedor para uma instância próxima ou preferida. Isso melhora a latência e absorve muitas falhas locais porque o tráfego pode se mover pela rede. É uma das razões pelas quais provedores de DNS gerenciado podem oferecer amplo alcance e resposta rápida.

Anycast não torna a capacidade infinita. Pode distribuir tráfego, mas também pode distribuir pressão de ataque. Se o ataque for grande o suficiente, amplo o suficiente ou direcionado de maneiras que congestionem links upstream, peering ou prefixos compartilhados, os locais anycast podem falhar juntos ou flutuar de maneiras complexas. A ThousandEyes observou que muitas consultas não conseguiam passar pelos provedores de serviços de internet da Dyn ou pela borda da rede da Dyn, e que servidores de nome dentro da mesma constelação e grupo mostraram desempenho correlacionado. Essa observação não prova que o design interno da Dyn foi negligente.

Mostra por que "temos múltiplos pontos de presença" não é o mesmo que "temos disponibilidade independente sob todas as condições DDoS plausíveis".

A declaração da Dyn disse que praticava cenários, tinha playbooks, usava parceiros de mitigação e iniciou o gerenciamento de incidentes e comunicações com o cliente. Também disse que os ataques eram altamente distribuídos, envolviam dezenas de milhões de endereços IP discretos associados ao Mirai e usavam múltiplos vetores e locais de internet. Um provedor não deve ser julgado como se a mitigação de DDoS fosse uma questão simples de comprar largura de banda suficiente.

Ataques distribuídos muito grandes criam erros de medição, tempestades de repetição, tráfego colateral, instabilidade de rota e difíceis compensações entre filtrar tráfego de ataque e preservar consultas legítimas.

Ainda assim, os clientes compram DNS gerenciado porque o provedor alega expertise exatamente nesse domínio operacional. A Dyn, portanto, possuía o lado da resiliência do provedor: planejamento de capacidade, coordenação upstream, arquitetura anycast, design de constelação de servidores de nome, comunicação de status, suporte ao cliente, prontidão do parceiro de mitigação e evidências pós-incidente. Uma conta de responsabilidade justa pode manter ambas as ideias ao mesmo tempo. O ataque foi malicioso e grande. O negócio da Dyn era manter o DNS autoritativo acessível sob condições hostis.

Mirai moveu o risco de dispositivos de consumo para a infraestrutura

Mirai tornou o ataque culturalmente memorável porque a botnet foi construída em grande parte a partir de dispositivos comuns conectados à internet: câmeras, roteadores, gravadores de vídeo digital e sistemas embarcados similares. Oartigo da USENIX Understanding the Mirai Botnetdescreve Mirai como composto principalmente por dispositivos embarcados e IoT e diz que cresceu para um pico de cerca de 600.000 infecções. O artigo argumenta que a simplicidade do método de infecção e o crescimento rápido mostraram que técnicas relativamente não sofisticadas poderiam comprometer dispositivos de baixo custo suficientes para ameaçar alvos bem defendidos.

O anúncio do Departamento de Justiça de 2017 sobre Mirai,Departamento de Justiça Anuncia Acusações e Confissões de Culpa em Três Casos de Crime Informático Envolvendo Ataques DDoS Significativos, disse que Paras Jha, Josiah White e Dalton Norman se confessaram culpados de operar a botnet Mirai, que visava dispositivos IoT como câmeras sem fio, roteadores e gravadores de vídeo digital. O DOJ disse que Mirai consistia em centenas de milhares de dispositivos comprometidos em seu pico, e que o envolvimento dos criadores originais com a variante original do Mirai terminou quando Jha publicou o código-fonte em um fórum criminoso no outono de 2016. Desde então, o DOJ disse que outros atores usaram variantes do Mirai em outros ataques.

O anúncio do Departamento de Justiça de 2020,Indivíduo Confessa Culpa por Participar de Ciberataque à Internet das Coisas em 2016, conectou uma botnet variante do Mirai ao dia Dyn mais diretamente. Disse que um indivíduo, anteriormente menor de idade, se confessou culpado em relação a um ciberataque de outubro de 2016. Segundo o DOJ, o indivíduo e outros usaram uma botnet para lançar vários ataques DDoS em 21 de outubro de 2016 na tentativa de derrubar a PlayStation Network da Sony; os ataques impactaram a Dyn, o que fez com que sites como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix e Southern New Hampshire University ficassem inacessíveis ou intermitentes por várias horas.

Esse registro de atribuição deve ser usado com cuidado. Ele não diz que o ator menor foi a única causa de todo o impacto na Dyn, nem significa que todo o mix de tráfego da Dyn veio de uma botnet. A própria Dyn disse que uma fonte de tráfego de ataque eram dispositivos infectados por Mirai. O provedor também descreveu múltiplos vetores e locais de internet. A conclusão mais segura é que Mirai e variantes de Mirai estavam materialmente envolvidos, e que a camada de conduta criminosa é separada da camada de arquitetura de resiliência.

Oalerta da CISA sobre a ameaça Miraiavisou que o malware Mirai escaneava dispositivos IoT vulneráveis e que a liberação pública do código-fonte do Mirai aumentou o risco de mais botnets. O relatório posterior do Comércio e Segurança Interna hospedado pelo NIST,Aumentando a Resiliência do Ecossistema da Internet e Comunicações Contra Botnets e Outras Ameaças Distribuídas Automatizadas, enquadrou o problema como ecossistêmico: ataques distribuídos automatizados são globais, ferramentas eficazes não são amplamente utilizadas, produtos devem ser protegidos ao longo de seu ciclo de vida, incentivos estão desalinhados e nenhuma comunidade de stakeholders pode resolver o problema sozinha.

Esse enquadramento ecossistêmico se encaixa melhor no incidente Dyn do que uma história de culpa estreita. Atacantes abusaram de dispositivos que não possuíam. Fabricantes de dispositivos frequentemente enviavam produtos de baixo custo sem controles fortes de atualização, identidade e ciclo de vida. Proprietários de dispositivos raramente entendiam que uma câmera ou gravador em um armário poderia participar de um ataque à infraestrutura DNS. ISPs tinham visibilidade parcial no tráfego de dispositivos infectados, mas incentivos mistos e limites práticos. Provedores de DNS viam o ataque quando ele chegava à sua borda.

Os clientes viam quando seus nomes paravam de resolver. Os usuários viam apenas como um site que não carregava.

O controle do cliente era real, mas desigual

Os clientes de DNS gerenciado não eram bystanders passivos. O proprietário do domínio controla as escolhas de delegação, seleção de provedor, monitoramento, política de TTL, design de failover e se os serviços críticos podem sobreviver à perda de um provedor de DNS. Mas o controle não era igual entre os clientes. Uma grande plataforma com uma equipe de infraestrutura profunda poderia executar vários provedores autoritativos, auto-hospedar parte da pilha, manter automação de consistência e testar a resolução de muitas redes.

Um pequeno editor, varejista, fornecedor de software, organização sem fins lucrativos ou serviço municipal pode ter comprado DNS gerenciado precisamente para evitar a necessidade dessa habilidade.

É aqui que a dependência de serviço em nuvem se torna uma questão de responsabilidade. Um fornecedor pode vender expertise, mas os clientes ainda precisam decidir qual nível de falha do fornecedor podem tolerar. A questão não é "todo site deve executar uma rede DNS global personalizada?" Isso seria economicamente absurdo. A questão é se as promessas de disponibilidade do cliente correspondem ao seu mapa de dependência. Um negócio que trata a acessibilidade online como missão crítica deve saber se um único provedor de DNS gerenciado é um ponto único de falha.

Deve saber com que rapidez pode mudar a delegação no registrador, quanto tempo os registros NS em cache viverão, se um provedor secundário tem uma zona atualizada, se o DNSSEC continuará validando e se o failover pode ser testado sem criar um incidente público.

Para organizações menores, a resposta prática pode não ser uma arquitetura multiprovedor perfeita. Pode ser um plano de recuperação mais restrito: um segundo provedor configurado para os registros mais importantes, TTLs mais longos para ativos estáveis quando apropriado, credenciais de registrador disponíveis para mais de uma pessoa de confiança, páginas de status fora de banda, informações de contato de emergência em cache e monitoramento que distingue falha de resolução DNS de falha de aplicação.

Isso é menos elegante do que a diversidade totalmente automatizada, mas ainda é melhor do que descobrir a dependência durante um incidente global de fornecedor.

O risco também se estende aos usuários downstream. Um marketplace, editor, provedor de SaaS ou serviço de pagamento que fica inalcançável transfere custos para anunciantes, vendedores, equipes de suporte, contratados e clientes. O usuário não pode ver se a causa raiz é DNS, DDoS, hospedagem em nuvem, roteamento ISP ou um bug de aplicação. Eles simplesmente não podem transacionar. Como o DNS gerenciado fica tão cedo no caminho, sua falha pode tornar toda a redundância posterior irrelevante até que a resolução de nomes retorne.

A comunicação teve que servir a dois públicos

A Dyn tinha dois problemas de comunicação. Ela tinha que dizer aos clientes diretos o que estava acontecendo e o que esperar. Também tinha que se comunicar com a comunidade mais ampla da internet porque a interrupção era visível muito além da base de clientes contratados da Dyn. Usuários públicos, jornalistas, reguladores, pares de infraestrutura e concorrentes tinham interesse em entender se o evento era uma interrupção direcionada de plataforma, uma instabilidade mais ampla da internet, uma emergência de botnet ou um problema de concentração de DNS.

A declaração da Dyn deu uma narrativa cuidadosa do provedor: não em todo o sistema, variavelmente regional, duas ondas com impacto no cliente, uma terceira tentativa mitigada, gerenciamento de incidentes ativado, parceiros de mitigação envolvidos, Mirai confirmado como uma fonte de tráfego e mais detalhes retidos para preservar defesas futuras. Esse equilíbrio é defensável. Um provedor de DDoS não deve publicar um blueprint completo de mitigação durante um ataque ativo ou repetível.

No entanto, os clientes precisavam de mais do que garantias. Eles precisavam de suporte a decisões. Deveriam mudar de provedor de DNS imediatamente? Deveriam alterar TTLs? Deveriam comunicar avisos de interrupção voltados ao cliente? A propagação da zona estava atrasada? Todas as regiões foram afetadas? Os registros DNS dos clientes estavam intactos? Quais grupos de servidores de nome estavam degradados? Era esperado que o problema se repetisse? Quanto mais um provedor se vende como infraestrutura de internet, mais sua comunicação de status se torna parte do serviço.

O incidente também mostrou por que os clientes precisam de monitoramento independente. A página de status de um provedor pode atrasar ou simplificar. As verificações de aplicação do próprio cliente podem perder a falha de DNS se forem executadas a partir de uma rede com caches quentes. O monitoramento deve testar a consulta autoritativa, a resolução recursiva de múltiplas regiões, a acessibilidade da aplicação e a falha específica de dependência. A análise pública da ThousandEyes foi poderosa porque separou a falha de consulta DNS da sensação geral do usuário de que "a internet caiu".

Caches, repetições e preparação mudaram a forma do dano

A falha de DNS não é experimentada de forma uniforme porque a camada recursiva fica entre os usuários e os provedores autoritativos. Se um resolvedor recursivo já tem uma resposta válida em cache, um usuário pode continuar alcançando um serviço mesmo enquanto os servidores autoritativos estão prejudicados. Se a resposta em cache expirar, ou se o resolvedor não tiver resposta, o mesmo serviço pode se tornar subitamente inalcançável a partir dessa rede. Dois usuários na mesma cidade podem, portanto, relatar resultados diferentes porque seus resolvedores, caches e temporização de consulta diferem.

Esse comportamento complica tanto a culpa quanto a resposta. Um proprietário de serviço pode olhar para seus servidores de origem e ver saúde normal. Um provedor de DNS gerenciado pode ver uma mistura de tráfego de ataque, repetições legítimas de resolvedores, efeitos de cache obsoleto e mudanças de rota. Operadores recursivos podem aumentar a pressão de consulta repetindo quando as respostas expiram. Os usuários veem acessibilidade intermitente e podem assumir que a aplicação está quebrada.

A narrativa pública se torna "grandes sites estão fora do ar", enquanto a realidade técnica é mais como "alguns resolvedores não podem obter ou atualizar respostas autoritativas para alguns domínios durante algumas janelas".

Aobservação rápida do RIPE Labs sobre o ataque à Dynusou medições do RIPE Atlas para observar o evento a partir de sondas distribuídas. Uma nota complementar do RIPE Labs,Especulando sobre DDoS DNS, destacou que o tráfego de repetição recursiva pode agravar o impacto e que distinguir tráfego DNS legítimo de tráfego de ataque durante um DDoS no protocolo DNS pode ser difícil. Estas não são avaliações legais sobre a Dyn. Elas explicam por que a mitigação de DDoS DNS é mais confusa do que bloquear uma única fonte hostil ou adicionar um único servidor de backup.

Pesquisas após o incidente fizeram o mesmo ponto de outro ângulo. O artigoWhen the Dike Breaks: Dissecting DNS Defenses During DDoSargumenta que o cache é um fator importante na resiliência do DNS e que diferentes camadas de DNS podem experimentar DDoS de forma muito diferente. O artigo usa o incidente Dyn como exemplo de uma interrupção visível que afetou domínios usando a Dyn como provedor de DNS, enquanto observa que outros alvos DNS, como servidores raiz, absorveram ataques sem interrupções visíveis de serviço. A lição não é que uma camada de DNS é segura e outra é fraca. É que arquitetura, cache, diversidade, volume de tráfego e prática do operador se combinam para determinar o impacto público.

Para um cliente de DNS gerenciado, isso significa que a preparação deve incluir mais do que um nome de fornecedor em um registro de risco. O cliente precisa saber quais registros são estáveis o suficiente para uma vida de cache mais longa, quais registros requerem direcionamento dinâmico, quais resolvedores recursivos são importantes para seus usuários e como respostas obsoletas podem afetar um failover. Também precisa decidir se uma alteração de TTL de emergência é útil antes de um incidente ou principalmente simbólica depois que os caches já contêm o valor antigo.

As mudanças de DNS são dependentes do tempo; um plano de recuperação que assume propagação global instantânea não é um plano de recuperação.

Orientações gerais de DDoS reforçam a mesma disciplina operacional. A coleção deorientações sobre negação de serviço do NCSC do Reino Unidoenquadra a preparação em torno de quatro práticas: entenda o serviço, entenda as defesas, crie um plano de resposta e teste a resposta. OUnderstanding Denial-of-Service Attacks da CISAexplica o problema básico de disponibilidade: usuários legítimos não podem acessar sistemas de informação, dispositivos ou recursos de rede. OUnderstanding and Responding to Distributed Denial-of-Service Attacksdo CISA, FBI e MS-ISAC é mais amplo que DNS, mas o princípio se aplica: as organizações precisam de preparação antecipada, coordenação com provedores de serviços, linhas de base de tráfego, procedimentos de resposta e planos de comunicação.

Essas práticas expõem uma verdade desconfortável sobre dependências em nuvem. Um cliente pode terceirizar a operação de DNS, mas não pode terceirizar o conhecimento de como a falha de DNS afeta seu próprio negócio. A Dyn podia mitigar ataques em sua infraestrutura; não podia conhecer o estado degradado aceitável de cada cliente. Um banco, marketplace, editor, universidade, rede de jogos e portal de consultas hospitalares têm tolerância diferente para resolução lenta, respostas obsoletas e perda de acessibilidade regional.

O plano de continuidade do cliente deve traduzir o status do provedor em decisões de negócio: se notificar usuários, mudar canais, suspender transações, falhar abertamente, falhar fechado ou aceitar acessibilidade parcial até o DNS estabilizar.

Para a Dyn, o mesmo princípio de preparação funciona na direção oposta. Um provedor de DNS gerenciado deve entender que um evento DDoS contra sua própria infraestrutura não é apenas um incidente técnico dentro de sua rede. É uma crise simultânea de clientes. Os clientes precisam de informações suficientes para evitar piorar o evento improvisando mudanças de delegação, encurtando TTLs, movendo zonas inconsistentemente ou inundando o suporte. Os playbooks do provedor, portanto, têm que incluir mitigação, segmentação de clientes, precisão de status e orientação para clientes com diferentes níveis de sofisticação em DNS.

O incidente de outubro de 2016 foi danoso em parte porque revelou a superficialidade da camada de preparação compartilhada. Engenheiros de DNS entendiam cache, anycast e resolução autoritativa. Muitos líderes empresariais e usuários não entendiam. Alguns clientes entendiam diversidade de provedores. Muitos não a tinham implementado. Especialistas em segurança IoT entendiam os riscos de credenciais padrão e frotas de dispositivos não gerenciados. Milhões de dispositivos já estavam expostos.

Uma falha de modo comum é frequentemente o que acontece quando o conhecimento especializado existe em comunidades separadas, mas não foi convertido em compromissos operacionais compartilhados.

O limite legal é mais estreito do que a lição operacional

O registro público estabelece atividade DDoS maliciosa, interrupção do serviço da Dyn, problemas de acessibilidade do cliente, envolvimento do Mirai e confissões de culpa posteriores. Não estabelece que a Dyn violou um contrato específico, que todo cliente afetado carecia de arquitetura razoável, que todo fabricante de IoT violou um dever legal ou que todas as perdas podem ser atribuídas a um único réu. Os termos dos contratos individuais da Dyn, acordos de nível de serviço do cliente, apólices de seguro e dependências de terceiros não são públicos de forma a apoiar conclusões legais amplas.

Esse limite não deve enfraquecer a lição operacional. Torna-a mais clara. A culpa legal é específica do foro. O controle operacional é visível nas escolhas de design. A Dyn controlava a resiliência e comunicação no nível do provedor. Os clientes controlavam a diversificação do provedor DNS e o planejamento de continuidade. Os vendedores de IoT controlavam credenciais padrão, caminhos de atualização e suporte ao ciclo de vida. Os proprietários de dispositivos controlavam a implantação e o endurecimento básico apenas na medida em que os produtos tornavam isso prático.

ISPs e empresas de segurança controlavam as escolhas de detecção, notificação e mitigação. Os governos controlavam incentivos, padrões, resposta de aplicação da lei e coordenação público-privada.

O incidente pertence à análise de responsabilidade porque nenhuma camada poderia corrigir toda a falha. Um cliente perfeito de DNS multiprovedor ainda poderia sofrer com uma botnet massiva em outra parte de sua pilha. Uma linha de produtos IoT bem construída não diversificaria o DNS autoritativo de um cliente. Um provedor de DNS brilhante ainda poderia enfrentar tráfego hostil sem precedentes de dispositivos que não vendeu. Um relatório governamental poderia recomendar segurança de ciclo de vida, mas não substituir instantaneamente milhões de dispositivos expostos. A falha de modo comum emergiu do ajuste entre essas camadas.

O sinal de mercado pós-incidente

Um mês após o ataque, a Oracle anunciou que havia concordado em adquirir a Dyn. Ocomunicado de imprensa da Oracledescreveu a Dyn como um provedor líder de DNS e desempenho na internet baseado em nuvem, disse que sua rede gerenciava 40 bilhões de decisões de otimização de tráfego diariamente para mais de 3.500 clientes empresariais e nomeou clientes como Netflix, Twitter, Pfizer e CNBC. A aquisição não deve ser interpretada como consequência do ataque sem evidências; o comunicado não disse isso. Ainda é um contexto útil para o papel de mercado da Dyn. Este não era um serviço de nicho amador. Era uma grande plataforma de DNS gerenciado para negócios digitais de alto perfil.

Essa posição de mercado é por que o incidente ainda importa. A concentração em nuvem frequentemente produz benefícios reais: melhor expertise, maior alcance global, mitigação mais rápida, equipe especializada e economias de escala. Também muda o modo de falha. Quando muitos clientes convergem no mesmo provedor, suas reivindicações independentes de continuidade de negócios podem se tornar correlacionadas. Uma plataforma pode terceirizar uma função e ainda possuir as consequências da arquitetura de terceirização.

O relatório de 2018 do Comércio e Segurança Interna argumentou que os incentivos de mercado estavam desalinhados para a resiliência a botnets. Um problema de incentivo semelhante existia no lado do cliente do DNS gerenciado. O DNS de provedor único é mais simples de comprar, configurar, monitorar e suportar. O DNS multiprovedor reduz o risco de modo comum, mas aumenta a complexidade de engenharia e a chance de má configuração. O cliente que evita essa complexidade pode nunca ser punido em tempos normais.

A penalidade aparece apenas quando um fornecedor falha sob estresse, e nesse momento muitos clientes podem experimentar o mesmo evento juntos.

Testes práticos de responsabilidade

O caso Dyn dá aos líderes vários testes que permanecem úteis.

Dependência de DNS autoritativo:Qual provedor responde por cada domínio e subdomínio crítico? Todos os servidores de nome listados são operados pelo mesmo provedor ou através do mesmo plano de controle de roteamento e gerenciamento? Quais serviços falham se esse provedor estiver inacessível a partir de uma grande região?

Independência do provedor:Existe um segundo provedor de DNS autoritativo com dados de zona atuais? Se sim, ele é verdadeiramente independente em rede, plano de controle, credenciais, caminho de suporte e mitigação de DDoS? Se não, a organização aceitou conscientemente o risco de provedor único?

Estratégia de TTL e cache:Os TTLs de DNS refletem a necessidade real da organização por agilidade versus tolerância a interrupções? Os registros mais estáveis recebem vida de cache suficiente para reduzir a dependência evitável de consultas autoritativas frequentes durante problemas temporários de provedor?

DNSSEC e controle de mudanças:Se o DNSSEC está habilitado, as assinaturas, chaves e registros DS podem sobreviver à operação multiprovedor ou a uma mudança de provedor de emergência? Se não, o fallback pode falhar de forma segura, o que ainda significa que os usuários não podem acessar o serviço.

Monitoramento:A organização pode distinguir falha de DNS autoritativo, problemas de resolvedor recursivo, problemas de CDN, falha de origem e falha de aplicação? Os testes são executados a partir de redes e regiões suficientes para detectar um problema de anycast ou DNS regional?

Recuperação do registrador:As credenciais do registrador, bloqueios de registro, contatos de emergência e procedimentos de mudança de delegação estão documentados, protegidos e disponíveis durante um incidente? Um provedor de DNS de backup não é útil se ninguém puder mudar a delegação com segurança.

Comunicações com o fornecedor:O provedor de DNS gerenciado fornece detalhes de status no nível que os clientes precisam para tomar decisões, sem expor métodos defensivos? Os caminhos de suporte ao cliente são projetados para um evento de impacto simultâneo onde muitos clientes pedem ajuda ao mesmo tempo?

Exposição a botnets:Para organizações que fabricam, implantam ou gerenciam dispositivos conectados, as credenciais padrão, atualização segura, identidade do dispositivo, relatório de vulnerabilidades e suporte de fim de vida são projetados para evitar que a frota de dispositivos se torne capacidade de DDoS de outra pessoa?

Esses testes não são pureza de engenharia abstrata. Eles são como um proprietário de domínio aprende se "temos servidores de nome redundantes" significa independência de falha genuína ou apenas vários hostnames dentro de uma dependência de provedor.

A lição durável

A Dyn não provou que o DNS gerenciado é ruim. O oposto está mais perto da verdade: o DNS gerenciado existe porque a disponibilidade do DNS é difícil, especializada e globalmente exposta. Muitos clientes seriam menos resilientes se forçados a executar sua própria infraestrutura autoritativa sem expertise. O incidente provou que a terceirização não apaga a arquitetura. Ela move parte da arquitetura para um fornecedor e então exige que o cliente decida se o fornecedor é um componente ou uma dependência de modo comum.

Nem o Mirai provou que a IoT de consumo pode ser culpada sozinha por toda interrupção de infraestrutura. Provou que dispositivos de borda inseguros podem ser agregados em uma força grande o suficiente para ameaçar serviços centrais. As residências e empresas que possuíam esses dispositivos não pretendiam atacar a Dyn. Os vendedores de dispositivos podem não ter imaginado seus produtos como peças de infraestrutura de internet. Mas a internet pública os tornou participantes de qualquer maneira.

A memória responsável do incidente Dyn deve, portanto, ser em camadas. Atores criminosos lançaram ataques. A Dyn defendeu uma plataforma DNS de alto valor sob tráfego hostil extremo e ainda experimentou interrupção com impacto no cliente. Muitos clientes dependiam de um provedor para DNS autoritativo e descobriram que múltiplos servidores de nome nem sempre significam diversidade de provedor. Vendedores e proprietários de IoT permitiram que dispositivos fracos se tornassem recursos de ataque.

Governos e órgãos de normalização posteriormente enquadraram a resiliência a botnets como um problema de mercado e ecossistema, não apenas uma questão de punir um atacante.

A lição prática é stark: a acessibilidade depende do plano de controle chato. Uma empresa pode construir servidores de aplicação redundantes, múltiplas nuvens, regiões ativo-ativo e resposta a incidentes sofisticada, e ainda desaparecer dos navegadores dos usuários se sua dependência de DNS autoritativo for de provedor único e inacessível. A delegação de DNS é poder. Tratá-la como uma linha de baixo risco de procurement é como um serviço gerenciado se torna uma falha de modo comum.