Configuração Cloudflare para sites empresariais: velocidade e segurança, passo a passo

Cloudflare fica entre seus visitantes e seu servidor. Os visitantes se conectam ao data center próximo da Cloudflare, que fornece arquivos armazenados em cache diretamente, filtra o tráfego hostil e encaminha o restante para o seu servidor. Para uma empresa, isso significa páginas mais rápidas para clientes distantes do local de hospedagem, proteção contra simples inundações de negação de serviço e um local para impor regras de segurança sem alterar o código do aplicativo. Muitos planos começam gratuitamente e os planos pagos adicionam recursos, portanto, verifique a comparação do plano atual antes de decidir.

Não é um substituto para software corrigido e código seguro. Nossa lista de verificação de segurança PHP ainda se aplica. Pense no Cloudflare como uma porta de entrada forte, não como um substituto para trancar os quartos internos.

Antes de começar

• Faça um inventário do seu DNS. Exporte ou capture imagens de todos os registros do seu provedor DNS atual, incluindo e-mail (MX, SPF, DKIM, DMARC) e registros de verificação. Um registro perdido é a maneira clássica de quebrar e-mails durante uma migração.
• Saiba quem é o proprietário da conta do registrador de domínio e certifique-se de que seja uma conta corporativa com autenticação multifator. Você alterará os servidores de nomes lá.
• Reduza o TTL dos seus registros principais com um dia de antecedência, se puder, para que as alterações se espalhem mais rapidamente.
• Escolha um momento tranquilo e conte à equipe. Planeje uma reversão: os servidores de nomes antigos, anotados.

Etapa 1: adicione o site e revise o DNS

Adicione seu domínio no painel Cloudflare. Ele verifica os registros existentes. Compare-os com seu inventário e corrija as lacunas. Para cada registro escolha entre dois modos:

• Proxied (nuvem laranja): o tráfego passa pela Cloudflare. Use nomes de host para seu site e aplicativos da web.
• Somente DNS (nuvem cinza): Cloudflare apenas responde à consulta DNS. Use para servidores de e-mail, nomes de host SSH ou FTP e qualquer coisa que não seja tráfego HTTP ou HTTPS.

Em seguida, atualize os servidores de nomes no seu registrador. Assim que o site aparecer como ativo, verifique-o e envie um e-mail de teste.

Etapa 2: configurar a criptografia corretamente

Esta é a configuração que mais quebra sites. Cloudflare tem vários modos SSL/TLS:

• Flexível: criptografa o visitante da Cloudflare, mas envia o tráfego para o seu servidor sem criptografia. Parece que funciona, mas a segunda etapa está aberta e geralmente causa loops de redirecionamento. Evite isso.
• Completo: criptografa ambas as pernas, mas não verifica o certificado do seu servidor.
• Completo (estrito): criptografa ambas as partes e verifica o certificado em seu servidor. Este é o único a usar.

Instale primeiro um certificado válido em seu servidor. Um certificado Cloudflare Origin CA ou um certificado Let's Encrypt gratuito funcionam. Em seguida, mude para Full (estrito), ative Always Use HTTPS, defina uma versão TLS mínima de 1.2 e habilite o HSTS somente depois que tudo funcionar em HTTPS, porque o HSTS diz aos navegadores para recusarem o HTTP simples por um longo tempo.

Etapa 3: tornar impossível ignorar Cloudflare

Se os invasores souberem o endereço IP real do seu servidor, eles poderão enviar tráfego diretamente para ele e ignorar todas as proteções configuradas. Corrija isso de duas maneiras:

• Permita o tráfego da web para o seu servidor somente a partir dos intervalos de IP publicados da Cloudflare.
• Restaure o IP real do visitante em seu servidor web, caso contrário, todas as solicitações em seus registros, limites de taxa e análises parecem vir da Cloudflare.

#!/usr/bin/env bash
# /opt/cf/update_cloudflare_ips.sh - run weekly from cron
set -euo pipefail
IPS="$(curl -fsS https://www.cloudflare.com/ips-v4) $(curl -fsS https://www.cloudflare.com/ips-v6)"

# 1) real visitor IP for Nginx
OUT=/etc/nginx/conf.d/cloudflare_real_ip.conf
{
  for r in $IPS; do echo "set_real_ip_from $r;"; done
  echo "real_ip_header CF-Connecting-IP;"
} > "$OUT.tmp" && mv "$OUT.tmp" "$OUT"
nginx -t && nginx -s reload

# 2) firewall: allow HTTPS only from Cloudflare (remove any generic "allow 443" rule first)
for r in $IPS; do ufw allow proto tcp from "$r" to any port 443 comment 'cloudflare'; done

Um detalhe importante para usuários Docker: as portas publicadas pelo Docker ignoram as regras do ufw. Vincule contêineres ao host local por trás de um proxy reverso ou restrinja o acesso na cadeia de firewall DOCKER-USER do Docker. Para um isolamento mais forte, Cloudflare Tunnel permite que seu servidor faça apenas uma conexão de saída, portanto, não precisa de nenhuma porta web de entrada aberta. Para webhooks de pagamentos e outras integrações entre servidores, certifique-se de que as regras de IP ainda permitam a passagem dessas solicitações, caso não passem pela Cloudflare.

Etapa 4: regras de cache

Por padrão, Cloudflare armazena em cache arquivos estáticos, como imagens, CSS e JavaScript, mas não HTML. Uma política sensata para um site PHP típico:

• Ativos estáticos: cache por muito tempo (um mês ou mais). Use nomes de arquivos com versão ou uma string de consulta como app.css?v=123 para que uma nova implantação seja selecionada imediatamente.
• Páginas HTML públicas (páginas de marketing, blog): podem ser armazenadas em cache por minutos ou horas com uma regra de cache. Teste com cuidado.
• Nunca armazene em cache: admin, conta, carrinho, checkout, endpoints de API e qualquer página que dependa de um cookie de login. Crie uma regra de desvio para esses caminhos e para solicitações que transportam seu cookie de sessão.

Limpe automaticamente após cada implantação para que os clientes nunca vejam arquivos obsoletos. Crie um token de API apenas com a permissão "Cache Purge" para esta zona e chame-o no script de implantação:

# purge selected files after a deployment
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/css/app.css","https://example.com/js/app.js"]}'

Páginas mais rápidas também ajudam na pesquisa e nas conversões. Consulte nosso guia Core Web Vitals para sites PHP para saber o que corrigir no lado do servidor quando o CDN estiver instalado.

Etapa 5: firewall, bots e limitação de taxa

• Ative as regras WAF gerenciadas disponíveis em seu plano. Eles bloqueiam padrões de ataque comuns antes que cheguem ao seu código.
• Ative a proteção contra bots adequada ao seu plano e observe as análises antes de restringir qualquer coisa.
• Endpoints sensíveis ao limite de taxa: login, redefinição de senha, inscrição e checkout. Os ataques de força bruta e de teste de cartas têm como alvo exatamente estes.
• Isento de tráfego de máquinas confiáveis: webhooks de provedores de pagamento, serviços de monitoramento e suas próprias integrações não devem ser atingidos por desafios do navegador, uma vez que uma página de desafio retornada a um webhook parece uma falha.

# Custom rule 1: block probes for secrets and repositories (action: Block)
(http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git" or http.request.uri.path contains "wp-config")

# Custom rule 2: let payment webhooks through (action: Skip, security features)
(http.request.uri.path in {"/webhooks/stripe" "/webhooks/paypal"})

# Rate limiting rule: at most 10 login attempts per minute per IP
(http.request.uri.path eq "/login" and http.request.method eq "POST")  =>  10 requests / 1 minute / IP

A sintaxe das regras e os campos disponíveis variam de acordo com o plano, portanto, trate-os como modelos e teste primeiro no modo "log". Mantenha também as proteções no nível do aplicativo: as verificações de assinatura de webhook, como em nosso guia Stripe webhooks, nunca dependem apenas de regras de rede.

Etapa 6: verifique a configuração

# is traffic going through Cloudflare?
curl -sI https://example.com | grep -iE "^(server|cf-cache-status|cf-ray)"

# does the origin refuse direct access? (replace with your server IP; expect a timeout or refusal)
curl -sI --max-time 8 https://203.0.113.10 -H "Host: example.com" -k

# are the nameservers and mail records right?
dig NS example.com +short
dig MX example.com +short
dig TXT example.com +short

Verifique um arquivo estático duas vezes: a segunda resposta deve mostrar cf-cache-status: HIT. Verifique os fluxos de login, checkout e administração com um navegador real e envie e receba um e-mail de teste.

Erros comuns

• SSL flexível e os loops de redirecionamento a seguir.
• Proxy do nome do host do e-mail (deve ser apenas DNS) ou esquecimento de um registro de e-mail durante a movimentação.
• Armazenar páginas privadas em cache para que um cliente veja a página da conta de outro. Sempre ignore o cache para tráfego logado.
• Deixando a origem exposta: o IP real fica visível em registros DNS antigos, cabeçalhos de e-mail ou logs de certificados. Restrinja o firewall e considere alterar o IP caso ele tenha vazado.
• Não restaurar o IP real, o que quebra limites de taxas, logs e verificações de fraude.
• Webhooks e APIs desafiadores, que causam falhas silenciosas em pagamentos e integrações.
• Limites de tamanho da solicitação: as solicitações com proxy têm um tamanho máximo de corpo dependendo do plano. Verifique o limite atual se seu aplicativo aceita uploads grandes.
• Esquecendo o monitoramento. Adicione alertas para expiração de certificados e domínios e mantenha verificações de tempo de atividade, conforme descrito em nosso guia de backup e monitoramento.

Uma lista de verificação de uma página

1. Inventário DNS exportado, conta do registrador protegida.
2. Site adicionado, registros revisados, proxy apenas para nomes de host da web.
3. Certificado de origem instalado, modo SSL completo (estrito), sempre usar HTTPS ativado.
4. Firewall limitado às faixas Cloudflare, IP real do visitante restaurado.
5. Regras de cache para ativos estáticos, desvio para caminhos privados, limpeza no script de implantação.
6. WAF gerenciado ativado, limites de taxa para login e checkout, webhooks isentos.
7. Comandos de verificação são executados, alertas configurados, reversão documentada.

Como podemos ajudar

Configuramos Cloudflare, hospedagem e pipelines de implantação para aplicações PHP e os conectamos a sistemas de pagamento, CRM e mensagens. Leia sobre nosso serviço de integração ou agende uma breve ligação e analisaremos sua configuração de DNS, SSL e cache de acordo com esta lista de verificação.