# Utilizar o ModSecurity e o OWASP Core Rule Set > Utilizar o ModSecurity e o OWASP CRS: escolher o motor adequado, perceber limiares de anomalia e níveis de paranoia e controlar falsos alarmes de forma dirigida. Fonte: https://phpsos.de/pt/blog/modsecurity-owasp-crs/ Atualizado em: 25/10/2026 Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6 **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](https://phpsos.de/pt/blog/waf-oder-update/). ## 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. 1. Níveis de gravidade: crítico 5 pontos, erro 4, aviso 3, nota 2. 2. Limiar para pedidos: `tx.inbound_anomaly_score_threshold`, por defeito 5. 3. Limiar para respostas: `tx.outbound_anomaly_score_threshold`, por defeito 4. 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`: ```apache # 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: ```apache 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 ``` 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](https://phpsos.de/pt/ratgeber/logfiles-auswerten/). 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: ```apache # 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. > **Dica:** > 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](https://phpsos.de/pt/blog/apache-fuer-php-absichern/). Como enquadrar as regras da Cloudflare em comparação é mostrado em [Regras de proteção da Cloudflare contra o PHP2Shell](https://phpsos.de/pt/blog/cloudflare-waf-php2shell/). As medidas transitórias no próprio servidor estão em [Medidas imediatas, quando ainda não pode aplicar o patch](https://phpsos.de/pt/php2shell/sofortmassnahmen-ohne-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](https://phpsos.de/pt/leistungen/waf-virtuelles-patching/), 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. ## Fontes - [OWASP CRS: documentação](https://coreruleset.org/) - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [Blogue da Cloudflare](https://blog.cloudflare.com/) - [php.net: comunicados de segurança](https://www.php.net/)