Como Corrigir BIND9 Contra Envenenamento de Cache DNS No Debian Etch

Versão 1.0
Autor: Falko Timme

Este artigo explica como você pode corrigir um servidor de nomes BIND9 em um sistema Debian Etch para que ele não seja mais vulnerável ao envenenamento de cache DNS.

Este documento vem sem garantia de qualquer tipo! Eu não emito nenhuma garantia de que isso funcionará para você!

1 Verificando Se o BIND É Vulnerável

Execute o seguinte comando contra seu servidor de nomes para descobrir se ele é vulnerável (substitua ns1.example.com pelo endereço do seu próprio servidor de nomes):

dig +short @ns1.example.com porttest.dns-oarc.net TXT

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“1.2.3.4 é POBRE: 26 consultas em 4.4 segundos de 1 portas com desvio padrão 0.00”
mh1:~#

POBRE indica que o BIND é vulnerável. Nesse caso, você deve corrigir o BIND.

Se você não receber nenhuma resposta, isso significa que seu servidor DNS não é um resolvedor recursivo, o que significa que ele não responde a consultas para domínios dos quais não é autoritativo. Nesse caso, você não é vulnerável ao envenenamento de cache, mas ainda assim eu recomendo fortemente que você atualize o BIND!

2 Corrigindo o BIND

Isso não é tanto uma correção, mas uma atualização. Basta executar

apt-get install bind9 bind9-host

Isso instalará os pacotes BIND atualizados dos repositórios Debian.

Depois, abra /etc/bind/named.conf e modifique a seção de opções. Se você não precisar de um resolvedor recursivo (ou seja, se seu servidor de nomes deve responder apenas a consultas para domínios pelos quais é responsável), adicione allow-recursion { none; };. Dessa forma, você desativa o cache para outros domínios. A segunda linha que você deve adicionar é dnssec-enable yes; - isso faz com que o BIND responda a consultas em portas aleatórias que são mais difíceis de adivinhar para hackers (lembre-se da resposta ao nosso comando dig no capítulo 1: […]26 consultas em 4.4 segundos de 1 portas[…] - o BIND estava respondendo em apenas uma porta…).

Correção: Acabei de receber o seguinte e-mail de Alan Clegg:

Bom dia! Acabei de ler seu artigo em: https://www.howtoforge.com/how-to-patch-bind-to-avoid-cache-poisoning-debian-etch e tenho alguns comentários. Primeiramente, obrigado por escrever isso. Precisamos que o maior número possível de pessoas corrija esse problema. Em segundo lugar, há um pequeno erro que deve ser corrigido. Você afirma: “A segunda linha que você deve adicionar é dnssec-enable yes; - isso faz com que o BIND responda a consultas em portas aleatórias que são mais difíceis de adivinhar para hackers” Na verdade, essa linha habilita o servidor a responder com registros DNSSEC quando o bit “DO” (DNSSEC OK) está definido na pergunta que está sendo feita. O que você quer que as pessoas procurem é uma declaração como: query-source […] port XX; Onde o XX é um número de porta fixo no qual as consultas deste sistema devem ser enviadas. Isso desfaz tudo o que as novas versões do BIND fazem para randomizar a porta de origem UDP. Se você tiver alguma dúvida, sinta-se à vontade para enviar um e-mail. Alan Clegg
Internet Systems Consortium (ISC)
Treinamento e Suporte

vi /etc/bind/named.conf

| [...] options { pid-file "/var/run/bind/run/named.pid"; directory "/etc/bind"; auth-nxdomain no; allow-recursion { none; }; dnssec-enable yes; /* * Se houver um firewall entre você e os servidores de nomes que deseja * conversar, pode ser necessário descomentar a diretiva query-source * abaixo. Versões anteriores do BIND sempre faziam perguntas * usando a porta 53, mas o BIND 8.1 usa uma porta não privilegiada * por padrão. */ // query-source address * port 53; }; [...] |

Reinicie o BIND depois:

/etc/init.d/bind9 restart

(Se você estiver usando ISPConfig, suas alterações serão sobrescritas pelo ISPConfig. Para evitar isso, pegamos o arquivo de modelo named.conf /root/ispconfig/isp/conf/named.conf.master, modificamos como mostrado acima e salvamos o modelo modificado no diretório /root/ispconfig/isp/conf/customized_templates => /root/ispconfig/isp/conf/customized_templates/named.conf.master. Por favor, também modifique /etc/bind/named.conf como mostrado acima além disso.)

3 Verificando o BIND Novamente

Agora executamos a consulta do capítulo 1 novamente:

dig +short @ns1.example.com porttest.dns-oarc.net TXT

Se tudo correu bem, agora deve mostrar BOM em vez de POBRE, e deve usar mais de uma porta:

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“1.2.3.4 é BOM: 26 consultas em 4.4 segundos de 26 portas com desvio padrão 20195.32”
mh1:~#

Parabéns, você acabou de corrigir o BIND!

Você também pode executar o comando dig contra os servidores de nomes do seu ISP para descobrir se os servidores de nomes deles ainda são vulneráveis. Se forem, você deve instar seu ISP a atualizar seus servidores de nomes!