Como Configurar um Firewall para Seu Hospedagem cPanel

Proteger um servidor cPanel sem uma firewall devidamente configurada é como deixar a porta principal de um centro de dados desbloqueada. O ConfigServer Security & Firewall (CSF) é o padrão de facto para fortalecer ambientes cPanel e WHM — integra-se diretamente na interface do WHM, envolve o iptables (ou nftables em kernels mais recentes), e inclui um daemon complementar chamado Login Failure Daemon (LFD) que trata da deteção de intrusões em tempo real. Este guia apresenta uma implementação completa de CSF para produção: instalação, arquitetura de regras, mitigação avançada de ameaças e um fluxo de trabalho de manutenção contínua.

Quer esteja a executar um VPS com cPanel ou um Servidor Dedicado completo, os princípios de configuração são idênticos. A diferença é que numa máquina dedicada tem acesso exclusivo ao kernel, o que significa que as funcionalidades de rastreamento de conexões mais agressivas do CSF e de proteção contra inundações SYN podem ser utilizadas com mais intensidade sem afetar outros utilizadores.

Por Que Uma Firewall de Software Não É Opcional em Servidores cPanel

O cPanel expõe uma grande superfície de ataque por design. Uma instalação padrão abre dezenas de portas de serviço — WHM (2086/2087), cPanel (2082/2083), FTP (21), submissão de correio (587), IMAP (993), POP3 (995), entre outras. Cada porta aberta é um potencial vetor de entrada. Sem um filtro de pacotes com estado à frente destes serviços:

• Ataques de força bruta contra SSH, FTP e webmail têm sucesso silenciosamente
• Bots de preenchimento de credenciais atacam os endpoints xmlapi e cpsrvd
• O tráfego DDoS baseado em amplificação satura a NIC antes que a camada de aplicação possa responder
• Contas de alojamento partilhado comprometidas podem mover-se lateralmente pelo servidor

Uma firewall de hardware na periferia da rede ajuda, mas não consegue ver o contexto da camada de aplicação — não sabe que um IP falhou 20 logins IMAP consecutivos em 60 segundos. O CSF + LFD opera ao nível do host e reage exatamente a esse tipo de sinal comportamental.

CSF vs. Outras Opções de Firewall para cPanel

O CSF supera em todos os aspetos que importam para um ambiente cPanel. A única razão para escolher firewalld ou ufw é se estiver a executar uma stack sem cPanel e preferir uma ferramenta mais leve.

Passo 1: Lista de Verificação Pré-Instalação

Antes de executar um único comando, complete estas verificações. Ignorá-las é como os administradores ficam acidentalmente sem acesso a servidores de produção.

Verifique o seu acesso fora de banda. Confirme que tem acesso à consola do seu fornecedor de alojamento (KVM over IP, IPMI, ou uma consola VNC baseada na web). Se o CSF bloquear o seu IP durante os testes, o acesso à consola é o seu caminho de recuperação.

Registe o seu endereço IP de gestão. Execute o seguinte a partir da sua máquina local:

curl -4 ifconfig.me

Irá colocar este IP na lista de permissões do CSF antes de ativar o modo de aplicação.

Verifique o estado atual do iptables:

iptables -L -n --line-numbers

Se outra ferramenta de firewall (APF, firewalld) já estiver ativa, pare-a e desative-a antes de instalar o CSF para evitar conflitos de regras.

Confirme que o Perl está instalado (o CSF é baseado em Perl):

perl -v

Num sistema CentOS/AlmaLinux/CloudLinux novo, o Perl está presente por padrão. Em instalações mínimas de Ubuntu, instale-o com apt install perl.

Passo 2: Instalar o CSF no Seu Servidor cPanel

Ligue-se ao seu servidor como root via SSH:

ssh root@YOUR_SERVER_IP

Descarregue, extraia e execute o instalador:

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf
sh install.sh

O instalador regista o CSF como um serviço do sistema, instala o plugin do WHM e coloca o ficheiro de configuração principal em /etc/csf/csf.conf.

Execute a verificação de dependências integrada para confirmar que todos os módulos Perl necessários estão presentes:

perl /usr/local/csf/bin/csftest.pl

Qualquer linha marcada como FATAL deve ser resolvida antes de continuar. As linhas marcadas como WARN são funcionalidades opcionais — reveja-as, mas não impedirão o CSF de funcionar.

Verifique a versão instalada:

csf -v

Passo 3: Configuração Principal em /etc/csf/csf.conf

Abra o ficheiro de configuração principal no seu editor preferido:

nano /etc/csf/csf.conf

O ficheiro tem comentários extensos. As seguintes diretivas têm o maior impacto na segurança e devem ser revistas em cada nova implementação.

Modo de Teste

Quando o CSF é instalado pela primeira vez, TESTING = "1" é definido por padrão. Neste modo, o LFD não inicia e nenhum bloqueio é aplicado — as regras são carregadas mas temporárias. Não desative o modo de teste até ter colocado o seu IP de gestão na lista de permissões e validado todas as regras de portas.

TESTING = "0"   # Set this only after full validation

Listas de Permissões de Portas de Entrada e Saída

TCP_IN e TCP_OUT definem quais as portas TCP permitidas em cada direção. Um servidor cPanel mínimo mas funcional necessita de:

TCP_IN = "20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096"
TCP_OUT = "20,21,22,25,53,80,110,113,443,587,993,995"
UDP_IN = "20,21,53"
UDP_OUT = "20,21,53,113,123"

Nota operacional crítica: A porta 2087 é o WHM SSL. A porta 2083 é o cPanel SSL. Se remover estas de TCP_IN antes de colocar o seu IP na lista de permissões, perderá imediatamente o acesso ao painel de controlo. A porta 123 (UDP saída) é NTP — removê-la quebra a sincronização de tempo, o que causa falhas em cascata na validação de certificados SSL e rejeições de entrega de correio.

Feche todas as portas que não estejam em uso ativo. Execute ss -tlnp para auditar o que está realmente a escutar antes de finalizar esta lista.

Colocar o Seu IP de Gestão na Lista de Permissões

Adicione o seu IP ao /etc/csf/csf.allow antes de desativar o modo de teste:

echo "YOUR.MANAGEMENT.IP # My office IP" >> /etc/csf/csf.allow

Em alternativa, use o comando CSF diretamente:

csf -a YOUR.MANAGEMENT.IP "Management workstation"

Os IPs na lista de permissões ignoram todos os bloqueios do LFD e todas as regras de limitação de taxa. Mantenha esta lista mínima — cada entrada é uma exceção permanente à sua política de segurança.

Bloquear IPs Maliciosos Conhecidos

Os bloqueios permanentes vão para /etc/csf/csf.deny:

csf -d MALICIOUS.IP.ADDRESS "Confirmed scanner"

Para importações em massa de feeds de inteligência de ameaças (Spamhaus DROP, Emerging Threats, etc.), adicione CIDRs diretamente ao /etc/csf/csf.deny e recarregue:

csf -r

Passo 4: Configurar o Login Failure Daemon (LFD)

O LFD é o componente de deteção de intrusões comportamental do CSF. Monitoriza os ficheiros de registo do sistema em tempo real, conta as falhas de autenticação por IP de origem e aciona um bloqueio temporário quando um limiar é ultrapassado. Esta é a sua principal defesa contra ataques de força bruta de credenciais.

Diretivas principais do LFD em csf.conf:

Caso extremo a conhecer: Se o seu servidor estiver atrás de um gateway NAT ou de um router de escritório partilhado, múltiplos utilizadores legítimos partilham um IP externo. Definir LF_TRIGGER demasiado baixo bloqueará todo o seu escritório após alguns erros de digitação. Aumente o limiar ou coloque o IP do escritório na lista de permissões em csf.allow.

O LFD também monitoriza processos suspeitos, eventos de monitorização de diretórios e deteção de alterações de ficheiros (as funcionalidades LF_DIRWATCH e LF_INTEGRITY). Ative LF_INTEGRITY para detetar modificações não autorizadas em binários do sistema:

LF_INTEGRITY = "3600"   # Check every hour

Passo 5: Funcionalidades Avançadas de Mitigação de Ameaças

Proteção Contra Inundação SYN

Os ataques de inundação SYN esgotam a tabela de conexões TCP enviando grandes volumes de pacotes SYN sem completar o handshake. Ative a mitigação integrada do CSF:

SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

Estes valores permitem 100 novos pacotes SYN por segundo com uma tolerância de burst de 150 antes de a regra ser acionada. Ajuste estes números com base no seu tráfego legítimo de pico — um site de e-commerce durante uma venda relâmpago pode necessitar de valores de burst mais elevados.

Rastreamento de Conexões

O rastreamento de conexões limita o número total de conexões simultâneas de um único IP em todas as portas. Isto é eficaz contra ataques DDoS de taxa lenta e esgotamento de conexões:

CT_LIMIT = "300"
CT_INTERVAL = "30"
CT_BLOCK_TIME = "1800"
CT_SKIP_LOCAL = "1"

CT_SKIP_LOCAL impede que as conexões localhost e loopback sejam contabilizadas no limite — essencial em servidores onde os daemons do cPanel comunicam internamente via TCP.

Deteção de Varredura de Portas

O CSF pode detetar e bloquear hosts que sondam múltiplas portas numa janela curta:

PS_INTERVAL = "300"
PS_LIMIT = "10"
PS_BLOCK_TIME = "3600"
PS_PERMANENT = "0"

Um IP que acede a 10 ou mais portas fechadas em 300 segundos é bloqueado durante uma hora. Defina PS_PERMANENT = "1" apenas se tiver a certeza de que os seus utilizadores legítimos nunca acionarão isto acidentalmente — alguns clientes de correio e ferramentas de monitorização sondam múltiplas portas durante a negociação de conexão.

Bloqueio por País

Se a sua aplicação não tem utilizadores legítimos em determinadas regiões de alto risco, bloquear ao nível do país reduz drasticamente o ruído nos seus registos e a carga de trabalho do LFD. Edite csf.conf:

CC_DENY = "CN,RU,KP,NG"
CC_ALLOW = ""

Os códigos de país seguem o padrão ISO 3166-1 alpha-2. O CSF descarrega dados GeoIP automaticamente. Seja preciso aqui — bloquear países inteiros é um instrumento grosseiro. Uma abordagem melhor para a maioria das implementações é CC_ALLOW (lista de permissões apenas dos países onde os seus utilizadores estão localizados) combinado com CC_ALLOW_PORTS para restringir o acesso baseado em país a portas específicas apenas.

Restrições SMTP de Saída

Instalações WordPress comprometidas e scripts vulneráveis são frequentemente usados como retransmissores de spam. O CSF pode restringir o SMTP de saída apenas a processos de correio autorizados:

SMTP_BLOCK = "1"
SMTP_ALLOWUSER = "mailman"
SMTP_ALLOWGROUP = "mail"

Isto bloqueia todas as conexões de saída na porta 25, exceto de processos a correr como o utilizador ou grupo especificado. A entrega legítima de correio através do seu MTA (Exim no cPanel) não é afetada porque o Exim corre como o grupo mail. Esta única diretiva elimina uma classe inteira de abuso de spam por conta comprometida.

Se precisar de infraestrutura de correio de saída de nível profissional ao lado do seu alojamento, considere associar o seu servidor a uma solução dedicada de Alojamento de Email para correio transacional e de marketing.

Passo 6: Aplicar e Testar a Configuração

Depois de ter revisto todas as diretivas, recarregue o CSF para aplicar as alterações sem um reinício completo:

csf -r

Para reiniciar completamente tanto o CSF como o LFD:

csf -ra

Verifique o estado atual e a contagem de regras ativas:

csf -l

Verifique se o LFD está a correr:

systemctl status lfd

Teste a partir de um IP externo (não o seu IP de gestão na lista de permissões) que o bloqueio de portas está a funcionar conforme esperado. Use nmap a partir de uma máquina separada:

nmap -sS -p 1-65535 YOUR_SERVER_IP

Apenas as portas explicitamente listadas em TCP_IN devem aparecer como abertas. Todas as outras devem retornar filtered.

Desative o modo de teste apenas após esta validação ser aprovada:

# In /etc/csf/csf.conf, set TESTING = "0", then:
csf -r

Passo 7: Configuração da GUI do WHM

Para administradores que preferem uma interface gráfica, o CSF integra-se completamente no WHM. Navegue até WHM > Plugins > ConfigServer Security & Firewall. A partir daqui pode:

• Ver a lista de bloqueios em tempo real e desbloquear IPs manualmente
• Adicionar entradas temporárias e permanentes de permissão/negação
• Acionar uma verificação de configuração que valida a sintaxe de csf.conf
• Ver registos do LFD numa interface paginada e pesquisável
• Executar a ferramenta de sincronização de cluster se gerir múltiplos servidores

A interface do WHM é particularmente útil para equipas de suporte que precisam de desbloquear o IP de um cliente legítimo sem acesso SSH. Conceda acesso ao plugin CSF a contas de revendedor WHM de forma seletiva — nem todos os revendedores precisam de capacidade de gestão de firewall.

Passo 8: Monitorização, Análise de Registos e Manutenção

Monitorização de Registos em Tempo Real

O LFD escreve eventos de bloqueio em /var/log/lfd.log. Monitorize-o durante um incidente ativo:

tail -f /var/log/lfd.log

O próprio registo de atividade do CSF está em /var/log/csf.log. Para um resumo dos IPs mais frequentemente bloqueados nas últimas 24 horas:

grep "Blocked" /var/log/lfd.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Alertas por Email

Configure o LFD para enviar alertas para o seu endereço administrativo:

LF_ALERT_TO = "admin@yourdomain.com"
LF_ALERT_FROM = "lfd@yourdomain.com"

Ative tipos de alerta específicos:

LF_EMAIL_ALERT = "1"      # Block alerts
LT_EMAIL_ALERT = "1"      # Login tracking alerts
RT_EMAIL_ALERT = "1"      # Resource usage alerts

Evite ativar todos os tipos de alerta num servidor ocupado — a fadiga de alertas faz com que os administradores comecem a ignorar as notificações, o que derrota completamente o propósito.

Atualizar o CSF

O CSF lança atualizações com frequência. Execute o atualizador integrado:

csf -u

Isto descarrega a versão mais recente, preserva os seus ficheiros de configuração e reinicia o serviço. Agende isto numa tarefa cron semanal:

0 3 * * 0 /usr/sbin/csf -u >> /var/log/csf_update.log 2>&1

Integração com cPHulk

O cPanel inclui a sua própria ferramenta de proteção contra força bruta chamada cPHulk. Executar tanto o cPHulk como o LFD simultaneamente cria bloqueios redundantes e pode causar confusão durante a resposta a incidentes. A abordagem recomendada: desative o cPHulk e confie exclusivamente no LFD, que é mais configurável e integra-se com a lista de bloqueios unificada do CSF.

Desative o cPHulk via WHM em Security Center > cPHulk Brute Force Protection.

Arquitetura de Firewall para Ambientes Multi-Servidor

Se gerir múltiplos servidores cPanel — um padrão comum com clusters de Alojamento VPS ou um servidor web principal associado a um servidor de base de dados separado — a funcionalidade de sincronização de cluster do CSF permite-lhe propagar listas de bloqueios por todos os nós simultaneamente.

Configure os membros do cluster em /etc/csf/csf.conf:

CLUSTER_MASTER = "PRIMARY_SERVER_IP"
CLUSTER_SENDTO = "SECONDARY_SERVER_IP"
CLUSTER_RECVFROM = "PRIMARY_SERVER_IP"
CLUSTER_KEY = "your_shared_secret_key"

Quando o LFD bloqueia um IP no servidor principal, o bloqueio é automaticamente propagado para todos os membros do cluster em segundos. Isto é particularmente valioso quando um scanner a sondar o seu servidor web também está a tentar força bruta SSH no seu nó de base de dados.

Para ambientes de alto tráfego ou cargas de trabalho intensivas em GPU a correr ao lado de serviços web, a infraestrutura de Alojamento GPU beneficia da mesma abordagem de fortalecimento com CSF — a configuração da firewall é idêntica, mas os valores de CT_LIMIT tipicamente precisam de ser mais elevados para acomodar conexões API paralelas legítimas.

Considerações de Segurança SSL e de Portas

Uma firewall controla o acesso às portas, mas não valida a integridade criptográfica das conexões nessas portas. Certifique-se de que cada serviço exposto através das suas regras de firewall também está protegido com um certificado SSL/TLS válido. Uma porta 443 aberta com um certificado expirado ou autoassinado é um risco de phishing e MITM.

Associe a sua configuração de firewall a certificados devidamente emitidos por uma CA de confiança. A AlexHost fornece Certificados SSL que se integram diretamente com o fluxo de trabalho AutoSSL do cPanel, garantindo que os seus endpoints HTTPS expostos são criptograficamente seguros.

Armadilhas Comuns e Como Evitá-las

Ficar sem acesso durante a configuração inicial. Coloque sempre o seu IP na lista de permissões em csf.allow antes de definir TESTING = "0". Confirme sempre o acesso à consola antes de fazer alterações de aplicação.

Bloquear os próprios serviços internos do cPanel. Os daemons do cPanel comunicam via localhost e por vezes via o IP principal do servidor. CT_SKIP_LOCAL = "1" e uma revisão cuidadosa de TCP_OUT evitam interrupções de serviço auto-infligidas.

LF_DURATION demasiado agressivo em alojamento partilhado. Se utilizadores legítimos partilham um IP NAT com atacantes, um bloqueio de 24 horas penaliza clientes inocentes. Use LF_DURATION = "3600" e LF_PERMBLOCK_COUNT = "4" para escalar apenas reincidentes para banimentos permanentes.

Esquecer de abrir portas de agentes de monitorização. Se usar um serviço de monitorização externo (Zabbix, Nagios, Datadog), o seu agente requer uma porta de entrada aberta. Adicione-a a TCP_IN e coloque o IP do servidor de monitorização na lista de permissões em csf.allow.

Não testar as regras de saída. Os administradores focam-se no TCP_IN de entrada mas negligenciam o TCP_OUT. Regras de saída demasiado restritivas quebram o sistema de atualização do cPanel, as renovações de certificados Let’s Encrypt (porta 80 de saída para servidores ACME) e as conexões MySQL remotas.

Executar o CSF num servidor com proxy Cloudflare. Quando o tráfego passa pelo Cloudflare, o IP de origem visto pelo CSF é um IP de nó de borda do Cloudflare, não o IP real do visitante. Bloquear um IP do Cloudflare bloqueia todo o tráfego através desse nó de borda. Use o ficheiro csf.allow para colocar na lista de permissões os intervalos de IP publicados pelo Cloudflare e configure a sua aplicação para ler o cabeçalho CF-Connecting-IP para os IPs reais dos visitantes.

Matriz de Decisão Técnica: Escolher o Seu Perfil de Configuração CSF

Principais Conclusões: Lista de Verificação de Prontidão para Produção

Antes de considerar a sua implementação CSF pronta para produção, verifique cada item abaixo:

• O IP de gestão está presente em /etc/csf/csf.allow e confirmado com csf -g YOUR.IP

TESTING = "0" está definido e csf -r foi executado
TCP_IN contém apenas portas com serviços ativos e intencionais — verificado contra ss -tlnp

SMTP_BLOCK = "1" está ativado a menos que o servidor seja um relay de correio dedicado
O LFD está a correr — confirmado com systemctl status lfd

LF_PERMBLOCK_COUNT e LF_PERMBLOCK_INTERVAL estão configurados para escalar reincidentes
CT_LIMIT está definido e ajustado às suas conexões simultâneas de pico esperadas
SYNFLOOD = "1" está ativado com valores de taxa apropriados para o seu volume de tráfego
Os alertas por email estão configurados e um alerta de teste foi recebido
O cPHulk está desativado no WHM para evitar conflitos com o LFD
Uma tarefa cron semanal de csf -u está agendada
O acesso à consola/IPMI foi testado independentemente do SSH
As regras de portas de saída (TCP_OUT) foram validadas — as atualizações do cPanel, Let’s Encrypt e NTP funcionam corretamente
Se usar Cloudflare, os intervalos de IP do Cloudflare estão na lista de permissões em csf.allow

FAQ

Qual é a diferença entre o CSF e uma firewall de hardware, e preciso de ambos?

Uma firewall de hardware opera no perímetro da rede e filtra o tráfego antes de chegar à NIC do seu servidor. O CSF opera ao nível do sistema operativo e adiciona deteção comportamental com consciência de aplicação que as firewalls de hardware não conseguem fornecer — como bloquear um IP após logins falhados repetidos no cPanel. Num ambiente de produção, ambas as camadas são complementares. A filtragem de hardware reduz a carga de DDoS volumétrico; o CSF trata das tentativas de intrusão direcionadas.

Como desbloquear um IP que o CSF baniu permanentemente?

Execute csf -dr BLOCKED.IP.ADDRESS para o remover da lista de negação, depois csf -r para recarregar as regras. Em alternativa, use a interface do plugin CSF no WHM em “Unblock an IP.” Para evitar o re-bloqueio, adicione o IP a csf.allow com csf -a IP.ADDRESS "reason".

O CSF irá interferir com as renovações de certificados Let’s Encrypt / AutoSSL?

Apenas se a porta 80 de saída estiver bloqueada em TCP_OUT ou se os IPs do servidor de validação Let’s Encrypt estiverem inadvertidamente em csf.deny. Certifique-se de que a porta 80 está em ambos TCP_IN (para respostas ao desafio HTTP-01) e TCP_OUT (para comunicação com o servidor ACME). Se as renovações falharem após a instalação do CSF, verifique csf.deny para quaisquer intervalos de IP do Let’s Encrypt e reveja /var/log/lfd.log para conexões de saída bloqueadas.

Como testar com segurança uma nova regra CSF sem arriscar um bloqueio?

Reative temporariamente o modo de teste definindo TESTING = "1" em csf.conf e executando csf -r. No modo de teste, as regras são carregadas mas não aplicadas, e o LFD não inicia. Valide as suas alterações, depois defina TESTING = "0" e recarregue. Tenha sempre o acesso à consola confirmado antes de voltar ao modo de aplicação.

O CSF protege contra ataques de camada de aplicação como injeção SQL ou XSS?

Não. O CSF opera nas camadas de rede e transporte (L3/L4) e não tem visibilidade sobre os payloads de pedidos HTTP. Os ataques de camada de aplicação requerem uma Firewall de Aplicação Web (WAF) como o ModSecurity com o OWASP Core Rule Set, que se integra com Apache e Nginx em servidores cPanel. O CSF e o ModSecurity são complementares — o CSF trata das ameaças ao nível da rede enquanto o ModSecurity trata dos ataques ao nível HTTP. O LFD pode ser configurado para bloquear IPs que acionam regras do ModSecurity repetidamente através da diretiva LF_MODSEC.