Em resumo: O ModSecurity é uma Web Application Firewall que corre no servidor web; o OWASP Core Rule Set (CRS) fornece, para ele, regras livremente disponíveis contra os tipos de ataque mais comuns. Para o Apache, o projeto CRS recomenda o ModSecurity v2; para o Nginx, entram em questão o conector v3 ou o Coraza. Comece em modo de bloqueio com limiares de anomalia muito altos, baixe-os gradualmente e trate os falsos alarmes com exceções dirigidas. Uma atualização do PHP não é substituída por isto.
Uma WAF própria como camada adicional
Desde o PHP2Shell, muitas empresas perguntam se precisam de uma Web Application Firewall. Quem entrega os seus sites através da Cloudflare tem, segundo a Cloudflare, regras de proteção automaticamente ativas desde 21 de outubro de 2026. Quem não o faz ou não quer encaminhar o tráfego através de um terceiro pode operar uma WAF diretamente no seu próprio servidor.
A combinação mais conhecida para isso é o ModSecurity com o OWASP Core Rule Set. Ambos são de código aberto e gratuitos. O CRS é um conjunto de regras gerais de deteção, por exemplo contra injeção de SQL, cross-site scripting ou introdução de ficheiros. O próprio projeto descreve o seu objetivo como deteção geral de ataques com o menor número possível de falsos alarmes, como um bloco entre vários.
Fica assim também enunciado o limite. Uma WAF verifica pedidos e respostas, não repara nenhuma vulnerabilidade no interpretador PHP. Por que razão precisa de ambas é descrito em WAF ou atualização: por que precisa de ambas.
Que motor se adequa ao seu servidor web
O conjunto de regras precisa de um motor que o execute. Segundo a documentação do CRS, existem três opções compatíveis:
| Motor | Servidor web | Enquadramento segundo o projeto CRS |
|---|---|---|
| ModSecurity v2 | Apache (módulo) | implementação de referência, recomendado para o Apache |
| ModSecurity v3 (libModSecurity) | sobretudo Nginx através de conector | só o conector Nginx é realmente utilizável em produção; não passa 2 a 4 por cento dos testes do CRS |
| Coraza | proxies e integrações baseados em Go | passa por completo a suite de testes do CRS v4 |
Como contexto: o ModSecurity foi durante muito tempo desenvolvido pela Trustwave. A Trustwave anunciou em 2021 que terminaria o desenvolvimento em 2024. A 25 de janeiro de 2024, o projeto passou para a OWASP Foundation. Para novas instalações, verifique que versão a sua distribuição entrega e quão atual é.
Como funciona o Core Rule Set
Na definição por defeito, o CRS não bloqueia à primeira anomalia suspeita. Trabalha com pontos de anomalia: cada regra acionada soma pontos segundo a sua gravidade e só quando a soma ultrapassa um limiar é que o pedido é rejeitado.
- Níveis de gravidade: crítico 5 pontos, erro 4, aviso 3, nota 2.
- Limiar para pedidos:
tx.inbound_anomaly_score_threshold, por defeito 5. - Limiar para respostas:
tx.outbound_anomaly_score_threshold, por defeito 4. - Níveis de paranoia 1 a 4 no
crs-setup.conf: o nível 1 é a proteção de base para qualquer servidor na Internet, o nível 2 adequa-se, segundo o projeto, a aplicações com dados reais de utilizadores, como lojas online, os níveis 3 e 4 trazem claramente mais falsos alarmes.
Um nível de paranoia mais alto reconhece mais, mas gera também mais falsos alarmes. Para a maioria dos sites de empresas, o nível 1 é o arranque e o nível 2 um objetivo posterior.
Introduzir o ModSecurity com o OWASP CRS sem paralisar o site
Para novas instalações, o projeto CRS recomenda ativar o modo de bloqueio desde o início, mas com limiares muito altos, até 10000, e baixá-los depois gradualmente. Assim, ganha experiência com acessos reais sem excluir utilizadores. Os limiares definem-se no crs-setup.conf:
# crs-setup.conf: fase inicial com limiares muito altos
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
A inclusão no Apache segue a ordem que a documentação do CRS prescreve para plugins. Os caminhos variam consoante a distribuição:
<IfModule security2_module>
SecRuleEngine On
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/plugins/*-config.conf
Include /etc/modsecurity/crs/plugins/*-before.conf
Include /etc/modsecurity/crs/rules/*.conf
Include /etc/modsecurity/crs/plugins/*-after.conf
</IfModule>
Depois, analise o registo de auditoria definido em SecAuditLog. Como pesquisar registos de forma sistemática é descrito em Analisar os registos do servidor web após um ataque. Baixe os limiares por fases, por exemplo ao longo de várias semanas, até chegar ao valor por defeito.
Tratar falsos alarmes de forma dirigida
Os falsos alarmes são normais, sobretudo em backends de CMS com editores que guardam HTML. A pior reação é desligar a WAF. Melhor são duas ferramentas.
Primeiro, plugins: o projeto CRS mantém plugins com regras de exceção para aplicações comuns, por exemplo para o WordPress. São copiados para a pasta de plugins e carregados através das linhas Include mostradas acima. A lista oficial é mantida pelo projeto no seu diretório de plugins.
Segundo, exceções próprias e estritamente delimitadas. Em vez de desativar uma regra em todo o lado, retire-a apenas para o caminho em que incomoda:
# Exceção própria, carregar ANTES das regras do CRS (p. ex. num *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
O ID da regra obtém-se do registo de auditoria do falso alarme. Documente cada exceção com motivo e data, para que possa ser revista mais tarde.
Após cada alteração de limiares ou exceções, teste os percursos críticos da sua aplicação: início de sessão, encomenda, pagamento, formulário de contacto e redação. Uma WAF que bloqueia encomendas é rapidamente desativada.
Para servidores Apache, vale a pena abordar a WAF em conjunto com o resto da configuração; os fundamentos estão em Configurar o Apache para PHP com segurança. Como enquadrar as regras da Cloudflare em comparação é mostrado em Regras de proteção da Cloudflare contra o PHP2Shell. As medidas transitórias no próprio servidor estão em Medidas imediatas, quando ainda não pode aplicar o patch.
Conclusão: uma WAF precisa de manutenção
O ModSecurity com o OWASP Core Rule Set dá-lhe uma Web Application Firewall potente, sem custos de licença e sem dependência de um serviço externo. O preço é trabalho: escolher o motor adequado ao servidor web, começar com limiares altos, analisar falsos alarmes, manter exceções e manter as regras atualizadas.
Quem não pode assumir este esforço fica muitas vezes melhor servido com uma WAF na nuvem bem configurada. Quem o assume obtém uma camada que intercepta muitos ataques-padrão e fornece, nos registos de auditoria, indicações valiosas. Em caso algum substitui a atualização: contra o PHP2Shell, só protegem o PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou um backport confirmado, seguido do reinício de todos os processos PHP.
Como ajuda concretamente a PHP SOS?
- Escolher o motor: verificamos servidor web, distribuição e pacotes existentes e recomendamos a combinação adequada.
- Introduzir: instalamos o CRS com limiares iniciais altos, integramos plugins adequados e configuramos o registo.
- Afinar: ao longo de várias semanas, analisamos falsos alarmes, criamos exceções dirigidas e baixamos os limiares.
- Enquadrar: no âmbito de WAF e patching virtual, ligamos a WAF às medidas transitórias e ao caminho para o patch regular.
Perguntas frequentes
O OWASP CRS protege contra o PHP2Shell?
Não deve presumi-lo. O Core Rule Set reconhece padrões gerais de ataque e não está concebido para uma vulnerabilidade específica. A Cloudflare alerta além disso que, no caso do PHP2Shell, regras baseadas apenas nos dados do pedido não bastam. A atualização do PHP continua a ser obrigatória.
Que motor devo usar para o Nginx?
Segundo o projeto CRS, no ModSecurity v3 apenas o conector Nginx é realmente utilizável em produção, e o v3 não passa uma pequena parte dos testes do CRS. Em alternativa existe o Coraza, que, segundo o projeto, passa por completo a suite de testes do CRS v4. Para o Apache, o projeto recomenda o ModSecurity v2.
O ModSecurity ainda é mantido?
Segundo a documentação do CRS, a Trustwave tinha anunciado o fim do desenvolvimento em 2024. A 25 de janeiro de 2024, o projeto foi entregue à OWASP Foundation e é, desde então, continuado aí.
Como evito que a WAF paralise a minha loja?
Comece com limiares de anomalia muito altos, como recomenda o projeto CRS, e baixe-os gradualmente. Analise entretanto os registos e crie exceções dirigidas para a sua aplicação, em vez de desativar regras de forma generalizada.