Tabela de conteúdo |
O DNS (Domain Name System - Sistema de Nomes de Domínios) é um sistema de gerenciamento de nomes hierárquico e distribuído operando segundo duas definições:
Existem diversos programas que cumprem esta função em servidores Unix Like, o mais famoso e conhecido é o BIND, também nomeado como NAMED em alguns sistemas. Vamos discutir a configuração e instalação do Bind em nossos sistemas preferidos.
A ferramenta dig é bem conhecida por possibilitar testes em DNSs, assim como a ferramenta nslookup, por questões de comodidade, vamos utilizar os exemplos com o dig. Os seguintes testes geralmente são feitos para saber se nosso serviço de DNS ou um servidor externo estão funcionando bem.
Para checar a resolução de IP por exemplo, usando como servidor de DNS o ns.exemplo.com.br usamos o comando:
# dig @ns.exemplo.com.br bibliotecaunix.org
e o retorno deve ser conter algo como:
;; QUESTION SECTION: ;bibliotecaunix.org. IN A ;; ANSWER SECTION: bibliotecaunix.org. 86400 IN A 67.18.208.175
a pergunta realizada e a resposta, existem outros campos que trazem outras informações, mas com isso, temos os dados que nos interessam neste momento.
É interessante sempre manter as informações reversas dos IPs para os servidores que os contém, isso é importante principalmente quando estamos montando um servidor de e-mail, em que uma das checagens é com relação ao reverso do servidor que cuida dos e-mails de um domínio. Veja como checar o reverso de um servidor de e-mail público conhecido:
# dig +short legacymail.ufms.br 200.129.192.67
com o IP em mãos:
# dig -x 200.129.192.67
e a resposta esperada:
;; QUESTION SECTION: ;67.192.129.200.in-addr.arpa. IN PTR ;; ANSWER SECTION: 67.192.129.200.in-addr.arpa. 86400 IN PTR legacymail.ufms.br.
veja que o IP aponta para o nome correto resolvido quando consultamos o nome, quer dizer que o IP e o seu reverso apontam para o local correto.
Muitas vezes desejamos saber qual o servidor de e-mail de determinado domínio, na verdade existem várias combinações que poderíamos usar com o dig, contendo os tipos que desejamos, como último exemplo, vamos ver quais os servidores de e-mail do Google:
# dig -t mx google.com
poderíamos substituir por qualquer domínio desejado e a reposta deve ser algo como:
;; QUESTION SECTION: ;google.com. IN MX ;; ANSWER SECTION: google.com. 900 IN MX 400 google.com.s9b2.psmtp.com. google.com. 900 IN MX 100 google.com.s9a1.psmtp.com. google.com. 900 IN MX 200 google.com.s9a2.psmtp.com. google.com. 900 IN MX 300 google.com.s9b1.psmtp.com.
contendo valores com as prioridades dos servidores.
Primeiro vamos criar um diretório para armazenar a lista de sites maliciosos:
# mkdir /etc/bind/blackhole
Agora vamos baixar as zonas dentro deste diretório:
# cd /etc/bind/blackhole # wget http://www.malwaredomains.com/files/spywaredomains.zones
Este arquivo de zonas aponta o domínio para o arquivo blockeddomain.hosts, que é um arquivo que vamos ter que criar, mas temos um pequeno problema aqui, este arquivo de spyware é um arquivo preparado para o FreeBSD, por isso devemos modificar o diretório /etc/namedb/ para /etc/bind/, podemos usar o comando sed para isso:
# sed -i 's/\/nameddb/\/bind/g' spywaredomains.zones
Vai alterar corretamente o caminho. Agora vamos editar o arquivo de domínios bloqueados:
# vim /etc/bind/blockeddomain.hosts
; This zone will redirect all requests back to the blackhole itself.
$TTL 86400 ; one day
@ IN SOA dns.exemplo.com.br. dns.exemplo.com.br. (
1
28800 ; refresh 8 hours
7200 ; retry 2 hours
864000 ; expire 10 days
86400 ) ; min ttl 1 day
NS dns.exemplo.com.br.
A 127.0.0.1
* IN A 127.0.0.1
poderia apontar para qualquer lugar, até por exemplo, para um servidor web que informasse do porque o usuário não conseguiu acessar determinado site.
Para que tudo funcione corretamente, você deve incluir a seguinte entrada no seu arquivo de configurações:
# vim /etc/bind/named.conf ... include "/etc/bind/blackhole/spywaredomains.zones"; ...
Reinicie o bind para ter certeza que está tudo funcionando:
# /etc/init.d/bind9 restart
Para automatizar o processo podemos criar um script que faça isso:
# vim /usr/local/bin/dnsbhupdate.sh #!/bin/bash cd /etc/bind/blackhole wget http://www.malwaredomains.com/files/spywaredomains.zones sed -i 's/\/nameddb/\/bind/g' spywaredomains.zones /etc/init.d/bind9 restart
E colocar isso no cron:
# crontab -e 0 * * * /usr/local/bin/dnsbhupdate.sh > /dev/null 2>&1
Poderíamos usar o IP de domínios do blockeddomain.hosts para um IP público, por exemplo: 200.129.192.35. E depois disso ativar o servidor WEB para entender as requisições, por exemplo, criar uma página com o seguinte conteúdo:
# vim /var/www/index.html
<!DOCTYPE html> <html> <head> <title>Nome da Sua Organização - TI</title> <script type="text/javascript">url = parent.window.location.href;</script> </head> <body> <h3>Notícia de Segurança</h3> Você foi redirecionado para esta página pois tentou acessar um site que reconhecidamente distribui <i>spyware</i>, <i>virus</i> ou outros softwares considerados maliciosos. <br><br> Como parte da Política de Segurança da Informação nós mantemos uma lista de sites potencialmente prejudiciais para ajudar na proteção dos nossos recursos computacionais. Isso também ajuda a proteger os usuários evitando a divulgação de informações pessoais para fins ilícitos como Spam ou fraudes. <br><br> Se você precisa acessar este site como um requisito, entre em contato com o departamento de TI responsável. </body> </html>
Agora toda vez que um usuário tentar se conectar em um site potencialmente perigoso, ele será redirecionado para o seu servidor WEB contendo a mensagem.
O bind9 no Debian e no Ubuntu tem uma característica interessante, assim como no FreeBSD, por padrão ele não vem enjaulado em chroot, é possível fazer isso, mas por enquanto, não vamos adicionar uma área para mostrar como fazer.
Primeiro vamos instalar os softwares necessários:
# apt-get install bind9
a versão no Debian é a 9.7.3 e no Ubuntu Server 10.04 é a 9.7, depois de instalado o pacote, será criado o usuário e grupo bind que vai gerenciar o serviço de dns e é gerado também, o arquivo /etc/bind/rndc.key
wrote key file "/etc/bind/rndc.key"
contendo a chave rndc. O serviço inicializado não contém qualquer domínio configurado.
Agora vamos configurar um domínio de exemplo com alguns serviços atrelados, eis a estrutura:
para este domínio nosso servidor será primário. Primeiro vamos dizer ao nosso bind que ele é master para esta zona, além de ativar as zonas da rfc1918. Edite o arquivo /etc/bind/named.conf.local:
include "/etc/bind/zones.rfc1918";
zone "exemplo.com.br" {
type master;
file "/etc/bind/db.exemplo";
};
apenas incluímos as redes privadas descritas na rfc1918 e dissemos para o bind que para a zona exemplo.com.br ele é do tipo master e o arquivo que contém suas regras é o db.exemplo. Vamos editar o arquivo e deixá-lo com o seguinte conteúdo:
$TTL 86400
@ IN SOA ns.exemplo.com.br. root.exemplo.com.br. (
2010061501 ; Serial: yyyy/mm/dd/nn [00..99]
10800 ; Refresh every 3 hours: 3h*60m*60s
900 ; Retry every 15 minutes: 15m*60s
604800 ; Expire after a week: 7d*24h*60m*60s
3600 ) ; Minimum ttl of 1 hour: 1h*60m*60s
IN NS ns.exemplo.br.
IN MX 10 mail.exemplo.br.
@ IN A 200.129.200.3
www IN A 200.129.200.4
mail IN A 200.129.206.5
quando você for configurar este arquivo, este exemplo mostra como funciona a criação de um domínio simples, mas sugerimos ler a documentação do BIND para entender algumas entradas. Por exemplo:
vamos reiniciar o serviço para carregar nossas alterações:
# /etc/init.d/bind9 restart
quando o serviço reiniciar, nos logs do sistema (/var/log/syslog) vai aparecer uma linha semelhante a abaixo:
Jun 15 20:00:07 vware01 named[10525]: zone exemplo.com.br/IN: loaded serial 2010061501
que significa que seu domínio foi carregado. Mas note que cometemos um pequeno erro, o servidor de e-mail ficou com o IP errado, deveria ser 200.129.200.5 não 200.129.206.5, vamos reeditar nosso arquivo para corrigir o problema:
$TTL 86400
@ IN SOA ns.exemplo.com.br. root.exemplo.com.br. (
2010061502 ; Serial: yyyy/mm/dd/nn [00..99]
10800 ; Refresh every 3 hours: 3h*60m*60s
900 ; Retry every 15 minutes: 15m*60s
604800 ; Expire after a week: 7d*24h*60m*60s
3600 ) ; Minimum ttl of 1 hour: 1h*60m*60s
IN NS ns.exemplo.br.
IN MX 10 mail.exemplo.br.
@ IN A 200.129.200.3
www IN A 200.129.200.4
mail IN A 200.129.200.5
este erro foi proposital e teve um objetivo, note que o Serial foi modificado, ou seja, toda vez que o arquivo do BIND for alterado, você deve alterar o serial para que os outros servidores entendam que ouve uma alteração nas configurações da sua zona.
Como exercício teste as consultas de DNS sugeridas no seu novo servidor e verifique se as resoluções estão acontecendo normalmente.
Para configurar o reverso de um domínio você deve ter em vista 2 coisas:
Para que o reverso funcione corretamente, vamos supor que a nossa rede pública seja:
Ou seja, todos os IPs deste range devem ter seus reversos corretamente configurados. Vamos supor o seguinte:
Com isso, vai existir uma entrada do tipo A de email para o IP que escolhemos. Geralmente servidores de email precisam que o reverso esteja configurado corretamente, por isso vamos criar uma nova zona para o reverso:
# vim /etc/bind/named.conf.local
...
zone "192.129.200.in-addr.arpa" {
type master;
file "/etc/bind/db-reverso.exemplo";
};
...
note que a rede desejada aparece invertida e o nome in-addr.arpa foi adicionado ao final, isso é importante e necessário, pois este é o caminho utilizado pelos root servers para resolução reversa. Agora o conteúdo do arquivo db-reverso.exemplo:
$TTL 86400
@ IN SOA ns.exemplo.com.br. root.exemplo.com.br. (
2010061501 ; Serial: yyyy/mm/dd/nn [00..99]
10800 ; Refresh every 3 hours: 3h*60m*60s
900 ; Retry every 15 minutes: 15m*60s
604800 ; Expire after a week: 7d*24h*60m*60s
3600 ) ; Minimum ttl of 1 hour: 1h*60m*60s
IN NS ns.exemplo.br.
IN MX 10 mail.exemplo.br.
1 IN PTR reverso01.exemplo.com.br.
...
130 IN PTR email.exemplo.com.br.
...
254 IN PTR reverso254.exemplo.com.br.
É uma boa prática definir todos os valores dos reversos com nomes padronizados e só modificar aqueles que forem utilizados, como foi feito com o email.exemplo.com.br. Um erro muito comum é quando esquecemos o ponto no final do nome que será apontado, se você esquecer isso, ele irá completar com o domínio FQDN e o nome pode ser resolvido de forma bem estranha ao esperado.
Agora basta reiniciar o bind para que as configurações entrem em atividade.
Agora vamos ativar um segundo servidor de DNS que vai servir como slave do servidor primário, ou seja, toda vez que uma informação for atualizada no master, o slave será notificado e atualizado.
Para isso primeiro precisamos alterar a nossa configuração anterior:
zone "exemplo.com.br" {
type master;
file "/etc/bind/db.exemplo";
};
e adicionar as informações de transferência e notificação:
zone "exemplo.com.br" {
type master;
file "/etc/bind/db.exemplo";
allow-transfer { IP_DO_SLAVE; };
allow-query { any; };
notify yes;
};
Ou seja, quando o master for modificado e o servidor bind for reinicializado, ele notificará o IP_DO_DNS_SLAVE e se tiveram mudanças, o slave vai puxar estas mudanças.
A instalação do slave é a mesma do servidor master, a diferença é que para o mesmo domínio exemplo.com.br vamos ter a entrada definida como:
zone "exemplo.com.br" {
type slave;
file "/etc/bind/db.exemplo";
masters { IP_DO_DNS_MASTER; }
allow-query { any; };
allow-notify { IP_DO_DNS_MASTER; };
};
A diferença aqui é que o tipo foi definido como slave, quem é o DNS master e de quem este servidor slave pode receber notificações. Pronto, reinicialize ambos os servidores de DNS:
# /etc/init.d/bind9 restart
Se você realizou alguma mudança no DNS master vai ver uma entrada parecida com esta nos logs:
May 23 08:24:47 ns named[9998]: transfer of 'exemplo.com.br/IN/public' from IP_DO_DNS_MASTER#53: connected using IP_DO_DNS_MASTER#60450 May 23 08:24:47 ns named[9998]: zone exemplo.com.br/IN/public: transferred serial 154 May 23 08:24:47 ns named[9998]: transfer of 'exemplo.com.br/IN/public' from IP_DO_DNS_SLAVE#53: Transfer completed: 1 messages, 78 records, 2460 bytes, 0.203 secs (12118 bytes/sec)
O que quer dizer que sua zona for corretamente transferida entre os servidores de DNS.
Quando você quer criar um DNS local que vai funcionar apenas como forwarder, ou seja, ele somente vai encaminhar requisições de resolução (e não vai necessariamente ser DNS de nenhuma zona/domínio), a configuração é muito simples, basta instalar o bind/named e depois configurar na seção de options dentro do named.conf:
# vim /etc/bind/named.conf
options {
...
forward only;
forwarders { 208.67.222.222; 208.67.220.220; };
...
};
As 2 configurações que interessam neste caso é a diretiva para encaminhar sempre (forward only) e os IPs dos DNS que receberam o encaminhamento destas requisições, no caso os 2 IPs acima são do OpenDNS.
Podemos fazer com que as requisições sejam vistas na rede de forma diferenciada, por exemplo, podemos criar zonas públicas que serão utilizadas para publicação de fato na Internet e zonas privadas, que somente a sua rede local poderá utilizar. As configurações serão feitas no arquivo named.conf, primeiro vamos criar ACLs contendo as subredes (vamos fazer isso somente para facilitar a criação das visões):
# vim /etc/bind/named.conf
...
acl rede_privada {
10.0.0.0/8;
172.16.0.0/12;
192.168.0.0/16;
};
acl rede_publica_dmz {
200.129.192.0/24;
200.129.193.0/24;
};
...
Ainda dentro do arquivo de configuração do named.conf, vamos agora criar as visões:
...
view "private" {
match-clients { localhost; rede_privada; rede_publica_dmz; };
allow-query { localhost; rede_privada; rede_publica_dmz; };
allow-recursion { localhost; rede_privada; rede_publica_dmz; };
recursion yes;
zone "exemplo.com.br" {
type master;
file "/etc/bind/master/private.exemplo.com.br";
allow-update { none; };
allow-transfer { none; };
};
include "/etc/bind/exemplo.default.zones";
include "/etc/bind/exemplo.master.zones";
include "/etc/bind/exemplo.slave.zones";
include "/etc/bind/exemplo.private.zones";
include "/etc/bind/blackhole/spywaredomains.zones";
};
view "public" {
match-clients { any; };
recursion no;
zone "exemplo.com.br" {
type master;
file "/etc/bind/master/public.exemplo.com.br";
allow-update { none; };
allow-transfer { slaves; };
};
include "/etc/bind/exemplo.default.zones";
include "/etc/bind/exemplo.master.zones";
include "/etc/bind/exemplo.slave.zones";
};
...
Temos 2 diferenças críticas aqui, a primeira é que as zonas privadas só foram adicionadas na visão privada e a segunda é que as zonas de spyware só foram adicionadas também na privada, pois não faria sentido resolver este tipo de zona na visão pública.
Um dos sistemas mais simples de configurar o DNS é o FreeBSD, pois ele já faz parte dos programas default do sistema, então para ativá-lo, basta rodar o comando abaixo:
# /etc/rc.d/named rcvar >> /etc/rc.conf
editar o arquivo /etc/rc.conf mudando o named_enable=NO para:
named_enable="YES"
e depois inicializar o serviço:
# /etc/rc.d/named start
a primeira vez que ele executar vai gerar o arquivo rndc.key
wrote key file "/var/named/etc/namedb/rndc.key"
e já estará funcionando com as configurações padrões. Nenhum domínio foi configurado até o momento. Uma detalhe interessante é que no FreeBSD todos as configurações ficam alocadas em /etc/namedb e em uma estrutura bem polida.
O CentOS/RedHat 5.5 tem um diferencial aqui, por padrão ele já vem preparado e facilita o uso de um ambiente chroot para o BIND (neste sistema chamado de named). Vamos instalar o software necessário:
# yum install bind bind-chroot
a versão do Bind utilizada é a 9.3.6. Feito isso precisamos configurar nosso ambiente.
Vamos configurar o serviço para atender ao seguinte ambiente:
primeiro precisamos criar nosso arquivo de configuração de zonas, vamos copiar o exemplo que vem no pacote do BIND:
# cp /usr/share/doc/bind-9.3.6/sample/etc/named.conf /var/named/chroot/etc/
diferente dos outros pacotes, este exemplo já vem preparado para trabalhar com visões, onde a visão internal se refere a como as máquinas na sua rede privada (LAN) enxergam as resoluções de nome e a visão external que são para os clientes fora da sua rede. É claro que é possível fazer as mesmas configurações em outros sistemas e vocês verão como, mas a priori o fato de já estar pronto para uso facilita um pouco.
Primeiro vamos copiar as outras entradas necessárias:
# cp /usr/share/doc/bind-9.3.6/sample/etc/named.root.hints /var/named/chroot/etc/ # cp /usr/share/doc/bind-9.3.6/sample/etc/named.rfc1912.zones /var/named/chroot/etc/
e os arquivos de configurações adicionais
# cp -r /usr/share/doc/bind-9.3.6/sample/var/named/* /var/named/chroot/var/named/
apenas para testar se tudo está ok, execute o comando abaixo e verifique que nenhum erro retornou:
# service named configtest
se tudo retornou certo, vamos configurar nosso ambiente. Vamos editar o arquivo
/var/named/chroot/var/named/exemplo.zone:
$TTL 86400
@ IN SOA ns.exemplo.br. root.exemplo.com.br. (
2010061502 ; Serial: yyyy/mm/dd/nn [00..99]
10800 ; Refresh every 3 hours: 3h*60m*60s
900 ; Retry every 15 minutes: 15m*60s
604800 ; Expire after a week: 7d*24h*60m*60s
3600 ) ; Minimum ttl of 1 hour: 1h*60m*60s
IN NS ns.exemplo.br.
IN MX 10 mail.exemplo.br.
@ IN A 200.129.200.3
www IN A 200.129.200.4
mail IN A 200.129.200.5
um detalhe muito importante é que como estamos trabalhando em um ambiente enjaulado, antes de realmente colocar em produção seu sistema, altere o dono e grupo dos arquivos:
# chown -R root:named /var/named/chroot
como nossa zona contém IPs públicos, vamos editar dentro da visão external no arquivo /var/named/chroot/etc/named.conf:
zone "exemplo.com.br" {
type master;
file "exemplo.zone.db";
};
execute novamente o configtest:
# service named configtest
e veja que agora está carregando a nossa nova zona:
zone exemplo.com.br/IN: loaded serial 2010061501
não esquecendo que toda vez que modificar o arquivo de configurações da zona é preciso atualizar o Serial. Vamos reiniciar o serviço:
# service named restart
note que ele vai falhar, e o erro no log será:
/etc/named.conf:99: configuring key 'ddns_key': bad base64 encoding
isso aconteceu, porque precisamos criar a chave secreta com o comando dns-keygen:
# dns-keygen Lmo2itzWnMMga3umirGHfbgbAW43M2SJYI1o0BoUiIyjPVmQuGorYiamgPGK
e copiamos essa chave gerada na entrada secret do ddns_key, no named.conf. Agora podermos reinicializar o serviço sem problemas:
# service named restart
Sugerimos como exercício testar a resolução de nomes, lembrando que como foi apenas configurada a visão externa, somente máquinas remotas conseguiram testar a resolução de nomes, o que por padrão é bloqueado, então não esqueça de liberar a porta 53 UDP para acesso externo.
Para instalar o serviço de DNS no CentOS 6 é necessário instalar o pacote do BIND, e mais alguns pacotes importantes, vamos lá:
# yum install bind bind-chroot
Instalamos o chroot para enjaular o bind para evitar que se um invasor conseguir quebrar o bind de alguma forma, ele vai ficar isolado somente ao ambiente do serviço.
Configurar o BIND no CentOS 6 ficou muito mais fácil que nas versões anteriores, pois agora está tudo unido em um pequeno número de pacotes. Ao instalar ele vai colocar todas as configurações em /var/named . Ele já vem com um arquivo de exemplo utilizando duas visões: interna e externa, e com suporte ao DNSSEC. Nossa configuração vai ativar o DNS tanto para IPv4, quanto para IPv6. Primeiro vamos copiar o arquivo de configuração do exemplo para o diretório correto:
# cp /usr/share/doc/bind-9.7.0/sample/etc/named.* /var/named/chroot/etc # cp -r /usr/share/doc/bind-9.7.0/sample/var/named/* /var/named/chroot/var/named/
com isso vamos ter os arquivos básicos de DNS dentro do ambiente enjaulado. O próximo passo é configurar o named.conf:
# vim /var/named/chroot/etc/named/named.conf
options
{
dump-file "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
allow-query { localhost; 10.0.1.0/24; };
allow-query-cache { localhost; 10.0.1.0/24; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
};
logging
{
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view "localhost_resolver"
{
match-clients { localhost; };
recursion yes;
zone "." IN {
type hint;
file "/var/named/named.ca";
include "/etc/named.rfc1912.zones";
};
view "internal"
{
match-clients { localnets; };
recursion yes;
zone "." IN {
type hint;
file "/var/named/named.ca";
};
include "/etc/named.rfc1912.zones";
zone "my.internal.zone" {
type master;
file "my.internal.zone.db";
};
zone "my.slave.internal.zone" {
type slave;
file "slaves/my.slave.internal.zone.db";
masters { /* put master nameserver IPs here */ 127.0.0.1; } ;
};
zone "my.ddns.internal.zone" {
type master;
allow-update { key ddns_key; };
file "dynamic/my.ddns.internal.zone.db";
};
};
key ddns_key
{
algorithm hmac-md5;
secret "use /usr/sbin/dnssec-keygen to generate TSIG keys";
};
view "external"
{
match-clients { any; };
zone "." IN {
type hint;
file "/var/named/named.ca";
};
recursion no;
zone "my.external.zone" {
type master;
file "my.external.zone.db";
};
};
feito isso, basta inicializar o serviço que vai funcionar corretamente:
# service named start Iniciando o named: [ OK ]
Se você quiser adicionar alguma zona, basta criar a zona e inseri-lá na visão correta, se a zona for interna (somente sua rede interna pode enxergar), você deve incluí-la na visão internal, se for externa na external, não esquecendo que agora com o IPv6 ativo, você deve ter entradas do tipo AAAA. Não esqueça de mudar o padrão para ler as configurações do chroot, pois por padrão ele vai ler o arquivo /etc/named.conf e não vai carregar nossas novas configurações.
--Brivaldo 22h08min de 5 de agosto de 2011 (AMT)