Aplicar um template de firewall
Escolher o template pelo papel do servidor, preencher os grupos de IPs e aplicar sem se trancar fora.
Os templates montam um conjunto coerente de regras de uma vez. O risco não está neles — está em aplicar sem preencher os grupos de IPs que eles deixam vazios de propósito.
A política padrão é descartar
Tudo que não for explicitamente aceito é bloqueado. É por isso que aplicar um template sem preencher os grupos certos derruba o serviço.
Antes de começar
Vá em Segurança → Firewall, aba Estado, e anote o seu próprio IP — a tela mostra de onde você está acessando. Ele precisa entrar no grupo de administração.
Abra uma segunda sessão SSH em outro terminal e deixe aberta. É o seu teste de que não se trancou fora.
Se já houver configuração viva, confira na aba de pontos de restauração que existe um recente.
Onde clicar, passo a passo
Este é o roteiro que mais pode te deixar de fora do servidor
Um modelo aplicado ao kernel sem o seu endereço de gerência liberado corta o seu próprio acesso. A aba Estado mostra, no topo, de que endereço você está acessando — leia esse valor antes de aplicar qualquer coisa, e garanta que ele está no grupo de IPs de administração.
Segurança → Firewall, aba Estado. Aqui está o retrato do que existe hoje: qual motor está
ativo, quantas regras são gerenciadas pelo produto e qual arquivo é gerado.
Anote o número de regras. É como você vai saber, depois, se o modelo somou ou substituiu.
Os modelos são conjuntos prontos de regras para os cenários comuns de um provedor. Eles poupam o trabalho de escrever a política do zero — e, principalmente, de esquecer uma regra.
A escolha depende do papel do servidor, e errar aqui derruba serviço:
| Modelo | Use quando |
|---|---|
| Recursor + Auth — Hardened | O servidor faz as duas coisas: resolve para os assinantes e hospeda zonas próprias. É o caso da maioria |
| Recursivo only | O servidor só resolve. Fecha a porta 53 nas faixas do cliente |
| Autoritativo only | O servidor só hospeda zonas. Deixa a 53 aberta para o mundo, que é obrigatório para o autoritativo |
Os dois marcados como aditivo são diferentes: somam regras sobre o que já existe, em vez de definir a política. Servem para situações temporárias — migração de zonas e liberação da porta entre servidores do cluster.
Aplicar o Recursivo only num servidor que também hospeda zonas descarta as consultas autoritativas externas. Os domínios dos clientes param de resolver para o mundo.
O botão inicia o processo — mas ainda não muda nada. Vêm duas perguntas antes.
Só confirma a intenção. Continuar leva à pergunta que importa.
Esta é a decisão real do roteiro, e ela não é reversível por desfazer.
| Escolha | O que acontece |
|---|---|
| Substituir tudo | Apaga todas as regras e grupos atuais — inclusive o grupo de IPs banidos e o de IPs de administração — e deixa só os do modelo |
| Cancelar | Mescla: soma as regras do modelo e mantém as atuais |
Substituir tudo apaga os IPs banidos
O grupo de IPs banidos é alimentado pela tela de Segurança toda vez que alguém bloqueia um cliente. Substituir tudo zera esse trabalho acumulado.
Numa instalação nova, substituir é o certo. Num servidor que já roda, mesclar é quase sempre a resposta.
O rodapé do diálogo repete o que vale para as duas opções: nada muda no kernel ainda.
O modelo traz os grupos vazios de propósito — ele não tem como adivinhar as suas faixas.
Preencha antes de aplicar ao kernel, em especial:
- o grupo de IPs de administração, com o endereço de onde você gerencia o servidor;
- o grupo de faixas de cliente, se o modelo escolhido fecha a porta 53 nelas.
Aplicar um modelo restritivo com esses grupos vazios é exatamente o cenário que corta o seu próprio acesso.
Até aqui nada saiu do banco de regras. Aplicar Agora é o único ponto do roteiro em que o kernel muda.
O produto gera o arquivo, valida a sintaxe, aplica e faz verificação de saúde. Se o serviço parar de responder depois de aplicar, ele desfaz sozinho — a rede de proteção existe, mas não substitui conferir os grupos antes.
O botão Preview ao lado mostra o arquivo que seria aplicado, sem aplicar. Vale o clique quando a dúvida for "o que exatamente isso vai fazer".
Escolher o template
Aba Modelos (Templates). A escolha é pelo papel do servidor:
| Papel do servidor | Template |
|---|---|
| Resolve para os assinantes e responde zonas próprias ao mundo | DNS Recursor + Auth — Hardened (o recomendado) |
| Só resolve para os assinantes | DNS Recursivo only |
| Só responde zonas próprias | DNS Autoritativo only |
Se houver cluster, some também o template aditivo de cluster.
Não use o Recursivo only num servidor que também é autoritativo
Ele fecha o DNS para tudo que não estiver nos grupos de faixas de cliente. As consultas externas às suas zonas seriam descartadas. Nesse caso o template correto é o Hardened.
Aplicar
Inserir o template no banco
Clique em Aplicar no cartão do template.
Quando perguntar o modo, escolha mesclar — a opção de substituir tudo apaga também os grupos gerenciados por outras telas, como os IPs banidos pela detecção de segurança e os autorizados a A transferência de uma zona inteira do servidor primário para o secundário, protegida por TSIG e por lista de IPs..
Nada mudou no kernel ainda. O template só escreveu no banco.
Preencher os grupos de IPs
Aba Grupos de IPs (Sets). Dois pontos obrigatórios:
O grupo de administração nasce aberto, de propósito, para não travar o operador no primeiro uso. Troque pelos IPs de gerência — e inclua o endereço que você anotou no começo.
Se você usou o Recursivo only, preencha os grupos de faixas de cliente. Eles nascem vazios. Use o botão de importar da Lista de faixas de IP autorizadas a usar um recurso. No Made4DNS define quem pode fazer consultas recursivas. de recursão, que aparece porque o nome do grupo contém "cliente" — ele puxa as faixas que você já cadastrou no resolvedor.
Somar o template de cluster, se houver
Volte aos Modelos, aplique o aditivo de cluster e use Re-sincronizar peers. Sem ele, um template restritivo derruba a malha entre servidores em silêncio.
Conferir antes de aplicar
Aba Estado, botão Preview — mostra exatamente o que seria aplicado.
Aplicar de verdade
Aplicar Agora. Com cluster, escolha somente este servidor na primeira vez.
Testar dentro dos 120 segundos
Com o aviso de confirmação na tela, teste de verdade: abra uma nova conexão SSH e resolva um nome a partir de um cliente.
Se travou, não faça nada — em dois minutos o sistema desfaz sozinho, kernel e banco.
Se está tudo bem, clique em Confirmar.
Repita servidor a servidor
Em cluster, cada servidor exige a própria confirmação. Aplicar em todos de uma vez e não abrir a tela de cada um faz os outros reverterem sozinhos depois de dois minutos.
Se você se trancou fora
Não faça nada por dois minutos: a reversão automática devolve o acesso.
Se você já tinha confirmado por engano, entre pelo console do servidor no hipervisor e restaure um ponto de restauração durável.
Depois, se quiser
Ligue a proteção contra enxurrada na aba Estado e acompanhe o contador de descartes. Se ele subir com tráfego legítimo, aumente a taxa.