visão geral sobre dnssec

VISÃO GERAL SOBRE DNSSEC

DNS - DOMAIN NAME SYSTEM

DNS é a abreviação de “Domain Name System”

(ou Sistema de Nome de Domínio) e serve

basicamente para fazer com que você consiga

acessar o host que esta querendo ver, usando

nomes, ao invés de números.

exemplo.foo.eng.br → 200.160.10.251

www.cgi.br → 200.160.4.2

www.registro.br → 2001:12ff:0:2::3

TIPOS DE SERVIDORES

Servidor Autoritativo:Ao receber requisições de resolução de nome, responde um endereço caso

possua, uma referência caso conheça o caminho da resolução ou uma

negação caso não conheça

Servidor Recursivo:Ao receber requisições de resolução de nomes, faz requisições para os

servidores autoritativos e conforme a resposta recebida dos mesmos

continua a realizar requisições para outros servidores autoritativos até

obter a resposta satisfatória

TIPOS DE DADOS QUE PODEM SER

ARMAZENADOS

Os dados associados com os nomes de domínio estão

contidos em Resource Records ou RRs (Registro de

Recursos)

Alguns Tipos Comuns de Records

SOA Indica onde começa a autoridade a zona

NS Indica um servidor de nomes para a zona

A Mapeamento de nome a endereço (IPv4)

AAAA Mapeamento de nome a endereço (IPv6)

MX Indica um mail exchanger para um nome

CNAME Mapeia um nome alternativo

TXT Campo de texto livre

COMO FUNCIONA O DNS

VULNERABILIDADES

DNS CACHE POISONING

MAN-IN-THE-MIDDLE

Objetivo

– Conseguir interceptar o trafego da rede sem ser

identificado

– Se fazer passar por um servidor para o usuário e por um

usuário para o servidor

– Obter acesso a conteúdos protegidos, mas aprendendo

como desproteger

MAN-IN-THE-MIDDLE

DNSSEC

DNSSEC é uma extensão do protocolo DNS para implementar

mecanismos de segurança ao protocolo DNS.

Permite que se possa verificar as informações recebidas, invés

de “confiar” em sua validade

Para implementar essas funcionalidades, o DNSSEC faz uso da

criptografia de chave pública (ou criptografia assimétrica) e

introduz um novo conjunto de Resource Records (RRs) com

funções específicas: assinar outros RRs (RRSIG), divulgar a chave

pública que valida as assinaturas digitais de um determinado

domínio (DNSKEY), garantir a não existência de outros registros

(NSEC) e garantir a continuidade do "canal de segurança" na

delegação de zonas (DS).

DNSSEC

O que garante?

Origem (Autenticidade)

Integridade

A não existência de um nome ou tipo

O que não garante?

Confidencialidade

Proteção contra ataques de negação de serviço (DoS)

CHAVES ASSIMÉTRICAS

DNSKEY

É um resource record que armazena a chave

pública da zona, que valida as assinaturas

digitais de um determinado domínio.

EXEMPLO:

foo.eng.br. 900 IN DNSKEY 256 3 5 (

AwEAAeZPN2yMs9q6kgYjFUblEwjCn

WWcPq+TGcJrD5gaXXAbP5MAqIkgZ

5J4TU1mmpL1A8gMfd/wUmBkVipXR

8FKHRajBZSRfgeKnKaQtrxNZ32Ccts

2F6Ylv9WaLXtiqebgOZtuJFpQr6pnIt/

FoOI+I7BUSNrX28VTq4jXu/qTrmM/

) ; key id = 62745

KSK E ZSK

KSK (Key Signing Key ): Sua chave privada é

utilizada apenas para assinar o conjunto de chaves

públicas da zona.

ZSK (Zone Signing Key): Sua chave privada é

utilizada para assinar registros autoritativos da zona:

conjunto de registros (A, AAAA, DS, CNAME, etc.),

com exceção do registro DNSKEY (assinado pela

KSK)

RRSIG

É a assinatura de um RRset. RRset é um conjunto de records na

base de dados DNS com mesmo nome, classe e tipo. Esta

assinatura é a garantia de que as informações enviadas sobre um

domínio são verdadeiras. Isso é possível em função da utilização

de criptografia assimétrica.

O processo de assinatura dos registros é feita off-line, ou seja, o

administrador da zona deve fazê-lo antes de publicar a zona.

No processo de checagem o cliente calculará o hash do RRSet

recebido, usará a chave pública da zona para decifrar o RRSIG e

fará uma comparação entre o hash gerado por ele e o hash

enviado pelo servidor (RRSIG decifrado). Caso sejam iguais, então

a resposta é valida; caso contrário os dados foram alterados e

teremos uma resposta do tipo SERVFAIL.

NSEC

NSEC (Next SECure). Esse registro armazena informações

sobre o próximo nome na zona, que agora passa a ser

ordenada. A grosso modo, cada registro mantem um

apontador, através de seu NSEC, para o próximo registro; o

último "aponta" para o primeiro. Vamos a um exemplo

(serão omitidos uma série de detalhes da definição da zona.

O objetivo é somente demonstrar o funcionamento do

NSEC):

DELEGATION SIGNER (DS)

A ideia é armazenar um hash da KSK de uma zona em sua zona

pai e deixar a tarefa de ancorar a chave diretamente no cliente

(servidor recursivo) somente quando não tivermos como fazer isso

com a zona pai. Ou seja, se todos os domínios aplicarem esse

processo, apenas precisaremos ancorar as chaves da zona raiz no

cliente.

IMPLANTAÇÃO DE DNSSEC EM SUA ZONA

Servidor de Nomes utilizado: bind9

Zona em que se está implantando DNSSEC:

exemplo-dnssec.br.

Localização dos arquivos de configuração:

named.conf -> /etc/bind/named.conf

Arquivo de zona de exemplo-dnssec.br. ->

/etc/bind/var/exemplo-dnssec.zone

Diretório para chaves DNSSEC -> /etc/bind/keys

IMPLANTAÇÃO DE DNSSEC EM SUA

ZONA

O arquivo de zona para exemplo-dnssec.br. (/etc/bind/var/exemplo-

dnssec.zone) inicialmente contém o seguinte:

$TTL 86400 ; 1 day

$ORIGIN exemplo-dnssec.br.

@ IN SOA ns1.exemplo-dnssec.br. hostmaster.exemplodnssec.br.(

2005032902 ; serial

10800 ; refresh (3 hours)

15 ; retry (15 seconds)

604800 ; expire (1 week)

10800 ; minimum (3 hours)

)

IN NS ns1.exemplo-dnssec.br.

IN MX 10 mail.exemplo-dnssec.br.

ns1 IN A 192.168.2.6

www IN A 10.1.2.1

IN A 172.16.2.1

mail IN A 192.168.2.3


ZONA

A configuração inicial do /etc/bind/named.conf é a seguinte

(somente a parte importante):

...

zone "exemplo-dnssec.br" {

type master;

file "/etc/bind/var/exemplo-dnssec.zone";

};

...

CONFIGURAÇÃO DO BIND

Primeiro geramos a chave KSK, que será usada somente para

assinatura dos registros DNSKEY.

# mkdir -p /etc/bind/keys

# cd /etc/bind/keys

# dnssec-keygen -a rsasha1 -b 1280 -fKSK -r/dev/urandom

exemplo-dnssec.br

Kexemplo-dnssec.br.+005+50148

A chave gerada está em dois arquivos: Kexemplo-

dnssec.br.+005+50148.key e Kexemplo-dnssec.br.+005+50148.private.

O primeiro é a chave pública, que deverá ser incluído na zona logo

abaixo, o segundo é a chave privada que deve ser mantida de forma

segura no servidor


ZONA

Em seguida, geramos a chave ZSK, que será usada somente para

assinatura dos demais registros da zona (com exceção da

DNSKEY, assinada pela KSK).

# cd /etc/bind/keys

# dnssec-keygen -a rsasha1 -b 1152 -r /dev/urandom exemplo-

dnssec.br


A chave gerada está em dois arquivos: Kexemplo-dnssec.br.+005

+39539.key e Kexemplodnssec.br.+005+39539.private.

O primeiro é a chave pública, que deverá ser incluído na zona logo

abaixo, o segundo é a chave privada que deve ser mantida de

forma segura no servidor.


ZONA

Uma vez que as chaves já foram geradas, é momento de incluí-las no arquivo da zona. A chave que será inclusa é a chave pública, tanto da KSK quanto da ZSK.


ZONA

Agora precisamos assinar o arquivo de zona. O procedimento de

assinatura consistem em ordenar o arquivo da zona, gerar os

registros NSEC, e assinar os RRsets da zona. O comando abaixo

realiza essas atividades

dnssec-signzone -K /etc/bind/keys -o exemplo-dnssec.br -g -t -k KSK_KEY

/etc/bind/var/exemplo-dnssec.zone ZSK_KEY

IMPLANTAÇÃO DE DNSSEC EM SUA ZONA

-K /etc/bind/keys informa qual o diretório que contém os

arquivos das chaves (públicas e privadas) KSK e ZSK, nesse caso

/etc/bind/keys.

-o exemplo-dnssec.br é o nome da zona, nesse caso exemplo-

dnssec.br

-g é um parâmetro usado para gerar o arquivo dsset que contém o

registro DS para possivelmente ser adicionado à zona parent.

Após a execução do comando acima com esse parâmetro, será

gerado um arquivo dsset-exemplo-dnssec.br. no diretório corrente;

-t é um parâmetro para gerar estatísticas sobre a assinatura da

zona;

-k KSK_KEY informa qual a chave KSK para assinatura do

DNSKEY;

/etc/bind/var/exemplo-dnssec.zone é o arquivo de zona

(parâmetro obrigatório);

ZSK_KEY é a chave ZSK usada na assinatura dos outros

registros da zona (parâmetro obrigatório).


ZONA

Agora precisaremos alterar a configuração do bind para utilizar a versão assinada do arquivo de zona. Para isso, edite o arquivo named.conf e deixe-o como a seguir


ZONA

Precisamos recarregar o daemon do bind para que ele

reconheça essa nova configuração. Para tal:

/etc/init.d/bind9 restart

Isso finaliza a configuração do servidor. Agora

precisaremos divulgar de alguma forma a chave pública de

nossa KSK.

DIVULGANDO A CHAVE PÚBLICA DA

KSK

Caso a zona parent possua DNSSEC implantado,

vamos simplesmente solicitar a inclusão do

registro DS. Esse é o método mais recomendado

para garantia da cadeia de confiança, logo

sempre que possível utilize esse método

OBS: Caso a zona parent de seu domínio não

tenha suporte à DNSSEC, você terá que usar

outro método de divulgação da chave pública, por

exemplo, divulgando sua chave em um servidor

DLV. Caso isso seja realmente necessário,

recomendamos usar o DLV da ISC:

MÉTODOS DE TROCA DE CHAVES NO

DNSSEC

A troca de chaves planejada vai depender da

política de chaves DNSSEC da instituição. No

caso do POP-BA, a ZSK é trocada a cada três

meses e a KSK tem validade de 2 anos.

Existem dois métodos utilizados na troca de

chaves: pre-publish e double-signing.

MÉTODO PRE-PUBLISH

No método pre-publish a ideia é adicionar uma ou

mais novas chaves na zona antes mesmo delas

serem de fato utilizadas para assinar registros.

Dessa forma garante-se a disponibilidade de

ambas as chaves no cache do servidores

recursivos, que devem utilizar todas as chaves

disponíveis na validação de um registro, e evita-

se falhas pela utilização incorreta da chave na

validação.

MÉTODO PRE-PUBLISH

Para ilustrar o funcionamento desse método,

vamos acompanhar os passos de substituição de

uma chave em uma zona fictícia. Para tal,

assumimos que o TTL de qualquer registro na

zona assinada é 24h (86400 segundos).

MÉTODO PRE-PUBLISH

1. No mínimo dois dias antes da expiração das assinaturas

da zona (poderia ser qualquer momento antes), a nova

chave (seja KSK ou ZSK) deve ser adicionada ao registro

DNSKEY da zona. A zona é então re-assinada usando a

chave atual, não a nova. A nova chave apenas estará

presente à zona, porém ainda não será usada em

nenhuma assinatura.

2. Passado-se as 24h (tempo definido do TTL ou TTL

máximo da zona), garantimos que o cache dos servidores

recursivos contém o registro DNSKEY contendo ambas as

chaves, a atual e a nova. Nesse caso, qualquer RR estará

assinado com a chave atual e ainda não temos uso claro

da nova chave.

MÉTODO PRE-PUBLISH

3. Nesse momento, a zona é re-assinada utilizando

a nova chave. A chave antiga permanece

disponível na zona.

4. A partir desse ponto e nas próximas 24h (tempo

definido do TTL ou TTL máximo da zona), a

assinatura de qualquer RR requisitado à um

servidor recursivo, por exemplo o RR A para

www.exemplo.com, pode ter sido feita com a

chave antiga (caso o RR já estava no cache) ou

com a chave nova (caso o cache tenha expirado e

o servidor recursivo obteve o registro novamente

em um servidor autoritativo

MÉTODO PRE-PUBLISH

5. Depois de 24h da assinatura da zona com a nova

chave, podemos garantir que todos os caches

contém apenas registros assinados com a nova

chave. A chave antiga pode então ser removida

do RR DNSKEY e a zona re-assinada com a

nova chave.

MÉTODO DOUBLE-SIGNING

Diferente do método de pre-publish, onde a nova

chave era adicionada à zona porém ser ter uma

utilidade clara no início, no método de double-

signing utilizamos tanto a chave atual quanto a

nova para assinar os registros da zona. Ou seja,

usando double-signing teremos duas assinaturas

para cada conjunto de RRs. Se a chave que

estiver sendo substituída for a ZSK, toda a zona

será assinada duas vezes. Já se for a KSK

somente os registros DNSKEY serão assinados

duas vezes.

MÉTODO DOUBLE-SIGNING

Uma vez que os registros de recurso são

assinados com todas as chaves, não corremos o

risco de um servidor recursivo, que armazena

uma das chaves em cache, falhe ao autenticar os

dados de uma consulta (o mesmo vale para

configuração de âncoras ou do registro DS na

zona parent). Quando todos os usuários da chave

tiverem atualizado suas configurações (o registro

DS foi atualizado na zona parent ou as âncoras de

segurança foram atualizadas), a chave antiga

pode ser removida e a zona re-assinada somente

com a nova chave.

GERÊNCIA DAS CHAVES DNSSEC

As chaves devem ser trocadas com alguma frequência. Essa

frequência depende da política de cada domínio. De

qualquer forma, é interessante manter em local seguro (por

exemplo na Intranet de sua instituição) uma planilha que

liste as chaves que estão sendo usadas, além de

informações sobre a data de utilização (criação e troca).

Ainda, configure duas rotinas em seu servidor de gerência

para enviar e-mails quando tiver próximo ao período de

troca das chaves:

Um e-mail para a troca da chave KSK

Um e-mail para a troca da chave ZSK

PROCEDIMENTO PARA SUBSTITUIÇÃO

MANUAL DE CHAVES DNSSEC

Para manter um controle sobre a utilização das chaves,

recomenda-se a utilização de uma tabela, como a seguinte,

que liste quais chaves estão sendo utilizadas e quando as

mesmas devem ser removidas.

OBS1: O campo Chave refere-se ao basename do arquivo que

contém a chave.

OBS2: Os valores dos campos Data Início e Data Fim são

determinados a partir da política de chaves da instituição

SUBSTITUIÇÃO DA KSK

Condição Necessária: Receber e-mail de alerta sobre a proximidade de substituição da KSK. Esse é o primeiro passo a ser seguido no procedimento de substituição da KSK.

Descrição das etapas:

Primeiro devemos gerar a nova chave. No comando abaixo, alguns parâmetros que podem variar com sua política de chaves, tais como algoritmo (-a rsasha1) e tamanho da chave (-b 1280), ou com a zona em questão (nome da zona nesse caso é exemplo-dnssec.br).

# dnssec-keygen -a rsasha1 -b 1280 -f KSK -r /dev/urandom exemplo-dnssec.brKexemplo-dnssec.br.+005+50148

Em seguida, adiciona-se essa nova chave ao arquivo de zona.

http://www.pop-ba.rnp.br/Site/DNSSEC_Politica

http://www.pop-ba.rnp.br/Site/DNSSEC_Politica

EXEMPLO DA INCLUSÃO DA CHAVE GERADA


Então, deve-se re-assinar a zona, utilizando as

duas chaves, a nova e a atual (o comando abaixo

possui uma única linha):

dnssec-signzone -o exemplo-dnssec.br -g -t -k Kexemplo-

dnssec.br.+005+12513 -k Kexemplo-dnssec.br.+005+50148

pop-ba.zone Kexemplo-dnssec.br.+005+03977

O comando acima irá gerar um arquivo,

provavelmente dsset-exemplo-dnssec.br.. Esse

arquivo deve ser enviado ao administrador da

zona parent


Passaremos a considerar que a chave atual

agora é chave antiga (no exemplo, key-tag é

12513) e a chave nova agora é chave atual

(no exemplo, key-tag é 50148). A partir desse

momento até a remoção da chave antiga,

assinaremos a zona sempre com o comando

acima.

CONTAGEM PARA REMOÇÃO DA KSK

ANTIGA

Condição Necessária: Receber e-mail do

administrador da zona parent notificando sobre a

alteração do registro DS. Esse é o segundo passo

a ser seguido no procedimento de substituição da

KSK.

Descrição das etapas: Uma vez que a zona parent já atualizou o registro DS para a

nova chave pública KSK, basta aguardar que os servidores de

cache expirem os dados que contém a chave antiga para que

possamos removê-la da zona. Ao final desse prazo deve ser

aplicado a seguinte etapa: Remover chave KSK antiga da

zona.

REMOVER A CHAVE KSK ANTIGA DA

ZONA

Condição Necessária: Receber e-mail de alerta

sobre a proximidade de remover a chave KSK

antiga da zona. Esse é o terceiro e último passo a

ser seguido no procedimento de substituição da

KSK.

Passados 30 dias desde a atualização do registro

DS na zona parent com sua nova KSK, é

momento de remover a chave antiga (no exemplo,

key-tag é 12513). Para isso, edite o arquivo de

definição da zona e remova a linha que contém a

KSK antiga ($INCLUDE Kexemplo-

dnssec.br.+005+12513.key ...)


ZONA


ZONA

Então, deve-se re-assinar a zona, utilizando a

chave nova/atual (key-tag = 50148):

dnssec-signzone -o exemplo-dnssec.br -t -k

Kexemplo-dnssec.br.+005+50148 pop-ba.zone


Finalmente, recarregue a configuração no

daemon do bind:


SUBSTITUIÇÃO DA ZSK

Adicionando a nova chave Condição Necessária: Receber e-mail de alerta sobre a

proximidade de substituição da ZSK. Esse é o primeiro

passo a ser seguido no procedimento de substituição da

ZSK.

Primeiro devemos gerar a nova chave. No comando abaixo,

alguns parâmetros que podem variar com sua política de

chaves, tais como algoritmo (-a rsasha1) e tamanho da

chave (-b 1152), com a zona em questão (nome da zona

nesse caso é exemplo-dnssec.br).

# dnssec-keygen -a rsasha1 -b 1152 -r /dev/urandom

exemplo-dnssec.br



Em seguida, adiciona-se esse nova chave ao arquivo de

zona e assina-se o arquivo de zona com a chave atual (não a

nova).


Então, deve-se re-assinar a zona, utilizando a chave atual:

dnssec-signzone -o exemplo-dnssec.br -t -k Kexemplo-

dnssec.br.+005+12513 pop-ba.zone Kexemplo-

dnssec.br.+005+03977

Finalmente, recarregue a configuração no daemon do bind:


Agora, configure uma rotina no seu servidor de gerência

para enviar um e-mail aos administradores da zona em 10

dias desde a configuração acima. Ao final desse prazo deve

ser aplicado a seguinte etapa: Re-assinar a zona com a

nova chave

RE-ASSINAR A ZONA COM A NOVA CHAVE


sobre a proximidade da assinatura da zona com a

nova chave. Esse é o segundo passo a ser seguido

no procedimento de substituição da ZSK.


Passados os 10 dias desde a introdução da nova

chave na zona, é hora de usá-la na assinatura da

zona. Para isso executamos o comando de

assinatura da zona, como anteriormente, porém

agora usando a nova chave (cujo key-tag é 39539):




Recarregue a configuração no daemon do bind:


A partir desse momento consideramos que a

chave atual agora é chave antiga (no

exemplo, key-tag é 03977) e a chave nova agora

é chave atual (no exemplo, key-tag é 39539).

Agora devemos aguardar mais 10 dias para

finalmente remover a chave antiga. Para isso

configure uma rotina no seu servidor de gerência

para enviar um e-mail aos administradores da

zona em 10 dias desde a configuração acima. Ao

final desse prazo deve ser aplicado a seguinte

etapa: Remover a chave antiga da zona



sobre a proximidade da remoção da chave antiga.

Esse é o terceiro e último passo a ser seguido no

procedimento de substituição da ZSK.

Passados 10 dias desde a assinatura da zona, é

momento de remover a chave antiga (no exemplo,

key-tag é 03977). Para isso, edite o arquivo de

definição da zona e remova a linha que contém a ZSK

antiga ($INCLUDE Kexemplo-

dnssec.br.+005+03977.key ...).


Então, deve-se re-assinar a zona, utilizando a

chave nova/atual (key-tag = 39539):




Finalmente, recarregue a configuração no

daemon do bind:


IMPLANTANDO DNSSEC NO SERVIDOR

RECURSIVO

Para que as checagens DNSSEC possam ocorrer no

servidor recursivo, precisaremos obter as chaves públicas

das zonas DNSSEC-habilitadas. Agora que a zona raiz foi

assinada, precisamos apenas ancorar sua chave pública

como Trust Anchor na configuração de servidores DNS

recursivos.

Entretanto, manteremos também a chave de um servidor

DNSSEC Lookaside Validation (DLV), que será usada em

casos de ilhas de segurança DNSSEC


RECURSIVO

No bind, a partir da versão 9.7.0, a chave do

servidor DLV do ISC já está disponível na

instalação padrão. Ainda, a partir dessa versão já

temos a implementação da RFC 5011, que fala

sobre a atualização automática de âncoras de

segurança DNSSEC quando do rollover das

chaves.

include "/etc/bind/bind.keys";


RECURSIVO

Precisamos, ainda, adicionar a chave da zona raiz

ao conjunto de chaves gerenciadas do bind

(managed-keys). Para isso, editamos o arquivo

/etc/bind/bind.keys e incluímos o seguinte:


RECURSIVO

O próximo passo é dizer ao bind para usar a chave DLV do

ISC na validação das consultas DNS e ativar o DNSSEC.

Para isso edite a configuração do bind que define as opções

(clausula options), no Debian esse arquivo é o

/etc/bind/named.conf.options e deve parecer com o seguinte:


RECURSIVO

OBS: Em versões anteriores do bind, era preciso

definir as opções dnssec-enable yes; e dnssec-

validation yes;. Porém a partir da versão 9.7.0,

elas estão habilitadas por padrão.

Pronto, agora basta reiniciar o daemon do bind

para carregar essa nova configuração:


TESTANDO A CONFIGURAÇÃO

Para testar se nosso servidor recursivo está

validando as respostas DNS, usaremos o

comando dig. Por exemplo, execute o comando

abaixo e verifique a saída.

dig +dnssec +multi @localhost www.pop-

ba.rnp.br

visão geral sobre dnssec

Documents