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,\nsempre 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.

Conclusão

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.

Este post está licenciado sob CC BY-NC.