Complexidades e Considerações sobre o DNSSEC

O DNS é dividido em partes menores chamadas zonas. Uma zona normalmente começa em um nome de domínio e contém todos os registros pertencentes aos subdomínios. Cada zona é gerenciada por um único gerente. Por exemplo, cloudflare.com é uma zona que contém todos os registros de DNS para cloudflare.com e seus subdomínios (por exemplo www.cloudflare.com, api.cloudflare.com).

Não há serviço de diretório para subdomínios no DNS, então se você quiser saber se api.cloudflare.com existe, você tem que perguntar a um servidor DNS e esse servidor DNS acabará perguntando ao cloudflare.com se api.cloudflare.com existe. Isto não é verdade com o DNSSEC. Em alguns casos, a habilitação do DNSSEC pode expor o conteúdo da zona de outro modo obscurecido. Nem todos se preocupam com o sigilo dos subdomínios e o conteúdo da zona pode ser facilmente adivinhado porque a maioria dos sites tem um subdomínio "www"; no entanto, os subdomínios são às vezes usados como portais de login ou outros serviços que o proprietário do site quer manter privados. O proprietário de um site pode não querer revelar que o "secretbackdoor.example.com" existe a fim de proteger aquele local contra os invasores.

A razão pela qual o DNSSEC pode expor subdomínios tem a ver com a forma como as zonas são assinadas. Historicamente, o DNSSEC é usado para assinar zonas estáticas. Uma zona estática é um conjunto completo de registros para um determinado domínio. Os registros de assinatura do DNSSEC são criados usando a Chave de Assinatura de Chave (KSK) e a Chave de Assinatura de Zona (ZSK) em um local central e enviados ao servidor autoritativo para serem publicados. Esse conjunto de registros permite que um servidor autoritativo responda a qualquer pergunta que seja feita, incluindo perguntas sobre subdomínios que não existem.

Ao contrário do DNS padrão, onde o servidor retorna uma resposta NXDOMAIN (Domínio Não Existente) não assinada quando um subdomínio não existe, o DNSSEC garante que todas as respostas sejam assinadas. Isto é feito com um registro especial que serve como prova de inexistência chamado registro NextSECure (NSEC). Um registro NSEC pode ser usado para dizer: "não há subdomínios entre os subdomínios X e Y". Ao preencher a lacuna entre cada domínio da zona, o NSEC fornece uma maneira de responder a qualquer consulta com um registro estático. O registro NSEC também lista os tipos de registros de recursos existentes em cada nome.

Para zonas assinadas estaticamente, há, por definição, um número fixo de registros. Como cada registro NSEC aponta para o próximo, isto resulta em um "anel" finito de registros NSEC que cobre todos os subdomínios. Qualquer pessoa pode "andar" por uma zona seguindo um registro NSEC até conhecer todos os subdomínios. Este método pode ser usado para revelar todos os nomes naquela zona---expondo, possivelmente, informações internas.

Suponha que exista uma zona habilitada para DNSSEC chamada "example.com", com subdomínios "public.example.com" e "secret.example.com". A adição de registros NSEC revelará a existência de todos os subdomínios.

Pedir o registro NSEC de example.com fornece o seguinte:

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

Pedir public.example.com fornece o seguinte registro NSEC:

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

Pedir secret.example.com fornece o seguinte registro NSEC:

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

O primeiro é para a zona top/apex e diz que o nome "example.com" existe e o próximo nome é "public.example.com". O registro public.example.com diz que o próximo nome é "secret.example.com". revelando a existência de um subdomínio privado. O "secret.example.com" diz que o próximo registro é "example.com", completando a cadeia de subdomínios. Portanto, com algumas consultas, qualquer pessoa pode conhecer o conjunto completo de registros da zona.

Tecnicamente, os registros de DNS não deveriam ser secretos, mas na prática, às vezes são considerados como tal. Os subdomínios têm sido usados para manter as coisas (como uma página de login corporativa) privadas por um tempo e, de repente, revelar o conteúdo do arquivo de zona pode ser inesperado e pouco apreciado.

Antes do DNSSEC, a única maneira de descobrir o conteúdo dos nomes em uma zona era consultá-los ou tentar realizar uma transferência da zona de um dos servidores autoritativos. As transferências de zona (AXFR) são frequentemente bloqueadas. A alternativa do NSEC, NSEC3, foi introduzida para combater as preocupações com a enumeração de zonas, mas mesmo o NSEC3 pode ser usado para revelar a existência de subdomínios.

A maioiria dos domínios com .ch usa NSEC3

O registro NSEC3 é como um registro NSEC, mas, em vez de um intervalo assinado de nomes de domínio para os quais não há respostas para a pergunta, o NSEC3 fornece um intervalo assinado de hashes de nomes de domínio. Isso foi feito para evitar a enumeração de zona. Assim, a cadeia NSEC3 para uma zona contendo “example.com” e “www.example.com” poderia ser (cada registro NSEC3 está em 3 linhas para maior clareza):

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Onde

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

A primeira linha do registro NSEC3 contém o “nome” da zona após o hash, o número de rodadas de hash e o salt usado no hash são os dois últimos parâmetros na primeira linha “3 ABCDEF”. O “1 0” significa algoritmo de resumo (1 significa SHA-1) e se a zona usa Opt-out (0 significa não). A segunda linha é o “próximo nome com hash na zona”, a terceira linha lista os tipos no nome. Você pode ver que o “próximo nome” no primeiro registro NSEC3 corresponde ao nome no segundo registro NSEC3 e o “próximo nome” naquele completa a cadeia.

Para a enumeração de NSEC, você pode criar a lista completa de domínios começando a adivinhar os nomes possíveis no domínio. Se a zona tiver cerca de 100 nomes de domínio, serão necessárias cerca de 100 solicitações para enumerar toda a zona. Com o NSEC3, quando você solicita um registro que não existe, um registro NSEC3 assinado é retornado com a próxima zona presente ordenada alfabeticamente por hash. Verificar se o próximo candidato a nome de consulta se encaixa em uma das lacunas conhecidas permite que qualquer pessoa descubra a cadeia completa em cerca de 100 consultas. Existem muitas ferramentas que podem fazer esse cálculo para você, incluindo um plug-in para nmap

Com os hashes que correspondem a todos os nomes válidos na zona, um ataque de dicionário pode ser usado para descobrir os nomes reais. Nomes curtos são facilmente adivinhados e, usando um dicionário, nomes mais longos podem ser revelados como existentes sem ter que inundar os nameservers autoritativos com suposições. Ferramentas como HashCat tornam isso fácil de fazer em software e a popularidade do bitcoin baixou drasticamente o preço do hardware específico para hashing. Há uma crescente indústria caseira de dispositivos construídos para computar hashes criptográficos. O cracker Tesla Password (abaixo) é apenas um exemplo destes dispositivos prontos para uso.

The Teslsa Cracker

Como o hash é barato, a privacidade da zona é apenas ligeiramente melhorada ao usar o NSEC3 conforme projetado; a quantidade de proteção que um nome recebe é proporcional à sua impossibilidade de adivinhação. Resumindo, NSEC é como revelar senhas de texto simples e NSEC3 é como revelar um arquivo de senhas no estilo Unix. Nenhuma das técnicas é muito segura. Com o NSEC3, um subdomínio é tão privado quanto difícil de adivinhar.

Esta vulnerabilidade pode ser atenuada por uma técnica introduzida nos RFCs 4470 e 4471 (https://tools.ietf.org/html/rfc4470 e https://tools.ietf.org/html/rfc4471) chamadas “mentiras brancas do DNSSEC”; isso foi implementado por Dan Kaminsky para fins de demonstração. Quando uma solicitação chega para um domínio que não está presente, em vez de fornecer um registro NSEC3 do próximo domínio real, um registro NSEC3 do próximo hash é apresentado em ordem alfabética. Isso não quebra a garantia do NSEC3 de que não há domínios cujo hash se ajuste lexicograficamente entre a resposta do NSEC3 e a pergunta.

Você só pode implementar “mentiras brancas” de NSEC3 ou NSEC se as assinaturas puderem ser computadas em tempo real em resposta a perguntas. Tradicionalmente, os registros de zona estática para resolução de DNS são criados off-line e todos os registros com assinaturas são armazenados em um arquivo de zona. Este arquivo é então lido por um servidor DNS ativo, permitindo que ele responda a perguntas sobre a zona.

A implementação de DNSSEC da Cloudflare aproveita a geração eficiente de assinaturas do ECDSA para assinar registros DNSSEC em tempo real.

O DNSSEC foi projetado para operar em vários modos, cada um oferecendo diferentes compensações de segurança, desempenho e conveniência. A assinatura ao vivo resolve o problema de exposição do conteúdo da zona em troca de um gerenciamento de chaves menos seguro.

O modo DNSSEC mais comum é a assinatura off-line de zonas estáticas. Isso permite que o sistema de assinatura seja altamente protegido contra ameaças externas, mantendo as chaves privadas em uma máquina que não esteja conectada à rede. Esse modelo operacional funciona bem quando as informações de DNS não mudam com frequência.

Outro modo de operação comum é a assinatura on-line centralizada. Se você assinar dados em acesso restrito, sistemas de assinatura de DNS dedicados, isso permitirá que os dados de DNS sejam alterados e publicados rapidamente. Alguns operadores executam a assinatura de DNS em seus principais servidores DNS. Assim como a assinatura off-line de zonas estáticas, esse modo segue o modelo de assinatura central, ou seja, um assinante central único (ou replicado) faz toda a assinatura e os dados são propagados a partir dele para os servidores DNS autoritativos reais.

Um modo mais radical é permitir que os servidores DNS autoritativos reais assinem dados em tempo real quando necessário, isso permite uma série de novos recursos, incluindo informações geograficamente dependentes assinadas onde a resposta é gerada. A desvantagem é que agora o material de digitação está em muitas máquinas diferentes que têm acesso direto à internet. A assinatura ao vivo na borda apresenta novos problemas, como distribuição de chaves e impõe requisitos extras de computação nos nós.

Recentemente, foi encontrado um bug conhecido como Heartbleed que abriu uma grande falha de segurança em aplicativos de servidor. Foi causado por um erro de codificação no OpenSSL que criou uma vulnerabilidade de divulgação de memória remota. Esse bug permitiu que invasores remotos extraíssem chaves criptográficas de servidores voltados para a internet. O bug de exposição de memória remota é apenas uma das muitas ameaças à segurança de chave privada quando a chave está sendo usada em um processo ativo, como assinatura dinâmica de DNSSEC. Quanto mais uma máquina é exposta à internet, mais vetores de ataque existem. As máquinas de assinatura off-line têm uma janela muito menor de exposição a essas ameaças.

Uma maneira de manter as chaves seguras é usar uma solução com suporte de hardware, como um Módulo de Segurança de Hardware (HSM). A principal desvantagem disso é o custo – os HSMs são muito caros (e lentos). Este é um dos pontos mais difíceis para a execução de servidores DNS que estão espalhados geograficamente para estarem próximos de seus clientes. A execução de um HSM em cada local de servidor pode não apenas ser cara, mas também pode haver complicações legais.

Outra solução para proteger as chaves da divulgação remota é descarregar as operações criptográficas em um componente confiável do sistema. É aqui que pode ser útil ter um servidor DNS personalizado que possa descarregar a criptografia.

O gerenciamento de chaves para DNSSEC é semelhante ao gerenciamento de chaves para TLS e apresenta desafios semelhantes. No início deste ano, introduzimos o Keyless SSL para ajudar a melhorar a segurança de chaves para TLS. Estamos procurando estender o Keyless SSL para fornecer as vantagens de servidores de chave remotos para assinatura ao vivo de DNSSEC.

Os operadores que executam um servidor DNS autoritativo geralmente ficam nervosos com o fato de que seu servidor será usado como um canal para ataques de negação de serviço distribuída (DDoS) maliciosos. Isso decorre do fato de que o DNS usa UDP, um protocolo sem estado.

No TCP, cada conexão começa com um handshake de três vias. Isso garante que o endereço de IP de ambas as partes seja conhecido e correto antes de iniciar uma conexão. No UDP, não existe esse handshake: as mensagens são apenas enviadas diretamente para um IP com um endereço de IP "de" não verificado. Se um invasor puder criar um pacote UDP que diga "oi, do IP X" para um servidor, o servidor normalmente responderá enviando um pacote UDP para X. Escolher X como o endereço de IP da vítima em vez do remetente é chamado de "falsificação" de UDP. Ao falsificar uma vítima, um invasor pode fazer com que um servidor que responde a solicitações UDP inunde a vítima com tráfego "refletido". Isso se aplica tanto a servidores autoritativos quanto a resolvedores recursivos abertos.

O DNSSEC também funciona sobre UDP e as respostas às consultas de DNS podem ser muito longas, contendo vários registros DNSKEY e RRSIG. Este é um alvo atraente para os invasores, pois permite que eles "amplifiquem" seus ataques de reflexão. Se um pequeno volume de solicitações de DNSSEC UDP falsificadas for enviado para nameservers, a vítima receberá um grande volume de tráfego refletido. Às vezes, isso é suficiente para sobrecarregar o servidor da vítima e causar uma negação de serviço.

A solicitação de um TLD que não existe de um servidor raiz retorna uma resposta de cerca de 100 bytes, a resposta assinada para a mesma pergunta é de cerca de 650 bytes ou um fator de amplificação de 6,5. A raiz é assinada usando uma chave RSA de 1.024 bits e usa NSEC para respostas negativas. Solicitar um domínio que não existe em um TLD usando NSEC3 assinado com chave de 1.024 bits resultará em um fator de amplificação em torno de 10. Existem outras consultas que podem gerar fatores de amplificação ainda maiores, sendo a mais eficaz a consulta “ANY”.

Como muitos serviços, o DNS também pode funcionar sobre TCP. Há um sinalizador de "truncamento" que pode ser enviado de volta a um resolvedor para indicar que o TCP é necessário. Isso resolveria o problema de reflexão de DNS ao custo de solicitações de DNS mais lentas. Esta solução não é prática no momento, pois 16% dos resolvedores não respeitam o sinalizador de truncamento TCP e 4% não tentam um segundo servidor.

Outra opção para reduzir o tamanho das respostas é usar chaves Elliptic Curve Digital Signature Algorithm (ECDSA) em vez de chaves RSA tradicionais. As chaves ECDSA são muito menores que as chaves RSA de força equivalente e produzem assinaturas menores tornando as respostas DNSSEC muito menores, reduzindo o fator de amplificação. O DNS público do Google adicionou suporte ao ECDSA no final de 2014 e vários outros seguiram o exemplo desde então.

O suporte para TCP e ECDSA ainda está atrasado em relação ao suporte geral ao DNSSEC, portanto, métodos antiabuso tradicionais podem ser usados. Isso inclui Limitação de Taxa de Recursos (RRL) e outras heurísticas.

Para se proteger contra ataques de reflexão, a Cloudflare está trabalhando em uma abordagem multifacetada. Primeiro, usando heurísticas de identificação de ataques e técnicas antiabuso que estamos usando atualmente em nosso servidor DNS e, segundo, reduzindo o fator de amplificação das respostas DNSSEC. As formas de reduzir o fator de amplificação máximo incluem apenas responder a solicitações “ANY” sobre TCP, usando chaves ECDSA menores quando possível e reduzindo a frequência de key rollovers.

A Cloudflare está ciente da complexidade introduzida pelo DNSSEC em relação à privacidade da zona, gerenciamento de chaves e risco de reflexão/amplificação. Com decisões inteligentes de engenharia e controles operacionais implementados, os perigos do DNSSEC podem ser evitados.