Bind versão 9: Procedimento de Instalação e Configuração

Thiago Alves da Silva <thiago@rnp.br>>

Rede Nacional de Ensino e Pesquisa (RNP)

Resumo
1. Introdução
1.1 Onde encontrar?
1.2 Requisitos
2. Compilação
3. Segurança com chroot
3.1 Criação de usuário e grupo
3.2 Criação da árvore de diretórios e arquivos necessários
3.3 Teste de configuração
4. Configurações do BIND
4.1 Seção "acl"
4.2 Seção "options":
4.3 Seção "server"
4.4 Seção "logging"
4.5 Seção "view":
4.6 Seção "zone":
4.7 Finalização
5. Ferramentas úteis
5.1 named-checkconf
5.2 named-checkczone
6. Dicas úteis
6.1 Escondendo a versão do BIND
6.2 "warning" com o named-checkconf
7. Conclusão
Referências bibliográficas

Resumo

O objetivo deste documento é mostrar quais foram as principais mudanças da versão 9 em relação a versão 8 do software BIND, bem como a maneira correta de se configurar um servidor levando em consideração essas mudanças, segurança e desempenho. Esta fora do escopo deste documento a explanação do serviço DNS, como ele funciona e para que serve.

1. Introdução

Muitas foram as melhorias e mudanças nesta nova versão do BIND, entre elas podemos citar:

Suporte a IPv6;
DNSSEC e TSIG (Funções de segurança);
Suporte a hardware com multiprocessadores;
Dynamic update para uso em redes DHCP;
Novos tipos de registros (RR – Resource Record);
IXFR – Transferência de zonas incremental;
Views (Permite várias visualizações do espaço de nomes);
Etc.

1.1 Onde encontrar?

O software BIND se encontra na versão 9.1.2.

Código fonte: ftp://ftp.isc.org/isc/bind9/9.1.2/bind-9.1.2.tar.gz

Assinatura PGP do código fonte: ftp://ftp.isc.org/isc/bind9/9.1.2/bind-9.1.2.tar.gz.asc

Chave Pública PGP do ISC: http://www.isc.org/ISC/isckey.txt

1.2 Requisitos

O código fonte do software já inclui os fontes do pacote de bibliotecas criptográficas OpenSSL necessários para as funções de segurança disponíveis (DNSSEC e TSIG), mas para uma melhor performance das operações de criptografia é indicado que o pacote seja instalado separadamente e configurado através da opção do autoconf:

#./configure --with-openssl=PATH

Site oficial OpenSSL - www.openssl.org

2. Compilação

A plataforma utilizada foi SPARCStation 20 com sistema operacional SUN Solaris 8 e NetFinity 3500 com sistema operacional OpenBSD 2.8. A lista de sistemas compatíveis esta em: http://www.isc.org/products/BIND/bind9.html.

Após baixar o arquivo e descomprimi-lo vem a tarefa de compilação. Existem várias opções que podem ser usadas para compilar o BIND 9.1.2, para maiores informações, consulte:

$ ./configure --help

Iremos usar as seguintes opções:

$./configure --with-openssl=/usr/ssl --sysconfdir=/etc
$ make
$ su root

Importante: Antes de instalar os binários e bibliotecas recomendamos realizar o backup de todos os arquivos relacionados ao BIND que se encontram na máquina.Isso é um texto simulado, indicando o tratamento do texto.

named.conf
Diretório do BIND. Ex.: /usr/local/bind
Binários: named, ndc, named-xfer, dig e outros.

# make install

3. Segurança com chroot

Para tornar seu sistema mais seguro contra possíveis invasões o ideal é fazer com que o daemon do BIND rode em um ambiente protegido, mais conhecido como "in jail", e também como um usuário não privilegiado..

A seguir estão os passos que devem ser tomados para a criação desse ambiente seguro:

3.1 Criação de usuário e grupo

Crie o usuário que será usado e o grupo ao qual ele pertencerá.

Nesse exemplo usaremos o usuário "named" e grupo "named".

3.2 Criação da árvore de diretórios e arquivos necessários

É importante lembrar que as modificações citadas abaixo não se referem aos arquivos principais do sistema, deve-se apenas usá-los como base ou partir do zero. O que queremos dizer é que não se deve mexer, por exemplo, no "/etc/passwd".

Os arquivos e diretórios devem ser criados sob o diretório que será designado raiz, em nosso exemplo "/var/named".

dev/:
null

Para criar esse arquivo especial use o comando "mknod":

Exemplo:

# mknod null c x y

onde "x" e "y" são o "minor number " e o "major number", respectivamente.

Dica: Para descobrir os valores corretos de "x" e "y", faça:

# ls -l /dev/null

os valores serão listados no lugar do tamanho do arquivo.

etc/ : passwd (somente com root e named e senha igual a '*')
group (somente com sys e named)

shadow ou master.passwd (Somente com root e named e senha igual a `*´.)
named.conf
resolv.conf
localtime (link simbólico para o arquivo de `time zone´)

usr/ :
lib/ - Devem ser colocadas nesse diretório todas as bibliotecas usadas pelo binário `named´.

share/zoneinfo/Brazil/East (Arquivo de `time zone´ usado)

Dica: Para descobrir as bibliotecas use o comando "ldd":

# ldd named

Resultado:

named lcrypto.2 => /usr/lib/libcrypto.so.2.4 (0x40182000)
lc_r.3 => /usr/lib/libc_r.so.3.1 (0x4022b000)

3.3 Teste de configuração

Com a configuração já feita precisamos testar se tudo está perfeito, para isso vamos executar o comando "chroot":

# chroot /var/named /usr/local/sbin/named -u named -g

Esse comando irá executar o daemon do BIND "enjaulado", como usuário "named" e no modo de depuração. A partir disso pode se constatar erros e realizar os acertos necessários.

Durante os testes alguns erros surgiram:

"No ld.so" – significa que a biblioteca "ld.so" esta faltando no diretório dentro do ambiente seguro, ou seja, em /var/named/usr/lib ou /var/named/usr/libexec, dependo do sistema operacional;

"User 'named' unknown" – Em sistemas BSD é necessário que o arquivo master.passwd também esteja no diretório "etc/", e mais, que o comando "pwd_mkdb" seja executado para a criação dos arquivos de contas do sistema:

# pwd_mkdb -d /var/named/etc /var/named/etc/master.passwd

4. Configurações do BIND

Com os arquivos instalados vem o momento da configuração de várias diretivas do software. O arquivo de configuração é o named.conf e deve ser criado no diretório especificado no momento da compilação (--sysconfdir=DIR), no nosso caso "/etc".

Neste exemplo que segue iremos mostrar as configurações vitais de um servidor DNS, logging, zonas, servidores secundários, diretivas de segurança e outros.

Algumas diretivas são, nesta versão, obrigatórias e precisam ser configuradas para que o servidor possa ser inicializado:

"$TTL" – Cada arquivo de zona deve conter essa diretiva;

Usado como padrão para todos os registros que não possuem TTL especificado. Deve constar na primeira linha do arquivo de zona.

"Serial Number" – O número serial deve ser um valor inteiro (Integer);

Versões anteriores a 9 permitiam usar o números seriais como este: "3.002".

Ocorreram muitas modificações no arquivo de configuração named.conf. Para saber detalhadamente quais foram as mudança de sintaxe, novas opções e opções que não são mais suportadas, pesquise na documentação distribuída com o BIND:

Caminho relativo: "doc/misc/options" ou em "doc/arm"

Para uma melhor explicação do named.conf foi feita uma divisão em seções, onde cada seção trata de um tipo de configuração: opção de configuração, logging, zonas e outras.

4.1 Seção "acl"

Com as ACL's (Access Control Lists) podemos criar listas de endereços IP's e designarmos nomes a essas listas, com o único objetivo de quando formos nos referenciar a endereços IP usarmos nomes em vez de números. Algumas acl's já existem e podem ser usadas:

any – Todos os hosts;
none – Nenhum host;
localhosts – Todos os IP's das interfaces da máquina;
localnets – A rede inteira a qual a máquina faz parte;

Outros exemplos:

acl intranet {
200.1.2.0/24;
200.1.3.0/24;
};

acl slaves {
200.4.5.6/32;
200.5.6.7/32;
};

4.2 Seção "options":

4.3 Seção "server"

Master - Deve ser configurado no servidor primário:

server 200.2.1.1 {
  provide-ixfr yes;
  transfer-format ( many-answers );
};

Slave - Deve ser configurado no servidor secundário:

server 200.2.1.2 {

  request-ixfr yes;

};

A transferência de zona incremental (IXFR) tem como finalidade diminuir a quantidade de informações trocadas, transferindo somente as mudanças feitas nas zonas do servidor primário para o servidor secundário.

Com essa configuração estamos dizendo que o servidor primário fornecerá esse recurso de transferência e o servidor secundário sempre que possível utilizará. Quando, por algum motivo, o servidor primário recusar uma IXFR, uma AXFR, transferência de zona convencional, será realizada.

4.4 Seção "logging"

Registro das mensagens do BIND. É importante saber que somente entrará em vigor as opções de logging depois que todo o arquivo named.conf for lido e o servidor for inicializado, antes disso as mensagens de erro serão enviadas para o sistema de syslog.

logging {
  channel "named_log" {
     syslog local3;
     severity info;
};

category "security" {
   "named_log";
};

category "xfer-out" {
  "named_log";
};

category "xfer-in" {
  "named_log";
};

category "general" {
  "named_log";
};

O registro de logs no BIND 9 é divido da seguinte forma:

"channel" – usado para especificar onde e que tipo de informação deve ser registrada – níveis (error, info, dynamic, etc). Nele você pode configurar o BIND tanto para usar o syslog, como um arquivo qualquer. No nosso exemplo utilizamos a categoria "local3" do syslog.
"category" – categorias de log do BIND. Existem várias categorias que podem ser usadas, tais como: security, xfer-out, notify, xfer-in, network, etc. Como os próprios nomes dizem, em security – informações de segurança, em notify – notificações de mudança na zonas primárias, etc.

Diante disso especificamos como queremos registrar (channel) e o que queremos registar (category): erros, informações de depuração, etc.

Alguns problemas foram detectados e reportados ao time de desenvolvedores do BIND, mas até a data da publicação desse tutorial não havíamos obtido respostas. Um dos problemas diz respeito ao modo como o novo BIND registra os eventos, por exemplo, a categoria "xfer-out" deveria registrar as transferência de zona que são enviadas pelo servidor, mas isso não acontece, só conseguimos registrar tais eventos com o nível de log igual a "severity debug 6", em "channel". Isso se torna inviável visto que muitas outras informações também são registradas, informações desnecessárias.

Outra questão importante diz respeito ao conteúdo que é registrado. Somente informações superficiais são registradas. Por exemplo, se alguém tentar realizar uma transferência de zona, somente a mensagem "< IP#Porta > zone transfer denied" irá ser registrada. O nome da zona não constará nos logs. Novamente, só conseguiremos tal feito se utilizarmos nível de depuração igual a 6.

Em nosso exemplo usamos o nível "info" para podermos registrar as informações das categorias segurança, transferências de zona e "general" – informações que não estão classificadas em nenhuma das outras categorias disponíveis. Fica a critério do administrador o modo de log do BIND.

Como também, pretendemos utilizar o BIND em um ambiente seguro, não poderíamos mais contar com o syslogd, pois não teríamos mais o socket unix "/dev/log" que é usado para receber as entradas de log.

Isso pode ser contornado utilizando versões recentes do syslogd, onde um outro socket para recebimento de informações pode ser utilizado na sua inicialização. Com a opção "-a" ou "-l", dependendo da plataforma, você especifica onde se localiza o socket adicional:

# syslogd -a /var/named/dev

Outra forma seria fazer com que o BIND registre os logs em arquivos, mas ficaríamos impossibilitados de usar um servidor de logs (loghost).

4.5 Seção "view":

Com essa nova opção de configuração pode-se fazer hoje o que antes era necessário com dois ou mais servidores DNS.

A idéia principal por detrás desta nova opção é permitir que possa ser configurado o que se conhece como "split DNS", ou seja, separar em dois ou mais servidores DNS os registros que podem ser acessados por toda Internet e os que somente são de interesse da empresa. Isso é usado principalmente em redes "desmilitarizadas", onde o servidor que se encontra na DMZ, de acesso publico, contém somente os registros dos hosts "visíveis" na Internet e o interno, com os registros da rede interna.

Bastante útil, também, em sites que implementam NAT.

Com a configuração abaixo ficará mais claro o entendimento deste novo recurso.

view "public" IN {
  match-clients { any; };
  zone-statistics yes;
  recursion no;
  zone "rnp.br" {
    type master;
    file "rnp-externo.br";
};
};

view "private" IN {
  match-clients { 200.1.2.0/24; };
  zone-statistics yes;
  recursion yes;
  zone "rnp.br" {
    type master;
    file "rnp-interno.db";
};
};

Neste exemplo, a zona "rnp-externo.db" contém o mapeamento dos hosts públicos e pode ser acessada por todos. Já a zona "rnp-interno.db" somente é acessada pelos hosts internos, ou seja, todos da rede 200.1.2.0.

Se nenhuma "view" for especificada, o BIND tratará, por default, as zonas como sendo da classe IN (Internet). Esse fato é importante, pois voltaremos a falar sobre isso na seção de "Dica útil".

Dentro das "views" são especificadas a configuração das zonas primárias e secundárias.

4.6 Seção "zone":

Configuração das zonas as quais o servidor responderá. Nela se configura as zonas primárias, secundárias, reversos e outros tipos. Também deve constar nessa configuração a zona "." do tipo "hint", raiz da Internet.

zone "." {
  type hint;
  File "named.root";
};

zone "0.0.127.in-addr.arpa" {
  type master;
  file "127.0.0.db";
};

zone "1.2.200.in-addr.arpa" {
  type master;
  file "200.2.1.db";
};

zone "rnp.br" {
  type master;
  file "rnp.br";
};

4.7 Finalização

Após a configuração deste arquivo, criação dos arquivos de zona, inclusive os de reverso, é necessário que se obtenha a versão mais atual do arquivo (named.root) que contém o nome dos servidores de mais alto nível, responsáveis pelo domínio raiz (".").

Para tal visite:

ftp://rs.internic.net/domain

Com o ambiente seguro e o arquivo de configuração criados, edite os arquivos de inicialização do sistema para que o daemon possa ser inicializado, acrescentando a seguinte linha:

# named -t /var/named -u named

Parâmetros usados

-t - indica qual será a raiz do ambiente seguro;
-u - roda o daemon do BIND como o usuário especificado.

5. Ferramentas úteis

Juntamente com o BIND 9 é distribuído várias ferramentas que ajudam a solucionar problemas de configuração, além de outras já conhecidas.

5.1 named-checkconf

Verifica a sintaxe do arquivo de configuração do BIND.

# named-checkconf [arquivo]

5.2 named-checkczone

Verifica a sintaxe e consistência dos arquivos de zona.

Sintaxe:

named-checkzone [-dq] [-c class] zona [arquivo]

Exemplo:

# named-checkzone rnp.br rnp.db

Irá verificar se o arquivo de zona "rnp.db" está correto para a zona "rnp.br".

6. Dicas úteis

6.1 Escondendo a versão do BIND

A maneira mais simples de ocultar aos olhos dos outros a versão do seu sistema é incluindo em options a cláusula version:

version "Not Available";

Mas para podermos ir além disso e registrar as consultas à versão devemos criar uma zona especial que conterá a seguinte configuração:

view "version" CHAOS {
  match-clients { any; };
  recursion no;
  zone "." {
    type hint;
    file "/dev/null";
};
zone "bind" chaos {
  allow-query { localhost; };
  type master;
  "file bind.db";
};
};

Como vimos anteriormente, o BIND tratará todas as zonas como pertencendo a uma única "view", se essa não for especificada, de classe IN. Para que possamos então inserir uma zona de classe diferente, CHAOS, precisamos criar uma "view" própria, e foi o que fizemos. Além disso, a zona "." é obrigatória para todas as "views". Após configurar uma "view" é necessário que todas as outras zonas também façam parte de uma.

6.2 "warning" com o named-checkconf

Após executar o comando "named-checkconf" o seguinte aviso é emitido:

"the default for the 'auth-nxdomain' option is now 'no'".

Nesta versão a opção auth-nxdomain é por default desligada, para evitar essa mensagem de aviso acrescente esta linha na seção "options" do named.conf:

auth-nxdomain no;

7. Conclusão

Algumas funcionalidades não foram abordadas neste documento que visou principalmente a migração da versão 8 para a 9 do software BIND, principais diferenças, aspectos de segurança e melhorias.

Entre essas funcionalidades estão as que trazem mais segurança ao serviço de DNS (DNSSEC e TSIG) e suporte a IPv6. Com toda a certeza depois que essas funcionalidades tiverem sido testadas um outro documento será produzido.

Com os problemas referentes aos logs esperamos que os desenvolvedores do BIND possam corrigi-los, pois as informações de transferência de zonas e consultas recusadas são fundamentais para auditorias. Caso alguém não tenha paciência para esperar, o fonte esta a disposição para ser alterado.

Referências bibliográficas

[1] Documentação fornecida com o software ; Em bind-9.x.x/doc/.

[2] Site oficial: http://www.isc.org/products/BIND

[3] Topics for System Administration, 1 - What's New in BIND9 – LISA 2000; Evi Nemeth – University of Colorado;CAIDA – San Diego Supercomputer Center, UC San Diego;

[4] Chroot-BIND HOWTO; http://www.losurs.org/docs/howto/Chroot-BIND.html Scott Wunsch, scott at wunsch.org;