O DNS costuma ser tratado como um detalhe de configuração — só o endereço que aponta para onde o site ou sistema está hospedado. Mas, na prática, é uma das primeiras coisas que um atacante examina: um registro mal configurado pode expor um painel administrativo, um servidor de backup ou uma VPN diretamente na internet, sem nenhuma camada de proteção entre o atacante e o sistema.
Hospedar o DNS na Cloudflare resolve o problema de disponibilidade e performance, mas o maior ganho para a maioria das empresas que atendemos está nas camadas de segurança que vêm junto — algumas ativas por padrão, outras que exigem configuração deliberada. Este artigo percorre as principais, com foco especial no Cloudflare Access, a peça que mais muda a forma como uma equipe de TI expõe sistemas internos com segurança.
O proxy como primeira camada
Quando um registro DNS fica com o proxy da Cloudflare ativado (a “nuvem laranja”), o tráfego passa a circular pela rede da Cloudflare antes de chegar ao servidor de origem. Isso traz três efeitos de segurança imediatos:
- O IP de origem fica oculto. Quem consulta o DNS vê apenas os IPs da Cloudflare — o endereço real do servidor não fica exposto para ser atacado diretamente.
- Mitigação de DDoS incluída. A Cloudflare absorve picos de tráfego malicioso na própria borda da rede, antes que cheguem perto do servidor — inclusive no plano gratuito.
- SSL/TLS automático. O Universal SSL emite e renova certificados sem intervenção manual, eliminando um erro comum: certificado vencido deixando o site fora do ar ou com aviso de insegurança.
Cloudflare Access: o fim do VPN tradicional
A maior mudança de postura de segurança, porém, vem do Cloudflare Access, parte do pacote Zero Trust. O modelo tradicional de VPN concede acesso à rede inteira depois de uma única autenticação: uma vez conectado, o usuário normalmente alcança bem mais do que precisaria. O Access inverte essa lógica — cada aplicação é publicada individualmente, e cada requisição é verificada contra uma política antes de passar.
Como funciona na prática
- O administrador publica uma aplicação interna (um painel, um sistema de gestão, um dashboard) com um endereço próprio, como
sistema.empresa.com.br. - Uma política define quem pode acessar — por e-mail, domínio corporativo, grupo do provedor de identidade (Google Workspace, Microsoft Entra ID, Okta) ou um PIN de uso único enviado por e-mail.
- Ao tentar abrir o endereço, o usuário é levado a uma página de login da própria Cloudflare — só depois de autenticado e aprovado pela política é que a requisição chega à aplicação.
- Cada tentativa de acesso fica registrada: quem entrou, quando, de onde.
Uma VPN verifica identidade uma vez, na conexão. O Access verifica a cada requisição, contra uma política específica daquela aplicação. Isso reduz bastante o estrago possível de uma credencial vazada: ela só abre a porta de uma aplicação, não da rede inteira.
Cloudflare Tunnel: acesso sem abrir portas
O Access normalmente trabalha em conjunto com o Cloudflare Tunnel (cloudflared): um conector instalado no mesmo ambiente do servidor que inicia uma conexão de saída até a borda da Cloudflare, e é por ela que o tráfego chega até a aplicação. Como a conexão é sempre de dentro para fora, não é preciso abrir nenhuma porta de entrada no firewall nem expor o IP do servidor — o caminho de ataque mais comum (varredura de portas abertas na internet) deixa de existir.
É o mesmo mecanismo que usamos para publicar ambientes de demonstração e painéis administrativos nos projetos que administramos, incluindo o WHF LinkWatch, cujo painel de cada cliente fica exposto exclusivamente através de um túnel protegido por Access — nunca diretamente na internet.
DNSSEC: impedindo que o DNS seja falsificado
Outra camada, mais silenciosa, é o DNSSEC. Ele adiciona uma assinatura criptográfica às respostas de DNS, permitindo que o resolvedor confirme que a resposta realmente veio do dono da zona e não foi alterada no caminho. Sem DNSSEC, um ataque de cache poisoning ou spoofing de DNS pode, em tese, redirecionar visitantes para um servidor malicioso sem que nada pareça errado no navegador. A Cloudflare oferece DNSSEC sem custo adicional — a ativação é simples, mas depende de um passo manual no registrador do domínio (adicionar o registro DS fornecido pela Cloudflare), por isso é um dos itens que mais ficam esquecidos em migrações de DNS.
WAF, rate limiting e Bot Fight Mode
Completando o conjunto, três recursos que atuam na camada de aplicação:
- WAF (Web Application Firewall): compara requisições contra assinaturas de ataques conhecidos — injeção de SQL, XSS, exploração de vulnerabilidades específicas de CMS — e bloqueia antes de chegar à aplicação. Os planos pagos permitem regras totalmente customizadas; o plano gratuito já inclui proteções essenciais.
- Rate limiting: limita quantas requisições uma mesma origem pode fazer em um intervalo — essencial para conter tentativas de força bruta em telas de login.
- Bot Fight Mode: identifica e desafia tráfego automatizado (bots de varredura, scraping agressivo), disponível já no plano gratuito.
Como a WHF aplica isso nos ambientes que administramos
Na prática, combinamos essas camadas conforme o que está exposto: sites institucionais ficam atrás do proxy com DNSSEC e WAF padrão; painéis administrativos e sistemas internos de clientes são publicados exclusivamente via Cloudflare Tunnel, protegidos por Access com política restrita a e-mails autorizados — nunca com porta aberta direto no firewall. É a mesma arquitetura que usamos para expor ambientes de demonstração e ferramentas internas com segurança, sem depender de VPN tradicional.
Seu DNS e suas aplicações expostas estão protegidos?
Avaliamos a configuração atual da sua zona DNS e dos sistemas publicados na internet.