O mistério do IP fantasma quando o CSF ignora whitelist, NAT e estado de conexão

O mistério do IP fantasma quando o CSF ignora whitelist, NAT e estado de conexão#

Recentemente eu enfrentei um dos cenários mais frustrantes para qualquer analista de infraestrutura: um cliente sendo bloqueado sistematicamente por um servidor cPanel, mesmo com o IP devidamente cadastrado no csf.allow e no csf.ignore.

Esse tipo de incidente parece contrariar a lógica básica do firewall. Se o IP está permitido, o acesso deveria passar. Mas, na prática, o CSF é uma camada de abstração sobre iptables, e em ambientes modernos com NAT, virtualização, conntrack agressivo, filtros de pacote e backends híbridos entre iptables-legacy e nftables, a resposta real pode ser muito menos óbvia.

O cliente reportava Connection Timed Out ao acessar WHM/cPanel nas portas:

2087
2083

O primeiro impulso seria liberar o IP, reiniciar o CSF e seguir o chamado. Mas o IP já estava liberado. E não só em um lugar, estava tanto em allow fixo quanto em ignore:

/etc/csf/csf.allow
/etc/csf/csf.ignore

Foi aí que eu precisei sair da leitura superficial do painel e tratar o caso como um problema de caminho de pacote, estado de conexão e ordem de chains no kernel.

O sintoma que quebrou a lógica do firewall#

Ao analisar o log do lfd, encontrei uma linha estranha:

/var/log/lfd.log: Mar 1 14:57:22 server lfd[4638]: Incoming IP 1.2.3.4 temporary allow removed

O detalhe é que o IP 1.2.3.4 não deveria depender de permissão temporária. Ele já estava em allow fixo. Isso me chamou atenção porque o lfd, o Login Failure Daemon, é um processo em Perl que monitora logs e altera regras de firewall por baixo, gerenciando chains do iptables por chamadas de sistema.

Quando o lfd remove um temporary allow, ele pode acionar reload, flush parcial, reordenação ou reconstrução de regras. Em condições normais isso não deveria afetar o allow fixo, mas em cenários com muitas chains, filtros de integridade e estados INVALID, o pacote pode ser descartado antes de chegar na chain onde a permissão do IP existe.

Essa foi a primeira virada do diagnóstico: o problema não era provar se o IP estava na whitelist, era descobrir se o pacote chegava até a regra de whitelist.

Validação inicial com CSF -g#

Executei a busca padrão no CSF:

csf -g 1.2.3.4

O resultado indicava que o IP aparecia nas chains esperadas, como:

ALLOWIN
ALLOWOUT

Em teoria, o verdict deveria ser ACCEPT. O csf -g consulta as regras do firewall, na prática fazendo uma leitura parecida com:

iptables -L -n | grep 1.2.3.4

Mas aqui mora uma armadilha: csf -g prova que a regra existe, não prova que o pacote passa por ela. Firewall é ordem de avaliação, tabela, chain, estado, interface, roteamento e módulos do kernel, a presença da regra é só o ponto de partida.

Análise de outras chains do iptables#

Para entender a ordem real de execução das regras, é preciso listar todas as chains com seus números de linha:

iptables -L -n --line-numbers

Verifique se existem drops de pacotes globais antes das chains de permissão (como ALLOWIN). No topo da chain INPUT do iptables, o fluxo de prioridades do CSF é inserido na seguinte ordem típica:

# Listar as primeiras regras da chain INPUT
iptables -L INPUT -n -v --line-numbers | head -20

Se houver uma chain de drop de pacotes com estado inválido (ex: INVALID) ou bloqueio por DoS avaliada acima do salto para a chain ALLOWIN, a whitelist do IP é sumariamente ignorada. Além disso, audite se existem chains customizadas ativas que possam estar descartando tráfego preventivamente:

iptables -L -n | grep -E "^Chain (CUSTOM|WHITELIST|BLOCK)"

Para inspecionar de onde o pacote do IP 1.2.3.4 pode estar sendo descartado antes da whitelist, verifique os contadores das chains superiores:

iptables -L INPUT -n -v | grep -B5 "1.2.3.4"

Diagnóstico de rota e NAT#

A primeira verificação de camada de rede foi descobrir como o kernel enxergava a rota de resposta para o IP do cliente:

ip route get 1.2.3.4

O resultado era semelhante a:

[root@server ~]# ip route get 1.2.3.4
1.2.3.4 via 192.168.x.1 dev eth0 src 192.168.x.124

Esse resultado indica um ambiente onde o servidor responde usando um IP interno como source: src 192.168.x.124.

Isso é comum em nuvens privadas, data centers com NAT, hosts atrás de roteadores internos, hypervisors, appliances de borda ou ambientes onde o IP público não está diretamente configurado como endereço primário da interface.

Validação de NAT e roteamento#

Quando o tráfego do cliente passa por NAT (ex: atrás de um firewall de borda ou roteador local), as tabelas de tradução de endereços do iptables do servidor precisam ser validadas. Verifique as regras de NAT ativas para certificar-se de que não há conflitos ou reescritas inesperadas de IPs de origem (SNAT) ou de destino (DNAT):

# Listar regras na tabela nat
iptables -t nat -L -n -v

# Verificar se há SNAT/DNAT ativo na pós-roteação
iptables -t nat -L POSTROUTING -n -v

Verifique se a sessão ativa do IP do cliente existe no pool de conexões com NAT e como o endereço público se traduz para a interface interna:

# Consultar conexões ativas com NAT para o IP
conntrack -L | grep "1.2.3.4"

# Validar o IP público de saída do servidor vs a configuração de interfaces locais
curl ifconfig.me
ip addr show | grep "inet "

Reverse path filtering e martian packets#

O ponto técnico mais importante nessa camada é o rp_filter, o Reverse Path Filtering.

O rp_filter faz o kernel validar se o caminho de resposta para um pacote combina com a interface por onde ele chegou. Se o pacote chega por uma interface, mas o kernel entende que a melhor rota de retorno seria outra, ou se o NAT altera a origem de uma forma inconsistente, o pacote pode ser tratado como suspeito.

Em alguns casos, o kernel descarta esse tráfego como Martian Packet.

Verificação de parâmetros de kernel (sysctl)#

Para auditar o comportamento de rede e validações de caminho reverso do kernel, liste todos os parâmetros sysctl relevantes:

# Validar configurações de rp_filter (0 = desativado, 1 = estrito, 2 = solto)
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter

Se o rp_filter estiver em 1 (estrito) em um ambiente com múltiplas rotas ou NAT de borda assimétrico, os pacotes legítimos serão silenciados antes de passarem pela camada de filtragem do firewall. Adicionalmente, verifique outros parâmetros cruciais para segurança e encaminhamento:

# Verificar encaminhamento e respostas de redirecionamento de ICMP
sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.all.accept_redirects
sysctl net.ipv4.conf.all.send_redirects
sysctl net.ipv4.conf.all.accept_source_route

Se o kernel descarta o pacote cedo demais por violação de rota reversa, a regra do CSF nunca é consultada. O pacote morre antes de chegar na chain LOCALINPUT, antes da regra ALLOWIN, ou até antes de aparecer de forma clara nos logs do CSF.

O impacto do estado INVALID#

Depois eu investiguei a integridade dos pacotes e o estado das conexões.

O CSF pode ativar filtros que dropam pacotes malformados, fora de ordem, com flags TCP suspeitas ou classificados como inválidos pelo conntrack. A configuração crítica é:

# No /etc/csf/csf.conf
PACKET_FILTER = "1"

Com PACKET_FILTER ativo, o CSF insere regras no topo da chain INPUT que usam módulos como state ou conntrack, por exemplo:

-m state --state INVALID -j DROP

ou:

-m conntrack --ctstate INVALID -j DROP

Esse é o pulo do gato. Essas regras costumam aparecer antes das regras específicas de allow por IP. A lógica do firewall é "limpar lixo" antes de processar permissões.

Então, mesmo com o IP em ALLOWIN, se o kernel marcou o pacote como INVALID, ele é descartado antes da regra de allow.

Importante: IP permitido não salva pacote com estado inválido se o DROP de INVALID vem antes.

Esse tipo de problema aparece muito quando o cliente está atrás de NAT agressivo, link instável, CGNAT, balanceamento de saída, middlebox alterando cabeçalho TCP, firewall corporativo reescrevendo sessão ou conexão móvel oscilando.

Ct_limit e nf_conntrack#

Outro ponto que eu avaliei foi o CT_LIMIT.

O conntrack mantém a tabela de conexões conhecidas pelo kernel. Se o cliente abre muitas conexões, comum em APIs, IMAP mobile, Outlook com múltiplas caixas, sincronização agressiva ou navegação com várias sessões, ele pode bater em limites de tracking.

Verificação e correção de overflow do conntrack#

Se a tabela do rastreador de conexões do kernel encher, novas conexões serão marcadas como INVALID e descartadas.

Diagnóstico de Conntrack Overflow:

# Verificar o total de conexões rastreadas atualmente
cat /proc/sys/net/netfilter/nf_conntrack_count

# Verificar o limite máximo da tabela de conntrack
cat /proc/sys/net/netfilter/nf_conntrack_max
sysctl net.netfilter.nf_conntrack_max

Se o valor em nf_conntrack_count estiver próximo ou igual a nf_conntrack_max, o servidor está sob overflow de conntrack. Verifique se o log do kernel acusa estouros de tabela:

dmesg | grep -i "conntrack\|nf_conntrack"
grep -i "table full" /var/log/messages
grep -i "nf_conntrack: table full" /var/log/syslog

Resolução do Conntrack Overflow:

Se detectado estouro, aumente temporariamente os limites do conntrack em tempo de execução:

echo 262144 > /proc/sys/net/netfilter/nf_conntrack_max

# Reduzir o timeout de conexões estabelecidas para liberar espaço na tabela mais rápido
echo 600 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

Para tornar os limites do conntrack permanentes pós-reboot, adicione as diretivas no arquivo /etc/sysctl.conf e aplique:

echo "net.netfilter.nf_conntrack_max=262144" >> /etc/sysctl.conf
echo "net.netfilter.nf_conntrack_tcp_timeout_established=600" >> /etc/sysctl.conf
sysctl -p

Monitoramento direto dos contadores de iptables#

Para validar se o pacote estava realmente chegando na regra de allow, eu monitorei contadores do iptables:

watch -n 1 "iptables -L -n -v | grep 1.2.3.4"

Esse teste é simples, mas muito poderoso. Se o cliente tenta conectar e o contador da regra de allow não sobe, significa que o pacote não está batendo naquela regra.

Eu também verifiquei mensagens do kernel:

dmesg | grep "1.2.3.4"

Quando há logs de martian source, estado inválido ou drops por subsistema, o dmesg pode mostrar o que o CSF não mostra. O CSF não loga tudo. Especialmente drops de PACKET_FILTER podem não aparecer de forma clara no /var/log/lfd.log. Então, confiar só no log do CSF é aceitar uma visão incompleta.

Teste cruzado com camada de serviço#

Como este post nasceu de um caso anterior onde o firewall parecia limpo, mas a causa era o Dovecot saturado, mantivemos a validação de camada de serviço no playbook.

Quando o cliente relata bloqueio, eu não paro no firewall. Também valido se a conexão chega ao host:

ss -ntp | grep '1.2.3.4'

ou:

netstat -atun | grep '1.2.3.4'

Se eu vejo sessões ESTABLISHED em portas como 993, 995, 143, 110, 2083 ou 2087, o tráfego está chegando. Nesse caso, o problema pode estar em limite de serviço, autenticação, aplicação, Dovecot, cPHulk ou outro componente acima da rede.

Para Dovecot, eu valido sessões por IP:

doveadm who | grep '1.2.3.4'

E confiro o limite:

dovecot -n | grep mail_max_userip_connections

Em escritórios com NAT, valores baixos como 10 ou 15 são insuficientes. Um único IP público pode representar vários usuários, cada um com desktop, celular, webmail e reconexões automáticas.

Um ajuste típico que já usei em cenário NAT é:

mail_max_userip_connections = 60

remote 127.0.0.1 {
  mail_max_userip_connections = 150
}

Depois aplico:

dovecot -n
systemctl restart dovecot
systemctl status dovecot --no-pager

Serviços críticos: resolução DNS e SSL/TLS#

Se o cliente continua incapaz de se conectar às portas administrativas do WHM/cPanel (2083 e 2087), é necessário validar se a comunicação SSL/TLS local está operacional e se as resoluções de nomes locais não estão gerando conflitos.

1. Verificação de resolução DNS#

Valide se o IP do cliente resolve de forma correta no servidor e se o hostname da máquina responde a consultas locais:

# Validar resolução reversa do IP do cliente
nslookup 1.2.3.4
dig -x 1.2.3.4 +short

# Verificar IPs resolvidos pelo hostname local
hostname -I

# Verificar se há registros estáticos conflitantes no hosts
grep "1.2.3.4" /etc/hosts

2. Verificação de conexão SSL/TLS nas portas administrativas#

Verifique se o serviço local está respondendo a conexões criptografadas nas portas 2083 ou 2087:

# Testar conexão SSL local no cPanel
openssl s_client -connect localhost:2083 </dev/null 2>/dev/null | grep -i "ssl"

# Verificar validade do certificado SSL do host
openssl x509 -in /etc/ssl/certs/hostname.crt -noout -dates 2>/dev/null || echo "Certificado ausente no caminho padrão."

Pesquise erros de handshake SSL nos logs de erro do Apache:

grep -i "ssl\|tls" /usr/local/apache/logs/error_log | tail -10

Cphulk e bloqueio em camada de aplicação#

Também validei cPHulk, porque ele pode bloquear tentativas no WHM/cPanel sem que isso pareça um drop clássico de firewall.

Em incidentes envolvendo portas 2087 e 2083, eu considero:

• bloqueio por falha de login;
• bloqueio por força bruta;
• usuário repetindo senha antiga;
• automação tentando autenticar;
• IP compartilhado por escritório inteiro;
• NAT fazendo várias pessoas parecerem o mesmo cliente.

Para garantir que o cPHulk não seja o causador de bloqueios sorrateiros do IP em portas cPanel:

/usr/local/cpanel/scripts/cphulkdwhitelist 1.2.3.4

Triagem avançada de SELinux e AppArmor#

Em distribuições com hardening aplicado, os módulos de controle de acesso obrigatório (MAC) do Linux, como SELinux e AppArmor, podem negar chamadas de sistema (syscalls) essenciais como recvmsg() ou acessos do Apache e Dovecot a portas específicas de rede.

1. Auditoria do SELinux#

Verifique o estado e as violações do SELinux:

# Verificar o modo atual
getenforce

# Buscar negativas (denials) do SELinux recentes
ausearch -m avc -ts recent | head -20

Se houver violações AVC, certifique-se de que os booleanos de rede do Apache estão ativos:

getsebool -a | grep -i "httpd\|network"

Verifique o contexto de segurança dos arquivos de regras e do Apache:

ls -Z /etc/csf/
ls -Z /usr/local/apache/

2. Auditoria do AppArmor#

Se estiver utilizando sistemas baseados em Ubuntu ou Debian com AppArmor, verifique se existem perfis aplicando restrições ativas aos daemons envolvidos:

aa-status

iptables-legacy, nftables e a obsolescência operacional do CSF#

O CSF foi desenhado como uma camada de scripts Perl gerenciando iptables, muitas vezes iptables-legacy.

Em sistemas modernos, como AlmaLinux 8/9, Rocky Linux 8/9, Debian recente e Ubuntu 22.04+, o backend real do firewall no kernel é o nftables. A tradução automática de regras em ambientes complexos pode gerar comportamentos inesperados:

CSF -> iptables wrapper -> iptables-nft ou iptables-legacy -> nftables/kernel

Insistir em ajuste fino quando a ferramenta ignora ou reorganiza flags em um ambiente com NAT agressivo vira perda de tempo operacional. Em alguns casos, desativar uma proteção automatizada devolve estabilidade mais rápido do que tentar forçar allow em uma chain que o pacote nunca alcança.

Protocolo de backup pré-desativação#

Se for necessário desativar o CSF para fins de migração ou depuração profunda, garanta a integridade operacional com o backup prévio completo de todas as políticas do CSF e iptables:

# Backup das configurações do CSF
tar czf /root/csf-backup-$(date +%Y%m%d).tar.gz /etc/csf/

# Backup das regras atuais do iptables em disco
iptables-save > /root/iptables-backup-$(date +%Y%m%d).rules

# Salvar a listagem amigável de regras do CSF
csf -l > /root/csf-rules-before.txt

Com os backups salvos, desative temporariamente o CSF para isolamento de problemas:

csf -x

Auditoria de hardware e interfaces de rede#

A nível de infraestrutura física, a perda de pacotes ou desconexões intermitentes podem ser causadas por falhas na placa de rede, incompatibilidade de MTU ou erros físicos de link.

Audite as estatísticas de erros das placas de rede físicas do servidor:

# Exibir o status da interface de rede
ip link show

# Exibir estatísticas detalhadas de transmissão e erros na interface
ip -s link show eth0

# Verificar contadores diretos de descarte (drops) no kernel
cat /proc/net/dev

Valide a velocidade, modo duplex e integridade física com o ethtool:

ethtool eth0 | grep -i "speed\|duplex\|link"

Plano de rollback do CSF#

Após concluir o diagnóstico ou a migração, reverta as configurações para o estado original e reabilite o CSF para restabelecer a segurança do servidor:

# Reabilitar o motor do CSF
csf -e

# Se necessário, restaurar a configuração anterior a partir do backup
cp /root/csf-backup-*/csf.conf /etc/csf/csf.conf
csf -r

# Verificar o status atual do CSF
csf -s

# Validar se o IP do cliente está na lista de permissão ativa do CSF
csf -g 1.2.3.4

Monitoramento de pós-alteração em produção#

Após desativar o CSF ou alterar regras de conntrack e rede, monitore de forma contínua o tráfego do IP do cliente e as conexões do servidor por pelo menos 15 a 30 minutos:

# Monitorar logs de autenticação do sistema
tail -f /var/log/secure | grep "1.2.3.4"

# Monitorar acessos HTTP nas portas administrativas do Apache/cPanel
tail -f /usr/local/apache/logs/access.log | grep "1.2.3.4"

# Monitorar logs de atividade do daemon LFD (se mantido ativo)
tail -f /var/log/lfd.log | grep "1.2.3.4"

# Observar descartes de pacotes gerais em tempo real
watch -n 1 "iptables -L -n -v | grep DROP"

Checklist: IP bloqueado com firewall "limpo"#

Siga este roteiro estruturado para triagem e correção de problemas de conexão fantasma:

1. Verificação CSF#

• [ ] csf -g IP - verificar se o IP consta nas chains de liberação ativa.
• [ ] grep IP /etc/csf/csf.allow - confirmar o registro estático na whitelist.
• [ ] grep IP /etc/csf/csf.ignore - confirmar o registro na ignore list.
• [ ] grep "IP" /var/log/lfd.log - auditar log em busca de detecção de brute force ou alterações temporárias.

2. Verificação de rota e redes#

• [ ] ip route get IP - validar a rota de retorno e endereço IP de origem (src).
• [ ] Verificar integridade física e erros do link de rede com ip -s link e ethtool.
• [ ] Analisar regras de tradução de endereços de rede nat com iptables -t nat -L.

3. Rastreamento e conntrack#

• [ ] Comparar nf_conntrack_count com nf_conntrack_max para identificar saturação.
• [ ] Verificar mensagens de "table full" nos logs do kernel com dmesg.
• [ ] Ajustar valores de timeout do conntrack para evitar retenção excessiva.

4. Rp_filter e políticas de kernel#

• [ ] Verificar se rp_filter está ativo nas interfaces de rede.
• [ ] Validar o parâmetro accept_redirects e accept_source_route.

5. Prioridade de chains do iptables#

• [ ] Listar regras com iptables -L -n --line-numbers.
• [ ] Verificar se as regras de PACKET_FILTER ou drops de estados INVALID estão avaliadas acima da chain ALLOWIN.

6. Monitoramento de contadores#

• [ ] Executar monitoramento com contadores em tempo real para verificar se o tráfego atinge a whitelist.

7. Auditoria de serviço e aplicação#

• [ ] Validar logins bloqueados na camada administrativa através do cPHulk.
• [ ] Auditar conexões do Dovecot via doveadm who e limites em mail_max_userip_connections.
• [ ] Testar conexões SSL/TLS locais nas portas 2083 e 2087 com openssl.

8. Controle de acesso mandatório (MAC)#

• [ ] Verificar AVC Denials do SELinux e status do AppArmor.

9. Decisão operacional#

• [ ] Avaliar se o CSF deve ser mantido ou se a melhor decisão de estabilidade é migrar para regras nativas do nftables/iptables.

Tabela comparativa de problemas e severidade#

Veja também

Infraestrutura IP bloqueado no servidor? Como identificar a conta de e-mail causadora via WHM e cPanel

Infraestrutura Debugando pure-ftpd travado na mensagem de boas-vindas em cPanel/OVH

Infraestrutura Como contornar o limite global de e-mails no cPanel e CloudLinux: resolvendo o erro XID psafa9

Este post está licenciado sob CC BY-NC.