Como corrigir erros do mod_security no WordPress: 6 métodos simples

Encontrar erros do mod_security, como " 403 Proibido " ou "406 Não Aceitável", enquanto trabalha em seu site WordPress, pode ser frustrante.

Muitas vezes, esses erros não indicam um problema com o código do seu site ou uma falha de um plugin, mas sim uma camada de segurança excessivamente zelosa no seu servidor web, chamada ModSecurity .

Este guia oferece uma análise aprofundada sobre o diagnóstico e a resolução desses problemas, garantindo que seu site permaneça seguro e funcionando corretamente.

Resumo: Guia rápido para solucionar erros do mod_security no WordPress

• Os erros do mod_security geralmente ocorrem quando o firewall do servidor bloqueia atividades legítimas do WordPress, e não porque seu site esteja com defeito.

• Sempre verifique os registros do servidor primeiro e identifique o ID exato da regra antes de fazer alterações. Isso evita riscos de segurança desnecessários.

• A solução mais segura é pedir ao seu provedor de hospedagem para adicionar o ID da regra específico à lista de permissões, em vez de desativar o ModSecurity completamente.

• Utilize backups e um ambiente de teste para testar as correções com segurança e, em seguida, aplique a remoção de regras direcionadas, como SecRuleRemoveById, para manter seu firewall ativo e seguro.

Erros do mod_security do WordPress: Visão geral e causas principais

O ModSecurity é um firewall sofisticado, mas carece da percepção contextual de um administrador humano.

Para corrigir isso, você precisa primeiro entender o que é e por que sinaliza atividades legítimas do WordPress como uma ameaça.

O que é o projeto ModSecurity e como ele funciona como um firewall de aplicações web?

firewall de aplicações web (WAF) de código aberto que funciona diretamente no seu servidor web (normalmente Apache, Nginx ou IIS).

Ele fica entre a internet e seu site, inspecionando cada HTTP e cada resposta enviada.

Sua função principal é filtrar o tráfego de acordo com regras predefinidas. O conjunto de regras WAF mais utilizado pelos hosts é o OWASP CRS (Core Rule Set).

Se a solicitação de um visitante corresponder a um padrão de ataque conhecido, como uma de injeção de SQL ou um bot malicioso, o mecanismo ModSecurity bloqueia a solicitação imediatamente.

Essa proteção proativa é vital para defender seu ambiente de hospedagem contra ameaças comuns e ataques HTTP.

Erros comuns do mod_security em sites WordPress

Quando o ModSecurity bloqueia uma requisição, raramente avisa explicitamente. Em vez disso, você verá códigos de erro padrão do servidor no seu navegador:

• 403 Proibido: O servidor entendeu a solicitação, mas se recusa a atendê-la. Este é o erro mais comum quando uma regra de segurança é acionada.

• 406 Não Aceitável: Isso ocorre quando o recurso solicitado não consegue gerar uma resposta que corresponda aos cabeçalhos enviados na solicitação (geralmente acionado por cabeçalhos específicos do navegador ou dados de cookies).

• Erro 500 Internal Server Error : Um arquivo .htaccess mal configurado que tenta controlar o ModSecurity pode causar a falha total do site.

• Loops de login: usuários do WordPress podem se deparar com a impossibilidade de fazer login, sendo redirecionados constantemente para a página de login sem nenhuma mensagem de erro, caso uma regra sinalize o processo de autenticação.

Por que o mod_security gera falsos positivos no WordPress?

O ModSecurity depende de lógica de correspondência de padrões. Ele não "sabe" que você é o administrador; ele apenas vê códigos e sequências de texto. Isso frequentemente leva a falsos positivos, onde ações seguras são bloqueadas

• Palavras-chave SQL suspeitas: Se você escrever uma postagem de blog sobre gerenciamento de banco de dados e usar termos como DROP TABLE ou SELECT * no texto, o ModSecurity poderá interpretar isso como um ataque de injeção de SQL e bloquear a ação "Publicar".

• Dados de plugins: Novos plugins e plugins de SEO frequentemente enviam dados complexos (JSON ou XML) para o servidor. Se esses dados contiverem caracteres especiais ou estruturas que se assemelhem a uma vulnerabilidade, o firewall os bloqueará.

• Falsos Positivos: Tarefas administrativas legítimas, como salvar estruturas de menu extensas ou formulários de contato com campos específicos, podem inadvertidamente corresponder a uma regra rigorosa destinada a impedir ataques de cross-site scripting (XSS).

Diagnosticar erros do mod_security no WordPress antes de aplicar correções

Desativar recursos de segurança indiscriminadamente é perigoso. Antes de aplicar qualquer correção, você deve confirmar se o ModSecurity é realmente o culpado, diagnosticando corretamente o erro.

Capture a mensagem de erro exata do navegador e o URL que está causando a falha

Comece por observar o erro com atenção.

• Acione o erro: Execute a ação que causa o bloqueio (por exemplo, salvar uma página específica).

• Verifique o URL: Observe a barra de endereços. O erro ocorre em wp-admin/post.php ou no URL de um plugin específico?

• Observe o código: trata-se de um erro 403, 406 ou 500?

Se o erro desaparecer quando você interromper essa ação específica (por exemplo, remover um trecho de código específico do conteúdo da sua postagem), você terá um forte indício de que um filtro de conteúdo é o responsável.

Acesse e analise os logs do ModSecurity no painel de controle da hospedagem ou via SSH

Para identificar a causa específica, você precisa revisar os registros. Muitos provedores de hospedagem permitem que você os visualize através do painel de controle ou via SSH.

• cPanel: Faça login e navegue até a seção “Métricas” ou “Segurança”. Procure por “ Logs de Erro ” ou “Log do ModSecurity”.

• SSH: Se você tiver acesso ao terminal, o arquivo de log geralmente está localizado em /usr/local/apache/logs/error_log ou /var/log/httpd/error_log.

Abra o arquivo e procure por “ModSecurity” ou seu endereço IP. Você está procurando por uma linha que diga “ModSecurity: Acesso negado”

Leitura complementar: Corrigir o erro "Desculpe, você não tem permissão para acessar esta página" no WordPress

Identificar IDs de regras de acionamento nos registros de auditoria do ModSecurity

Esta é a etapa mais crítica. No registro de log, procure o ID da regra. Geralmente, ele aparece entre colchetes, assim: [id “941160”].

Exemplo de trecho de log: ModSecurity: Acesso negado com código 403… [msg “NoScript XSS InjectionChecker: Injeção de HTML”] [id “941160”]

Neste exemplo, 941160 é o ID da regra. Anote este número. Ele permite que você desative apenas esta regra específica posteriormente, em vez de desativar todo o firewall.

Reproduzir erros do mod_security em um site WordPress de teste

Nunca teste alterações de segurança em um site em produção.

• Crie um clone de teste do seu site usando as ferramentas do seu provedor de hospedagem ou um plugin.
• Tente reproduzir o erro no ambiente de teste.
• Caso o erro ocorra nesse ponto, você pode testar com segurança as correções abaixo sem comprometer a disponibilidade do seu site principal.

Saiba mais: Como corrigir erros 301 no WordPress

Métodos para corrigir erros do mod_security no WordPress

Após obter o ID da regra (ou confirmar que se trata de um problema do ModSecurity), utilize um dos seguintes métodos.

Método 1: Solicitar ao provedor de hospedagem que adicione IDs de regras ModSecurity específicos à lista de permissões

Esta é a melhor e mais permanente solução. A maioria dos provedores de hospedagem compartilhada não oferece acesso root para editar os arquivos principais do ModSecurity, então você precisa solicitar esse acesso a eles.

• Abra um chamado de suporte.

• Modelo : “Olá, estou recebendo um erro 403 no meu site. Os registros de erro mostram que ele está sendo acionado pela Regra ModSecurity de ID [Inserir ID aqui]. Este é um falso positivo causado pela minha atividade legítima no WordPress. Você poderia, por favor, adicionar esta regra à lista de permissões do meu domínio ?”

• A equipe de suporte geralmente consegue adicionar essa exceção à configuração do servidor em poucos minutos.

Método 2: Desativar temporariamente o mod_security no cPanel para testes

Se você estiver com dificuldades e não puder esperar pelo suporte, pode desativar temporariamente o ModSecurity para concluir sua tarefa.

• Faça login no cPanel.
• Acesse Segurança → ModSecurity.
• Localize seu domínio na lista.
• Mova a chave seletora de "Ligado" para "Desligado".

Observação: Isso desativa completamente o firewall. Faça isso apenas pelos poucos minutos necessários para concluir sua tarefa (por exemplo, salvar as configurações) e, em seguida, ative-o novamente imediatamente para se proteger contra ameaças comuns.

Método 3: Corrigir conflitos de plugins ou temas que acionam erros do mod_security

Às vezes, o problema está em um software mal programado no seu site.

• Conflitos de plugins: Desative seus plugins um por um. Se o erro parar após a desativação de um plugin específico, verifique se há atualizações disponíveis. Caso contrário, entre em contato com o desenvolvedor do plugin; ele pode precisar ajustar a forma como o plugin envia dados para evitar que fornecedores comerciais de WAF o sinalizem.

• Problemas com o tema: Alterne temporariamente para um tema padrão do WordPress (como o Twenty Twenty-Four). Se o erro for resolvido, seu tema original pode incluir scripts personalizados que estão causando o bloqueio.

Saiba mais: O que é um erro de conflito 409 e como corrigi-lo?

Método 4: Modificar as regras do .htaccess para resolver o bloqueio do mod_security

Se o seu serviço de hospedagem permitir alterações no arquivo .htaccess, você pode desativar manualmente o ModSecurity para o seu site.

• Acesse seu site via FTP ou Gerenciador de Arquivos.
• Localize o arquivo .htaccess na pasta raiz.
• Adicione o seguinte código no início:

<IfModule mod_security.c>SecFilterEngine Off SecFilterScanPOST Off</IfModule>

Observação: Nem todos os servidores suportam esta diretiva. Se o seu site apresentar falhas (Erro 500) após adicioná-la, remova-a imediatamente.

Método 5: Usar SecRuleRemoveById na configuração do servidor Apache ou NGINX

servidores VPS ou (ou se seu provedor de hospedagem suporta essa diretiva .htaccess específica), você pode remover a regra de bloqueio manualmente usando o ID que encontrou anteriormente.

• Para o Apache (.htaccess): Adicione esta linha ao seu arquivo .htaccess, substituindo XXXXXX pelo ID dos seus logs:

<IfModule mod_security.c>SecRuleRemoveById XXXXXX</IfModule>

• Para o Nginx: Normalmente, você precisa de acesso root para modificar o arquivo nginx.conf ou o arquivo vhost do site. Adicione o seguinte dentro do bloco server ou location:

modsecurity_rules 'SecRuleRemoveById XXXXXX';

Este método é superior ao Método 4 porque mantém o firewall ativo para todas as outras ameaças.

Leia mais: Apache vs Nginx

Método 6: Reconfigurar os plugins de segurança para evitar conflitos com o firewall

Se você utiliza plugins como Wordfence , JetPack , etc., eles atuam como um firewall de nível de aplicação. Executá-los juntamente com uma configuração rigorosa do ModSecurity no servidor pode causar "filtragem dupla", onde solicitações válidas são bloqueadas.

• Verifique as configurações do seu plugin de segurança para encontrar o “Modo de Aprendizagem” ou a “Lista de Permissões”

• Certifique-se de que seus provedores de serviços de internet ou IPs dinâmicos não estejam sendo sinalizados por configurações excessivamente agressivas tanto no plugin quanto no servidor.

Saiba mais: Como corrigir o erro de conteúdo misto no WordPress

Fluxo de trabalho seguro para resolução de problemas usando backups e ambiente de teste do WordPress

Modificar regras de segurança em nível de servidor e editar arquivos de configuração principais acarreta riscos inerentes significativos.

Um único erro de sintaxe no seu arquivo .htaccess pode causar imediatamente um erro "500 Internal Server Error", tirando todo o seu site do ar.

Para evitar interrupções inesperadas e perda de dados, você deve seguir rigorosamente este fluxo de trabalho de solução de problemas seguro:

• Faça um backup: Antes de mexer em qualquer código, crie um backup manual completo do seu site. Certifique-se de baixar tanto o diretório de arquivos do WordPress (especificamente, wp-content e .htaccess) quanto uma exportação completa do banco de dados SQL. Isso cria um ponto de restauração imediato caso algo dê errado.

• Ambiente de teste: Nunca teste alterações de firewall em um ambiente de produção. Crie um clone de teste do seu site; a maioria dos provedores de hospedagem modernos oferece esse recurso. Execute todos os testes de diagnóstico e edições nos arquivos de configuração primeiro nesse ambiente isolado.

• Verificação: Após aplicar uma correção (como SecRuleRemoveById), é necessário realizar testes completos. Não basta verificar se o erro original desapareceu; teste funcionalidades críticas, como formulários de contato, páginas de login e fluxos de finalização de compra em lojas virtuais, para garantir que a alteração de segurança não tenha afetado outros scripts acidentalmente.

• Implantação: Depois que a solução for validada em ambiente de teste sem efeitos colaterais, você poderá aplicar com segurança a mesma correção ao seu site em produção.

Conclusão: Resolvendo erros do mod_security no WordPress

O ModSecurity é um componente essencial da segurança de aplicações, fornecendo filtragem de respostas e bloqueando ataques antes que eles atinjam sua instalação do WordPress . No entanto, a configuração correta é fundamental para evitar frustrações.

Ao analisar os registros de erros, identificar o ID da regra específica e aplicar regras de lista de permissões direcionadas (em vez de desativar completamente o firewall), você pode manter um ambiente de hospedagem seguro que funcione sem problemas para você e seus usuários.

Seja corrigindo o problema através do arquivo .htaccess ou entrando em contato com seu provedor de hospedagem, buscar aconselhamento especializado e seguir uma abordagem metódica é a melhor maneira de resolver esses erros permanentemente.

Perguntas frequentes sobre como corrigir erros do mod_security no WordPress