Visão geral sobre DNSSEC
-
Upload
madson-araujo -
Category
Documents
-
view
179 -
download
17
Transcript of Visão geral sobre DNSSEC
![Page 1: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/1.jpg)
VISÃO GERAL SOBRE DNSSEC
![Page 2: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/2.jpg)
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
![Page 3: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/3.jpg)
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
![Page 4: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/4.jpg)
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
![Page 5: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/5.jpg)
COMO FUNCIONA O DNS
![Page 6: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/6.jpg)
VULNERABILIDADES
![Page 7: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/7.jpg)
DNS CACHE POISONING
![Page 8: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/8.jpg)
DNS CACHE POISONING
![Page 9: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/9.jpg)
DNS CACHE POISONING
![Page 10: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/10.jpg)
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
![Page 11: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/11.jpg)
MAN-IN-THE-MIDDLE
![Page 12: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/12.jpg)
MAN-IN-THE-MIDDLE
![Page 13: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/13.jpg)
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).
![Page 14: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/14.jpg)
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)
![Page 15: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/15.jpg)
CHAVES ASSIMÉTRICAS
![Page 16: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/16.jpg)
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
![Page 17: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/17.jpg)
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)
![Page 18: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/18.jpg)
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.
![Page 19: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/19.jpg)
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):
![Page 20: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/20.jpg)
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.
![Page 21: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/21.jpg)
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
![Page 22: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/22.jpg)
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
![Page 23: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/23.jpg)
IMPLANTAÇÃO DE DNSSEC EM SUA
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";
};
...
![Page 24: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/24.jpg)
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
![Page 25: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/25.jpg)
IMPLANTAÇÃO DE DNSSEC EM SUA
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
Kexemplo-dnssec.br.+005+39539
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.
![Page 26: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/26.jpg)
IMPLANTAÇÃO DE DNSSEC EM SUA
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.
![Page 27: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/27.jpg)
IMPLANTAÇÃO DE DNSSEC EM SUA
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
![Page 28: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/28.jpg)
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).
![Page 29: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/29.jpg)
IMPLANTAÇÃO DE DNSSEC EM SUA
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
![Page 30: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/30.jpg)
IMPLANTAÇÃO DE DNSSEC EM SUA
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.
![Page 31: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/31.jpg)
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:
![Page 32: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/32.jpg)
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.
![Page 33: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/33.jpg)
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.
![Page 34: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/34.jpg)
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).
![Page 35: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/35.jpg)
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.
![Page 36: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/36.jpg)
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
![Page 37: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/37.jpg)
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.
![Page 38: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/38.jpg)
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.
![Page 39: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/39.jpg)
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.
![Page 40: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/40.jpg)
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
![Page 41: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/41.jpg)
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
![Page 42: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/42.jpg)
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.
![Page 43: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/43.jpg)
EXEMPLO DA INCLUSÃO DA CHAVE GERADA
![Page 44: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/44.jpg)
SUBSTITUIÇÃO DA KSK
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
![Page 45: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/45.jpg)
SUBSTITUIÇÃO DA KSK
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.
![Page 46: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/46.jpg)
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.
![Page 47: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/47.jpg)
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 ...)
![Page 48: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/48.jpg)
REMOVER A CHAVE KSK ANTIGA DA
ZONA
![Page 49: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/49.jpg)
REMOVER A CHAVE KSK ANTIGA DA
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
Kexemplo-dnssec.br.+005+03977
Finalmente, recarregue a configuração no
daemon do bind:
/etc/init.d/bind9 restart
![Page 50: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/50.jpg)
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
Kexemplo-dnssec.br.+005+39539
![Page 51: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/51.jpg)
SUBSTITUIÇÃO DA ZSK
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).
![Page 52: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/52.jpg)
SUBSTITUIÇÃO DA ZSK
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:
/etc/init.d/bind9 restart
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
![Page 53: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/53.jpg)
RE-ASSINAR A ZONA COM A NOVA CHAVE
Condição Necessária: Receber e-mail de alerta
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.
![Page 54: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/54.jpg)
RE-ASSINAR A ZONA COM A NOVA CHAVE
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):
dnssec-signzone -o exemplo-dnssec.br -t -k
Kexemplo-dnssec.br.+005+12513 pop-ba.zone
Kexemplo-dnssec.br.+005+39539
Recarregue a configuração no daemon do bind:
![Page 55: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/55.jpg)
RE-ASSINAR A ZONA COM A NOVA CHAVE
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
![Page 56: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/56.jpg)
RE-ASSINAR A ZONA COM A NOVA CHAVE
Condição Necessária: Receber e-mail de alerta
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 ...).
![Page 57: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/57.jpg)
RE-ASSINAR A ZONA COM A NOVA CHAVE
![Page 58: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/58.jpg)
RE-ASSINAR A ZONA COM A NOVA CHAVE
Então, deve-se re-assinar a zona, utilizando a
chave nova/atual (key-tag = 39539):
dnssec-signzone -o exemplo-dnssec.br -t -k
Kexemplo-dnssec.br.+005+12513 pop-ba.zone
Kexemplo-dnssec.br.+005+39539
Finalmente, recarregue a configuração no
daemon do bind:
/etc/init.d/bind9 restart
![Page 59: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/59.jpg)
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
![Page 60: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/60.jpg)
IMPLANTANDO DNSSEC NO SERVIDOR
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";
![Page 61: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/61.jpg)
IMPLANTANDO DNSSEC NO SERVIDOR
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:
![Page 62: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/62.jpg)
IMPLANTANDO DNSSEC NO SERVIDOR
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:
![Page 63: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/63.jpg)
IMPLANTANDO DNSSEC NO SERVIDOR
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:
/etc/init.d/bind9 restart
![Page 64: Visão geral sobre DNSSEC](https://reader030.fdocument.pub/reader030/viewer/2022020717/5571f9c34979599169905eb4/html5/thumbnails/64.jpg)
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