Dominando cpguard CLI: diagnóstico real do erro "firewall is disabled

Esse cenário já apareceu mais de uma vez: painel cPGuard com sensação de "ok", mas no terminal o comando de checagem retorna Firewall is disabled. Em ambiente de hospedagem isso é crítico, porque dá falsa percepção de proteção ativa enquanto o enforcement de rede está desligado.

Sinal de incidente#

Comando:

cpgcli ip --check 1.2.3.4

Retorno com firewall desativado indica que os módulos de malware/WAF podem até estar ativos, mas camada de firewall não está aplicando bloqueios.

Diagnóstico correto em sequência#

1. estado global:

cpgcli status

1. estado específico do firewall:

cpgcli fw --status

1. serviços subjacentes do host (iptables/nftables):

iptables -S | head
nft list ruleset | head

Ativação segura (sem auto-bloqueio)#

Nunca ativo firewall sem permitir IP administrativo primeiro.

cpgcli ip --allow 203.0.113.10 --reason "Acesso administrativo"
cpgcli fw --enable

Depois, valido novamente:

cpgcli fw --status
cpgcli ip --check 203.0.113.10

Comandos de operação diária#

cpgcli ip --temp-ban --list
cpgcli ip --temp-ban --remove 203.0.113.10
cpgcli waf --watch

Evidência e auditoria pós-correção#

Registro mínimo que guardo no ticket:

1. output de cpgcli fw --status antes/depois;
2. IP allowlist aplicado;
3. teste de conectividade externa após ativação;
4. logs de bloqueio em tempo real (waf --watch).

Erros comuns durante correção#

GUI mostra ativo, CLI mostra inativo#

Causa: descompasso de estado entre módulos ou serviço reiniciado parcialmente.

Lockout de acesso SSH#

Causa: ativação sem whitelist prévia. Mitigação: sempre sessão secundária aberta (console/IPMI) antes de mudança.

Rollback de emergência#

Se o firewall recém-ativado causar bloqueio indevido, aplico reversão imediata:

cpgcli fw --disable
cpgcli ip --allow 203.0.113.10 --reason "Recuperacao acesso"

Depois reviso regras e ativo novamente de forma gradual. Em host crítico, sempre mantenho sessão de console fora do canal SSH antes de alterar política.

Monitoramento pós-ativação#

Nos primeiros minutos pós-change, acompanho:

1. tentativas de conexão administrativa;
2. eventos WAF de falso positivo;
3. status do painel e serviços de e-mail/web.

Isso evita que uma ativação "tecnicamente correta" gere indisponibilidade operacional não percebida.

Integração com processo de mudança (change management)#

No meu fluxo, ativação de firewall no cPGuard entra como mudança controlada:

1. janela definida;
2. responsável técnico com console out-of-band;
3. evidência de backup de regra atual;
4. critério de sucesso e rollback explícitos.

Esse nível de disciplina impede que correção de segurança vire incidente de acesso administrativo em ambiente de produção.

Considerações práticas#

No cPGuard, a referência operacional deve ser CLI, não percepção visual da GUI. Com fluxo de diagnóstico, whitelist preventiva e validação pós-ativação, o erro "Firewall is disabled" deixa de ser armadilha recorrente e vira rotina de resolução controlada.

Veja também

Infraestrutura Migrando do cPanel para DirectAdmin: como gerar backups via CLI

Infraestrutura Melhores painéis de controle Linux: cPanel, DirectAdmin, CyberPanel ou CloudPanel?

Infraestrutura Guia Definitivo de Troubleshooting de Let's Encrypt e SSL no DirectAdmin (CLI, CAA e Subdomínio WWW)

Este post está licenciado sob CC BY-NC.