DNSSEC - Antes tarde do que nunca

[ Update 22/03/2014 ]

Três anos depois, parece que o "nunca" ganhou do "antes tarde"?

DNSSEC Has Failed

O autor do artigo acima tem razão em alguns pontos, especialmente o que tange a complexidade da implementação adequada do DNSSEC ("To enable DNSSEC we have a “tutorial” by Olaf Kolkman which spans a whopping sixty-nine pages. DNS engineers can get trainings, which always take multiple days.")

[ Update 20/11/2011 ]

Seguem alguns sites que podem ser usados para verificar o status de implementações de DNSSEC (incluindo delegações / cadeia de autenticações / etc.. )

1. Sandia Laboratories: http://dnsviz.net/
2. IIS.SE: http://dnscheck.iis.se
3. Verisign: http://dnssec-debugger.verisignlabs.com/

[ Update: 31/05/2010 ]

Atenção administradores de DNS Recursivos brasileiros - reproduzo abaixo informações de configuração DNSSEC postadas no GTS por Frederico Neves do registro.br incluindo a nova KSK key da zona .br:

Senhores(as),

Conforme a nossa "Política de publicação e administração de chaves DNSSEC" [1], desde 31/05/2010 estamos utilizando uma nova chave KSK para a zona .br. A nova chave com key id 41674 juntamente com exemplos de configuração para BIND e UNBOUND pode ser obtida abaixo [3] ou em nosso site [2].

A chave em uso desde 24/06/2008, com key id 18457, deixará de ser utilizada a partir de 26/07/2010.

Se você administra servidores DNS recursivos que estejam com DNSSEC habilitado, não se esqueça de atualizar a chave do .br na configuração de seu servidor. A substituição da chave ancorada em seu servidor DNS pela nova KSK do .br deve ser feita antes do final do período de rollover, que se encerra em 26/07/2010.

É esperado que este seja o último rollover manual uma vez que a raiz será assinada em breve e as próximas trocas de chaves serão efetuadas de forma automática.

Atenciosamente,
Frederico Neves

[1] http://registro.br/info/dnssec-policy.html
[2] https://registro.br/ksk/index.html
[3]
*DNS RR
br. IN DNSKEY 257 3 5 (
AwEAAblaEaapG4inrQASY3HzwXwBaRSy5mkj7mZ30F+h
uI7zL8g0U7dv7ufnSEQUlsC57OHoTBza+TQIv/mgQed8
Fy4XGCGzYiHSYVYvGO9iWG3O0voBYy/zv0z7ANfrA7Z3
lY51CI6m/qoZUcDlNM0yTcJgilaKwUkLBHMAp9NJPuKV
t8A7OHab00r2RDEVjiLWIIuTbz74gCXOVfAmvW07c8c=
) ; key id = 41674


*BIND trusted-keys config
trusted-keys {
br. 257 3 5
"AwEAAblaEaapG4inrQASY3HzwXwBaRSy5mkj7mZ30F+h
uI7zL8g0U7dv7ufnSEQUlsC57OHoTBza+TQIv/mgQed8
Fy4XGCGzYiHSYVYvGO9iWG3O0voBYy/zv0z7ANfrA7Z3
lY51CI6m/qoZUcDlNM0yTcJgilaKwUkLBHMAp9NJPuKV
t8A7OHab00r2RDEVjiLWIIuTbz74gCXOVfAmvW07c8c=";
};


*UNBOUND trust-anchor config
trust-anchor: "br. DS 41674 5 1 EAA0978F38879DB70A53F9FF1ACF21D046A98B5C"

[ Update: 06/05/2010 ]

A mudança de chave para o DNSSEC do último dos 13 root DNS servers foi ontem. A partir de agora todos respondem com uma versão assinada da root zone. A validação das assinaturas ainda não é possível pois as chaves públicas só serão disponibilizadas durante uma cerimônia (txt ICANN) em julho desde ano.

Mais informações:

http://www.h-online.com/security/news/item/DNSSEC-on-all-root-servers-994744.html

Posts Relacionados:

• Root DNS, CA e AS - uma questão de (des)confiança
• (mais uma) Falha no protocolo DNS descoberta
• Telefônica sofre ataques de negação de serviço (DDOS)
• Trojan DNSChanger - v4

[ Post Original: 21/01/2010 ]

Na próxima semana a Verisign iniciará a configuração do DNSSEC para os domínios .com e .net (2 root servers). O processo envolverá inicialmente todas as empresas e entidades responsáveis pelos 13 root servers e esta fase inicial deve durar até julho deste ano.

O DNS - Domain Name Service - (udp/tcp 53) é um dos protocolos mais importantes da Internet - por ser responsável por resolver os endereços IP aos quais os computadores devem se conectar, a partir de um banco de dados distribuído. É ele que permite que você somente precise se lembrar de nomes simples para acessar utilizar a internet (www.google.com - em vez de 72.24.204.99 ou 2001:4860:0:1001::68 para ipv6).

As RFCs 282 e 283 definiram a implementação DNS em 1982, e depois várias outras detalharam ou alteraram especificações relacionados ao protocolo e/ou serviço DNS - e podem ser verificadas no seguinte link: http://www.dns.net/dnsrd/rfc/.

Num exemplo claro de que as mudanças nem sempre são rápidas quando se trata de segurança - o DNSSEC foi primeiramente proposto em 1997, na RFC 2065.

Em resumo, as extensões DNSSEC oferecem 3 novos record types que trazem mais segurança ao protocolo e indiretamente aos serviços da internet e à sua navegação:

1) processo de distribuição de chaves (KEY/DNSKEY),

2) a certificação da origem de dados (SIG/RRSIG) e,

3) a certificação de transações e requisições (NXT/NSEC).

Ou seja, o DNSSEC pretende proteger a integridade dos dados DNS e garantir que as informações estão vindo da origem correta:

1) os domínios da internet podem se assegurar que eles que somente eles são os responsáveis pelas informações de resolução dos sites que possuem, e

2) usuários - que ao navegar automaticamente fazem resoluções DNS - podem verificar que o resultado obtido veio de uma origem confiável.

Por estes motivos, o DNSSEC é considerada a melhor solução para melhorar a segurança deste serviço fundamental e eliminar o problema de envenenamento de caches DNS (DNS cache Poisoning) - que como sabemos é um ataque muito comum e efetivo hoje.

Em 2007, eu tive a oportunidade de revisar um paper publicado pelo CERT.BR que trata entre outras coisas - de DNS Poisoning - segue o link: http://www.cert.br/docs/whitepapers/dns-recursivo-aberto/.

Além disto publicamos em 2008 uma série de updates sobre a falha descoberta por Dan Kaminski que facilita as explorações de DNS Poisoning utilizando birthday attack. (desde então ele faz uma campanha defendendo a adoção do DNSSEC).

Os efeitos de ataques em servidores DNS são inúmeros, incluindo:

1) Ataque de Negação de Serviço Abusando de Servidores DNS Recursivos Abertos - detalhes aqui.

2) "falso-deface": pois o usuário ao digitar o endereço do site - e resolver o endereço IP no servidor DNS que sofreu o envenenamento - será redirecionado para outro servidor sobre controle do hacker (como foi o caso do Twitter no final de 2009)

3) golpes de phishing em massa ( ou pharming ): ou seja, sem utilização de código malicioso no cliente, que tem o seu servidor de DNS envenenado redirecionando sites de instituições financeiras para outro endereço IP - controlado pelo hacker - era muito comum no Brasil de 2002 a 2005 e ainda é existente por aqui e pelo mundo.

Com relação ao DNSSEC, sabemos que este tipo de alteração em um serviço tão fundamental da internet deve idealmente envolver todos os administradores de DNS's.

Quem já cansou de esperar por 13 anos - desde a primeira RFC que tratou do assunto - pode estar entre os "early adopters" ou - é claro - esperar mais 6 meses - quando todos os root servers estarão OK - para iniciar o trabalho de assinar as zonas, e gerenciar as chaves criptográficas envolvidas nas comunicações entre os resolvers e os servers.

Os passos naturais para tanto são: geração das chaves criptográficas (pública e privada), update do arquivo de zona, configuração de resolver c/ forwarding, publicação da zona e verificação da nova zona assinada.

A tendência natural é que grandes sites adotem o DNSSEC mais rapidamente, para garantir uma maior segurança para eles próprios e para os seus usuários.

Mais informações:

Para acompanhar a evolução da adoção do DNSSEC pelos root servers, acesse http://www.root-dnssec.org/. Para detalhamentos técnicos, visite a seção de documentos:

Este é o timeline previsto:

• December 1, 2009: Root zone signed for internal use by VeriSign and ICANN. ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.
• January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.
• Early May, 2010: All root servers are now serving the DURZ. The effects of the larger responses from the signed root, if any, would now be encountered.
• May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.
• July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.

É claro que sobra muito espaço ainda para melhoria no DNSSEC e algumas questões precisam ser mais bem trabalhadas, como ataques "Man-in-the-middle" com spoofing, a questão da necessidade de se confiar no resolver, ataques de negação de serviço e dados não encriptados, por exemplo.

Obviamente as preocupações tradicionais de segurança continuam valendo para o DNSSEC - e as principais são manter o serviço instalado de forma adequada e no último patch level possível.

Recentemente foi divulgada uma falha na implementação do DNSSEC pelo BIND (advisory aqui) - que já foi corrigida. As versões atualmente recomendas são: 9.4.3-P5, 9.5.2-P2 or 9.6.1-P3.

Uma excelente discussão e o status da implementação do DNSSEC no Brasil dado pelo Frederico A C Neves do Registro.BR você pode verificar neste vídeo "DNSCurve X DNSSEC" - do FISL 10 (Obrigado Zucco pela dica nos comentários!).