Como desativar o ModSecurity por domínio ou por regra no cPanel imprimir

Como desativar o ModSecurity num domínio pelo cPanel, liberar só a regra que causa o falso positivo com SecRuleRemoveById e o que evitar no servidor.

• Tempo: 5 a 15 min
• Nível: Intermediário
• Vale para: cPanel/WHM com ModSecurity 2 (EasyApache 4) e Apache 2.4 sem painel
• Atualizado: outubro de 2026

O ModSecurity às vezes bloqueia uma ação legítima do site: salvar um post no WordPress, finalizar uma compra, enviar um formulário com código. O sintoma típico é um erro 403 Forbidden só naquela ação. A tentação é desligar tudo, mas o certo é desligar o mínimo possível. Esta é a ordem recomendada:

1. Remover só a regra que dispara, só no domínio afetado.
2. Desativar o ModSecurity no domínio afetado.
3. Desativar a regra no servidor inteiro.

Desligar o ModSecurity no servidor inteiro não está na lista: deixa todos os sites sem proteção contra ataques automatizados.

Antes de começar: descubra o ID da regra

Toda regra do ModSecurity tem um número. Sem ele, você está chutando.

• No WHM: Security Center » ModSecurity™ Tools » Hits List. Cada linha mostra o domínio, o endereço acessado e o ID da regra.
• No cPanel da conta: Métricas » Erros mostra as últimas linhas do log de erros do site, onde aparecem as mensagens do ModSecurity.
• Pelo SSH:

  grep -i modsecurity /etc/apache2/logs/error_log | grep seudominio.com.br | tail -n 5

  Procure o trecho [id "949110"] em cada linha.

Opção 1: remover só uma regra num domínio (o mais seguro)

Exige acesso root. No cPanel, isso é feito com um arquivo de inclusão no virtual host do domínio, que sobrevive às atualizações do painel.

1. Crie as pastas do domínio, trocando usuario pelo usuário cPanel e o domínio pelo seu. A pasta std vale para HTTP e a ssl para HTTPS:

   mkdir -p /etc/apache2/conf.d/userdata/std/2_4/usuario/seudominio.com.br
   mkdir -p /etc/apache2/conf.d/userdata/ssl/2_4/usuario/seudominio.com.br

2. Crie o arquivo com a exceção nas duas pastas, por exemplo modsec.conf:

   <IfModule security2_module>
       SecRuleRemoveById 942100
   </IfModule>

   Para mais de uma regra, separe os IDs por espaço: SecRuleRemoveById 942100 942200.
3. Recompile a configuração e reinicie o Apache:

   /usr/local/cpanel/scripts/rebuildhttpdconf
   /usr/local/cpanel/scripts/restartsrv_httpd

4. Teste a ação que estava bloqueada. Se outro ID aparecer na Hits List, repita com ele.

Para aplicar a exceção a todos os domínios de uma conta, grave o arquivo um nível acima, em .../2_4/usuario/modsec.conf.

Opção 2: desativar o ModSecurity num domínio pelo cPanel

Funciona para o próprio cliente da hospedagem, sem acesso root, desde que o administrador tenha liberado o recurso.

1. Entre no cPanel e abra Segurança » ModSecurity.
2. Localize o domínio na lista e mude a chave para Off.
3. Teste a ação que estava bloqueada.
4. Volte para On assim que identificar a regra (opção 1). Deixar desligado de vez tira a proteção do site contra ataques automatizados.

Se o item não aparece no cPanel, o administrador precisa instalar o módulo pelo EasyApache 4 e liberar o recurso ModSecurity Domain Manager no Feature Manager do WHM.

Opção 3: desativar uma regra no servidor inteiro

Em WHM » Security Center » ModSecurity™ Tools, na Hits List, clique no ID da regra e depois em Disable. Use só quando a regra causa falso positivo em muitos sites, como uma regra que bloqueia o painel de um CMS popular. Para grupos inteiros de regras, use o botão Edit do fornecedor em ModSecurity™ Vendors.

Servidores sem cPanel (Apache 2.4)

No Apache 2.4 com ModSecurity 2, as diretivas vão no bloco <VirtualHost> do site, não no arquivo htaccess (o ModSecurity 2 ignora as diretivas antigas SecFilterEngine do ModSecurity 1, que não existe mais):

<VirtualHost *:443>
    ServerName seudominio.com.br
    # ... resto da configuração ...
    <IfModule security2_module>
        SecRuleRemoveById 942100
    </IfModule>
</VirtualHost>

Para desligar o ModSecurity só nesse site, use SecRuleEngine Off no lugar de SecRuleRemoveById. Depois teste e recarregue: apachectl configtest && systemctl reload httpd (no Ubuntu e no Debian, systemctl reload apache2).

Problemas comuns

Removi a regra e o 403 continua

Confira se o arquivo foi para a pasta certa (ssl para sites em HTTPS), se o rebuildhttpdconf rodou sem erro e se a Hits List agora mostra outro ID. Também pode não ser o ModSecurity: permissões de arquivo e regras no arquivo htaccess também geram 403.

O 403 parou, mas o IP do cliente continua bloqueado

Com o CSF, cada disparo do ModSecurity conta para o bloqueio no firewall (LF_MODSEC). Depois de corrigir a regra, desbloqueie o IP com csf -dr IP ou csf -tr IP.