O que é CSF (ConfigServer Security and Firewall)? Um Guia Técnico Completo

CSF, ou ConfigServer Security & Firewall, é um firewall de inspeção de pacotes com estado (SPI), um daemon de deteção de falhas de login e um conjunto de reforço de segurança para servidores Linux. Funciona como um frontend rico em funcionalidades para iptables (e nftables em kernels mais recentes), abstraindo a gestão complexa de regras numa camada de configuração estruturada, ao mesmo tempo que adiciona deteção ativa de ameaças através do seu daemon complementar, LFD (Login Failure Daemon).

Para qualquer servidor Linux em produção — seja a executar alojamento partilhado, um VPS ou um ambiente dedicado de bare-metal — o CSF fornece defesa perimetral em camadas: filtragem de tráfego de entrada/saída, análise de registos em tempo real, mitigação de força bruta, deteção de varrimento de portas e controlo de acesso por país, tudo gerível através de uma CLI ou de uma interface web integrada com cPanel, DirectAdmin ou Webmin.

Como o CSF Funciona Internamente

O CSF não substitui o iptables nem o nftables — gere-os. Quando define regras em /etc/csf/csf.conf ou manipula listas de IP, o CSF traduz essas diretivas em regras netfilter ao nível do kernel e aplica-as atomicamente.

A arquitetura tem dois componentes principais a funcionar em simultâneo:

• csf — o motor de regras de firewall que lê os ficheiros de configuração e preenche as cadeias iptables/ip6tables.
• lfd — um daemon persistente que monitoriza os ficheiros de registo do sistema em tempo real, avalia os eventos de autenticação em relação a limiares configuráveis e instrui o csf a bloquear ou desbloquear endereços IP dinamicamente.

No arranque, o CSF elimina as cadeias existentes e reconstrói-as de raiz com base na sua configuração. Esta abordagem de “estado limpo” evita a acumulação de regras e garante que o estado da firewall é sempre determinístico e auditável.

Modos de Funcionamento do CSF

O CSF opera numa de duas posturas fundamentais de tráfego:

Modo de Permissão (predefinição para a maioria das implementações): Todo o tráfego de entrada e saída é negado por predefinição. Apenas as portas explicitamente listadas nas diretivas TCP_IN, TCP_OUT, UDP_IN e UDP_OUT são permitidas. Esta é a postura de produção recomendada.

Modo de Teste (TESTING = "1"): O CSF carrega as regras, mas o LFD não aplica bloqueios. Isto evita que fique bloqueado durante a configuração inicial. Desative sempre o modo de teste antes de entrar em produção:

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

Principais Funcionalidades do CSF Explicadas

Motor de Regras de Firewall

O CSF gere quatro listas de portas principais em csf.conf:

TCP_IN / UDP_IN — portas abertas para ligações de entrada
TCP_OUT / UDP_OUT — portas permitidas para ligações de saída

Uma configuração mínima de servidor web pode ter o seguinte aspeto:
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"
Além da gestão de portas, o CSF suporta regras baseadas em CIDR, permitindo-lhe permitir ou negar intervalos de rede inteiros. As regras são armazenadas em ficheiros simples para facilitar o controlo de versões:




Ficheiro
Finalidade




/etc/csf/csf.allow
IPs ou CIDRs permanentemente na lista de permissões


/etc/csf/csf.deny
IPs ou CIDRs permanentemente bloqueados


/etc/csf/csf.ignore
IPs que o LFD nunca bloqueará automaticamente


/etc/csf/csf.dyndns
Nomes de host DNS dinâmicos para resolução automática e permissão




Login Failure Daemon (LFD)
O LFD é a camada de inteligência ativa do CSF. Monitoriza ficheiros de registo — incluindo /var/log/secure, /var/log/maillog, /var/log/exim_mainlog e outros — e conta as falhas de autenticação por IP de origem dentro de uma janela de tempo configurável.
Diretivas de configuração principais do LFD:

LF_TRIGGER — número de falhas antes de um bloqueio ser emitido
LF_INTERVAL — a janela de tempo rotativa (em segundos) para contagem de falhas
LF_DURATION — duração de um bloqueio temporário (0 = permanente)
LF_SSH, LF_FTPD, LF_SMTPAUTH, LF_POP3D, LF_IMAPD — limiares de falhas por serviço

Um exemplo prático de reforço: defina LF_SSH = "5" com LF_INTERVAL = "300" para bloquear qualquer IP que falhe a autenticação SSH 5 vezes em 5 minutos. Esta única diretiva elimina a grande maioria dos ataques automatizados de preenchimento de credenciais direcionados à porta 22.
Caso extremo crítico: Se o seu sistema de monitorização ou agente de backup se autenticar a partir de um IP dinâmico, acabará por acionar o LFD. Adicione sempre esses IPs de origem ao /etc/csf/csf.ignore antes de apertar os limiares.
Deteção de Intrusões e Rastreamento de Processos
Além da monitorização de logins, o LFD executa várias funções de deteção de intrusões baseadas no host:

PT_LOAD — monitoriza a carga da CPU e alerta ou bloqueia se um processo exceder os limiares definidos, útil para detetar criptomineração ou processos descontrolados em infraestruturas partilhadas.
PT_USERMEM e PT_USERTIME — limites de memória e tempo de CPU por utilizador, críticos para ambientes de alojamento web partilhado onde o isolamento de recursos é essencial.
LF_DIRWATCH — monitoriza diretórios especificados para alterações de ficheiros, fornecendo monitorização rudimentar da integridade dos ficheiros.
LF_SCRIPT_ALERT — deteta scripts que enviam email em excesso, um indicador comum de uma aplicação PHP comprometida.

Deteção de Varrimento de Portas
O CSF utiliza o rastreamento do módulo iptables recent para identificar hosts que sondam múltiplas portas em rápida sucessão. As diretivas PS_INTERVAL, PS_LIMIT e PS_PORTS controlam a sensibilidade. Quando um varrimento de portas é detetado, o IP de origem é imediatamente adicionado à lista de negação e é enviado um alerta.
Uma subtileza que vale a pena conhecer: a deteção agressiva de varrimento de portas pode gerar falsos positivos de scanners de rede legítimos utilizados por equipas de segurança ou serviços de monitorização de disponibilidade. Adicione proativamente esses IPs de scanner ao csf.ignore.
DDoS e Limitação da Taxa de Ligações
O CSF fornece vários mecanismos para absorver ou deflectir ataques volumétricos:

CT_LIMIT — número máximo de ligações simultâneas por IP. Definir este valor para 100–300 para servidores web evita que um único host monopolize os slots de ligação.
CT_INTERVAL — frequência com que o rastreador de ligações é executado.
SYNFLOOD e SYNFLOOD_RATE — ativa a proteção contra inundações SYN do iptables com um limite de taxa de pacotes configurável.
UDPFLOOD — limita a taxa de pacotes UDP por IP, mitigando ataques de amplificação UDP.

É importante compreender o âmbito de mitigação DDoS do CSF: é eficaz contra ataques na camada de aplicação e ataques de baixo volume na camada de rede originários de um número limitado de fontes. Contra um DDoS volumétrico de grande escala (dezenas de Gbps), é necessário null-routing upstream ou um serviço dedicado de limpeza de DDoS. O CSF complementa, mas não substitui, a proteção de rede upstream.
Controlo de Acesso por País (CC_DENY / CC_ALLOW)
O CSF integra-se com as bases de dados GeoIP da MaxMind para aplicar políticas de acesso geográfico. A diretiva CC_DENY aceita códigos de país ISO 3166-1 alpha-2:
CC_DENY = "CN,RU,KP,IR"
Alternativamente, CC_ALLOW_FILTER combinado com CC_DENY = "ALL" cria uma política geográfica apenas com lista de permissões — útil para serviços que servem legal ou operacionalmente apenas jurisdições específicas.
Armadilha operacional: As bases de dados GeoIP não são perfeitamente precisas. Utilizadores legítimos por trás de VPNs corporativas ou nós de borda CDN podem parecer originar-se de um país bloqueado. Combine o bloqueio por país com a lista de permissões de IP para parceiros conhecidos.
Bloqueios Temporários e Desbloqueio
O CSF suporta bloqueios com limite de tempo, que são preferíveis a banimentos permanentes em casos ambíguos:
# Block an IP for 3600 seconds (1 hour)
csf -td 192.168.1.100 3600 "Suspicious scan activity"

# Remove a temporary block manually
csf -tr 192.168.1.100

# Check if an IP is currently blocked
csf -g 192.168.1.100
Alertas e Relatórios por Email
O CSF envia notificações por email para uma ampla gama de eventos. A diretiva LF_ALERT_TO define o endereço do destinatário. As categorias de alerta incluem:

Violações do limiar de falhas de login
Logins root bem-sucedidos
Deteções de varrimento de portas
Violações do limite de recursos de processos
Alterações nas regras de firewall
Modificações suspeitas de ficheiros (se LF_DIRWATCH estiver ativado)

Para servidores de alto tráfego, a fadiga de alertas é um risco operacional real. Utilize limiares LF_EMAIL_ALERT e considere encaminhar os alertas do CSF para uma caixa de correio dedicada ou uma integração SIEM em vez de uma caixa de entrada geral. A entrega fiável de alertas depende de uma pilha de correio corretamente configurada — se estiver a executar a sua própria infraestrutura de correio, o alojamento de email com alinhamento SPF/DKIM adequado garante que os alertas do CSF não são silenciosamente descartados como spam.
Instalar o CSF num Servidor Linux
O CSF não está disponível nos repositórios de distribuição padrão. A instalação é simples:
# Download the latest release
cd /usr/src
wget https://download.configserver.com/csf.tgz

# Extract and install
tar -xzf csf.tgz
cd csf
sh install.sh
Após a instalação, verifique se todos os módulos iptables necessários estão disponíveis:
perl /usr/local/csf/bin/csftest.pl
Quaisquer resultados FATAL indicam módulos de kernel em falta que devem ser resolvidos antes de o CSF funcionar corretamente. Os resultados WARN são informativos e tipicamente não bloqueantes.
A configuração inicial encontra-se em /etc/csf/csf.conf. O primeiro passo mais crítico é desativar o modo de teste e definir as suas portas permitidas antes de reiniciar o daemon.
Integração do CSF com Painéis de Controlo
O CSF é fornecido com plugins de UI nativos para os três painéis de controlo de alojamento Linux dominantes:




Painel de Controlo
Método de Integração
Localização na UI




cPanel / WHM
Plugin CSF para WHM
WHM > Plugins > ConfigServer Security & Firewall


DirectAdmin
Plugin CSF
Painel de administração > Funcionalidades Extra


Webmin
Módulo CSF para Webmin
Webmin > Rede > ConfigServer Security & Firewall




A integração com WHM é a mais completa em termos de funcionalidades, expondo o editor completo de ficheiros de configuração, pesquisa de IP, gestão de bloqueios temporários e visualizador de registos dentro da interface WHM. Para administradores que executam VPS com cPanel, o CSF é efetivamente a solução de firewall padrão — está pré-instalado ou é trivialmente instalável em praticamente todas as imagens de VPS cPanel.
Para ambientes sem painel de controlo, a CLI é totalmente capaz. Comandos principais:
csf -s    # Start firewall
csf -f    # Stop (flush) firewall
csf -r    # Restart firewall
csf -l    # List current iptables rules
csf -a 203.0.113.5   # Allow an IP permanently
csf -d 203.0.113.5   # Deny an IP permanently
csf -g 203.0.113.5   # Check block status of an IP
csf -u    # Check for CSF updates
CSF vs. Soluções Alternativas de Firewall para Linux
Compreender onde o CSF se encaixa no ecossistema mais amplo ajuda-o a tomar uma decisão arquitetural informada.




Funcionalidade
CSF + LFD
UFW
firewalld
Fail2ban + iptables




Camada de abstração principal
iptables / nftables
iptables / nftables
nftables / iptables
iptables / nftables


Mitigação ativa de força bruta
Integrada (LFD)
Nenhuma (requer emparelhamento)
Nenhuma (requer emparelhamento)
Funcionalidade principal


Integração com painel de controlo
Nativa (cPanel, DA, Webmin)
Nenhuma
Nenhuma
Limitada


GeoIP / bloqueio por país
Integrado
Nenhum
Nenhum
Via plugin


Deteção de varrimento de portas
Integrada
Nenhuma
Nenhuma
Via filtro


Monitorização de processos/recursos
Integrada (PT_*)
Nenhuma
Nenhuma
Nenhuma


Complexidade de configuração
Média-Alta
Baixa
Média
Média


Adequado para alojamento partilhado
Sim
Não
Não
Parcial


Suporte IPv6
Sim (ip6tables)
Sim
Sim
Sim




Quando escolher o CSF: Está a executar um servidor cPanel/DirectAdmin/Webmin, um VPS ou servidor dedicado num contexto multi-inquilino ou de alojamento, ou precisa de uma única ferramenta que consolide a gestão de firewall, deteção de força bruta e monitorização baseada no host sem reunir múltiplas ferramentas separadas.
Quando considerar alternativas: Está a executar um ambiente de microsserviços em contentores onde a política de rede é gerida na camada de orquestração (Kubernetes NetworkPolicy, Calico), ou precisa de gestão nativa de nftables numa distribuição moderna sem shims de compatibilidade iptables legados.
Casos de Uso Comuns e Cenários de Implementação
Proteger um Servidor de Alojamento Web
Num servidor cPanel típico, o CSF deve ser configurado para:

Abrir apenas as portas necessárias pelos serviços ativos (HTTP, HTTPS, SMTP, IMAP, POP3, FTP, SSH, DNS)
Ativar LF_SCRIPT_ALERT para detetar mailers PHP comprometidos
Definir CT_LIMIT para evitar o esgotamento de ligações de uma única fonte
Ativar a integração MODSEC se o ModSecurity estiver instalado, correlacionando bloqueios WAF com drops ao nível da firewall

Reforçar o Acesso SSH
Combinar o CSF com autenticação SSH baseada em chaves e uma porta SSH não padrão cria uma postura robusta de controlo de acesso:
# Allow only your management IP on the SSH port
# In /etc/csf/csf.allow:
tcp|in|d=2222|s=203.0.113.10  # Replace with your actual management IP and SSH port
Defina LF_SSH = "3" para bloquear qualquer IP após três tentativas falhadas, e adicione o seu IP de gestão ao csf.ignore para evitar o bloqueio acidental de si próprio.
Proteger a Infraestrutura de Email
Os servidores de correio são alvos de alto valor para ataques de força bruta. Os limiares LFD por serviço do CSF (LF_SMTPAUTH, LF_POP3D, LF_IMAPD) devem ser definidos de forma agressiva (3–5 falhas) em qualquer servidor que processe SMTP autenticado. Combine isto com certificados SSL corretamente configurados em todas as portas de correio para evitar a interceção de credenciais que tornaria a proteção contra força bruta inútil.
Cargas de Trabalho GPU e de Alto Desempenho
Para ambientes de alojamento GPU que executam APIs de inferência ML ou serviços de renderização, a proteção CT_LIMIT e SYNFLOOD do CSF é particularmente valiosa — estes serviços frequentemente expõem endpoints de API de alto valor que atraem sondagem automatizada. Restrinja as portas de API a CIDRs de clientes conhecidos via csf.allow e utilize CC_DENY para filtrar geografias sem base de utilizadores legítima.
Lista de Verificação de Reforço da Configuração do CSF
Antes de considerar uma implementação do CSF pronta para produção, verifique o seguinte:

TESTING = "0" está definido e o CSF foi reiniciado
TCP_IN e TCP_OUT contêm apenas as portas necessárias pelos serviços ativos — remova as predefinições que não se aplicam
Os limiares LF_SSH, LF_FTPD, LF_SMTPAUTH estão definidos para 3–5 falhas
Os seus IP(s) de gestão estão em /etc/csf/csf.ignore e /etc/csf/csf.allow

Matriz de Decisão: O CSF é a Ferramenta Certa para o Seu Ambiente?

FAQ

Qual é a diferença entre o CSF e o Fail2ban?

Ambas as ferramentas realizam o bloqueio de IP por força bruta através da análise de ficheiros de registo, mas o CSF é um conjunto de segurança completo que também gere as regras de firewall subjacentes, acesso a portas, limitação da taxa de ligações, monitorização de processos e filtragem GeoIP. O Fail2ban é uma ferramenta focada de prevenção de intrusões que depende de uma firewall externa (iptables, nftables ou firewalld) para a aplicação. Em servidores de alojamento com painéis de controlo, o CSF é a solução operacionalmente mais completa. Em sistemas Linux mínimos ou contentores, o Fail2ban emparelhado com firewalld pode ser mais leve e mais adequado.

O CSF pode bloquear tráfego IPv6?

Sim. O CSF gere conjuntos de regras tanto iptables (IPv4) como ip6tables (IPv6). O suporte IPv6 está ativado por predefinição quando o kernel o suporta. Certifique-se de que IPV6 = "1" está definido em csf.conf e que as suas listas de portas TCP6_IN / TCP6_OUT estão configuradas, pois por predefinição espelham as definições IPv4, mas podem ser personalizadas de forma independente.

Como posso evitar bloquear-me acidentalmente ao configurar o CSF?

Adicione o seu IP de gestão tanto ao /etc/csf/csf.allow como ao /etc/csf/csf.ignore antes de fazer quaisquer alterações restritivas. Mantenha TESTING = "1" durante a configuração inicial — no modo de teste, o CSF carrega as regras, mas o LFD não aplica bloqueios, e as regras são automaticamente eliminadas após 5 minutos se não forem confirmadas. Defina TESTING = "0" apenas depois de ter verificado a conectividade.

O CSF funciona em servidores sem painel de controlo?

Sim, totalmente. O CSF é instalado e gerido inteiramente via linha de comandos. A UI web é uma camada de conveniência opcional para ambientes com painel de controlo. Toda a configuração é feita através de ficheiros simples em /etc/csf/ e o binário CLI csf. Muitos administradores preferem a gestão apenas via CLI para auditabilidade e automação através de ferramentas de gestão de configuração como Ansible ou Puppet.

Com que frequência o CSF deve ser atualizado e como é feito?

O CSF deve ser atualizado sempre que uma nova versão for lançada, particularmente para alterações relevantes para a segurança. Verifique se há atualizações com csf -u, que compara a versão instalada com o lançamento mais recente no servidor de download do ConfigServer. As atualizações podem ser aplicadas diretamente a partir da UI do plugin WHM ou via CLI. Automatize a verificação com um cron job semanal, mas aplique as atualizações manualmente após rever o changelog — as atualizações do CSF ocasionalmente alteram valores de configuração predefinidos que requerem revisão antes da implementação.