Um estudo de caso de implantação de DNSSEC em ambiente corporativo multisite

Transcrição

1 ISSN T.I.S. São Carlos, v. 4, n. 2, p , mai-ago 2015 Tecnologias, Infraestrutura e Software Um estudo de caso de implantação de DNSSEC em ambiente corporativo multisite Resumo: Com o crescimento dos serviços baseados na Internet, o serviço de resolução de nomes de domínios (DNS) passou a ser alvo constante de ameaças. Diante disso, como o serviço não previa nenhum tipo de confirmação de que os dados estavam sendo recebidos de um servidor verdadeiro, foram elaboradas pelo IETF extensões de segurança para DNS, intituladas DNSSEC. DNSSEC visa a prover autenticação e integridade das respostas DNS obtidas de um determinado servidor. Este artigo descreve características fundamentais do funcionamento de servidores DNS, de seus registros, e trata de recursos e ferramentas usadas para adoção de DNSSEC em uma zona DNS. Além disso, apresenta um roteiro de implementação das extensões de segurança em um domínio, ressaltando as principais configurações aplicadas nos servidores de DNS, sejam eles autoritativos, escravos ou de encaminhamento. Palavras Chave: Internet, DNS, DNSSEC, Segurança de rede A case study ofdnssec implantation in multi-site corporate environment Abstract: With the growth of Internet-based services, the DNS name resolution server became a constant target of threats. As the service did not foresee any kind of confirmation that the data was being received from a real server, a set of security extensions were drawn up by the IETF for DNS, entitled DNSSEC. DNSSEC aims to provide authentication and integrity for DNS responses from a certain server. This paper describes key features of the operation of DNS servers, of its registers and deals with resources and tools used to adopt DNSSEC in a DNS zone. Moreover, it presents a roadmap for the implementation ofsecurity extensions in a domain, emphasizing the main settings applied on the DNS servers, being them authoritative, slaves or forwarding servers. Keywords: Internet, DNS, DNSSEC, Network Safety I. INTRODUÇÃO Atualmente, os serviços baseados na rede mundial de computadores (Internet) são difundidos e utilizados de maneira exaustiva por milhões de pessoas no mundo. A cada ano cresce o tráfego de dados e a quantidade de informações armazenadas na Internet, ou em infraestruturas de computação em nuvem (GARTNER, 2012). Como os serviços baseados em nuvem são uma tendência que está se elevando cada dia mais, os serviços de Internet são os mais visados por golpes virtuais. Uma das formas de golpes comuns envolve a criação de réplicas de servidores e o redirecionamento dos acessos de usuários de serviços legítimos para essas versões fraudulentas dos serviços. Isso é comumente feito através da tradução indevida das consultas ao sistema de nomes de domínio (DNS Domain Name System ). Departamento de Computação - Universidade Federal de São Carlos (UFSCar) Caixa Postal São Carlos SP Brasil Autor para correspondência: marcelo@padovan.net.br, helio@dc.ufscar.br

2 Desta maneira, o serviço de DNS é visado em ataques, pois é através dos seus serviços que normalmente são obtidos endereços associados aos nomes lógicos de servidores em rede. Domain Name System (DNS), ou Sistema de Nomes de Domínio, é um serviço de Internet que possibilita a identificação lógica de computadores ligados em rede, através da associação de nomes e endereços. Assim, proporciona aos usuários e às aplicações que utilizem nomes para acesso aos serviços disponibilizados na rede, ao invés de requerer o conhecimento dos endereços IP (Internet Protocol). DNS é um sistema hierárquico baseado em bancos de dados distribuídos. Como exemplo poderíamos citar o nome que é uma forma mais intuitiva de se lembrar da referência a um computador, uma vez que se remete logicamente a uma instituição. Por tratar-se de uma referência de nomes hierárquicos é mais fácil memorizar um nome DNS do que um endereço IP associado, como Neste exemplo vê-se a resolução de um endereço de 32bits IPv4, e uma vez que implantado o protocolo IPv6 (128 bits), observase que a associação de endereços como [2001:db8:10:a0:30:b0:50:c10] para acesso ao computador desejado seria ainda mais complexa e impraticável. Segundo Tanenbaum (2010), o objetivo da criação do DNS foi organizar máquinas em domínios e mapear nomes de hosts (computadores ou nós interligados em rede) em endereços IP. Desde então, o DNS se transformou em um sistema de bancos de dados distribuídos, capaz de armazenar uma série de informações referentes à atribuição de nomes e à consulta de outros parâmetros associados a hosts e a domínios lógicos. DNS é usado principalmente para mapear nomes de hosts em endereços IP. Seu protocolo e suas informações de controle são definidos nas RFCs 1034 e 1035, 2181, entre outras. Usando a resolução DNS, a tradução de endereços é feita encaminhando mensagens de consulta para um servidor conhecido. Esse servidor responde diretamente às consultas cujos resultados são mantidos em suas tabelas locais, e pode encaminhar solicitações desconhecidas a outros servidores. Uma restrição deste modo de operação, contudo, é que o protocolo de comunicação entre clientes emissores de consultas e servidores não é autenticado. Com isso, a possibilidade de redirecionamentos de consultas a servidores indevidos é uma ameaça à resolução de endereços. Vista a iminente vulnerabilidade que o serviço DNS apresentava, foi desenvolvida uma forma de validar os registros obtidos com a resolução, identificando se foram adulterados, sendo alvos de envenenamento, quando registros verdadeiros são trocados por falsos, que geralmente levam a páginas falsificadas. Conhecidos como phishing, os golpes que envolvem a personificação de servidores procuram levar o usuário a ter sensação de estar no site correto, enquanto interage com um servidor fraudulento, parcialmente clonado do servidor legítimo. Um usuário dificilmente se atenta a detalhes pequenos como erros de ortografia, ou mesmo verificação da URL completa de um endereço buscado. A forma de verificação de segurança para o sistema DNS provê autenticação das informações obtidas de servidores na tradução de endereços, sendo chamada de DNSSEC. O protocolo e as extensões DNSSEC (Domain Name System Security Extensions Extensões de Segurança para o Sistema de Nomes de Domínio) foram definidos pela RFC2535 do IETF (Internet Engineering Task Force), que foi atualizada com a publicação das RFCs 4033,4034 e Essa extensão foi elaborada para prover integridade dos dados e autenticação segura para os resolvedores de nomes com o uso de chaves criptográficas. Segundo Tanenbaum (2010) DNSSEC oferece serviços, que são: 1) Prova da origem dos dados: função principal do DNSSEC, uma vez que ele verifica se a origem dos dados retornados é confirmada pelo dono do domínio em questão; 2) Distribuição de chave pública: através da propagação de chaves pelo próprio DNS, é possível armazenar e recuperar as chaves públicas de forma segura; 3) Transação e autenticação da requisição: este serviço é necessário para prevenir o sistema contra execução de ataques de falsificação dos registros. Uma vantagem da adoção do DNSSEC nos servidores é que o mesmo não adiciona complexidade significativa para sua implantação, pois todas as ferramentas utilizadas são desenvolvidas em código aberto e estão disponíveis para diversos sistemas operacionais, além de contar com vasta documentação para uso. Os benefícios da adoção do DNSSEC são interessantes, pois o mesmo não implica em perda de compatibilidade com sistemas legados, ou não configurados. DNSSEC provê a segurança confirmação necessária para os clientes que já o utilizam, fornecendo respostas autoritativas e confirmando a origem de respostas recursivas. Além disso, quando um resolvedor não compatível com DNSSEC faz uma requisição para um servidor que já forneça respostas com este formato, não há impedimentos para a operação do protocolo pois a resposta é fornecida no formato suportado pelo cliente. Nesta situação a resposta será enviada sem o suporte das extensões providas pelo DNSSEC. Para ilustrar o funcionamento do DNSSEC, este artigo mostra a implantação das extensões DNSSEC em um sistema DNS já instalado, tratando das configurações e dos ajustes necessários. Os principais conceitos relacionados são apresentados, bem como ferramentas e métodos para assinatura de informações com DNSSEC. Também são abordadas todas as etapas necessárias à implementação do DNSSEC em servidores de nomes de maneira prática, mostrando como gerenciá-los com a menor complexidade, seja um ambiente de pequeno ou grande porte. Como resultado, este artigo deve servir como um guia prático de implantação de DNSSEC, mostrando como são geradas as chaves relacionadas e de que forma um domínio deve ter sua zona assinada e mantida. II. DNS E DNSSEC Antes de tratar da assinatura das informações de zonas DNS com DNSSEC, é importante entender conceitos sobre DNS e 139

3 Um estudo de caso de implantação de DNSSEC em ambiente corporativo multisite conhecer os recursos que o DNSSEC utiliza para seu funcionamento e segurança e os tipos de transferência de informação que podem ser sujeitas à validação de conteúdo. Há diferentes tipos de servidores DNS, como tratado por Aitchison (2011): Primário (Master): é o servidor com autoridade (autoritativo) de uma ou mais zonas DNS; Secundário (Slave): é um servidor com autoridade sobre uma zona, que recebe as informações para seu tratamento explicitamente do servidor master; Recursivo (Caching): é um servidor que faz consultas aos servidores autoritativos (primários ou secundários) e mantém os resultados obtidos localmente para atender a novas consultas sobre aquele domínio, até a expiração do TTL da zona; Servidor de Encaminhamento (Forwarding ou Proxy): é um servidor que encaminha todos os pedidos para outro servidor, mas armazena as respostas obtidas; Oculto (Stealth ): é um servidor que não aparece publicamente nos registros RRs do tipo NS de um domínio; Unicamente Autoritativo (Authoritative-only): trata-se de um servidor que provê apenas respostas autoritativas. Estes servidores são responsáveis pelas Zonas DNS, que definem áreas de mapeamento e de encaminhamento de requisições. Alguns aspectos da resolução DNS, considerando os diferentes tipos de Zona DNS, inclu Zona de encaminhamento: uma zona de tipo de encaminhamento substitui o caminho de consulta padrão (pergunte à raiz primeiro) para um domínio particular. O uso de uma zona de encaminhamento é típico quando uma organização tem uma estratégia de relacionamento com algum outro grupo ou empresa e deseja canalizar o tráfego diretamente para servidores de nomes daquela empresa, ignorando o caminho de consulta padrão (NEMETH et al., 2010). Zona de mapeamento reverso: Mapeamentos reversos traduzem endereços IP em nomes de domínio (NEMETH et al., 2010). Ao contrário da zona de encaminhamento, a zona de mapeamento reverso retorna um nome de domínio para um dado endereço IP. Para os mapeamentos reversos existe um domínio especial chamado: IN-ADDR.ARPA (AITCHISON, 2011). A) Manutenção da zona DNS Uma das atividades realizadas pelo DNS é a manutenção da consistência de seus arquivos de zonas, tendo sempre cópias atualizadas entre o servidor master e os slaves. A necessidade de propagação de arquivos contendo informações é determinada por alterações do número serial no RR SOA da zona (AITCHISON, 2011). Para isso, há três extensões que viabilizam o processo de atualização: Transferência completa de Zona (AXFR): As especificações originais de DNS (RFC 1034 e RFC 1035) previam que um servidor de nomes escravo (ou secundário) da zona, iria consultar o servidor de nomes principal da zona. O tempo entre a pesquisa é determinado pelo valor de atualização de SOA RR do domínio (AITCHISON, 2011). Transferência de zona incremental (IXFR): Transferir grandes arquivos de zona pode levar um longo tempo e consumir largura de banda entre outros recursos. Isso é um desperdício, principalmente se apenas um único registro foi alterado. Assim, a RFC 1995 introduziu a transferência de zona incremental (IXFR), que permite que o servidor de nomes principal transfira aos slaves somente os registros que foram alterados (AITCHISON, 2011). Notificação (NOTIFY): de acordo com Aitchison (2011), o comando NOTIFY permite que não seja preciso esperar até o vencimento do TTL da zona para procurar por atualizações, provendo agilidade na replicação dos registros DNS alterados. A RFC 1996 introduziu um esquema em que um servidor de nomes de zona autoritativa (mestre ou escravo) irá enviar uma mensagem de NOTIFICAÇÃO para os servidores de nomes de zona (definido pelos RRs NS da zona) sempre que a zona for recarregada ou atualizada. Esta mensagem indica que uma mudança pode ter ocorrido nos registros de domínio. O servidor de nomes no momento da recepção da mensagem NOTIFICAR solicitará, então, o RR SOA do mestre zona e, se o número de série for maior do que o atualmente armazenado, tentará uma transferência de zona usando AXFR ou IXFR (AITCHISON, 2011). B) DNSSEC DNSSEC é um conjunto de extensões criado para reduzir problemas de segurança do DNS. Conforme a RFC4033, com estas extensões de segurança (DNSSEC) é possível autenticar a origem dos dados de uma zona DNS, além de verificar sua integridade, através de chaves criptográficas e assinaturas nas informações transmitidas. Os serviços associados são: distribuição de chaves, prova da origem dos dados e autenticação da requisição e transação. A RFC4033, em seu capítulo 4, ainda define que o DNSSEC não oferece proteção contra ataques de negação de serviço, não provê confidencialidade (possível de ser obtida com IPSEC), não há uma lista de controle de acesso (ACLs) e nem meios que possam diferenciar um cliente que está efetuando consulta. DNSSEC depende de uma cadeia de confiança em cascata. Os servidores raiz fornecem informações de validação para os domínios de nível superior, os domínios de nível superior fornecem informações de validação para os domínios de segundo nível, e assim por diante. Ou, pelo menos, essa é a concepção original do sistema (Nemeth et al., 2010, tradução do autor). A figura a seguir, mostra a diferença entre uma requisição DNS e uma requisição DNSSEC. 140

4 Figura 1. Requisições DNS e DNSSEC. (KUROIWA, 2014) Na resolução DNSSEC ilustrada pela figura anterior, temos o seguinte cenário: de acordo com (KUROIWA, 2014), o Servidor DNS recursivo já possui a chave pública da zona.br ancorada, e supomos que o servidor raiz (root server) não usa DNSSEC. O solicitante (resolver) questiona ao servidor DNS recursivo qual o Registro de Recurso (RR) A do host: exemplo.foo.eng.br? O servidor DNS recursivo consulta o Servidor DNS autoritativo (raiz) sobre o registro A para o endereço citado. Como o servidor raiz não possui este registro, ele retorna como resposta o registro NS do.br. O servidor recursivo ao verificar que o nome da zona (.br ) consta em suas ancoras confiáveis (trusted-keys), requisita a DNSKEY para o servidor DNS, que responde com os RRs DNSKEY e RRSIG. É realizada a comparação da trusted-key com a DNSKEY e o RRSIG recebidos, e caso for comprovada a validade, prossegue com as requisições para o servidor que neste caso tem a autoridade sobre o.br e.eng.br. Novamente a resposta referencia a um NS, desta vez o autoritativo do foo.eng.br O servidor DNS recursivo verifica se este servidor DNS é válido. Após a validação, é retornado o registro A com sua assinatura RRSIG, que é aceita pelo servidor DNS recursivo e então o endereço IPv4 referente ao registro A do host exemplo.foo.eng.br é então repassado ao solicitante. Como pode ser notado, existem diferenças significativas na troca de mensagens entre os servidores autoritativos e o servidor recursivo, como o envio dos registros de recursos: DNSKEY, RRSIG e DS que são exclusivos do DNSSEC e serão explanados oportunamente neste artigo. C) Cadeia de confiança do DNSSEC (Chains oftrust) Conforme Aitchison (2011), DNSSEC permite que um cliente DNS valide a origem e a integridade dos dados recebidos em resposta a uma consulta. DNSSEC não conta com uma PKI (Public Key Infrastructure Infraestrutura de Chaves Públicas), mas em vez disso cria uma hierarquia, ou cadeia de confiança, com base na delegação de nomes DNS. A entidade de confiança constitui a raiz ou o ponto de entrada seguro (SEP) da cadeia de confiança, em que certos RRs (Resource Records Registros de Recursos) no ponto de delegação são assinados criptograficamente (usando uma assinatura digital) pela zona pai. Isto cria uma ligação segura com o domínio seguinte na cadeia que, por sua vez, assina os registos de delegação e assim por diante, até que o ponto final tenha sido atingido (AITCHISON, 2011). Ao usar DNSSEC, constrói-se uma cadeia de confiança. A cadeia é criada, permitindo que uma zona pai possa assinar a chave pública de uma zona filha. A cadeia começa com uma chave que é conhecida por um resolvedor. Idealmente, esta chave seria a chave dos servidores raiz (rootservers) da Internet. Se um resolvedor confia em um TLD (Top Level Domain), por ter essa chave pré-configurada, este é o ponto de entrada de seguro na árvore de DNSSEC, os rootservers ("."). Resumindo, a chave do funcionamento do DNSSEC está relacionada à confiança no primeiro servidor, ou seja, o servidor de raiz; tendo a confiança neste servidor, toda a cadeia se torna autossustentável. No Brasil, a entidade Nic.br1 (Núcleo de Informação e Coordenação do Ponto BR) recomenda que apenas a chave da raiz seja utilizada como Trust Anchor na configuração de servidores DNS recursivos. O Nic.br também disponibiliza um script para automatizar o download da chave raiz que encontra-se no site da IANA (Internet Assigned Numbers 1 Nic.BR. DNSSEC - Chave Pública da Raiz. em < Acesso 17 Out. 141

5 Um estudo de caso de implantação de DNSSEC em ambiente corporativo multisite Authority) 2, este script é intitulado de Fetch Root Anchor, que pode ser obtido ftp://ftp.registro.br/pub/doc/fetch_root_anchor.sh. D) Validação de consultas com DNSSEC Huston (2010), nos diz que quando solicitado pelo cliente na consulta DNS, o servidor DNS com autoridade irá adicionar dados DNSSEC às respostas, o que permite ao cliente DNS autenticar as informações recebidas. Na prática, o que acontece é a adição do RR RRSIG na resposta de DNS. Se não houver dados de DNS autoritativos para responder à consulta (quando o nome de domínio existe), então a resposta DNS irá incluir um RR NSEC, além do registro RRSIG. O cliente DNSSEC deve usar os dados RRSIG para verificar a validade da resposta DNS. Para isso, deve-se usar o RRset respondido e aplicar o algoritmo referenciado no registro RRSIG para gerar o hash dos dados (método criptográfico que, quando aplicado sobre uma informação, independentemente do tamanho que ela tenha, gera um resultado único e de tamanho fixo) 3. Depois disso, usa-se o valor do RRSIG, que é encriptado usando a chave pública DNSKEY; para isso o cliente DNS já deve possuir o RR DNSKEY para a zona. Com estas ações será possível descriptografar o hash no registro RRSIG. Os resultados destas duas operações são comparados, e se a resposta DNS for autêntica o hash dos dados RRset irá coincidir com o valor de hash RRSIG descriptografado. A Figura 2 exemplifica este processo. Figura 2. Validação DNSSEC. (KUROIWA, 2014). E) Registro de recurso DNSKEY O registro de recurso DNSKEY é descrito pela seção 2 da RFC 4034/2005. DNSSEC usa criptografia de chaves públicas para assinar e autenticar conjuntos de registros de recursos (RRsets). Estas chaves públicas são armazenadas no registro de recurso chamado de DNSKEY e são usadas pelo DNSSEC para o processo de autenticação (que é descrito pela RFC 4035/2005). Uma zona autoritativa assina seus registros de recursos usando uma chave privada e armazena a chave pública correspondente num registro de recursos DNSKEY. Um resolvedor de DNS pode então usar a chave pública para validar assinaturas dos registros de recursos cobertos pela zona, e então autenticá-los. A chave RR DNSKEY pode ser obtida a partir de uma consulta ao recurso DNSKEY do domínio. Segue um 2 A IANA é o órgão responsável pela coordenação global dos DNS raiz, endereçamento IP, e outros recursos do protocolo internet. 3 Cert.br. Cartilha de Segurança para Internet. Glossário. em < Acesso em 26 Out. exemplo de DNSKEY, obtida através do comando drill : # drill dnskey ufscar. br A DNSKEY pode corresponder a uma cadeia ou chave de confiança local, em que o DNSKEY pode ser aceito sem testes. Caso contrário, o RR DNSKEY terá de ser validado. Este procedimento implica a verificação de validação do RR RRSIG DNSKEY, usando o mesmo procedimento anteriormente descrito para outros RRs. No entanto, a validação da chave da zona de domínio implica também na construção de uma cadeia de confiança reversa para uma âncora de confiança. Se a chave do domínio não for uma âncora de confiança, o cliente precisa consultar a zona pai para obter o registro DS desta zona. Esta consulta DS deve retornar o valor da chave pública (DS do RR), uma RRSIG RR associada com o DS RR, e um RR 142

6 DNSKEY da zona principal. O DS RR pode ser validado através do RRSIG RR, usando a chave pública contida na RR DNSKEY. Esta chave pública, por sua vez, tem de ser validada. Este processo iterativo constrói uma cadeia de confiança que, deve levar de volta a uma âncora de confiança configurado localmente. Nesse ponto, a resposta de DNS com DNSSEC pode ser considerada válida (Huston, 2010, tradução do autor). F) Registro de recurso assinado (RRSIG) A sigla RRSIG corresponde a Resource Record Signature, definida na seção três da RFC 4034/2005. A RFC 4034 diz que um registro RRSIG contém uma assinatura para cada nome, classe ou tipo. RSSIG especifica a validade para a assinatura, o tipo de algoritmo utilizado, o nome do assinante e uma chave que identifica o RR DNSKEY que contém a chave pública que o validador deve utilizar para conferir a assinatura. De acordo com Aitchison (2011), o Registro de Recurso Assinado (RRSIG) é um registro DNSSEC que contém a assinatura digital dos conjuntos de registros (RRset) a serem assinados. Os registros de recursos RRSIG operaram em RRsets (definidos como sendo qualquer registro cujos campos nome, classe e tipo RR são os mesmos) que não são registros de recursos individuais. Os registros de recursos RRSIG, que são as assinaturas digitais para cada registro de recursos da zona, são gerados automaticamente quando é utilizada uma ferramenta para assinatura da zona (ldns-signzone ou o utilitário dnssecsignzone do BIND) usando a chave privada cuja chave pública é armazenada em um registro de recurso DNSKEY definido no topo da zona ou na raiz. G) Registro de recursos DS Segundo a RFC 4034 em seu capitulo de número cinco, o registro de recurso nomeado de DS refere-se a um RR do tipo DNSKEY e é usado no processo de autenticação da DNSKEY do DNS. O campo RR DS refere-se a um RR DNSKEY que armazena o rótulo da chave, o número de algoritmo, e um resumo do RR DNSKEY. Note-se que o resumo deverá ser suficiente para identificar a chave pública, armazenando a etiqueta da chave e um algoritmo de chave ajuda a tornar o processo de identificação mais eficiente. Identificando o registro DS, um resolvedor de DNS pode autenticar o RR DNSKEY para o qual aponta o registro DS. O RR DS e seu RR DNSKEY correspondente devem ter o mesmo nome do proprietário, mas eles são armazenados em locais diferentes. O campo RR DS só é visível através de seu domínio de delegação (domínio pai), ou seja para o domínio ufscar.br. Considerando o domínio ufscar.br, o registro de recurso DS é armazenado no.br., e o RR DNSKEY correspondente no registro filho (ufscar.br.). H) Secret Key Transaction Authentication for DNS (TSIG) De acordo com a RFC 2845, a TSIG permite autenticação da transação através de chaves compartilhadas com hashes de via única. Este registro pode ser usado para autenticar atualizações dinâmicas de um cliente ou autenticar respostas vindas de um outro servidor DNS autorizado. Este registro deve ser configurado pelo administrador de rede de maneira estática entre os servidores e clientes que a utilizarão. A assinatura TSIG em uma mensagem autentica os pares (cliente e servidor) e verifica se os dados não foram adulterados. As assinaturas são verificadas no momento em que um pacote é recebido e são descartadas; elas não são armazenadas em cache e não se tornam parte dos dados do DNS (NEMETH et al., 2010). Resumindo, pode-se dizer que uma chave TSIG valida se o servidor que está enviando os dados é um servidor autêntico. A criação da chave compartilhada TSIG é simples. Conforme a documentação do NSD, pode ser feita executando apenas um comando: Deste modo, tem-se uma chave compartilhada, como ilustrado a seguir: Vale observar que esta mesma chave deve ser configurada no outro servidor que irá autenticar a mensagem, em nosso caso, um servidor slave. I) Registro de recurso NSEC 3 De acordo com a RFC5155, o padrão NSEC3 (Next Secure 3) fornece respostas autenticadas de negação de existência para registros de nomes. Isso significa que é possível ter autenticação e integridade para respostas de negação à existência em consultas de DNS, no caso da resposta ser NXDOMAIN (Non-Existent Domain ). Se não houver esta validação, um atacante pode forjar uma resposta de não existência de registro e se o mesmo for armazenado em algum servidor poderá causar a falha de acesso ao serviço até a expiração do cache em questão. Uma das principais vantagens do NSEC3 em relação ao seu antecessor NSEC é que ele não permite a descoberta de zona (zone walking), ou seja, é possível descobrir todos os registros existentes em uma zona DNS, mesmo com DNSSEC, o que do ponto de vista de segurança não seria ideal. Mais informações a respeito de negação de existência autenticada, podem ser obtidas através da RFC J) LDNS Conforme (NEMETH et al., 2010), ldns é uma biblioteca de funções para programação de DNS. Essa biblioteca provê suporte às mais novas RFCs com relação ao DNSSEC. Como é escrita em linguagem C, pode-se considerar que a ferramenta é muito ágil no quesito desempenho. Além disso suporta nativamente IPv6. Para as funções de criptografia a biblioteca ldns usa funções 4GIEBEN, R. MEKKING, W.. RFC7129. Authenticated Denial of Existence in the DNS. < Acesso em 17 Out. 143

7 Um estudo de caso de implantação de DNSSEC em ambiente corporativo multisite da biblioteca OpenSSL. A biblioteca ldns possui diversos programas que podem ser utilizados na exibição de parâmetros do servidor de nomes, na criação de chaves, na assinatura e no detalhamento de zonas com DNSSEC, entre outras funções. K) Chaves ZSK e KSK Para fazer a assinatura criptográfica dos arquivos da zona, é possível usar chaves assimétricas, ou seja, uma chave privada de uma chave pública para encriptar os arquivos. Isto identifica dois tipos de operações de assinatura. O primeiro tipo é a ZSK - Zone Signing Key, e o segundo é a KSK - Key Signing Key. Aitchison (2011) as define da seguinte forma: a chave ZSK é usada para assinar registros de recursos dentro da zona, e inclusive assina a si própria. A chave KSK é utilizada para assinar as chaves na raiz da zona em questão, o que inclui a chave ZSK. Ela também usada ou referenciada fora da zona em questão para, por exemplo, validar um resolvedor da cadeia de confiança. III. ESTUDO DE CASO NA IMPLANTAÇÃO DE DNSSEC Para um estudo de caso na implantação de uma infraestrutura de DNS com autenticação, usando DNSSEC, optou-se por um modelo de rede corporativa de um ambiente acadêmico, com um ASN próprio e com estrutura de rede dividida entre mais de um campi. Assim, este trabalho apresenta uma descrição de um modelo similar à infraestrutura de rede da UFSCar (Universidade Federal de São Carlos). Neste cenário, demonstramos como pode ser realizada a instalação e configuração dos servidores de DNS autoritativos e recursivos para atendimento do ambiente de acesso a rede interna e externa. Conforme informações obtidas da Secretaria Geral de Informática (SIn) do campus de São Carlos da UFSCAR, a estrutura conta em sua estrutura de DNS com 3 (três) servidores DNS autoritativos (zona ufscar.br e zonas reversas dos IPs), sendo um primário e um secundário em São Carlos e o terceiro em Sorocaba. Também existem 4 (quatro) servidores DNS recursivos, sendo dois deles em São Carlos, um servidor em Sorocaba e um em Araras. Nos campi de São Carlos e Sorocaba os servidores DNS (Autoritativos e recursivos) estão instalados sobre o sistema operacional FreeBSD e executando o servidor de nomes BIND. Em São Carlos, todos os servidores trabalham em pilha dupla (IPv4 e IPv6) e nas outras localidades apenas com IPv4. A grande quantidade de computadores servidores da universidade mantém muitos dos serviços de alta disponibilidade e confiabilidade, tornando a manutenção dos serviços DNS de alta criticidade, pois além de manter os serviços ao público interno, ainda contempla uma grande gama de usuários externos, utilizando os recursos da Universidade. Como base do número de usuários da UFSCAR, usando o Relatório de Autoavaliação Institucional da UFSCAR5, com indicadores do ano de 2012, há cerca de alunos, aproximadamente 1000 docentes e 900 funcionários técnicos administrativos. Assim, o acesso conhecido dos recursos é realizado por cerca de pessoas. Considerando a implantação das extensões do DNSSEC nos servidores de DNS da UFSCar, inicia-se com a criação de uma assinatura para o serviço DNS. Esta assinatura deverá estar devidamente registrada na cadeia de confiança do registro.br para garantir que não possa haver nenhum tipo de manipulação durante o transporte dos dados até o usuário. Para a execução do serviço com autenticação, propomos a utilização do Sistema Operacional FreeBSD versão 10.0 Release-P7 e seus recursos nativos. Para a função de Servidor DNS autoritativo a escolha é o software NSD (Name Server Daemon ) versão da empresa NLnetLabs, que é utilizado pelo registro.br em metade do cluster de nomes do cctld (Country Code Top Level Domain ).br. Segundo seu desenvolvedor, NSD é utilizado nos servidores K e H dos root servers, incluindo servidores para os domínios.nl,.se,.at,.dk e.cz. Para servidor escravo das zonas do domínio propomos a utilização do servidor de nomes BIND (Berkley Internet Name Domain ) na versão P1 (Extended Support Version ). Para uso como servidor de nomes recursivos podemos utilizar os próprios servidores escravos ou ter servidores de cache e encaminhamento com o servidor de nomes Unbound (versão ). Este projeto não visa a modificar a estrutura existente na instituição alvo, mas apenas acrescentar o serviço de segurança DNSSEC; por isso, a quantidade e funções dos servidores serão mantidos conforme a situação atual. A) Implementação da Assinatura e publicação da zona com DNSSEC Para a criação do par de chaves assimétricas ZSK e KSK, pode-se usar a ferramenta "ldns-keygen". A Criação da chave de assinatura de zona (ZSK) é possível através do seguinte comando: #ldns-keygen -a RSASHA1_NSEC3 -b 1024 ufscar. br a seguinte saída é a resultante do comando: Neste caso, entre os parâmetros utilizados pelo ldnskeygen, -a <alg> define o algoritmo a ser utilizado, e -b <bits> define o tamanho da chave em bits. O último argumento é o nome da zona, ufscar.br É importante destacar que estamos considerando a segurança do NSEC3, através do algoritmo RSASHA1_NSEC3. A ZSK assinará todos os registros da zona, então quanto maior o tamanho da zona, maior será o tempo para a realização da assinatura, por isso escolhemos o valor de apenas 1024 bits para a composição da chave. Para a geração da chave KSK, pode-se usar o seguinte 5 UFSCAR. < Acesso 24 Set. 144

8 comando: #ldns-keygen gera a saída: -a RSASHA1_NSEC3 -b k ufscar. br, que Neste caso, os parâmetros utilizados na criação da KSK são quase os mesmos da ZSK, com exceção do parâmetro k, que tem a única função de adicionar o valor 257 no RR DNSKEY dentro do arquivo.key. Geradas as chaves, pode-se listar os resultados da criação das mesmas, onde teremos para chave seus respectivos arquivos.ds (registro DS do RR DNSKEY),.key (que contém o DNSKEY público) e.private (que contém os dados da chave privada). Obs.: O processo de criação das chaves pode ser acelerado utilizando dados do pseudo arquivo /dev/random. B) Assinando a zona Depois da criação das chaves (ZSK e KSK), assinaremos a zona com as chaves geradas. A ferramenta que utilizaremos neste passo é o ldns-signzone: Neste caso, o argumento -n habilita a saída com NSEC3, seguido do arquivo da zona não assinado; o próximo é a KSK e por último a ZSK, sendo que as chaves devem ser declaradas sem extensão. C) Validade ou expiração da assinatura Conforme informado no site da empresa NLnetLabs, as assinaturas criadas com as opções padrões têm validade de 30 dias a partir do momento da assinatura. Seguindo este raciocínio, teríamos que reassinar a zona a cada 30 dias, porém os assinadores possuem parâmetros para que possamos prolongar esta assinatura. O argumento do ldns-signzone a ser utilizado é o -e. Assim, pode-se especificar uma data de expiração apropriada para administração, como no exemplo: No comando anterior, a expiração seria no dia 25 de setembro de 2014 ( ) às 10h01m02s. A RFC4034 trata de detalhes sobre a expiração das assinaturas. D) Publicando a zona assinada através do NSD Após obter a assinatura da zona é necessário informar ao servidor autoritativo que ele deverá usar o arquivo de zona assinado, ao invés do convencional. Para isto deve-se editar o arquivo de configuração nsd.conf, substituindo a declaração da zona e de seu respectivo arquivo pelo arquivo arquivo.signed, como exemplificado: Depois desta alteração será necessário reler o arquivo de configuração para que o serviço descubra a modificação através do comando nsd-control reconfig. Mesmo relendo o novo arquivo de configuração, a base de dados contida no servidor DNS ainda é antiga. Para a atualizarmos para o novo conteúdo é necessário recarregar a zona com o comando nsd-control reload. Para notificar os outros servidores pode-se usar o comando nsd-control notify. E) Rolagem e Republicação das chaves A RFC 4641 informa que as mesmas chaves DNSSEC não podem ser usadas indefinidamente. Segundo Nemeth et al. (2010), a rolagem das chaves DNSSEC sempre foi um assunto complicado, de forma que as especificações originais foram alteradas especificamente para tratar da questão da comunicação necessária entre zona pai e zonas filhas sempre que as chaves forem criadas, alteradas ou excluídas. As novas especificações são chamadas de DNSSEC-bis. Baseado em Nemeth et al. (2010) pode-se afirmar que a renovação das chaves de assinatura de zona (ZSK) não é complexa, sendo necessário atentar-se quanto à sincronia, ou seja, a propagação das novas chaves através da própria estrutura de DNS. A troca renovação da ZSK inicia-se com a geração de uma nova chave ZSK e sua inclusão no arquivo da zona em questão. Feito isso, a zona deve ser reassinada com as chaves já existentes e o servidor deve ser recarregado para garantir que após o TTL a nova chave pública da zona está replicada. Após a propagação, basta apenas assinar a zona com a nova ZSK, recarregar o servidor e aguardar a replicação e o processo de troca desta chave estará concluído. A troca da KSK, é similar à da ZSK, porém será necessário informar um novo registro DS para a zona pai. O processo ocorre da seguinte maneira: inicialmente gera-se uma nova KSK, que é incluída no arquivo de zona. Ainda é necessária a assinatura dupla da zona com as duas KSKs (antiga e nova) além da ZSK, e então deve-se recarregar os servidores e aguardar a propagação. O passo adicional neste cenário é que deverá ser notificado a qualquer entidade com uma âncora de confiança para seu domínio do novo valor da KSK, e, após a confirmação, exclui-se o registro da KSK que está sendo retirado da zona. Então, basta reassinar a zona com as novas KSK e ZSK. Podemos notar que o processo de troca e republicação das chaves corresponde a duas vezes o tempo TTL da zona, então esse é o prazo mínimo para termos o processo de substituição ou rolagem das chaves. F) Configurações utilizadas Com as chaves devidamente criadas e a zona assinada, deve-se apenas refletir estas configurações em nossos servidores para que passem a entregar as zonas DNSSEC nas consultas autoritativas. As etapas previstas para a implantação 145

9 Um estudo de caso de implantação de DNSSEC em ambiente corporativo multisite de DNSSEC no cenário alvo considerado neste artigo são apresentadas a seguir. Servidor Autoritativo Iniciamos com a configuração do servidor autoritativo, onde alteraremos o arquivo que consta a zona, neste caso será o arquivo nsd.conf. Como tratamos servidores já em produção, a zona de domínio a ser referenciada pode estar em outro arquivo de configuração. Segue um exemplo de configuração de zona: O parâmetro zonefile, que antes apontava para o arquivo ufscar.br, agora aponta para o arquivo ufscar.br.signed. Para a configuração da autenticação através da TSIG, as seguintes configurações devem ser acrescentadas ao arquivo de configuração, lembrando que o parâmetro secret mostrado é apenas um exemplo: Para garantir a perfeita sincronia usando o TSIG deve-se certificar que as configurações de notificação e transferência estejam devidamente configuradas, como demonstrado: OBS.: O parâmetro notify-retry deve ser configurado conforme as necessidades do administrador. Obs.: Em versões um pouco mais antigas do BIND, é necessária a adição de outros parâmetros no arquivo de configuração ( named.conf ) para que o mesmo passe a trabalhar com DNSSEC, como listado a seguir: Servidor recursivo No servidor recursivo utilizado, Unbound, é necessário apenas um parâmetro para habilitar a validação da cadeia de confiança do DNSSEC, definido no arquivo de configuração unbound.conf : Antes da inicialização do serviço, este arquivo deverá ser obtido através do comando: # unbound-anchor. Com isso, necessita-se apenas que o mesmo encaminhe as consultas do domínio para os servidores autoritativos (principal e escravo). Ainda no arquivo unbound.conf, pode-se identificar as redes que terão recursividade atendida e informar que há um arquivo de zona a ser incluído. Servidor Escravo Prosseguindo com as modificações, deve-se configurar o servidor escravo para que aceite as zonas assinadas com DNSSEC. Neste exemplo, que considera o servidor de nomes bind, as configurações não estão diretamente no arquivo de configuração do BIND ( named.conf ) mas em um arquivo adicional nomeado de ufscar_zones.conf. Habilitando a autenticação pela chave TSIG: No arquivo de configuração da zona de domínio (ufscar.conf), informa-se que há uma zona cujas requisições devem ser encaminhas aos servidores especificados. Também é possível definir relações de confiança para domínios específicos, conforme citado no próprio arquivo de configuração do Unbound, para casos que em a cadeia de confiança DNSSEC não está completa. Seguem exemplos da nlnetlabs: Como a zona que está sendo enviada para replicação já conta com DNSSEC, não é necessário fazer alterações adicionais no servidor escravo. Assim, pode-se inclusive manter o nome originalmente configurado, em nosso caso ufscar.br. IV. RESULTADOS E CONCLUSÕES A implantação do DNSSEC na estrutura de servidores de 146

10 domínio não é tarefa demasiado complexa em relação às vantagens que o mesmo oferece para a organização. Com o DNSSEC tornam-se incorrompíveis as respostas que o servidor de nomes autoritativos produz, assim como as respostas que os servidores de nomes recursivos recebem também são validadas. Ou seja, com DNSSEC podemos ter certeza que estaremos provendo e recebendo respostas DNS com prova da origem. Como visto neste documento, as etapas necessárias são bem definidas e estabelecidas, sendo que o ponto de maior complexidade será que o administrador do servidor de nomes terá que ter maior cautela nas alterações que forem efetuadas. Além disso, aumentará a demanda para gerenciamento dos registros, mas isso pode ser minimizado através da criação de rotinas automatizadas para as operações mais usuais. A finalização deste estudo de caso contribui com um guia prático de implantação de DNSSEC em um ambiente multisite, que pode servir de guia para futuras implementações em instituições que almejam administrar seus domínios com a funcionalidade do DNSSEC em seus servidores, além de servir como parâmetro para trabalhos correlatos. REFERÊNCIAS AITCHISON, R.. Pro DNS and BIND 10 (Expert's Voice in Open Source). 1st ed.. Apress p. ARENDS, R. et al.. RFC4033. DNS Security Introduction and Requirements < Acesso em 12 Out. ARENDS, R. et al. RFC4034. Resource Records for the DNS Security Extensions < Acesso em 12 Out. ARENDS, R. et al. RFC4035. Protocol Modifications for the DNS Security Extensions < Acesso em 12 Out. ARKKO J. et al. RFC5737. IPv4 Address Blocks Reserved for Documentation < Acesso em 12 Jul. EASTLAKE, D.. RFC2535. Domain Name System Security Extensions < Acesso em 12 Jun. GARTNER. Gartner Says That Consumers Will Store More Than a Third of Their Digital Content in the Cloud by < Acesso 27 Ago. HOFFMAN, P. SCHLYTER, J.. RFC6698. The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA < Acesso em 17 Ago. HUSTON, G.. DNSSEC - A Review. The ISP Column. June < Acesso em 12 Out. HUSTON, G. et al. RFC3849. IPv6 Address Prefix Reserved for Documentation < Acesso em 12 Jul. IANA. DNS Security Algorithm Numbers. < Acesso em 17 Ago. KOLKMAN, O. GIEBEN, R.. RFC4641. DNSSEC Operational Practices < Acesso em 17 Ago. KUROIWA, C. Registro.br. Tutorial DNSSEC. em < ftp://ftp.registro.br/pub/doc/tutorial-dnssec.pdf>. Acesso em 07 Out. LAURIE, B. et al. RFC5155. DNS Security (DNSSEC) Hashed Authenticated Denial of Existence < Acesso em 24 Ago. RNP. DNSSEC: O Que É e Por Que Precisamos Dele. < Acesso 10 Jun. NEMETH, E. et al. UNIX and Linux system administration handbook. 4th ed. Prentice Hall p. NLNETLABS. DNSSEC HOWTO, a tutorial in disguise. < c_howto.pdf>. Acesso em 18 Ago TANENBAUM, A. S.; Wetherall D. J.. Computer networks. 5th ed. Prentice Hall p. VIXIE, P. et al. RFC2845. Secret Key Transaction Authentication for DNS (TSIG) < Acesso em 15 Ago. WELLINGTON, B.. RFC3008. Domain Name System Security (DNSSEC) Signing Authority < Acesso em 17 Ago. 147