Visão geral
Implementação de uma camada de Web Application Firewall como projeto separado, integrada ao Nginx interno da aplicação utilizando ModSecurity com OWASP Core Rule Set e anomaly scoring, seguindo uma estratégia de defense in depth complementar ao AWS WAF.
Contexto
O AWS WAF protegia os pontos de entrada externos da plataforma, mas a estratégia de segurança exigia uma segunda camada de proteção mais próxima da aplicação. Um projeto separado de WAF interno foi necessário para adicionar detecção e bloqueio de ameaças na camada de aplicação, com capacidade de tuning independente e rollout controlado.
Desafio
Implementar e operar um WAF interno que complementasse o AWS WAF sem duplicar esforços, mantendo compatibilidade com aplicações, controlando falsos positivos e permitindo ativação e desativação sem impacto na operação.
Minha atuação
- Implementação do ModSecurity com OWASP Core Rule Set como projeto separado
- Integração com Nginx interno da aplicação
- Configuração e tuning de regras baseadas no OWASP CRS
- Implementação de anomaly scoring com thresholds configuráveis
- Parametrização para ativação/desativação por ambiente
- Análise de falsos positivos e calibração contínua das regras
- Logging, troubleshooting e compatibilidade com aplicações
Arquitetura
A arquitetura de defense in depth ficava clara: AWS WAF atuava na borda, protegendo os pontos de entrada externos; ModSecurity + OWASP CRS atuava internamente como camada separada de proteção da aplicação. Cada controle operava em um ponto distinto da arquitetura, com papéis complementares — não duplicados.
Decisões técnicas
- Projeto separado de WAF interno — não uma extensão do AWS WAF
- OWASP Core Rule Set como base para detecção de padrões de ataque
- Anomaly scoring em vez de bloqueio por regra individual
- Parametrização como decisão de engenharia: rollout, rollback e troubleshooting
- Defense in depth com controles em pontos distintos da arquitetura
Segurança e governança
O ModSecurity utilizava OWASP Core Rule Set para detectar padrões associados a classes comuns de ataques: SQL injection, cross-site scripting, protocol violations, malformed requests e padrões suspeitos de requisição. O anomaly scoring permitia que diferentes regras contribuíssem para um score acumulado — o comportamento final era definido com base no score e nos thresholds configurados.
Automação
A parametrização permitia habilitar ou desabilitar o ModSecurity via parâmetro do ambiente, viabilizando rollout controlado, testes, ativação progressiva, troubleshooting e rollback simplificado.
Desafios de engenharia
Implementar um WAF interno não significava apenas instalar ModSecurity. O trabalho envolvia integração com Nginx, configuração das regras, tuning de thresholds de anomaly score, análise de falsos positivos, logging, troubleshooting, compatibilidade com aplicações e manutenção contínua das regras.
Resultados
- Camada complementar de proteção na aplicação, separada do AWS WAF
- Proteção baseada em regras reconhecidas do OWASP CRS
- Capacidade de tuning através de anomaly scoring com thresholds
- Ativação controlada por configuração com possibilidade de rollout e rollback
- Estratégia de defense in depth com controles em pontos distintos da arquitetura