Permitir apenas IPs da Cloudflare no nginx, Apache e IIS

O proxy da Cloudflare esconde o endereço IP do seu servidor e acrescenta proteção contra DDoS, mas apenas para o tráfego que passa efetivamente pela Cloudflare. [1] Quem descobrir o IP real pode ligar-se diretamente ao servidor e contornar tudo isso. Este guia mostra como permitir apenas IPs da Cloudflare nas portas 80 e 443 (com o UFW e o nginx ou o Apache no Ubuntu 24.04, e com a Windows Defender Firewall e o IIS no Windows Server 2022 ou 2025) e como manter atualizada a lista da Cloudflare.

Porque é que quem tem o IP do seu servidor pode contornar a Cloudflare

Os pedidos enviados diretamente para o IP do seu servidor nunca passam pela Cloudflare, pelo que não beneficiam de nenhuma das suas proteções. Um registo DNS com proxy ativo esconde o IP de origem, e a Cloudflare pede-lhe que permita os endereços IP dela no servidor de origem, para que os pedidos da própria Cloudflare cheguem ao servidor. [1] Ao nível da rede, a Cloudflare vai mais longe e recomenda bloquear explicitamente todo o tráfego que não venha da Cloudflare nem de parceiros em que confie. [1]

Limite à Cloudflare apenas as portas TCP 80 e 443. O SSH no Linux e o Ambiente de Trabalho Remoto no Windows devem continuar limitados ao seu próprio endereço IP ou a uma VPN: a nossa lista de verificação de segurança SSH e o guia sobre uma rede privada WireGuard explicam as duas opções.

A Cloudflare classifica uma lista de IPs permitidos como moderadamente segura, e o Authenticated Origin Pulls e o Cloudflare Tunnel como muito seguros. [1] Por isso, este guia combina várias camadas de verificação:

Uma firewall no próprio servidor não consegue travar uma inundação de tráfego capaz de saturar a ligação da máquina. Na StealthRDP, os planos da UE incluem proteção DDoS ao nível da rede; os planos dos EUA não incluem. A nossa lista de verificação de proteção DDoS para VPS trata dessa parte.

Onde a Cloudflare publica os seus intervalos de IP

A página IP Ranges da Cloudflare, em www.cloudflare.com/ips, pretende ser a lista definitiva. Tem ligações para cópias em texto simples em www.cloudflare.com/ips-v4 e www.cloudflare.com/ips-v6, e a mesma lista está disponível na API da Cloudflare. [2]

A lista muda mesmo. O histórico de atualizações mostra que o 199.27.128.0/21 foi removido em 2017, que o 104.16.0.0/12 foi substituído pelo 104.16.0.0/13 e pelo 104.24.0.0/14 em 2021 e que o 2405:b500::/32 foi removido em 2022 e voltou a ser acrescentado em 2023. [2] Se faltar um intervalo, os pedidos da Cloudflare vindos desse intervalo são bloqueados [1], por isso uma lista colada uma única vez acaba por ficar desatualizada.

Como permitir apenas IPs da Cloudflare no UFW

Para permitir apenas IPs da Cloudflare no UFW, acrescente regras que abram as portas 80 e 443 a cada intervalo da Cloudflare e, depois, apague as regras que abrem essas portas a toda a gente. O UFW é a ferramenta de firewall predefinida do Ubuntu e vem desativado de início; pode abrir uma porta a um único anfitrião ou a uma rede, como em sudo ufw allow proto tcp from 192.168.0.2 to any port 22, e funciona com IPv4 e IPv6. [3]

sudo ufw allow proto tcp from 198.51.100.7 to any port 22
sudo ufw enable
sudo ufw status verbose

#!/usr/bin/env bash
# Rebuild Cloudflare's IP ranges for UFW, nginx and Apache.
set -euo pipefail
export LC_ALL=C PATH=/usr/sbin:/usr/bin:/sbin:/bin

STATE=/etc/cloudflare-ips.txt
NEW=$(mktemp)
trap 'rm -f "$NEW"' EXIT

v4=$(curl -fsS --max-time 30 https://www.cloudflare.com/ips-v4)
v6=$(curl -fsS --max-time 30 https://www.cloudflare.com/ips-v6)
printf '%s\n%s\n' "$v4" "$v6" | grep -E '^[0-9a-fA-F:.]+/[0-9]+$' | sort -u > "$NEW"

# Stop before touching anything if a list is missing or cut short.
if ! grep -q '\.' "$NEW" || ! grep -q ':' "$NEW" || [ "$(wc -l < "$NEW")" -lt 10 ]; then
  echo "Cloudflare lists look wrong; nothing changed" >&2
  exit 1
fi

touch "$STATE"
# Add new ranges first, then remove the ones Cloudflare dropped.
comm -13 "$STATE" "$NEW" | while read -r net; do
  ufw allow proto tcp from "$net" to any port 80
  ufw allow proto tcp from "$net" to any port 443
done
comm -23 "$STATE" "$NEW" | while read -r net; do
  ufw delete allow proto tcp from "$net" to any port 80 || true
  ufw delete allow proto tcp from "$net" to any port 443 || true
done
cp "$NEW" "$STATE"

if command -v nginx > /dev/null; then
  { sed 's/.*/set_real_ip_from &;/' "$NEW"; echo 'real_ip_header CF-Connecting-IP;'; } \
    > /etc/nginx/conf.d/cloudflare-realip.conf
  nginx -t && systemctl reload nginx
fi

if command -v apache2ctl > /dev/null; then
  cp "$NEW" /etc/apache2/cloudflare-ips.lst
  apache2ctl configtest && systemctl reload apache2
fi

sudo chmod 755 /usr/local/sbin/cloudflare-ips
sudo /usr/local/sbin/cloudflare-ips
echo '17 4 * * * root /usr/local/sbin/cloudflare-ips' | sudo tee /etc/cron.d/cloudflare-ips

sudo ufw status numbered
# For example, if you once ran "ufw allow 80" and "ufw allow 443":
sudo ufw delete allow 80
sudo ufw delete allow 443
sudo ufw status numbered

As portas publicadas pelo Docker contornam o UFW

O Docker desvia, na tabela nat, o tráfego destinado a uma porta publicada antes de este chegar à cadeia INPUT que o UFW usa, pelo que as regras do UFW são ignoradas para essa porta. [4] O Docker também desaconselha editar as regras que cria, e desligar a gestão do iptables por parte do Docker provavelmente deixa a rede dos contentores sem funcionar. [4] Mantenha no sistema anfitrião o servidor web que recebe o tráfego da Cloudflare, ou filtre o tráfego numa firewall à frente do servidor.

nginx e Apache: reponha o IP dos visitantes e recuse pedidos diretos ao IP

Os dois servidores web conseguem substituir o endereço da Cloudflare pelo do visitante, que a Cloudflare envia no cabeçalho CF-Connecting-IP. [5] Isto é necessário porque, com a firewall em funcionamento, todos os pedidos chegam de endereços da Cloudflare. Confie no cabeçalho apenas quando vier dos intervalos da Cloudflare: a Cloudflare avisa que, caso contrário, pode ser falsificado. [5]

nginx

A configuração que a Cloudflare indica para o nginx usa o módulo realip: uma linha set_real_ip_from por cada intervalo da Cloudflare, mais real_ip_header CF-Connecting-IP, com os intervalos sempre atualizados. [5] O script de atualização escreve este ficheiro:

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
# ...one line for every Cloudflare range...
set_real_ip_from 2c0f:f248::/32;
real_ip_header CF-Connecting-IP;

A seguir, recuse os pedidos para nomes que não aloja, como um pedido feito diretamente ao IP: a Cloudflare aconselha a aceitar apenas os valores do cabeçalho Host que espera receber. [1] No nginx, isso faz-se com um servidor predefinido (default server). deny all recusa todos os pedidos que chegam a esse servidor [6], e ssl_reject_handshake on rejeita os handshakes TLS no bloco server onde está; o próprio exemplo do nginx combina-o com default_server, para que falhem os handshakes para qualquer outro nome. A diretiva exige o nginx 1.19.4 ou posterior. [7]

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    deny all;
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

Retire default_server de qualquer outro bloco server que use estas portas, ative o ficheiro e recarregue o nginx.

O nginx também poderia guardar a lista da Cloudflare como linhas allow seguidas de um deny all final, já que as regras são verificadas por ordem até uma corresponder. [6] Use essa abordagem apenas num servidor que não reponha os IPs dos visitantes e, nesse servidor, registe em vez disso $http_cf_connecting_ip no registo de acessos. [5] Um endereço reposto é o do visitante, por isso uma lista que só permita a Cloudflare recusaria os visitantes reais, como a documentação do Apache explica a propósito do seu próprio módulo. [8]

Apache 2.4

Os passos que a Cloudflare indica para o Apache usam o mod_remoteip: ative o módulo, defina RemoteIPHeader CF-Connecting-IP, indique os intervalos da Cloudflare como proxies de confiança em /etc/apache2/conf-available/remoteip.conf, ative esse ficheiro e mude %h para %a na linha LogFormat do formato combined em /etc/apache2/apache2.conf. [5] RemoteIPTrustedProxyList lê os intervalos de um ficheiro no arranque, o que se adapta bem ao script. [8]

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxyList /etc/apache2/cloudflare-ips.lst

sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

Há dois pormenores importantes. Sem proxies de confiança, o mod_remoteip confia no cabeçalho vindo de qualquer anfitrião, pelo que qualquer pessoa poderia falsificar o próprio endereço. [8] Além disso, depois da substituição, Require ip e o campo %a do registo veem o endereço do visitante, enquanto %{c}a e CONN_REMOTE_ADDR mantêm o endereço da Cloudflare que estabeleceu a ligação. [8] Por isso, mantenha os intervalos da Cloudflare na lista de confiança e na firewall, e use Require ip apenas em regras sobre visitantes, como uma página de administração limitada ao seu IP.

IIS no Windows Server: limite as portas 80 e 443 à Cloudflare

Num VPS Windows com Windows Server 2022 ou 2025, a Windows Defender Firewall faz o mesmo trabalho a partir do PowerShell. O New-NetFirewallRule aceita sub-redes IPv4 e IPv6 em notação CIDR no parâmetro -RemoteAddress, pelo que uma só regra contém todos os intervalos, e o Set-NetFirewallRule altera uma regra existente. [9]

$ErrorActionPreference = 'Stop'
$ranges = foreach ($list in 'ips-v4', 'ips-v6') {
    (Invoke-RestMethod "https://www.cloudflare.com/$list") -split "`n" |
        ForEach-Object { $_.Trim() } | Where-Object { $_ -match '^[0-9a-fA-F:.]+/\d+$' }
}
$v6 = @($ranges | Where-Object { $_ -match ':' })
if ($ranges.Count -lt 10 -or $v6.Count -eq 0 -or $v6.Count -eq $ranges.Count) {
    throw 'Cloudflare lists look wrong; nothing changed'
}

$name = 'Cloudflare HTTP and HTTPS'
if (Get-NetFirewallRule -DisplayName $name -ErrorAction SilentlyContinue) {
    Set-NetFirewallRule -DisplayName $name -RemoteAddress $ranges
} else {
    New-NetFirewallRule -DisplayName $name -Direction Inbound -Protocol TCP `
        -LocalPort 80,443 -RemoteAddress $ranges -Action Allow
}

Uma regra de permissão deixa entrar todos os pacotes que lhe correspondem [9], pelo que qualquer outra regra ativa que permita as portas 80 ou 443 a partir de qualquer endereço as mantém abertas a toda a gente. Liste essas regras, verifique cada uma e desative as que não forem suas:

Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True |
    Where-Object { $_.DisplayName -ne 'Cloudflare HTTP and HTTPS' -and
        (($_ | Get-NetFirewallPortFilter).LocalPort -match '^(80|443)$') } |
    Select-Object Name, DisplayName
# After checking a rule: Set-NetFirewallRule -Name '<Name>' -Enabled False

Para o IIS 8.5 a 10, a Cloudflare indica como registar o IP real do visitante acrescentando CF-Connecting-IP como campo personalizado: no IIS Manager, abra Logging no site, selecione o formato W3C, escolha Select Fields e acrescente o cabeçalho. [5] Isto só altera o registo; a sua aplicação continua a ver o endereço da Cloudflare. [5]

Authenticated Origin Pulls: a verificação mais forte na origem

O Authenticated Origin Pulls (AOP) acrescenta TLS mútuo: a Cloudflare apresenta um certificado de cliente quando se liga à sua origem, e o servidor web verifica-o. Exige o modo de encriptação SSL/TLS Full ou superior. [10] A configuração global usa um certificado da Cloudflare partilhado por todas as contas Cloudflare, pelo que só prova que um pedido veio da rede da Cloudflare; para uma verificação associada à sua conta, carregue o seu próprio certificado com AOP ao nível da zona ou por nome de anfitrião. [10]

Transfira o certificado de origin pull da Cloudflare (.PEM) a partir do guia de configuração e copie-o para o servidor; não é o certificado da Cloudflare Origin CA. [10] Configure o servidor web para usar esse certificado, sem impor ainda nada; no nginx, isso significa ssl_verify_client optional: o nginx pede um certificado de cliente e, se receber um, verifica-o. [7] Depois, ative o AOP na Cloudflare: página Origin Server, separador Authenticated Origin Pulls, secção Global. [10]

Quando confirmar que o site continua a funcionar, torne a verificação obrigatória: ssl_verify_client on no nginx, SSLVerifyClient require no Apache. [10]

ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
ssl_verify_client optional;   # change to "on" to enforce

SSLCACertificateFile /etc/apache2/certs/origin-pull-ca.pem
# add this line to enforce:
SSLVerifyClient require

Cloudflare Tunnel: nenhuma porta web de entrada

O Cloudflare Tunnel fecha as portas web em vez de as filtrar. O daemon cloudflared no seu servidor só faz ligações de saída para a Cloudflare, pelo que o site não precisa de um endereço IP publicamente encaminhável. [1] Com o túnel ativo, as portas 80 e 443 podem ficar fechadas. A Cloudflare classifica o Tunnel como muito seguro e disponibiliza-o a todos os clientes; o preço a pagar é ter mais um serviço para gerir. [1]

Como o IP de origem é exposto e como testar o bloqueio

Normalmente, o IP de origem é exposto por registos DNS-only, pelo correio eletrónico no mesmo servidor ou pelo histórico de DNS, como explica o guia de proteção da origem da Cloudflare. [1]

• Registos DNS-only que contêm o IP de origem, incluindo registos SPF e TXT.
• Correio no mesmo servidor: uma mensagem enviada para um endereço inexistente é devolvida e mostra o IP do servidor de correio.
• Histórico de DNS: os registos antigos ficam guardados e mostram o IP que usava antes da Cloudflare.

A Cloudflare aconselha a mudar o IP de origem depois de concluída a adesão ao serviço. [1] Faça-o depois do bloqueio, para que o novo endereço nunca tenha sido público. Todos os servidores da StealthRDP, VPS Linux ou Windows, têm um endereço IPv4 dedicado, e cada mudança de IP custa 5 €, mediante pedido ao suporte.

Depois, teste a partir do seu próprio computador, que a firewall impede de chegar às portas 80 e 443:

# Straight to the origin IP: both should hang, then fail
curl http://203.0.113.10/
curl https://203.0.113.10/

# Through Cloudflare: should return your page
curl https://www.example.com/

O resultado que procura é um timeout (tempo de espera esgotado). Uma página 403, ou qualquer erro de TLS ou de certificado, significa que o pedido chegou ao servidor web e, portanto, que a firewall continua aberta.

Depois de tornar o AOP obrigatório, um pedido que não passe pela Cloudflare também deve falhar na verificação do certificado. [10] A partir do seu computador, a firewall bloqueia um pedido destes antes de ele chegar tão longe, por isso faça este teste no próprio servidor:

curl -k --resolve www.example.com:443:127.0.0.1 https://www.example.com/

O nginx deve responder com um erro 400 porque não foi enviado nenhum certificado de cliente, e o Apache deve recusar o handshake TLS. Se, a partir daí, os visitantes virem páginas de erro da Cloudflare, confirme que todos os intervalos estão presentes; o nosso guia sobre o erro 502 Bad Gateway trata outros erros de origem atrás da Cloudflare.

Perguntas frequentes

Onde encontro os intervalos de IP da Cloudflare?

A Cloudflare publica-os em www.cloudflare.com/ips, com listas em texto simples em www.cloudflare.com/ips-v4 e www.cloudflare.com/ips-v6, e os mesmos dados na respetiva API. A lista muda de vez em quando, por isso atualize a sua cópia automaticamente. [2]

Alguém pode contornar a Cloudflare com o IP do meu servidor?

Sim, se o servidor aceitar tráfego web de qualquer endereço. Os registos DNS-only, as mensagens de correio devolvidas e os registos DNS antigos podem revelar o IP, por isso a Cloudflare aconselha a bloquear o tráfego que não venha dos endereços dela. [1]

Como vejo o IP real dos visitantes atrás da Cloudflare?

A Cloudflare envia-o no cabeçalho CF-Connecting-IP. O módulo realip do nginx e o mod_remoteip do Apache podem usá-lo, desde que só confie no cabeçalho quando vier dos intervalos da Cloudflare. [5]

O UFW bloqueia as portas do Docker?

Não bloqueia as portas que um contentor publica. O Docker desvia esse tráfego na tabela nat antes de chegar às cadeias que o UFW usa, pelo que as regras do UFW são ignoradas nessas portas. [4]

Preciso de portas abertas para o Cloudflare Tunnel?

Não é preciso abrir nenhuma porta web de entrada. O daemon cloudflared só faz ligações de saída para a Cloudflare, pelo que o servidor não precisa de um endereço IP publicamente encaminhável para o site. [1]