Cloudflare para segurança web: WAF, DNS, cache e proteção de borda
A borda do Cloudflare protege quando bem configurada. Veja como usar WAF, DNS e TLS sem deixar brechas.
O Cloudflare é uma camada de borda popular que combina DNS, CDN, WAF e proteção contra abuso. Bem configurado, ele filtra tráfego malicioso antes que chegue à origem, melhora desempenho e adiciona controles de segurança. Mal configurado, gera falsa sensação de proteção: a origem continua exposta diretamente, o TLS está em um modo permissivo ou as regras nunca foram ajustadas.
Este guia trata da configuração defensiva do Cloudflare para segurança web, com foco nos pontos que mais importam: proteger a origem contra bypass, ajustar o WAF, escolher o modo de TLS correto e usar rate limiting e proteção de bots com critério.
Proteger a origem e o modo TLS
O erro mais comum é deixar a origem acessível diretamente pelo IP, ignorando o Cloudflare. Se um atacante descobre o IP real, ele contorna toda a borda. Restrinja a origem para aceitar conexões apenas do Cloudflare, por exemplo permitindo somente as faixas da borda no firewall, e evite expor o IP de origem em registros DNS, e-mails ou cabeçalhos.
Escolha o modo de TLS com cuidado. Modos permissivos podem aceitar tráfego não criptografado entre a borda e a origem, anulando parte da proteção. Prefira um modo que exija criptografia válida ponta a ponta entre o Cloudflare e a sua origem.
Bloquear a origem para só aceitar a borda
Restringir a origem não é uma configuração única, e sim uma combinação de camadas. No firewall ou security group da origem, permita apenas as faixas de rede do Cloudflare e negue o restante. Onde a plataforma oferece, ative a autenticação de origem com certificado do próprio Cloudflare, de forma que a origem só responda a requisições que venham comprovadamente da borda. E revise periodicamente as faixas permitidas, porque uma regra esquecida que libera a internet inteira anula todo o esforço.
WAF, regras e bots
Ative os conjuntos de regras gerenciadas e, como em qualquer WAF, introduza bloqueios de forma observada para medir o impacto antes de barrar tráfego legítimo. Crie regras específicas para o seu contexto, como proteger rotas administrativas e endpoints sensíveis, e use rate limiting nos pontos sujeitos a abuso. A proteção contra bots ajuda contra automação, mas deve ser dosada para não criar atrito.
- Restringir a origem para aceitar apenas tráfego do Cloudflare
- Não vazar o IP de origem em DNS, e-mail ou cabeçalhos
- Usar modo de TLS que exija criptografia válida até a origem
- Ativar regras gerenciadas e ajustar com observação
- Aplicar rate limiting em rotas sensíveis e de login
- Dosar proteção de bots para não barrar usuários reais
Cabeçalhos de segurança na borda
A borda é um bom lugar para garantir cabeçalhos de segurança de resposta de forma consistente, sem depender de cada aplicação lembrar de emiti-los. O mais importante é o HSTS, que instrui o navegador a só acessar o site por HTTPS, fechando a janela em que um primeiro acesso em texto claro poderia ser interceptado. Some a ele cabeçalhos que reduzem classes inteiras de ataque no cliente.
# Forçar HTTPS; ative preload só quando tiver certeza da cobertura
Strict-Transport-Security: max-age=31536000; includeSubDomains
# Impede que o conteúdo seja carregado em um frame de terceiros
X-Frame-Options: DENY
# Evita que o navegador adivinhe o tipo do conteúdo
X-Content-Type-Options: nosniff
# Controla quanto do referenciador é enviado a outros sites
Referrer-Policy: strict-origin-when-cross-originUma Content Security Policy bem feita reduz o impacto de scripts injetados, mas ela precisa ser desenhada a partir do que a aplicação realmente carrega, senão quebra funcionalidades. Comece em modo de somente relatório para observar as violações antes de impor a política, do mesmo jeito que se faz com regras de WAF. Aplicar o HSTS com includeSubDomains e, mais tarde, preload é um ganho grande, mas confirme antes que todos os subdomínios de fato suportam HTTPS, porque preload é difícil de reverter.
Autenticação de origem e rotas administrativas
Filtrar por faixa de rede protege bastante, mas quem descobre o IP de origem ainda pode tentar falar direto com ela. A autenticação de origem por certificado, em que a origem só aceita conexões apresentando o certificado da borda, torna o bypass muito mais difícil: mesmo conhecendo o endereço, o atacante não tem o certificado que a origem exige. É a diferença entre esconder a porta e trancá-la.
Rotas administrativas merecem proteção além do WAF. Painéis de gestão, áreas internas e endpoints de operação são alvos preferenciais e não precisam estar acessíveis à internet toda. Coloque uma camada de autenticação na borda para essas rotas, exigindo identidade antes que a requisição sequer chegue à aplicação, e restrinja o acesso a redes ou identidades conhecidas. Isso reduz muito a superfície exposta justamente nos caminhos de maior impacto.
- Autenticar a origem por certificado, além de filtrar por faixa de rede
- Exigir identidade na borda para painéis e rotas administrativas
- Restringir rotas internas a redes ou identidades conhecidas
- Não expor endpoints de operação à internet sem necessidade
- Tratar o acesso administrativo como o de maior impacto a proteger
DNS, cache e cuidados de configuração
No DNS, mantenha os registros que devem passar pela borda com o proxy ativado; registros sem proxy expõem o IP de origem. Cuidado com cache de conteúdo sensível: regras de cache mal definidas podem servir a um usuário um conteúdo destinado a outro. Defina explicitamente o que pode e o que não pode ser cacheado.
Como toda borda, o Cloudflare complementa a segurança da aplicação, não a substitui. Uma falha na aplicação continua explorável por uma requisição que passe pelas regras. Trate a borda como uma camada a mais, ajustada continuamente.
Checklist prático
- Restringir a origem para aceitar apenas tráfego do Cloudflare
- Ativar autenticação de origem por certificado, além do filtro por rede
- Evitar vazar o IP de origem em DNS, e-mail e cabeçalhos
- Escolher modo de TLS com criptografia válida até a origem
- Aplicar HSTS e confirmar cobertura de HTTPS antes de includeSubDomains e preload
- Definir cabeçalhos de segurança na borda de forma consistente
- Desenhar a CSP a partir do que a aplicação carrega, começando em somente relatório
- Ativar regras gerenciadas de WAF
- Introduzir bloqueios de forma observada antes de barrar
- Aplicar rate limiting em rotas sensíveis e de login
- Exigir identidade na borda para rotas administrativas
- Dosar a proteção de bots para não criar atrito
- Manter proxy ativo nos registros DNS que devem passar pela borda
- Definir explicitamente o que pode ser cacheado
- Revisar regras e faixas permitidas de forma contínua
Boas práticas
- Proteja a origem contra acesso direto que ignore a borda
- Tranque a origem com autenticação por certificado, não só filtro de rede
- Use TLS ponta a ponta entre Cloudflare e origem
- Padronize cabeçalhos de segurança na borda, incluindo HSTS
- Ajuste WAF e CSP com observação antes de impor
- Proteja rotas administrativas com identidade na borda
- Cuide do cache para não vazar conteúdo entre usuários
- Combine borda com correção da aplicação
- Trate a configuração como processo contínuo
Erros comuns
Origem acessível diretamente pelo IP
O atacante descobre o IP real e contorna toda a proteção de borda.
Modo de TLS permissivo até a origem
Tráfego pode seguir sem criptografia entre a borda e a origem.
IP de origem vazando em registros ou e-mails
Facilita o bypass do Cloudflare e ataque direto à origem.
Rotas administrativas expostas à internet
Alvos de maior impacto ficam acessíveis a qualquer origem.
Preload de HSTS ativado sem cobrir todos os subdomínios
Subdomínio sem HTTPS fica inacessível e a reversão é lenta.
Regras de cache mal definidas
Conteúdo sensível de um usuário pode ser servido a outro.
Confiar na borda e ignorar a aplicação
Falhas da aplicação continuam exploráveis quando a requisição passa.
Quando procurar apoio especializado
Configurar Cloudflare protegendo a origem e ajustando regras sem barrar usuários é parte do serviço de WAF e Proteção de Borda da GUARDIASEC, que avalia exposição, TLS, regras e cache e ajusta o tuning de forma observada.
Perguntas frequentes
O Cloudflare melhora a segurança e o desempenho da web ao mesmo tempo?
Sim, e essa é justamente a sua vantagem. Como camada na borda, o Cloudflare melhora a segurança ao filtrar tráfego malicioso com WAF, mitigar abuso e esconder a origem, e melhora o desempenho ao servir cache de uma rede distribuída próxima do usuário, reduzindo latência e carga na origem. O ganho nos dois lados só aparece com a configuração correta de cache, TLS e regras; mal configurado, ele entrega menos em ambas as frentes.
Usar o Cloudflare já protege meu site?
Só se estiver bem configurado. Se a origem continua acessível pelo IP direto, o modo de TLS é permissivo ou as regras nunca foram ajustadas, a proteção é parcial e pode dar falsa sensação de segurança. O ganho real vem de proteger a origem, ajustar o WAF e cuidar de TLS e cache.
Como impeço que descubram o IP da minha origem?
Restrinja a origem para aceitar conexões apenas das faixas do Cloudflare no firewall e evite vazar o IP real em registros DNS sem proxy, em cabeçalhos de e-mail e em respostas da aplicação. Se o IP de origem vaza, um atacante pode atacar diretamente, contornando a borda inteira.
Qual modo de TLS devo usar no Cloudflare?
Evite modos permissivos que aceitam tráfego não criptografado entre a borda e a origem. Prefira um modo que exija criptografia válida ponta a ponta, com um certificado confiável na origem. Isso garante que o tráfego permaneça protegido em todo o caminho, e não apenas entre o usuário e a borda.
O Cloudflare substitui o pentest e a correção da aplicação?
Não. A borda filtra tráfego malicioso e reduz abuso, mas uma falha na aplicação continua explorável quando uma requisição passa pelas regras. O Cloudflare é uma camada complementar; pentest, correção de vulnerabilidades e boas práticas na aplicação continuam necessários.
Devo configurar HSTS e cabeçalhos de segurança na borda?
Sim, e a borda é um bom lugar para isso, porque garante os cabeçalhos de forma consistente sem depender de cada aplicação emiti-los. O HSTS instrui o navegador a só usar HTTPS, e cabeçalhos como os que impedem enquadramento em frame de terceiros e a adivinhação de tipo de conteúdo reduzem classes inteiras de ataque no cliente. O cuidado maior é com o preload do HSTS: só ative depois de confirmar que todos os subdomínios suportam HTTPS, porque reverter é lento.
Como impeço acesso direto à origem mesmo se descobrirem o IP?
Filtrar por faixa de rede ajuda, mas quem descobre o IP ainda pode tentar falar com a origem. A camada mais forte é a autenticação de origem por certificado: a origem só responde a conexões que apresentam o certificado da borda, então conhecer o endereço não basta para contornar o Cloudflare. Combine isso com a restrição de rede e com a revisão periódica das regras, para que nenhuma exceção esquecida abra a origem para a internet.
Como protejo o painel administrativo com o Cloudflare?
Rotas administrativas não precisam estar acessíveis à internet inteira. Coloque uma camada de autenticação na borda que exija identidade antes de a requisição chegar à aplicação, e restrinja o acesso a redes ou identidades conhecidas. Assim, mesmo que o WAF deixe passar uma requisição, o caminho administrativo continua fechado para quem não está autenticado, reduzindo a superfície exposta justamente onde o impacto de um comprometimento é maior.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.