Segurança DNS: Hardening com Recurse e Rate Limit no Linux

A segurança da infraestrutura de rede moderna depende criticamente da robustez dos serviços de resolução de nomes. O DNS (Domain Name System) não é apenas um diretório telefônico da internet; é uma peça fundamental na arquitetura de qualquer servidor Linux. Quando mal configurado, o serviço de DNS pode se tornar um vetor de ataque massivo, facilitando ataques de negação de serviço distribuídos (DDoS), espionagem de dados e amplificação de tráfego. Este tutorial foca em duas técnicas essenciais de hardening Linux para servidores BIND9: a restrição rigorosa da recursão e a implementação de rate limit (limites de taxa). Ao aplicar essas configurações, você transforma seu servidor DNS de um alvo vulnerável em uma ferramenta resiliente e segura.

Entendendo os Riscos: Recursão Aberta e Amplificação DDoS

Antes de configurar qualquer diretiva, é crucial compreender a mecânica da ameaça. Um servidor DNS recursivo aberto permite que qualquer máquina na internet consulte o nome do domínio desejado, sem verificar se o cliente é originário de uma rede confiável. Atacantes exploram isso enviando consultas com o endereço IP da vítima spoofado (falsificado) como origem. O servidor responde à vítima com um pacote grande contendo o resultado da consulta, enquanto a vítima nunca solicitou tal dado. Isso resulta em uma amplificação de tráfego que pode sobrecarregar a largura de banda do alvo.

Além disso, servidores sobrecarregados por consultas excessivas tornam-se lentos ou indisponíveis para usuários legítimos. A configuração adequada da recursão e o rate limit mitigam ambos os problemas, garantindo que seu servidor responda apenas a clientes autorizados e dentro de limites sustentáveis.

Passo 1: Verificação do Ambiente e Backup

A administração Linux exige cautela. Antes de modificar arquivos de configuração críticos, você deve garantir que possui acesso root ou sudo e uma cópia de segurança íntegra da configuração atual. Isso permite a reversão imediata em caso de erro de sintaxe, que poderia impedir o reinício do serviço BIND.

Primeiro, verifique a versão instalada do BIND9:

named -v

Em seguida, realize um backup completo do diretório de configuração padrão do BIND. Em distribuições baseadas em Debian e Ubuntu, o caminho é geralmente /etc/bind/. No RHEL/CentOS/Rocky Linux, pode variar para /etc/named.conf.

sudo cp /etc/bind/named.conf.options /etc/bind/named.conf.options.bak
sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

Se estiver em um ambiente RHEL/CentOS:

sudo cp /etc/named.conf /etc/named.conf.bak

Passo 2: Restringindo a Recursão (Controle de Acesso)

A medida mais importante para um servidor DNS público é impedir que ele sirva como amplificador DDoS. Isso é feito restringindo quem pode realizar consultas recursivas. A diretiva allow-recursion define quais redes ou hosts podem solicitar resoluções completas. O padrão, se não especificado, muitas vezes permite recursão para todos, o que é inseguro.

Edite o arquivo de configuração principal. No Debian/Ubuntu, edite /etc/bind/named.conf.options. No RHEL/CentOS, as opções geralmente estão no final do /etc/named.conf.

sudo nano /etc/bind/named.conf.options

Dentro da seção options { ... }, defina a lista de clientes permitidos. Use ACLs (Listas de Controle de Acesso) para manter a organização. Se você não definiu ACLs previamente, pode especificar as redes diretamente.

acl "trusted-clients" {
    127.0.0.1;          // Loopback local
    192.168.1.0/24;     // Sua rede interna LAN
    ::1;                // IPv6 loopback
};

options {
    directory "/var/cache/bind";

    // Restringe a recursão apenas aos clientes de confiança
    allow-recursion { trusted-clients; };

    // Opcional: Restringir consultas gerais (query) se desejar um controle mais fino
    // allow-query { trusted-clients; };

    // Impede que o servidor atue como autoridade para zonas que não possui
    allow-transfer { none; };

    // Desabilita recursão por padrão em servidores de raiz ou cache públicos puros,
    // mas aqui estamos habilitando-a apenas para a ACL acima.
    recursion yes;

    dnssec-validation auto;

    listen-on-v6 { any; };
};

Nota Importante: Se seu servidor for um DNS público destinado a resolver nomes para toda a internet (como um resolvedor recursivo público), você deve remover a recursão ou usá-la com extrema cautela, preferencialmente protegida por chaves TSIG ou ACLs muito específicas. Para servidores corporativos ou domésticos que resolvem nomes para uma rede local, a configuração acima é o padrão ouro de segurança.

Passo 3: Implementando Rate Limit (Limites de Taxa)

Mesmo com a recursão restrita, seu servidor pode ser alvo de ataques de negação de serviço direcionados ou de scanners maliciosos tentando exaurir seus recursos de CPU e memória. O BIND9 possui um módulo nativo chamado rate-limit que permite controlar quantas consultas um cliente pode enviar dentro de um determinado período.

As diretivas de rate limit devem ser inseridas dentro da seção options. Vamos configurar limites conservadores para tipos de consultas comuns.

options {
    // ... configurações anteriores ...

    // Rate Limit Configuration
    // rate-limit {
        // Limita o número de respostas por segundo para um prefixo específico
        responses-per-second 10;

        // Limite de consultas únicas por segundo para um único IP (window em segundos)
        window 5;

        // Configurações específicas por tipo de resposta ou classe
        answers-per-second 10 { any; };
        nxdomain-per-second 10 { any; };
        cname-per-second 10 { any; };

        // Exceção para clientes confiáveis (ex: não limitar a rede local)
        exempt-clients { trusted-clients; };
    // };
};

Explicação dos parâmetros:

• responses-per-second: Define o limite global de respostas enviadas. Se excedido, o servidor começa a silenciar respostas para novos clientes.
• window: O período em segundos no qual as contagens são mantidas.
• answers-per-second / nxdomain-per-second: Limita especificamente respostas positivas ou negativas (NXDOMAIN). Ataques de força bruta frequentemente geram muitos NXDOMAINs ao tentar adivinhar subdomínios.
• exempt-clients: Crucial para não penalizar seus próprios usuários internos. Certifique-se de que a ACL trusted-clients definida anteriormente esteja incluída aqui.

Para servidores sob alta carga ou ameaça iminente, você pode ser mais agressivo. Para ambientes estáveis, os valores acima são seguros e não impactam a experiência do usuário normal.

Passo 4: Validação da Configuração

Nunca reinicie o serviço BIND sem validar a sintaxe. Um erro de digitação pode impedir que o daemon inicie, paralisando a resolução de nomes em toda a sua infraestrutura.

Execute o comando named-checkconf:

sudo named-checkconf /etc/bind/named.conf.options

Se o comando retornar silêncio, a sintaxe está correta. Se houver erros, ele indicará a linha exata e o problema. Corrija os erros antes de prosseguir.

Além disso, verifique as zonas configuradas:

sudo named-checkzone exemplo.com.br /etc/bind/zones/exemplo.com.br.db

Passo 5: Aplicando e Monitorando Alterações

Com a configuração validada, aplique as mudanças. Em sistemas systemd (a maioria das distribuições modernas), use o comando systemctl.

sudo systemctl restart named

Se o serviço falhar ao reiniciar, verifique os logs para diagnóstico:

sudo journalctl -u named -f --since "5 minutes ago"

Após a reinicialização, monitore o comportamento. Você pode verificar se o rate limit está ativo observando as estatísticas do BIND. Adicione statistics-channels à sua configuração de opções para permitir consultas via localhost:

statistics-channels {
    inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
};

Reinicie o serviço novamente e consulte as estatísticas:

dig @127.0.0.1 -p 8053 stats | grep rate-limit

Isso retornará contadores de consultas descartadas ou limitadas, confirmando que a proteção está operando.

Passo 6: Integração com Firewall (Firewall DNS)

A segurança em profundidade exige que o rate limit e as ACLs do BIND sejam complementados por regras de firewall. Embora o BIND possa filtrar clientes, o firewall é a primeira linha de defesa e consome menos recursos do processador para descartar pacotes maliciosos antes que eles alcancem a aplicação.

Para sistemas com iptables ou nftables, limite as conexões novas ao serviço DNS (porta 53 UDP/TCP) por origem. No entanto, tenha cuidado para não bloquear sua própria rede interna ou gateways de resolução.

# Exemplo iptables: Limitar a 20 novas conexões por segundo de uma IP específico
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --set
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 1 --hitcount 20 -j DROP

No caso do nftables</em>, a sintaxe é mais moderna e eficiente:</p> <pre><code>nft add rule inet filter input udp dport 53 ct state new limit rate over 20/second drop

Essa regra descarta pacotes que excedem 20 consultas por segundo, aliviando a carga no BIND.

Boas Práticas Adicionais de Hardening Linux

Além das configurações específicas do DNS, considere as seguintes práticas para fortalecer seu servidor:

• Execução como Usuário Não-Root: O BIND já roda por padrão como o usuário bind ou named. Nunca execute o daemon como root.
• Sandboxes e Chroots: Em sistemas mais antigos, o BIND era executado em um chroot para isolar o sistema de arquivos. Hoje, use namespaces Linux, cgroups ou contêineres (Docker/Podman) para isolar o serviço.
• Atualizações Constantes: Mantenha o BIND e o sistema operacional atualizados. Vulnerabilidades como CVEs conhecidos são corrigidos regularmente.
• DNSSEC: Assine suas zonas com DNSSEC (Domain Name System Security Extensions) para garantir a integridade e autenticidade dos dados, prevenindo envenenamento de cache.

Conclusão

A segurança DNS não é uma configuração "defina e esqueça". Ela requer monitoramento contínuo e ajustes finos. Ao restringir a recursão apenas aos clientes necessários e implementar rate limits, você elimina os vetores mais comuns de ataques de amplificação DDoS e garante a estabilidade do seu serviço de resolução de nomes.

Lembre-se: cada ambiente é único. Teste as configurações de rate limit em um ambiente de staging antes de aplicá-las em produção para garantir que não estão bloqueando consultas legítimas de usuários internos. A combinação de hardening no nível da aplicação (BIND) e na rede (Firewall) cria uma postura de defesa robusta, essencial para qualquer administrador Linux sério.

Aplique estas configurações hoje mesmo e transforme seu servidor DNS em um ativo seguro e confiável para sua infraestrutura.