Liberando ranges de IP do Cloudflare no CSF sem

Se você roda aplicações em um servidor Linux e usa o ConfigServer Security & Firewall (CSF) integrado ao Login Failure Daemon (LFD), já conhece a tranquilidade que ele traz ao barrar tentativas de invasão e varreduras automáticas. Mas quando você coloca o site atrás do Cloudflare como proxy reverso, a dinâmica muda por completo.

Como todo o tráfego web passa antes pelos servidores de borda do Cloudflare, o seu servidor passa a enxergar esses nós como a origem direta de todas as conexões HTTP e HTTPS. Se visitantes normais digitarem a senha errada repetidas vezes ou dispararem regras de proteção, o LFD pode bloquear os IPs do próprio Cloudflare. Quando isso acontece, milhares de usuários legítimos perdem o acesso ao site de uma só vez.

Abaixo, mostro como funciona o comando de liberação (csf -a), quais são as formas mais limpas de cadastrar os blocos oficiais do Cloudflare e como restaurar o IP real dos visitantes no servidor web para não perder a visibilidade dos logs.

Como funciona o comando CSF -a por baixo do capô#

O comando csf -a serve para autorizar um endereço no firewall, mas é importante entender o impacto dessa regra antes de sair liberando blocos de rede inteiros.

A sintaxe básica no terminal é:

csf -a [IP_OU_CIDR] [COMENTARIO_OPCIONAL]

Onde:

-a (Allow): grava o endereço ou bloco de rede no arquivo de permissões /etc/csf/csf.allow.
IP_OU_CIDR: o endereço específico (como 192.0.2.10) ou a sub-rede completa (como 192.0.2.0/24).
COMENTARIO_OPCIONAL: uma anotação em texto entre aspas para identificar quem é o dono daquele acesso.

Quando você roda esse comando, o CSF executa três tarefas automáticas:

Gravação persistente: o endereço entra em /etc/csf/csf.allow, garantindo que a regra continue ativa mesmo após reiniciar a máquina ou recarregar o serviço com csf -r.
Imunidade no LFD: o Login Failure Daemon interrompe o rastreamento desse IP. Isso significa que tentativas falhas de autenticação vindas desse endereço não vão disparar bloqueios automáticos.
Aplicação imediata: o firewall insere a regra nas tabelas do iptables ou nftables, aceitando pacotes daquela origem sem esperar pelo próximo ciclo de checagem.

Exemplos do dia a dia no terminal:

# Liberação simples de um IP fixo
csf -a 203.0.113.42

# Liberação com comentário descritivo
csf -a 203.0.113.42 "VPN de Acesso Remoto"

# Liberação de uma faixa completa (CIDR)
csf -a 198.51.100.0/24 "Escritorio Central"

Uma dica importante: adicionar um IP de forma permanente em csf.allow remove a camada de proteção contra força bruta do LFD para aquele endereço. Se você precisa liberar um acesso temporário para prestar suporte ou fazer uma manutenção rápida, prefira a liberação temporária com expiração automática:

# Libera o IP por 3600 segundos (1 hora)
csf -tempallow 203.0.113.42 3600 "Acesso temporario suporte"

Se precisar remover uma liberação permanente anterior, use a flag -ar:

csf -ar 203.0.113.42

Liberando as faixas de IP oficiais do Cloudflare#

Para evitar que o tráfego legítimo seja interrompido por engano, precisamos permitir que os servidores de borda do Cloudflare conversem livremente com o nosso host. Existem dois métodos diretos para fazer isso.

Opção 1: Injeção direta pelo terminal#

Se o seu site está caindo por falsos positivos neste exato momento e você precisa de uma resposta imediata, este laço de repetição baixa as listas oficiais da API do Cloudflare e cadastra cada faixa no CSF:

# Baixa e libera os blocos IPv4
wget https://www.cloudflare.com/ips-v4 -O - | while read line; do csf -a $line "Cloudflare IPv4"; done

# Baixa e libera os blocos IPv6
wget https://www.cloudflare.com/ips-v6 -O - | while read line; do csf -a $line "Cloudflare IPv6"; done

# Recarrega as regras do firewall
csf -r

Essa solução resolve o problema na hora, gravando todas as faixas diretamente no /etc/csf/csf.allow.

Opção 2: Inclusão dinâmica com a diretiva include#

O CSF oferece suporte à inclusão de listas remotas diretamente dentro do arquivo de configuração. Essa abordagem mantém seu arquivo local limpo e garante que as listas sejam lidas da fonte oficial a cada recarga.

Abra o arquivo de permissões:

nano /etc/csf/csf.allow

Adicione ao final do arquivo as seguintes linhas:

# Cloudflare IPv4
Include https://www.cloudflare.com/ips-v4

# Cloudflare IPv6
Include https://www.cloudflare.com/ips-v6

Salve o arquivo e recarregue o firewall para aplicar:

csf -r

Com isso, sempre que o CSF reiniciar ou recarregar suas regras, ele vai consultar e carregar os blocos oficiais mais recentes.

Restaurando o IP real no servidor web#

Liberar as faixas do Cloudflare no firewall resolve a indisponibilidade, mas cria outro problema se você parar por aqui: os logs do seu servidor web passarão a exibir apenas os IPs do Cloudflare, escondendo quem realmente fez a requisição.

Sem saber o IP de origem de quem acessou a página, você perde a capacidade de identificar tentativas de invasão, varreduras de formulários ou ataques direcionados.

Para resolver isso, precisamos instruir o servidor web a ler o cabeçalho HTTP CF-Connecting-IP (enviado pelo Cloudflare) e substituir o IP do proxy pelo IP real do visitante.

Configuração no Nginx#

Se você usa Nginx, certifique-se de que o módulo http_realip_module está presente (ele já vem compilado na grande maioria das distribuições) e adicione a configuração no bloco http ou dentro do arquivo de configuração do seu site em /etc/nginx/conf.d/:

# Lista de proxies confiaveis do Cloudflare (exemplos de faixas oficiais)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

# Faixas IPv6 do Cloudflare
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

# Extrai o endereco real a partir do cabecalho do Cloudflare
real_ip_header CF-Connecting-IP;

Teste a sintaxe e recarregue o Nginx:

nginx -t && systemctl reload nginx

Configuração no Apache#

No Apache, precisamos do módulo remoteip. Ative o módulo caso ainda não esteja ativo:

# Em sistemas baseados em Debian/Ubuntu
a2enmod remoteip

Em seguida, crie ou edite o arquivo de configuração (por exemplo, /etc/apache2/conf-available/remoteip.conf no Ubuntu ou dentro de /etc/httpd/conf.d/remoteip.conf no CentOS/AlmaLinux):

<IfModule remoteip_module>
    RemoteIPHeader CF-Connecting-IP
    RemoteIPTrustedProxy 173.245.48.0/20
    RemoteIPTrustedProxy 103.21.244.0/22
    RemoteIPTrustedProxy 103.22.200.0/22
    RemoteIPTrustedProxy 103.31.4.0/22
    RemoteIPTrustedProxy 141.101.64.0/18
    RemoteIPTrustedProxy 108.162.192.0/18
    RemoteIPTrustedProxy 190.93.240.0/20
    RemoteIPTrustedProxy 188.114.96.0/20
    RemoteIPTrustedProxy 197.234.240.0/22
    RemoteIPTrustedProxy 198.41.128.0/17
    RemoteIPTrustedProxy 162.158.0.0/15
    RemoteIPTrustedProxy 104.16.0.0/13
    RemoteIPTrustedProxy 104.24.0.0/14
    RemoteIPTrustedProxy 172.64.0.0/13
    RemoteIPTrustedProxy 131.0.72.0/22
    RemoteIPTrustedProxy 2400:cb00::/32
    RemoteIPTrustedProxy 2606:4700::/32
    RemoteIPTrustedProxy 2803:f800::/32
    RemoteIPTrustedProxy 2405:b500::/32
    RemoteIPTrustedProxy 2405:8100::/32
    RemoteIPTrustedProxy 2a06:98c0::/29
    RemoteIPTrustedProxy 2c0f:f248::/32
</IfModule>

Reinicie o Apache para colocar a regra em vigor:

systemctl restart apache2 # ou httpd

Testando a configuração e monitorando os logs#

Depois de aplicar os ajustes no firewall e no servidor web, vale a pena acompanhar os arquivos de log em tempo real para ter certeza de que tudo está se comportando como o esperado:

Acompanhe os acessos web: rode tail -f /var/log/nginx/access.log (ou o caminho de log correspondente do seu domínio) e faça uma requisição pelo navegador. O primeiro campo de cada linha deve exibir o seu IP de internet pessoal, e não um bloco começando com 172.68. ou 162.158..
Acompanhe os alertas do LFD: observe /var/log/lfd.log. Se alguém tentar abusar de formulários ou errar senhas, o LFD vai anotar o IP real do usuário.
Verifique se o CSF não está bloqueando a borda: use csf -g [IP] para consultar se algum IP específico do Cloudflare caiu nas regras de bloqueio.

Com essas três pontas amarradas (liberação das faixas no CSF, imunidade no LFD e recuperação do IP real no servidor web), o seu site fica protegido contra ataques sem o risco de derrubar conexões legítimas por falsos positivos.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

Este post está licenciado sob CC BY-NC.

Liberando ranges de IP do Cloudflare no CSF sem comprometer a segurança

Como funciona o comando CSF -a por baixo do capô#

Liberando as faixas de IP oficiais do Cloudflare#

Opção 1: Injeção direta pelo terminal#

Opção 2: Inclusão dinâmica com a diretiva include#

Restaurando o IP real no servidor web#

Configuração no Nginx#

Configuração no Apache#

Testando a configuração e monitorando os logs#

Este artigo foi útil?

Comentários

Como funciona o comando CSF -a por baixo do capô#

Liberando as faixas de IP oficiais do Cloudflare#

Opção 1: Injeção direta pelo terminal#

Opção 2: Inclusão dinâmica com a diretiva include#

Restaurando o IP real no servidor web#

Configuração no Nginx#

Configuração no Apache#

Testando a configuração e monitorando os logs#

Este artigo foi útil?

Veja também

Comentários