Hardening Cloudflare com Python: automatizando o básico que não pode ficar manual

TL;DR: Configurei um script em Python para aplicar uma linha de base de segurança em uma zona Cloudflare: Always Use HTTPS, TLS mínimo 1.2, Cloudflare Managed Ruleset e regras customizadas simples no WAF.

Automação de segurança não precisa começar grande. Às vezes, o melhor ganho é tirar do painel aquilo que sempre deveria estar ligado e transformar em algo revisável, repetível e versionado.

Foi essa a motivação do script scripts/cloudflare_hardening.py: aplicar controles básicos de Cloudflare de forma idempotente, usando variáveis de ambiente e a API oficial.

O problema

Configuração manual funciona até deixar de funcionar.

Na prática, eu olharia para três riscos comuns em sites pequenos ou projetos pessoais:

1. HTTPS não forçado: o site aceita HTTP quando deveria redirecionar tudo para HTTPS.
2. TLS antigo: versões como TLS 1.0 continuam habilitadas por inércia.
3. WAF básico ausente: paths sensíveis e scanners comuns passam sem nenhum bloqueio ou challenge.

Esses pontos não resolvem todos os problemas, mas formam uma base mínima. Eles também conversam com o que discuti no artigo sobre OWASP Top 10 2025, especialmente configuração incorreta de segurança e falhas de exposição.

O que o script faz

O script aplica quatro controles:

• ativa Always Use HTTPS;
• define Minimum TLS Version como 1.2;
• implanta o Cloudflare Managed Ruleset disponível no plano Free;
• cria regras customizadas para paths sensíveis, scanners comuns e métodos HTTP inesperados.

O ponto importante é a idempotência: rodar uma segunda vez não deveria duplicar regras nem criar ruído operacional.

Regras customizadas

As regras foram pensadas para um site estático. O objetivo não é substituir análise de eventos, mas reduzir tráfego obviamente indesejado:

• bloquear caminhos como .git, .env, wp-admin, xmlrpc.php, phpmyadmin e backups;
• aplicar managed challenge em user agents comuns de scanners;
• bloquear métodos HTTP que não fazem sentido para o site.

Para uma aplicação com API, login ou formulários complexos, eu revisaria essa lista antes de aplicar. Segurança boa não é copiar regra pronta; é adaptar regra ao comportamento esperado do sistema.

Como eu validaria

Um checklist mínimo seria:

1. Rodar --dry-run antes de aplicar.
2. Confirmar a zona Cloudflare correta.
3. Aplicar com token de menor privilégio possível.
4. Revisar eventos do WAF depois da mudança.
5. Ajustar exceções se algum comportamento legítimo for afetado.

Esse tipo de automação se conecta diretamente com DevSecOps: controle de segurança bom precisa ser repetível, auditável e fácil de revisar.

Onde isso entra na estratégia

Minha leitura é simples: antes de comprar ferramenta complexa, vale automatizar o básico que reduz exposição imediata. Em um fluxo maduro, esse script poderia evoluir para:

• checagem periódica de drift;
• relatório de configuração de zona;
• integração com CI/CD;
• comparação entre configuração esperada e configuração real;
• alerta quando um controle crítico for desativado.

Isso também conversa com CTI aplicada à priorização: nem todo alerta tem o mesmo peso, mas controles básicos ausentes aumentam a superfície para scanners e ataques oportunistas.

Limites

Esse script não substitui revisão de arquitetura, threat modeling, monitoramento ou gestão de vulnerabilidades. Ele só automatiza uma base.

O valor está em transformar uma configuração manual em um artefato técnico que pode ser lido, discutido e melhorado.