Servidor DNS seguro com Bind9 (Recursivo, Autoritativo e Reverso) + Fail2ban + nftables no Debian 10 Buster

BIND (Berkeley Internet Name Domain ou, como chamado previamente, Berkeley Internet Name Daemon) é o servidor para o protocolo DNS mais utilizado na Internet, especialmente em sistemas do tipo Unix, onde ele pode ser considerado um padrão de fato.
ln -s /var/cache/bind/master-rev /etc/master-rev
Ante de iniciar a instalação é preciso saber como funciona um DNS:

Requesitos:
Debian 10 Stretch – Instalação Limpa

DNS RECURSIVO
O DNS recursivo é responsável pela resolução de nomes, começando sempre com consultar recursivas nos servidores raízes. Para melhorar a eficiência e reduzir o tráfego DNS na Internet e aumentar o desempenho em aplicativos de usuário final, fazendo o cache DNS, armazenando resultados de consulta DNS por um período de tempo determinado na configuração (tempo de vida determinado pelo autoritativo do domínio consultado).

DNS AUTORITIVO
É o serviço DNS que possui autoridade sob um domínio. Assim como servidor ns1.remontti.com.br é o DNS autoritativo de meu domínio remontti.com.br, é ele que sempre vai responder qualquer subdomínio “hosts” ex blog.remontti.com.br.
E esse servidor que você vai apontar nas configurações de um domínio, exemplo registrado no registro.br.

DNS REVERSO
DNS atua resolvendo o nome do domínio/subdomínio para um endereço IP correspondente. Já o DNS Reverso ele resolve o endereço IP buscando o nome de domínio associado ao host.
Ou seja, quando temos disponível o endereço IP de um host e não sabemos o endereço do domínio(nome dado à máquina ou outro equipamento que acesse uma rede), tentamos resolver o endereço IP através do DNS reverso que procura qual nome de domínio está associado aquele endereço.
Os servidores que utilizam o DNS Reverso conseguem verificar a autenticidade de endereços, verificando se o endereço IP atual corresponde ao endereço IP informado pelo servidor DNS.
Isto evita que alguém utilize um domínio que não lhe pertence para enviar spam, por exemplo (pois isso que ele é importante para servidores de e-mail).

DICAS
– Para que o DNS Reverso funcione no registro.br é importante que você já tenha configurado o DNS autoritativo, e aguarde sua publicação antes de fazer a designação. (Normalmente demoram 4 horas)
– Se você é um provedor, o correto seria você ter dois servidores DNS em sua rede, uma Master e outro Slave. Neste tutoria foi explicar como criar os dois!

PERGUNTAS FREQUENTES:
Preciso montar dois servidores?
Sim/Não, para a configuração do DNS autoritativo/reverso são necessários apontar dois endereços, no entanto nada impede de configurar dois IPs no mesmo servidor. Em alguns caso vejo as pessoas virtualizar 2 servidores (apenas DNS) na mesma maquina de virtualização, se pensarmos que se o servidor de virtualização para nada adianta ter 2 servidores, neste caso quem sabe seria mais interessante ter alguma outra aplicação rodando com o servido slave (pensando pelo lado aproveitamento de hardware). Então vai da sua realidade.

Preciso separar o recusivo do autoritativo/reverso?
Não! Ao não ser que você seja um grande data center com centenas de domínios autoritativos não vejo o motivo para separa-los. Na maioria das vezes que vi isso acontecer quem fez isso é porque não sabe como fechar as consultas recursivas para o mundo. E é ai que neste tutorial entra o fail2ban como a cereja do bolo.

Vamos iniciar com a instalação do servidor Master, lembrando que para isso estou usando a Distribuição linux Debian 10, com uma instalação que eu chamo de limpa.

Ex.: ASN – CIDR/22

Nesse exemplo vou usar um bloco /22, porém mais a baixo vou deixar um exemplo também para você que é dono destes “/22” e vai delegar um bloco menor que /24 para outra empresa que queira ter seu próprio servidor DNS resolvendo o reverso desse bloco delegado.

Bloco recebido: IPv4 – 45.80.50.0/22 IPv6 – 2804:f123::/32
Domínio autoritativo:: remontti.net.br

Antes de mais nada o mínimo de conhecimento é saber realizar cálculos de sub-redes.

:: ipcalc ::

:: ip6calc ::

Para ilustrar “nossa rede” conto com os seguintes servidore:

45.80.50.0/22 IPv6 – 2804:f123::/32

ROUTER GW -> 45.80.50.1 / 2804:f123:bebe:cafe::1 (cpd)
SERV DNS MASTER -> 45.80.50.2 / 2804:f123:bebe:cafe::2 (ns1)
SERV DNS SLAVE -> 45.80.50.3 / 2804:f123:bebe:cafe::3 (ns2)
SERV WEB + FTP -> 45.80.50.4 / 2804:f123:bebe:cafe::4 (www,ftp)
SERV ZABBIX + phpIPam -> 45.80.50.5 / 2804:f123:bebe:cafe::5 (zabbix,phpipam)
SERV E-MAILS -> 45.80.50.6 / 2804:f123:bebe:cafe::6 (mail,imap,pop,smtp,mx,dkim)

Dentro da rede ainda conto com alguns blocos de IPs inválidos 192.168.0.0/16, 172.16.0.0/12, 100.64.0.0/10 e 10.0.0.0/8 utilizando NAT que por ventura também preciso autoriza-los a fazer consultas recursivas no servidores.

Tenha sua interface de rede configurada corretamente.

MASTER (NS1)

Pronto! O servidor recursivo já está funcionando, porém ele está aberto, e isso não é nada legal!
Você não vai querer “qualquer um” utilizando seu servidor para resolver nomes. Resolveremos isso mais a frente no arquivo named.conf.options.

Alteramos o DNS do servidor fazendo com que ele consulte em si próprio. Essa alteração deve ser feita no arquivo /etc/resolv.conf.

Para descobrir se seu servidor esta resolvendo nomes use o comando dig.

Retornará algo como:

Os arquivos de configuração do bind ficam no diretório /etc/bind/ e agora no Debian 10 Buster também separando os root servers em /usr/share/dns/

Iremos alterar o named.conf.options, o próprio nome já se auto descreve o que vamos encontrar nele.
Sempre gosto de preservar o arquivo original, então fizemos um backup antes de modifica-lo.

Aqui vai uma dica para que usa Windows + Putty, tome cuidado ao colar, principalmente quem usa Windows 10 “ele copia caracteres imaginários que você não vê!”.
Recomento usar o Bitvise SSH Client que é muito superior

Explicação comentada no arquivo.

Legal agora o servidor Recursivo já está funcionando e limitando os IPs que poderão realizar consultas ao mesmo.
Caso você não queria seu servidor sendo recursivo altere na ACL autorizados deixando apenas 127.0.0.1 e ::1.

Se seu servidor não tiver IPv6? (Que triste rsrsrs) Recomendo que desative o ipv6 no bind.

Adicione um -4 em OPTIONS.

Altere listen-on-v6 para none.

Toda alteração feita no bind para ter efeito é necessário restartar o serviço.

Se desejar remover os comentários do named.conf.options execute:

Para verificar se seu arquivo tem algum erro use o comando named-checkconf

Se nada retornar é porque não tem nenhum erro.
Vou deixar proposital mente faltando um “;” depois do 45.80.50.0/22. Veja o que retornou um altera dizendo que falta ponto virgula antes do IPv6, ou seja onde esta o IPv4/22.

Verifique também o status do bind para ver se o mesmo era rodando.

Verifique se está: “active (running)”

Antes configurar o Autoritativo e Reverso precisamos pensar na segurança do Recursivo.
Para isso utilizaremos o Fail2Ban e fazer algumas alterações para deixa-lo bem “nervoso”!

Fail2Ban + nftables

Fail2Ban é uma estrutura de software de prevenção de intrusões que protege os servidores de computadores contra ataques de força bruta, que opera monitorando arquivos de logs. Sendo o mais comum usado para bloquear endereços IPs selecionados que podem pertencer a hosts que estão tentando violar a segurança.

Como o iptables está sendo substituído por nftables começando com o Debian Buster, vamos configurar o Fail2Ban para usar o nftables como padrão.
Mas vou ir além em vez de usar o filtro multiport vou setar allports e modifica-lo para que quando uma tentativa de violação acontecer o Fail2Ban crie uma regra de firewall que dropa definitivamente o IP e não apenas fechando a porta do serviço para “invasor”.

Procure por “banaction = iptables-multiport” e “banaction_allports = iptables-allports” e altere seu valor para “nftables-allports”:

Altere o modo de bloqueio em nftables-allports.conf para fazer que ele de um “drop all”.

Procure por nftables_mode = meta l4proto e altere deixando seu valor vazio:

Em nftables-common.conf alteraremos o padrão de reject para drop

Procure por “blocktype = reject” e altere seu valor para “drop”.

Melhorias feitas, precisamos ativar o filtro para ler os logs do bind, porém ao ativar o filtro named-refused me deparei com seu não funcionamento, e quebrando a cabeça descobri que os logs do bind estão diferente e a expressão regular do filtro está errada. Os desenvolvedores do fail2ban já fizeram a correção, mas acredito que irá levar um tempo para o pessoal do Debian fazer um novo empacotamento.
A correção pode ser feita editando o arquivo /etc/fail2ban/filter.d/named-refused.conf

Porém como eu vou ser mais “bruto” no filtro. Vou criar nosso próprio filtro bind9, vamos lá!

Adicone no arquivo:

Ativamos o filtro que criamos, e definir um tempo de banimento por 24h você pode ajustar para mais se achar necessário. E “maxretry” que é a quantidade de tentativas para 1.

Adicione no arquivo:

Vale lembrar que o filtro de SSH já vem ativo por padrão em “/etc/fail2ban/jail.d/defaults-debian.conf”.

Precisamos fazer o bind gerar os logs com tentativas de consultas negadas (denied), incluído logging {…} no arquivo named.conf.

Crie o diretório onde o bind vai registrar seus logs e de permissão para que possa gravar nesta pasta.

É importante ativar o nftables na inicialização e restartar os serviços para que nossas configurações sejam interpretadas.

Para visualizar seu firewall use o comando:

Note que ja temos alguns IPs sendo dropado por tentativas de consulta no DNS e SSH.

Alguns comandos legais do fail2ban

Veja quais filtros estão ativos

Ex:

Para remover um IP que foi bloqueado basta:

Pronto agora já temos um servidor DNS com um nível de segurança bem elevado!

Autoritativo (ns1)

Agora é aquela hora que precisamos ter planejado o que iríamos fazer com nosso IPs recebidos.

Para ficar organizado vou criar a pasta master-aut onde ficará os arquivos de hosts dos domínios autoritativos.

Crie o arquivo remontti.net.br.hosts na pasta master-rev. Ajuste remontti.net.br para seu domínio.

Chamaremos a zone remontti.net.br em named.conf.local

Adicione ao final do arquivo:

De permissões ao diretório/arquivo criados

Restart o serviço.

Testamos agora para ver se está resolvendo nosso domínio.

Testes:

Seu autoritativo já está funcionado, você já é possível registrar seu domínio (claro ainda falta o slave).

Neste momento você pode verificar no registro.br se seu servidor já tem autoridade sobre o domínio que configurou.
Acessando: Ferramentas Registro BR

Se o STATUS for “Autoridade sobre o domínio” parabéns suas configurações estão respondendo corretamente.

Reverso (ns1)

Obs: Para fazer a Delegações de DNS reverso do seu bloco, é importante que você já tenha configurado no registro.br seu DNS autoritativo.

O bloco 45.80.50.0/22 será necessário quebrar em 4 blocos /24 tendo uma configuração para cada /24 Como já planejado no autoritativo vamos ter que dar nomes a todos os IPs. Vale lembrar que todos esses nomes de hosts é permitido apenas um nome por IP, e cada nome desses deve ser configurado no autoritativo.

Primeiro arquivo/24 45.80.50.rev

Preste atenção em 50.80.45.in-addr.arpa. essa linha ela deve ser alterada com o inverso do seu IP.
Outra coisa importante é o serial (2019071900) ele esta presente em todos os arquivos e deve ser alterado toda vez que for alterado. Ele segue o padrão [ano-mes-dia-sequencial]. É fundamental altera-lo para que o servidor slave copie sempre que tiver uma alteração.

Não podemos esquecer nosso reverso do IPv6! Antes que alguém pergunte (novamente) posso configurar o reverso de todos os IPv6? Bom você precisa saber que precisa resolver 79.228.162.514.264.337.593.543.950.336 (2^96) endereços IPv6, e isso é algo quase impossível! Informaremos apenas os nomes a ipv6 fixos.

Este site http://rdns6.com/hostRecord pode ser bem útil para gerar seus PTRs.
Para finalizar acertando as permissões.

Precisamos informar nossas zonas reversas no named.conf.local, como estamos configurando nosso servidor master essas zonas serão do tipo (type) master e para informar o arquivo onde está a configuração da zone usamos o parâmetro file /caminho-completo/arquivo

Adicione ao final do arquivo:

Para ficar fácil acesso criamos uma atalhos das nossas pastas master-* dentro de /etc/bind

Restart o serviço e veja se esta rodando sem erros.

Vamos ver se ele já está resolvendo nosso IP então?

Como pode ver todos os endereços estão resolvendo seus nomes.

Reverso pronto!

Atualizando ROOT SERVERS

Para finalizar o master vamos fazer uma atualização no root server que na versão do debian 10 buster passou a ser /usr/share/dns/root.hints. A vesão instalada é de 13/03/2019 “last update: March 13, 2019”

Para obter uma versão mais recente, iremos mover nosso arquivo root.hints e baixar um novo.

Pode editar o arquivo /usr/share/dns/root.hints e verificar qual é a ultima atualização, (hoje 19/07/2019) ele esta: “last update: July 03, 2019”. Reinicie o serviço para ter efeito.

Parabéns! Seu servidor master está pronto!

SLAVE (ns2)

Praticamente o processo se repete, com algumas alterações sendo necessário apenas configurar:
named.conf (Gerar log)
named.conf.local (Incluir as zonas)
named.conf.options (Setar nossas opções)

Alterar o DNS do servidor:

No named.conf.options unica coisa em relação ao master é que vai alterar allow-transfer para none e remover o also-notify.

Para organizar criamos duas pastas slave-rev e slave-aut é importante dar permissões para o usuário bind, pois ele precisa importar as configurações do master e vai escrever nelas.

Não é mais necessário criar os arquivos, esses serão transferidos do servidor master. Basta informarmos em nossas zonas do arquivo named.conf.local, que serão do tipo (slave) e apontaremos o IP do master para que nosso servidor slave faça a transferência do master.

Restart o serviço verifique se não teve nenhum erro e verifique dentro dos diretórios slave-aut/slave-rev se os arquivos foram criados.

Para ficar fácil acesso criamos uma atalhos das nossas pastas slave-* dentro de /etc/bind

Se os mesmo foram criados seu DNS já está praticamente pronto!

Volte o tutorial e refaça a parte:
Fail2Ban + nftables
Atualizando ROOT SERVERS
Isso é primordial para segurança do servidor!

Gostou?


Se quiser fazer uma doação para o café ficarei muito feliz pelo seu reconhecimento!
Banco 260
Nu Pagamentos S.A
Agência 0001
Conta 9363371-5
CPF (Solicite)

Se não puder doar pode deixar seu agradecimento nos comentário também ficarei feliz em saber que ajudei. Se tiver qualquer pergunta deixe-a também. Se preferir entrar em Contato clique aqui.

Ahhh não terminei, ainda falta a configuração do nosso /28.

Reverso de blocos menores que /24 – Ex.: CIDR/28

Antes de mais nada você deve ler ao menos como foi configurado o /22, pois será necessários que você compreenda e faça também o procedimentos:
Fail2Ban + nftables
Atualizando ROOT SERVERS

Vamos supor que você recebeu um /28 e queira ter seu reverso respondendo sobre esses bloco.
A primeira coisa que você precisa saber que isso só será possivel se o dono do ASN fizer a configurações em seu servidor DNS (rfc2317), não basta ele simplismente ir la no registro.br e delegar esse /28 para você, e é claro que ele também precisa fazer isso!
Se ficar em dúvidas recomendo ver que assista: DNS e DNS Reverso (~20min fala sobre isso)

Então se você é o responsável pelo ASN você deve fazer o seguinte na configuração no seu arquivo reverso. No exemplo anterior deixamos já o 45.80.51.64/26 para esses casos, e no exemplo vamos delegar um /28 para o “Provedor do José”.

Configuração feita pelo o dono do ASN, vamos as configurações do José que recebeu o bloco /28, e quer seus DNS respondendo por eles. Vamos supor que 45.80.51.66 e 45.80.51.67 sejam seu servidores DNS Master/Slave.

:: Autoritativo ::

:: Reverso ::

:: Zonas ::

Gostou?


Se quiser fazer uma doação para o café ficarei muito feliz pelo seu reconhecimento!
Banco 260
Nu Pagamentos S.A
Agência 0001
Conta 9363371-5
CPF (Solicite)

Se não puder doar pode deixar seu agradecimento nos comentário também ficarei feliz em saber que ajudei. Se tiver qualquer pergunta deixe-a também. Se preferir entrar em Contato clique aqui.

Abraço!

Rudimar Remontti

Trabalho atualmente como Gerente de Redes em um Provedor de Internet no Rio Grande do Sul.

Você pode gostar...

7 Resultados

  1. Excelente tutorial. Uma dúvida, você que o bind como recursivo tem desempenho melhor que o unbound.

  2. Wando Santos disse:

    Caro Rudimar Remontti, primeiramente quero parabeniza-lo pelo tutorial e pelo blog, pessoas como você que propaga conhecimento faz do mundo um lugar melhor. Também gostaria de saber qual o procedimento para que uma página web hospedada em servidores de terceiros funcione após a configuração dos servidores DNS como descrito neste tutorial. Pois, após configurar-lo e cadastrar no registro.br os ns, o site parou de funcionar.

  3. Paulo Jr Andrade disse:

    Bom dia Rudimar, primeiro parabéns pelo tutorial. Admiro muito seu trabalho e auxilio a nós pobres ignorantes rsrsrs
    Rudimar, para eu ter um autoritativo, vejo q vc setou um servidor de email… é necessário? Se sim você tem um tutorial para criar um básico, mas funcional.
    Pois já montei um autoritativo usando o metodo anterior que você postou, porem em alguns casos estou tendo retorno de erro

    ** server can’t find dns1.xxxx.com.br: NXDOMAIN

    seria falta de servidor de email ???

  4. Paulo Morais disse:

    Excelente material, muito didático parabéns pelo conteúdo, seu blog ajuda muito com tantos detalhes, espero que atualize todos os posts, gostei demais desse update para o Buster.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *