Pular para o conteúdo
EdgeServers
Blog

ModSecurity e o OWASP CRS — as regras de WAF que de fato entregamos no Apache

14 de maio de 2026 · 2 min de leitura · por Sudhanshu K.

This is a snippet. The full article lives on Medium.

ModSecurity é uma daquelas ferramentas que quase todo mundo tem instalada e quase ninguém ajustou. O padrão em auditorias é consistente: o módulo está carregado, o OWASP Core Rule Set está colocado com as configurações padrão, os logs enchem com milhares de alertas que ninguém lê, e ou (a) está rodando silenciosamente em DetectionOnly há anos, ou (b) está bloqueando tráfego legítimo e o cliente não sabe.

Ambos os modos significam que o WAF não está fazendo nada útil.

Por que se importar em 2026 quando o Cloudflare existe?

Três razões pelas quais ainda implantamos ModSecurity no nível do origin atrás de um WAF de nuvem:

  1. Defesa em profundidade. O WAF de nuvem é uma camada. Quando classifica errado, ou o cliente não habilitou um pacote de regras, ou alguém descobre o IP de origin, a camada interna pega o que o edge perdeu.
  2. Regras específicas da aplicação. O Cloudflare não sabe que seu endpoint /admin/export nunca deveria ver uma palavra-chave SELECT. ModSecurity no origin sabe.
  3. Forense. O audit log do ModSecurity te dá a requisição completa que disparou a regra. WAFs de nuvem dão dados amostrados, com perdas.

A configuração base

ModSecurity 3 (libmodsecurity) com o conector Apache — não o v2 legado:

<IfModule security2_module>
    SecRuleEngine On
    SecRequestBodyAccess On
    SecRequestBodyLimit 13107200
    SecAuditEngine RelevantOnly
    SecAuditLogParts ABIJDEFHZ
    Include /etc/modsecurity/crs/crs-setup.conf
    Include /etc/modsecurity/crs/rules/*.conf
</IfModule>

Depois o trabalho de tuning de verdade — escolher o paranoia level certo, fazer allowlist das regras que disparam no tráfego normal da sua aplicação, e escrever as regras por rota que o Cloudflare não consegue. O artigo completo no Medium cobre:

  • Paranoia Level 1 → 4 — o que cada um adiciona, e o nível que entregamos por padrão
  • O workflow de «triagem de falsos positivos» que rodamos por duas semanas antes de virar para o modo block
  • Regras custom para caminhos comuns de aplicação (admin, endpoints API, uploads de arquivo)
  • Enviar o audit log para o SIEM, e os dashboards que monitoramos
  • As regras que sempre desabilitamos (e por quê)

Continua no Medium.