Resumo

  • Confirmado:Em 21 de outubro de 2016, a Dyn relatou ataques DDoS contra sua infraestrutura de DNS gerenciado. Seu comunicado público indicou que a primeira onda começou por volta das 7h00, horário do leste, afetando usuários direcionados aos servidores Dyn da 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 afirmou que uma terceira tentativa de onda foi mitigada sem impacto aos clientes.
  • Observado:A ThousandEyes mediu altas taxas de falha de consultas DNS a partir de seus pontos de observação globais e relatou que aproximadamente 75% de seus pontos de observação enviaram consultas que não receberam resposta dos servidores da Dyn no pico do ataque. A empresa também observou cerca de 1.200 sites e serviços afetados entre aqueles monitorados por seus clientes e constatou que muitos clientes vulneráveis usavam apenas os servidores de nomes da Dyn, em vez de múltiplos provedores DNS.
  • Atribuição limitada:A Dyn afirmou que análises da Flashpoint e Akamai confirmaram que parte do tráfego veio de dispositivos infectados pelo Mirai. O Departamento de Justiça dos EUA anunciou posteriormente confissões de culpabilidade dos criadores do Mirai e uma confissão separada de um indivíduo cujo botnet, usando uma variante do Mirai, em 21 de outubro de 2016, afetou a Dyn e tornou sites como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix e a Southern New Hampshire University inacessíveis ou intermitentes por várias horas. O registro público não prova que um único ator, um único botnet ou um único vetor de ataque explique todo o tráfego sofrido pela Dyn naquele dia.
  • Avaliação:O incidente foi uma falha de modo comum de dependência. A Dyn controlava sua plataforma de DNS gerenciado, seus parceiros de mitigação, suas comunicações e a arquitetura de sua infraestrutura. Os clientes controlavam a diversificação do DNS autoritativo entre múltiplos provedores e a adequação de práticas de TTL, failover e monitoramento com suas próprias declarações de disponibilidade. Fabricantes de IoT, proprietários de dispositivos, ISPs, reguladores e atacantes controlavam cada um uma parte distinta do problema do botnet.

O DNS falhou antes da aplicação web

Um usuário normalmente nota o DNS apenas quando ele não funciona. O nome do site parece normal. O navegador funciona. A conexão do usuário pode estar saudável. A aplicação de destino pode ainda estar em execução. No entanto, se o caminho do DNS autoritativo não puder responder, o serviço pode desaparecer como se os próprios servidores estivessem offline. Foi isso que tornou o incidente da Dyn tão desconcertante. Muitos serviços não estavam necessariamente inativos em sua camada de aplicação. Seus nomes simplesmente 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 situa-se na interseção de duas formas de terceirização. Por um lado, muitas empresas digitais terceirizaram seu DNS autoritativo para um provedor gerenciado, pois ele poderia oferecer alcance anycast global, direcionamento de tráfego, expertise operacional e preparação para DDoS que muitos clientes não conseguiam construir sozinhos de forma econômica. Por outro lado, milhões de lares e organizações colocaram dispositivos conectados não seguros na Internet pública, muitas vezes com credenciais padrão fracas ou caminhos de atualização insuficientes.

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

O comunicado da Dyn, preservado em uma cópia pública em PDF doComunicado da Dyn sobre o Ataque DDoS de 21/10/2016, afirmou que a empresa sofreu ataques DDoS contra sua infraestrutura de DNS gerenciado. Descreveu uma primeira onda começando por volta das 7h00, horário do leste, recuperação cerca de duas horas depois, uma segunda onda mais global pouco antes do meio-dia, recuperação por volta das 13h00, e uma terceira tentativa de onda que a Dyn disse ter mitigado sem impacto aos clientes. A Dyn também observou que em nenhum momento sofreu uma falha em escala de sistema, e que alguns usuários, como aqueles acessando sites afetados da Costa Oeste dos EUA durante a primeira onda, podem ter conseguido acesso com sucesso.

Esse detalhe é importante. O incidente não foi uma falha binária nítida onde cada cliente da Dyn desaparecia em todos os lugares. Foi uma falha de disponibilidade moldada por geografia, anycast, comportamento de resolvedores, TTL, configuração de domínio do cliente e intensidade variável do tráfego DDoS. Isso tornou a comunicação difícil. Um cliente podia testar de uma rede e obter sucesso, enquanto usuários em outros lugares obtinham falha. Um proprietário de plataforma podia ter servidores de aplicação saudáveis e ainda receber reclamações de que o serviço estava fora do ar.

Um usuário podia esperar a resposta DNS em cache expirar e perder subitamente o acesso.

A dependência compartilhada era visível nas métricas

A análise da ThousandEyes,Ataque DDoS à infraestrutura DNS da Dyn, fornece a explicação pública mais clara da dependência do lado do cliente. Seu monitoramento identificou três fases: um impacto inicial concentrado na Costa Leste dos EUA, um impacto global mais amplo e, em seguida, mitigação com ataques persistentes ou blackholing. No pico do ataque, cerca de três quartos de seus pontos de observação globais enviaram consultas DNS que ficaram sem resposta dos servidores da Dyn. Também relatou cerca de 1.200 sites e serviços afetados entre os domínios monitorados por seus clientes.

O ponto técnico era simples, mas severo. A Dyn operava servidores autoritativos para os domínios de seus clientes. Se um resolvedor não tinha já uma resposta em cache válida e não conseguia alcançar os servidores autoritativos da Dyn, não podia obter o endereço necessário para se conectar. Valores de TTL mais curtos podem tornar o gerenciamento de tráfego mais ágil em operação normal, mas também tornam os usuários mais dependentes de resoluções autoritativas bem-sucedidas. Um TTL baixo não é ruim por si só; é uma compensação.

Durante um evento DDoS que afeta um provedor DNS, isso pode reduzir o tempo entre "o cache ainda sabe para onde ir" e "o resolvedor precisa consultar novamente a autoridade indisponível".

A ThousandEyes também descreveu a popularidade da Dyn para direcionamento de tráfego. O DNS gerenciado não era apenas um diretório estático. Ajudava grandes serviços a rotear usuários para datacenters próximos, mover tráfego e otimizar 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 podia afetar muitos clientes ao mesmo tempo. Quanto mais forte a proposta de valor do provedor, mais atraente ele se tornava como um plano de controle compartilhado.

A conclusão mais importante da ThousandEyes para a responsabilidade dizia respeito à arquitetura dos clientes. Muitos clientes da Dyn afetados usavam apenas os servidores de nomes da Dyn, em vez de diversificar entre múltiplos provedores DNS. A análise contrastava 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 da mesma indisponibilidade total observada por muitos outros. Isso não significa que todo cliente poderia ter mudado para DNS multiprovedor da noite para o dia.

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

Amatéria da AP republicada pelo Chicago Sun-Timesrelatou a experiência pública: repercussões para usuários tentando acessar sites populares nos EUA e na Europa, com Twitter, Netflix e a PlayStation Network da Sony entre os serviços aparentemente afetados. Orelato contemporâneo do Guardianlistou Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News e grandes jornais entre os serviços relatados como offline ou degradados. Esses relatos são úteis para a abrangência e percepção pública; não provam que cada serviço nomeado experimentou o mesmo modo de falha técnica ou a mesma duração.

A falha de modo comum se esconde em DNS "redundante"

O DNS incorpora redundância em seu design. Os domínios listam múltiplos servidores de nomes. Os resolvedores podem tentar alternativas. Os servidores autoritativos podem ser geograficamente dispersos. O problema é que a redundância pode ser formal sem ser independente em caso de falha.

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

O caso Dyn transpôs esse princípio da localização física para a dependência do provedor. Um cliente podia listar vários servidores de nomes da Dyn, mas ainda ter um único provedor, um único relacionamento comercial, um único caminho de suporte operacional, um único conjunto de credenciais de gerenciamento de DNS e uma única exposição a um ataque importante contra esse provedor. Do ponto de vista do domínio, esses servidores de nomes podem parecer diversificados. Do ponto de vista da responsabilidade, eles ainda fazem parte de uma dependência comum de um provedor.

O estudoA Falta de Redundância na Resolução de DNS por Grandes Sites e Serviçosexaminou a concentração e diversificação do DNS após o incidente Dyn. Constatou uma concentração crescente em torno de um pequeno número de provedores DNS e uma forte tendência dos domínios a não usar múltiplos provedores de gerenciamento de DNS. Em sua amostra, a proporção de domínios usando apenas um provedor era de cerca de 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 da Dyn, a parcela de domínios não diversificados caiu fortemente após o incidente e continuou caindo até maio de 2017.

Esses números devem ser considerados como resultados de pesquisa em um conjunto de dados específico, e não como um censo exato da Internet como um todo. No entanto, confirmam a lição prática. O DNS tornava possível a diversificação de provedores, mas muitos clientes escolheram a simplicidade operacional em vez da independência em relação a falhas. Isso não é irracional.

Um DNS autoritativo multiprovedor introduz complexidade: consistência de dados de zona, assinatura DNSSEC e gerenciamento de chaves, comportamento de verificações de saúde, 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 da não diversificação também pode se tornar real, e pode ocorrer através de um provedor, em vez da própria infraestrutura do cliente.

Anycast é poderoso, mas não mágico

A infraestrutura da Dyn, como a de muitas plataformas DNS globais, usava anycast. Anycast permite que múltiplos locais anunciem o mesmo endereço IP, de modo que o roteamento da Internet possa direcionar um resolvedor para uma instância próxima ou preferida. Isso melhora a latência e absorve muitas falhas locais, pois 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 o tráfego, mas também pode distribuir a pressão do ataque. Se o ataque for grande o suficiente, abrangente ou direcionado de modo a congestionar enlaces upstream, peering ou prefixos compartilhados, os locais anycast podem falhar juntos ou fazer failover de forma complexa. A ThousandEyes observou que muitas consultas não conseguiam atravessar os provedores de acesso à Internet da Dyn ou a borda da rede da Dyn, e que os servidores de nomes dentro de uma mesma constelação e grupo mostravam desempenho correlacionado. Essa observação não prova que o design interno da Dyn era negligente.

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

O comunicado da Dyn afirmava que a empresa praticava cenários, tinha manuais operacionais, usava parceiros de mitigação e havia iniciado o gerenciamento de incidentes e comunicações com clientes. Também afirmava 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 da 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 novas tentativas, tráfego colateral, instabilidade de roteamento e escolhas difíceis entre filtrar tráfego de ataque e preservar consultas legítimas.

No entanto, os clientes compram DNS gerenciado porque o provedor alega expertise precisamente nessa área operacional. A Dyn detinha, portanto, o lado do provedor da resiliência: planejamento de capacidade, coordenação upstream, arquitetura anycast, design da constelação de servidores de nomes, comunicação de status, suporte ao cliente, preparação de parceiros de mitigação e evidências pós-incidente. Um relato justo de responsabilidade pode conter ambas as ideias simultaneamente. O ataque foi malicioso e de grande escala. A atividade da Dyn era manter o DNS autoritativo acessível em condições hostis.

Mirai transformou o risco de dispositivos de consumo em risco de infraestrutura

O Mirai tornou o ataque culturalmente memorável porque o botnet era construído em grande parte a partir de dispositivos comuns conectados à Internet: câmeras, roteadores, gravadores de vídeo digital e sistemas embarcados similares. O artigo da USENIXEntendendo o Botnet Miraidescreve o Mirai como composto principalmente por dispositivos embarcados e IoT, e afirma que atingiu um pico de cerca de 600.000 infecções. O artigo argumenta que a simplicidade do método de infecção e o rápido crescimento mostraram que técnicas relativamente pouco sofisticadas poderiam comprometer dispositivos de baixo custo o suficiente para ameaçar alvos bem defendidos.

O anúncio do Departamento de Justiça de 2017 sobre o Mirai,Departamento de Justiça Anuncia Acusações e Confissões em Três Casos de Crime de Computador Envolvendo Ataques DDoS Significativos, indicou que Paras Jha, Josiah White e Dalton Norman se confessaram culpados por operar o botnet Mirai, que visava dispositivos IoT como câmeras sem fio, roteadores e gravadores de vídeo digital. O DOJ afirmou que o Mirai tinha centenas de milhares de dispositivos comprometidos em seu auge, 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, segundo o DOJ, outros atores usaram variantes do Mirai em outros ataques.

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

Esse registro de atribuição deve ser usado com cautela. Ele não diz que o ator menor era a causa única de todo impacto na Dyn, nem que todo o tráfego da Dyn naquele dia veio de um único botnet. A própria Dyn afirmou que uma fonte do tráfego de ataque veio de dispositivos infectados pelo Mirai. O provedor também descreveu múltiplos vetores e locais da Internet. A conclusão mais segura é que o Mirai e suas variantes estiveram materialmente envolvidos, e que a camada de comportamento criminoso é distinta da camada de arquitetura de resiliência.

Oalerta da CISA sobre a ameaça do Miraiadvertia que o malware Mirai estava ativamente procurando dispositivos IoT vulneráveis e que a publicação do código-fonte do Mirai aumentava o risco de novos botnets. O relatório posterior do Comércio e Segurança Interna hospedado pelo NIST,Aumentando a Resiliência da Internet e do Ecossistema de Comunicações Contra Botnets e Outras Ameaças Automatizadas Distribuídas, enquadrou o problema em escala de ecossistema: ataques distribuídos automatizados são globais, ferramentas eficazes não são amplamente utilizadas, produtos precisam ser seguros ao longo de seu ciclo de vida, os incentivos estão desalinhados e nenhuma comunidade de partes interessadas pode resolver o problema sozinha.

Esse enquadramento ecossistêmico se adequa melhor ao incidente Dyn do que uma narrativa estreita de culpa. Os atacantes abusaram de dispositivos que não possuíam. Os fabricantes de dispositivos frequentemente comercializavam produtos de baixo custo sem controles robustos de atualização, identidade e ciclo de vida. Os proprietários de dispositivos raramente entendiam que uma câmera ou gravador em um armário poderia participar de um ataque à infraestrutura de DNS. Os ISPs tinham visibilidade parcial sobre o tráfego de dispositivos infectados, mas incentivos mistos e limitações práticas.

Os provedores de DNS viram o ataque quando ele alcançou sua borda. Os clientes o viram quando seus nomes pararam de ser resolvidos. Os usuários o viram apenas como um site que não carregava.

O documento posteriorNISTIR 8259A Linha de Base Central de Capacidade de Cibersegurança para Dispositivos IoTnão existia em 2016 e não deve ser tratado como uma obrigação legal retroativa para a Dyn. Continua útil como evidência do que o ecossistema aprendeu a valorizar: identificação de dispositivos, configuração segura, proteção de dados, acesso lógico, capacidade de atualização de software, consciência do estado de cibersegurança e documentação. O Mirai teve sucesso porque muitos dispositivos não podiam ser gerenciados como entidades responsáveis na Internet.

O controle dos clientes era real, mas desigual

Os clientes de DNS gerenciado não eram espectadores passivos. O proprietário do domínio controla as escolhas de delegação, a seleção do provedor, o monitoramento, a política de TTL, o design do failover e a capacidade dos serviços críticos de sobreviver à perda de um provedor DNS. Mas esse controle não era igual entre todos os clientes. Uma grande plataforma com uma equipe de infraestrutura robusta podia operar múltiplos 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 dessas habilidades.

É aqui que a dependência de serviços em nuvem se torna um problema de responsabilidade. Um provedor pode vender expertise, mas os clientes ainda precisam decidir qual nível de falha do provedor podem tolerar. A questão não é "todo site deveria operar 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ências. Uma empresa que considera a acessibilidade online como crítica para sua missão deve saber se um único provedor de DNS gerenciado constitui um ponto único de falha.

Deve saber com que rapidez pode alterar a delegação no nível do registrador, por quanto tempo os registros NS em cache permanecerão válidos, se um provedor secundário tem uma zona atualizada, se a validação DNSSEC continuará funcionando e se o failover pode ser testado sem criar um incidente público.

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

É menos elegante do que uma diversidade totalmente automatizada, mas ainda é melhor do que descobrir a dependência durante um incidente global no provedor.

O risco também se estende aos usuários a jusante. Um mercado, editor, fornecedor de SaaS ou serviço de pagamento que se torna inacessível repassa custos para anunciantes, vendedores, equipes de suporte, subcontratados e clientes. O usuário não consegue ver se a causa raiz é DNS, um DDoS, hospedagem em nuvem, roteamento de ISP ou um bug de aplicação. Ele simplesmente não consegue realizar a transação. Como o DNS gerenciado está tão cedo no caminho, sua falha pode tornar qualquer redundância subsequente inútil até que a resolução de nomes seja retomada.

A comunicação precisava atender a dois públicos

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

O comunicado da Dyn forneceu um relato cauteloso do provedor: não em escala de sistema, variável por região, duas ondas com impacto ao cliente, uma terceira tentativa de onda mitigada, gerenciamento de incidentes ativado, parceiros de mitigação envolvidos, Mirai confirmado como uma fonte de tráfego e outros detalhes não divulgados para preservar defesas futuras. Esse equilíbrio é defensável. Um provedor de serviços de proteção DDoS não deve publicar um plano completo de mitigação durante um ataque ativo ou com probabilidade de recorrência.

No entanto, os clientes precisavam de mais do que apenas garantias. Precisavam de ajuda para tomar decisões. Deveriam mudar de provedor DNS imediatamente? Deveriam alterar os TTLs? Deveriam comunicar avisos de falha a seus próprios clientes? A propagação de zona estava atrasada? Todas as regiões estavam afetadas? Os registros DNS dos clientes estavam intactos? Quais grupos de servidores de nomes estavam degradados? Esperava-se que o problema se repetisse? Quanto mais um provedor se vende como infraestrutura da Internet, mais sua comunicação de status se torna parte integrante 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 estar atrasada ou simplificar demais a situação. As próprias verificações de aplicação de um cliente podem perder uma falha de DNS se executadas de uma rede com caches ainda quentes. O monitoramento deve testar a resolução autoritativa, a resolução recursiva de múltiplas regiões, a acessibilidade da aplicação e as falhas específicas de dependência. A análise pública da ThousandEyes foi poderosa porque separou a falha de consultas DNS do sentimento geral do usuário de que "a Internet está fora do ar".

Caches, novas tentativas e preparação alteraram a extensão dos danos

A falha do DNS não é sentida uniformemente porque a camada recursiva fica entre os usuários e os provedores autoritativos. Se um resolvedor recursivo já tem uma resposta em cache válida, um usuário pode continuar a acessar um serviço mesmo que os servidores autoritativos estejam degradados. Se a resposta em cache expirar, ou se o resolvedor não tiver resposta, o mesmo serviço pode subitamente se tornar inacessível a partir dessa rede. Dois usuários na mesma cidade podem, portanto, relatar resultados diferentes porque seus resolvedores, caches e o momento de suas consultas diferem.

Esse comportamento complica tanto a atribuição de responsabilidade quanto a resposta. Um proprietário de serviço pode verificar seus servidores de origem e constatar saúde normal. Um provedor de DNS gerenciado pode ver uma mistura de tráfego de ataque, novas tentativas legítimas de resolvedores, efeitos de cache obsoleto e mudanças de rota. Operadores de resolvedores recursivos podem aumentar a pressão de consultas ao tentar novamente quando as respostas expiram. Os usuários veem acessibilidade intermitente e podem presumir que a aplicação está quebrada.

A narrativa pública se torna "grandes sites estão fora do ar", enquanto a realidade técnica parece mais com "alguns resolvedores não conseguem obter ou atualizar respostas autoritativas para certos domínios durante certas janelas de tempo".

ABreve Análise do Ataque à Dyndo RIPE Labs usou medições do RIPE Atlas para observar o evento a partir de sondas distribuídas. Uma nota complementar do RIPE Labs,Especulando sobre DDoS de DNS, destacou que o tráfego de novas tentativas recursivas pode agravar o impacto e que pode ser difícil distinguir tráfego DNS legítimo de tráfego de ataque durante um DDoS usando o protocolo DNS. Não se trata de julgamentos legais sobre a Dyn. Eles explicam por que a mitigação de DDoS de DNS é mais complicada do que simplesmente bloquear uma única fonte hostil ou adicionar um único servidor de backup.

Pesquisas pós-incidente fizeram a mesma constatação de outro ângulo. O artigoQuando o Dique Quebra: Dissecando Defesas de DNS Durante DDoSargumenta que o cache é um fator importante na resiliência do DNS e que diferentes camadas de DNS podem sofrer DDoS de maneiras muito diferentes. O artigo usa o incidente Dyn como exemplo de uma falha visível afetando domínios que usavam a Dyn como provedor de DNS, ao mesmo tempo que observa que outros alvos de DNS, como servidores raiz, absorveram ataques sem falhas de serviço visíveis. A lição não é que uma camada de DNS é segura e outra fraca. É que a arquitetura, o cache, a diversidade, o volume de tráfego e as práticas dos operadores 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 apenas um nome de provedor em um registro de riscos. O cliente precisa saber quais registros são suficientemente estáveis para um tempo de vida de cache mais longo, quais registros precisam de 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 emergência do TTL é útil antes de um incidente, ou principalmente simbólica depois que os caches já contêm o valor antigo.

As alterações de DNS dependem do tempo; um plano de recuperação que assume propagação global instantânea não é um plano de recuperação.

Guias gerais sobre DDoS reforçam a mesma disciplina operacional. AColetânea de Guias sobre Negação de Serviçodo National Cyber Security Centre britânico estrutura a preparação em torno de quatro práticas: entender o serviço, entender as defesas, criar um plano de resposta e testar a resposta. OEntendendo Ataques de Negação de Serviçoda CISA explica o problema fundamental de disponibilidade: usuários legítimos não conseguem acessar sistemas de informação, dispositivos ou recursos de rede. O documento posterior da CISA, FBI e MS-ISAC,Entendendo e Respondendo a Ataques de Negação de Serviço Distribuídos, é mais amplo que o DNS, mas o princípio se aplica: as organizações precisam de preparação prévia, coordenação com provedores de serviços, referências de tráfego, procedimentos de resposta e planos de comunicação.

Essas práticas revelam uma verdade desconfortável sobre dependências em nuvem. Um cliente pode terceirizar a operação do DNS, mas não pode terceirizar o conhecimento de como uma falha de DNS afeta seu próprio negócio. A Dyn podia mitigar ataques contra sua infraestrutura; não podia saber o estado degradado aceitável para cada cliente. Um banco, um mercado, um editor, uma universidade, uma rede de jogos e um portal de agendamento hospitalar têm tolerâncias diferentes 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: informar usuários, alternar para outros canais, suspender transações, abrir em caso de falha, fechar em caso de falha ou aceitar acessibilidade parcial até que o DNS se estabilize.

Para a Dyn, o mesmo princípio de preparação se aplica 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 para os clientes. Os clientes precisam de informações suficientes para evitar agravar o evento improvisando alterações de delegação, encurtando TTLs, movendo zonas de forma inconsistente ou sobrecarregando o suporte.

Os manuais operacionais do provedor devem, portanto, incluir mitigação, segmentação de clientes, precisão de status e orientações para clientes com diferentes níveis de sofisticação em DNS.

O incidente de outubro de 2016 foi prejudicial em parte porque revelou a fragilidade da camada de preparação compartilhada. Engenheiros de DNS entendiam cache, anycast e resolução autoritativa. Muitos executivos de negócios e usuários não entendiam. Alguns clientes entendiam diversificação de provedores. Muitos não a implementaram. Especialistas em segurança de IoT entendiam os riscos de credenciais padrão e frotas de dispositivos não gerenciadas. Milhões de dispositivos já estavam expostos.

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

A fronteira legal é mais estreita que a lição operacional

O registro público estabelece atividade DDoS maliciosa, interrupção do serviço da Dyn, problemas de acessibilidade para clientes, envolvimento do Mirai e confissões de culpabilidade posteriores. Não estabelece que a Dyn violou um contrato específico, que todo cliente afetado carecia de uma arquitetura razoável, que todo fabricante de IoT violou uma obrigação legal, nem 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 com clientes, apólices de seguro e dependências de terceiros não são públicos de uma forma que sustente conclusões legais gerais.

Essa fronteira não deve enfraquecer a lição operacional. Ela a torna mais clara. A culpa legal depende da jurisdição competente. O controle operacional é visível nas escolhas de design. A Dyn controlava a resiliência no nível do provedor e as comunicações. Os clientes controlavam a diversificação do provedor DNS e o planejamento de continuidade. Os fabricantes 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 na medida em que os produtos permitiam.

ISPs e empresas de segurança controlavam escolhas de detecção, notificação e mitigação. Governos controlavam incentivos, padrões, resposta policial e coordenação público-privada.

O incidente se enquadra na análise de responsabilidade porque nenhuma camada poderia sozinha remediar toda a falha. Um cliente perfeito com DNS multiprovedor ainda poderia sofrer com um botnet massivo em outra parte de sua pilha. Uma linha de produtos IoT bem projetada 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 nasceu da montagem dessas camadas.

O sinal do mercado após o 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 desempenho na Internet e DNS baseado em nuvem, afirmou que sua rede impulsionava 40 bilhões de decisões de otimização de tráfego por dia para mais de 3.500 empresas clientes e citou clientes como Netflix, Twitter, Pfizer e CNBC. A aquisição não deve ser interpretada como consequência do ataque sem evidência; o comunicado não indicava isso. Continua sendo um contexto útil para o papel de mercado da Dyn. Não era um serviço de nicho ou amador. Era uma plataforma importante de DNS gerenciado para empresas digitais de destaque.

É essa posição no mercado que faz o incidente importar ainda hoje. A concentração em nuvem frequentemente produz benefícios reais: melhor expertise, alcance global mais amplo, mitigação mais rápida, pessoal especializado e economias de escala. Também altera o modo de falha. Quando muitos clientes convergem para o mesmo provedor, suas declarações independentes de continuidade de negócios podem se tornar correlacionadas. Uma plataforma pode terceirizar uma função e ainda assim ser proprietária das consequências da arquitetura de terceirização.

O relatório de 2018 do Comércio e Segurança Interna argumentava que os incentivos de mercado estavam desalinhados para a resiliência contra botnets. Um problema de incentivo semelhante existia no lado dos clientes de DNS gerenciado. DNS de provedor único é mais simples de comprar, configurar, monitorar e suportar. DNS multiprovedor reduz o risco de modo comum, mas aumenta a complexidade de engenharia e o risco de má configuração. O cliente que evita essa complexidade pode nunca ser penalizado em tempos normais. A penalidade só aparece quando um provedor falha sob pressão, e nesse momento muitos clientes podem sofrer o mesmo evento juntos.

Testes práticos de responsabilidade

O case Dyn oferece aos líderes vários testes que continuam úteis.

Dependência de DNS autoritativo:Qual provedor responde por cada domínio e subdomínio crítico? Todos os servidores de nomes 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 ficar inacessível a partir de uma região importante?

Independência de provedor:Existe um segundo provedor de DNS autoritativo com dados de zona atualizados? Se sim, ele é verdadeiramente independente em termos de rede, plano de controle, credenciais, caminho de suporte e mitigação 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 entre agilidade e tolerância a falhas? Os registros mais estáveis têm tempo de vida de cache suficiente para reduzir a dependência evitável de resoluções autoritativas frequentes durante problemas transitórios no provedor?

DNSSEC e controle de alterações:Se o DNSSEC estiver ativado, as assinaturas, chaves e registros DS podem sobreviver a uma operação multiprovedor ou a uma mudança emergencial de provedor? Se não, a reversão pode falhar de forma segura, o que ainda significa que os usuários não conseguem acessar o serviço.

Monitoramento:A organização consegue distinguir uma 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 alteração de delegação estão documentados, protegidos e disponíveis durante um incidente? Um provedor DNS de backup não é útil se ninguém puder alterar a delegação com segurança.

Comunicações com o provedor:O provedor de DNS gerenciado fornece detalhes de status no nível necessário para que os clientes tomem 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 buscam ajuda ao mesmo tempo?

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

Esses testes não são sobre pureza de engenharia abstrata. Eles permitem que o proprietário de um domínio descubra se "temos servidores de nomes redundantes" significa independência real de falhas ou apenas múltiplos nomes de host dentro de uma dependência de um único provedor.

A lição duradoura

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

O Mirai também não provou que a IoT de consumo pode ser a única responsável por toda falha de infraestrutura. Provou que dispositivos de borda não seguros podem ser agregados em uma força grande o suficiente para ameaçar serviços centrais. Os lares e empresas que possuíam esses dispositivos não tinham a intenção de atacar a Dyn. Os fornecedores desses dispositivos podem não ter imaginado seus produtos como elementos da infraestrutura da Internet. Mas a Internet pública os tornou entidades de qualquer forma.

A memória responsável do incidente Dyn deve, portanto, ser estratificada. Atores criminosos lançaram ataques. A Dyn defendeu uma plataforma DNS de alto valor sob tráfego hostil extremo, ao mesmo tempo que sofreu interrupção com impacto nos clientes. Muitos clientes dependiam de um único provedor para DNS autoritativo e descobriram que múltiplos servidores de nomes nem sempre significam diversidade de provedores. Fabricantes de IoT e proprietários de dispositivos permitiram que dispositivos fracos se tornassem recursos de ataque.

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

A lição prática é brutal: a acessibilidade depende do plano de controle, por mais entediante que seja. Uma empresa pode construir servidores de aplicação redundantes, múltiplas nuvens, regiões ativo-ativo e uma resposta sofisticada a incidentes, e então desaparecer dos navegadores dos usuários se sua dependência de DNS autoritativo repousar sobre um único provedor inacessível. A delegação de DNS é um poder. Tratá-la como um mero item de compra de baixo risco é como um serviço gerenciado se torna uma falha de modo comum.