Benefícios de segurança

Introdução: ameaças e mitigações de segurança de DNS

Devido ao design aberto e distribuído do Sistema de Nomes de Domínio e ao uso do Protocolo de Datagramas do Usuário (UDP), o DNS é vulnerável a várias formas de ataque. Os resolvedores DNS públicos ou "abertos" são especialmente arriscados, porque não restringem os pacotes de entrada a um conjunto de endereços IP de origem permitidos. Estamos preocupados principalmente com dois tipos comuns de ataque:

• Ataques de spoofing que levam ao envenenamento de cache do DNS. Há vários tipos de spoofing de falsificações de DNS e falsificações, com o objetivo de redirecionar os usuários de sites legítimos para sites maliciosos. Isso inclui os chamados ataques do Kaminsky, em que os invasores assumem o controle autoritativo de toda a zona de DNS.
• Ataques de negação de serviço (DoS). Os invasores podem iniciar ataques DDoS contra os próprios resolvedores ou invadir resolvedores para lançar ataques de DoS em outros sistemas. Os ataques que usam servidores DNS para iniciar ataques DoS em outros sistemas ao explorar um tamanho grande de registros/respostas DNS são conhecidos como ataques de amplificação.

Veja abaixo mais detalhes sobre cada classe de ataque.

Ataques de envenenamento de cache

Existem várias variantes de ataques de spoofing de DNS que podem resultar em intoxicação de cache, mas o cenário geral é o seguinte:

1. O invasor envia várias consultas do resolvedor de DNS de destino para um nome de domínio em que sabe que o servidor não é confiável, e é improvável que esteja no cache do servidor.
2. O resolvedor envia solicitações a outros servidores de nomes com os endereços IP que o invasor também consegue prever.
3. Enquanto isso, o invasor inunda o servidor da vítima com respostas falsificadas que parecem ser originadas do servidor de nomes delegado. As respostas contêm registros que, por fim, resolvem o domínio solicitado para os endereços IP controlados pelo invasor. Elas podem conter registros de resposta do nome resolvido ou, pior ainda, delegar mais autoridade a um servidor de nomes do invasor para que ele assuma o controle de uma zona inteira.
4. Se uma das respostas falsificadas corresponder à solicitação do resolvedor (por exemplo, por nome, tipo, ID e porta de origem do resolvedor) e for recebida antes de uma resposta do servidor de nomes genuíno, o resolvedor aceitará a resposta falsa e a armazenará em cache e descartará a resposta genuína.
5. Consultas futuras para a zona ou o domínio comprometido são respondidas com as resoluções de DNS falsificadas do cache. Se o invasor especificar uma vida útil longa na resposta falsa, os registros falsificados permanecerão no cache pelo maior tempo possível sem serem atualizados.

Para uma excelente introdução aos ataques do Kaminsky, consulte Um guia ilustrado sobre a vulnerabilidade de DNS do Kaminsky (em inglês).

Ataques de DoS e amplificação

Os resolvedores de DNS estão sujeitos às ameaças frequentes de DoS que assolam qualquer sistema em rede. No entanto, os ataques de amplificação são preocupantes, porque os resolvedores de DNS são alvos atrativos para invasores que exploram os resolvedores' grande proporção de tamanho de respostas a solicitações para ganhar mais largura de banda livre. Os resolvedores compatíveis com EDNS0 (mecanismos de extensão para DNS) são especialmente vulneráveis devido ao tamanho do pacote substancialmente maior que eles podem retornar.

Em um cenário de amplificação, o ataque continua da seguinte maneira:

1. O invasor envia consultas ao servidor DNS para uma vítima usando um endereço IP de origem falsificado. As consultas podem ser enviadas de um único sistema ou de uma rede de sistemas com o mesmo endereço IP forjado. As consultas são de registros que o invasor sabe que resultarão em respostas muito maiores, até várias dezenas de vezes¹ do tamanho das consultas originais, por isso o nome "amplificação" ataque.
2. O servidor da vítima envia as respostas grandes ao endereço IP de origem transmitido nas solicitações falsificadas, sobrecarregando o sistema e causando uma situação de DoS.

Mitigações

A solução padrão para vulnerabilidades de DNS em todo o sistema é a DNSSEC. No entanto, até que seja implementado universalmente, os resolvedores de DNS abertos precisam adotar algumas medidas de maneira independente para reduzir as ameaças conhecidas. Muitas técnicas foram propostas. Consulte IETF RFC 5452: medidas para tornar o DNS mais resiliente contra respostas falsificadas para ter uma visão geral da maioria delas. No DNS público do Google, implementamos e recomendamos as seguintes abordagens:

• Proteger o código contra estouros de buffer, especialmente o código responsável por analisar e serializar mensagens DNS.
• Provisionamento excessivo de recursos da máquina para proteger contra ataques diretos de DoS nos próprios resolvedores. Como os endereços IP são comuns em invasores, é impossível bloquear consultas com base em endereços IP ou sub-redes. A única maneira eficaz de lidar com esses ataques é absorver a carga.
• Implementação de verificação básica da validade de pacotes de resposta e de credibilidade do servidor de nomes para proteger contra envenenamento simples de cache. Esses são os mecanismos padrão e as verificações de integridade que precisam ser realizados por qualquer resolvedor de armazenamento em cache que esteja em conformidade com os padrões.
• Adicionar entropia para solicitar mensagens, para reduzir a probabilidade de ataques de spoofing ou envenenamento de cache mais sofisticados, como ataques do Kaminsky. Há muitas técnicas recomendadas para adicionar entropia. Confira abaixo uma visão geral dos benefícios, limitações e desafios de cada uma dessas técnicas e mostramos como implementá-los no DNS público do Google.
• Remover consultas duplicadas para combater a probabilidade de "ataques de aniversário"
• Solicitações de limitação de taxa para evitar ataques de DoS e amplificação.
• Monitorar o serviço dos IPs do cliente usando a maior largura de banda e aproveitando a proporção mais alta de resposta para solicitação.

DNSSEC

O padrão Extensões de segurança de nome de domínio (DNSSEC) é especificado em várias RFCs da IETF: 4033, 4034, 4035 e 5155.

Resolvedores que implementam ataques de envenenamento de cache de DNSSEC verificando a autenticidade das respostas recebidas de servidores de nomes. Cada zona de DNS mantém um conjunto de pares de chave privada/pública. Para cada registro DNS, uma assinatura digital exclusiva é gerada e criptografada usando a chave privada. Em seguida, a chave pública correspondente é autenticada por uma cadeia de confiança por chaves que pertencem às zonas pai. Os resolvedores em conformidade com as DNSSEC rejeitam respostas que não contêm as assinaturas corretas. As DNSSEC impedem efetivamente que as respostas sejam adulteradas, porque, na prática, é quase impossível falsificar assinaturas sem acesso a chaves privadas.

Desde janeiro de 2013, o DNS público do Google é totalmente compatível com as DNSSEC. Aceitamos e encaminhamos mensagens formatadas nas DNSSEC e validamos respostas para autenticação correta. Recomendamos que outros resolvedores façam o mesmo.

Também armazenamos respostas da NSEC conforme especificado em IETF RFC 8198: uso agressivo de cache validado pelas DNSSEC. Isso pode reduzir as consultas NXDOMAIN a nomear servidores que implementam DNSSEC e usar NSEC para respostas negativas.

Transportes criptografados do lado do cliente

O DNS público do Google é compatível com protocolos de transporte criptografados, DNS via HTTPS e DNS via TLS. Esses protocolos evitam adulteração, espionagem e spoofing, aumentando muito a privacidade e a segurança entre um cliente e o DNS público do Google. Elas complementam as DNSSEC para fornecer buscas DNS autenticadas de ponta a ponta.

Como implementar a verificação básica de validade

Algumas corrupções de cache de DNS podem ser causadas por incompatibilidades não intencionais e não necessariamente maliciosas entre solicitações e respostas, por exemplo, devido a um servidor de nomes configurado incorretamente, um bug no software DNS e assim por diante. No mínimo, os resolvedores de DNS precisam fazer verificações para confirmar a credibilidade e a relevância dos servidores de nomes. Recomendamos (e implementamos) todas as defesas a seguir:

• Não defina o bit recursivo em solicitações de saída e sempre siga explicitamente as cadeias de delegação. Desativar o bit recursivo garante que seu resolvedor opere no modo"iterativo" para que você consulte cada servidor de nomes na cadeia de delegação explicitamente, em vez de permitir que outro servidor de nomes execute essas consultas em seu nome.
• Rejeitar mensagens de resposta suspeitas Veja abaixo detalhes sobre o que consideramos ser "quot;suspenho""
• Não retorne registros A para clientes com base em registros cola armazenados em cache em solicitações anteriores. Por exemplo, se você receber uma consulta de cliente para ns1.example.com, resolva novamente o endereço, em vez de enviar um registro A com base em registros cola armazenados em cache retornados de um servidor de nomes TLD .com.

Rejeitar respostas que não atendem aos critérios obrigatórios

O DNS público do Google rejeita todos os seguintes itens:

• Respostas não analisáveis ou malformadas.
• Respostas em que os campos principais não correspondem aos campos correspondentes na solicitação. Isso inclui o ID da consulta, o IP de origem, a porta de origem, o IP de destino ou o nome da consulta. Consulte a seção 3 da RFC 5452 para ver a descrição completa do comportamento de spoofing de DNS.
• Registros que não são relevantes para a solicitação.
• Registros de resposta para os quais não podemos reconstruir a cadeia CNAME.
• Registros (na seção de resposta, autoridade ou outras) em que o servidor de nomes de resposta não é confiável. Nós determinamos a "credibilidade" de um servidor de nomes pelo seu local na cadeia de delegação de um determinado domínio. O DNS público do Google armazena em cache as informações da cadeia de delegação, e verificamos cada resposta recebida em relação às informações armazenadas em cache para determinar a credibilidade do servidor de nomes de resposta para responder a uma solicitação específica.

Adicionar entropia a solicitações

Depois que um resolvedor aplica verificações básicas de integridade, um invasor precisa inundar o resolvedor vítima com respostas em um esforço para corresponder ao ID da consulta, à porta UDP (da solicitação), ao endereço IP (da resposta) e ao nome da consulta da solicitação original antes do servidor de nomes legítimo.

Isso não é difícil de alcançar, porque o único campo de identificação, o ID da consulta, tem apenas 16 bits (ou seja, para uma chance de 1/65.536 de acertar). Os outros campos também são limitados, o que torna o número total de combinações exclusivas um número relativamente baixo. Consulte a seção 7 da RFC 5452 para ver um cálculo dos combinadores envolvidos.

Portanto, o desafio é adicionar o máximo de entropia ao pacote de solicitações, no formato padrão da mensagem DNS, para dificultar que os invasores correspondam corretamente a uma combinação válida de campos na janela de oportunidade. Recomendamos e implementamos todas as técnicas discutidas nas seções a seguir.

Em julho de 2022, apresentamos uma revisão atualizada das técnicas mencionadas aqui na conferência OARC 38 do DNS. A apresentação também inclui recomendações para operadores de servidor de nomes.

Ordem aleatória de portas de origem

Como etapa básica, nunca permita que pacotes de solicitação de saída usem a porta UDP padrão 53 ou um algoritmo previsível para atribuir várias portas (por exemplo, incremento simples). Use uma maior variedade de portas de 1024 a 65535, conforme permitido no sistema, e use um gerador de números aleatórios confiável para atribuir portas. Por exemplo, o DNS público do Google usa aproximadamente 15 bits para permitir aproximadamente 32.000 números de portas diferentes.

Se os servidores forem implantados por trás de firewalls, balanceadores de carga ou outros dispositivos que fazem conversão de endereços de rede (NAT, na sigla em inglês), esses dispositivos poderão desalear as portas em pacotes de saída. Configure dispositivos NAT para desativar a remoção aleatória de portas.

Escolha aleatória de servidores de nomes

Alguns resolvedores, ao enviar solicitações a servidores raiz, TLD ou outros nomes, selecionam o endereço IP do servidor de nomes com base na menor distância (latência). Recomendamos que você randomize os endereços IP de destino para adicionar entropia às solicitações de saída. No DNS público do Google, simplesmente escolhemos um servidor de nomes aleatoriamente entre os servidores de nomes configurados para cada zona, de certa forma favorecendo servidores de nomes rápidos e confiáveis.

Se você está preocupado com a latência, use o banda de tempo de retorno (RTT, na sigla em inglês), que consiste em randomizar dentro de um intervalo de endereços que estão abaixo de um determinado limite de latência (por exemplo, 30 ms, 300 ms etc.).

Cookies de DNS

A RFC 7873 define uma opção EDNS0 para adicionar cookies de 64 bits a mensagens DNS. Um cookie de DNS compatível com cliente inclui um cookie aleatório de 64 bits e, opcionalmente, um cookie de servidor em uma solicitação. Se um servidor de suporte encontrar a opção de cookie válido em uma solicitação, ele refletirá o cookie de cliente e o de servidor corretos na resposta. O cliente compatível pode verificar a resposta do servidor esperado verificando o cookie do cliente na resposta.

Se um servidor de nomes não for compatível com cookies DNS, as duas opções a seguir poderão ser usadas para adicionar entropia.

Ordem aleatória em nomes de consulta

Os padrões de DNS exigem que os servidores de nomes tratem nomes com diferenciação de maiúsculas e minúsculas. Por exemplo, os nomes example.com e EXAMPLE.COM precisam ser resolvidos com o mesmo endereço IP². Além disso, todas, exceto uma pequena minoria de servidores de nomes, ecoam o nome na resposta, como ele apareceu na solicitação, preservando o caso original.

Portanto, outra maneira de adicionar entropia às solicitações é variar aleatoriamente o uso de letras em nomes de domínio consultados. Essa técnica, também conhecida como "0x20" porque o bit 0x20 é usado para definir o caso de letras ASCII dos EUA, foi proposta primeiro no rascunho da Internet IETF Uso de Bit 0x20 em rótulos DNS para melhorar a identidade da transação. Com essa técnica, a resposta do servidor de nomes precisa corresponder não apenas ao nome da consulta, mas ao caso de cada letra na string, por exemplo, wWw.eXaMpLe.CoM ou WwW.ExamPLe.COm. Isso pode adicionar pouca ou nenhuma entropia às consultas dos domínios raiz e de nível superior, mas é eficaz para a maioria dos nomes de host.

Um desafio significativo que descobrimos ao implementar essa técnica é que alguns servidores de nomes não seguem o comportamento de resposta esperado:

• Alguns servidores de nomes respondem com inconsistência de maiúsculas e minúsculas: eles retornam corretamente os mesmos resultados, independentemente do caso na solicitação, mas a resposta não corresponde ao caso exato do nome na solicitação.
• Outros servidores de nomes respondem com diferenciação completa de maiúsculas e minúsculas (em violação dos padrões DNS): eles processam nomes equivalentes de forma diferente dependendo do caso na solicitação, não respondem nem retornam respostas incorretas de NXDOMAIN que correspondem ao caso exato do nome na solicitação.
• Alguns servidores de nomes funcionam corretamente, exceto para consultas PTR na zona arpa.

Nos dois tipos de servidor de nomes, alterar o caso do nome da consulta resultaria em resultados indesejados: para o primeiro grupo, a resposta seria indistinguível de uma resposta falsa. Já no segundo, a resposta (se houver) pode ser totalmente incorreta.

Nossa solução atual para esse problema é usar a ordem aleatória de casos apenas para servidores de nomes que sabemos aplicar os padrões corretamente. Além disso, listamos os subdomínios de exceção adequados para cada um deles com base na análise dos nossos registros. Se uma resposta que parece vir desses servidores não contiver o caso correto, nós a rejeitaremos. Os servidores de nomes ativados lidam com mais de 70% do nosso tráfego de saída.

Etiquetas de uso único com nomes de consulta anteriores

Se um resolvedor não conseguir resolver diretamente um nome do cache ou não consultar um servidor de nomes autoritativo, ele precisará seguir as referências de um servidor de nomes raiz ou TLD. Na maioria dos casos, as solicitações para os servidores de nomes raiz ou TLD resultam em uma referência a outro servidor de nomes, em vez de uma tentativa de resolver o nome em um endereço IP. Portanto, para essas solicitações, é seguro anexar um rótulo aleatório a um nome de consulta para aumentar a entropia da solicitação, sem arriscar uma falha para resolver um nome inexistente. Ou seja, o envio de uma solicitação a um servidor de nomes de referência para um nome com um valor de uso único, como entriih-f10r3.www.google.com, precisa retornar o mesmo resultado que uma solicitação de www.google.com.

Na prática, essas solicitações compõem menos de 3% das solicitações de saída, supondo que o tráfego normal (já que a maioria das consultas pode ser respondida diretamente do cache ou por uma única consulta), essas são exatamente os tipos de solicitações que um invasor tenta forçar a emissão de um resolvedor. Essa técnica pode ser muito eficaz para evitar invasões no estilo Kaminsky.

Para implementar essa técnica, é necessário usar rótulos de uso único apenas para solicitações com garantia de resultar em referências, ou seja, respostas que não contêm registros na seção de respostas. No entanto, encontramos vários desafios ao tentar definir o conjunto dessas solicitações:

• Alguns servidores de nomes de TLDs (ccTLD, na sigla em inglês) de código de país são autoritativos para outros TLDs de segundo nível (2LDs, na sigla em inglês). Embora tenham dois rótulos, os 2LDs se comportam como TLDs, e é por isso que eles são frequentemente processados pelos servidores de nomes ccTLD. Por exemplo, os servidores de nomes .uk também são autoritativos para as zonas mod.uk e nic.uk e, portanto, nomes do host contidos nessas zonas, como www.nic.uk, www.mod.uk e assim por diante. Em outras palavras, as solicitações a servidores de nomes ccTLD para resolução desses nomes de host não resultarão em referências, mas em respostas autoritativas. A inclusão de rótulos de valor de uso único para esses nomes de host fará com que os nomes não sejam resolvíveis.
• Às vezes, os servidores de nomes genéricos de TLD (gTLD, na sigla em inglês) retornam respostas não confiáveis para servidores de nomes. Ou seja, há alguns nomes de host de servidor de nomes que residem em uma zona gTLD, e não na zona do domínio. Um gTLD retornará uma resposta não autorizada para esses nomes de host, usando qualquer registro cola que tenha no banco de dados, em vez de retornar uma referência. Por exemplo, o servidor de nomes ns3.indexonlineserver.com costumava estar na zona gTLD .COM em vez de na zona indexonlineserver.com. Quando emitimos uma solicitação para um servidor gTLD para n3.indexonlineserver.com, recebemos um endereço IP para ele, em vez de uma referência. No entanto, se incluímos um prefixo de valor de uso único, recebemos uma referência a indexonlineserver.com, que não conseguiu resolver o nome do host. Portanto, não podemos anexar rótulos de valor de uso único para servidores de nomes que exigem uma resolução de um servidor gTLD.
• As autoridades das zonas e dos nomes do host mudam com o tempo. Isso pode fazer com que um nome de host valor de uso único que possa ser resolvido não seja resolvível se a cadeia de delegação mudar.

Para lidar com esses desafios, configuramos exceções para nomes de host para os quais não é possível anexar rótulos de valor de uso único. Esses são nomes de host para os quais servidores de nomes TLDs retornam respostas não referências, de acordo com os registros do servidor. Analisamos continuamente a lista de exceções para garantir que ela permaneça válida ao longo do tempo.

Como remover consultas duplicadas

Os resolvedores de DNS são vulneráveis a "ataques de aniversário", portanto, chamados porque exploram o paradoxo matemático de "birthday", em que a probabilidade de uma correspondência não requer um grande número de entradas. Os ataques de aniversário envolvem inundar o servidor de vítimas não apenas com respostas falsas, mas também com consultas iniciais, contando com o resolvedor para emitir várias solicitações para uma única resolução de nome. Quanto maior o número de solicitações enviadas, maior a probabilidade de o invasor corresponder uma dessas solicitações a uma resposta forjada: um invasor só precisa ter cerca de 300 solicitações em trânsito para ter uma chance de 50% de correspondência em uma resposta forjada e 700 solicitações para quase 100% de sucesso.

Para se proteger contra essa estratégia de ataque, descarte todas as consultas duplicadas da fila de saída. Por exemplo, o DNS público do Google nunca permite mais de uma solicitação pendente para o mesmo nome, tipo e endereço IP de consulta e destino.

Consultas com limitação de taxa

A prevenção de ataques de negação de serviço apresenta vários desafios específicos para resolvedores de DNS recursivos abertos:

• Os resolvedores recursivos abertos são destinos atrativos para lançar ataques de amplificação. Eles são servidores de alta capacidade e alta confiabilidade e podem produzir respostas maiores do que um servidor de nomes autoritativo típico, especialmente se um invasor puder injetar uma grande resposta no cache dele. Todos os desenvolvedores de um serviço de DNS aberto são responsáveis por impedir que os servidores deles sejam usados para iniciar ataques em outros sistemas.
• Ataques de amplificação podem ser difíceis de detectar enquanto ocorrem. Os invasores podem iniciar um ataque por meio de milhares de resolvedores abertos, de modo que cada resolvedor veja apenas uma pequena fração do volume geral da consulta e não possa extrair um sinal claro de que ele foi comprometido.
• O tráfego malicioso precisa ser bloqueado sem interrupções ou degradações do serviço de DNS para os usuários normais. O DNS é um serviço de rede essencial, portanto, desativar servidores para cortar um ataque não é uma opção nem nega o serviço a qualquer IP do cliente por muito tempo. Os resolvedores precisam bloquear rapidamente um ataque assim que ele for iniciado e restaurar o serviço totalmente operacional assim que o ataque terminar.

A melhor abordagem para combater ataques de DoS é impor um mecanismo de limitação de taxa ou de limite. O DNS público do Google implementa dois tipos de controle de taxa:

• Controle de taxa de solicitações enviadas para outros servidores de nomes. Para proteger outros servidores de nomes DNS contra ataques de DoS que podem ser iniciados pelos nossos servidores resolvedores, o Google DNS público impõe limites de QPS em solicitações de saída de cada cluster de exibição para cada endereço IP do servidor de nomes.

• Controle de taxa de respostas enviadas para clientes. Para proteger qualquer outro sistema contra amplificação e ataques de DoS distribuídos (botnet) tradicionais que podem ser iniciados com nossos servidores de resolução, o DNS público do Google executa dois tipos de limitação de taxa em consultas do cliente:

  • Para se proteger contra ataques tradicionais baseados em volume, cada servidor impõe QPS de IP por cliente e limites de largura de banda médios.
  • Para se proteger contra ataques de amplificação, em que grandes respostas a pequenas consultas são exploradas, cada servidor impõe um fator máximo de amplificação médio por cliente-IP. O fator médio de amplificação é uma proporção configurável do tamanho da resposta à consulta, determinado a partir de padrões de tráfego históricos observados nos nossos registros de servidor.

  Se as consultas DNS de um endereço IP de origem excederem a taxa máxima de QPS, o excesso de consultas será descartado. Se as consultas DNS por UDP de um endereço IP de origem excederem a largura de banda média ou o limite de amplificação de forma consistente (a resposta grande ocasional passará), as consultas poderão ser descartadas ou apenas uma pequena resposta poderá ser enviada. Respostas pequenas podem ser uma resposta de erro ou uma resposta vazia com o bit de truncamento definido para que as consultas mais legítimas sejam repetidas via TCP e bem-sucedidas. Nem todos os sistemas ou programas tentarão novamente por TCP. Além disso, talvez o DNS sobre TCP seja bloqueado por firewalls do lado do cliente, por isso alguns aplicativos podem não funcionar corretamente quando as respostas são truncadas. No entanto, o truncamento permite que clientes compatíveis com RFC funcionem corretamente na maioria dos casos.